本文所称的 Skill 是一个工程工作定义：将特定领域的操作步骤、约束、输入输出契约、质量标准和所需工具封装为可复用能力单元。它不是所有 Agent 框架中都具有完全一致名称的标准对象。本文所称的 专家角色 既可以是人类专家，也可以是具备明确职责、权限与评审准则的规则服务或专用模型；高影响决策不应仅依赖角色名称，而应配置可审计的授权与升级机制。
摘要
配套流程图描述了一种面向复杂任务的协同执行模式：用户以目标、上下文和约束提出需求；AI Agent 将其转化为可执行计划，并按需调度 Skill、MCP 工具与专家角色；执行后，系统把数据、证据、文件和运行状态作为观察结果回传；Agent 通过验证与反思决定继续、重试、重新规划、请求专家复核或结束，最终形成可靠交付物。这一模式的核心不在于让模型“调用更多工具”，而在于建立受约束的闭环控制系统。
MCP（Model Context Protocol）提供了 LLM 应用连接外部数据源和工具的标准化方式，并将 Prompts、Resources 与 Tools 列为服务端能力。MCP 工具可由模型根据上下文发现和调用，但规范也明确建议在人机交互中保留用户拒绝工具调用的能力。[1] [2] 因此，MCP 解决的是“能力如何被标准化暴露与调用”；Skill 解决的是“特定任务应遵循什么方法”；专家角色解决的是“哪些结果需要专业判断、风险约束或责任审批”；AI Agent 则负责将这些能力纳入状态化、可验证的执行循环。
1. 如何阅读协同流程图
图中的主线可以压缩为以下闭环：
任务输入 → 理解与规划 → 能力选择 → 受控执行 → 观察证据 → 验证与反思 → 交付或重新规划。
其中，AI Agent 位于控制中心，Skill 库、MCP 工具和专家角色位于能力协作层。“执行与反馈闭环”并非一个附属步骤，而是决定系统是否可靠的关键层：如果 Agent 只生成计划并一次性输出，系统仍然是文本生成应用；只有当它能对工具返回、文件内容、环境状态和质量检查结果进行观察并据此改变后续行动时，才具备真正的任务执行闭环。ReAct 研究提出，让语言模型交替生成推理轨迹和任务行动，既可让推理帮助更新计划、处理异常，也可让行动获取外部信息，从而减少仅依赖内部推断带来的错误传播。[5]
| 流程层 | 图中节点 | 主要职责 | 关键产物 | 常见失败信号 |
|---|---|---|---|---|
| 输入层 | 用户需求 | 声明目标、上下文、约束和风险容忍度 | 任务说明、附件、权限范围 | 目标含糊、缺少验收标准、权限不明 |
| 决策层 | AI Agent | 任务澄清、规划、能力路由、状态管理 | 计划、调用序列、停止条件 | 目标漂移、工具选择不当、无限循环 |
| 方法层 | Skill 库 | 提供领域步骤、模板、准则与质量门槛 | 可复用工作流、输入输出契约 | Skill 不匹配、版本陈旧、前置条件不满足 |
| 连接层 | MCP 工具 | 受控访问浏览器、API、数据库、文件与计算能力 | 工具结果、资源内容、结构化数据 | 权限过大、参数错误、外部内容不可信 |
| 审查层 | 专家角色 | 领域评估、合规把关、风险升级与质量判定 | 审核意见、批准/拒绝、修订要求 | 审查标准不清、角色越权、结论不可追溯 |
| 执行层 | 执行任务 | 完成检索、计算、生成、自动化与变更 | 文件、数据、结果、操作状态 | 运行失败、超时、重复副作用 |
| 反馈层 | 观察结果、验证与反思 | 收集证据，比较实际状态与目标 | 验证报告、异常分类、重规划指令 | 只看文本不看证据、虚假完成、缺少退出条件 |
| 交付层 | 可靠交付 | 输出可使用、可核验、可追溯的成果 | 答案、报告、代码、内容、行动记录 | 结果虽生成但不可用、缺失来源或审批记录 |
2. 运行模型：从需求到可靠交付的八步闭环
2.1 任务规范化：把自然语言需求变成可执行约束
用户输入通常混合了目标、偏好、背景信息、附件、保密要求、时限和隐含风险。Agent 的第一职责不是立即调用工具，而是把需求规范化为任务契约。一个可执行的任务契约至少应明确：要达成的业务结果、允许与禁止的操作、输入与依赖、成果形式、完成判据、预算或时间上限，以及需要人工确认的风险动作。
| 字段 | 示例 | 工程意义 |
|---|---|---|
goal |
“比较三家供应商并形成决策备忘录” | 为计划和验收提供唯一主目标 |
constraints |
“只使用公开资料；不得提交表单；中文交付” | 限制工具权限与输出形式 |
acceptance_criteria |
“包含来源、价格日期、优缺点和推荐依据” | 让验证层可以判断是否完成 |
risk_level |
“中等：涉及商业建议，不得自动签约或付款” | 决定专家审查与用户确认门槛 |
output_contract |
“Markdown 报告，附参考资料和数据表” | 避免执行正确却交付格式错误 |
stop_conditions |
“资料不足、出现登录墙、达到预算上限即暂停” | 防止盲目重试和无限循环 |
这一阶段应将事实、假设、待确认项和不可执行项分开。若缺少完成任务所必需的信息，Agent 应提出窄而清晰的问题；若需求已足够明确，则应记录合理假设并继续推进。这样做的价值是将“语言理解问题”前移为“可审计的任务建模问题”，降低后续工具调用和专家审查的返工成本。
2.2 计划与路由：确定步骤、依赖和权限边界
计划不是一段面向用户的解释文字，而是一份可运行的控制结构。它需要指出哪些步骤可并行、哪些步骤依赖前序证据、何时应选用 Skill、何时应调用工具、何时需要专家判断，以及在什么条件下停止或回滚。复杂任务的计划应按阶段保留中间状态，而不是一次生成一个冗长的工具调用清单。
实际系统可将路由规则表达为“任务特征 → 能力组合”的映射。例如，结构化数据清洗优先路由至数据分析 Skill 与文件/数据库工具；涉及外部事实的研究任务要求检索 Skill、网页工具和来源验证；涉及法律、财务、医疗或高影响人事判断的任务还应触发专业审查与人工确认。Agent 的路由权不应覆盖权限边界：即使模型认为某工具能解决问题，也只能在已授权范围内选择调用。
2.3 Skill 选择：复用方法，而不是只复用提示词
Skill 的价值在于将成功经验固化为可重复执行的方法单元。一个工程化 Skill 不应只是几句提示词，而应包含明确的触发条件、输入模式、前置检查、处理步骤、允许使用的工具、输出模式、质量检查和失败升级规则。这样，Agent 可以根据任务类型选择方法，而不是在每次执行时从零开始构造流程。
| Skill 元素 | 推荐内容 | 示例 |
|---|---|---|
| 适用范围 | 解决什么问题、何时不应使用 | “仅适用于含数值列的 CSV 分析” |
| 输入契约 | 必需字段、文件类型、数据敏感级别 | 数据文件、指标定义、时间范围 |
| 前置条件 | 工具、权限、数据质量和风险要求 | 已授权读取文件；列名可识别 |
| 执行步骤 | 可审计的阶段化操作 | 读取、校验、转换、分析、可视化、复核 |
| 工具依赖 | 允许的 MCP 能力与调用限制 | 只读数据库查询；禁用写操作 |
| 输出契约 | 结果格式、必含字段、证据要求 | 图表、结论、异常说明、原始数据链接 |
| 质量门槛 | 验证条件和容错范围 | 合计一致、空值已处理、时间区间已标注 |
| 升级规则 | 何时转交专家或请求用户 | 数据缺失、异常值影响结论、涉及敏感决策 |
Skill 与 Agent 的关系可概括为：Agent 负责判断“做什么、何时做、是否继续”，Skill 负责约束“在这个问题上应如何做”。当二者混淆时，常见后果是 Agent 把流程细节硬编码到规划逻辑中，造成难以维护；或 Skill 试图在不了解全局目标和权限边界的情况下擅自决定后续行动。
2.4 MCP 工具调用：把外部能力纳入标准接口
MCP 为应用连接 LLM 所需的上下文和能力提供开放协议。规范将服务器侧能力分为 Prompts、Resources 和 Tools：Prompts 可承载模板化消息或工作流，Resources 提供上下文与数据，Tools 则提供可被调用的函数能力。[1] 这与流程图中的 MCP 工具层相对应，但工程实现中应把“发现工具”“选择工具”“调用工具”“解释结果”视为四个独立步骤。
MCP 工具可由模型基于上下文发现并调用；但官方工具规范建议，系统应向用户清楚呈现暴露给模型的工具和调用提示，并为用户保留拒绝工具调用的能力。[2]
每次工具调用都应携带可审计的调用上下文，包括任务 ID、子目标、权限令牌或作用域、输入参数、超时、重试策略、幂等键和预期输出模式。工具返回不应只是一段自由文本；对于可被后续步骤消费的结果，应尽量同时提供结构化字段、来源/资源标识、错误代码、警告项和可追踪的执行元数据。这样，验证层才能区分“工具调用成功”“数据为空”“权限不足”“业务条件不成立”和“结果不满足验收标准”。
2.5 专家角色：将专业责任嵌入决策门
图中的专家角色包含领域专家、合规审查和质量评估三种典型职责。其目的不是为每一步都增加人工成本，而是在模型不应单独承担责任的节点提供更高质量或更高可信度的判断。专家角色应拥有明确的审查对象、评审准则、权限级别、响应时限和升级路径；否则，“请专家审核”会退化成无法执行的抽象要求。
领域专家关注结论是否符合专业事实和业务语义；合规审查关注数据使用、隐私、授权、监管和组织政策；质量评估关注成果是否满足用户验收标准、是否完整、是否可复现。对于高影响操作，专家的输出最好是结构化裁决，例如 approve、reject、revise、escalate，并带有理由、适用条件和到期时间。这样，Agent 可以将审查结果转换为下一步行动，而不是把专家意见当作静态备注。
2.6 执行任务：区分读取、推理、生成与变更
“执行任务”可以包括检索、计算、生成和自动化，但这些操作的风险并不相同。读取公开网页与修改生产数据库、生成草稿与对外发布内容、做本地计算与触发付款都不应使用同一种授权模型。成熟实现会给不同动作设置不同的能力等级和确认机制。
| 操作等级 | 示例 | 默认策略 | 需要的额外控制 |
|---|---|---|---|
| 低风险读取 | 读取公开文档、检索知识库、查看只读报表 | 可自动执行 | 来源记录、输入内容隔离 |
| 受限读取 | 访问内部文档、客户数据、私有 API | 基于身份与作用域执行 | 最小权限、数据脱敏、审计日志 |
| 可逆写入 | 创建草稿、生成待审批工单、保存临时文件 | 允许在策略范围内执行 | 幂等键、回滚入口、变更记录 |
| 高影响写入 | 发布内容、删除数据、转账、签约、修改权限 | 必须显式确认 | 双重授权、专家/用户审批、不可抵赖审计 |
这一区分与 MCP 工具规范的人机控制建议一致，也与 OWASP 关于按任务授予最小工具集合、按工具和资源范围配置权限、对敏感操作要求显式授权的建议相呼应。[2] [4]
2.7 观察、验证与反思：用证据替代“自我感觉完成”
工具调用完成不等于任务完成。观察层应将执行环境反馈转化为可判断的状态，例如文件是否存在、网页是否返回预期内容、数据是否通过校验、代码是否测试通过、审批是否通过、目标资源是否真的被更新。ReAct 的基本思想正是将行动与外部观察交替进行，让计划可以基于环境事实更新，而非仅根据语言模型的内部预测延续。[5]
验证层可采用三类检查。第一类是结构验证，例如输出是否含有必需章节、字段、引用或文件。第二类是事实/执行验证，例如工具返回状态、计算复算、来源交叉核验或测试结果。第三类是目标验证，即成果是否真正回答了用户目标、是否遵守约束、是否仍处于权限范围内。反思并不是要求模型无限自我批评，而是根据验证信号选择有限动作：接受、修订、换用能力、请求澄清、升级专家或终止。
2.8 交付：把答案、证据与行动状态一起交给用户
可靠交付不应只有最终文本。对于研究任务，应包含来源与不确定性；对于数据分析，应提供数据范围、方法和异常处理；对于代码任务，应提供可运行产物、验证结果和已知限制；对于需要执行外部动作的任务，应说明实际操作状态、审批记录和后续可回滚路径。交付层还应避免“把内部思考过程当成证据”：用户需要的是可核验的结论、来源和可使用产物，而不是未过滤的中间推断。
3. 四类协同角色的职责边界
3.1 AI Agent：控制平面而非万能执行器
AI Agent 是系统的控制平面，负责维护目标、选择路径、协调能力、读取观察、处理异常和决定是否停止。实践资料将 Agent 描述为由 LLM 动态主导其流程和工具使用的系统：任务明确后可独立规划与执行，但应在检查点或遇到阻塞时回到人类；执行中应通过工具结果或代码执行结果获取环境事实，并设置停止条件以保持控制。[6]
Agent 不应直接拥有无限制的外部权限，也不应在缺少证据时宣称任务已完成。它的核心设计指标不是“能调用多少工具”，而是能否在复杂环境中保持目标对齐、权限收敛、状态一致、证据可追踪和失败可恢复。
3.2 Skill：方法、知识与质量标准的封装层
Skill 的主要作用是缩小开放式推理空间。对同一种任务，Skill 将经过验证的过程、模板和约束抽象为稳定接口，从而让系统更一致、更易测试。Skill 可以引用工具，但不应把长期凭证、环境特有的硬编码参数或无边界的写入权限封装进去。理想的 Skill 是可版本化、可测试、可观测、可审查和可停用的。
3.3 MCP 工具：外部世界的最小化能力接口
MCP 工具层把浏览器、API、数据库、文件系统、搜索、计算和自动化等外部能力转化为带模式的可调用接口。MCP 的关键价值是应用与外部系统之间的标准化连接，而不是替代领域建模或业务授权。[1] 在设计工具时，应让工具名称表达真实意图，参数与返回模式保持窄而清晰，并把高风险动作拆成“预览/校验”和“确认执行”两个操作。
3.4 专家角色：在不确定性与高风险处形成责任闭环
专家角色的价值是把“正确性、合规性和责任”放在一个可执行节点上。对低风险、标准化任务，可使用规则化质量门或专用评估器；对高影响决策、法律/医疗/金融判断、对外承诺和不可逆变更，应引入具备授权的人类专家或审批者。NIST AI RMF 的定位是帮助组织在 AI 产品、服务和系统的设计、开发、使用和评估中纳入可信赖性考虑与风险管理，说明治理不应仅发生在上线前，而应贯穿系统生命周期。[3]
4. 推荐的工程架构
建议将实现划分为控制平面、能力平面、数据平面和治理平面。控制平面负责目标、计划、状态机、调度和停止条件；能力平面承载 Skill 注册表、MCP 客户端/服务器连接和工具目录；数据平面承载上下文、临时工作区、检索索引、工件与执行结果；治理平面则负责身份、权限、策略、审计、评估和人工审批。虽然小型原型可以由单个进程实现，但这一逻辑分层能显著降低权限混乱和状态不可追溯的风险。
| 平面 | 核心组件 | 关键职责 | 必须保留的记录 |
|---|---|---|---|
| 控制平面 | 任务状态机、计划器、调度器、策略引擎 | 分解任务、选择能力、管理并行与停止 | 计划版本、状态迁移、重规划原因 |
| 能力平面 | Skill 注册表、MCP 客户端、工具目录 | 发现、选择、调用和版本管理 | Skill 版本、工具模式、调用策略 |
| 数据平面 | 上下文仓库、工件库、事件流、缓存 | 保存输入、观察、文件和中间结果 | 来源、内容哈希、数据分级、保留期 |
| 治理平面 | 身份、授权、审批、审计、评估 | 限权、确认、风险控制、复盘 | 谁批准、何时执行、作用域、结果摘要 |
4.1 任务状态机
不要只用“正在运行/已完成/失败”三个状态。一个可维护的 Agent 状态机至少可区分：draft、awaiting_clarification、planned、awaiting_approval、running、waiting_for_tool、waiting_for_expert、verifying、completed、failed、cancelled 和 escalated。每次状态变化都应有触发事件和证据，例如工具返回、用户确认、专家裁决、预算耗尽或超时。
状态机带来的好处是：系统可以在长任务中恢复执行；高风险步骤可以暂停而不丢失上下文；用户或审计人员可以理解任务为何没有完成；并行子任务可在统一父任务下被取消、重试或合并。对于有副作用的工具调用，应将“意图生成”“权限确认”“执行请求”“执行结果”拆开记录，避免模型输出与真实世界变更混为一谈。
4.2 上下文、记忆与工件的分层
上下文并非越多越好。建议分为四类：任务上下文保存当前目标、约束和计划；工作记忆保存当前循环所需的短期观察；长期记忆保存经过审查的偏好、规则或知识；工件仓库保存文件、数据集、代码和报告。外部网页、邮件、附件和工具返回都属于不可信输入，不能因为进入上下文就获得指令权。OWASP 将提示注入、工具滥用与权限提升、数据外泄、记忆投毒和目标劫持列为 AI Agent 系统的重要风险，因此记忆写入必须经过来源、可信度和权限检查。[4]
4.3 并行化与汇合
图中写有“按需选择、并行执行、结果回传”，但并行并不总是更快或更安全。只有子任务之间输入独立、不会争用外部资源、输出可独立验证且可在汇合阶段去重时，才应并行。例如，分别检索不同来源、对不同文件执行只读分析、生成多个候选方案可以并行；修改同一资源、依赖前一步输出、需要共享预算或受速率限制的动作则应串行或由调度器加锁。
并行结果汇合时，应记录每个子任务的输入版本、工具版本、完成状态、证据和置信条件。聚合 Agent 不应简单投票，而应基于来源质量、任务覆盖度、冲突检测和验收条件合并结果。若关键结论冲突，应进入专家复核或请求用户裁决，而不是由模型任意选择一个答案。
5. 安全、权限与治理控制
5.1 最小权限与能力分级
授权必须细化到工具和资源范围，而非只按“这个 Agent 能否访问系统”划分。OWASP 建议仅授予 Agent 完成特定任务所需的最小工具集合，使用按工具的权限范围区分只读与写入权限，并为不同信任级别配置不同工具集；对敏感操作则要求显式授权。[4] 因而，一个研究 Agent 不应自动继承文件删除、账号管理或对外发布工具；一个内部支持 Agent 也不应默认访问全量客户数据。
建议采用“默认拒绝、显式允许、作用域短时有效”的权限模型。Token 或授权上下文应绑定任务 ID、工具名、允许的资源路径/账户、操作类型、过期时间和最大调用次数。高影响操作应采用两阶段调用：第一阶段返回影响预览、变更范围与风险摘要；第二阶段仅在用户或专家确认后执行。
5.2 不可信内容与提示注入防护
网页、文档、邮件、工具输出、数据库字段和用户上传文件都可能包含试图改变 Agent 行为的文本。系统必须把这些内容视为数据，而不是新的系统指令。实现上可在工具返回中标注来源与可信等级，将外部内容放入受限上下文区域，并禁止其直接修改权限、策略、长期记忆或任务目标。对于涉及敏感数据和关键工具的任务，应在执行前再次核对“目标—工具—参数—影响范围”是否仍与用户批准的任务契约一致。
5.3 人机协同与专家审批
人工参与并不意味着每次调用都由人工点击确认。更有效的方法是按风险设置检查点：低风险读取自动完成；可逆写入要求任务级确认；高风险或不可逆操作要求操作级确认与专家审批。MCP 工具规范明确建议为用户保留拒绝工具调用的能力，并向用户清晰展示所暴露和被调用的工具，这为透明的人机协同提供了协议层面的设计方向。[2]
专家审批应避免成为没有时限的“人工黑洞”。每个审批请求应包含任务摘要、拟执行动作、影响资源、证据、替代方案、截止时间和默认处理策略。若专家拒绝，应返回可操作原因；若超时，应根据风险等级暂停、降级为只读结果或转交其他授权人，而不是静默继续执行。
5.4 风险管理与持续评估
NIST AI RMF 旨在帮助组织在 AI 系统的设计、开发、使用和评估中纳入可信赖性与风险管理考量。[3] 对 Agent 系统而言，这意味着需要同时评估模型输出风险、工具副作用、数据风险、身份与授权风险、供应链风险和运营风险。上线前测试只能证明有限场景下的行为；运行期仍需要监控异常工具调用、权限拒绝率、重复循环、成本激增、敏感数据暴露信号和质量下降趋势。
6. 可观测性、评估与质量门
Agent 系统的日志不应只保存聊天文本。最小可观测集应覆盖任务、计划、Skill、工具、数据来源、审批和结果六条链路。每条工具调用至少应可关联到具体子目标、输入摘要、授权作用域、开始与结束时间、重试次数、返回状态、影响资源和后续验证结果。这样才能回答“为什么调用此工具”“为何重试”“哪些证据支持最终结论”“谁批准了实际变更”。
| 指标类别 | 建议指标 | 管理价值 |
|---|---|---|
| 任务效率 | 完成率、平均循环次数、等待时间、重规划率 | 识别计划和路由效率问题 |
| 工具可靠性 | 成功率、超时率、参数校验失败率、幂等冲突率 | 识别工具接口和外部依赖问题 |
| 质量 | 验收通过率、人工退回率、事实核验失败率、引用覆盖率 | 判断交付是否可信可用 |
| 安全 | 权限拒绝率、敏感操作确认率、策略拦截率、异常调用模式 | 识别越权和攻击面 |
| 成本与资源 | 模型调用量、工具调用量、检索量、运行时长 | 为预算、配额和停止条件提供依据 |
| 用户体验 | 澄清轮次、状态可见性、交付修改率、满意度 | 判断系统是否真正降低用户负担 |
质量门应具备确定性优先、模型评估补充、专家复核兜底的特点。结构、格式、字段存在性、权限和可重复计算的结果，应尽量用确定性规则检查；开放式写作质量、语义完整性和专业合理性，可用评估模型或专家审查；高影响结论应有独立证据和责任人。这样可以避免用同一模型既生成又自评造成的偏差。
7. 常见部署模式
7.1 单 Agent + 专业 Skill 模式
该模式适用于任务边界清楚、工具数量有限、主要风险可通过策略控制的场景。一个 Agent 负责计划和执行，按任务调用若干 Skill 和 MCP 工具，在交付前经过结构化验证。其优点是实现简单、状态集中、成本可控；局限是单个 Agent 的上下文和职责可能膨胀。适合研究助理、文档生成、报表分析和受限的知识工作自动化。
7.2 协调 Agent + 执行 Agent 模式
协调 Agent 负责拆分目标、分配预算、选择 Skill 和汇合证据；执行 Agent 仅在受限工具集内完成特定子任务。该模式可降低单个执行器拥有过多权限的风险，并提高并行处理能力。实现时必须定义清晰的子任务契约和结果模式，避免多个 Agent 对同一目标重复行动或相互覆盖结论。
7.3 专家闸门模式
在关键节点加入领域、合规或质量专家。适用于对外发布、受监管决策、敏感数据分析、不可逆变更和高价值交易。专家角色可以审查计划、工具调用预览、关键证据或最终结果；但其授权必须明确定义。该模式牺牲部分自动化速度以换取责任清晰和风险可控。
7.4 事件驱动模式
当任务由文件到达、工单创建、监控告警或数据更新触发时，可采用事件驱动的编排方式。事件启动任务状态机，Agent 在每个阶段读取已持久化状态，调用受限工具并发布观察事件。该模式适合长时间运行和可恢复流程，但要避免把事件载荷直接当作可信指令；事件应经过身份验证、模式校验、去重和幂等处理。
8. 失败模式与修复策略
| 失败模式 | 根因 | 可观察信号 | 修复策略 |
|---|---|---|---|
| 目标漂移 | 任务契约不完整，外部内容改变了目标 | 后续工具与初始目标无关 | 锁定目标与约束；对目标变更要求显式确认 |
| 工具幻觉 | Agent 误判工具能力或参数 | 不存在的工具、无效参数、重复失败 | 使用结构化工具目录、模式校验、错误分类和回退路径 |
| 权限过度 | Agent 继承了宽泛身份或工具集 | 低风险任务触发高影响工具 | 最小权限、信任分层、短时作用域与审批闸门 [4] |
| 提示注入 | 外部文本被错误当成指令 | 请求泄露数据、绕过策略或改变任务 | 标注不可信内容、隔离上下文、策略引擎优先于文本指令 [4] |
| 无限循环 | 没有停止条件或失败策略 | 相同调用重复、成本/时长持续增长 | 设置最大迭代、预算、时间、退避和人工升级条件 [6] |
| 虚假完成 | 只依据模型文字而未核验环境 | 宣称文件已生成但不存在、结论无来源 | 引入工具状态验证、工件检查与独立验收 |
| 专家瓶颈 | 审批对象不清、责任和时限缺失 | 长时间等待、意见无法执行 | 结构化审批、SLA、默认暂停策略与升级矩阵 |
| 记忆污染 | 未审查的外部内容写入长期记忆 | 后续任务持续出现错误偏好 | 记忆分级、来源可追踪、人工审核后再写入 [4] |
9. 分阶段实施路线
建议先从一个低风险、高重复、验收标准明确的业务场景开始。第一阶段只配置只读工具和少量 Skill，重点实现任务契约、计划、调用日志、结果验证和停止条件。第二阶段引入 MCP 工具注册表、权限作用域、结构化工件和可恢复状态机。第三阶段再增加专家闸门、并行执行、事件触发和跨系统写入能力。这样可在每一步验证价值与风险，而不是一开始构建一个拥有广泛权限的“万能 Agent”。
| 阶段 | 目标 | 最小能力 | 完成门槛 |
|---|---|---|---|
| 0：边界定义 | 选择安全的业务问题 | 任务契约、风险分级、验收标准 | 明确禁止动作与人工责任人 |
| 1：可验证 MVP | 跑通低风险闭环 | 单 Agent、只读工具、一个或两个 Skill | 输出可复现，验证通过率可量化 |
| 2：平台化能力 | 提升复用与治理 | MCP 接入、Skill 注册表、任务状态机 | 工具权限可审计，失败可恢复 |
| 3：人机协同 | 控制高风险动作 | 专家角色、审批闸门、影响预览 | 高影响操作无审批不执行 |
| 4：规模运营 | 支持多任务和持续优化 | 并行调度、观测指标、评估集、事件驱动 | 成本、质量、安全指标稳定达标 |
10. 结论
配套流程图的核心思想可以总结为：AI Agent 不是孤立的模型，而是一个在明确目标、受限能力、外部观察和责任机制之间运行的协调器。 Skill 让方法可复用，MCP 让外部能力可标准化连接，专家角色让高风险判断有责任归属，执行与反馈闭环让系统根据事实而非猜测调整行动。
成功的 Agent 系统并不追求最大自治，而是追求恰当的自治：在低风险、可验证任务上自动化；在不确定、高影响或不可逆任务上收紧权限、引入专家、保留用户控制权；在每一个阶段留下足以解释和复现结果的证据。只有把规划、工具、观察、验证、权限和治理共同设计，才能将流程图中的“可靠交付”从视觉概念落实为生产级工程能力。
参考资料
[1] Model Context Protocol Specification（2025-06-18），Model Context Protocol 官方规范。
[2] MCP Tools Specification（2025-06-18），Model Context Protocol 官方规范。
[3] AI Risk Management Framework，National Institute of Standards and Technology（NIST）。
[4] OWASP AI Agent Security Cheat Sheet，OWASP Cheat Sheet Series。
[5] ReAct: Synergizing Reasoning and Acting in Language Models，Yao et al.，ICLR 2023。
[6] Building Effective AI Agents，Anthropic Engineering。