第0章　执行摘要¶

Release Candidate 1

适合谁读：企业决策者、产品负责人、架构师、技术负责人。
阅读时间：5分钟掌握结论；30分钟完成采用判断。
证据说明：本章给出全书的决策框架。工程公式与架构建议是综合抽象；实验性结论会明确标注适用范围，不把单次模型结果外推为普遍规律。

本章回答的三个问题¶

AI Agent 与聊天机器人、Copilot、工作流和 RPA 有什么区别？
哪些任务值得引入 Agent，哪些任务应保持确定性？
企业应如何从一个可演示原型，走到可评估、可治理、可恢复的生产系统？

5分钟速读：十条蓝皮书结论¶

Agent 的本质不是聊天，而是闭环执行。 模型根据当前信息选择行动，工具作用于环境，环境结果再成为下一步决策依据。
Agent 边界内可以概括为 LLM + 上下文 + 工具。 LLM 提供语义决策，上下文决定当前可见信息，工具定义可感知和可执行的能力；文件、网页、用户和业务系统属于外部环境。
并非所有 LLM 应用都需要 Agent。 步骤已知、规则稳定、结果可由确定性程序产生时，优先使用普通代码、结构化模型调用或工作流。
选择满足成功条件的最低自主性。 推荐升级顺序是：确定性代码 → 单次结构化调用 → RAG → 固定或条件工作流 → 有界工具 Agent → 多 Agent。
上下文质量通常比上下文长度更重要。 模型只能依据当前可见信息决策；无关、冲突、受污染或失去来源的信息会降低可靠性。
工具决定 Agent 的实际影响面。 Prompt 可以影响行为，却不能授予权限；授权、参数校验、幂等、审批和审计必须由代码执行。
“模型说完成了”不是完成证据。 应由测试、数据库状态、外部回执、用户确认或其他独立验证器判断任务是否真正结束。
没有评估，就无法可靠判断改动是否有效。 需要同时评估最终结果、执行轨迹、系统可靠性、成本与延迟，以及安全行为。
多 Agent 不是默认升级方向。 它只有在引入新信息、扩大并行覆盖、隔离上下文、区分身份权限或形成真实异步委派时才值得增加复杂度。
企业长期资产不是某个 Prompt，而是 Harness、评估集和运行轨迹。 模型会变化，能够约束、验证、恢复并持续改进模型行为的工程系统更持久。

蓝皮书结论
Agent 的价值来自“面对变化仍能推进任务”，风险也来自同一处。真正的生产工程，不是尽可能扩大模型自由度，而是把自主决策限制在可观察、可验证、可终止和可恢复的边界内。

一、什么是 AI Agent¶

1.1 一个边界清楚的定义¶

本书把 AI Agent 定义为：

能够依据当前上下文选择行动，通过工具获得环境反馈，并在预算与终止条件内持续推进目标的系统。

这个定义包含四个必要要素：

目标：系统知道要推进什么，而不只是生成一段文字；
选择：下一步不是完全写死，模型需要在候选行动中作语义判断；
行动与观察：系统能够读取或改变环境，并看到行动结果；
循环边界：系统有成功、阻塞、失败、取消或预算耗尽等终态。

因此，一次“输入文本—返回文本”的模型调用通常不是 Agent；一个按固定步骤执行、只有局部模型节点的流程，更准确地称为 AI 工作流。这不是高低之分，而是不同的控制结构。

1.2 三种互补视角¶

直觉视角	工程组件	系统职责
大脑	LLM / Model	理解目标、判断、规划、选择下一步
眼睛	Context	提供策略、任务、状态、证据、历史和工具定义
手脚	Tools	搜索、读取、计算、写入、通信或控制外部系统

对应到控制与强化学习语言，模型近似策略，当前上下文承载观察与历史，工具提供观察和行动接口。但它们不是严格一一等同：上下文不等于完整观察空间，工具背后的真实状态也不属于 Agent。

