Agent 六层架构
面向业务场景的 Agent 产品架构分层模型：场景定义→入口设计→编排→能力→治理→运营
简介
Agent 六层架构是刘天真在 woshipm.com 提出的一套面向业务场景的 Agent 落地产品架构模型。它回答的核心问题是：一个要在真实业务中长期运行的 Agent，应该长什么样？
该模型认为，Agent 落地的难点不只是模型够不够聪明，而是如何把不确定的智能能力放进一个要求稳定、可控、可追踪的业务系统里。六层架构把 Agent 产品从上到下拆成六个层次，每层解决一个明确的问题，六层需要业务、产品、技术、运营、安全和一线使用者共同参与。
六层详解
第 1 层：场景定义层
核心问题：Agent 到底要完成什么业务任务？
场景定义层是六层的起点，也是最容易被跳过的一层。很多团队做 Agent 第一反应是讨论模型、RAG、Function Calling、Workflow，但 Agent 落地真正应该先问的是”它到底要完成什么业务任务”。如果任务定义不清，后面的模型、知识库、工具调用都会变成能力堆砌。
以客服工单 Agent 为例，场景定义层需要回答：
- 谁在什么场景下触发 Agent？
- 用户输入通常是什么形式？
- Agent 最终要交付什么结果？
- 完成任务需要哪些知识和系统能力？
- 哪些动作可以自动执行，哪些必须人工确认？
第 2 层：入口设计层
核心问题：用户从哪里进入 Agent？
入口设计层定义用户与 Agent 交互的界面和通道。可能是客服工作台的侧边栏、企业微信群机器人、网页插件、内部系统的嵌入式入口等。入口设计直接影响用户使用频率和体验——独立 AI 入口的留存率必然走低，能嵌入现有工作流的入口才有持续使用率。
第 3 层：编排层
核心问题：Agent 怎么把目标变成行动？
编排层是六层架构的大脑，负责把用户目标拆成步骤，并决定调用哪些能力。包含五个核心组件：
- 任务规划：把复杂目标拆成可执行步骤
- 流程控制：决定步骤执行顺序和分支
- 工具选择：根据任务类型选择合适的能力
- 上下文管理：维护对话历史和用户状态
- 人工确认节点：在高风险动作前插入人工审核
第 4 层：能力层
核心问题：Agent 能用什么工具？
能力层提供底层技术支撑，包括：
- 大模型：理解、推理、生成
- 知识库：帮助文档、产品文档、SOP
- 工具 API：第三方系统调用
- 业务系统：订单、账号、支付、物流等内部系统
- 搜索能力：知识检索
- 消息系统：通知、工单、邮件
能力越复杂，越需要明确每个能力的输入、输出、限制和失败处理方式。
第 5 层：治理层
核心问题：Agent 的行为是否可控？
治理层决定 Agent 是否可控、可追责、可持续优化。四大核心机制见 Agent 运行治理：
- 权限控制
- 风险分级
- 日志追踪
- 效果评估
第 6 层：运营层
核心问题：Agent 的效果会不会随时间衰减？
运营层保证 Agent 的持续有效性，包括：
- 知识更新：产品文档/SOP 变更时同步更新
- 反馈收集：用户满意度、bad case 积累
- 问题复盘：定期分析失败案例
- 策略调整：根据复盘结果调整处理策略
- 版本迭代：持续优化 Agent 能力
Agent 的能力会随着业务变化而衰减，如果没有运营机制，效果会逐渐变差。
与其他架构框架的关系
与企业智能体三阶段成熟度模型的关系
企业智能体三阶段（问答型→流程型→运营型，来自申悦的企业 AI 落地方法论）描述的是演进路径——Agent 从简单到复杂的发展阶段。Agent 六层架构描述的是产品蓝图——每一阶段的 Agent 产品应该包含哪些层次。两者的结合点：问答型 Agent 可能只需要场景定义+能力层（知识库），流程型需要加入编排层和治理层，运营型需要全部六层。
与 Agent 五问框架的关系
Agent 五问（来自 Agent 工作台相关素材）是评估层的判断工具——Agent 产品是否值得做。Agent 六层架构是设计层的工程框架——做出来应该长什么样。五问判断”该不该做”，六层指导”怎么做”。
与 SOP 即思维链的关系
SOP 即思维链（来自忘机的 IoT 运维案例）解决的是”规则怎么注入 Agent”的编译问题——把老专家隐性 SOP 显性化，再翻译成 ReAct 思维链。Agent 六层架构中的编排层和能力层解决的是”Agent 内部怎么组织和执行这些规则”的架构问题。SOP as CoT 是能力层中”知识库+SOP”的输入来源。
不同素材中的观点
来自 2026-06-02-woshipm-agent-architecture-landing：
- 六层架构的原创定义：刘天真首次提出面向业务场景的 Agent 六层架构模型，以企业客服工单处理 Agent 为贯穿案例，逐层拆解每层的核心问题、关键组件和设计约束。
- Demo vs 生产的第一道分水岭：Demo 展示的是智能，生产要求的是闭环。真实客服场景中”无法登录”背后可能是十几种不同原因，Agent 需要判断类型、读取上下文、调用系统、识别风险、转人工、记录完整过程。
- 治理层是 Agent 长期运行的基石：没有权限/日志/评估/兜底机制，一旦出错很难定位问题也很难持续优化。很多团队做 Demo 时忽略了治理层，导致 Agent 上线后不可控。
- 运营层防止效果衰减：Agent 的能力会随业务变化而衰减，没有知识更新/反馈收集/问题复盘/策略调整/版本迭代机制，效果会逐渐变差。运营层不是可选项，而是六层架构的必要组成部分。
- 六层需要跨职能参与：六层不是技术部门单独完成的，也不是产品部门单独完成的。业务定义场景，产品设计入口和编排，技术构建能力层，运营维护运营层，安全把控治理层，一线使用者提供反馈。
实用信息
适用场景
六层架构适用于需要在真实业务中长期运行的 Agent 产品，特别是：
- 企业客服工单处理 Agent
- 内部知识助手 Agent
- 流程自动化 Agent
- 多步协调型 Agent
对于一次性 Demo 或个人实验性 Agent，不需要完整的六层架构。
使用方法
- 从第 1 层开始，确保任务定义清晰后再进入下一层
- MVP 阶段可以先做 1+3+4+5（场景定义+编排+能力+治理），跳过入口设计和运营层
- 稳定运行后补充第 2 层（优化入口）和第 6 层（建立运营机制）
- 每一层都需要回答”核心问题”，如果答不上来说明这一层还没设计好
常见陷阱
- 跳过第 1 层直接讨论模型和工具选型（能力堆砌）
- 只做能力层不做治理层（上线后不可控）
- 只做前五层不做运营层（效果随时间衰减）
- 六层全由技术部门独立设计（缺少业务和一线视角）