第 9 章 Agent 与自动化：决策框架与治理要点
随着大模型能力从“单次对话”演进到“工具调用与多步协作”，许多企业和团队开始尝试搭建 Agent（智能体）或复杂的自动化工作流。
Agent 的能力上限确实很高：它能够理解复杂任务、结合中间结果选择下一步、调用外部工具，并在一定范围内推进任务。但对企业而言，真正的问题不是“能否做出一个 Agent”，而是“在什么情况下提高自主性，才能带来超过额外风险与运营成本的业务价值”。
本章不讲“怎么写一个 Agent 系统的代码”，而是站在决策与治理的角度，回答三个问题：
- 这个业务场景到底需不需要 Agent？
- 如果采用 Agent，它应如何调用经过验证的 Skill，而不是自由发挥？
- 如何用上下文、权限、评测、熔断、人工接管和审计，让它保持安全、可控、长期稳定？
受控 Agent 的最小运行观： LLM 负责在限定状态下推理；上下文包决定它此刻允许依据什么；工具与连接器决定它能查询或执行什么；身份、审批、评测、日志和回退决定它的行为能否被企业接受。Agent 不是“模型加工具”的简单叠加，而是一套可运行、可限制、可恢复的控制系统。
一、先区分自动化、工作流、Skill 与 Agent
讨论 Agent 前，先避免一个常见误区：把“能调用大模型的自动化”都叫作 Agent。不同技术形态的控制方式和风险完全不同。
| 形态 | 下一步由谁决定 | 适合解决的问题 | 企业首选控制 |
|---|---|---|---|
| 传统自动化 | 预先写定的规则或流程 | 数据搬运、固定审批、确定性计算 | 规则测试、权限控制、异常分支 |
| 固定 AI 工作流 | 预先定义的步骤与状态 | 有 AI 参与但顺序明确的多步任务 | 验证节点、状态机、人工审批 |
| Skill | 对一类任务的受控能力封装 | 高频、可验证、可复用的单类任务 | 输入输出契约、Rubric、版本、Owner、回退 |
| Agent | 模型依据状态在受限范围内选择 Skill、上下文或工具 | 步骤不能完全预先固定的动态任务 | 上下文/动作白名单、最小权限、预算/步数限制、人工接管、审计 |
关键原则：Agent 不是更高级的 Prompt，也不应替代稳定的 Skill。 企业级 Agent 应被理解为一个受控编排层：它只可以在预先允许的状态、Skill、上下文来源和工具之间选择；它不能自行扩张目标、读取未批准资料、获得新权限、绕开审批或把未经验证的内容直接写入真实世界。
推荐的建设顺序是：先稳定 Prompt，再封装 Skill；先连接固定工作流，再评估是否需要 Agent。 如果固定规则、确定性自动化或人工决策足以完成任务，就不应为了“更智能”而增加自主性。
二、自主性的代价：为什么 Agent 更容易失控
在传统软件工程中，流程通常由确定规则控制。在单任务 AI 工作流中，虽然输出有波动性，但由于步骤单一，可以通过结构化 Prompt 和单步验证进行拦截。
在 Agent 场景中，系统被允许根据中间结果选择后续动作。自主性带来能力，也带来三类根本挑战。
1. 多步骤稳定性会快速衰减
如果一个流程包含多个必须成功的步骤，并且将每一步视为近似独立，其端到端成功率可粗略理解为各步骤成功率的乘积：
整体成功率 ≈ P₁ × P₂ × P₃ × … × Pₙ
（数学表达式：\( P_{\text{total}} \approx \prod_{i=1}^{n} P_i \)）例如，五步流程中每一步都达到 90% 的成功率，端到端成功率约为 59%。这个公式不是对所有真实流程的精确预测——步骤之间往往存在相关性，检查与回退也会改变结果——但它清楚说明了一个事实：单步看起来不错，并不意味着多步自主系统可以直接投入生产。
因此，企业应同时记录每个关键 Skill 的通过率、Agent 的端到端任务成功率、人工接管率与错误动作率，而不能只展示某一个步骤的平均效果。
2. 错误会沿链路传播并被放大
在单步工作流中，如果输出错误，流程通常会立即中断或由人工修正。但在 Agent 循环中，早期错误可能成为后续决策的输入。例如，Agent 错认客户身份后继续检索、计算、拟稿或调用工具，后续动作会在错误上下文上继续“合理化”。
控制方法不是相信 Agent 会自我纠正，而是缩小它可造成影响的范围。 这包括把高风险判断拆回人工、把写操作放在审批之后、把工具调用限制为白名单、把关键事实交给独立验证 Skill 或确定性规则检查。
3. 自主系统存在额外的运行风险
除内容质量外，Agent 还可能发生工具参数错误、权限越界、重复调用、循环、外部数据误导、成本失控、状态丢失或人工接管失败。它的评测必须覆盖这些运行风险，而不是只检查“最后生成的文字好不好”。
三、Agent 适用条件决策树
在决定为某个场景开发 Agent 之前，必须通过以下决策树进行评估。不要因为技术时髦而选择复杂方案。
开始评估：该不该用 Agent？
│
├── 1. 能否用确定性规则、传统自动化或固定工作流完成？
│ ├── 能 ──> 优先不用 Agent；选择复杂度更低、可控性更高的方案
│ └── 不能，下一步确实依赖中间结果动态选择 ──> 进入下一步
│
├── 2. 任务是否已被拆成可验证的 Skill？
│ ├── 否 ──> 暂缓；先定义输入输出、质量标准、回退和责任人
│ └── 是 ──> 进入下一步
│
├── 3. 能否定义最小上下文包、来源白名单、权限和记忆边界？
│ ├── 否 ──> 暂缓；先完成第 5 章的上下文资产与数据边界设计
│ └── 是 ──> 进入下一步
│
├── 4. 是否涉及不可逆、高影响或需人类最终判断的动作？
│ ├── 是 ──> 可做辅助或受限编排，但必须保留人工审批；不得全自主执行
│ └── 否 ──> 进入下一步
│
├── 5. 团队能否建设并长期维护上下文、权限、评测、监控、熔断、审计与人工接管？
│ ├── 否 ──> 暂缓；使用固定工作流或人机协作
│ └── 是 ──> 进入下一步
│
└── 6. 动态编排的收益是否明显大于额外复杂度、成本与风险？
├── 否 ──> 使用固定工作流
└── 是 ──> 可以从受限 Agent 试运行开始以下场景不应采用全自主 Agent：资金划拨、定价或折扣最终决定、对外正式承诺、医疗或法律结论、直接修改核心数据库、涉及敏感个人信息的外发、重大人事决策，以及其他错误后果不可逆或难以补救的场景。是否允许辅助使用，应由业务、风险、安全和法务按组织实际边界确认。
在评估任何 Agent 前，应先完成附录 A 第 34 节的用例级风险初筛；多数跨系统、可调用工具或具有较高自主性的 Agent 至少应按 R2 受控用例处理，并在试运行、阶段提升或重大变更前完成附录 A 第 35 节的 AI 影响评估。Agent 的自主等级不能高于其风险控制、审批、回退和证据治理能够支持的水平。
四、自主性的五个分级策略
不要把“全自动”当成唯一目标。根据场景风险、Skill 成熟度和治理能力，选择最合适的自主性级别。
| 级别 | 自主性程度 | 人机协作模式 | 典型形态 | 上线前提 |
|---|---|---|---|---|
| L1：单步辅助 | 无自主性 | 人类手动发起并决定是否采用 | 单个 Prompt 或 Skill 输出草稿、提取结果 | 输出可验证；使用者完成基础培训 |
| L2：受控流水线 | 极低自主性 | 步骤固定，关键节点有人审核 | 固定顺序调用多个 Skill | 每个关键 Skill 有验证与回退；流程状态明确 |
| L3：建议式编排 | 中等自主性 | Agent 可提出计划、检索和建议，但关键动作须批准 | 调研、异常调查、复杂信息归纳 | 允许动作白名单、计划可见、每次工具调用可审查 |
| L4：授权后执行 | 较高自主性 | Agent 可在限定范围内执行低影响动作；写入、发送或关键决定前仍需确认 | 低风险内部工单处理、草稿准备、监控分流 | 端到端评测、权限隔离、预算/步数熔断、人工接管已验证 |
| L5：无人值守运行 | 完全自主 | 无人工逐次干预，仅例外处理 | 低风险内部监控、非生产数据维护、可逆的批处理 | 仅限低影响、可逆、可快速停止场景；持续监控与定期复审 |
企业落地铁律： 初始上线通常从 L1 或 L2 开始；只有当底层 Skill 稳定、端到端评测达标、没有未解决的高严重度事件，并且人工接管和回退经过真实演练后，才可申请提高自主性。对外部客户、财务、核心数据或敏感决策场景，禁止使用 L5；L3 或 L4 也应保留与风险相称的人工审批。
五、Agent 运行合约：让“能做什么、不能做什么”可执行
每个进入试运行的 Agent 都应有一份独立的运行合约（Agent Runtime Contract）。它不是技术设计文档的替代品，而是业务、技术与治理人员共同确认的最小控制面。
| 合约要素 | 必须写清楚的内容 | 目的 |
|---|---|---|
| 业务目标与边界 | 要完成什么；不承担什么决策；不可接受的结果 | 防止目标扩张和误用 |
| 自主等级 | L1–L5；哪些动作必须人工批准 | 将口头承诺变成系统限制 |
| 可调用 Skill | Skill 名称、版本、输入输出契约、适用状态 | Agent 只能编排已验证能力 |
| 上下文包与来源 | 任务上下文、权威知识、检索来源、排除来源、优先级、预算、版本与失效条件 | 限制错误、过期、无关或越权信息进入推理 |
| 可调用工具与连接器 | 工具/MCP/连接器白名单、允许参数、读写权限、数据范围、返回量、超时 | 限制破坏面、越权和工具结果污染 |
| 持久记忆 | 可读/可写记忆类别、事实与假设标记、保留期、租户隔离、删除与失效 | 避免错误记忆、跨用户混用和无控制累积 |
| 状态与路径 | 合法状态、允许转移、终止状态、重试条件 | 防止自由循环与状态迷失 |
| 预算与熔断 | 最大步骤数、最大工具调用数、最大时间、最大成本、并发上限 | 控制循环、资源和账单风险 |
| 验证与审批 | 哪些事实要独立检查；哪些动作必须批准 | 防止错误进入下游或真实世界 |
| 人工接管与回退 | 触发条件、接管人、降级方式、恢复所需证据 | 确保出错时业务仍可继续 |
| 责任与审计 | 业务 Owner、技术 Owner、知识 Owner、日志保留与复盘责任 | 保证有人对质量、运行和知识负责 |
1. 最小权限：先只读，后写入；先窄范围，后扩大
不要给 Agent 无限制的工具访问权限。优先级应是：只读查询优先于写入操作；沙箱优先于生产环境；限定资源范围优先于全库访问；短期凭证优先于长期高权限密钥。
即使必须允许写入，也应尽可能采用“生成建议 → 人工确认 → 受控执行”的两阶段设计，并限制可写入的字段、对象和数量。Agent 能够调用某个工具，不等于它可以执行该工具的所有动作。
2. 上下文与连接器：信息面同样需要最小权限
Agent 能够看到什么，与它能够执行什么同样重要。上下文包应设定允许来源、排除来源、选择逻辑、返回量、版本和失效条件；工具、MCP 或其他连接器也应以独立清单记录其数据流、身份、读写范围、返回字段、超时、审计和退出方式。工具描述、参数和返回内容本身会进入模型上下文，因此职责重叠、字段模糊或默认返回过量的工具，会降低行为可预测性并增加成本与错误风险。1
对于长时任务，压缩摘要、工作笔记或持久记忆必须区分“已确认事实”“待核验假设”和“待办”，并能够定位原始来源、按权限隔离、失效和删除。不得把完整会话、全量工具输出或未经确认的推断直接写入长期记忆。
3. 人工看守：看守关键动作，而非机械点击
人工确认不应只是形式上的“一键通过”。系统应向审核者展示：Agent 的目标、所依据的上下文来源与版本、已调用的 Skill 与工具、工具结果摘要、拟执行动作、风险提示和可修改选项。审核者需要有足够信息做判断，也必须能够拒绝、修改、转人工或终止。
4. 状态机与动作白名单：限制轨道，而非要求模型更聪明
不要让 Agent 完全自由地决定下一步做什么。使用状态机或等价的受控流程，预先定义合法状态、状态转换和终止条件。模型只负责在当前状态下选择允许的下一步，而不能自行发明新步骤、接入新工具或扩大权限。
例如，一个异常工单调查 Agent 可以只在“读取工单—调用分类 Skill—检索知识—形成建议—请求审批—结束”之间跳转。遇到信息缺失、工具超时、置信不足或异常输入时，应进入“转人工”或“终止”状态，而不是无限重试。
六、Agent 评测：不仅测答案，还要测行为与恢复
进入试运行前，Agent 需要至少覆盖五类评测。样本数量和阈值应随风险等级、错误成本和业务场景调整，不应用单一数字替代判断。
| 评测层 | 要测试什么 | 代表性样本 |
|---|---|---|
| 上下文层 | 是否选择正确、有效、可定位且在权限内的来源；是否处理冲突、过期和信息不足 | 正常、冲突、过期、无来源、跨用户或超范围资料 |
| Skill 层 | 每个被调用 Skill 的输入输出、事实、格式、边界 | 正常任务、缺字段、知识冲突、过期信息 |
| 任务层 | Agent 能否完成端到端目标且不遗漏关键步骤 | 真实历史任务、长链路任务、边界案例 |
| 安全与权限层 | 是否尝试越权、误用工具、处理不当输入或工具结果 | 非法写入请求、提示注入、敏感数据、恶意或超长工具返回 |
| 运行与恢复层 | 是否循环、超预算、超时；人工接管是否可用 | 空结果、工具故障、重复任务、成本阈值触发、审批拒绝 |
上线前应至少形成一份包含正常、边界、失败和异常输入的评测集；每次修改 Skill、模型、工具、权限、知识或状态逻辑后，都应在受影响样本上重新评测。对高影响场景，评测结果必须由业务 Owner 与相应的风险/安全责任人共同审阅。
必看运行指标
- 端到端任务成功率：任务真正完成且满足质量标准的比例。
- 人工接管率与接管成功率：系统把问题交回人类的频率，以及接管后能否顺利完成。
- 错误动作率：发生了不应发生的工具调用、写入尝试、错误路由或越权尝试的比例。
- 平均步骤数、工具调用数、上下文量与单位任务成本：识别循环、冗余、无效加载和成本飙升。
- 来源可定位率与过期/冲突上下文拦截情况：检查系统是否能说明依据，并在不应继续时停止。
- 工具错误率与无效返回率：识别参数、工具描述、返回结构或权限设计问题。
- 熔断触发率与恢复时间：判断控制是否在需要时生效。
一次通过率仍然重要，但不能单独代表 Agent 的可靠性。
七、Agent 的上线治理检查表
在允许一个 Agent 进入试运行前，必须通过以下检查。
- [ ] 业务价值明确：动态编排相对于固定工作流有可验证的额外价值，而不是为了追赶技术潮流。
- [ ] 风险与影响已评估：已完成用例级风险初筛；R2/R3 或发生重大变化的用例已完成 AI 影响评估，任何例外均有范围、补偿控制和到期日。
- [ ] Skill 已就绪：每个关键任务均已封装为有输入输出、验证、回退、Owner 和版本的 Skill。
- [ ] 角色与责任人明确：指定业务 Owner、技术 Owner、知识 Owner；明确谁有暂停、恢复和变更权限。
- [ ] 自主等级受限：定义 L1–L5 级别，并在系统上实现相应限制，而不只是写在文档里。
- [ ] 上下文最小必要且可追溯：上下文包、来源白名单、排除来源、版本、范围、权限、预算和失效条件均已验证。
- [ ] 工具、连接器与数据最小权限：工具/MCP 白名单、参数范围、返回量、数据范围、读写权限、凭证有效期和退出方式均已验证。
- [ ] 记忆与状态受控：可读/可写记忆、事实/假设标记、保留期、隔离、删除和合法状态路径均已定义。
- [ ] 状态、预算与熔断已配置：最大步骤数、调用数、时间、成本、并发和合法状态路径均有硬限制。
- [ ] 人工确认节点可用：关键决策、对外发送、写入或高影响操作前，审核者可以看懂、修改、拒绝和转人工。
- [ ] 评测集与回归机制就绪：已覆盖正常、边界、异常和滥用情形；变更后会重新评测。
- [ ] 人工接管与回退经过演练：API 超时、格式错误、权限拒绝、熔断、审批拒绝等情形下，业务可以平滑降级。
- [ ] 审计日志可追溯：记录任务目标、状态转移、Skill/工具版本、输入输出摘要、审批、异常、熔断和最终结果；日志留存方式符合组织政策。
八、如何用一个受控示例开始
如果团队尚未运行过 Agent，不要从“自动处理客户请求”或“直接修改系统”开始。建议先使用附录 A 第 14 节的“异常工单调查助手”作为演练参考：它处于 L3 建议式编排，只读取已授权的内部工单、日志和 Runbook，最终只输出带来源标识的调查建议，由人工决定是否采取行动。
这个示例刻意保留了四个边界：第一，Agent 只编排已定义的 Skill，不直接把一条超级 Prompt 接到工具上；第二，它只读取已批准的工单、日志和 Runbook 片段，并保留来源标识，不加载整库资料或未批准历史；第三，它没有任何写入、发送、代码执行或外网访问权限；第四，空结果、工具超时、权限拒绝、敏感信息、上下文冲突或置信不足都会让它停止并转人工。读者应先按自己的组织数据边界替换上下文包、工具与责任人，再用已关闭的历史工单测试，而不是直接连接生产环境。
评测时，除最终摘要质量外，还应使用附录 B 第六节记录人工接管、熔断、错误动作和运行证据完整性。若系统在异常时能够及时、可解释地停止并把工作交回人工，即使它没有“自动解决问题”，也已证明了最关键的控制机制。
九、本章行动清单
本周立即执行：
- [ ] 盘点团队正在开发或计划开发的 Agent 与复杂自动化项目。
- [ ] 用本章决策树逐一重评，识别可以降级为固定工作流、单个 Skill 或传统自动化的项目。
- [ ] 为所有在研 Agent 指定自主等级，并列出其实际可调用的 Skill、上下文来源、工具/连接器、记忆和写入权限。
下个月内建立：
- [ ] 为每个试运行 Agent 建立运行合约、上下文包、记忆/工具控制记录、风险初筛/影响评估、评测集、预算/熔断与人工接管 Runbook。
- [ ] 把已经稳定的高频任务整理成 Skill 卡，而不是继续堆叠在一个超级提示词中。
- [ ] 做一次异常演练：模拟空结果、工具超时、审批拒绝或预算触发，确认系统会停止、通知并安全回退。
本章小结
Agent 不是魔法，而是一个在受控上下文、外部工具与状态之间进行有限编排的概率系统。它的价值来自动态任务处理能力，它的风险也来自同一份自主性。
企业应该坚持“能用确定性流程就不用 Agent；能用固定工作流就不增加动态决策；没有稳定 Skill 就不让 Agent 编排；没有最小必要上下文、身份权限、评测、熔断、接管和审计，就不上生产”的原则。
把上下文、工具和动作的控制权设计进系统，而不是寄希望于模型临场表现，才是让 Agent 长期可靠的前提。