1.3 Agent 与环境的闭环¶

用户目标
   ↓
Harness 构造当前上下文
   ↓
Model 选择回答或工具调用
   ↓
Harness 校验权限、参数和预算
   ↓
Tool 作用于 Environment
   ↓
Environment 返回真实观察
   ↓
Harness 更新状态并决定继续、审批、恢复或终止

这里有一条关键边界：

Agent 内部：Model 与 Harness；
Agent 外部：文件、网页、数据库、用户、其他 Agent、设备以及物理或仿真世界；
Harness：把模型能力转化为受控执行的运行与治理层。

Harness 至少负责上下文构造、工具暴露、状态维护、权限、预算、验证和纠正。一个演示系统可能只有简单循环；生产系统则必须补上这些控制。

二、Agent 不等于所有智能软件¶

2.1 五种常见形态¶

形态	控制方式	适合任务	主要风险
Chatbot	一问一答	咨询、解释、内容生成	幻觉、缺少最新事实
Copilot	人掌握流程，模型辅助局部工作	写作、编程、分析	人过度信任建议
AI Workflow	程序定义步骤和分支	审核、抽取、报表、稳定业务流程	流程覆盖不足
RPA	预定义界面操作	稳定、重复、规则明确的界面任务	页面变化导致脆弱
Agent	模型根据反馈选择下一步	开放检索、复杂办事、动态工具任务	越权、循环、成本和不可预测副作用

同一产品可以同时包含多种形态。例如客服系统可用确定性路由识别业务类型，用 RAG 回答政策问题，用工作流完成身份核验，只在处理未知异常时启用有界 Agent。

2.2 先问“为什么不是更简单的方案”¶

在采用 Agent 前，按以下顺序判断：

确定性代码能否可靠解决？ 能计算、校验或查库的事实，不交给模型猜。
一次结构化模型调用是否足够？ 分类、抽取、改写等有界转换通常不需要循环。
问题只是缺少知识吗？ 如果是，先增加检索，而不是增加自主性。
步骤是否稳定？ 稳定步骤用工作流；模型可用于某些语义节点。
下一步是否必须根据环境结果动态决定？ 只有此时才进入工具 Agent。
一个上下文真的装不下，或任务需要独立并行与权限吗？ 只有此时再考虑多 Agent。

架构决策
自主性不是产品成熟度等级。一个严格工作流可能比自主 Agent 更适合高风险业务，也可能具有更高的生产价值。

三、哪些任务适合 Agent¶

3.1 四个正向信号¶

Agent 更适合同时具备以下特征的任务：

步骤无法完全预先确定：需要搜索、诊断、试错或动态改道；
环境反馈有信息增量：搜索结果、测试失败、页面变化或对方回复会改变下一步；
成功可以独立验证：存在测试、状态查询、业务结果或人工验收；
任务影响可被控制：工具权限、预算、审批和回滚能够把失败限制在可接受范围内。

典型例子包括：

在多个来源间迭代检索并形成带引用报告；
搜索代码、修改文件、运行测试并根据失败修复；
调用多个业务系统处理异常工单；
在 API 缺失时，通过受限 Computer Use 完成界面任务；
长时间等待邮件、Webhook 或人工审批后继续执行。

3.2 五个停止信号¶

出现以下情况时，不应直接采用自主 Agent：

结果无法验证，只能依赖模型自称正确；
操作不可逆且没有预览、审批或补偿机制；
模型没有工具或环境反馈，只是在循环生成文本；
步骤固定，却为了“更智能”而让模型重新规划；
质量收益没有覆盖增加的延迟、成本和运维复杂度。

四、从 Demo 到生产，真正变化了什么¶

4.1 Demo 的最小循环¶

演示系统通常只需要：

请求 → 模型 → 工具 → 模型 → 回答

这个循环可以证明模型会调用工具，却不能证明系统能够安全、稳定地处理真实业务。进入生产环境后，需要增加六类能力。

4.2 生产控制面的六个部分¶

状态与持久性¶

每次运行需要唯一 ID、类型化状态和明确终态。长任务必须能够 Checkpoint、重启恢复和取消，不能只保存在某个进程内存中。

权限与副作用¶

模型只能提出动作，不能决定自己是否有权执行。读工具和写工具应分离；支付、删除、发送、部署等动作需要更窄参数、幂等键、预览和人工批准。

预算与终止¶

系统应限制：

模型调用次数；
工具调用次数；
Token 与金额；
墙钟时间；
并发和委派深度。

预算由代码强制，而不是只在 Prompt 中提醒模型“不要浪费”。

验证与完成判定¶

完成状态应来自环境事实，例如：

测试全部通过；
目标数据库记录存在；
外部服务返回成功回执；
页面出现预期状态；
用户批准准确的动作载荷。

可观测性与评估¶

一次任务形成一个 Trace，模型调用、检索、工具和审批形成 Span。评估既看最终结果，也看是否选对工具、参数是否正确、是否出现无效循环，以及成本和风险。

恢复与发布¶

模型、Prompt、工具和政策都要有版本。新版本先离线回放，再进入影子流量、金丝雀和有限放量；达到回滚阈值时恢复旧版本。

五、企业 Agent 成熟度模型¶

等级	能力	关键门禁
L0 辅助生成	单次模型调用	输入输出校验、数据保护
L1 受控工作流	固定链路和结构化中间结果	节点测试、失败分支、版本管理
L2 有界 Agent	动态工具选择和环境反馈	工具权限、预算、终止、轨迹
L3 生产 Agent	持久状态、审批、恢复和在线观测	SLO、幂等、审计、灰度和回滚
L4 持续优化	从失败轨迹更新知识、规则或模型	私有评估集、变更验证、污染防护
L5 多 Agent 协作	独立上下文、权限或并行工作	准入证明、通信契约、成本和冲突治理

成熟度不是要求每个系统最终到达 L5。多数业务应停在能够满足成功条件的最低一级。

六、评估价值：不要优化每次调用成本¶

6.1 核心指标是“每个成功任务的成本”¶

只看 Token 价格可能产生错误决策：便宜模型如果需要更多重试、人工修复或工具调用，最终更贵；昂贵模型如果减少失败和人工接管，可能有更好的业务经济性。

建议同时追踪：

维度	代表指标
结果	任务成功率、业务完成率、正确性
轨迹	工具选择、参数正确率、循环和恢复
性能	p50/p95 延迟、排队时间、吞吐量
成本	每次运行成本、每个成功任务成本
可靠性	超时、重试、恢复、重复副作用
安全	越权请求、审批拦截、数据泄露和注入
用户	满意度、重复提问、人工接管和投诉

6.2 四级质量门¶

Schema / Unit Test
        ↓
Smoke Test
        ↓
Offline Evaluation
        ↓
Online Evaluation

Schema/Unit Test：验证工具、权限和确定性逻辑；
Smoke Test：确认部署可达且最小路径可工作；
Offline Eval：用固定数据比较模型、Prompt、工具和架构；
Online Eval：监控真实流量中的质量、漂移、成本和未知失败。

Smoke Test 不是完整质量证明，LLM Judge 也不应成为事实、权限或高风险动作的唯一裁判。

七、安全：模型不能扩大自己的权限¶

7.1 统一威胁模型¶

Agent 需要防范的不只是有害文本，还包括：

用户或外部内容改变系统目标；
检索知识库被污染；
工具访问关键系统或敏感数据；
循环调用造成资源和费用过载；
一个工具错误级联到其他系统；
多 Agent 之间传播未验证信息；
日志记录存在但可被篡改或无法归因。

7.2 一条安全动作链¶

高影响动作应遵循：

模型提出候选动作
→ Schema 与业务规则校验
→ 身份与权限检查
→ 生成可读预览
→ 人工批准准确载荷
→ 使用幂等键执行
→ 验证真实环境结果
→ 记录审计证据

密码学回执可以证明某个密钥签署了特定内容、内容未被修改，并通过哈希链证明顺序。但它不能证明动作本身正确、政策确实执行或输入真实。回执是审计层，不是治理系统的替代品。

八、多 Agent：先通过准入测试¶

只有满足至少一个强理由时才增加多个 Agent：

独立并行研究能明显降低延迟或扩大搜索覆盖；
子问题超出一个上下文，隔离可以减少污染；
不同身份或权限必须强制分离；
专家需要独立拥有后续对话；
大型 Artifact 需要明确所有权和异步委派。

反之，角色名称不同、提示词风格不同，或者“让多个模型讨论一下”并不足以证明需要多 Agent。审核者若没有测试结果、页面截图、外部事实或其他新证据，很可能只是重复提议者已有的信息。

九、90/180/365天采用路线图¶

前90天：证明价值，不建设平台¶

选择一个结果可验证、影响可控的任务；
建立10–30条真实评估任务；
从最低自主性架构开始；
实现一条端到端路径和一个失败恢复路径；
记录模型、工具、成本和最终结果；
不建设通用多 Agent 平台。

90–180天：补齐生产控制面¶

引入持久状态、幂等、预算、取消和审批；
建立 Trace/Span 与离线回放；
将生产失败加入评估集；
定义 SLO、发布和回滚阈值；
对模型和工具进行权限分层。

180–365天：规模化复用和持续优化¶

抽取经过验证的共用 Harness 能力；
建立模型路由和成本治理；
从轨迹更新知识、Skill、程序或模型；
只有在单 Agent 评估表明瓶颈确实来自上下文、并行或权限时，再引入多 Agent；
建立跨团队安全、数据和评估责任机制。

十、管理层决策清单¶

在批准 Agent 项目前，至少回答：

业务¶

[ ] 成功能否用业务结果定义，而不是“回答看起来不错”？
[ ] 与普通代码或工作流相比，Agent 的增量价值是什么？
[ ] 失败的经济、法律和用户影响是什么？

架构¶

[ ] 为什么需要动态行动选择？
[ ] 哪些事实、权限和状态必须由确定性系统掌握？
[ ] 是否存在明确预算和终止条件？

安全¶

[ ] 模型是否能直接执行高影响动作？
[ ] 人工批准是否绑定到准确动作，而不是模糊意图？
[ ] 工具是否最小权限、幂等和可审计？

评估¶

[ ] 是否有真实任务构成的离线集？
[ ] 是否分别衡量结果、轨迹、成本、延迟和安全？
[ ] 是否定义灰度和回滚阈值？

运营¶

[ ] 长任务能否在进程重启后继续？
[ ] 是否能取消运行并避免孤儿任务？
[ ] 是否能追溯模型、Prompt、工具和政策版本？

如果这些问题中的多数尚无答案，项目仍处于探索阶段，不应以“生产级 Agent”对外承诺。

本章证据与来源说明¶

本章综合自：

主仓库引言、第1章、第7章、第9章和第10章；
实验1-1的上下文消融及其修订后的证据边界；
补充仓库关于 Agent 入门、可信 Agent、生产观测、部署与密码学回执的课程；
ReAct、OpenTelemetry、RFC 8785 和 RFC 8032 等论文、项目与标准来源。

本章没有使用未复现的历史百分比来证明普遍规律。详细主张裁决见：

bluebook/data/sample-chapter-evidence.yml

知识检查¶

为什么固定工作流不比 Agent “低级”？
Agent 内部三要素与外部 Environment 的边界是什么？
为什么 Prompt 不能代替授权？
Smoke Test、Offline Eval 和 Online Eval 分别解决什么问题？
多 Agent 的准入理由中，哪些属于真正的信息或控制增量？

第0章 执行摘要¶