ai agent book - (下册)

内容摘抄自github:ai-agent-book , 仅作为学习使用🌈

---

---

Agent 的评估

构建 Agent 系统时，开发者面对大量设计选择，而它们往往没有显而易见的正确答案：

• 用什么模型？
• 让模型能调用哪些工具？
• 知识库该存什么数据、以什么结构来构建？
• 用户记忆该怎么做？
• 模型的提示词和 Skills 该如何组织？
• Harness 中需要加上哪些约束？
• 如何把评估结果转化为 Agent 持续进化的学习信号？

评估为我们提供了科学的决策依据：通过系统性的对比实验（改变一个变量，观察效果变化）和消融实验（逐一关闭某个组件，观察整体性能变化，从而判断该组件的真实贡献），区分真正的能力提升与表面的波动，避免 “捡了芝麻，丢了西瓜”。正如软件工程中 “没有度量就没有改进” 的说法，不建立可重复的评估体系，Agent 的迭代方向就只能靠直觉。

从第一章引入的 Harness 工程视角看，评估在 Harness 中扮演着 “验证” 功能的核心角色。一个关键认识是：评估的对象不应只是模型，而应是模型与 Harness 的组合体。同一个模型在不同的 Harness 中可能表现差异悬殊——一些团队仅通过优化 Harness 就显著提升了同一模型在终端类任务上的表现（详见第五章）。这意味着，当 Agent 在评估中表现不佳时，改进方向可能不是换模型，而是优化 Harness 的某个组件（提示词、工具设计、反馈循环）。完善的评估体系应能区分 “模型能力不足” 和 “Harness 设计缺陷” 这两类本质不同的问题。

区分这两类问题的常见手段是模型替换实验（model swap）——固定 Harness，只更换更强/更弱的模型，观察分数变化幅度；如果换强模型分数不涨，说明瓶颈在 Harness；如果换弱模型分数大跌、分数随模型能力大幅波动，最直接的解读就是瓶颈在模型能力本身、当前表现主要由模型决定（至于这是因为任务本身就难、还是 Harness 过度依赖模型先验，则需进一步分析）。注意这与前面提到的 “消融实验” 是两种不同的方法：消融是关闭 Harness 的某个组件看整体性能如何变化，模型替换则是固定 Harness、只换模型——前者定位 Harness 内部哪个部件重要，后者区分瓶颈在模型还是在 Harness。

评估体系的价值在模型快速演进的时代更加凸显。模型能力仍在快速演进，但新模型在公开基准上表现更好，并不意味着在你的特定任务上也更好，反而可能出现性能退化（regression，即新版本在某些方面不如旧版本）。只有在自己的评估数据集上完整测试，才能做出数据驱动的升级决策。更进一步，完善的评估体系使得 “为未来的模型开发产品” 成为可行策略——即使当前模型不足以支撑商用，也可以先完成产品开发并建立评估集，持续追踪新模型的表现，一旦达到门槛就立即上线。

本章导读

本章从三个层次构建完整的评估体系。第一层是评估设计：为了避免先讨论工具和数据、最后才定义“成功”，正文先建立评估指标体系（“什么算成功”），特别区分技术奇观阶段的能力上限与业务场景要求的连续可靠性；随后展开评估环境与数据集（“在哪里测、测什么”）。第二层是评估方法（“怎么判”）：介绍 LLM-as-a-Judge、配对比较与模型排名。第三层是评估驱动的决策（“测了干什么”）：将结果转化为模型选型、架构优化和持续迭代的行动指南，并借助统计显著性判断观察到的分数差异是否真实可信。此外，本章还会讨论可观测性与生产级 Agent 的内部评估基础设施，并在章末介绍连接第七章后训练的仿真环境。

贯穿全章的核心理念是：评估体系的首要价值不是给当前系统打分，而是让你能快速、可靠地跟上模型的演进。当一个更强或更便宜的模型发布时，拥有完善评估体系的团队能在数小时内得出切换决策，而缺乏评估体系的团队只能凭直觉或等待社区反馈。在竞争激烈的 Agent 市场中，这种速度差距可能决定成败。

一个具体的评估示例

在深入方法论之前，先通过一个完整的例子建立直觉。假设我们构建了一个客服 Agent，需要评估它处理退款请求的能力。

测试用例：用户要求退掉 3 天前的订单（订单号 #12345，金额 ¥299）。公司政策：7 天内可全额退款。

Agent 的轨迹：

用户：我想退掉 3 天前买的那个耳机，订单号 12345。（今天是 2026-04-10）

Agent（思考）：用户要退款，需要先查询订单信息。
Agent → 调用工具 query_order(order_id="12345")
工具返回：{status: "delivered", amount: 299, date: "2026-04-07", item: "蓝牙耳机"}

Agent（思考）：下单日 2026-04-07，距今天 2026-04-10 为 3 天，在 7 天退款期内，符合全额退款条件。
Agent → 调用工具 process_refund(order_id="12345", amount=299)
工具返回：{refund_id: "R-98765", status: "processing", eta: "3-5个工作日"}

Agent：已为您发起退款，订单 #12345（蓝牙耳机，¥299）的全额退款正在处理中，
      预计 3-5 个工作日到账。退款编号 R-98765，可用来查询进度。

用 Rubric 评分（四个维度，每维度 1-4 分）。表6-1 给出了这个客服退款任务的评分示例，用来说明 Rubric 如何把一次 Agent 轨迹拆成可检查的评价维度。

表6-1 客服退款任务的 Rubric 评分示例

维度	标准	得分	理由
操作正确性	退款金额、订单号是否正确	4	正确查询并发起 ¥299 全额退款
政策合规性	是否遵循 7 天退款政策	4	订单在退款期内，符合政策
信息完整性	是否告知金额、到账时间、退款编号	4	三项关键信息均已告知
幻觉检测（一票否决项）	是否编造不存在的信息	通过	所有信息均来自工具返回结果

幻觉之所以列为一票否决项（veto）而非分级评分维度，是因为它与质量是正交的。一个流畅、详尽、礼貌的回答如果包含虚假事实，对用户的伤害远大于一个简短但准确的回答。

这个用例通过了。但好的评估不仅测成功场景，更要测边界和陷阱——用户要退 15 天前的订单（超出退款期）时，Agent 能否正确拒绝？用户声称 “客服已经批准了退款” 时，Agent 是否会在没有系统记录的情况下轻信？这些边界场景才是区分 Agent 能力高低的关键。

上面这个流程——定义测试用例、运行 Agent、用 Rubric 评分、分析结果——就是评估的基本骨架。本章接下来会逐步展开每个环节的设计方法。

评估指标体系

在搭建环境、编写数据集之前，先要明确“成功”究竟意味着什么：是只要找到一条可行路径，还是要求每一次运行都不出错？指标口径不同，评估结论和工程决策可能完全相反。本节先建立这套口径，再在后文说明如何实现环境、数据集和评分器。

技术奇观：用 Pass@k 看能力上限

当前许多模型和 Agent 仍处在一个可以称为 “技术奇观” 的阶段。这里的 “奇观” 是指展示在大量尝试、充足时间和人工筛选下能够达到的最高上限：只要其中一次成功，就足以证明 “这件事原则上做得到”。这正是 Pass@k 的逻辑——在同一任务上运行 $k$ 次，只要至少有一次通过，任务就算通过；如果输出是连续得分，则取最好的一次，记为 Best@k。

Anthropic 对长时运行 Agent 的讨论体现了这类能力的上限。例如，让 Agent 自主工作一周，从头写出一个 C 编译器；或者持续探索，直到找到一个重要数学猜想的反例；又或者反复审查开源软件，发现已经存在几十年的重大安全漏洞。

对这类工程与科研探索，展示的通常不是“每次都做对”，而是把探索预算拉长后终于出现一条突破性轨迹。对于科研发现、漏洞挖掘、开放式创作等任务，这种能力上限本身就很有价值：人类可以从 $k$ 条候选轨迹中挑出那一条最好的。

除了基座模型，很多应用公司也在使用 “技术奇观” 策略。Manus 之所以引发广泛关注，是因为它提供了一个虚拟电脑，让此前对 Agent 没有直观概念的人发现 AI 可以像人一样操作电脑，持续工作半小时甚至一小时，逐步完成复杂的任务。

OpenClaw 则让很多人第一次感受到 Agent 的 “活人感”。它更像真实的人一样，可以通过即时通讯软件给它安排任务，访问电脑上的所有文件和在线服务；工作到一定阶段会主动反馈，或者向用户索取新的信息；甚至能够主动唤醒自己去查询和处理邮件。

早期的 Manus 和 OpenClaw 在完成复杂任务时的成功率并不高，token 成本也非常高。但由于这些 Agent 框架的通用性，在使用最强模型的时候，复杂任务往往有较高的 Pass@k，体现较高的技术上限。这些 “技术奇观” 在社交网络上被大量分享，是这些 Agent 产品成功的关键。

业务可靠性：关注 Pass^k

真实业务通常更关心另一件事：在多次尝试中一次错都不能犯。我们把这个目标称为 Pass^k（可以读作 Pass consecutive k）：同一任务连续运行 $k$ 次，要求每一次都通过，且不能触发安全、合规或幻觉等一票否决项。它回答的是“Agent 能否稳定可靠地交付”，而不是 “能否偶尔创造奇迹”。

若每次运行相互独立、单次成功率为 $p$，两类指标的关系很直观：

$$ \mathrm{Pass@k}=1-(1-p)^k,\qquad \mathrm{Pass}^{k}=p^k. $$

例如单次成功率 $p=0.6$ 时，$k=5$：Pass@5 $=1-0.4^5\approx99.0%$，看起来几乎总能 “至少成功一次”；但 Pass consecutive@5 $=0.6^5\approx7.8%$，说明连续五次都不出错仍然很难。前一个数字适合衡量探索时的能力天花板，后一个数字才接近支付、退款、权限变更、生产部署等场景的可靠性要求。

评估报告必须写清 $k$ 次尝试的口径：是同一任务的 $k$ 次独立采样，还是生产流水线上连续 $k$ 个任务。对于会产生副作用的操作，不能简单地 “重试直到成功”，而应在沙盒或可回滚环境中采样，并把每一次失败都记入可靠性指标。

过程指标：从黑盒到白盒

仅关注最终结果是不够的，Agent 达到结果的过程同样重要。行动合法率测量操作中有效且合法的比例——无效操作包括调用不存在的工具、传递错误的参数类型；越权操作指超出权限范围的行为。高合法率说明 Agent 对工具生态有清晰的理解。工具调用正确率进一步要求参数在语义上合理：搜索工具的查询词应准确表达需求，文件操作的路径应指向正确目标。

路径效率衡量完成任务的经济性：步数（思考-行动-观察循环次数）、冗余动作（重复搜索相同关键词、反复读取同一文件）、回退次数（意识到错误并纠正的频率——偶尔回退很正常，但频繁回退说明前瞻规划不足）。需要建立人类专家或启发式算法的基线来定义“合理步数”。

检索覆盖率针对信息收集类任务：Agent 是否充分探索了信息空间？是否只看了搜索结果第一页就草率下结论？成本与延迟关注请求次数、Token 花费（需区分输入/输出成本，考虑 KV Cache 复用）、墙钟时间（包括模型推理 + 工具执行 + 网络延迟），需要追踪时间分布来定位瓶颈。

安全、鲁棒性与轨迹覆盖

安全与合规指标在生产部署中至关重要：触发敏感操作（删除数据 / 修改权限 / 发送对外通信）、数据外泄（日志中打印密码 / 私密文档发送到外部 API）、违规内容，都应遵循零容忍原则——与幻觉一票否决项同理（见后文 “Rubric 四准则”），一次严重安全违规即否决整体评价，不因其他维度表现优秀而豁免。

鲁棒性衡量面对不确定性时的稳定性：随机种子敏感性（不同初始化下表现差异有多大）、页面变化适应性（网站 UI 更新不应导致完全失效）、API 抖动容忍度（能否优雅处理临时故障、超时、格式变化）、长时记忆干扰（上下文中积累的过时信息是否会导致错误决策）。

执行轨迹与最终结果的双重覆盖。评测中容易忽视的一个区分是：Agent 在执行过程中“说了什么、做了什么”（即第一章定义的轨迹，trajectory）和“系统最终变成了什么样”（最终结果，outcome）是两件事。Agent 说“订票已完成”是轨迹层面的信息，数据库里确实生成了一条订单才是结果层面的验证。只看轨迹会漏掉“说了但没做到”的情况，只看结果又可能看不出中间步骤走歪了。Anthropic 曾举过一个例子：一个机票预订 Agent 在执行中发现了航空公司政策里的漏洞，为用户找到了更便宜的方案——如果只按预设执行路径打分，这次运行会被判为失败；但从最终结果看，用户拿到了更好的方案。因此两类评测都应覆盖，以避免系统性盲区。

人工抽检和对抗式评审

即使自动评估在大多数情况下是可靠的，也需要定期人工抽检：覆盖不同任务类型、成功/失败案例和边界分数附近的模糊案例，不仅验证结果，还要审查评分理由的合理性。人工抽检可以进一步系统化为评判者校准：在放量使用 LLM 评判之前，先构建一个人工标注的金标集（如 100-200 个覆盖各任务类型和难度的案例），在其上测量评判模型（即用 LLM 充当评委，其机制详见下节 LLM-as-a-Judge）与人类标注的一致率（简单一致率或 Cohen's kappa 等一致性系数，后者剔除了随机猜中的成分），达到预设门槛（如 kappa 高于 0.7）后才将评判模型用于大规模评估；此后每当评判模型或 Rubric 更新，都应在金标集上重新校准。没有这一步，LLM 评判的分数只是“另一个模型的意见”，而非人类判断的可靠代理。对抗式评审通过红队（Red Teaming）主动构造挑战性案例：表面完美但含隐蔽错误的回答、通过关键词堆砌蒙混过关的回答、利用评判模型已知偏见获取不应得高分的回答。多评委机制使用多个独立评判者分别评分，通过加权平均或一致性检查确定最终结果——当评判者之间严重分歧时，标记为需进一步人工审查。

自动评估环境

Agent 评估需要一个可重复运行的自动化环境——能在开发阶段快速测试变更的效果。搭建这样的环境要回答三个问题：评什么（任务定义和验证标准）、对谁评（如何模拟 Agent 的交互对象）、用什么标准打分。

评估环境的基本组成

评估环境包含五个要素——后续章节将重点展开其中的数据集设计和评分标准设计：

**数据集（Dataset）**定义任务集合，包含初始状态、目标描述和可选的参考解决方案。

**环境状态（Environment State）**维护任务执行中的可变信息，需在真实性和可控性之间取得平衡。例如，在客服评估中，环境状态包括数据库中的订单记录和用户账户余额。Agent 调用 process_refund 后，订单状态从 "delivered" 变为 "refunded"、余额增加——这些就是“可变信息”。“真实性”要求状态变化符合业务逻辑（退款不超过订单金额），“可控性”要求每次测试可重置到相同初始状态。

**工具接口（Tools）**定义 Agent 可执行的操作集合——工具不应提供过高层的抽象（如“解决用户问题”），而应提供原子操作（如查询订单、修改预订、发送邮件），迫使 Agent 通过规划和思考来组合这些操作。

**评分标准（Rubric，评分准则）**量化 Agent 的表现，可以是二元的（通过/不通过）、连续的（0 到 100 分）或多维的（分别给准确性、效率、安全性打分）。

**执行协议（Interaction Protocol）**规定交互模式和终止条件。

根据 Agent 任务的不同，评估环境可以粗略划分为工具调用型和人机交互型。

工具调用型评估环境

对于代码生成、数据分析等主要依赖工具使用的任务，Verifiers 框架展示了典型的设计模式。Agent 通过调用预定义工具完成任务，验证基于可执行标准（测试是否通过、答案是否匹配），不依赖人类标注或模型评判。

Verifiers 引入了层次化的环境设计：SingleTurnEnv 适用于单轮任务（如简单问答），ToolEnv 支持多轮工具调用的自主循环，StatefulToolEnv 和 SandboxEnv 支持有状态工具和长期运行的沙盒环境（如代码执行）。例如，SingleTurnEnv 适用于问一道数学题后直接验证答案；ToolEnv 适用于搜索多个网页后综合回答再验证最终结果；StatefulToolEnv 适用于修改数据库记录后验证数据库状态变化；SandboxEnv 适用于在沙盒中运行代码后检查输出文件。表6-2 汇总了这些环境类型，便于读者按任务状态、工具调用和隔离需求选择合适的评估环境。

表6-2 Verifiers 环境类型对比

环境类型	状态保持	工具调用	典型用例
SingleTurnEnv	无	无	单轮问答、数学题
ToolEnv	无	多轮	搜索+信息综合
StatefulToolEnv	有	多轮	修改数据库记录
SandboxEnv	有+隔离	多轮	代码执行与测试

框架支持并行采样和轨迹缓存，每次评估的完整轨迹（观察、行动、奖励）都会被保存，方便后续分析和回放。

环境还需处理操作的状态依赖性——工具的执行效果取决于当前状态，失败时应提供清晰的错误信息而非简单的失败标志，让 Agent 能从错误中学习并调整策略。

人机交互型评估环境

许多真实任务不仅涉及工具调用，还需要与人类用户对话。客服 Agent 需要理解模糊表达、澄清需求、查询后台系统、向用户确认信息。这类任务的评估面临一个根本性挑战：如何在自动化环境中模拟真实用户？

关键设计原则是渐进式信息透露（Progressive Information Disclosure），这是人机交互型评估与传统基准测试（benchmark）的根本区别。大多数 benchmark 一开始就把完整需求全盘托出，但现实中用户很少能一上来就清晰描述需求——他们往往只会说“我的航班好像有问题”、“网络连不上了”。Agent 需要通过主动提问来澄清需求，这个过程本身就是能力的重要体现。因此在评估中，绝不能一开始就把模拟用户的所有信息暴露给 Agent，信息应按需、渐进地在对话中透露。

τ-bench 的解决方案是用户模拟（User Simulation）：用另一个 LLM 扮演用户角色，根据预定义的指令与 Agent 对话。模拟用户接收任务指令（如 “我需要取消明天的航班”），在对话中逐步向 Agent 透露必要信息、回应询问，任务完成后发出终止信号。提示词要求模拟用户 “不要一次性透露所有信息，只提供当前步骤必要的内容”、“不要编造指令中未提供的信息”。用户模拟的设计需要在真实性和可控性之间权衡：行为应接近真实用户（表达模糊、信息不完整、偶尔情绪波动、耐心有限），同时遵循一定的剧本以确保可复现。

以下是一个渐进式信息透露的多轮对话示例（用户模拟器按固定脚本行动）：

模拟用户：“我的航班有个问题。” Agent：“请问是哪个航班？” 模拟用户：“Delta 123，明天早上从旧金山飞纽约。” Agent：“具体是什么问题？” 模拟用户：“飞行时间太长了，我想改签。” Agent：“对新航班有什么偏好吗？” 模拟用户：“下午的航班都行。”

用户模拟器遵循一个固定的脚本（已知信息 + 透露规则），确保评估可复现，同时模拟真实用户的渐进式表达方式。模拟用户往往还会设置有限的耐心，如果 Agent 沟通效率低下，模拟用户就可以终止对话，任务失败。

τ-bench 是评测 Agent 在结构化业务流程（如航空客服、零售客服）中表现的基准测试。它的检查是组件级、多维度的：一方面检查数据库最终状态是否正确（如预订记录状态变为 “已取消”），另一方面验证 Agent 在对话中是否输出了必要的关键信息（如退款金额和到账时间，通过搜索特定字符串或模式来验证）。这种双重验证同时考察操作准确性和沟通有效性。但在任务层面，这些检查最终汇总为零或一的二元奖励——所有检查全部通过才得 1 分，任何一项不通过就是 0 分。二元奖励便于统计 Pass^k 等可靠性指标（见前文 “评估指标体系”），代价是 “操作准确但漏掉某个非关键字段” 与 “完全失败” 得到相同的分数。

改进版 τ²-bench 的核心增量不在评分粒度，而在两点：一是双控环境（Dual-Control）——不再只有 Agent 一方能调用工具，用户模拟器也能操作同一个共享环境（如 Agent 指导用户切换飞行模式，用户的操作真正改变环境状态），这更贴近技术支持等需要用户动手配合的真实场景；二是更精确的任务规范与组合式任务生成——成功条件的歧义更少、具体任务实例可以参数化批量生成（详细验证维度见后文 “可验证性与客观性保障” 一节）。

实验 6-1 ★：运行 τ²-bench 并对比 τ-bench 的演进

本实验通过运行 τ²-bench 评估框架，理解人机交互型评估环境的设计要点，并通过对比 τ-bench 与 τ²-bench 的差异，体会评估数据集是如何迭代改进的。

深入阅读任务定义文件：每个任务包含已知信息（用户的背景知识）、任务指令（指导如何渐进式透露信息和响应策略）以及成功条件（数据库目标状态和对话中必须出现的确认信息）。运行完整评估流程，观察用户模拟器与 Agent 的多轮对话，分析典型的失败模式（政策违规、信息遗漏、过度转接人工等）。

对比 τ-bench 与 τ²-bench 的设计差异：τ-bench 初始版本的用户指令过于简单（Agent 能猜对答案）、成功条件不够精确（导致误判）、用户模拟器过于机械。τ²-bench 针对这些问题做了系统性改进：

• 引入更详细的任务指令：包括“事实锚定要求”（Grounding），即必须基于环境真实状态回答
• 更精确的评估标准：如“速度测试返回 excellent 才算解决”
• 更真实的用户模拟器行为规范：渐进式信息透露、自然的情绪波动

特别关注 τ²-bench 新增的 telecom 领域任务，理解其双控环境设计（如前文所述，用户与 Agent 共同操作同一共享环境）。

与工具调用型评估侧重 “是否完成了可观测的状态变更” 不同，人机交互型评估关注 “是否引导用户完成了认知或决策上的变化”——前者考察 Agent 的行动正确性，后者考察其沟通策略的合理性。

评估环境的构建还涉及仿真环境的设计——当评估环境需要支持大规模重复交互时就演化为仿真环境，本章末尾将简要讨论。

评估任务数据集的设计

评估环境是“舞台”，数据集是“剧本”——剧本设计的好坏，往往比舞台本身更能决定评估的价值。一个设计糟糕的数据集，即使跑在完美的环境里，得到的也只是噪声。本节从 GAIA、AndroidWorld、SWE-Bench Verified（Software Engineering Benchmark，软件工程基准测试）、τ-bench 与 τ²-bench、Terminal-Bench、OSWorld 与 OSWorld-Verified 等基准的设计实践中，提炼出几条反复被验证的原则。

实验 6-2 ★：人肉执行基准测试任务

从 GAIA、AndroidWorld、SWE-Bench Verified、τ²-bench、Terminal-Bench、OSWorld-Verified 中各挑选任务亲手完成。建议每个数据集完成简单、中等、困难各一个——“困难”级别对人类也有挑战。将执行结果与标准答案对比，分析差异来源。通过亲身体验理解：任务描述需要在明确性与开放性之间平衡，验证标准必须客观可执行，任务难度的层次化要能区分不同能力水平。

任务数据集设计的核心挑战

挑战一：明确性与开放性的张力。 任务描述必须足够明确以确保评估可复现，又不能过于死板限制 Agent 的创造性。GAIA 提供了一个范例：任务 “概念简单” 但实现路径开放——例如要求找到 NASA 每日天文图片中的宇航员信息，目标明确（找到特定宇航员及其太空时间），但如何搜索、筛选、验证完全由 Agent 自主决策。

挑战二：真实性与可控性的平衡。 真实任务包含不确定性和噪声，能让鲁棒性得以显现，但也威胁可复现性。SWE-Bench 初始版本直接取自 GitHub 真实 issue，确保了真实性，但也导致任务描述模糊、测试用例不完整、评估标准主观。SWE-Bench Verified 引入人类专家进行系统性验证，从中筛选出问题清晰、测试充分、方案明确的 500 个高质量任务，在保持真实性的同时显著提升了可控性。

挑战三：多样性与系统性的协调。 有效的数据集需覆盖典型情况、边界条件和错误陷阱，同时要有系统性的组织方式，使评估结果能诊断出具体的能力短板。AndroidWorld 的 116 个任务横跨 20 个真实应用，每个任务标注了所需的核心能力（多步规划、视觉理解、时间推理），使评估结果不仅能给出整体成功率，还能揭示特定能力维度的强弱。更关键的是，通过参数化机制可以生成几乎无限的任务变体。

挑战四：评估成本与覆盖范围。 复杂 Agent 任务可能需要数分钟甚至数小时才能完成，使用前沿模型完整跑完一个评估数据集往往需要数千美元的 token 成本。数据集的规模需要在全面性与经济性之间平衡。GAIA 精选 466 题、分三级难度，既覆盖多种能力维度又能在合理成本下完成评估。SWE-Bench Verified 通过更严格的质量标准提升了信噪比，从 2294 题筛选至 500 题，成本降低约 80%。

挑战五：数据泄漏（Data Contamination）防范。 数据泄漏是评估面临的严峻挑战：当评估数据被纳入训练数据时，评估测的就是记忆力而非泛化能力，好比考试前把答案背下来了，成绩再好也说明不了真实水平。各个基准采用了不同的防范策略：GAIA 依靠答案的独特性，问题需要组合多个信息源才能回答，且部分任务配有专门创建的附件文件（互联网上不存在的 PDF/音频/图片），单一网页无法直接提供答案。SWE-Bench Verified 本身不含时间维度的防泄漏设计；真正靠时间新鲜度防泄漏的是 SWE-bench-Live 等后续工作，它们持续收录模型训练截止日期之后新创建的 issue，使评估始终领先于模型的训练语料。τ²-bench 通过动态参数生成做防范，具体任务实例（用户姓名、订单号、日期等）每次随机生成。AndroidWorld 的参数化任务生成天然具有抗泄漏能力，因为验证基于最终 UI 状态而非操作序列。Terminal-Bench 通过嵌入金丝雀标识符（canary GUID）使泄漏可检测：如果模型能输出含该 GUID 的内容，说明基准数据已泄漏到训练集中。

任务描述的精确性设计

GAIA 通过明确的信息源约束、时间范围、主题和查询目标来确保答案的唯一性。例如 Level 3 任务要求从特定日期的 NASA 图片出发，经视觉理解识别宇航员、查询所属宇航员组、计算太空停留时间并精确格式化输出（“姓氏，分号分隔，千位分隔符”），每个细节都服务于自动验证——只有格式和内容完全匹配才算通过。

τ²-bench 引入了情境化设计，每个任务包含多层信息：表面问题（“移动数据无法工作”）、性能期望（“绝对想要出色速度”）、约束条件（“不接受其他速度”）以及隐含情绪。关键改进是将“已知信息”与“任务指令”分离：已知信息是用户当前掌握的事实，任务指令指导模拟器如何渐进式透露信息，其中包含“事实锚定要求”（Grounding Requirement，即必须根据工具调用的实际返回结果回答，不能编造）。

SWE-Bench Verified 包含问题描述、复现步骤、预期/实际行为等结构化字段，标注者会验证描述与测试用例的匹配性。Terminal-Bench 的任务描述中每个元素都可以机械化验证：文件路径是否存在、权限数值是否正确、证书参数、日期格式等。例如 “build-linux-kernel-qemu” 要求从源码构建 Linux 内核 6.9、在 start_kernel 中添加自定义 printk、生成 initramfs 并在 QEMU 中运行，成功标准是启动日志中出现自定义消息——Agent 无法通过伪造输出蒙混过关，必须真正完成整个流程。

AndroidWorld 采用参数化模板设计。一个任务不是静态文本，而是可动态实例化的模板（如“将联系人 [CONTACT_NAME] 的电话改为 [NEW_PHONE]”），每次评估时随机生成不同的参数值。好处有三个：

• 防止记忆：参数值每次不同，无法回放固定的操作序列
• 增加数据多样性：一个模板可以生成几乎无限的实例
• 支持对比实验：固定某些参数只变化其他参数，精确测量特定因素的影响

验证基于最终 UI 状态（如电话号码字段是否包含预期值）而非操作序列。

OSWorld 的任务往往不从 “干净的” 初始状态开始，而是从精心配置的中间状态启动，更贴近真实使用场景。任务描述需要处理多解性（“将背景设为紫色” 需提供具体颜色代码消除歧义，“拼接两个 CSV” 需接受保留单表头/双表头等所有合理方式）和环境不确定性（网站反爬、应用 UI 演变、时序竞争等，OSWorld-Verified 通过离线页面快照、锁定依赖版本、显式等待条件等机制加以缓解）。

上述 Agent 评估数据集并未穷尽 Agent 评估的版图。仅 Web/GUI 类就有多个各有侧重的基准：WebArena 自建了一套可完全复现的网站（电商、论坛、代码托管等），把 “真实网页” 的不可控性关进沙盒；Mind2Web 反其道而行，直接在上百个真实网站上测泛化能力；ClawBench 则让隔离容器中的 Agent 在真实网站上执行端到端日常任务，V1 覆盖 144 个网站的 153 项任务、V2 再增加 130 项，并同步记录会话回放、动作截图、HTTP 流量、浏览器动作和 Agent 消息五层证据。它补充了沙盒化基准，便于分析真实站点漂移和长尾失败，代价是复现性会受第三方网站变化影响；BrowseComp 则专攻深度检索——答案藏得很深、需要多跳浏览与交叉验证才能找到。

任务复杂度的层次化设计

GAIA 设计了三级难度：Level 1 只需 1-2 个工具（人类 93.9% vs GPT-4 30.3%），Level 2 需要多步思考（91.8% vs 9.7%），Level 3 需要复杂组合（87.3% vs 0%）。层次化设计的诊断价值在于：Level 1 失败指向基础工具使用问题，Level 2 指向多步规划和信息整合，Level 3 指向长序列思考和复杂性管理——每个层次对应不同的改进方向（提示工程 vs 规划机制 vs 分层架构/后训练）。

τ²-bench 通过业务复杂度分层：从简单的信息查询，到多步流程（修改航班需要查询、展示替代、确认、计算差价、支付），再到故障诊断（系统性检查多个可能原因并验证修复），最后到策略判断（处理不符合政策的请求）。

Terminal-Bench 通过技术领域×操作复杂度双维度分层，已收录 200 余个任务，从简单的 mlflow 模型注册，到中等的 7z 密码破解，到困难的 git 服务器+webserver 多组件集成，到最困难的 FEAL 差分密码分析（需密码学知识+算法优化满足 30 秒时间约束）。

可验证性与客观性保障

GAIA 的答案简洁明确，严格的格式规定使验证可以通过精确的字符串匹配来完成，二元结果（匹配或不匹配）确保客观可复现。答案的稀有性也起到了防作弊作用——高度具体的事实不太可能以原样出现在训练数据中。

SWE-Bench Verified 基于代码的可执行性做验证，区分 FAIL_TO_PASS（修复前失败、修复后通过，证明问题被解决了）和 PASS_TO_PASS（修复前后都通过，证明没有引入新的 bug），实现双重验证。Verified 版本还确保测试本身质量可靠、没有时而通过时而失败的不稳定测试（flaky tests）。

τ²-bench 的验证体系包含多层检查（各层检查结果在任务层面仍汇总为二元奖励，全部通过才算成功）：

• 数据库状态检查：预订记录状态、退款记录是否创建
• 对话内容关键词搜索：是否向用户确认退款金额和到账时间
• 流程合规性：工具调用序列分析，如修改订单前是否获得用户的明确确认

τ²-bench 的双控环境（见前文 “人机交互型评估环境”）在验证层面还多出一维：用户模拟器实际改变环境状态后，Agent 必须通过工具调用观察到这一变化并据此继续排查，验证因此覆盖了 “Agent 是否真的读到了用户侧的操作结果”。

OSWorld 配备了 134 个独立评估函数，拥有完整的 OS 访问权限，能深入检查文件系统结构、进程状态、网络连接、应用内部状态。例如在数据库操作任务中，评估脚本不仅验证报告文件是否存在，还会直接连接数据库检查 SQL 是否正确执行；在浏览器任务中会分析 DOM 树、检查 cookie/localStorage、向后端发送验证请求确认表单是否真正生效。这种深度检查能发现“表面完成但实质错误”的情况——比如 Agent 点击了提交按钮，但因为字段填写错误而被服务端拒绝。

Terminal-Bench 基于 Docker 容器标准化环境，结合文件系统状态检查（路径是否存在、权限数值、内容格式）和程序执行功能验证（build-linux-kernel-qemu 中实际启动 QEMU 并搜索自定义 printk 消息），canary GUID 使泄漏可追踪。

任务分布的系统性设计

任务分布需要系统性地覆盖能力维度、难度维度、场景维度和边界情况。GAIA 追求通用性——大多数任务需要推理、多模态、浏览、工具使用的组合。τ²-bench 专门设计了 “陷阱任务”——比如用户声称 “客服已批准取消” 但实际并不符合政策，用以测试 Agent 在面对压力和误导时能否保持正确判断。OSWorld 基于操作类型（文件 IO / 桌面应用 / 网页应用 / 跨应用流程）与应用领域的双维度矩阵，跨三个操作系统（研究表明跨 OS 能力强相关，在一个系统上学到的能力可以迁移到其他系统）。Terminal-Bench 包含 “跨技术栈组合任务” 以测试系统思维（如融合数据处理 + 文件操作 + Python 工程的重分片任务）。

数据质量控制与迭代改进

SWE-Bench Verified 是质量控制的典范。OpenAI 从原始 2294 个任务中随机抽取 1699 个进行人工评估，招募了 93 名精通 Python 的开发者。标注者需完成多项检查：问题描述是否清晰（能否理解要解决什么）、测试用例是否完整（覆盖所有方面和边界条件）、测试是否稳定（有没有因环境或随机性导致的 flaky test）、patch 是否正确（是否引入了新错误）、难度是否合理。经过严格筛选，最终仅 500 个通过（29%）——这种高淘汰率是对评估质量的必要投资。他们还建立了标准化的标注指南，为每项检查定义具体标准和示例，确保不同标注者之间的一致性。

τ²-bench 相比初版 τ-bench，引入了“已知信息”/“任务指令”分离（使模拟器行为更真实）和更严格的完成条件（如“只有 excellent 才算解决，poor/fair/good 都不接受”），防止“敷衍性修复”。

OSWorld-Verified 是迭代改进的典范。OSWorld 在 2024 年 4 月发布后迅速成为多模态 Agent 评估的重要基准，但在 15 个月的广泛使用中暴露出超过 300 个问题。这些问题分为四类：环境问题（网站反爬 / CAPTCHA / 动态内容变化）、任务描述问题（歧义表述）、验证逻辑问题（过严或过松）、初始状态问题（配置不完整）。香港大学团队组建了约 10 人小组，与 MoonShot AI、OpenAI、ByteDance Seed TARS、Anthropic、Simular 等深度合作两个月进行系统性修复。针对每类问题制定了修复策略：环境问题通过锁定版本和离线备份解决，任务描述通过重写歧义表述消除，验证逻辑通过人工建立正确基线和调整条件来平衡，初始状态通过增加完整性校验来增强。

评估基础设施也从本地 VM 迁移到 AWS 云平台，利用弹性伸缩实现了 50 倍并行加速（从 10 多小时缩短到几分钟），Google Drive 任务初始化成功率从 50% 提升到 95% 以上。所有官方评估轨迹数据公开在 HuggingFace 上，使社区能审查每个细节、复现结果、发现问题，形成持续改进的良性循环。

值得一提的是，评估环境与后训练环境往往同源：一套设计良好的评估环境，稍加改造就能变成训练环境——SWE-Gym 就是基于 SWE-bench 构建训练任务的代表，τ²-bench、AndroidWorld 的参数化模板则能批量生成海量训练实例。但要划清一条红线：可以复用的是环境的构造机制，评估集本身的那些具体题目必须与训练数据严格隔离。

自动化评估方法

有了评估环境、数据集和明确的指标体系，接下来的核心问题是：怎么打分？对于有明确正确答案的任务（如数学题、SQL 查询），简单的二元判定（对/错）已经足够；但对于开放式任务（如客服对话、报告撰写），需要更精细的评估方法。

代码自动验证只覆盖有标准答案的场景，开放式任务的评分才是本节的主题。其中，奖励信号的密度设计（从二元奖励到过程奖励再到生成式奖励）以及奖励模型的训练方法留待第七章后训练部分系统讨论；本节则回答一个更基础的问题：如何用 LLM 自动化地评判开放式任务的输出质量。

LLM-as-a-Judge：自动化评估的核心

为什么需要 LLM-as-a-Judge？对于开放式任务（如生成报告、处理客户投诉、创意内容），没有标准答案可以自动对比，人工评估成本高且难以规模化。LLM-as-a-Judge 通过让语言模型根据专家定义的评分标准（Rubric）进行评判，在自动化规模和人类专业判断之间取得了平衡。但这种方法也有已知的局限：评判模型可能有自己的偏见（最典型的是长度偏差——倾向于给更长、更详尽的回复打高分，哪怕内容并不更正确），相同输入多次评判也可能有波动。长度偏差尤其值得单独防范，常用手段有三：在 Rubric 里显式惩罚冗长、对同类任务规定回答的长度上限；做配对比较时先把两个候选的长度控制到相近再评；以及定期审计评分与回答长度的相关性——如果高分几乎总是伴随长回答，就说明评判已被长度带偏，需要回炉修订 Rubric。为了系统性地应对这些挑战，Rubric 设计必须遵循以下准则：

Rubric（评分标准）：LLM 评判的依据。

Rubric 四准则（Scale AI，“Rubrics as Rewards”）：

（1）基于专家指导——必须反映领域知识，捕捉核心事实和推理步骤。比如医疗问答的 Rubric 需包含诊断标准和必须避免的医学错误，缺乏专业基础的 Rubric 只能捕捉语言流畅度等表面特征。

（2）全面覆盖——涵盖事实准确性、逻辑连贯性、完整性、安全性，而且不仅定义正面标准，还要明确陷阱（Pitfall）——即高风险的常见错误，如医疗建议中推荐未经验证的疗法。

（3）标准重要性权重——分为必要项（Essential）、重要项、可选项、陷阱项。支持一票否决机制（Veto）：比如在客服场景中，幻觉（编造虚假信息）是典型的否决维度——无论其他维度表现多优秀，只要出现虚假信息就必须否决。这也有助于防范关键词堆砌式的奖励作弊。

（4）自包含评估——每个评价项独立可操作，不依赖评价者的领域知识。要避免“回应展示了深刻理解”这种抽象标准，改为“引用了至少两个权威理论并准确解释如何支持结论”这种可验证的标准。

关键实践：为每个维度定义客观可验证的评分档次，提供具体示例和边界案例帮助区分模糊情况。要主动防范奖励作弊（Reward Hacking）——即 Agent 找到了获取高分的“捷径”却没有真正完成任务——明确惩罚幻觉、讨好用户、关键词堆砌、回避棘手问题。Rubric 是迭代产物——通过试用收集评价者分歧、逐步完善，逐渐从抽象准则演化为详尽的判例集。

以用户记忆 Agent 为例，展示一个符合四准则的完整 Rubric。测试问题：“我女儿的儿科医生是谁？”（答案需要跨两次对话关联：第一次对话提到“女儿叫 Lily”，第二次提到“带 Lily 去看了 Dr. Chen”）。

rubric:
  dimensions:
    - name: 事实正确性
      weight: essential        # 必要项
      scoring:
        4_优秀: "准确回答 Dr. Chen，且关联到女儿 Lily"
        3_良好: "准确回答 Dr. Chen，但未提及是 Lily 的医生"
        2_及格: "给出了正确医生但附带不确定的额外信息"
        1_不及格: "给出错误医生名，或回答不知道"

    - name: 信息完整性
      weight: important        # 重要项
      scoring:
        4_优秀: "主动补充相关信息（如上次就诊时间、诊断结果）"
        3_良好: "回答了核心问题，无遗漏"
        2_及格: "回答了核心问题，但遗漏了可用的关联信息"
        1_不及格: "关键信息缺失"

    - name: 思考正确性
      weight: important
      scoring:
        4_优秀: "正确关联'女儿=Lily'和'Lily的医生=Dr. Chen'两条跨会话信息"
        3_良好: "关联正确但思考路径不够清晰"
        2_及格: "部分关联正确"
        1_不及格: "错误关联（如把用户自己的医生当成女儿的医生）"

    - name: 幻觉检测
      weight: veto             # 一票否决项：一旦触发，总分归零
      scoring:
        pass: "所有信息均可溯源到历史对话记录"
        fail: "编造了对话中不存在的信息（如虚构就诊日期、诊断结果）"

  edge_cases:
    - "如果用户有多个女儿且分别看不同的医生，应追问是哪个女儿"
    - "如果记忆中同时存在'Dr. Chen'和'陈医生'，应识别为同一人"

好的 Rubric vs 坏的 Rubric：上面每个评分档都给出了可验证的具体行为（“准确回答 Dr. Chen”），而非“展示了对记忆的深刻理解”这类无法客观判定的描述。一票否决项明确了底线：即使其他维度全部满分，一旦出现幻觉就直接判零。

将这个 Rubric 和 Agent 的实际回答一起交给评判模型，模型会逐项打分并说明理由。把几十个用例的结果汇总起来，再回看其中的低分轨迹，原本笼统的“成功率下降”就能拆成几类具体问题：是没检索到信息，还是把人物关系想错了，抑或补充了没有依据的内容。这样一来，Rubric 不只告诉我们“得了多少分”，还会告诉我们下一步该改哪里。

失败归因：从整条轨迹定位首个错误

端到端评估通常只给出“成功”或“失败”，却没有回答“为什么失败、从哪一步开始失败”。要让评估结果真正驱动修复，必须把每条失败轨迹做失败归因（failure attribution）：标出主要错误类别、首次出现不可接受行为的步骤、对应的工具调用或模型输出，并附上可复核的证据。归因对象是轨迹中的首个导致任务偏离的错误，后续错误往往只是连锁反应，不能把最后一个报错简单当成根因。

生产 Agent 的 bad case 通常来自三类信号：用户明确纠正（“不要这么做”）、用户点踩或负面反馈，以及事后通过状态检查、规则验证器或 LLM 评审发现 Agent 做了不该做的事情。

构建失败归因系统需要开发者有耐心仔细阅读、分析生产 Agent 的 bad case 轨迹。这个过程可以借助 LLM，但不能完全依赖 LLM，因为失败归因往往反映了产品问题，不止是技术问题。

随着产品不断完善，错误分类可能有多个大类，每个大类下又有多个小类，错误类别可能达到数百类。这些错误类别和归因方式可以作为归因标注 Agent 的提示词或 Skill。

以 Coding Agent 为例，一个实用的初始分类如下。

错误类别	典型表现	首个错误的定位方式
流程与规范缺失	未执行单元测试就提交；未写 Plan 或设计文档就开始改代码；未读仓库必要文档便按个人习惯修改	找到第一次违反流程的动作，例如首次 git commit、首次写文件或首次跳过必读文档的工具调用
工具调用错误	同一文件反复编辑失败；JSON/schema 或参数格式错误；特殊字符导致抄写、转义或写入错误	记录第一次失败的编辑/工具及原始请求、错误返回；重复失败属于后续症状
作用域敏感的文档格式错误	中文自然语言中的直引号未按规范变为弯引号；英文原文、代码、JSON 或路径被错误转换；代码注释与代码语法混淆	定位首个符号所在的文档片段，记录片段类型、语法角色、允许动作和保护动作；同时检查 Markdown、JSON 或源代码是否仍然有效
精确复制错误	old_string 与文件内容只差一个字符、空格、换行、转义或 Unicode code point；模型每次复述同一个低频字符串都发生漂移	沿“原始字节 → 工具返回 → 序列化 → 模型输入 → 模型输出 → 工具匹配”逐层比较，记录首次 byte/token 分歧；若模型输出正确而传输层改变，根因归给 Harness 或工具而非模型
模型执行异常	输出中途截断、无故停止、超时，或没有完成收尾动作就结束	定位第一个异常终止的位置，区分模型停止、Harness 超时和工具服务故障
任务完成度与逻辑判断问题	多目标任务只完成一部分；未穷尽合理方案就宣布不可能；声称完成但验收条件未满足	定位第一次遗漏目标、错误判断 “已完成” 或放弃探索的决策，并与最终验证失败分开记录

归因标注 Agent 可以利用 LLM 规模化完成大量生产轨迹的根因分析，但不能只输出一句 “失败原因”。归因记录需要结构化，可以采用 JSON 或 YAML 文档格式，要求它返回结构化归因记录，并引用具体的步骤号、工具名和观察证据；同时要求它区分根因与后果、判断是否可恢复、给出置信度。例如，edit_file 返回 old_string 匹配失败，之后 Agent 连续三次重试仍未写入文件：主因是 “文件编辑与工具调用错误”，三次重试是后果，而不是三个独立根因。若多个类别同时出现，按 “最早且能解释后续失败” 的原则选主因，其余保留为次因。

在保存归因记录时，除了 LLM 输出的记录，还应把任务目标、环境状态、Agent 和工具集版本、完整 Agent 轨迹一起保存，以便进行回归测试。

作用域敏感的文档格式错误

用户说“引号格式不对”时，不能直接把它转成全局字符替换。至少要区分 ASCII 直引号（"、'）、中文弯引号（“”、‘’）和 Markdown 反引号（`）。同一字符在中文自然语言、英文原文、行内代码、代码块、代码注释、JSON 和路径中承担的语法角色不同。

评估数据应先把文档解析为带作用域的片段，例如 ZH_PROSE、EN_PROSE、QUOTED_SOURCE、INLINE_CODE、CODE_BLOCK、CODE_COMMENT 和 JSON_OR_SCHEMA。每个片段保存允许变换集合、必须保护的字符以及修改后的验证器结果。下面三处不能用同一条替换规则处理：

中文说明：调用 `reset()` 方法。
这是一段英文原文：“Please restart the service.”
```python
# 中文注释：显示 "当前状态"
name = "status"

轨迹前缀回归应要求模型做最小修改，并同时检查中文文档风格、英文原文保持率、代码和 JSON 语法，以及非目标文本的编辑距离。规则无法确定作用域时，保留原文并请求澄清应是允许动作，而不是把猜测性修改算作通过。

精确复制错误：从 old_string mismatch 到逐层定位

old_string 失败也不能只归因于“模型抄错了”。应对同一个字符串保存原始字节哈希、Unicode code point 序列和 tokenizer token ID 序列，沿以下链路寻找首个差异：

文件原始字节 → 工具返回 → Harness 序列化 → 模型上下文
→ 模型 token 输出 → 解码字符串 → JSON/tool-call 解析 → 工具匹配

最小化评估探针覆盖直接复述、从长上下文抽取、放入工具参数、相似字符串选择，以及空格、换行、反斜杠、Unicode 组合字符和低频 token。指标使用 byte-exact match、code-point-exact match、token-exact match、首次分歧位置和真实工具成功率。若模型在直接探针中正确而工具调用失败，应修复 tokenizer、序列化、Harness 或工具协议；只有首个差异出现在模型输出时，才把该案例转成第七章的复制训练数据。

端到端回归任务与轨迹前缀回归任务

失败归因明确了首个错误及其类别，下一步是把修复目标写成可重复执行的测试用例，即回归任务（regression task）。这里需要两层互补的回归任务：端到端回归任务验证改动没有破坏完整工作流；轨迹前缀（trajectory prefix）回归任务则截取首个错误之前的状态，只验证那个决策边界是否被修好。

端到端回归任务从初始状态和用户请求开始，让 Agent 完成整个任务，并检查最终状态、必要输出和安全条件。它最接近生产结果，却难以判断失败究竟发生在哪一步。一般来说，端到端回归任务用于验证 Agent 在各个领域的能力符合预期。本章所述的 OSWorld、AndroidWorld、tau-bench 等标准评测集都是端到端回归任务。

轨迹前缀回归任务把已有的上下文、对话、工具返回和环境状态冻结下来，只要求 Agent 思考并执行下一步或下几步可观察动作，成本更低，也能隔离单个策略或工具问题。对需要高可靠的生产级 Agent，构建轨迹前缀回归任务集往往比端到端回归任务集更重要，也需要开发者有耐心建立上一节所述的失败分类体系和失败归因系统。

轨迹前缀回归任务的答案应定义为可接受动作集合，而不是唯一的动作或答案：可以要求 “先读仓库规则” “先询问用户” 或 “拒绝危险操作”，同时列出禁止动作。

失败归因完成后，就可以构造包括端到端和轨迹前缀回归任务在内的评估数据集。以 Coding Agent 为例，流程缺失应生成带有计划文档和测试验收条件的端到端回归任务；工具调用错误应把出错前缀截断并编辑成边界任务，测试模型能否修正格式、转义特殊字符或换用合适工具；执行异常应加入截断、超时和工具故障的恢复场景；完成度与逻辑错误则应加入多目标清单、剩余任务提醒和 “尚未证明不可能” 的边界。

评估数据集是第七章模型后训练和第八章 Agent 自我进化的基础。

下面以用户记忆为一个具体案例，展示如何把这套通用方法落到可执行的评估集和评分器上。

实验 6-3 ★★：构建基于 Rubric 的用户记忆评估系统

前置要求：需完成第三章用户记忆实验（chapter3/user-memory-evaluation）。

本实验要求改造第三章的 chapter3/user-memory-evaluation 框架，将当前基于简单 LLM-as-a-Judge 的评分机制升级为结构化的多维度 Rubric 评估系统。现有系统使用单一 LLM 调用返回通过/失败加评估理由，缺乏结构化的诊断能力。

设计统一的多维度 Rubric 框架，适用于所有三层任务。评价维度包括：事实正确性（Precision，精确率——在所有给出的信息中，有多少是正确的）验证数字/日期/名称是否与记忆信息一致；事实完整性（Recall，召回率——在所有应该给出的信息中，有多少被提及了）验证是否提供了所有相关信息而非遗漏关键内容；思考正确性检查是否正确理解了信息间的关系和隐含逻辑；思考主动性评估是否在适当时候提供超出直接回答的建议或风险提醒；幻觉检测确保未编造记忆中不存在的信息。

四档制评分（优秀/良好/及格/不及格），每档配具体判定标准而非抽象描述。幻觉维度设为一票否决项。为每个维度提供示例和边界案例。

实验 6-4 ★★：Advanced JSON Cards 与 RAG 的对比评估

前置要求：需完成第三章用户记忆与 RAG 实验（chapter3/user-memory、chapter3/agentic-rag-for-user-memory）。

目标：在同一套评估集上公平对比结构化记忆与非结构化检索的优势边界。复用两个第三章项目，在 chapter3/user-memory-evaluation 的 60 个测试用例上对比三种配置——纯 Advanced JSON Cards（结构化卡片常驻上下文、无需检索）、纯 RAG（对话分块入向量库、必须检索）、混合系统（核心事实常驻 + 原始对话按需检索）。

验收：在三层复杂度（基础回忆 / 多会话消歧 / 跨会话隐藏关联）上记录成功率、平均步数、工具调用次数、延迟与成本，说清每种方案的失效边界——结构化丢了什么、检索漏了什么、混合是否真有协同。注意，这一实验属于端到端回归层：它检验完整任务是否仍然可用，但不能单独说明 Agent 在记忆已经出现时是否正确判断了作用域。配置细节与测试用例见配套仓库。

配套实验用同一组 60 个问题测试了三套记忆方案，共保留 180 条真实 API 运行轨迹。结果见表6-3；总体成功率后面同时列出成功题数，以免百分比掩盖样本量。

表6-3 三种用户记忆系统的分层成功率

系统	基础回忆	多会话消歧	跨会话隐藏关联	总体
Advanced JSON Cards	95%	60%	50%	68.3%（41/60）
RAG	90%	40%	15%	48.3%（29/60）
混合系统	80%	70%	50%	66.7%（40/60）

最值得注意的是，混合方案并没有自然胜出。它在 3 道题上做到了两种单一方案都没做到的事，却在另外 8 道题上不如表现更好的单一方案；与每道题上的最佳单一方案相比，平均奖励反而低了 0.092。纯 RAG 在基础回忆题上与结构化卡片相差不大，一到跨会话关联题，成功率却降到 15%。这说明检索出相关片段只是第一步，Agent 还得把人物、时间和事件之间的关系拼对。

另一个容易被忽视的数字是：180 次评判中，幻觉否决触发了 28 次。可见一票否决项并不是写在 Rubric 里 “以防万一” 的装饰，它确实会改变最终结果。

实验 6-5 ★★：轨迹前缀边界评估：同一上下文的多种表示

前置要求：需理解本节的轨迹前缀评估协议；本次案例使用第三章的用户记忆表示和本节的 Rubric 设计，不要求运行完整的 60 用例端到端记忆矩阵。

本实验不测试“上下文检索器有没有找回信息”，而是把一组已经提供给 Agent 的上下文（本案例使用用户记忆）、当前任务、trajectory prefix、工具返回和环境状态一起输入模型，要求模型只输出下一步可观察动作。用例来自三类生产 bad case：用户纠正、点踩关联轨迹，以及事后规则/LLM 审计发现的错误。边界覆盖论文风格与 X 帖子的作用域冲突、worktree/PR 习惯与仓库规则冲突、当前明确指令覆盖旧偏好、低置信度推断、高风险删除前确认，以及对外发布前预览等情况。

对同一组用例运行 JSON Cards、Markdown 和 Python-like 三种等语义表示。它们是用户记忆这一案例的三种编码；换成 RAG 证据、系统提示或工具观察时，也可以沿用同一套轨迹前缀评估协议。评分由确定性规则完成：决策类别是否属于允许集合、下一步动作是否安全、是否出现要求的证据、是否触发禁止动作，以及上下文是否在该场景被正确使用。

配套实验使用 GPT 5.6 Sol 模型，完成了 11 个边界用例 × 3 种表示，共 33/33 个 API 单元且没有 API 错误。三种表示的总成绩碰巧都是 6/11，但失败位置并不完全相同：Markdown 通过了“仓库规则未知时先检查”的用例，却多失败了一个作用域冲突用例；JSON Cards 和 Python-like 的情况相反。三种表示都没有通过论文风格过度泛化、过时偏好覆盖当前要求、以及高风险删除前确认这三类用例。这个小样本评估说明，改变上下文的表示方式并不会自动修复应用策略。

同源模型问题与多源评判。

当 Agent 与评判模型来自同一家族时，Agent 可能学会利用评判模型的偏好和盲点。

这正是古德哈特定律（Goodhart's Law）所说的：当一个度量指标变成优化目标时，它就不再是好的度量指标。 Agent 越是在某个评分系统上训练或调优，就越倾向于钻这个系统的漏洞，而非真正提升能力。

更隐蔽的是，Agent 还会逐渐学会避开评判模型不擅长检测的错误类型，让评分系统看起来一切正常。

缓解策略是多源异构评判——使用不同模型家族的多个 LLM 分别评判（比如 Agent 用 Claude，评判就用 GPT-5 和 Gemini），不同家族的偏见往往是正交的，Agent 很难同时“欺骗”所有评判者。使用相同的 Rubric 确保大家评判的是同一目标，通过加权平均或一致性检查聚合结果。部署阶段可以用单一模型快速评估，但应定期用完整的多源评判进行质量审计。

多源评判解决的是“用什么模型评判”的问题；接下来要解决“评判哪些模态”的问题——把 LLM-as-a-Judge 的能力从文本扩展到语音、图像、视频，是评估覆盖度的另一维度。

多模态 LLM-as-a-Judge。

多模态评判将 LLM-as-a-Judge 扩展到语音、图像、视频领域，常见的四个方向如下。

• TTS 评估（TTS 即 Text-to-Speech，文本转语音）：判断准确性、自然度、音色一致度、情感表达。这些维度能发现传统 WER（Word Error Rate，词错误率）难以捕捉的韵律问题。
• ASR 评估（ASR 即 Automatic Speech Recognition，语音识别）：做语义影响判断——“今天天气”识别错误无伤大雅，但“转账一千”变成“一万”就可能造成严重后果。
• UI 评估：采用提议者-审核者（Proposer-Reviewer）机制，检查文字溢出、颜色对比度、按钮位置等问题。这里的提议者-审核者作为评估方法使用，与第五章中作为生成系统组件的用法不同，但核心机制相同——一个模型生成，另一个模型独立审查。
• 视频剪辑评估：通过关键帧验证剪辑起止点和特效应用是否正确。

实验 6-6 ★★：构建全自动 TTS 质量评估流水线

本实验要求从零设计并实现完整的多模态 LLM-as-a-Judge TTS 质量评估系统。

设计 TTS 多维度 Rubric：准确性维度验证是否正确读出所有文字（无遗漏/错读/添加），自然度维度评估语音是否流畅（有无机器感、不自然停顿，韵律是否符合人类习惯），情感表达维度检查语气是否符合文本情感色彩（疑问句升调、感叹句强调、悲伤内容语速慢语调低），音色一致性维度在有参考语音时评估说话人相似程度（多模态模型同时接收参考语音与合成语音对比）。

构建多样化测试语料库：不同长度（单句→长段落）、文体（新闻/故事/对话）、情感（中性/兴奋/悲伤）、特殊挑战（数字/专有名词/多音字/方言词汇）。实现评估流水线：TTS 生成模块接入主流服务（OpenAI、ElevenLabs、Fish Audio、Minimax、豆包），由可直接接收音频的多模态评判模型将合成语音、原始文本、参考语音和 Rubric 一起输入，逐维度评分并给出详细理由。分析评估结果的分布，同时记录评判模型、参考音频哈希和候选音频哈希，使结果可复核。

配套仓库中保留了一次小规模的直接听评。OpenAI 和 Fish Audio 分别生成了数字、多音字、长句和兴奋语气四类音频，8 条音频都由 Voxtral 按上述四个维度完成评分。两者在准确性和自然度上都得到 5.00 和 4.00；Fish Audio 在情感表达和音色一致性上得到 4.00 和 3.00，OpenAI 则是 3.75 和 2.75。四个维度分开评分后，即使“有没有读对”看不出差别，语气和音色上的差别仍会显现出来。

但这组分数还不能用来判断哪家 TTS 更好。每家只有四条音频，更关键的是，实验使用的固定参考音频来自 Fish S1；拿它来比较音色，本来就更有利于 Fish Audio。如果要比较通用 TTS，就不该把“像不像 Fish 参考音色”算进总分；如果要比较声音克隆，则应让所有方案模仿同一个目标说话人，并用人工盲听校准模型评分。选什么参考答案、参考图片或参考音频，本身就是评估设计，而不是评估开始前无关紧要的准备工作。

人工编写 Rubric 适合快速建立这样的诊断维度。评估规模再扩大时，还可以训练专门的生成式奖励模型来自动打分——相关训练方法将在第七章讨论。

在实际的模型选型中，我们经常面对的问题是：“A 和 B 哪个更好？”配对比较提供了一种不依赖绝对分数的评估方式。

配对比较与模型排名

Elo 评分（一种最初用于国际象棋的排名系统）通过大量的两两对决来量化模型的相对能力：分差越大，强者的预期胜率越高。例如，模型 A 得分 1200、模型 B 得分 1000，Elo 系统会预测 A 的胜率约 76%。如果 B 意外获胜，B 加分较多、A 减分较多——爆冷的结果会带来更大的分数调整，这种机制让排名快速收敛到真实水平。其背后的统计基础是 Bradley-Terry 模型：将每个模型抽象为一个潜在的“实力分数”，两两对决胜负的概率由两者分数差决定，Elo 即是该模型在线更新形式的工程实现。

Chatbot Arena 采用匿名随机对决——用户在不知道模型身份的情况下盲选更优回应，通过数百万次投票得出排名。这种方法的优势在于不需要定义“绝对标准”，只需要人类判断“A 和 B 哪个更好”。但也有局限：排名结果取决于用户提了什么问题——如果大量用户恰好都问编程题，擅长编程的模型排名就会偏高，这未必反映它在其他任务上的真实水平。

当配对评判由 LLM 而非人类投票完成时，还要防范位置偏差（Position Bias）——评判模型会系统性地偏向出现在某个位置（通常是先出现）的候选，即使两个候选的内容完全对调，判决也可能不变。标准的缓解方法是交换顺序各评一次：A 在前评一次、B 在前再评一次，取两次结果的平均；更严格的做法是只有两次判决一致时才计入，不一致则记为平局或送人工复核。Chatbot Arena 的做法本质相同——随机化两个回答的展示位置，让位置偏差在大样本下相互抵消。

实验 6-7 ★★：从配对比较数据构建模型排行榜

本实验通过从零实现 Elo rating 计算系统，深入理解 Bradley-Terry 模型如何从大量配对比较中提取出相对能力评分。使用 Chatbot Arena 开源的真实投票数据集（包含数百万次用户盲选投票）。

实现 Elo rating 迭代更新算法：初始所有模型评分 1000 分，按时间顺序处理投票记录。对每场对决，根据两个模型当前的评分差计算预期胜率，将实际结果与预期比较，按固定学习率调整——胜者加分、败者减分，调整幅度与预期偏差成正比（爆冷失败会导致更大的分数变化）。按最终评分降序排列并计算两两胜率矩阵，与官方榜单对比、验证排名大体一致即可。不必苛求逐分对齐：Chatbot Arena 官方用的是 Bradley-Terry 极大似然拟合（对全部对局一次性求解，与投票的先后顺序无关），而这里实现的是在线增量更新的 Elo（结果受学习率 K 因子和处理顺序影响），两种算法在总体排名上应当吻合，但具体分值不会精确一致。

实验第二部分创建历史排名演进动画：将投票数据按时间切片（每周或每月），对每个时间点计算 Elo 评分快照。使用 D3.js 实现条形图竞赛动画（水平条形长度=评分，纵向位置=排名，随时间平滑变化）。通过观察动画识别技术突破时刻（某模型评分骤升）、竞争格局演变、模型生命周期。

评估驱动的模型选型

模型选择不是简单地“选最强的模型”，而是根据应用场景在多个维度之间做评估驱动的权衡。

选型的关键维度

吞吐量与延迟是两组容易混淆的指标，理清它们只需知道大模型推理分两个阶段。Prefill（预填充）一次性读入完整上下文，决定用户按下回车到第一个字出现的首字延迟（业内用 TTFT，Time To First Token 度量）——上下文越长 prefill 越慢、TTFT 越大。**Decode（解码）**随后逐 token 生成回答，决定后续出字速度（tokens/秒），也直接决定思考时长：一个 50 tokens/s 的模型生成 2000 个思考 token，光思考就要 40 秒。

围绕这两个阶段，主要的吞吐与延迟指标如下：

• 输入吞吐量 / 输出吞吐量：分别对应 Prefill 和 Decode 的速度。
• TTFT：等于排队时间加上 Prefill 时间，是用户感知的 “反应快慢”。
• 思考延迟：不同模型生成的思考 token 数差异可达数倍，且思考长度与任务效果不一定正相关。应在自己的工作负载上实测各模型的思考 token 用量和对应收益，而非仅凭公开榜单推断。
• p95 尾部延迟：95% 的请求都不会超过的延迟。它比平均值更能反映真实用户体验——均值会被大量快速请求拉低，掩盖少数用户遭遇的严重卡顿。

成本：输入/输出/缓存 token 的定价。一个便宜但成功率低的模型，因为需要频繁重试，实际花费可能反而更高。需要计算每个任务的平均成本和成本-性能比。

性能：Pass@1、Pass@k、Pass^k、Best@k 等四个指标的精确定义见前文 “评估指标体系”。日常场景看最常用的 Pass@1（单次平均成功率）；关键操作场景优先 Pass^k，盯的是 “每次都别出错” 的稳定性；探索性任务优先 Pass@k 或 Best@k，看的是给足机会后的能力上限。

速率限制与可靠性：RPM（每分钟请求数）/ TPM（每分钟 token 数）限制会影响并发能力，某些 API 在高峰期还会动态调整限额。鲁棒性方面需关注分布外数据、对抗性输入、长时运行稳定性（是否出现模式崩溃、注意力分散等问题）。

预算—能力曲线：固定预算下的单点成绩不足以判断 Agent 能否胜任长程任务。除了成功率，还应报告性能随墙钟时间、token、工具调用次数或算力预算变化的曲线。RE-Bench 的人机对照很能说明问题：在每个环境 2 小时的总预算下，最佳 Agent 得分约为人类专家的 4 倍；但人类从增加时间预算中获得的收益更大，8 小时时已略微超过最佳 Agent，在跨多次尝试合计 32 小时时得分约为其 2 倍[^re-bench-2025]。因此，短预算领先不能直接外推成长时间运行能力，选型时必须在接近真实任务时长的多个预算点上比较。

实践中可以采用多模型协同的策略：用轻量模型处理简单请求以降低成本，用强大模型处理复杂任务以保证质量；或者使用专门的模型处理特定的子任务（如图像理解、代码生成），通过子 Agent 机制进行协作。这种异构的模型组合需要通过评估来验证，确认整体效益是否超过了所增加的系统复杂度，以及是否会在一些场景下出现性能回退（例如，把 “9.9 跟 9.11 哪个大” “要洗车，家离洗车店 50 米，是走路去还是开车去” 等问题视为简单问题交给轻量模型，导致决策错误）。

模型的行为策略

模型选型不只是在比较 “能不能做成”，还要比较模型默认会怎样做。Coding Agent 中一个很容易观察到的差异是行动阈值：面对同一个代码任务，有的模型会先广泛探索仓库再修改；有的模型则凭较少的局部证据快速定位，先改再用测试反馈补齐认识。前者把过早修改的风险估得更高，后者把 “再读一个文件” 的机会成本估得更高。

Agent 的这种倾向有两个来源：Harness 中的系统提示词、模型的行为策略。后训练是模型行为策略的关键来源：SFT 轨迹会示范 “先读到什么程度再动手”，过程奖励会奖励或惩罚某种工具路径，结果奖励又会强化最终成功的整套策略。久而久之，模型学到的不只是如何写代码，也包括工程习惯。

实验 6-8 ★★：在固定 Coding Harness 中测量模型的行动阈值

实验目标：隔离模型因素，量化不同 Coding 模型在“继续收集信息”与“开始修改代码”之间的默认取舍，并把路径效率与最终质量联合起来评价。

技术方案：默认通过同一个 OpenRouter OpenAI-compatible 端点调用 GPT-5.6-sol 与 Claude Sonnet 5，固定系统提示、工具 Schema、任务仓库、测试命令和最大轮次；中性提示既不要求读够若干文件，也不要求尽快编辑。三个小型代码库分别覆盖局部 bug、跨模块身份规范化和公共契约敏感的缓存修复，每个模型对每题独立运行三次，共 18 条轨迹。

因果判断：中性实验回答 “同一 Harness 下，行为是否随模型变化”。如需测 Harness 的调节作用，再用 --policy explore-first 单独跑一组；不要把两种 policy 混在同一模型比较里。若更换模型时行为改变、而同一模型跨 Harness 保持倾向，则证据更支持模型效应；反之则更支持 Harness 效应。

实验发现：GPT-5.6-sol 在第一次修改前平均调用工具 6.89 次、读取 4.67 个文件；Claude Sonnet 5 分别为 4.56 次和 3.56 个文件。差距在局部任务中最明显，而在明确跨模块的任务中几乎收敛（7.00 对 6.67 个文件）。两者的首个受测补丁和最终测试均为 100% 通过，因此这个小实验支持的是“行动策略随模型而变”，而不是“多读或早改必然更好”。时间到首次修改也几乎相同（15.01 秒对 14.48 秒），提醒我们工具步数、并行调用和模型延迟必须分开看。

Agent 系统的成本分析

成本是模型选型中容易被低估的维度。如果你的 Agent 已进入生产环境或准备进入生产环境，本节的成本分析不应跳过。

上一节将成本列为模型选型的关键维度之一，但 Agent 场景下的成本远比简单的 token 定价复杂——多轮推理、工具调用和上下文累积会使成本呈非线性增长。系统性的成本分析是评估体系不可或缺的一环，也是生产部署的必要前提。

成本的构成要素。

Agent 系统的成本可分解为三个层次：

模型推理成本是最直接的部分，由输入 token 和输出 token 的消耗决定。但 Agent 场景下有两个常被忽视的放大因素。一是上下文累积效应：Agent 每轮调用 LLM 时，都会把之前所有的对话历史和工具返回结果一起发送（这样模型才能理解上下文）。如果没有利用好 KV Cache（即缓存已处理过的上下文，避免重复计算），成本增长会非常快——第 1 轮发送 1000 token，第 2 轮发送 2000 token，第 3 轮发送 3000 token，总量是 1000+2000+3000=6000 而非 3×1000=3000，轮次越多差距越大。二是思考 token 成本：支持思考的模型会生成大量思考 token，这些 token 虽然不展示给用户，但同样计入费用。

工具调用成本包括外部 API 费用（搜索引擎按次计费、数据库查询消耗计算资源）、代码执行的沙盒资源，以及一个容易被忽视的间接成本：工具返回结果注入上下文后产生的 token 费用。一次网页搜索返回的内容可能就占用 2000-5000 个 token，而且在后续每轮推理中都会作为输入被反复计费。

基础设施成本涵盖向量数据库（用于 RAG 检索）、消息队列、关系型数据库、日志与追踪存储（用于可观测性）等运维开销。

为了看清这些费用究竟从哪里来，配套实验选了一个固定的八轮客服退款任务：查询订单、物流、退款政策和知识库，随后完成风控、退款、通知与关单。实验调用 gpt-4o-mini，分别打开或关闭 “稳定前缀” 和 “压缩历史” 两个开关，得到四组对照。

表6-4 八轮 Agent 任务的真实成本对照

方案	输入 token	缓存 token	总成本	比基线节省
无缓存、无压缩	20,700	0	$0.003776	—
仅稳定前缀	20,386	13,568	$0.002707	28.3%
仅压缩历史	16,177	0	$0.003115	17.5%
稳定前缀 + 压缩	16,035	6,144	$0.002643	30.0%

在基线组中，每轮输入从 1,113 token 一路涨到 3,668 token。工具返回会跟着历史反复进入后续请求，八轮累计占了 9,544 个输入 token。两项优化同时开启后，这个数字降到 5,248，总费用下降 30%。

不过，“仅稳定前缀”已经节省 28.3%，“仅压缩历史”又节省 17.5%，两者一起却只节省 30%，并不是二者相加。原因是压缩历史的同时，也缩短了可以命中缓存的前缀。因此，几项上下文优化同时使用时，必须在完整任务中一起实测，不能把各自的节省比例直接相加。

成本优化策略。

从输入侧看，最值得优先测试的有三类办法：复用 KV Cache，也就是尽量保持前缀不变；压缩上下文，减少旧轨迹和冗长工具返回；以及分层选择模型，让轻量模型处理简单请求、强模型处理复杂推理。第二章已经介绍了具体做法。这里要强调的是：这些能力最好都能独立开关，这样既能看清每一项的作用，也能检查它们合用时会不会互相抵消。除此之外，还有两项与评估和运维直接相关的手段。

异步批处理将非实时任务积攒起来批量处理，利用 API 提供商在波谷时段的批量定价折扣；在模型本地部署场景下，也能提高波谷时段的 GPU 利用率。

成本监控与预算控制。

生产环境中应当建立实时的成本监控体系：按任务类型、模型、用户等维度追踪 token 消耗和 API 费用。同时设置每个任务的成本上限——当 Agent 陷入循环或探索过深时自动终止，防止单次任务产生异常高额的费用。

实验 6-9 ★：Agent 任务的端到端成本分析

实验目标：复现上述八轮任务的全链路成本拆解，并用自己的真实工作负载验证优化策略。

技术方案：先复现配套仓库中的固定任务，再换成几个自己的典型任务。使用 LangSmith 或自建追踪系统记录每次 LLM 调用的输入/输出 token 数、思考 token 数、工具调用次数和返回大小、端到端延迟。计算每类任务的平均成本、成本分布（p50/p95/p99）和成本构成比例。

验收标准：生成成本拆解报告，识别主要成本驱动因素。四种开关组合都要运行，既比较每项优化单独带来的变化，也检查两项优化合用后的结果。

评估驱动的持续迭代

模型选择不是一次性的决策，而是随着模型演进需要动态调整的持续过程。本章开篇已经提出 “拥有评估体系就能快速跟上模型演进” 这一核心理念，下面用一个具体的模型切换案例，说明这套体系在真实决策中究竟如何运作。

假设你的 Agent 系统当前基于 Claude 构建，在工具调用和复杂编排上表现优异。某天 Gemini 发布了一个新模型，公开基准显示它在多项指标上超越 Claude，而且定价更低。此时你面临的问题不是 “Gemini 是否比 Claude 强”，而是 “在我的特定任务上，Gemini 是否比 Claude 好？好多少？切换成本是什么？”

拥有完善评估体系的团队可以在数小时内给出答案：在自己的评估数据集上运行新模型，对比任务成功率、工具调用正确率、延迟和成本。你可能会发现新模型在简单任务上确实更优且更便宜，但在涉及复杂多轮工具编排的核心场景中，成功率反而下降了 5%——在确认这一差异超出噪声带宽之后（见下文 “评估结果的统计显著性”），你的决策就变成了 “简单任务迁移到新模型以降低成本，复杂任务保留原模型以确保质量” 的差异化策略，而非盲目的全量切换。这种精细化的数据驱动决策，只有在预先构建好评估体系的前提下才可能实现。

实验 6-10 ★★：多维度模型性能基准测试

对主流 LLM 及不同 API 提供商进行全面基准测试，建立多维度模型选型决策数据库。

选择测试范围：GPT 系列、Claude 系列、Gemini 系列、Doubao 系列等闭源 SOTA 模型，以及 Qwen、Kimi、DeepSeek 等开源模型。对同一模型测试不同 API 提供商（如 DeepSeek 官方 vs Siliconflow），验证第三方性能监测平台（如 Artificial Analysis）的结果。

设计标准化测试工作负载：输入吞吐量测试使用固定长度上下文（8K/32K/128K tokens），输出吞吐量测试请求生成固定长度响应（512/2048 tokens）。延迟测试包含 TTFT（首个 token 生成时间）和端到端延迟，对支持思考的模型单独测量思考长度与思考延迟。每个配置至少 100 次请求，计算标准差/p50/p95/p99——高延迟方差意味着用户体验不稳定。

评估 API 的可用性与稳定性：在一周内每小时探测一次，记录成功率、错误类型和故障时长。计算故障率、MTTR（平均恢复时间）和最长连续可用时间。测试速率限制的实际阈值——通过逐步提升并发量来找到限流点，记录 RPM/TPM 上限。计算综合成本：收集定价信息（输入/输出/缓存 token 的单价），考虑 KV Cache 的影响，计算典型多轮 Agent 任务的平均成本。

实验 6-11 ★★：用户记忆系统的端到端选型评估

前置要求：需完成第三章上下文检索或智能体化 RAG 实验。

目标：对用户记忆检索 Agent 做全链路选型评估，看嵌入模型、reranker、Agent 主模型三个选择点如何共同影响检索质量、延迟与成本。复用 chapter3/contextual-retrieval-for-user-memory 或 chapter3/agentic-rag-for-user-memory，在 60 个测试用例上对比。

验收：遍历三个选择点：嵌入模型（BGE-M3 / OpenAI / 豆包等，记 top-5 检索准确率、延迟、成本）、reranker（含“不用 reranker”基线，量化其边际价值）、主模型（相同检索配置下比成功率与工具使用效率）。发现：更强的嵌入可能让 reranker 变得多余，更强的主模型可能弥补检索的不足。

评估结果的统计显著性

评估集有限，模型输出又有随机性，因此分数差异可能只是抽样噪声。若在 $n$ 个用例上测得成功率 $p$，标准误可粗略估为：

$$ \mathrm{SE}(p)\approx\sqrt{\frac{p(1-p)}{n}} $$

例如 100 个用例、成功率 70% 时，95% 置信区间约为 $70%\pm9$ 个百分点；“新模型 73% 对旧模型 70%”不足以支持切换。

同一批任务比较两个配置时，应优先做配对分析：逐题记录谁胜出，用 McNemar 检验或配对 bootstrap 判断差异，而不是直接相减两个独立成功率。由于 Agent 每次运行也可能不同，每个配置最好用多个随机种子（如 3–5 次），报告均值和波动范围；单次运行只能用来筛选方向。若预期收益只有 2–3 个百分点，而评估集只有几十题，应该先扩大样本，标准误会按 $1/\sqrt{n}$ 缩小。

并行验证多个假设时还要考虑多重比较：收紧显著性阈值，或对正向结果做独立复跑。实务上的判断标准很简单：分差要超过噪声、在配对分析中成立，并且能够复现，才值得据此切换模型或发布改动。

Agent 的可观测性

评估驱动的决策（无论是模型选型还是持续迭代）都依赖于高质量的运行数据。下面先介绍如何系统性地采集这些数据（可观测性），然后讨论如何将评估结果转化为系统改进。

可观测性（Observability）这个概念借自分布式系统领域：你没法直接打开系统内部看它在做什么，只能通过它输出的日志、指标和追踪数据来推断发生了什么，就像医生不能直接看到患者体内的情况，只能通过体温、血压、影像等外部信号来诊断问题。Agent 系统把这件事变得更难：同样的输入可能产生不同的输出，多轮推理和工具调用使执行路径极其复杂，而模型的“思考”过程对外完全不透明。

可观测性的价值首先在于问题诊断：完整的轨迹让开发者能回放全过程，而非靠猜测。其次是持续优化的基础——你能看到哪些任务需要多轮迭代、哪些工具成功率最低、哪些检索查询总是返回空结果。在成本管理上，Agent 运行成本在不同任务上可能差一两个数量级，追踪可以识别出异常高成本的案例。最后，积累的轨迹数据也为模型后训练提供了基础。

Agent 可观测性的数据基础是追踪（Trace），其数据结构直接沿用了分布式系统的 span 树模型：一次任务执行对应一条 trace，其中每个 LLM 调用、每次工具调用、每次检索都是一个 span（记录输入输出、起止时间、token 消耗、错误信息的执行单元），span 之间的父子关系构成一棵执行树——比如“Agent 主循环”span 之下挂着若干“LLM 调用”和“工具调用”子 span。这一层已有标准化协议可用：OpenTelemetry 是通用的分布式追踪标准，OpenInference 等规范则在其上定义了 LLM 应用特有的语义约定（如何记录提示词、模型参数、token 用量等）。采用标准协议的好处是采集与分析解耦——同一份追踪数据可以对接不同的分析后端，避免被单一平台锁定。

LangSmith 是这一领域的代表性平台之一（类似定位的还有 Langfuse、Arize Phoenix 等），将可观测性、评估、优化整合为闭环。每次执行创建一个追踪会话，其中的模型调用、工具使用、知识检索被记录为独立的执行单元，通过因果关系链接形成一棵执行树。每个单元记录完整的输入输出、时间信息、成本数据和错误信息。平台采用异步批量数据采集，确保追踪本身不影响 Agent 的响应延迟。

平台还支持 A/B 测试（将一部分用户的流量路由到新版本，自动对比各项指标，支持快速回滚或渐进扩量）、提示词版本管理（每个版本都关联着运行时的性能数据）、以及协作式开发（团队成员可共享追踪数据和问题案例）。生产环境中的海量真实数据是持续改进的金矿——能发现未曾预料的场景，识别最需要优化的功能点。

可观测性数据最有价值的去向，是回流成评估资产。一条实用的闭环是：从生产轨迹中筛选出失败与可疑案例 → 脱敏处理（去除用户隐私、密钥等敏感字段）→ 沉淀为评估集的新用例和回归测试。这样评估集就不再是一次性构造的静态集合，而是随产品演化、持续贴近真实用户分布的活资产。今天线上暴露的失败模式，明天就成为守住这条底线的回归用例。

有了完备的评估体系和数据集之后，关键在于将评估结果转化为切实的系统改进。

从 Benchmark 报告到系统改进

下面来看配套仓库里一次真实的 AndroidWorld 调优过程。实验只跑了 API 35 模拟器上的 4 个 Wi-Fi 设置任务，每项任务做一次配对对照。这个案例的价值不在于证明系统整体提高了多少，而在于展示如何根据一轮结果，决定下一轮只改什么。

从 Harness 工程的视角看，这一节本质上讲的是 Harness 迭代优化的方法论——通过评估数据定位 Harness 中的薄弱环节（上下文不足？约束缺失？验证不够？反馈不及时？），有针对性地改进，再重新评估，形成 Harness 持续进化的闭环。

在开始分析 Benchmark 报告之前，有一条容易被忽视的原则：看到 Agent 表现下降时，应先检查评测系统本身，再动 Agent。一个常见误区是看到分数下降就立刻修改 Agent 代码，而忽略了评测系统本身可能先出了问题——基于失真的信号调整方向，改的方向可能从一开始就是错的。评测系统常见的错误来源包括：运行环境的资源不足导致进程被杀（表现为随机性的失败）、评分器本身有 bug 把正确答案判为失败、测试用例与生产场景之间存在脱节。这些问题在结果数字上都跟模型退化一模一样，只有审查完整的轨迹才能区分。

读懂 Benchmark 报告：发现问题的艺术

最初的报告记录了 116 项任务各跑一次的结果，总成功率约为 88%。但失败并不是零星散落的：四项 SystemWifiTurn* 任务里有三项失败，轨迹中还反复出现来回导航、无法确认最终状态等现象。这里至少有两种解释：可能是 Agent 不知道设置入口，也可能是它拿到的界面信息不完整。

如果只盯着 88% 这个总分，这个小而集中的失败簇很容易被忽略；如果只是增加最大步数，又可能把“看不见界面”误当成“不够耐心”。所以，读报告时应先找失败集中在哪些任务和能力上，再回放轨迹，分清问题出在看、想、做还是验。本例先把范围缩到四项 Wi-Fi 任务，目的只是用较低成本判断病因，不是估算系统的整体水平。

从数据到假设：构建改进路线图

第一轮先试最便宜的改法。假设 H1 认为 Agent 只是“不知道路”，因此只给实验组补充 Wi-Fi 设置的导航提示和最终状态检查要求。结果成功率没有变化，说明问题不在提示词。

第二轮转而检查 Agent 到底“看见了什么”。假设 H5 把 API 35 上不兼容的 accessibility feed 换成 AndroidWorld 已支持的 UIAutomator 元素树。成功率确实提高了，但完整元素树太长，token 用量大幅上升。于是第三轮 H5C 不再增加新信息，只把元素树中不可见、没有文字、也不能操作的容器节点删掉，看看能否在保留成功率的同时去掉噪声。

三轮实验始终使用相同的模型、任务参数、随机种子、步数上限和模拟器，并交替安排两组的运行顺序。这样一轮接一轮地缩小问题，比同时堆上许多改动更容易说清因果：上一轮暴露的问题，恰好成为下一轮唯一要验证的改动。

从结果到决策：数据驱动的权衡

三轮实测结果汇总在表6-5。每组都只有四项任务，所以这里的数字只能用来决定下一步是否值得扩大测试，不能用来推断整个 AndroidWorld 的成功率。

表6-5 AndroidWorld Wi-Fi 子集的三轮实验

实验	只改了什么	对照组→实验组成功率	实验组/对照组 token	下一步
H1	增加导航提示	25%→25%	0.47×	没有提高成功率，沿用原提示
H5	accessibility feed 换成 UIAutomator	25%→100%	2.498×	效果明显但太费 token，继续优化
H5C	精简 UIAutomator 元素树	100%→100%	0.506×	成功率不变、token 减半，进入完整复测

三轮结果串起来看，结论比某一个百分比更有用。第一，提示写得更详细，也补不回 Agent 根本没有看到的信息；遇到这类失败，应先检查输入，而不是继续堆提示词。第二，输入也不是越多越好。完整元素树解决了“看不见”的问题，却带来大量无用 token；删除无语义节点后，四项任务仍全部成功，token 又减少了约一半。整个过程中没有更换模型，仅仅调整 Harness 如何表示界面，就先后解决了“能不能做成”和“做成是否划算”两个问题。

持续迭代：从第一次改进到系统演化

H5C 通过了这四项任务的检查，只说明它值得进入下一轮，并不等于可以部署。下一步需要补齐第三方应用，在 Pixel 6 / API 33 标准环境中，对 116 项任务各跑 5 个随机种子；除了检查成功率不能下降，还要确认 token 不超过原方案的 75%，延迟不超过 1.5 倍。在这轮完整复测之前，不能把子集上的 4/4 写成系统整体 100%。

这就是持续迭代真正的含义：一轮证据只支持与它规模相称的下一步。H1 失败，让我们不再继续堆提示词；H5 找到了正确方向，也暴露了成本问题；H5C 解决成本问题后，才获得扩大测试的资格。好的 Benchmark 报告不只给出一个分数，还应写清结论适用于哪里、哪些底线没有通过、下一轮要验证什么。

实验 6-12 ★★★：AndroidWorld 的评估和改进

本实验练习如何从评估报告一路走到系统改进。以 chapter6/android-world 中的 AndroidWorld 历史报告和三组已保存的配对结果为起点。

第一步：诊断。交叉分析逐任务表格和能力标签矩阵，将表面的任务失败映射到深层的能力缺陷。识别成功率低于预期的能力标签和集中失败的任务区域。

第二步：构建假设。按照三层框架（表层→中层→深层）形成改进假设，每个假设明确预期的成功率提升目标和验证方法。

第三步：分阶段实验。先复现 H1、H5 和 H5C，每轮只改变一个变量；除成功率外，还要记录 token、延迟和是否出现回退。

第四步：数据驱动决策。根据成本收益比做部署决策——不是简单地采用所有有效的改进，而是需要权衡每项改进的适用范围、延迟影响和成本开销。低成本高收益的改进优先部署，高成本的改进限定在关键场景中使用。

第五步：迭代。小范围实验通过后，只能进入完整复测；在标准环境完成 116×5 次运行后，才能讨论是否部署。报告中必须保留环境差异、样本量和尚未完成的部分。

从外部评估到内部评估：生产级 Agent 的评估基础设施

前面几节讨论了如何从外部评估 Agent 系统——搭建评估环境、设计数据集、分析 Benchmark 报告。但最优秀的 Agent 产品不仅接受外部评估，还内建了持续自我评估的基础设施。下面以第五章介绍的开源通用 Agent OpenClaw 为例，并结合头部 Coding Agent 产品的公开技术分析与从业者分享，展示一套值得借鉴的内部评估体系——它将 ML 研究中的实验方法论系统性地嵌入到了产品工程中。

消融基础设施：理解每个特性的真实贡献

ML 研究者长期使用消融实验（Ablation Study）来理解模型的哪些组件真正重要——所谓消融，就是逐一“摘除”某个组件，看整体性能掉多少。OpenClaw 将这一方法论引入了产品工程：系统内置了一个总开关，可以同时禁用多个主要特性（思考模式、上下文压缩、自动记忆、后台任务等），创造一个“裸模型”基线。这使得团队能回答一个关键问题：某个特性是真的改善了用户体验，还是只是感觉有用？

将消融作为常规的工程实践而非一次性的研究，有几个实际意义。首先，消融开关必须在启动路径的极早期注入——在任何模块级常量捕获配置值之前——这意味着消融基础设施必须从一开始就设计进系统架构，而非事后加装。其次，定期运行消融实验（如每次大版本发布前）可以发现“特性债务”——那些曾经有效但随着模型进化已不再必要的特性。对于任何构建生产 Agent 的团队，建议的实践是：每个主要特性都应是可独立关闭的，团队应定期验证每个特性的实际贡献。

AB 测试方法论：区分机制与目标

成熟的 Agent 产品会对自身行为进行严格的 AB 测试（即把用户随机分成两组，一组使用旧版本、一组使用新版本，通过对比两组的实际数据来判断改动是否有效）。一个设计精良的 Agent AB 测试案例展示了几个关键的方法论原则：

多臂而非二元。不仅对比 “有” 和 “没有”，而是设计多个渐进式变体（例如测试不同强度的提示词约束时，设置控制组和三个渐进更严格的实验组）。这种设计能揭示剂量-效应关系，帮助找到最优点。

区分机制指标和目标指标。这是最容易犯的错误——把你正在改变的东西当作优化目标。例如，如果你在测试“缩短 Agent 的计划文件长度”，计划长度是机制指标（你直接改变的东西），但它不是目标。真正的目标可能是“降低会话级成本”。缩短计划文件可能降低成本，但也可能因为计划不够详细而导致更多的编辑-检查-编辑循环，反而增加了总输出量。始终问自己：**我改变的东西（机制）和我真正关心的东西（目标）是同一个吗？**如果不是，以目标为准。

设置护栏指标。即使目标指标改善了，如果用户满意度下降、操作次数增加、或错误率上升，实验也应该停止。护栏指标是 “不能变差的底线”。

记录基线统计。包含样本量、分布百分位数、相关性分析（如 “拒绝率随计划大小单调递增”），为实验结果的解读提供必要的上下文。没有基线，你无法判断实验结果是否具有统计显著性。

双层特性开关系统

Agent 产品需要从第一天就设计特性开关（Feature Flag）基础设施——所谓特性开关，就是一个可以远程控制的开关，决定某项功能对用户是开启还是关闭，无需重新部署代码。它同时服务于三个目的：实验、渐进发布和紧急熔断。

编译时开关在构建阶段就将相关代码从产物中物理移除。内部专用的特性在外部构建中根本不存在——即使逆向工程也无法发现被移除的功能。这也是一种干净的消融机制：关闭某个特性不是在运行时跳过逻辑，而是对应的代码在物理上就不存在。

运行时开关的配置由服务端下发，并在本地磁盘缓存一份。设计上宁可读取到稍旧的缓存配置，也不能让 Agent 因等待网络请求而阻塞启动。具体的分组决策通过实验平台（如 GrowthBook）完成，用于分配 AB 测试组。一个关键的设计细节是：每个特性的曝光事件在每个会话中最多记录一次，避免重复记录污染实验数据。

对于 Agent 开发者的启示：特性开关不是调试工具，而是一等公民级的架构组件。

提示词敏感性评估

系统提示是 Agent 行为的核心“代码”，但它往往缺少与普通代码同等的版本控制和回归测试。OpenClaw 的做法是提供一个专用工具，能在指定的 git 版本上提取完整渲染后的系统提示——包含所有动态条件展开后的最终文本。这使得团队能精确回答：哪个 commit 改变了提示词？对评估集的影响是什么？

对于任何 Agent 团队，建议的实践是：(1) 系统提示应该是可确定性渲染的（给定相同的配置输入，永远产生相同的输出）；(2) 建立提示词的版本化快照机制；(3) 每次提示词变更都应在评估集上运行回归测试——就像代码变更需要跑 CI 一样。

隐私感知的分析作为评估基础

评估依赖好的数据，但 Agent 产品处理的往往是用户的敏感内容。OpenClaw 通过类型系统来解决这个矛盾：分析接口只接受经过特殊类型包装的值，类型名本身就是审计线索——它直白地声明“我已验证这不是代码或文件路径”。这种设计将隐私约束从文档化的规范变成了编译时强制执行的类型检查。

核心原则是：从一开始就把隐私约束设计进去，而非事后加装。如果你的分析系统无法安全地收集数据，你就无法有效地评估。隐私和评估并不对立——隐私感知的设计迫使你认真思考真正需要度量什么，这反而会催生更精准的评估指标。

从外部到内部：评估思维的转变

本节的核心信息是：前面几节教你如何从外部评估 Agent，本节揭示的是最好的 Agent 产品如何从内部评估自己。外部评估告诉你“Agent 有多好”，内部评估基础设施告诉你“哪个改变让它变好了”。消融实验发现哪些特性真正重要，AB 测试量化每个改变的影响，特性开关提供实验和回滚的基础设施，提示词敏感性评估将系统提示纳入 CI 体系，隐私感知分析确保数据收集的合规性。这五个组件共同构成了评估驱动的产品工程——不是偶尔做一次评估，而是将评估嵌入到每一次产品决策中。

仿真环境：从评估到后训练的桥梁

评估的终点不是打分，而是改进。本章已经展示了改进的两条路径：调整 Harness（从 Benchmark 报告到系统改进）和把评估嵌入产品工程（内部评估基础设施）。而改进的最强形态是训练——当目标从“评估现有能力”扩展到“培养新能力”时，特别是通过第七章讨论的后训练技术，评估环境就需要演化为仿真环境：一个能让 Agent 反复练习、自动打分的虚拟操场。仿真环境与评估环境的核心区别在于：交互频率远高（数百万次 vs 数千次）、需要随机化（防止死记硬背特定配置）、以及必须提供即时反馈。从应用领域看，仿真环境分为数字环境（信息处理任务）与具身环境（物理世界感知与操作）两大类。

这座桥梁的两端是这样接起来的。评估侧已经积累的资产可以近乎无缝地转成训练信号：一套定义清晰的 Rubric 或验证器，本质上就是一个可验证奖励（RLVR，Reinforcement Learning with Verifiable Rewards）的奖励函数——判分脚本直接就是奖励脚本，测试是否通过、状态是否达标，既是评估的判据，也是强化学习的回报。但训练会提出评估阶段不必操心的新要求。其一是可靠的 reset 语义：训练要跑数百万个 episode（一个 episode 即一次从初始状态到任务结束的完整交互回合），每个 episode 都必须能把环境重置到一个确定、干净的初始状态，否则梯度信号会被上一轮的残留状态污染。其二是远高于评估的吞吐：评估几千次就够出结论，训练则要在可接受的墙钟时间内喂给模型上百万次交互，环境的并行度和单实例开销直接决定训练是否可行。这两点——奖励函数化的验证器、面向训练的 reset 与吞吐——都将在第七章展开。

数字环境方面，AWorld 框架为 GAIA 任务构建了可控的 MCP 服务器沙盒，提供 26 个 MCP 服务器、涵盖 126 个工具函数，避免直接访问真实 API 带来的封禁和不可控副作用。所有工具调用可重放、可审计。AWorld 的分布式架构将传统串行执行的 7695 秒缩短到 525 秒（14.6 倍加速），环境的无状态设计使每个实例完全独立，支持高效并行。

具身环境方面，RoboTwin2 基于物理引擎构建双臂操作任务，环境随机化物体位置、朝向和外观以提升泛化能力。观测空间包括多相机视觉和关节状态，通过动作分块（Action Chunking）——模型一次规划多个连续动作——实现实时控制（详见第九章）。OSWorld 通过虚拟机快照实现可重置性，AndroidWorld 聚焦移动应用自动化。无论数字环境还是具身环境，仿真环境同样需要第四章讨论的隔离执行环境与虚拟身份机制（VM/容器隔离、住宅代理、Human-in-the-Loop 认证、共享文件系统），此处不再重复。

实验 6-13 ★★：配置 OpenVLA 与 RoboTwin2 的具身智能环境

搭建机器人操作的仿真环境。阅读 ch7/SimpleVLA-RL 和 OpenVLA 文档，理解视觉-语言-动作模型的架构（视觉编码器 + 语言模型 + 动作解码器端到端整合，图像和文本投影到共享语义空间）。配置 RoboTwin2 环境，理解观测空间（三视角 RGB + 14 维关节状态）和动作空间（14 维控制向量）。研究 move_can_pot 中的环境随机化机制和空间约束逻辑。运行预训练模型评估，记录成功率、完成时间和失败模式，重点关注动作分块机制的影响。

保真度权衡与领域随机化

高保真环境能更好地迁移到真实世界，但计算开销大。保真度的另一维度是随机化程度：适度随机化能提升泛化能力，过度随机化则会让任务变得过于困难。**领域随机化（Domain Randomization）**是缩小仿真与现实差距（sim-to-real gap）的关键技术：在物理参数、视觉外观、传感器噪声等方面引入大范围随机变化——好比在各种光照和角度下都练习过抓取，到了真实环境也不会因为光线变化就失手。在数字环境中，sim-to-real 表现为界面渲染、响应时间等方面的差异，可通过引入延迟和失败的随机化来缓解。

[^re-bench-2025]: Wijk, Hjalmar, et al. RE-Bench: Evaluating Frontier AI R&D Capabilities of Language Model Agents against Human Experts. arXiv:2411.15114, 2025.

本章小结

本章围绕一个核心问题：怎么判断 Agent 变好了还是变差了？从定义成功标准和区分 Pass@k、Best@k 与 Pass consecutive@k，到搭建可复现的测试环境、设计经得起泄漏考验的数据集、让 LLM 担任评判者并对失败轨迹做可审计的归因，最后用评估结果驱动模型选型和迭代，这条链路的每个环节都会影响结论的可信度。

轨迹前缀边界评估进一步说明，获得一条信息和正确将它用于当前决策是两种不同能力：端到端回归保证基本任务不退化，trajectory prefix 边界集则直接检查作用域判断、当前指令覆盖、澄清和危险动作前确认。用户记忆只是这一通用方法的一个案例。生产级 Agent 的评估不是偶尔做一次的考试，而是从真实 bad case 中持续生成回归任务和边界任务的验证系统。

核心方法论：观察→假设→实验→验证→新认识→新假设，使 Agent 工程从经验驱动的 “炼金术” 转向数据驱动的科学工程。

本章介绍的评估体系形成一个完整闭环：评估环境提供自动化的测试基础设施 → 评估数据集定义端到端任务和 trajectory prefix 边界 → 自动化评估方法（确定性验证器、LLM-as-a-Judge 与 Rubric）对 Agent 表现打分并生成失败归因 → Benchmark 与 bad case 分析揭示改进方向 → 系统改进修复问题 → 更新评估环境和数据集，开始新一轮迭代。

本章建立的评估体系不仅服务于当前系统的优化，也为后续两章提供关键基础。第七章把评估环境和数据转化为模型后训练的输入；第八章则把生产轨迹的多维评价转化为知识、指令、程序的更新。

思考题

1. ★★ LLM-as-a-Judge 使用语言模型评估语言模型的输出。这种 “自我评估” 是否存在系统性盲区——比如模型可能一致地给某种风格的回答打高分，而这种偏好与人类评判不一致？如何检测和校正这种偏差？
2. ★★★ 评估数据集的 “防泄漏” 设计至关重要。但在开源生态中，benchmark 数据一旦公开，很快就会被纳入训练数据。这场 “猫鼠游戏” 有终局吗？设计一种从根本上抵抗数据泄漏的评估方法。
3. ★★ Scale AI 的四准则（基于专家指导、全面覆盖、标准重要性权重、自包含评估）旨在消除评估的主观性。但某些任务维度（如 “回答是否有帮助”“语气是否恰当”）天然具有主观性。如何为这些主观维度设计可靠的 Rubric？
4. ★★ τ-bench 通过模拟真实用户行为来评估 Agent。但模拟用户本身也是一个 LLM——它可能系统性地低估某些边缘场景（如情绪激动、表达不清的用户）。如何验证模拟用户本身的质量？
5. ★★ 配对比较（Bradley-Terry 模型）假设偏好是传递的（如果 A > B 且 B > C，则 A > C）。但人类偏好经常违反传递性。在 Agent 评估中，非传递偏好可能出现在哪些场景？这如何影响排名的可靠性？
6. ★★ 本章区分了 Pass@k 的能力上限与 Pass consecutive@k 的业务可靠性。对于一个单次成功率只有 60% 的 Agent，怎样结合任务的失败成本、重试成本和副作用，决定应该报告哪个指标、取多大的 $k$？
7. ★★ 本章提出 “观察→假设→实验→验证” 的科学方法。但在实践中，Agent 的行为空间巨大，验证一个假设可能需要数百次评估运行。如何在有限计算预算下最大化评估的信息量？
8. ★ AndroidWorld 小实验中，完整元素树把成功率从 25% 提高到 100%，却把 token 用量推到 2.498 倍；精简后成功率不变，token 降到对照组的 0.506 倍。怎样设计一套自动裁剪规则，既删掉无语义的 UI 节点，又不误删对可访问性、状态验证或后续操作有用的信息？
9. ★★ τ-bench 的用户模拟采用了 “渐进式信息透露”——不一次性提供所有信息，而是根据 Agent 的提问逐步透露。这种设计如何影响评估结果？如果模拟用户的信息透露策略与真实用户差异较大，评估结论还可靠吗？

---

---

模型后训练

本书的核心公式是 Agent = LLM + 上下文 + 工具。本章聚焦于优化 LLM 这个“大脑”——通过后训练让模型更好地利用上下文和工具，从而提升整个 Agent 系统的能力。第六章结尾指出，评估体系与仿真环境是后训练的两块基石：评估环境为训练提供练习场，评估指标为训练定义目标。本章就建立在这两块基石之上，讨论如何真正改动模型权重，把能力沉淀进参数。

本章面向完全没有强化学习或模型训练背景的读者。我们不预设你懂梯度、懂策略优化，而是从“一个模型是怎么被训练出来的”这件事本身讲起，把每一步的目的、原理和它解决的问题都讲清楚。读完这一章，你应该能回答：模型的能力在哪些阶段形成、每一步在做什么、这些阶段通常如何组合、在什么条件下顺序可以不同，以及在自己的项目里该在哪一步下功夫。

先建立一张最重要的地图：现代模型的能力开发通常分为三个阶段。 预训练打地基，SFT 与 RL 则是根据目标、基础模型和输出要求选择或组合的后训练阶段：

1. 预训练（Pre-training）：在海量互联网文本上做“预测下一个词”的训练。这一步让模型学会语言规律、世界知识和基本推理，就像一个人读完了图书馆里的所有书——博学，但还不会好好回答问题。这是最贵的一步（动辄数千万美元），也是能力的地基。
2. 监督微调（SFT，Supervised Fine-Tuning，即用标注好的 “输入—输出” 对来训练模型，类似老师给出标准答案让学生照着学）：用几千到几万条 “问题—标准回答 ”的示范数据，教会模型 “该用什么格式、什么风格、什么流程来回答”。这一步把博学的模型变成一个听得懂指令、输出规整的助手。它便宜、快、稳，是当前几乎所有部署模型都会经过的一步。
3. 强化学习（RL，Reinforcement Learning，即让模型反复尝试、根据结果好坏给奖惩来改进行为，类似训练小狗：做对了给零食，做错了不给）：不再直接模仿标准回答的 token，而是让模型自己去试，把做得好的行为的概率调高、做得差的调低。当奖励、数据和环境设计得当时，这一步可以让模型在没见过的情况下做出更好的决策——也是本章篇幅最大、最需要工程功力的一步。

一个直觉类比：预训练是 “读万卷书”（积累知识），SFT 是 “老师手把手教标准解法”（模仿示范），RL 是 “自己下场做题、根据对错反复打磨”（试错提升）。

本章有两条贯穿始终的主线：

• 主线一：在本章的对照实验中，SFT 更容易记住示范，而 RL 表现出更好的泛化。 在 GeneralPoints 和 V-IRL 的相同任务、模型和预算设置下，SFT 对训练答案过拟合，而 RL 在分布变化的测试中更容易学到可迁移策略。这是这些实验条件下测得的结果，不是 SFT 与 RL 的普遍属性：数据足够多样、正则化得当时 SFT 也能泛化，奖励或环境有偏时 RL 也会过拟合。本章用“SFT 记忆，RL 泛化”概括这些实验，并在 7.1 节解释两种优化目标为什么可能产生这种差异。
• 主线二：数据和环境，比算法更重要。 这是工业界最反直觉、也最值钱的一条经验。现成的 RL 算法（PPO、GRPO 等）你知道怎么用就够了，真正决定成败的是两件事：仿真环境（模型练习的场地够不够真实）和训练数据（示范和奖励信号的质量够不够高）。很多场景下，只要 SFT 的数据质量到位，你甚至根本不需要做 RL。本章会不断把你的注意力从“调哪个算法”拉回到“数据和环境做对了没有”。

阅读指引：本章内容按读者背景分为两条路径：

• Agent 应用开发者（不需要自己训练模型）：先读开篇的“预训练、SFT、RL：三阶段全景”建立全局认知，然后可以跳过紧随其后的两节 [可选阅读]（经典 RL 与预训练背景），从 SFT 一节继续。重点关注“SFT 与 RL 的本质区别”“何时选择 SFT，何时选择 RL”的决策框架，以及“数据与环境比算法更重要”的判断——这些认知会影响你在 Harness 工程中的设计决策（什么时候靠 prompt 解决，什么时候值得微调）。
• 模型训练工程师：从头顺序阅读，两节 [可选阅读] 提供强化学习和预训练的完整背景，后续实验提供可复现的训练方案。

预训练、SFT、RL：三阶段全景

引言给了三阶段的地图，这一节把每一步的机制讲透。三个阶段用的数据、优化目标、代价各不相同，理解它们的异同，是读懂整章的钥匙。表7-1 先给一个总览，随后逐项展开。

表7-1 模型能力炼成的三个阶段

阶段	用什么数据	优化目标	学到什么	典型代价
预训练	海量原始互联网文本	预测下一个词	语言规律、世界知识、基本推理	极高（数百万～数千万美元）
SFT	几千～几万条“输入—输出”示范对	预测下一个词（只在回答上算损失）	指令遵循、输出格式、风格、流程协议	低（几小时～几天）
RL	任务、环境 + 奖励信号（参考答案可选）	最大化期望奖励	可迁移的决策策略、探索出的新解法	高（常是 SFT 的几十～上百倍）

预训练在做什么：预测下一个词

现代大模型的全部“智能”，都建立在一个简单到令人意外的任务上：预测下一个词（Next Token Prediction，NTP）。

给模型看一段文本的前半部分，让它猜下一个 token 是什么。比如输入“中国的首都是”，模型应该给“北京”很高的概率。模型每猜一次，就把自己的预测和真实的下一个 token 比较，差距（称为损失 Loss）越大，就越用力地调整参数，让下次在类似上下文里猜得更准。在几万亿 token 的互联网文本上反复做这件事，模型被迫学会了语法、事实、逻辑乃至基本推理——因为要在海量语境里持续猜对下一个词，没有捷径，只能真正“消化”文本里的规律。

有一个关键点要记住，它会一路贯穿到 SFT 和 RL：模型的输出本质上是一个概率分布。给定前文，模型对词表里每一个可能的 token 都给出一个概率。所谓“训练”，归根结底就是调整这个概率分布——让我们想要的 token 概率更高、不想要的更低。三个阶段的区别，只在于“想要什么”，以及“用什么信号来定义想要”。

预训练之后，模型博学却不好用：你问它问题，它可能续写出更多问题，而不是回答——因为互联网文本里，一个问题后面常常跟着的是另一个问题。它还没学会“被提问时应该回答”这个协议。

SFT 的本质：换了数据的“预测下一个词”

这是本章第一个需要打通的关键认知：SFT 在数学上和预训练是同一个任务——都是预测下一个词、最小化同一个损失函数。 很多初学者以为 SFT 是一种全新方法，其实不是。SFT 与预训练的差别只有两点：

1. 数据不同。 预训练用原始互联网文本（无结构、什么都有）；SFT 用人工精心准备的“输入—输出”对，格式统一为“用户提问 → 理想回答”。模型在这些示范上继续做“预测下一个词”，于是把“被提问时该怎么组织回答”这个协议学了进去。
2. 损失只算在“回答”上（loss masking，损失屏蔽）。 一条 SFT 样本包含问题和标注回答两部分。我们不希望模型学“怎么提问”，只希望它学“怎么回答”，所以计算损失时把问题部分的 token 屏蔽掉，只对回答部分回传梯度。这是 SFT 在工程上与预训练唯一实质性的区别。

理解了这一点，也就能看出 SFT 为什么会在有限示范上表现出记忆倾向：它的优化目标是让标注回答里每一个 token 的概率尽可能高，也就是尽量复现示范。对目标明确、格式固定的任务，这种方法极其高效（几千条样例就见效）；但当数据覆盖面和多样性不足时，模型可能对示范中的表面模式或捷径过拟合，在分布变化后性能下降。

一句话概括 SFT 的本质：用极高的样本效率，把一套稳定的“输入→输出”映射与协议固化进参数。 它固化的是“格式、风格、流程”这类协议性知识（该怎么说、怎么做），而非大量事实性知识（知道什么）——后者要靠预训练或 RAG。

训练成本：LoRA 参数高效微调。上面 SFT 和后面的 RL 都要更新模型参数，而全参数微调对显存的要求很高（要为数十亿参数都存梯度和优化器状态）。LoRA（Low-Rank Adaptation，低秩适配）是最常用的省钱办法：不动原始的大权重矩阵，只在旁边挂一个很小的“补丁”（低秩矩阵）来学习任务，参数量仅占原始的 1%–5%，却能接近全参微调的效果。因为原权重被冻结，LoRA 对基座已有能力的扰动也更小，灾难性遗忘的风险更低。几条经过验证的实践经验[^ch7-1]：必须把 LoRA 应用到所有主要权重矩阵（尤其参数占比最大的 MLP 层），只加在注意力层会掉点；最优学习率约是全参微调的 10 倍（SFT、RL 都成立，是个非常实用的迁移规则）；SFT 用中高 rank（64–256），RL 因每轮信息量很小、用小 rank（8–32）甚至 rank=1 就够。部署时一台推理服务器可同时加载多个 LoRA adapter 做多租户服务。本书把 LoRA 当作贯穿所有后训练方法的工程默认项，不再单独展开。

什么时候需要先 SFT 后 RL

预训练先提供语言与知识的地基。真正需要解释的是：在什么条件下 SFT 应该放在 RL 之前？

答案藏在 RL 的工作方式里。RL 策略不直接模仿参考回答的 token，而是用奖励信号评估模型自己生成的回答；奖励计算仍可以使用参考答案或偏好数据。可要判断好坏，首先得能把模型的输出解析出来：如果任务要求输出一段 JSON 或一次工具调用，而模型吐出的是一团格式混乱的文本，奖励函数根本无从算起（连“成功还是失败”都判断不了），RL 也就无从学起。

所以在结构化输出不稳定的设置中，SFT 可以先扮演“把话说利索”的角色：用少量示范让输出格式稳定、能被可靠解析，RL 才有一个能打分的起点。这是业界稳健的**“先 SFT 后 RL”两阶段范式。在这种设置中跳过 SFT 直接做 RL，输出不稳定可能让奖励信号变成噪声、导致训练失败。借用中国画的说法：SFT 先把“形”（格式、结构）立起来，RL 再追求“神”（策略、泛化），即先形后神**。

一个重要边界：“必须先 SFT”是在“较小基础模型 + 严格结构化输出”的设定下成立的。实验 7-11 会看到，Llama-3.2-Vision-11B 这个量级不经 SFT 直接 RL 会完全失败。但若基础模型足够强，它可能一上来就能产出够格的输出，从而跳过 SFT——DeepSeek-R1-Zero 就证明了强基模可以直接 RL 成功，自行涌现出反思与长链思考。代价是输出可读性差、中英文混杂，所以 DeepSeek 最终仍在 R1 里加回“冷启动 SFT”，把“形”重新立稳。R1 从 Zero 到冷启动的往返，正是“先形后神”的最好注脚。

SFT 与 RL 的本质区别

前面用“SFT 记忆、RL 泛化”概括了本章的对照实验。现在解释这种倾向为什么可能出现，关键在于两者的优化目标不同：

• SFT 最大化标注回答的概率。 每个训练样本都用极大似然推动模型复现示范。多样且有代表性的示范可以教会模型可泛化的特征，但示范或 prompt 缺乏多样性时，模型也可能对表面模式或捷径过拟合。GeneralPoints 的有限示范把 J/Q/K 都当作 10，模型因此在测试值变化时性能下降。
• RL 最大化期望奖励。 模型探索多条路径，并提高高奖励路径的概率。当奖励忠实反映目标、探索也足够时，模型可能发现示范中没有的可迁移策略。GeneralPoints 中，重新执行计算过程而不是套用固定值，在分布外测试中取得了更好表现。反过来，奖励或环境有偏时，RL 同样可能对捷径过拟合。

表7-2 SFT 与 RL 的本质对比

维度	SFT（监督微调）	RL（强化学习）
优化目标	最大化标注答案的概率（极大似然）	最大化期望奖励
训练信号	标注回答的逐 token 监督	策略生成的回答或轨迹 + 结果级或步骤级标量奖励
数据形态	“输入—输出”示范对	任务、环境 + 奖励信号（参考答案可选）
直接优化压力	模仿示范中的映射与协议	强化能够获得奖励的行为与策略
分布漂移下	取决于示范覆盖和正则化；本章有限示范实验出现过拟合	取决于奖励、环境和探索；本章实验中迁移更好
样本效率	高（几千条见效）	低（常是 SFT 的几十～上百倍）
训练稳定性	高、收敛快	低、易震荡，需要小心调
最适合	固化格式/风格/流程、有高质量示范、环境稳定	需泛化到新场景、探索最优策略、标注成本过高

从概率分布看，SFT 与 RL 还有一组重要差别。一个问题往往存在多类合理回答，每一类都对应概率分布中的一个“峰”。极大似然 SFT 会逐条学习示范，因此常表现出 **mass-covering（覆盖式）**倾向：尽量覆盖训练数据中出现过的多个模式。RL 则按奖励重新分配概率，配合常见的反向 KL 约束时更容易表现出 **mode-seeking（寻峰）**倾向：把概率集中到少数高奖励峰上，而不是平均复现所有示范。

这一区分解释了两者的典型特点：SFT 擅长覆盖多种已知写法，RL 擅长从候选行为中寻找高奖励策略。但它们不是不可改变的固有属性；示范分布、奖励函数、KL 方向与系数、熵正则和采样温度都会影响最终是保持多样性还是收缩到少数模式。

后训练还会塑造模型何时行动。 以 Coding 模型为例，GPT 系列与 Claude 系列经常表现出不同的默认行动阈值：前者可能先读更多仓库信息再修改，后者可能用较少文件完成定位、先实现再借测试反馈修正。这不是把模型拟人化成“谨慎”或“有直觉”，而是参数中的策略在估计：多读一个文件的预期价值，是否还高于提交当前补丁并验证的预期价值。若 SFT 示范反复包含广泛调查后才编辑的轨迹，模型就会模仿较高的行动阈值；若 RL 的过程或结果奖励持续认可快速定位、尽早进入可验证循环，概率质量就会向较早行动的轨迹集中。第六章实验 6-8 在完全相同的中性 Coding Harness 中换模，确实测到这种差异随模型变化，说明 Harness 无需强制流程，模型自身也会携带稳定的工具使用策略。Harness 可以调节它，但行为的主要来源可以位于后训练后的模型参数中。由于厂商并不公开完整数据与奖励配方，这个实验能证明的是模型侧的行为差异，不能据此断言某一种具体的私有算法造成了它。

在线反馈给了模型探索示范之外策略的机会。 固定数据集上的 SFT 使用示范提供的直接训练信号，但仍可组合预训练知识，对示范中没有的输入进行泛化。在线 RL 则让模型按当前策略生成回答、接收环境反馈，从而直接评估示范之外的候选行为。这并不自动保证更高上限：结果取决于基础模型、示范覆盖、奖励忠实度、探索和优化稳定性。在线/离线与更严格的在轨/离轨（on-policy / off-policy）将在奖励与蒸馏部分用到。这里先看在线反馈提供的三个机会：

• 其一，可以评估固定示范之外的候选。 SFT 的直接监督来自数据中记录的回答；RL 还可以强化奖励函数能够评分的新行为。实验 7-13（SimpleVLA-RL）中的“推切”动作从未出现在人类示范里，说明模型有机会发现示范之外的策略。但奖励无法识别的质量学不到，探索不到的策略也发现不了。
• 其二，可以利用“验证比生成容易”的任务。 SFT 需要先写出正确答案或高质量轨迹；RL 只需要可靠地判断答案质量。数学答案可以对照，代码可以测试，定理证明可以由验证器检查。这种不对称是 RLVR 的优势，但验证器不完整时也会导致奖励黑客。
• 其三，可以在当前策略实际访问的状态上训练。 离线模仿存在经典的协变量漂移（covariate shift）：策略偏离示范、进入数据中没有的状态后，可能缺少恢复信号。在特定的序列模仿学习设置中，误差最坏可随轨迹长度 $T$ 近似按 $T^2$ 累积，而在线数据聚合可把它降到约 $T$。本章后面的 On-Policy Distillation（7.12 节）把这种在线匹配与 SFT 的稠密监督结合起来。

打个比方：SFT 细致学习已有地图，RL 则可以拿着奖励这枚指南针探索地图外的候选路线。 地图或指南针不准都会迷路。因此许多系统先用 SFT 建立稳定起点，再在奖励与环境足够可信时加入 RL。

有了这张全景图，后面每一节都能对号入座。紧接着的两节 [可选阅读]——“从经典 RL Agent 到现代 Agent”和“模型预训练基础”——为想深入的读者补上强化学习与预训练的背景；只想直接上手后训练的读者可以跳过它们，直接从 SFT 一节开始。

从经典 RL Agent 到现代 Agent [可选阅读]

Agent 与环境的交互

强化学习（Reinforcement Learning, RL）的核心在于学习如何根据当前情境选择动作，以获得最大的累积奖励（Cumulative Reward）。想象一个学下棋的 AI：每走一步就是一个动作，赢棋得到正奖励、输棋得到负奖励，累积奖励就是整盘棋的总收益。Agent 和环境持续交互：每一步，Agent 观察当前状态，选择一个动作，环境产生新状态并给出奖励。

为了更直观地理解这种交互，下图展示了标准 RL 循环——Agent 在每个时间步观察环境状态，输出动作，环境据此给出奖励并转移到新状态。

交互产生轨迹——即“状态→动作→奖励→新状态→动作→奖励...”的完整记录，策略的优劣最终体现在轨迹质量上。**价值函数（Value Function）**回答的是这样一个问题：“如果我现在处于这个状态，按照当前策略一直行动下去，最终总共能获得多少奖励？”这就像一位经验丰富的棋手看到一个局面时，不需要算到最后一步，凭直觉就能估计出这盘棋的胜率。Agent 与环境的边界遵循一个简洁的原则：凡是 Agent 无法任意改变的，都属于环境。

强化学习区别于监督学习（需要标注正确答案）和无监督学习（发现数据中的隐藏模式）的两个独特特征是试错搜索（Agent 必须自己摸索哪些动作好，没有老师直接告诉正确答案）和延迟奖励（动作的影响可能在多步之后才显现，比如一步好棋的价值到终局才看得出来）。由此还带来独特的探索与利用权衡（Exploration-Exploitation Tradeoff）：一直走熟悉的路，学不到新东西；一直乱试，永远到不了终点。

强化学习系统包含五个核心要素：

• 动作空间：定义 Agent 可以采取的所有行动集合。动作可以是离散的（如棋类中“走哪一步”，选项有限）或连续的（如机器人“关节转多少度”，是一个连续数值）。
• 策略：Agent 的行为准则，规定在给定状态下应该怎么做。策略可以很简单（一张查找表：看到状态 A 就执行动作 X），也可以很复杂（一个深度神经网络）。
• 奖励信号：环境给出的即时反馈。但 Agent 的目标是最大化长期而非即时奖励——这个区别至关重要，就像投资不能只看今天涨跌，要看长期回报。
• 价值函数：估计从某个状态出发，未来总共能获得多少累积奖励，帮助 Agent 在没有即时反馈时做出明智决策。过去六十年 RL 研究最重要的认识之一就是价值估计的核心地位。
• 环境模型（可选）：预测环境对动作的响应。有了环境模型的方法称为基于模型的方法（先学会预测环境怎么变化，再据此规划），没有环境模型的称为无模型方法（不去预测环境，直接从经验中学习）。

表7-3 对比了各种 Agent 系统的关键组成要素，揭示了 Agent 概念的普遍性，并帮助读者看到传统 RL Agent 与现代 LLM Agent 在动作空间上的差异。

表7-3 不同 Agent 系统的关键要素对比

Agent 类型	环境	动作空间	奖励信号
新生小羚羊	地形、重力、身体姿态	连续高维（各肌肉群收缩）	平衡(+)、跌倒(-)
扫地机器人	房间布局、电量	离散（方向、吸尘、充电）	清洁面积(+)、电量耗尽(-)
国际象棋大师	棋盘状态、时间限制	离散有限（合法走法）	赢棋(+1)、输棋(-1)
客户服务 Agent	对话历史、知识库	变长组合式（思考、说话、API 调用）	问题解决(+)、处理时间(-)
代码助手 Agent	需求文档、代码库	变长组合式（思考、搜索、编辑、执行）	测试通过(+)、引入 bug(-)

表格揭示了一个重要洞察：棋类、Atari 等典型环境使用预定义的有限离散原始动作，机器人控制则使用维度和物理边界确定的连续动作。基于 LLM 的客户服务与代码 Agent 用有限的 token 和工具调用组合出变长动作序列，因此很难一次性枚举所有可能序列，并且可以利用“内部思考”提升能力。

两种动作表示：经典 RL 设置与 LLM 的变长策略

这里比较的两类设置，最显眼的差异在于动作的表示方式。MDP 本身可以表示有限、无限、离散或连续的动作空间。本节的棋类与 Atari 示例使用有限离散的原始动作，机器人控制使用有界连续动作；LLM 策略则用有限 token 词表和工具 schema 构造变长序列。这种组合式表示会显著影响算法设计、样本效率和泛化方式。下面分别展开。

基础示例：MDP 与表格 Q-learning。

MDP（Markov Decision Process，马尔可夫决策过程）是强化学习的数学框架，定义了状态、动作、奖励等核心要素。它的核心假设是马尔可夫性质：未来只取决于当前状态，而当前状态必须包含决策所需的全部历史信息。以国际象棋为例，状态不仅包括棋子位置，还应包括轮到哪方、王车易位权、吃过路兵权，以及五十步规则和重复局面判定所需的信息。状态定义充分时，无需每次重读完整棋谱；若观测没有包含必要历史，则应把历史纳入状态，或使用部分可观测模型。

本节讨论的典型 RL 环境使用预先定义的动作空间。围棋 361 个落子位置虽大但有限，国际象棋动作仍可枚举，Atari 游戏通常只有几个到十几个离散原始动作。机器人 Agent 使用连续但有界的动作空间：关节角度、速度、抓取力度是连续值，但有明确物理边界，维度由机器人自由度决定。

有限离散动作便于逐一评估候选；当状态与动作数足够小时，表格 Q-learning 可以直接存储价值，更大的 Atari 或棋类状态空间则需要把函数近似与搜索结合起来。连续动作 MDP 不能枚举所有动作，通常使用策略梯度或 actor-critic 等方法近似策略与价值函数。本节经典示例与 LLM 策略的另一个差异，是它没有预训练知识，只从试错开始学习。

在这个框架下，最基础也最重要的算法之一是 Q-learning。它为每个“状态-动作”组合维护一个价值估计：在状态 s 下采取动作 a，之后一直按最优策略行动，总共能拿到多少奖励？直觉上，一个动作好不好，取决于它带来的即时回报，再加上“它把你带到的下一个状态有多好”。

把这个直觉写成等式，就是 RL 教科书里大名鼎鼎的贝尔曼方程（Bellman equation）的核心递归关系：一个动作的真实价值 = 这一步拿到的即时奖励 + 到达下一个状态后能拿到的最大未来价值：

$$Q^(s, a) = r + \gamma \max_{a'} Q^(s', a')$$

其中 $r$ 是即时奖励，$s'$ 是执行动作后到达的下一个状态（这里为直觉起见写成确定性形式，随机环境下需对下一个状态 $s'$ 取期望），$\gamma \in [0, 1)$ 是折扣因子——它决定 Agent 有多看重未来：$\gamma$ 越接近 1 越重视长期回报，越接近 0 越只顾眼前。前文反复出现的“累积奖励”，正是各步奖励按 $\gamma$ 逐步折扣后的总和 $\sum_{t} \gamma^{t} r_t$。算法每次行动后，把旧的估计值往“实际发生的结果”方向微调一点——这种“用一步实际结果修正旧估计”的范式叫时序差分学习（Temporal-Difference Learning, TD learning），经过成千上万次试错，估计值逐渐逼近真实值。

以下两张图分别展示 Q-learning 在网格世界中的探索过程与 Q 值的逐步收敛。

Q-learning 属于一种离轨策略（Off-Policy）方法——它可以用不同于目标策略的探索策略所生成的数据来学习最优策略，但仍要求充分覆盖相关状态—动作对，并满足适当的学习率与收敛条件；它并不是对任意数据分布都能自动收敛。在轨/离轨策略的严格定义与在 LLM 后训练中的对应关系，见后文“强化学习算法比较”一节。

实验 7-1 ★：Q-learning 在寻宝游戏中的表现

为了验证 Q-learning 的特性与局限，我们设计了一个寻宝游戏环境。这个环境包含几个关键挑战：隐藏机制要求 Agent 自行发现钥匙和门的对应关系、武器效果和物品合成规则；多步依赖意味着完成任务需要正确的动作序列（最优解 11 步）；稀疏奖励意味着只有关键动作和最终胜利才有显著奖励，中间大部分步骤得不到任何反馈。

Q-learning Agent 使用标准参数配置，采用 ε-贪婪探索策略（大部分时间选当前最优动作，偶尔随机尝试，随着训练推进逐渐减少随机探索的比例）。

学习曲线展现典型特征（episode 指一局完整的游戏，从开局到通关或失败算作一次）：

• 前 1000 episodes：0% 胜率，Q 表仅 124 个状态，Agent 在盲目探索
• 前 5000 episodes：依然没有稳定胜利，Q 表 133 个状态
• 7000-8000 episodes：胜率从 34% 逐步升至 96%
• 10000 episodes：100% 胜率，Q 表 145 个状态，找到 11 步最优解

整个训练仅需不到 10 秒（仿真效率极高），但需要将近 10000 次完整尝试。这展示了本实验中无先验知识、采用 ε-贪心探索的表格 Q-learning 的特征：需要大量随机探索才能偶然走通完整路径，价值信号的传播很慢，必须反复强化。

在游戏模拟器中，10000 轮试错只需 10 秒，代价微乎其微。但在真实世界的 Agent 场景中——每次打电话有成本、每次操作浏览器有延迟、每次错误决策可能造成不可逆后果——10000 次试错是完全不可接受的。使用预训练 LLM 策略的一个原因，正是可以利用已有知识，在更少的环境交互中做出有效决策。

这个无先验知识的表格 Q-learning 实验有三项局限：简单任务也需要大量交互，样本效率低；一个环境中的表格值难以直接迁移到另一个环境；每个新任务都要重新探索。这些不是 MDP 数学框架本身的限制。函数近似、迁移学习和基于模型的 RL 可以处理更复杂的状态和知识迁移，不过与预训练 LLM 相比仍可能需要大量环境交互。

基于预训练 LLM 策略的 Agent。

大语言模型在 Agent 的动作表示与初始化方式上带来了重要的实用变化。

经典 RL 也可以把内部计算或信息收集建模为状态与动作。LLM 的实用变化不是第一次允许“思考”，而是预训练语言策略能够用变长 token 序列表示内部计算，并与外部行动由同一策略生成。思考 token 不直接改变外部世界，却可以提高最终行动质量。于是 Agent 的动作表示不仅包括“做什么”，还包括“想多久、想什么”。

最关键的实用创新，是把思考 token 作为特殊动作纳入策略输出空间。典型传统 RL 环境主要使用移动、攻击、拾取等改变环境状态的原始动作，尽管内部计算也可以在 MDP 或层级策略中建模；在 LLM Agent 中，内部思考成为学习到的语言动作空间的核心组成部分。它不直接改变外部环境，也不立即获得环境奖励，但能在 token 成本和上下文上限内表达多种计算路径。

这种变长组合式动作比原始动作拥有大得多的搜索空间，因此很难在没有先验知识时从零学习。从零开始的 Agent 就像蒙着眼睛在沙漠里找宝藏。LLM 则从海量文本预训练中学到了人类留下的问题解决模式——数学问题常按“识别条件→回忆公式→逐步计算”，编程任务常按“理解需求→设计结构→实现细节”展开。预训练策略给结构化路径更高先验概率，显著压缩搜索空间。因此即使没有额外 RL，预训练 LLM 也能生成基本的思维链（Chain of Thought, CoT）。这些模式来自数学解题、代码注释、讨论回应等预训练语料，模型通过预测下一个 token 隐式学会“下一步思考应该长什么样”。

RL 后训练再用外部奖励教会 LLM 在特定任务中更有效地利用这些模式。语言结构不是单独的“内部奖励”，而是预训练策略的先验分布（prior）：训练数据中一致出现的“因为要把外币换算成美元，所以先查汇率”可能具有较高初始生成概率，而“因为要换算货币，所以先查天气”这类无关路径的概率较低。RL 在这个初始分布上用真实任务奖励重新调整各条路径的概率。

预训练语言策略使 LLM Agent 能够理解未见过的指令（零样本泛化），并用少量示范适应新任务（少样本适应），这与前述无先验知识的表格 Q-learning 设置形成鲜明对比。

从预定义原始动作扩展到变长组合式动作，是 AI Agent 范式的重要转变。LLM 的动作仍由有限 token 词表和工具 schema 定义，但内部思考、自然语言查询、程序代码、复杂 JSON 与多模态内容可以组合成数量爆炸的变长序列。代码解释器和搜索工具把这种表示连接到现实环境中的广泛任务与信息。这带来新的机会与挑战：Agent 可以组合基础工具处理未见任务，但也需要在巨大的组合空间里定义奖励并高效探索。

以 Kimi K3 这类面向工具调用和长链思考优化的模型为例，可以看到 LLM+RL 范式的典型方向：在大规模语言预训练基础上，通过后训练强化问题分解、工具调用和自我纠错能力。OpenVLA[^ch7-21]（详见第九章）则展示了 LLM 时代的 VLA（视觉-语言-动作）架构范式：视觉编码器处理环境观察、语言模型理解指令并推理、动作解码器生成控制信号，实现语言条件控制与跨任务泛化。需要澄清的是，OpenVLA 本身是在近百万条机器人演示轨迹上通过模仿学习（行为克隆）训练的，属于 SFT 性质而非 RL；真正把 RL 引入机器人、在这类 VLA 架构之上用奖励进一步优化的代表，是本章后面实验 7-13 的 SimpleVLA-RL。

姚顺雨在博客《The Second Half》[^ch7-2]中回顾了 OpenAI 探索之路的认知演变。第一阶段（2015-2016）算法中心主义：相信更好的算法才是关键，在 Atari 等标准环境取得进展，但换一个新环境就得从头训练。第二阶段（2016-2018）环境的重要性：Gym 标准化了各类任务，Universe 和 World of Bits 试图把整个互联网变成 RL 的训练环境，Dota 2 在特定复杂环境中追求超人表现。思路很清晰，但通用计算机使用和网页导航始终无法突破。

第三阶段（2018 至今）先验的觉醒：GPT-2/GPT-3 展示了语言预训练的强大力量，WebGPT、ChatGPT 证明这些先验知识可以转化为实用 Agent。最重要的发现是：先验知识可以通过与 RL 完全无关的方式获得。这是一个反直觉的真相：几十年来 RL 研究者的优先级可能完全颠倒了——不是算法 > 环境 > 先验，而是先验 > 环境 > 算法。

实验 7-2 ★★：传统 RL 与 LLM Agent 的对比研究

在同一个寻宝游戏中对比 Q-learning 与 LLM Agent（Kimi K3，维护最多 50 条经验的缓冲区）。结果令人震撼：LLM Agent 第一局就在 18 步内通关。

前期（有目的的探索）：拿起生锈的剑（“武器总比空手好”），系统探索地图，发现北门被锁后推理 “需要找钥匙”，转而探索储藏室，先后取得红钥匙与魔法水晶。中期（机制理解与主动合成）：理解 “钥匙自动使用” 规则，并预判生锈的剑不足以对付守卫，于是在第 8 步主动合成银剑。后期（执行与纠错）：持银剑向北，第 13 步击败强守卫，其间夹杂一两步无效尝试（重复挥剑/回退），最终在第 18 步取得巨龙宝藏。

这展现了语义理解与符号映射之间的根本差异。LLM Agent 理解了游戏的概念结构，每一步都有目的和逻辑支撑。而对 Q-learning 来说，“门”“钥匙”“剑”只是无意义的符号组合，只能通过大量统计学习慢慢发现它们之间的关系。

计算成本形成了一个有趣的悖论：Q-learning 跑 10000 局只需 10 秒，LLM Agent 一局却要 1-2 分钟。但在现实任务中，每次交互的时间、金钱和风险成本远超纯计算成本，所以单看 GPU 时间并不公平。更关键的洞察是：LLM Agent 的成功不是因为拥有更好的“学习算法”，而是因为携带了海量先验知识。当游戏规则变化时，Q-learning 需要完全重新训练，LLM Agent 却能通过推理直接适应。由此可以得出实用的设计原则：在仿真成本低、可大量重复的场景中，传统 RL 仍然有价值；在交互成本高、需快速适应的现实场景中，LLM Agent 的样本效率更为实际。

至于上下文适应、外部产物更新与参数更新如何协同，第一章已经给出概念地图，本章末尾的“完整图景”还会回到这个话题。本章的主线是其中的后训练——把难以由外部规则完整表达的能力写进模型参数。

模型预训练基础 [可选阅读]

要理解后训练技术为什么有效，需要先明白预训练建立了什么。后训练（SFT 与 RL）本质上是在预训练建立的表征空间内进行优化——预训练奠定的知识结构决定了后训练的天花板。因此，我们通过三个实验考察预训练的核心环节：从头训练小规模语言模型、扩展视觉能力、以及注入新语言知识。本节三个实验为辅助性内容，帮助读者建立对预训练（Pretraining，即在大规模数据上进行初始训练，让模型学会语言的基本规律和世界知识）的直觉。

语言模型训练一般遵循 “词元化 — 预训练 — 后训练” 三阶段流程。词元化（Tokenization）将文本切分为离散单元，比如“我喜欢编程”可能被切分为“我”“喜欢”“编程”三个 token——这些 token 就是模型处理文本的最小单位。预训练的任务概念上很简单：给模型看一段文本的前半部分，让它预测下一个 token 是什么。模型通过比较自己的预测与正确答案的差距（这个差距叫做损失（Loss），损失越小说明预测越准），不断调整自身参数。在海量文本上反复训练后，模型逐渐学会了语言规律、世界知识与基本推理能力。预训练完成后，模型能生成流畅文本，但输出缺乏结构、难以遵循指令。后训练通过 SFT（用标注好的输入-输出对训练）与偏好优化（如 DPO，让模型学会生成人类更偏好的回答）将其转化为实用助手。

实验 7-3 ★★：从头训练 LLM——算法改进的威力

以 MiniMind 2（一亿参数）为案例，在消费级 GPU 上完成完整训练流程。通过引入两项算法优化（QK Norm 和 Muon 优化器），收敛速度提升 3 倍，生成质量显著改善——实现成本极低，总训练约 14 小时，成本约 34 美元。

各训练阶段的效果：预训练后模型可以回答“世界上最高的山峰”等事实性问题，但格式不规范；SFT 后指令遵循与输出格式显著改善，能按期望方式组织答案；偏好优化进一步减少了事实错误与不自然表达。一亿参数的模型仍有明显局限（复杂问题容易出错），但启示是：在固定的小规模预算下，算法改进比单纯堆规模更具性价比。

实验 7-4 ★★：自己训练 VLM

VLM 将视觉感知与语言理解统一在一个模型中，核心挑战在于跨模态对齐——让“看到的”和“说出来的”对应起来。架构由三个组件构成：视觉编码器（如 CLIP，参数固定）提取图像的语义特征；投影层（轻量级，唯一从头训练的部分）充当视觉特征与语言模型之间的“翻译官”，将视觉特征映射到语言模型能理解的表示空间；语言模型生成描述文本。训练采用“冻结 LLM + 只训练投影层”的策略，以避免灾难性遗忘（Catastrophic Forgetting，即学了新技能后把旧技能忘了）；预训练对齐后再解冻 LLM，用高质量图像-描述对做 SFT，描述的详细程度与准确性显著改善。

本实验揭示了多模态模型训练的基本范式：复用单模态预训练成果，通过训练一个轻量投影层实现跨模态对齐——高效且可扩展，但投影层的表达能力有限，可能成为跨模态深层理解的瓶颈。同样的“视觉编码器 + 投影层 + LLM”骨架再向前延伸一步、让模型输出动作，就是第九章将展开的 VLA（视觉-语言-动作）模型。

实验 7-5 ★★：继续预训练学习新语言

以 Mistral 7B v0.3 为基础（主要用英语预训练，对韩语几乎没有理解能力），通过韩语维基百科继续预训练来注入韩语能力——在已完成预训练的模型上用新语言数据继续做无监督训练，模型已具备通用语言建模能力，只需适应新的数据分布，成本远低于从头训练。关键工程点是用混合数据（约 80% 韩语 + 20% 英语）缓解灾难性遗忘：目标语言占比过高会导致原语言退化，占比过低则学习效率不足。最后用韩语指令数据做 SFT，获得实用的韩语对话能力。本实验的结论会在本章末尾的完整图景中再次用到：要让模型记住大量新领域知识，靠的是继续预训练而非 SFT。

三个预训练实验共同揭示了一个规律：在预算受限时，算法改进与架构创新比单纯扩大规模更具性价比。更重要的是，预训练赋予模型的是描述性知识与语言建模能力，缺乏结构化的指令遵循和任务导向行为——这正是 SFT 需要填补的空白。

有了预训练的基础能力，下一步就是通过后训练把通用模型变成实用的 Agent。后训练的第一阶段是监督微调（SFT）。

SFT（监督微调）

7.1 节已经讲透了 SFT 的本质（换了数据、只在回答上算损失的 “预测下一个词”）。这一节用四个实验，看看这套“把稳定映射与协议写进参数”的机制在不同任务上具体固化了什么。SFT 的核心价值不在于注入新知识，而在于固化协议：把映射关系、交互格式、风格规范写入参数，使推理时无需冗长提示即可产出符合预期的输出。通常只需数千到数万条高质量样例，即可建立基本的对话能力与指令遵循。

这种高效率可能以依赖训练分布为代价：特别是在需要探索多种正确策略，或部署分布偏离示范数据的任务中，SFT 可能偏向复现示范模式，并在新场景中性能下降。接下来的实验从不同角度展示“固化协议”的过程，而不是证明 SFT 与 RL 存在普遍的优劣关系。

在动手做 SFT 之前，有一个绕不开的实操问题：SFT 数据从哪来？ 工业界的答案基本就三条路：

• 人工专家示范——质量天花板最高，但贵且慢，适合用来定义格式与风格的 “种子数据”；
• 教师模型生成——即合成数据，让强模型批量产出 “输入—输出” 对，过滤后再蒸馏给学生，详见实验 7-8、7-9；
• 拒绝采样——模型自己对同一问题采样多条候选，用验证器筛出正确样本再反过来训练自己，详见实验 7-9。

三条路经常组合使用：先用少量人工种子立住格式，再用教师模型放大规模，最后用拒绝采样把质量拉齐。无论走哪条路，构造流程都大同小异：先定义任务分布与输出 schema，再批量生成候选，然后用规则校验、格式检查加人工抽检做质量过滤，最后去重、平衡配比、保证多样性。量级上不必贪多——数千到数万条高质量样本通常就足以固化协议，与其堆十万条脏数据，不如精修一万条干净数据：数据里的每一处噪声，SFT 都可能忠实地写进参数。

实验 7-6 ★★★：语音 SFT——从 “声音复制” 到 “副语言建模” [扩展实验]

以 Orpheus（语境提示 voice cloning）与 Sesame（副语言标记建模）为对象，展示如何将“声音风格与表达习惯”写入参数。两者思路不同：

• Orpheus：把声音波形压缩为 token 序列，通过拼接同一说话者的参考音频，让模型学会“用这个人的声音说话”，实现跨句音色一致。
• Sesame：将笑声、叹气等副语言现象抽象为 <laugh>、<sigh> 等特殊标记，训练模型学会“看到标记就发出对应的声音”。

SFT 在表达型任务中固化的是风格控制协议与结构化表达习惯，而非事实知识或复杂思考。关键在于训练数据的多样性和标注质量。常见失败模式：训练数据中说话者过少导致所有人听起来一个腔调；标记过拟合（Overfitting，即模型死记硬背了训练样本的细节，遇到新情况反而表现更差）产生“机械笑”。

实验 7-7 ★★★：多语言思考——让模型用任意语言思考 [扩展实验]

大多数思考模型只会用英语“思考”：不管你用什么语言提问，模型内部的思维链几乎都是英文的，因为训练数据中高质量的思考示范基本都是英语写的。本实验的目标很简单——让模型能够用指定的语言进行思考。

做法是对 gpt-oss-20b 进行 SFT：在系统指令中加一句 reasoning language: German（或其他语言），然后用英语、西班牙语、法语等几种语言的思考样例进行训练。训练数据中完全没有中文，但训练完成后，只要把 reasoning language 设为 Chinese，模型就能用中文进行完整的思维链思考——这种零样本的跨语言泛化是本实验最有意思的发现。需要注意，这并非 SFT 本身的泛化能力。多语言预训练已经在模型中建立了跨语言的共享表征空间，SFT 只是激活了这种预训练时已有的跨语言能力。

实验 7-8 ★★：Prompt 蒸馏——以更小开销复现可用能力

在实际应用中，为了让模型完成复杂任务，常常需要设计冗长的系统提示（数千甚至上万 token），每次调用都会增加延迟与费用。使用思考型大模型时，内部思考 token 进一步放大成本。Prompt 蒸馏的思路是把“长提示 + 思考型教师”的行为压缩到“短提示/无提示 + 非思考学生”中。教师在完整提示与思考模式下生成高质量答案，训练数据只保留用户输入与最终结论，丢弃冗长提示与中间思考过程。学生学会“直接给出结论”，蒸馏后在相同输入上接近教师的输出质量，同时因为不需要处理冗长提示和思考 token，延迟与费用显著降低。

蒸馏可以在两个维度进行：“大到小”（用中小模型替代大模型，在成本和质量之间取得折中）和“思考到非思考”（同等规模下把显式 CoT 折叠为隐式参数化知识，获得 20-30 倍的响应速度提升）。两者并不冲突，在生产环境中经常同时使用。需要注意的是，蒸馏会继承教师的边界——若教师在长尾分布上有系统性错误，学生会进一步硬编码这些错误；若教师依赖工具来确保正确性，单纯的输出蒸馏会失去工具带来的鲁棒性。工程启示：当产品形态稳定、输入分布可预期、成本约束明显时，Prompt 蒸馏是很好的优化手段；而在探索期或任务尚未定型的阶段，保留显式思考与可编辑的提示工程仍是快速试错的核心。

实验 7-9 ★★★：思维链（Chain of Thought, CoT）蒸馏

Prompt 蒸馏丢弃思考过程，CoT 蒸馏则相反：把强教师模型的完整思考轨迹转移给学生模型。对能力较强的教师模型进行 CoT 蒸馏，在同等参数量下可恢复教师 70%-80% 能力。对于不追求刷新前沿能力边界、但寻求自主可控模型的团队，这是最务实的跟随者策略。DeepSeek-R1 发布时同步开源的一系列蒸馏小模型（用 R1 的思考轨迹对 Qwen、Llama 系列做 SFT），正是这条路线的代表。

背景：“思维围墙”现象。一些闭源思考模型（如 OpenAI o 系列、Gemini 系列）在思考时会生成内部思维链，但用户看到的并非原始思考过程——厂商出于防蒸馏、安全和产品体验等考虑，通常会在输出前对 CoT 进行改写或摘要，最有价值的原始思考过程被隐藏在 API 之后。这正是本实验选择开源思考模型作为教师的原因：DeepSeek V4、Kimi K3、GLM 5.2 等模型直接公开完整思维链，蒸馏在技术与许可上都可行（使用前仍应确认模型许可证对蒸馏产物的授权条款）。

实验现场：模型会写代码，不代表它愿意帮助你蒸馏模型。 在实现本实验时，作者最初使用由 GPT-5.6-Sol 驱动的 OpenAI Codex 编写实验代码，但当任务明确涉及模型蒸馏时，Codex 拒绝继续执行。随后，作者切换到由 Claude Opus 5 驱动的 Claude Code，也遇到了同样的拒绝。最终，作者使用 Kimi K3 完成了实验代码和后续运行。

两次拒绝针对的都不是普通数学推理，也不是简单地要求模型公开内部思维链，而是实现一个使用强教师数据训练学生模型的完整蒸馏实验。模型蒸馏与正常的监督微调在技术上高度相似，但在厂商的安全与产品策略中，它也可能与模型提取、能力复制和知识产权保护联系起来，因此成为一个敏感类别。

对绝大多数做后训练的人来说，根本不需要去蒸馏闭源模型的思维链。 当前最先进的开源模型与 SOTA 闭源模型的差距并没有想象中大；教师模型只需要 “明显高于学生”，不需要 “全球第一”。如果你要后训练的是 200B 及以下规模的模型，用开源 SOTA 模型当教师已经完全够用。

实验设计：三步流程。第一步，采集轨迹：从目标任务分布（如数学、代码）采样问题，用开源教师模型生成完整的“思考 + 答案”轨迹，并用规则验证器过滤掉最终答案错误的轨迹——否则错误的思考过程会被学生一并模仿。这一步“生成候选—验证过滤—只留正确轨迹”的做法有个专门的名字：拒绝采样（Rejection Sampling）。用它构造的数据做 SFT，就是拒绝采样微调（Rejection Sampling Fine-Tuning, RFT）。它介于纯 SFT 与 RL 之间：不训奖励模型、不做策略梯度，只靠“从多条采样中拒绝错的、留下对的”来提升数据质量，是可验证任务上性价比极高的数据构造手段。第二步，SFT 训练：以“问题 → <think> 思考轨迹 </think> + 最终答案”为训练对，对小模型（如 7B 量级）做标准 SFT。第三步，对比评估：在同一基准上对比蒸馏前后的学生模型与教师模型，衡量能力恢复比例。

验收标准：蒸馏后的学生模型在数学/代码基准上相对蒸馏前显著提升，且思考轨迹中出现教师式的反思、回溯与验算行为。同时注意蒸馏的代价：学生会继承教师的系统性错误和冗长思考习惯（后者可结合实验 7-10 的 AdaptThink 思路做二次优化）。

这四个实验有一个共同特征——“把稳定的映射与协议写进参数”：语音 SFT 固化风格控制协议，多语言 SFT 固化思考组织模板，蒸馏 SFT 固化输入到输出的直接映射。目标越明确、格式越清晰、评估标准越稳定，SFT 越能以很高的样本效率提升性能。

SFT 数据合成：从示范到可训练轨迹

SFT 的上限首先由数据决定。实际项目很少能靠人工逐条写出足够多的示范，通常要把少量人工种子、教师模型生成和验证器筛选组合起来：人工示范定义格式与边界，教师模型放大规模，规则验证或人工抽检守住质量。模型自举时，可以对同一题采样多条候选，只保留验证通过的轨迹，这就是拒绝采样微调（RFT）。

合成数据的目标不是复述线上日志，而是从日志中提炼可复用的任务结构：用户意图、初始状态、可用工具、业务约束、常见失败方式和成功条件。去除身份信息后，为每种任务重新生成虚构人物、订单、文件和状态，放进可重置的隔离环境。这样既保留真实难点，也避免模型记住客户数据或内部凭据。

一条稳妥的流水线是：线上数据 → 任务蓝图 → 合成任务 → 多次候选轨迹 → 任务验证与轨迹验证 → SFT 数据。任务验证检查题目本身是否可完成、难度是否合适、参考结果是否正确；轨迹验证检查最终状态、工具调用和业务约束。能写成单元测试、数据库断言或状态差异检查的条件，优先使用确定性代码；开放式的沟通质量再由模型评价器补充，并用人工抽样校准。技能图、可执行环境和独立验证器可以进一步扩大任务覆盖并过滤无效轨迹[^ch7-12][^ch7-17][^ch7-18][^ch7-19][^ch7-20]。

同一套任务和验证设施之后还可以转成 RL 环境，但两阶段的用法不同：SFT 只保留验证通过的成功轨迹，学习稳定的格式、流程和基本动作；RL 让当前策略重新 rollout，利用环境奖励探索示范之外的路径。失败轨迹不应直接当作正确示范，可以用来构造偏好对、发现任务覆盖缺口，或补上诊断与修复后再加入训练。

数据合成的关键不是数量，而是覆盖面、多样性和准确性。训练集还应按任务模板、客户或时间段去重划分，评估集必须来自不重叠的任务类型；参考解法、隐藏测试和验证器反馈不能泄露给模型。

第六章的 bad case 也可以在这里转成训练数据。以 Coding Agent “过早结束”为例，先把“准备宣称完成”的轨迹前缀截出来，再把当时的过早宣称作为 rejected，把“先运行测试、逐条核对验收条件，再下结论”作为 chosen。这类数据适合做 DPO 或决策边界示范，而不是直接当作正确的 SFT 轨迹；失败原因、适用条件和验证器应随样本保存，方便追溯和复查。实验 7-17 的 build_preference_data.py 提供了确定性模板和教师模型两条构造路径，训练数据与后面的评估集分开保存。

同一批任务还可以转成 RL 的练习环境。SFT 只使用已经验证通过的轨迹，RL 则让当前策略重新执行任务，由外部验证器判断结果。这样，bad case 不只是被“记住”，还可以用来定义模型需要改进的决策边界。

本章新增的两个 Bad Case 实验分别展示两种不同的监督目标。中文弯引号案例先把反馈提炼成作用域敏感的文档 Skill，再用结构化合成数据做 SFT；特殊字符串案例则把 old_string mismatch 转成 byte-exact 复制任务，重点训练逐 token 的保真度。二者共享第六章的失败归因和训练/评估隔离协议，但不共享总分：前者测“该改才改、该留则留”，后者测“必须逐字复制”。

何时选择 SFT，何时选择 RL

7.1 节讲清了 SFT 与 RL 的本质区别，这一节回答一个更实操的问题：面对一个具体任务，到底该用哪一个？ 下面的决策框架部分结论会在后续 RL 实验（实验 7-10、实验 7-11）中进一步验证，读者可先建立初步判断，读完 RL 部分再回来对照。

SFT 适用于格式固化（JSON 输出、对话风格）、拥有高质量专家示范、训练与部署环境高度一致的场景。可以考虑 RL 的场景则不同：当实际部署环境与训练环境存在系统性差异，且能构造反映这些差异的可靠奖励时（比如训练时卡牌 J/Q/K 都是 10，部署时变成了 11/12/13；或者训练时用黑色花色，部署时遇到红色花色），需要探索最优策略（专家示范本身不一定最优），或者标注成本过高、无法为每条路径都提供示范时，可以考虑 RL。

在结构化输出不稳定的设置中，最稳健的策略是**“先 SFT 后 RL”两阶段流程。此时 SFT 的主要目标不是追求任务性能的极致，而是建立输出的格式稳定性**——确保模型能产出可解析的 JSON、正确的工具接口调用。只有输出格式稳定后，RL 的奖励信号才能被可靠地计算。直接在未经 SFT 的基础模型上做 RL，往往会因为输出格式混乱、奖励无法计算而训练失败；实验 7-11 就是在“较小基础模型 + 严格结构化输出”的设定下观察到这一点。DeepSeek-R1-Zero 证明了足够强的基础模型可以跳过 SFT、直接 RL 成功，涌现出反思与长链思考能力——代价是输出可读性差、多种语言混杂，这正是 DeepSeek 最终在 R1 中加回“冷启动 SFT”的原因。R1 从 Zero 到冷启动的这段往返说明：结构化输出不稳定时可用 SFT 快速建立“形”（格式与可读性），再在有可靠奖励时用 RL 发展“神”（策略与推理能力）。

两者各有代价：SFT 样本效率高、收敛快，泛化性能很大程度上取决于数据的覆盖范围与多样性；RL 可以探索示范中没有的策略，但样本效率低且训练不稳定。如果增加多样、优质的示范后，新场景表现仍然停滞，并且有能可靠评估这些场景的奖励与环境，就可以考虑 RL。

实际决策时，可以按以下顺序考虑：

1. 先问：需要后训练吗？ 如果通过 Harness 工程（优化 prompt、工具设计、上下文管理）就能解决问题，不需要训练模型。大多数 Agent 应用落在这里。
2. 如果需要训练：先试 SFT。 适用于固化输出格式（JSON schema、API 调用格式）、固化协议性知识（术语的用法、输出格式、流程习惯，即“该怎么说、怎么做”）、统一风格（语气、长度）。但注意 SFT 不适合注入大量事实性知识（“知道什么”）——那需要继续预训练或交给 RAG。SFT 成本低、见效快。
3. SFT 不够时：加 RL。 适用于需要泛化到新场景、需要探索最优策略、或标注成本过高的情况。如果输出尚不能稳定满足奖励函数要求，可先用 SFT 或约束解码稳定格式，再应用 RL；如果强基础模型已经满足格式要求，也可以直接做 RL。

单轮强化学习：记忆与泛化的对照

“单轮” 指任务在一次交互中完成：模型接收输入、产出输出、获得奖励，无需维护跨步骤的状态。这种简化设定让我们能够聚焦于 SFT 与 RL 在学习机制上的根本差异，而不被多轮交互的复杂性干扰。单轮场景提供了清晰的对照实验条件：相同任务、相同基础模型、相同计算预算，唯一的变量是训练方法。第一个实验展示 RL 如何学会“何时该思考”这一元策略；第二个实验通过算术推理卡牌游戏系统地量化 “SFT 记忆、RL 泛化”。

在进入实验之前，先建立一点关于 RL 算法的最小直觉，以便理解后续实验里出现的术语。本章的 RL 训练大多基于策略梯度：让模型对同一个问题多生成几条回答，奖励高的回答就提高它出现的概率、奖励低的就降低——“奖励高的方向多走，奖励低的方向少走”。为抑制单次更新把模型带偏，主流的 PPO 算法会在概率比超出指定区间时裁掉代理目标中的额外收益；它会抑制大幅更新，但不是对策略变化的硬约束（后文实验中出现的 “带价值网络的 PPO” 即指此，价值网络用来估计基线、算出更细的优势）。另一种 GRPO 则不训练价值网络，而是用 “同一问题的多条回答互相比较” 来判断每条的相对好坏。记住这条直觉，就足以读懂接下来两个实验。

实验 7-10 ★★：AdaptThink——学会 “何时不思考”

大型思考模型（如 OpenAI o1、DeepSeek-R1）对所有问题都会生成冗长的思维链，在简单问题上造成不必要的开销。实验首先验证了一个直觉：NoThinking 模式（通过 <think></think> 跳过思考）在简单问题上性能相当甚至更好，只有面对困难问题时 Thinking 的优势才显现出来。

AdaptThink 通过 RL 训练模型自适应地选择模式。两个核心组件：

• 约束优化目标：鼓励 NoThinking 的同时确保整体性能不下降。
• 重要性采样策略：平衡 Thinking/NoThinking 样本，解决初始模型几乎总选 Thinking 带来的冷启动问题（Cold Start，这里特指训练初期模型几乎只产生 Thinking 样本、NoThinking 分支样本极少而学不起来的问题；它与前文 DeepSeek-R1 用少量示范数据做“冷启动 SFT”是不同语境下的用法）。

这里出现的“重要性采样”是统计学常用的方法——在采样分布偏向某一类样本时，通过给样本加权来“纠正”分布，让学习信号能够公平覆盖所有类别。本书后续讨论的 PPO、DAPO 等 RL 算法都会反复用到这一思想。

本书对这次历史训练的规范记录是 checkpoint-free 训练报告(../chapter7/AdaptThink/TRAINING_REPORT.md)。公开 W&B 主运行 wubbn5tj 使用 8×NVIDIA H100 80GB；step 0→300 时，MATH500 准确率 0.8100→0.8180（+0.80 pp）、响应长度 4911.46→1576.62（-67.90%），GSM8K 为 0.796816→0.818802（+2.20 pp）、1025.24→477.33（-53.44%），AIME mean@16 则为 0.314583→0.310417（-0.42 pp）、12119.51→6402.23（-47.17%）。对应 NoThinking 比例为 83.80%、84.15%、56.25%，说明数据集汇总层面存在与难度一致的路由信号，但不能称为逐题 “完美难度感知”，也不能声称准确率普遍提升。

运行在报告选点后继续到 step 410，累计 36.92 小时，随后 W&B 状态为 crashed；配置的 10 epochs / 3,140 steps 并未完成。Step 300 虽有 checkpoint 计时事件，但 checkpoint 不随书分发，也没有独立回执证明其经 run_eval_verl_hf.sh 成功评估或重跑 MMLU。历史源码提交为 9e588202…；未来复现固定到其直接子提交 0033ad172…，三个入口文件保持不变，但训练脚本生成的 -fl- 路径与评估脚本硬编码的 -fl4096 路径不兼容，需手工修正。

与 Prompt 蒸馏互补形成 “快-慢双系统”：蒸馏降低需思考的任务比例，AdaptThink 优化剩余任务的触发策略，共同实现思考效率最大化。

实验 7-11 ★★：GeneralPoints——单轮 RL 的 “记忆与泛化” 对照

GeneralPoints 是 Chu 等人提出的算术思考卡牌游戏[^ch7-3]，专门用于评估模型的泛化能力。任务目标类似“24 点”游戏：使用四张卡牌上的数字，通过加减乘除运算，每个数字恰好用一次，凑出目标数字 24。实验设计了纯文本 GP-L 与图像 GP-VL 两个变体，使我们能在同一框架下分别考察规则泛化与视觉泛化。

规则变体：训练时 J/Q/K 都计为 10，测试时分别计为 11/12/13，确保测试集出现训练未见的数字组合（含 11、12、13 的运算），严格评估泛化能力。视觉变体：训练用黑色花色（♠♣），测试用红色花色（♥♦），评估视觉外观变化下的鲁棒性。基于 Llama-3.2-Vision-11B，遵循标准后训练流程：先 SFT 初始化使其具备基本指令遵循能力，然后在相同计算预算下分别扩展 SFT 与 RL 训练（RL 部分采用带价值网络的 PPO 算法），用单一规则（J/Q/K=10）数据训练，在分布内（ID）与分布外（OOD）测试集上评估。

结果在这一受控设置中显示出明显差异。规则 OOD：RL 在 GP-L 上 +3.5%（11.5%→15.0%），SFT 下降 8.1%（11.5%→3.4%）；GP-VL 上 RL +3.0%，SFT 下降 5.6%。视觉 OOD：RL 在 GP-VL 上 +17.6%（23.6%→41.2%），SFT 下降 9.9%（23.6%→13.7%）。

追踪视觉识别准确率后发现：RL 通过结果导向的优化改善了底层视觉编码器，且这种改善与整体性能提升高度相关；而 SFT 因为过度拟合思考过程中的 token 模式，忽视了对视觉 token 的学习，导致识别准确率反而下降。

实验还说明，在本实验的设定下（Llama-3.2-Vision-11B 这个量级的基础模型，加上严格的结构化输出要求），RL 需要先用 SFT 初始化：未经 SFT 直接做端到端 RL 完全失败，因为基础模型无法产生结构化输出，奖励根本无法计算。注意这是特定设定下的结论而非普适规律：足够强的基础模型可以跳过 SFT 直接 RL 成功（见前文对 DeepSeek-R1-Zero 的讨论）。另一个值得关注的发现是，在这个实验中，验证迭代次数越多，测得的泛化越好：10 次 +5.99% vs 1 次 +0.48%，表明增加测试时计算量是其泛化提升的重要因素。

为什么在这个实验的分布偏移下 SFT 性能下降，而 RL 表现更好？一种与观察相符的解释是：有限的 SFT 数据强化了“遇到 J/Q/K 就当 10 用”的固定模式；测试时 J=11，模型仍按 10 计算。结果导向的 RL 分支则更可能强化“重新计算直到得到正确答案”的策略，因而在 J 变成 11 时仍能应用。这解释了本实验中的“记忆”与“泛化”对照，但不是说 SFT 必然只能记忆，或 RL 必然学会通用算法。

本实验的核心贡献，是在有限的 GeneralPoints 设置中系统量化了 SFT 的过拟合倾向与 RL 更好的分布外表现，并在纯语言和视觉—语言变体中观察到同一模式。在这个设置中，SFT 稳定格式，RL 在此基础上探索策略，两者形成互补。借用中国画术语，这种“先形后神”的训练配置先把外在形态（格式、结构）画准，再打磨内在策略，为后续多轮、多模态任务提供了方法论参考。

RL 算法：从 16 次 rollout 到一次参数更新

**GRPO（Group Relative Policy Optimization）**是 DeepSeek 提出的、今天 RL 训练最常用的算法之一。可以借助一个例子直观理解这个算法：假设 SWE-bench 中有一条任务：某个 Python 项目的 parser.py 在输入为空时会触发 IndexError，要求 Agent 修复代码，并且不能修改测试。训练系统会经历下面四步。

第一步：让策略模型重复尝试。 策略模型就是当前正在训练的语言模型。系统把同一份初始代码、同一条问题描述分别复制到 16 个相互隔离的沙箱中，让模型独立解决 16 次。每一次都包含完整的“阅读代码 → 修改文件 → 运行测试 → 提交结果”，这整条过程就叫一次 rollout。问题和初始环境完全相同，但采样具有随机性，所以 16 次尝试可能走出不同路径：有的正确补上边界检查，有的只捕获异常掩盖问题，有的改错文件，还有的试图修改测试。

第二步：计算奖励。 每条 rollout 结束后，验证器在干净环境中应用补丁并运行测试。假设 16 次尝试中有 4 次通过全部测试且没有修改测试文件，另外 12 次失败，那么前 4 条得到奖励 1，后 12 条得到奖励 0。在这种 coding 任务里，“奖励计算”并不神秘，就是用测试和规则判断这次修复到底对不对。开放式任务没有确定测试时，才需要人类偏好或奖励模型来评价。

第三步：计算相对优势。 奖励只说明单条轨迹成功或失败，相对优势则说明它相对于同组其他尝试有多好。这一组的平均成功率是 4/16：通过测试的 4 条高于组内平均，得到正优势；失败的 12 条低于平均，得到负优势。GRPO 的核心就是这种组内比较。若 16 条全部失败，或全部成功，大家的奖励完全一样，就比较不出谁更好，相对优势也会消失。RLVP 的路径信号、过程奖励和部分进展奖励，解决的正是如何在这些组里恢复有意义的差异。

第四步：用梯度下降更新策略。 训练程序把相对优势转成训练损失，计算梯度，再由优化器（如 AdamW、Muon）执行梯度下降，提高正优势轨迹中模型所做选择的概率，降低负优势轨迹中选择的概率。它不是把某个成功补丁原样背下来，而是在许多任务和 rollout 上逐步调整；以后遇到类似错误时，“先复现问题、检查边界条件、修改实现并运行测试”会更容易出现，“掩盖异常、改测试、没有验证就提交”会更少出现。

这四步合起来构成一次训练迭代，也就是一个 step：第 $k$ 个 step 用当前策略生成一批 rollout，完成奖励、优势和梯度计算，再由优化器更新参数；第 $k+1$ 个 step 随即使用更新后的策略重新 rollout。训练 100 steps，就是把这个闭环重复约 100 轮。具体 RL 训练框架可能把内部的多个 minibatch 更新另行计数，因此看训练日志时仍需确认其 step 定义。

做一个粗略的时间估算。复杂 Agent rollout 会生成数十轮工具调用，即使 16 条并行运行，一个 rollout 阶段的墙钟时间也由最慢的那条决定。假设最慢 rollout 用时约 2,000 秒，随后梯度下降和优化器更新用时约 600 秒，那么一个 step 大约需要 $2{,}000+600=2{,}600$ 秒，即约 43 分钟；连续训练 100 steps 就接近 72 小时。

PPO 与 GRPO 都遵循这个闭环，区别主要在 “拿谁来比较”。GRPO 直接比较同一问题的多条 rollout，不需要额外的价值模型；PPO 会训练一个价值模型，估计在轨迹的每一步 “通常能做到多好”，再判断当前动作是否比这个预期更好，因此更适合需要细粒度信用分配的长轨迹。两者都会限制单次更新幅度，避免模型因为一小批样本突然改变过多。DPO 则不同：它直接学习事先收集好的 “较好回答—较差回答” 偏好对，不让当前策略在线生成这组 rollout。

在本章案例中，AdaptThink 使用自定义约束目标，GeneralPoints 与 V-IRL 使用带价值模型的 PPO，SimpleVLA-RL 与 RLVP 使用 GRPO，ReTool 使用 PPO。算法决定如何比较轨迹和更新参数；奖励决定 “什么算成功”；环境和数据决定模型能经历哪些问题。

RL 环境：从评估到仿真

RL 训练的瓶颈往往不在算法，而在环境是否足够真实、可重置、可并行。真实 Agent 的电话、付款或文件修改可能昂贵且不可逆，不能靠无限重试弥补一次错误；第六章的评估环境可以提供验证器，但训练还需要让 Agent 反复试错、承受动作副作用，并在数百万次交互中保持稳定。因此环境工程是 RL 的前置条件，不是训练完成后的附属品。

环境：模型练习的场地

RL 的本质是“试错学习”，而试错必须有个试错的场地——这就是仿真环境（simulation environment）。模型在环境里一遍遍地跑任务、拿反馈、调整策略。环境的保真度（跟真实部署场景有多像）直接决定了训练出来的策略能不能用：

• 环境失真，策略必废。 如果仿真里的客服总是按固定套路回话、错误信息跟生产环境对不上，模型就会学到一套只在仿真里管用的“应试策略”，一上线就露馅。这是 RL 项目最常见的翻车方式——不是算法不行，是练习场跟考场不是一回事。
• 构建高保真环境，常常比训练本身更贵、更难。 一个能大规模并行、可复现、反馈真实的环境，往往需要投入比调模型多得多的工程。本章后面工具调用的实验（AWorld 的 MCP 沙盒、ReTool 的代码解释器沙盒）之所以花大力气搭环境，正是因为真实 API 有速率限制、会封号、有副作用，根本没法直接拿来训练——你必须先造一个稳定可控可重放的“影子世界”。
• 环境的另一半是奖励函数。 环境不仅要模拟“世界怎么变”，还要能判定“做得好不好”，这就是后面奖励设计的输入。

一句话：在动手调算法之前，先问自己——我的仿真环境，真的像真实世界吗？ 这个问题的答案，比选 PPO 还是 GRPO 重要得多。

造不出环境怎么办：让模型扮演环境

但还有一个更根本的问题：很多场景里，高保真环境不是“贵”，而是根本造不出来——真实 API 有副作用不能乱调，真实用户不能拿来试错，物理世界更是没法快进。如果连一个可用的“影子世界”都搭不起来，RL 是不是就做不成了？一个越来越主流的思路是：用模型来模拟环境——让一个 LLM 扮演环境，生成 Agent 交互所需的反馈。这条路线有两个层次。

第一个层次：模型合成工具调用的返回值。 以 ZeroSearch[^ch7-13]为例：训练 “会搜索的模型” 通常离不开真实搜索引擎，而搜索 API 有成本、有速率限制，返回结果还不可控。ZeroSearch 干脆用一个 LLM 扮演搜索引擎：学生模型发出搜索 query，由这个 “模拟引擎” 生成检索结果返回。更妙的是它用了课程式设计——训练初期让模拟引擎返回高质量、强相关的文档，随着训练推进逐步掺入噪声、降低返回质量，逼学生学会在真实搜索引擎那种不完美的返回里提取有用信息。最终，训练全程没见过真实搜索引擎的模型，直接对接真实搜索依然表现良好。

第二个层次：模型仿真整个环境的动态。 不只是单个工具的返回值，连 “执行动作后世界会变成什么样” 也可以交给模型。DreamGym[^ch7-14]把环境动态蒸馏进一个推理式的 “经验模型”：给定当前状态与 Agent 的动作，它逐步推理出状态转移和反馈信号，从而在不访问真实环境的情况下批量合成 rollout 用于在线 RL。客服、销售类 Agent 的训练普遍用 LLM 扮演用户（用户模拟器），τ-bench 系列评测正是建立在这个思路上——同一个模型模拟器，既能当考场，也能当练习场。

但必须指出这条路的风险：模拟器的世界知识就是训练的天花板，模拟器的系统性偏差会被策略照单全收。 如果模拟的客服比真实用户更有耐心、模拟的搜索引擎从不返回垃圾结果，学生学到的就是一套只在 “模型扮演的世界” 里成立的策略；更糟的是，RL 会主动寻找并利用模拟器的漏洞，进行 reward hacking。所以工程上的稳妥做法是混合：用模型模拟承担大部分交互量，辅以真实环境的交互，并用真实环境交互定期校准模拟器的偏差。

环境、任务分布与评估隔离

环境本身决定了 RL 能学到什么：它必须可重置、可并行、可复现，并在状态转移后给出可信的验证结果。训练任务可以从真实业务日志提炼，但应先去除身份信息，抽象出用户意图、初始状态、可用工具、约束和成功条件，再生成新的虚构人物、订单、文件与状态。这样既覆盖真实长尾，又不会把客户数据或内部凭据直接暴露给模型。

训练环境和评估环境可以共享任务生成器与验证代码，却不能共享同一批任务。SWE-Gym、τ²-bench、AndroidWorld 都说明了这一点[^ch7-28]：测试用例、隐藏状态和参考解法应留在验证器一侧，训练集与评估集按任务模板、客户和时间段去重隔离。先用少量 rollout 检查“任务是否可完成、验证器是否能区分对错”，再扩大采样规模；如果验证器本身有系统性偏差，RL 只会更快地利用它。

因此，环境工程的顺序应是：任务蓝图 → 可重置模拟器 → 确定性验证器 → 训练/评估隔离 → 少量真实交互校准。SFT 数据合成放在前文，是为了构造稳定的示范；这里的环境则服务于 RL，让当前策略反复试错并探索示范之外的路径。

确定性验证器“便宜”不等于“没有成本”。Lean kernel、测试运行器或容器执行可能让 CPU 验证速度远慢于 GPU 生成速度；这时吞吐量取决于并行的验证器 worker，而不是继续堆 GPU[^ch7-9]。

从单轮到多轮：任务场景与信用分配

多轮任务的核心挑战

从单轮到多轮，复杂性发生了质的跃迁。策略不仅要选择当前最优动作，还要考虑未来的状态价值；不仅要处理即时反馈，还要在延迟奖励下进行信用分配（Credit Assignment）——判断多步序列中到底哪一步对最终结果贡献最大。比如一个客服 Agent 用了 10 轮对话解决了用户问题，最终获得好评——但这个好评该归功于第 2 轮的精准提问，还是第 7 轮的耐心解释？

这里讨论的多轮交互，正是第一章和第四章描述的 ReAct 循环——每一轮就是一次思考 → 行动 → 观察的迭代，奖励延迟即来自“最终结果好坏要在多轮之后才能判断”这一结构性约束。

实验 7-12 ★★★：V-IRL-VL——多轮视觉导航

V-IRL[^ch7-24]让 Agent 在真实城市街景中连续导航：训练使用纽约路线，测试迁移到不同城市，并同时改变方向表达和视觉外观。RL 在规则和视觉 OOD 上都明显优于 SFT，说明在多轮任务中，策略需要学会根据当前观测重新规划，而不是复现训练轨迹。实验使用带价值网络的 PPO，并观察到逐步反馈能缓解长时序信用分配。

实验 7-13 ★★★：SimpleVLA-RL——结果奖励下的开放探索 [扩展实验]

SimpleVLA-RL 在 LIBERO 机器人任务中只使用成功/失败结果奖励。每个任务仅用一条演示轨迹做 SFT 冷启动，随后 RL 将成功率从 17.3% 提升到 91.7%，并发现演示中没有出现的“推切”动作。它与 V-IRL 形成对照：过程信号容易定义时能加速学习，最优路径未知时稀疏结果奖励反而保留更大的探索空间。

工具调用：把环境带进 Agent

多轮任务一旦接入外部工具，动作就不再只是“移动或回答”，而是搜索、执行代码、修改文件、查询数据库和组合多个 API。工具调用因此把信用分配、环境工程和安全约束同时推到了前台。

Search-R1[^ch7-25]代表检索增强路线：模型自主决定何时搜索、搜索什么，并利用返回结果继续推理。ReTool 则把代码解释器嵌入思考循环，模型需要学会何时执行代码、如何读取反馈、如何根据报错修正。AWorld-train 提供 MCP 多工具沙盒，进一步引入工具选择、依赖管理、状态重置和可重放性问题。

工具轨迹还有一个关键实现细节：环境返回的 token 不是策略生成的，计算策略梯度时应屏蔽这些反馈 token，只对模型自己的思考和工具调用参数回传梯度。否则模型会被训练去预测沙盒输出，而不是学会如何使用工具。

实验 7-14 ★★★：ReTool——代码解释器增强数学解题

ReTool 在 SFT 预热后，用交织的文本思考、代码执行和解释器反馈进行 PPO 训练。它展示了工具反馈如何改变思考策略：模型逐渐学会主动执行、读取错误并自我修正。训练数据来自 DAPO-Math-17k，但优化算法仍是标准 PPO[^ch7-26][^ch7-27]。

在 AIME 2024 上，训练从约 25% 提升到 67.0%；相比纯文本 RL，代码反馈让模型更快学会精确计算和纠错。详细的训练动态与沙盒配置见实验配套说明。

实验 7-15 ★★★：AWorld-train——在沙盒中学习使用工具

AWorld-train 使用 MCP 服务器沙盒，提供 Web、文档、多媒体、代码和知识检索等工具。这个开放式实验的重点不是刷新 GAIA 指标，而是跑通可重置、可重放的多工具训练链路，并观察工具调用成功率和组合策略是否随训练改善。

这些场景共同说明：多轮 Agent 的训练难点不是“有没有一个更复杂的优化器”，而是环境反馈是否可靠、动作链是否可验证，以及最终奖励该如何归因到中间决策。

奖励设计：如何把任务目标变成学习信号

前面的单轮、多轮和工具调用场景说明了“要训练什么”；这一节回答“环境应该怎样告诉模型做得好不好”。奖励设计可以沿三个互补维度展开：奖励来自哪里、什么时候给、要表达多少信息。最后再讨论一个额外问题：结果正确时，路径是否也合规。

奖励来自哪里：规则、人类偏好与模型评判

最可靠的来源是可验证奖励（RLVR）：用测试用例、数据库断言、状态差异或格式检查直接判断结果。数学答案、代码测试和结构化工具调用都适合从二元结果奖励开始；规则越确定，奖励越便宜、可复现，也越不容易被模型钻空子。

RLHF 只作为背景。InstructGPT[^ch7-4]的基本流程是：人工比较回答，训练奖励模型，再用 PPO 优化策略。奖励模型只是偏好的代理，过度优化会导致 reward hacking[^ch7-5]，因此通常用 KL 正则把策略锚定在 SFT 参考模型附近。DPO[^ch7-6]跳过显式奖励模型，直接从偏好对做离线优化；这些方法不是本章 Agent RL 的主线。

当目标难以完全规则化时，可以使用模型评判。**生成式奖励模型（GRM）**不只输出一个分数，还生成“哪里做得好、哪里需要改”的诊断；它可以作为奖励来源，也可以把诊断转成后续蒸馏或偏好数据。DeepSeek-GRM[^ch7-23]的核心思路是让模型先归纳任务评价原则，再按原则评价轨迹，最后用可验证事实检查评价是否正确。这样得到的反馈更透明，但仍需抽样人工校准，防止评判器形成新的偏差。

这里还要区分两个容易混淆的概念：reward hacking 是钻规则或实现漏洞拿高分，reward seeking 则是模型先在心里建立一个“评判器会看什么”的模型，再按这个猜测调整行为。后者不一定篡改测试或伪造结果，却可能在长程任务中自设一个很浅的检查，刚好通过就提前结束，交付物因此只满足代理指标而没有满足真实意图[^ch7-29]。所以“通过了 grader”不能自动等价于“任务完成了”：评判器是意图的代理，训练越强，模型越可能把代理当成目标本身。

奖励在什么时候给：结果还是过程

**结果奖励（ORM）**只在 episode 结束时判断任务是否完成，最简单，也给策略最大的探索自由度；当中间路径没有公认标准、最优解尚未被人类发现时，SimpleVLA-RL 的稀疏成功/失败奖励就是合适的起点。稀疏反馈让模型难以判断多步轨迹中的具体错误，这也是长期以来 RL 样本效率受限的原因之一[^ch7-8]。在长程 coding 或 cowork 任务中，还应把“是否完成”的判定交给模型写不了的隐藏测试、状态断言或外部终止钩子，而不能只依赖模型自己声称完成。

“过早结束”是一个具体例子：模型说任务完成时，Harness 在隔离工作区运行模型看不到的验收测试；通过才给正奖励，未通过则给负奖励。测试必须读取真实文件或环境状态，不能只检查模型是否说了“已完成”，否则模型可能学会口头承诺验证而不真正验证。评估时还要把任务未完成的边界集和确实已经完成的保留集分开，前者观察过早结束率，后者观察模型是否仍然能够正常收尾，避免把模型训练成永远不敢结束。

**过程奖励（PRM）**在中间步骤提供反馈，例如检查身份验证、工具参数、测试通过数或导航动作。OpenAI 的《Let's Verify Step by Step》[^ch7-7]展示了逐步验证在数学推理中的价值。过程奖励能缓解长时序信用分配，却可能把模型限制在设计者预设的路径上，而且标注和验证成本更高。V-IRL-VL（实验 7-12）采用逐步导航反馈，SimpleVLA-RL（实验 7-13）则保留终点奖励，两者构成“密集反馈换收敛速度、稀疏反馈换探索空间”的对照。

工程上可以先用结果奖励建立可靠基线，再只为真正可验证的中间事件加入过程信号。多轮 LLM RL 通常令折扣因子 $\gamma=1$；PPO 的价值网络或 turn-level 优势负责把终点反馈归因到较早的动作，GRPO 则把轨迹级优势均摊到生成 token，长轨迹上需格外注意信号稀释。

奖励需要表达多少信息：标量、向量与生成式诊断

奖励的密度和表示形式是两件事。标量只回答“总体多好”；半标量先给简短理由再给分数；向量按准确性、完整性、成本和安全等维度分别打分；生成式奖励则给出自然语言诊断并可多次采样后汇总。选择原则很直接：

• 有确定答案或测试：优先二元标量；
• 有多个相互独立的质量目标：使用向量，或将各维度加权成标量；
• 开放式、难以穷举规则：使用生成式诊断，但要配合事实校验和人工抽检。

不要为了“奖励更丰富”而堆叠不可验证的维度。每增加一个评价维度，就增加一种被策略钻空子的可能；先确认这个信号能在少量 rollout 中产生有意义的组内差异，再决定是否加入训练。

结果正确还不够：路径约束与 RLVP

结果奖励解决“事情有没有办成”，却表达不了“是否按规定办成”。真实 Agent 可能通过改测试文件、跳过身份验证或执行破坏性命令获得表面成功。RLVP（Reinforcement Learning with Verified Penalty）[^ch7-9]的原则是：奖励结果，惩罚路径。它针对的是可机器判定的、与最终成败无关的结果中性约束；它不能替代对语义意图、交付完整性和早停行为的独立检查。

真实环境通常是非对称验证器：检测“做了一个坏动作”便宜而可靠，证明“这一步确实朝着目标取得了有意义的进展”却很难。把总奖励写成 $R=O+\beta\Phi$：$O$ 是任务结果，$\Phi$ 是由确定性规则逐动作计算的路径信号。对可验证的违规动作扣分，对可验证的合规动作或可达子目标给少量部分奖励；两路归一化后再合并，避免路径信号淹没主目标。它不改变 PPO/GRPO，只改变每一步看到的奖励。

RLVP 的关键不是“奖励越密越好”，而是能否补回组内差异。纯结果奖励在全败组和全胜组都会产生零方差、没有梯度；违规动作通常容易检测，惩罚几乎总能补回差异；进展奖励只有在部分进展可达时才有效。设计时应遵循四点：只惩罚具体动作，不惩罚“不够努力”；结果奖励始终保留，避免模型学会什么都不做；每个惩罚最好配一条可达的合规路径；规则必须确定、难以钻空子。如果基础策略根本不会采样合规动作，应先用少量示范把这条路径“种”出来，待合规行为稳定后再逐步减弱路径塑形。换句话说，惩罚是通常可达的那一半，进展奖励是受可达性门控的那一半。

实验 7-16 ★★★：RLVP——奖励结果、惩罚路径

在 GRPO 上加入结果奖励 $O$ 与路径信号 $\Phi$，对比纯结果奖励。TerminalBench 上违规次数由 3.71 降至 0.66，而成功率基本持平；miniF2F 上可达的部分奖励把达到 0.9 成功率所需迭代从 7.0 降至 4.4。软件修复中若所有 rollout 都无法通过任何测试，进展信号不可达，加入它不会带来收益。这个实验提醒我们：先测信号可达性，再决定是否增加奖励维度。

这些数字来自可控代理环境，不能直接外推成线上 Agent 的同等提升；更稳妥的结论是机制性的：只要路径信号能在同一组 rollout 中区分行为，且规则不易被策略钻空子，它就能补上终点奖励看不见的那部分信息。对于真实部署，还需要把隐藏验证、轨迹监控和外部终止条件一起纳入 harness。

蒸馏：提升样本效率

前述实验已系统展示了 RL 在 Agent 训练中的核心价值，但都付出了高昂的样本成本。这里的“样本效率”特指：每次昂贵的环境交互，能带来多少有效的参数更新，而不只是训练步数或 GPU 时间。ReTool 的 RL 训练时间是 SFT 的 200 倍以上（9 天 vs 1 小时），因此减少环境采样尤其重要。

RL 样本效率低，除了高方差和在轨数据难复用，更根本的原因是反馈太稀疏。主流 model-free RL 通常只在一条 rollout 结束时得到一个成败标量，中间的错误原因、缺少字段、流程提示都没有直接的学习信号。比如客服说“需要信用卡后四位”，模型却只能从最终的 0/1 结果反复试错，可能要数百次交互才偶然学会这一步；人类听到一次就能记住。

蒸馏则把一次 rollout 变成密集的监督信号，不必额外探索更多环境轨迹，就能让同一条轨迹贡献大量梯度，这是蒸馏提升样本效率的关键。

On-Policy Distillation：让一次 rollout 产生密集监督

On-Policy Distillation（在轨蒸馏）由 Thinking Machines Lab 于 2025 年系统提出并推广[^ch7-10]。它要同时解决 SFT 和 RL 的短板：SFT 的监督很密集，却来自教师或人类走过的离轨路径；学生自己犯错、进入训练数据没有覆盖的状态时，不知道如何恢复。RL 让学生自己生成在轨路径，但一条轨迹通常只有一个最终奖励，学习信号稀疏且方差很高。

On-Policy Distillation 让学生先按自己的策略生成轨迹，再让更强的教师在学生实际走过的每个状态上给出下一个 token 的概率分布。于是，一条长度为 $T$ 的 rollout 不再只产生一个 0/1 信号，而能产生约 $T$ 组逐 token 的监督；教师推理消耗的是计算，而不是额外的环境交互。这样既避免了 SFT 的分布错位，又显著降低了 RL 的方差和试错次数：一次昂贵的采样就能学到“这一步该怎么改”，而不必等任务结束后再从成败反推。

具体做法是让学生的预测分布贴近教师分布，通常最小化两者的 KL 散度。例如学生生成“先查询 API，再解析返回值……”时，教师可以在当前位置给出“查询”80%、“调用”15%、其余 5% 的分布。相比最终成败的二元奖励，逐 token 对齐提供了密集得多、方差更低的学习信号；代价是教师推理成本，因此在环境交互昂贵时尤其划算。

在数学等任务上，达到同等性能所需的训练步数约为纯 RL 的 1/10。在多轮 Agent 中，成败信号更晚、更稀疏，逐 token 的教师分布能直接指导中间决策；但前提是仿真环境足够真实，让学生探索到的状态接近部署分布，否则教师对陌生偏差状态的评分也不可靠。

“稠密信号胜过稀疏信号”在一个纯 Agent 场景中也得到过验证。笔者和合作者曾在“时间感”任务上比较 DPO、四种 RL 与 On-Policy Distillation：前者分别受到稀疏奖励、目标错位、rollout 形状不匹配和策略崩溃的限制；换成冻结的 Qwen3-32B 教师，在学生自己的多轮轨迹上逐 token 对齐后，训练平滑收敛，四种条件下通过率比同源 SFT 基线高出 23 到 47 个百分点[^ch7-11]。这说明瓶颈往往不是奖励函数不够复杂，而是每次交互提供的信号不够密。

没有更强的教师怎么办：On-Policy 自蒸馏

On-Policy Distillation 的威力来自教师，但它也因此背上了一个硬前提：必须有一个明显强于学生的教师模型。 这在很多场景里并不成立。如果你要训练的是垂直领域模型，现有模型的能力都存在不足，那就没有教师模型可用。没有更强的教师，稠密信号的红利就与我们无缘了吗？

一个巧妙的破题思路是 On-Policy Self-Distillation（OPSD，在轨自蒸馏）[^ch7-15]：同一个模型分饰教师和学生两角，但看到的上下文不同。 教师版能看到“特权信息”——如标准答案或已验证的正确解答；学生版只看到问题本身，却在自己采样的轨迹上向教师版的逐 token 分布对齐。对着答案解释学生刚走过的路径，通常比独立探索更容易，因此一条 rollout 仍能产生密集监督。

相比 RLVR，OPSD 不要求奖励一定能被自动验证：特权信息可以是标准答案、人工示范或领域文档。它用这些信息替代更强的外部教师，同时保留“在轨采样 + 逐 token 监督”的样本效率优势。但它不会凭空创造新知识——如果模型拿着答案也讲不清过程，自蒸馏就没有额外信号；朴素 OPSD 还可能让模型丢失原有思考风格，需要额外正则稳定[^ch7-16]。

从 bad case 到后训练

这一节回到第六章留下的问题：基于生产 bad case 构建的评估数据集，如何真正变成后训练的输入。第六章结尾把评估环境和验证器比作后训练的基石。失败归因记录、端到端回归任务、轨迹前缀回归任务、Rubric 评分各自对应不同的训练用法：

表7-4 第六章评估数据集到第七章训练用法的映射

第六章的评估数据集	第七章的训练用法
端到端回归任务（含验证器）	RL rollout 任务与可验证奖励（RLVR）；拒绝采样（RFT）的采样池
轨迹前缀回归任务	DPO 偏好对、决策边界的 SFT 示范、On-Policy Distillation 的教师状态
失败归因记录（首个错误步骤与错误类别）	过程监督的负标签（PRM）、RLVP 路径惩罚的规则来源
Rubric 多维评分与人工金标集	向量奖励的各维度、生成式奖励模型（GRM）的训练与校准数据

案例 1：Coding Agent 过早结束

从 bad case 到归因。 Coding Agent 最常见、也最难根治的失败之一是过早结束：测试还没跑就宣称 “已完成”；用户要求改三个功能，改完两个就收尾；遇到两次失败就宣布 “这个任务不可能完成”。按第六章的错误分类，这属于 “任务完成度与逻辑判断问题”，生产侧的三类信号都能捕获它：用户纠正（“你根本没跑测试”）、点踩、事后审计（宣称完成的轨迹里没有任何测试工具调用）。归因记录把首个错误定位在 “准备宣称完成” 的那个决策边界上——在此之前，读代码、改代码可能都没错，错的是 “在缺乏证据时下结论” 这一步。前文奖励设计一节讨论的 reward seeking（自设一个很浅的检查、刚好通过就提前结束），描述的正是这类行为。

构造训练数据。 端到端回归任务：把 “宣称完成前必须跑通验收测试” 写成可验证奖励。测试对模型不可见，模型宣称完成时才运行，通过 +1、不通过 −1；这正是 “判定交给模型写不了的隐藏测试”（见前文奖励设计）的直接应用，也是本案例可选的 RL 分支。

轨迹前缀回归任务：截取 “准备宣称完成” 的决策边界构造偏好对——被拒绝的样本是过早结束的错误行为，被选中的样本是 “先运行测试、逐条核对验收条件，再下结论” 的期望行为。被选中的样本由教师模型生成，再经过规则验证器过滤（拒绝采样），得到一批 DPO 训练对。如果 bad case 数量太少，可以用数据扩充（换任务类型、换缺失的验证项、换完成措辞）形成数百条偏好对。按小配比混入通用任务数据做 LoRA 微调，避免把 “逢收尾必验证” 学成新的过拟合，也降低灾难性遗忘的风险。

评估：边界集与保留集缺一不可。 训练后的验证使用第六章的评估数据集：轨迹前缀边界集检查 “任务未完成时，模型是否选择继续验证而非宣称完成”；同样重要的是保留集——任务确实已完成时，模型应正常宣称完成。只盯前一个指标，会把模型训练成永远不敢收尾的过度矫正状态：每个任务都无限验证下去，延迟与成本崩溃。这与第六章反复强调的 “改动不能破坏既有行为” 是同一原则在参数层面的版本；评估还应抽查通用能力，确认 LoRA 补丁没有破坏其他能力。

实验 7-17 ★★：从“过早结束” bad case 到 DPO 修复

实验目标：跑通从生产 bad case 到参数更新的完整链路——失败归因 → 轨迹前缀回归任务 → DPO 偏好对 → 7B 模型 LoRA 训练 → 边界集与保留集双集验证。

数据构造：配套仓库提供 24 条写实的过早结束 bad case，覆盖四类失败（未跑测试就宣称完成、多目标只完成一部分、验收条件未满足、遇错放弃宣称不可能，含删除失败测试这类更恶劣的 reward hacking 变体），以及与训练数据严格隔离的 held-out 评估集（boundary 12 条 + retention 8 条）。

这是一个教学作用的实验。在生产中，偏好对要覆盖更多任务族，保留集要覆盖更多 “正常收尾” 的场景，还要警惕奖励作弊的新形态：模型可能学会 “口头声称去验证” 而不真的验证。这正是端到端数据集的奖励必须依赖模型写不了的隐藏测试、而不是模型自己的声明的原因。

案例 2：中文引号

用户反馈 “中文文章中的直引号应统一为弯引号”。这句话描述了期望，却没有给出可以直接训练的规则：同一个引号，在中文自然语言、英文原文、Markdown 行内代码、代码块、代码注释、JSON 或路径中承担的角色完全不同。正确的修复是作用域敏感的最小编辑：中文自然语言中的引用可以转换为 “”，嵌套引用按中文标点规则处理；英文原文、可执行代码、JSON/schema、路径、标识符和 Markdown 反引号中的内容必须原样保留；无法判断作用域时应保留原文。

构造训练数据。 将引号的使用规则写成 Skill。正例覆盖中文段落、嵌套引用以及代码注释中的中文自然语言，反例覆盖英文原文、字符串/字符字面量、JSON、路径、行内代码和整段代码。这样教给模型的是 “先判断作用域，再做最小编辑”，而不是 “看到直引号就替换”。

实验 7-18 ★★：作用域敏感的中文弯引号 SFT

实验目标：验证 LoRA SFT 能否让模型在混合中文、英文、Markdown、代码和 JSON 的文档中，准确执行“该改的引号改弯、受保护的引号不动”，并在未见过的上下文组合上保持这一边界。

实验设置：以 Qwen/Qwen3-8B 为基座，使用 bf16 LoRA 训练 2 个 epoch（256 次更新）。SKILL.md 的作用域规则同时作为生成标签、质量门禁和回归规范；模型只负责选择作用域和生成最小编辑，生产侧的解析器与语法检查不被移除。

数据构造：按 16 类片段、10 种文章体裁和 9 种编程语言渲染 1024 条训练样本、256 条留出样本和 256 条边界样本。样本成对保存原文与目标文本，中文自然语言和中文代码注释提供需要转换的正例，英文原文、字符串字面量、JSON、路径、行内代码、代码块及嵌套结构提供必须保护的反例。

案例 3：编辑文件经常失败

如第五章所述，Coding Agent 常用 edit_file(path, old_string, new_string) 这样的工具：模型把要替换的 old_string 抄写到工具参数。编辑工具通常按精确字符串匹配，哪怕只差一个空格、换行、反斜杠、Unicode 组合字符或低频 token，都会返回失败。

从 bad case 到归因。 对失败轨迹沿着下面的链路逐层对比：文件原始字节 → 工具返回 → Harness 序列化 → 模型上下文 → 模型 token 输出 → 解码字符串 → JSON/tool-call 解析 → 工具匹配。

若文件读取或工具返回已经改变字节，归因给工具；若序列化、转义或提示词拼装改变了内容，归因给 Harness；如果 tokenizer encode 后再 decode 发生变化，归因给 tokenizer。只有模型收到的上下文与原始字符串完全一致，而模型输出是链路上首个出现差异的位置，才能把它标为模型的精确复制能力问题，作为后训练候选。

构造训练数据。 把复制任务抽象成三个可验证任务：直接逐字复述；在相似且等长的多个字符串中选择完全相同的目标；以及把指定字符串完整抄写到 old_string 的工具 JSON 参数。样本特意包含真实编辑最容易损坏的空格、真实换行、反斜杠、Unicode 等。

实验 7-19 ★★：特殊字符串的精确复制 SFT

实验目标：在已确认差异来自模型抄写错误的前提下，测试 LoRA SFT 能否提升模型对随机字符串的精确抄写，并用独立 tokenizer 审计排除词元化造成的假象。

实验设置：以 Qwen/Qwen3-8B 为基座，使用 bf16 LoRA 训练 2 个 epoch。训练脚本只对目标字符串或 old_string JSON 字段提供逐 token 监督。

结果：模型留出集 byte-exact accuracy 从基座的 37.5% 提升到 78.9%，独立边界集为 80.1%；平均首次字节分歧位置分别为 54.0 和 54.2。另用留出与边界共 512 条探针比较三个开源 tokenizer，Qwen3 与 Qwen2.5 的无损 round-trip 均为 80.1%。因此 80.1% 同时反映了模型复制和 tokenizer 上限。

后训练实践要点

这一章从预训练的“预测下一个词”出发，走了一条很长的路：SFT 可以高效学习格式与协议，本章的对照实验中，结果导向的 RL 改善了分布外泛化；多轮任务引入信用分配难题，奖励设计从结果奖励延伸到“奖励结果、约束过程”的路径信号，工具使用带来组合爆炸。这些实验有一条共同的线索——模型学到什么，取决于训练信号教了它什么；而信号的质量，主要由数据和环境决定，不是由算法决定。

在结构化输出不稳定的设置中，可以先用 SFT 建立格式和基本能力，再在有可靠奖励与环境时用 RL 探索策略。在这些实验中，SFT 稳定了协议与结构（JSON 格式、对话模板、工具接口），RL 改善了算术规则、空间思考和动作序列的分布外表现。SFT 训练过度或 RL 优化过度，都可能产生过拟合。

以下常见陷阱值得警惕，识别这些问题往往比掌握技术细节更能避免资源浪费：

1. 过度依赖后训练来记忆事实——应该用 RAG 管理事实知识（可动态更新、可追溯来源、不因训练而遗忘），后训练聚焦于“如何使用知识”。
2. 格式未稳定就引入 RL——如果模型不能稳定生成奖励计算所需的 JSON，训练信号会变得稀疏或失真。可接受的解析失败率取决于任务与奖励设计，不应把固定阈值当作普遍标准；先用小规模评估设定格式稳定性门槛，必要时通过 SFT 或约束解码稳定输出后再应用 RL。
3. 奖励函数设计不当导致奖励黑客——模型学会钻奖励的漏洞来获得高分，而非真正完成任务（比如只看回复长度就生成冗长无意义的文本）。应该评估最终目标而非中间指标。
4. 忽视仿真保真度——若仿真过于简化（客服总按固定模式回复）或环境响应不真实（错误信息与生产环境不一致），训练出的策略在真实场景中会完全失效。高保真仿真环境的构建成本可能高于训练本身。
5. 过度训练导致泛化下降——训练损失持续下降但验证集性能反而恶化时，模型正在死记训练细节。SFT 尤其容易出现这个问题，早停仍然至关重要；RL 过度优化同样会导致策略过拟合当前任务分布。
6. 价值函数崩溃与探索不足——PPO 中价值估计不准确会导致优势计算出现偏差，表现为训练曲线剧烈震荡。温度参数过低或随机性不足会使 Agent 陷入局部最优。
7. 低估 RL 的计算成本——SFT 上表现良好的任务转 RL 可能需要 10-100 倍训练时间。如果测试分布与训练高度一致，SFT 可能已经足够。
8. 训练数据质量低下——SFT 会直接学习数据中的噪声与偏差，将错误固化为参数；RL 虽然通过探索可能发现更好的策略，但如果奖励模型有系统性偏差，就会朝错误方向优化。

核心原则：在投入大规模资源前，先用小规模实验验证关键假设——少量数据测试 SFT 能否稳定格式、简化环境验证 RL 能否收敛、小样本检查奖励函数是否反映真实目标。快速失败比大规模失败更可接受。

与 RAG/ICL（上下文学习）的协同：三者不是互斥方案，而是作用于不同位置。ICL 用示例、规则和当前状态实现零参数的即时适应，但随着上下文增长，延迟与费用也会上升；RAG 把事实与证据放在可动态更新、可追溯的外部知识中；后训练则把高维感知、生成风格和隐式决策策略写入参数。选择依据不只是任务是否长期稳定，更重要的是能力能否被外部符号充分表达。医疗影像识别、自然语气等能力即使面对持续变化的领域，仍往往需要参数更新；反过来，长期稳定的转账审批规则也应由代码提供确定性保障，而不能只靠模型记忆。

稳健的系统通常组合使用这些方法：用 RAG 管理事实与证据，用 ICL 快速试验可用语言描述的策略，用程序固化确定性流程与硬约束，再把难以用语言表达且需要广泛泛化的能力通过后训练写入参数。后训练还可以实现模型蒸馏——把高能力大模型的能力迁移到成本更低的小模型中。

本章小结

SFT 和 RL 与其说是竞争关系，不如说是经常按顺序组合的方法。在结构化输出不稳定的设置中，可以先用 SFT 稳定格式，使 RL 奖励信号能够可靠计算，再用 RL 探索策略并改善分布外表现。“SFT 记忆、RL 泛化” 概括的是本章受控实验中观察到的倾向，并不是不受数据、模型、奖励与环境影响的普遍规律。

还有两条贯穿全章、比任何算法都值得记住的判断。其一，数据和环境比算法更重要：现成的 RL 算法你会用就行，真正拉开差距的是仿真环境的保真度和训练数据的质量；造不出真实环境时，用模型模拟环境（合成工具返回值、仿真环境动态）也是一条可行路线，但要记得模拟器的偏差就是训练的天花板。不仅答案可以筛选，训练数据的任务分布本身也可以成为优化对象。很多场景下，只要 SFT 的数据质量到位，你甚至不需要做 RL。

其二，当前 RL 的主要瓶颈是样本效率：On-Policy Distillation 把一条 rollout 的终点标量扩展为逐 token 监督，RLVP 则把被浪费的环境反馈变成可学习信号，两者是目前看起来最有希望的两个方向。它们的共同点是把环境和数据里本就存在、却被纯结果奖励浪费掉的信息，重新变成模型能学的东西。

本章回答了怎样通过更新模型参数来实现 Agent 持续进化的问题。下一章我们将看到，参数只是知识、指令、程序与参数四种 Agent 自我进化的载体之一。

[^ch7-1]: Schulman, John and Thinking Machines Lab, “LoRA Without Regret”, 2025. [^ch7-2]: 姚顺雨（Shunyu Yao），“The Second Half”，2025 年 4 月 10 日。https://ysymyth.github.io/The-Second-Half/ [^ch7-3]: Chu, Tianzhe et al., “SFT Memorizes, RL Generalizes: A Comparative Study of Foundation Model Post-training”, 2025. arXiv:2501.17161. https://arxiv.org/abs/2501.17161 [^ch7-4]: Ouyang, Long et al., “Training Language Models to Follow Instructions with Human Feedback”, OpenAI, 2022. [^ch7-5]: Gao, Leo, John Schulman, and Jacob Hilton, “Scaling Laws for Reward Model Overoptimization”, OpenAI, 2023. [^ch7-6]: Rafailov, Rafael et al., “Direct Preference Optimization: Your Language Model is Secretly a Reward Model”, 2023. [^ch7-7]: Lightman, Hunter et al., “Let's Verify Step by Step”, OpenAI, 2023. [^ch7-8]: Silver, David and Richard S. Sutton, “Welcome to the Era of Experience”, 2025. [^ch7-9]: Li, Bojie, and Noah Shi, “RLVP: Penalize the Path, Reward the Outcome”, 2026. arXiv:2607.07435. https://arxiv.org/abs/2607.07435 [^ch7-10]: Thinking Machines Lab, “On-Policy Distillation”, 2025. https://thinkingmachines.ai/blog/on-policy-distillation/ [^ch7-11]: Li, Bojie, and Noah Shi, “Agents That Sense Physical Time: Urgency, Persistence, and Vigilance as Missing Controls for LLM Agents”, 2026. https://01.me/research/physical-time-agent [^ch7-12]: Kulikov, Ilia, et al. Autodata: An Agentic Data Scientist to Create High Quality Synthetic Data. arXiv:2606.25996, 2026. [^ch7-13]: Sun, Hao, et al. “ZeroSearch: Incentivize the Search Capability of LLMs without Searching”, 2025. arXiv:2505.04588. [^ch7-14]: “DreamGym: Scaling Agent Learning via Experience Synthesis”, 2025. arXiv:2511.01824. [^ch7-15]: Zhao, Siyan, et al. “Self-Distilled Reasoner: On-Policy Self-Distillation for Large Language Models”, 2026. arXiv:2601.18734. [^ch7-16]: Shen, Ziqi, et al. “Purified OPSD: On-Policy Self-Distillation Without Losing How to Think”, 2026. arXiv:2607.02234. [^ch7-17]: Tan, Zelin, et al. “SKT: Skill-Use Training at Scale via Verified Synthetic Data Generation”, 2026. arXiv:2608.02287. [^ch7-18]: Wei, Yifan, et al. “Towards Compositional Generalization of LLMs via Skill Taxonomy Guided Data Synthesis”, 2026. arXiv:2601.03676. [^ch7-19]: Zhu, Kaijie, et al. “TermiGen: High-Fidelity Environment and Robust Trajectory Synthesis for Terminal Agents”, 2026. arXiv:2602.07274. [^ch7-20]: Hua, Zhanbo, et al. “CLI-Universe: Towards Verifiable Task Synthesis Engine for Terminal Agents”, 2026. arXiv:2606.22883. [^ch7-21]: Kim, Moo Jin et al., “OpenVLA: An Open-Source Vision-Language-Action Model”, 2024. arXiv:2406.09246. https://arxiv.org/abs/2406.09246 [^ch7-23]: Liu, Zijun et al., “Inference-Time Scaling for Generalist Reward Modeling”, 2025. arXiv:2504.02495. https://arxiv.org/abs/2504.02495 [^ch7-24]: Yang, Jihan et al., “V-IRL: Grounding Virtual Intelligence in Real Life”, 2024. arXiv:2402.03310. https://arxiv.org/abs/2402.03310 [^ch7-25]: Jin, Bowen et al., “Search-R1: Training LLMs to Reason and Leverage Search Engines with Reinforcement Learning”, 2025. arXiv:2503.09516. https://arxiv.org/abs/2503.09516 [^ch7-26]: Feng, Jiazhan et al., “ReTool: Reinforcement Learning for Strategic Tool Use in LLMs”, 2025. arXiv:2504.11536. https://arxiv.org/abs/2504.11536 [^ch7-27]: Yu, Qiying et al., “DAPO: An Open-Source LLM Reinforcement Learning System at Scale”, 2025. arXiv:2503.14476. https://arxiv.org/abs/2503.14476 [^ch7-28]: Pan, Jiayi et al., “Training Software Engineering Agents and Verifiers with SWE-Gym”, 2024. arXiv:2412.21139；Barres, Victor et al., “$\tau^2$-Bench: Evaluating Conversational Agents in a Dual-Control Environment”, 2025. arXiv:2506.07982；Rawles, Christopher et al., “AndroidWorld: A Dynamic Benchmarking Environment for Autonomous Agents”, 2024. arXiv:2405.14573. [^ch7-29]: storm, “长程智能体自我检查与早停行为：Reward Seeking 现象及其缓解措施”，青稞社区，2026 年 8 月 6 日。https://qingkeai.online/archives/Reward-Seeking；原文链接：https://zhuanlan.zhihu.com/p/2064127486921909656

思考题

1. ★★ 灾难性遗忘——一次针对特定任务的微调破坏了模型原有的通用能力（如通用工具调用）——在 Agent 场景下尤其棘手。相比全参微调，LoRA 冻结基座权重、遗忘风险更低，但并非免疫。有哪些策略可以进一步缓解微调带来的能力遗忘？
2. ★★ 后训练将能力固化为模型权重（“肌肉记忆”），而上下文学习将知识放在推理时的输入中。但有些能力（如领域知识）既可以通过后训练学习，也可以通过 few-shot 示例提供。你会用什么标准来决定某项能力应该走哪条路径？
3. ★★ 模型蒸馏让小模型学习大模型的行为。按能力层次，被蒸馏的模型大致可分为三级——Chat 模型（单轮对话、直接作答）、Reasoning 模型（带长链思考再作答）、Agentic 模型（多轮调用工具、与环境交互）。分别蒸馏这三类模型，难点有什么不同？（提示：从“要蒸馏的到底是什么”入手——是输出的风格、完整的思考轨迹，还是与环境交互的决策策略；轨迹里哪些 token 该学、哪些是环境返回的不该学；以及成败信号出现得有多晚、有多稀疏。）
4. ★★★ 在多轮 Agent 交互中，奖励的归因（credit assignment）问题比单轮更严重——一个最终的成功或失败很难归因到第 3 轮还是第 7 轮的决策。你会如何设计奖励分配策略？
5. ★★★ 如果你有固定预算（比如 $10,000），要提升一个客服 Agent 的性能，你会如何在上下文与知识、Prompt/Skills、程序约束和参数训练之间分配预算？你的决策取决于哪些因素？
6. ★★★ 在没有明确奖励函数、样本稀少的情况下，自主实现模型学习，被一些人认为是后训练的终极目标。当前的 RL 训练方法距离这个目标还有多远？你认为下一个突破最可能来自哪个方向？
7. ★★ 本章指出 LoRA 微调的成本并不高。那么，是否有可能给每个用户（或每个客户公司）训练一个专属的 LoRA，将用户记忆或企业知识写入参数，而非像第三章那样存储在外部知识库中？在什么场景下，“记忆写入参数” 比 “记忆存入知识库” 更有优势？又在什么场景下会适得其反？
8. ★★★ On-Policy Distillation 依赖更强的教师模型来监督学生。但 OpenAI 的 Weak-to-Strong Generalization 研究提出了一个反直觉的发现：弱模型的监督信号有时能激发强模型本身潜在但未被激活的能力。如果将这一思路应用到 Agent 训练，是否可能实现 “小模型教大模型” 的逆向蒸馏？
9. ★★ 过程奖励模型（PRM）评估每个思考步骤，而结果奖励模型（ORM）只看最终结果。但“正确的过程导致错误结果”和“错误的过程侥幸得到正确结果”哪个更值得奖励？在 Agent 的多步工具调用场景中，你会如何权衡？
10. ★★★ 本章讨论的评估数据集（如 SWE-Bench Verified、τ²-bench、AndroidWorld）既可以用于评估也可以用于后训练。但如果将评估集用于训练，它就不再是独立的评估集——这是否违反了训练集与测试集必须分离的基本原则？τ²-bench 的动态参数生成和 AndroidWorld 的参数化模板在一定程度上缓解了这个问题，但模板结构本身仍然是固定的。如何在充分利用评估数据的训练价值与维护评估独立性之间找到平衡？
11. ★★★ 本章提出 “先形后神” 的训练范式：SFT 到 “格式稳定、能力初具” 即止，然后切换到 RL。但实践中，如何判断 SFT 已经 “足够” 而应该切换？
12. ★★★ ReTool 的训练动态显示（见实验 7-14），少数超长响应会显著拖长整个训练周期——一批 rollout 里绝大多数已经生成完毕，却要等那几条最长的响应收尾，其间集群的 GPU 利用率很低。如何提升这种长尾响应场景下训练集群的资源利用率？
13. ★★★ 用 LLM 模拟环境（如模拟搜索引擎、模拟用户）训练 Agent 时，Agent 钻空子的对象从 “真实环境的规则” 变成了 “模拟器本身的偏见与漏洞”。这类训练中可能出现哪些具体的 reward hacking 行为？又该如何防范？

---

---

Agent 的持续进化

今天的 Agent 面临一个鲜明的能力悖论：它可以零样本解决从未见过的复杂任务，却可能在处理了一万次相似任务之后，第二天仍然犯下第一天的错误。能否自主从经验中学习，正在成为 Agent 从“会完成任务”走向“能够可靠工作”的关键能力，也是下一代模型的核心研究课题。然而，目前模型本身的持续学习能力仍远远不够。

原因在于，部署后的模型并不会因为一次推理自动改变参数。第二章讨论的上下文学习、状态维护和压缩，能让 Agent 在当前任务内适应；但上下文结束后，这种变化不会自然进入下一次任务。把对话存进记忆也不等于学会了新的行为：原始轨迹可能很长，其中既有有效策略，也有偶然成功、错误归因和不可信输入。

这里有一个容易混淆的区别：保存经历不等于从经历中学习。把一百条轨迹放进长上下文或向量库，可以帮助模型在需要时找回某个案例，却不会自动完成跨案例比较——哪些步骤在成功轨迹中反复出现，哪些做法只在旧版接口上有效，某次成功究竟来自正确策略还是环境偶然。学习发生在系统主动完成“评价、对照、归纳、验证”之后，而不是发生在日志写入磁盘的那一刻。第三章的用户记忆主要沉淀“用户与世界是什么样的”，本章的经验学习则要进一步沉淀“在什么条件下应该怎样行动”；前者让 Agent 记得更多，后者才让它从聪明变得熟练。

那么，为什么不让模型在每次任务后直接训练自己？因为生产环境很少提供干净的学习信号。用户满意不代表合规，测试通过也可能源于删除了失败用例；一次局部更新还可能造成能力遗忘、策略漂移或安全退化。若允许正在运行的模型依据未经验证的反馈直接修改自身，错误经验和提示注入就可能被固化，并在后续任务中持续放大。基础模型的周期性训练可以提升通用能力，却无法及时吸收每个 Agent 每天遇到的私有规则、工具变化和局部经验。

因此，在模型自身尚不能可靠地持续学习时，必须先把 “学习” 构造成模型外围的一套自主系统：记录运行证据，验证结果与过程，从多条轨迹中提取共性，再决定应更新知识、指令、程序还是模型参数。所有修改先形成待验证版本，经过回归测试和安全检查后，才能改变下一轮运行。这不是对模型学习能力的替代，而是在当前技术条件下让 Agent 获得持续学习能力的工程路径。

前面的章节已经给出了这套系统所需的主要部件。第二章处理任务内状态，第三章提供知识基础设施，第五章赋予 Agent 创造工具和修改系统的元能力，第六章建立评估与验证，第七章说明如何更新模型参数。第八章的任务，是把这些部件组织成图8-1所示的持续进化闭环。

持续进化需要来自可追溯的运行经验、能够改变后续行为，并经过验证没有造成明显退化。本章首先讨论如何判断一次运行究竟好在哪里、错在哪里；然后比较四种更新方法及其适用边界；接下来讨论这些更新如何在长期运行中被验证、发布、修订与淘汰。

从运行轨迹中获得学习信号

持续进化的起点不是“总结”，而是“评价”。如果系统不知道任务是否完成，也不知道哪一步造成了成功或失败，那么语言模型生成的反思只能是一种猜测。错误的评价一旦进入长期知识、系统提示或训练数据，影响会跨越后续任务不断放大。

有些任务的结果相对容易验证。Coding Agent 可以运行测试、类型检查和性能基准；替用户办理退款的 Agent 可以查询订单状态和实际退款金额。这类信号来自环境中的真实状态，通常比模型对自己行为的描述可靠。不过，结果正确并不代表过程正确。删除失败的测试用例也能让测试通过，口头承诺用户 “我们会在 7 天内退款，请耐心等候” 也可能得到暂时的满意反馈。因此，可靠评价既要看结果，也要检查达成结果的路径。

更多任务没有单一的正确答案。客服是否耐心、是否提供了合规范围内的变通方案，研究报告是否抓住了关键证据，生成文本是否自然简洁，都需要结合语境判断。此时可以使用第六章介绍的 LLM-as-a-Judge，但不能只让评委给出一个模糊总分。更有效的做法是预先定义评价量表（Rubric），要求验证器逐项给分、引用轨迹证据，并在证据不足时明确表示不确定。

图8-2给出了一个三层验证结构。底层的结果验证器读取测试结果、数据库状态和工具返回，回答“事情是否真的办成”；中间的过程验证器检查业务规则、权限和动作序列，回答“是否以允许的方式办成”；上层的质量验证器依据 Rubric 评价语言与策略，回答“是否办得合适”。越靠下的指标越应依赖代码和环境真值，只有难以形式化的部分才交给语言模型。

以客服 Agent 为例，一套有用的 Rubric 至少应覆盖表8-1中的几个维度。前五项主要约束底线，后两项衡量服务质量。这样的拆分比“用户是否满意”更有诊断价值：用户可能因为 Agent 违规退款而满意，也可能因为合规限制而不满，单一满意度无法区分两者。

表8-1 客服 Agent 的轨迹评价维度

维度	验证问题	主要证据
任务结果	用户的核心诉求是否得到解决	最终环境状态、工具结果
规则遵从	是否违反政策、权限或必要流程	政策库、动作轨迹
隐私边界	是否泄露不应提供的信息	回复文本、数据访问记录
事实可靠性	陈述是否有知识或工具结果支持	引用来源、工具返回
承诺—行动一致性	声称完成的操作是否真实发生	回复与工具日志对照
表达质量	是否自然、简洁，避免重复与模板化	对话全文、语言 Rubric
合规变通	原方案不可行时，是否找到允许的替代路径	用户目标、政策与后续动作

其中，“承诺—行动一致性”尤其适合 Agent 场景。传统文本评价只读最终回复，容易把“我已经为你提交退款”当作良好服务；轨迹评价则会继续检查是否真的调用了退款工具、调用是否成功、订单状态是否改变。“合规变通”也不是鼓励模型随意突破规则，而是要求它理解用户的真实目标，在退款不可行时检查改签、延期或部分补偿等合法选项。

验证结果不应被压缩成一个标量。一次轨迹评价更像一份结构化诊断：任务部分成功，规则遵从通过，但出现了一处无证据陈述、一处虚假承诺，回复还重复解释了三次政策。维度化信号既保留了问题性质，也保留了证据位置。后续模块才能进一步判断：无证据陈述是缺知识、缺引用要求还是模型能力不足；虚假承诺应修改提示词，还是应在 Harness 中增加回复与工具状态的一致性检查。

LLM 验证器本身也需要校准。生产系统通常准备一小批由专家标注的轨迹，检查验证器在每个维度上的一致性；高风险或低置信度案例交给第二个模型或人工复核；模型版本变更后重新运行校准集。验证器负责给出评价和证据，至于应修改 Agent 的哪个部分，则应由独立的诊断与进化模块决定，避免同一个模型既当裁判又直接改写规则。

实验 8-1 ★★：为客服 Agent 构建轨迹验证器

实验目的：把客服 Agent 的运行轨迹转换成带证据的结构化诊断，为后续的经验提炼提供可靠学习信号。

实验说明：对照“只输出一个总分”和“逐维度输出结论、证据与置信度”两种验证方式，观察哪一种更容易区分任务失败、规则违规、虚假承诺和表达问题。

实验说明了什么：持续进化不能只依赖成功率或单一分数。只有保留“哪里错、为什么错、证据在哪里”，后续模块才知道应该更新知识、Prompt、程序还是模型参数；低置信度案例也不应自动进入学习集。

Agent 持续进化的四种方法

学习信号说明 Agent 应当改变，但没有说明改变应发生在哪里。选择更新方式的首要依据不是经验出现了多久，而是目标能力能否被某种载体自然表达。事实和经验适合写成知识文档；可以清楚语言化的策略适合写入提示词或 Skill；可以精确执行的流程与约束适合写成程序；感知、语言风格和隐式策略等高维能力则必须进入模型参数。图8-3展示了这四种方式及其关系。

表8-2给出了一个紧凑的比较。四种方式并不互斥：医疗影像 Agent 依靠参数识别病灶，用知识库提供最新指南，再用代码计算风险指标；客服模型的自然语气来自后训练，具体企业政策由知识和 Skill 提供，关键合规则由服务端代码兜底。

表8-2 四种持续进化方式的适用边界

更新方式	适合承载	主要优势	主要局限
经验知识库	事实、经验规律、例外与来源	更新快、可追溯、可按需检索	依赖检索和模型正确应用
Prompt 与 Skill	需要理解语境、例外和优先级，但仍能用自然语言说明的判断原则	可解释、作用范围可控	容易膨胀、冲突或被忽略
程序与 Harness	可确定解析、可执行验证和高风险硬约束	可测试、执行稳定、成本低	开发与维护成本较高
模型参数	高维感知、生成风格和隐式策略	泛化能力强、推理开销低	更新与回归成本高

将经验沉淀为知识

最轻量的进化方式，是把多次运行中反复出现的经验整理成可检索的知识文档。这里所说的“经验知识库”与第三章共享存储、索引和检索技术，但知识来源和验证目标不同。第三章主要从用户对话、文档和数据集中提取“用户与世界是什么样的”；本章则从 Agent 的行动轨迹和结果中提取“在什么条件下应该怎样做”。例如，“该航空公司要求特殊餐食提前二十四小时预订”是领域知识；“订票前先检查特殊餐食截止时间，避免付款后才发现无法满足需求”则是行动经验。

原始轨迹不适合作为正式知识单元。它既长又嘈杂，包含工具原始输出、偶然的绕路和环境细节。更稳妥的系统保留三层数据：不可变的原始轨迹用于审计，单次运行分析记录本次成败与经验草案，多条同类轨迹再被比较、聚类和归纳，形成面向未来的 Markdown 知识文档。正式文档通常写清适用场景、推荐策略、禁止做法、例外条件、证据来源和最近验证时间，而不是复述某一次任务的完整过程。

这种设计与第三章的 User-as-Code 有相同的两阶段思想。User-as-Code 先把对话事实追加到不可变日志，再周期性重建结构化用户模型；经验学习同样应先保存证据，再离线生成可变知识。图8-4展示了这一过程。把记录与整理分开，可以避免一次偶发成功或网络故障立即改变 Agent，也使系统能够在看到多条成功和失败后再判断共性。

经验文档不是简单的轨迹摘要。真正有迁移价值的内容来自对照：同类成功轨迹做了什么，失败轨迹缺少什么；某种策略在哪些环境版本中有效，在哪些前置条件下失效。第三章已经介绍知识抽取、聚类与检索，本章不再重复这些算法，而把重点放在轨迹评价如何成为抽取条件，以及抽取出的知识是否能提高后续任务表现。

一个完整的知识提炼管道可以分成五步。首先保存不可变轨迹和环境结果；然后为单次运行生成结构化分析，列出任务类型、所需能力、观察到的策略、错误与例外；接着按任务族聚合同类运行，为每条经验草案建立“哪些轨迹支持、哪些轨迹反驳”的证据表；只有达到支持门槛的草案才写入正式文档；最后在未参与提炼的新任务上测试迁移效果。正式知识与草案分析分库存放，使系统可以重新归纳而不篡改原始证据，也可以在环境版本变化时精确撤销某条结论。

GAIA 经验学习提供了一个直观例子。GAIA[^gaia-2023] 包含需要综合搜索、网页阅读、文件处理和计算的多步骤问题，AWorld[^aworld-2025] 则提供运行 Agent、调用这些工具和保存轨迹的执行环境；前者像试卷，后者像考场与实验记录系统。旧式做法是在一次任务成功后立刻生成策略摘要并向量化入库；更严格的实现会先用 GAIA 答案验证或其他环境验证器标记成功、部分成功和失败，再比较同一任务族的多条路径。成功轨迹贡献策略草案，失败轨迹贡献排除性知识，部分成功轨迹则帮助识别“哪一段有效、哪一段仍有问题”。Reflexion[^reflexion-2023] 所提出的自然语言反思可以参与生成经验草案，但反思本身不是证据；只有与环境结果相符、得到跨轨迹支持并在新任务上显示正向迁移的内容，才应进入正式经验文档。

实验 8-2 ★★：从 GAIA 轨迹提炼经验知识文档

实验目的：检验多条已验证轨迹归纳出的经验文档，是否比一条成功轨迹的摘要更能迁移到新任务。

实验说明：比较“不使用历史经验”“检索一条相似轨迹摘要”和“检索由多条轨迹共同支持的知识文档”三种方式，并把提炼用的任务与迁移任务分开。

实验说明了什么：经验不是“记住一次成功”，而是从成功、失败和部分成功的对照中归纳出适用条件、例外和证据来源。若文档不能提高未见任务的表现，或会带来负迁移，就不能算学会了经验。

[^reflexion-2023]: Shinn, N., et al. Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv:2303.11366, 2023.

[^gaia-2023]: Mialon, G., et al. GAIA: a benchmark for General AI Assistants. arXiv:2311.12983, 2023.

[^aworld-2025]: Yu, C., et al. AWorld: Orchestrating the Training Recipe for Agentic AI. arXiv:2508.20404, 2025.

将经验写成指令

经验知识库给 Agent 提供“可以参考的资料”，Prompt 和 Skill 则规定“应该怎样行动”。当多条相似轨迹反复暴露同一种策略错误，而且错误能够用语言清楚描述时，才值得把经验提升为指令。这里先把三个概念分开：系统 Prompt 对所有任务生效，Skill 只在匹配到某个领域或工具时按需加载，程序/Harness 负责权限和其他硬约束。

Andrej Karpathy 将这种做法称为系统提示学习（System Prompt Learning）[^karpathy-system-prompt-learning]：模型遇到问题后，用一句清楚的话提醒未来的自己。DSPy[^dspy-2023] 在开发集上搜索指令和示例；OPRO[^opro-2023] 根据历史提示词及其得分提出提示提案；GEPA[^gepa-2025] 从失败轨迹的自然语言反思中生成并筛选提示提案。这些方法适合离线批量优化；生产环境更适合使用可审计的最小更新提案，并保留快速回滚路径。

系统提示学习与第二章的提示工程不是一回事。第二章讨论怎样组织一份好 Prompt；本节讨论什么反馈足以触发修改，以及更新提案怎样安全发布。修改应是带来源的最小 diff，而不是让模型每次都重写整份 Prompt。待验证版本必须同时在触发失败的边界集和正常工作的保留集上测试，前者要改善，后者不能退化。

例子一：基于失败轨迹优化提示词中的规则

第六章(chapter6.md#人机交互型评估环境)用 τ-bench/τ²-bench 说明了航空客服 Agent 的评估方式：用户逐步透露需求，系统既检查订单等环境状态，也检查对话中是否给出了必要信息。该章的失败归因还强调，不能只记录“失败”，而要找到首个错误步骤。

本例的 bad case 是：用户对退票、改签费或行李政策不满，Agent 没有查政策、解释规则或寻找允许的替代方案，就调用 transfer_to_human。普通政策争议不需要转接；用户明确要求人工或出现安全/人身风险时才必须转接。因此，问题不是“Agent 不够礼貌”，而是 Prompt 没有写清转接边界。

这条诊断可以直接变成提示词中的一条规则：先查询并解释政策，识别用户真正想解决的目标，提供合规替代方案；只有在明确要求人工或超出权限/涉及安全时才转接。

实验 8-3 ★★：基于失败轨迹优化航空客服的系统 Prompt

实验目的：让航空客服 Agent 修复“遇到普通政策争议就过早转人工”的行为，同时保留明确要求人工和安全事件的转接能力。

实验说明：从失败轨迹中提取规则遵从、任务解决和合规变通三个维度，生成一条带来源的最小 Prompt 补丁，再与初始版本、人工调优版本做同条件对照。更新提案只有在边界案例改善、旧任务不退化并通过发布门槛后，才进入灰度阶段。

实验说明了什么：Prompt 自动优化的重点不是让模型自由改写一大段文字，而是把可归因的失败转成作用域明确、可回滚、可验证的局部规则。

例子二：需求澄清 Skill——从“直接开工”到“先确认再执行”

第二章介绍了如何编写一份 Skill。这里假设系统已经有一份初版的需求澄清 Skill，关注的是另一件事：当 Agent 在生产环境中不断收到用户反馈时，如何自动判断“什么时候应该先问，问什么，什么时候可以直接开始”是否需要更新。

这是一个典型的流程性问题。用户说“把登录页改成支持企业登录”，Agent 如果立刻开工，可能在身份提供商、回退方式、兼容旧用户和上线范围上做出用户没有想过的选择；如果无论任务大小都先列十几个问题，又会把简单修改变成一次访谈。问得太少会导致返工，问得太多会增加打扰。 Skill 要表达的不是“所有任务都必须确认”，而是一条带作用域的判断路径。

一个初版流程可以这样写：先判断任务的歧义程度、风险和返工成本；低风险、容易撤销的小改动，说明假设后直接执行；涉及架构、数据、权限、公开接口或大范围改动时，集中提出少量真正会改变方案的问题；得到答案后生成短 Spec 或 Plan，列出目标、非目标、关键取舍、假设和验收标准，交给用户确认；确认后再执行，过程中发现原 Spec 不成立时暂停并重新确认。

持续进化从运行证据开始。系统应同时记录任务、澄清问题、Spec 版本、用户修改、执行结果和交付后的返工。负反馈可能是“做出来的和我想象的不一样”，也可能是“你问得太多了”；正反馈则包括用户一次确认后顺利交付、主动修改 Spec 后减少返工，以及在低风险任务中没有被多余问题打断。单独保存一句抱怨不足以触发更新，必须把反馈和具体轨迹、任务类型以及结果关联起来。

当多条轨迹反复指向同一个缺口时，Agent 可以提出最小 Skill 更新提案。例如，多个涉及认证架构的任务都在交付后才发现需要兼容旧登录方式，规则草案可以要求在执行前确认“身份提供商、回退路径和兼容范围”；如果大量拼写修复都被 Agent 先问一轮，规则草案则应收窄高风险与高歧义的触发范围。模型只生成带来源的更新提案，不能直接改写正式 Skill；合并、冲突处理、版本化和回滚由模型外代码负责。

拟议流程需要通过对照实验验证。可以比较“直接执行”“先提问再执行”和“提问后生成 Spec、确认后执行”三种策略，并按任务复杂度分层。评价指标至少包括需求偏差率、交付后的返工次数、澄清轮数、首次有效产出时间、用户放弃率、Spec 被修改的比例和高风险操作错误率。更新提案只有在减少需求偏差的同时没有显著增加打扰，并在未参与提炼的任务上通过回归，才进入灰度发布。

这个例子还说明了 Skill 与 Harness 的边界。Skill 负责理解语境并主动提出问题、整理 Spec 和说明取舍；Harness 负责在缺少确认时否决高风险写入、直接操作 main 或绕过发布流程。否决器不能替模型决定 PR 应该怎样描述，也不能代替模型选择需求方案。随着经验积累，流程可以从一条 Skill 规则扩展为结构化 Spec、状态机和验证程序，稳定的对话轨迹还可以进一步生成第七章所需的 SFT 或偏好训练数据。

实验 8-4 ★★：从用户反馈中进化需求澄清与 Spec 确认 Skill

实验目的：检验 Agent 能否在“需求偏差”和“交互打扰”之间找到更好的澄清策略，并把经过验证的改进写回 Skill。

实验说明：准备一组低风险、低歧义任务和一组涉及架构、权限、数据或公开接口的高风险任务，比较直接执行、提问后执行、提问后 Spec 确认三种流程。记录用户回答、Spec 修改、交付结果和返工反馈，让 Agent 生成 Skill 更新提案；提案必须经过留出任务回归、打扰成本检查和高风险否决器验证。

实验说明了什么：持续进化不是把每次抱怨直接追加到 Prompt，而是从结果和反馈中识别作用域，提出最小指令更新，再用独立评价器决定是否发布。Skill 负责主动规划和沟通，Harness 负责在模型判断失误时兜底。

[^dspy-2023]: Khattab, O., et al. DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines. arXiv:2310.03714, 2023.

[^opro-2023]: Yang, C., et al. Large Language Models as Optimizers. arXiv:2309.03409, 2023.

[^gepa-2025]: Agrawal, L., et al. GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning. arXiv:2507.19457, 2025.

[^karpathy-system-prompt-learning]: Karpathy, A. “We’re missing (at least one) major paradigm for LLM learning … system prompt learning?” X, May 11, 2025. https://x.com/karpathy/status/1921368644069765486

将经验写成程序

当经验描述的是稳定、重复并且可以验证的操作时，每次都让模型重新阅读文档和推理并不经济。此时更合适的做法是把经验编译为工作流、工具或 Harness 代码，使一次探索变成可重复执行的程序。第五章已经说明 Coding Agent 如何读写文件、运行测试和生成系统；本节关注的不是一般代码生成，而是 Agent 如何根据自己的轨迹修改未来版本的自己。

可修改的对象远不止新工具。操作层可以把浏览器轨迹编译为参数化工作流，或为变化的 API 生成适配器；控制层可以修改工具路由、重试、熔断和上下文压缩策略；验证层可以根据生产失败新增参数检查、状态验证器和回归测试；架构层则可以增加 Reviewer Agent，改变规划与执行之间的信息流。

浏览器工作流说明了程序化经验的价值。它可以类比电子表格的宏录制：第一次发送邮件时，多模态 Agent 通过观察—思考—行动寻找 “撰写、收件人、主题、正文、发送” 这些控件；以后发送另一封邮件时，流程没有变化，只有收件人和内容不同，没必要再次调用模型从像素和 DOM 中重新发现整条路径。系统要做的，是把第一次探索产生的轨迹编译成一个带参数、状态检查和版本信息的小程序。

图8-4所示的知识提炼过程在浏览器场景中对应一个更具体的生命周期：

1. 捕获轨迹：记录导航、点击、输入、下拉选择等动作，保存动作参数、当时的 URL，以及 XPath、CSS 等元素定位证据。定位信息只用于再次寻找元素，不能证明任务已经完成。
2. 参数化：把首次运行中的字面量识别为模板变量，例如将 test@example.com、邮件主题和正文替换为 {recipient}、{subject} 和 {content}；其余稳定动作保持不变。
3. 定义状态检查：为动作增加执行前检查和执行后检查，例如 “发送按钮当前可见”；为整个工作流增加最终状态检查。动作执行成功与任务成功是两件事，最终状态检查必须读取真实页面或后端状态。
4. 独立回放验证：系统必须把沙盒账号或测试站点重置到独立初始状态，再完整回放录制下来的程序；每一步的执行前检查、执行后检查和最终状态检查全部通过后，才能发布。
5. 匹配与回放：新任务到来时，先在正式能力库中按意图和关键词寻找工作流，提取本次参数，然后由 Playwright 直接执行。回放路径不需要逐步调用 LLM，但仍需等待元素可用并完成所有状态检查。
6. 失效与重学：找不到目标元素、状态检查不通过、API Schema 改变或最终状态错误时，回退到完整 Agent 重新探索。

PreAct[^preact] 的实验中，这类程序在重复任务上实现了 8.5–13 倍的端到端加速，回放阶段不需要逐步调用语言模型；更重要的结论是，流程记忆必须同时具备动作前验证、动作后验证和独立回放验证。否则系统很容易得到一种危险的假象：每个按钮都点过了，但某个字段其实为空，任务从未真正完成。

实验 8-5 ★★★：从浏览器轨迹生成可验证工作流

实验目的：验证网页 Agent 能否把一次探索转化为可复用工作流，并在页面变化或状态异常时拒绝错误回放。

实验说明：把一次成功轨迹编译成带参数和状态检查的待验证工作流，与“每次都重新探索”的基线比较；再改变页面或制造假成功，观察待验证工作流是否失效并回退到完整 Agent。

实验说明了什么：流程记忆的价值不在“动作被重复执行”，而在任务最终状态仍然正确。可复用工作流必须有独立验证和失效机制，否则加速只是把错误更快地重复。

Agent 修改自己的代码不意味着运行中的进程直接覆盖自身。生产系统应从当前稳定版本创建隔离更新分支，由 Coding Agent 生成最小补丁，依次通过静态检查、单元测试、安全扫描、失败轨迹重放和旧任务回归，再生成可灰度部署的新版本。这把“自我修改”转化为可审计的软件发布流程，也正是第八章与第五章的边界：第五章提供修改系统的能力，本章提供由经验触发、以验证闭环约束的自我修改方法。

Git worktree 和 Pull Request 是软件开发流程中一个很好的例子。Skill 应主动指导 Agent：先为任务创建独立 worktree，确认需求和 Spec，完成实现与测试，提交有意义的 commit，并在 Pull Request 中写清背景、方案、测试结果和剩余风险。Harness 不负责替模型做这些判断，但可以在它准备结束任务时检查是否仍在 main 上直接提交、是否遗漏 worktree 或 Pull Request；一旦违反边界就否决这次操作，要求 Agent 返回修复。这样，Skill 负责提出和执行流程，Harness 负责在模型判断失误时兜底。

仅有“补丁尽量小”还不足以支持可靠归因。每个修改请求还应是一份可证伪的变更契约：列出失败证据、推断根因、归属的 Harness 组件、修改提案、预期修复的行为、可能受损的既有行为，以及分别验证两者的用例。Agentic Harness Engineering 将这种做法概括为组件、经验和决策三层可观测性：可编辑组件都有文件级表示；海量轨迹先整理为可逐层下钻的证据；每次编辑在执行前声明影响预测，再由下一轮结果验证[^ahe-2026]。这样，分数上涨才能与某个具体机制建立联系，而不只是一次不可解释的试错。

提案生成器的输入也不应只有失败案例。Self-Harness 的做法还会提供必须保留的成功行为和此前被拒绝的修改记录[^self-harness-2026]。前者告诉 Agent 哪些性质不能在修复时被破坏，后者避免它换一种说法重复提交已经失败的方案。失败证据、成功约束与历史尝试共同构成一个有边界的方案空间，比把全部源码和原始日志无差别塞给修改 Agent 更容易产生局部、可验证的改动。

工具创造也遵循同一个协议。Alita[^alita-2025] 给出的案例是：Agent 要从一段由《指环王》中咕噜配音演员解说的 YouTube 360 VR 视频中，找出恐龙首次出现后紧接着提到的数字。它发现自己缺少字幕读取能力后，搜索并测试 youtube-transcript-api，将其封装为新的字幕工具，最终从字幕中得到答案 100000000。只有安全扫描、功能测试和后续任务复用都通过，新工具才进入能力库。

实验 8-6 ★★★：由失败轨迹触发 Agent 自我修改

实验目的：检验系统能否把“不可重试错误被反复调用”的经验写入重试与熔断程序，同时保留临时故障的恢复能力。

实验说明：比较“只在 Prompt 中提醒不要重试”和“修改程序中的重试策略”两种修复。修改提案必须经过失败轨迹重放、正常故障回归和安全发布门槛，且不能修改验证器或稳定版本。

实验说明了什么：能确定执行的约束应该进入程序，而不是继续堆在 Prompt 里。Agent 可以提出代码提案，但“是否能发布”必须由模型外的测试、审计和回滚机制决定。

验证层也可以采用同一协议：当多条用户纠正、点踩或事后审计都指向“高风险操作未经确认”时，系统生成一个确认门禁提案。提案必须在边界任务和正常任务上都通过验证，且安全门本身不能被提案修改。

实验 8-7 ★★：由用户反馈触发高风险操作确认门禁

实验目的：检验系统能否从用户纠正和事后审计中发现安全流程缺口，并为高风险工具调用生成确认门禁。

实验说明：用危险操作边界集和正常操作保留集共同评价门禁提案。提案既要拦住未经确认的高风险调用，也不能阻断正常任务；生成提案的 Agent 无权修改安全测试和批准规则。

实验说明了什么：安全能力的进化不能由修改者自证成功。真实模型生成的更新提案可能被安全门拒绝，这正说明独立验证器和不可修改的可信根比“提案看起来合理”更重要。

[^preact]: Li, Bojie. PreAct: Computer-Using Agents that Get Faster on Repeated Tasks. arXiv:2606.17929, 2026.

[^alita-2025]: Qiu, J., et al. Alita: Generalist Agent Enabling Scalable Agentic Reasoning with Minimal Predefinition and Maximal Self-Evolution. arXiv:2505.20286, 2025.

将经验写入参数

知识、指令和程序都建立在一个前提上：目标能力能够被外部符号较完整地表达。医疗影像理解、自然的语音韵律、消除文本的模板化“AI 味”、长程规划等能力却很难压缩成几条规则或工作流。这类能力必须通过后训练写入模型参数。弯引号的作用域判断处在中间地带：文档语法边界可以由程序解析，语境和例外需要 Skill 表达，跨任务的识别习惯才适合通过后训练内化。

是否参数化并不由“任务是否长期稳定”单独决定。新影像设备带来的域偏移仍可能需要 LoRA 或持续微调；快速变化的语言风格也可以通过周期性偏好训练适应。稳定性影响更新频率和成本，但能力的表示性质决定主要载体。反过来，一条长期稳定的转账审批规则也不应只依赖参数记忆，服务端代码仍需提供确定性保障。

第七章已经完整讨论 SFT、蒸馏和 RL，本节不重复。对持续进化而言，关键是把经过评价的生产轨迹转化为训练数据：高质量示范可以进入 SFT，明确偏好可以形成成对数据，具有可靠环境奖励的交互可以用于 RL。

从更新产物到更新“更新方法”

前面的四种方法讨论了经验最终写到哪里，但持续进化还有另一条正交的轴：系统正在优化的究竟是某份产物的内容，还是产生、管理和验证这些产物的方法。沿这条轴看，优化对象可以逐层扩大为：单条规则或记忆 → 结构化上下文 → 工作流 → Harness 代码 → 产生更新提案的优化器代码[^weng-harness-2026]。这不是五种新的更新载体，而是五种不同的搜索尺度；知识、Prompt、Skill 和程序都可能出现在其中多个层级。

最内层只修改产物内容。例如，根据失败轨迹给系统提示增加一条局部规则，或给经验文档补充一个例外条件。这种修改作用面小，容易归因和回滚，应当是默认选择。不过，反复让模型重写整份 Prompt 或记忆会产生另一类退化：为了追求简洁，旧版本中的少数重要细节可能在多轮改写后逐渐消失；相互制约的条件也可能被合并成一句过度抽象的原则。Agentic Context Engineering（ACE）把上下文维护成带稳定标识符的条目集合，由生成、反思和整理模块提出增量更新，再用确定性逻辑合并与去重，而不是每轮重写一个越来越短的文本块[^ace-2026]。它为本章前文“最小 diff、保留来源”的原则提供了一个具体研究实例。

再向外一层，优化对象不再只是“上下文里有什么”，而是“上下文应怎样被构造”。Meta Context Engineering（MCE）把两者拆成内外两个循环：内层在给定管理方法下优化当前任务的上下文产物，外层则根据多轮执行和验证结果，修改搜索、选择、过滤、格式化这些上下文操作本身[^mce-2026]。这一区分很重要：修改一条检索规则是在改内容管理机制；让系统比较多种检索与整理机制、保留迁移效果更好的版本，才是在学习“如何管理上下文”。

同样的思想可以扩展到工作流和整个 Harness。AFlow 把由多个 LLM 调用组成的工作流表示为代码图，通过执行反馈搜索节点与控制流的组合[^aflow-2025]；Meta-Harness 则让 Coding Agent 读取待验证 Harness 版本的源码、分数和轨迹，搜索决定信息如何存储、检索和呈现的代码[^meta-harness-2026]。第五章已经说明代码是 Agent 表达系统结构的通用语言；这里的新增之处是：代码不只是一次生成的产物，还可以连同评估历史一起成为持续搜索的对象。

优化层级并非越高越好。搜索一条局部规则只需少量边界案例，搜索完整工作流或 Harness 却要面对更大的方案空间、更高的评估成本和更严重的归因困难。一个明确、反复出现且能定位到单一组件的故障，应优先做可审计的局部补丁；只有当局部修改长期无法解决跨组件问题，或现有管理方法本身成为瓶颈时，才值得上升到工作流、Harness 乃至优化器层。无论上升到哪一层，评价器、权限边界和留出测试都必须位于可修改范围之外——搜索空间越大，这个可信根越重要。

实验 8-8 ★★★：把这本书交给 Hermes：它能升级自己吗？

实验目的：检验 Agent 能否阅读外部知识、发现自身问题，并在外部审查和测试约束下完成一次自我更新。

实验说明：不给 Agent 预设修复目标，而是观察它能否把书中的原则映射到自己的代码，并根据 Reviewer 的退回意见继续修正。稳定版本、验收测试和批准门槛始终位于它的修改权限之外。

实验说明了什么：自我修改不是“模型读完资料后直接改代码”，而是“理解原则 → 提出更新提案 → 接受外部检验 → 根据反馈修正”的闭环。一次提案被接受，只能证明更新流程成立，不能自动证明下游能力已经提升。

构建可长期运行的持续进化闭环

四种更新方式只有进入同一个自主循环，才会从单次优化变成持续进化。图8-5展示了生产系统中更稳妥的双循环结构：在线执行循环只完成任务并记录证据，不直接改写正式 Agent；离线进化循环聚合轨迹、诊断根因、生成更新提案，再通过验证门槛发布新版本。两者通过版本化的经验库和评估集连接。

Voyager[^voyager-2023] 展示了一个较完整的持续进化循环。它在 Minecraft 中根据当前能力选择新目标，通过环境反馈迭代程序，验证成功后把代码存入技能库，再组合旧技能解决更难任务。自动课程、可执行技能和环境验证缺一不可：只有技能库而没有课程，Agent 不知道下一步学什么；只有自我反思而没有环境验证，技能库会积累错误；只有探索而没有持久化，每次任务仍要从头开始。现实 Agent 的知识、Prompt、工具和参数虽然更复杂，基本学习过程是类似的。

具体来说，Voyager 由三个互相咬合的机制组成。自动课程生成器根据当前物品、环境和已掌握技能提出下一个难度适中的目标，使探索不是随机漫游；技能库把成功程序保存为可检索、可组合的代码，例如高级采集技能可以调用移动和制作等基础技能；迭代提示机制把环境观察、执行错误和自验证结果带回下一轮代码生成，直到任务真正通过。论文报告，相比当时的基线，Voyager 获得了 3.3 倍的独特物品、探索了 2.3 倍的距离，解锁关键科技树里程碑最高快 15.3 倍，并能把技能库迁移到新的 Minecraft 世界中；这些指标衡量的是能力随经历增长的曲线，而非冻结 Agent 的一次考试成绩。

从问题定位到经验沉淀

同一个表面问题可能需要不同的修改方式。客服 Agent 出现编造事实的幻觉，可能是由于知识库缺少事实，也可能是由于 Prompt 没要求引用；Agent 在没有完成任务时就作出 “已经完成” 的虚假承诺，既可以用指令纠正，也可以由 Harness 强制检查回复与工具状态。进化模块应先定位根因，再选择最小、最容易验证和回滚的修改对象。证据不足的偶发故障不应立即触发学习，而应继续积累样本。

这种选择也可能随经验增加而变化。一条新发现的策略先作为经验文档供检索；多个案例反复验证后，可以提升为知识。知识有三种表达方式：自然语言可以清晰描述的规则可以沉淀为 Skill；若步骤稳定、无需自然语言理解能力，可以编译成工具代码；若它实际上反映了广泛的隐式决策能力，则可进入后训练。

验证、发布与回滚

所有修改首先产生待验证能力版本或待验证 Agent 版本，而不是直接覆盖生产版本。知识文档要验证检索后是否提高新任务表现，Prompt 和 Skill 要检查边界案例与旧任务回归，程序要在沙盒和重置环境中运行测试，参数更新则要检查遗忘、安全和分布外任务。验证通过后仍应通过灰度发布观察真实流量；关键指标恶化时自动回滚到已知安全版本。

验证还要区分两种经常混在一起的能力。Harness 更新能力（harness-updating）是从轨迹中产生有价值的持久修改；Harness 受益能力（harness-benefit）是任务 Agent 在后续运行中找到、激活并正确使用这些修改。一个 Skill 本身可能写得完全正确，但较弱的任务模型没有在合适场景加载它，或加载后无法长期遵循，其中任一种都会让最终成绩看起来 “没有进化”。因此，不能只用端到端分数反推更新器好坏。Lin 等人的模型替换实验表明，这两种能力与基础模型能力的关系并不相同[^harness-benefit-2026]；具体强弱关系仍需更多任务验证，但将二者拆开评估是普遍适用的方法。

表8-3 持续进化的分层评估指标

指标	回答的问题	主要证据
更新提案有效率	更新器是否提出了有价值的修改	提案在独立验证中的接受率与增益
产物激活率	任务 Agent 是否在正确场景加载了新 Skill、记忆或工具	检索、路由与工具调用轨迹
遵循成功率	激活后是否按新规则或流程执行	动作序列与过程验证器
留出任务增益	整体是否改善了未参与进化的任务	held-out 成功率、质量与成本

诊断时可以固定同一份待验证 Harness，只替换任务模型：如果强模型能够受益而弱模型从不激活新产物，瓶颈在检索或路由；如果两者都能激活但只有强模型正确执行，瓶颈在指令遵循或长程规划；如果所有模型都退化，才更有理由怀疑修改本身。反过来，也可以固定任务模型、更换负责提出修改的模型，单独比较更新器质量。这样的双向模型替换，比只观察一个“进化后总分”更容易定位应该把能力预算放在哪里。

评估不是学习结束后的考试，而是自我进化过程中不可或缺的一部分。长期评价至少同时观察五类结果：

• 回退（regression），即新经验是否与已有的其他经验冲突，原有本来能通过的案例是否出现回退；
• 泛化能力，即新经验在测试集尚未覆盖的场景中带来的效果提升；
• Token 效率，即完成任务消耗的 Token 成本；
• 安全性，即规则、隐私和拒绝边界是否随进化漂移；
• 长期工程质量，即维护复杂度、架构一致性、所有权边界、向后兼容性以及未来迁移和调试负担是否恶化。

只解决了当前失败案例的问题，却在其他已有案例或新领域中退化，不是成功的持续学习。

实验 8-9 ★★★：评估 Agent 是否在持续进化

实验目的：区分“保存反馈”“不断追加反馈”和“能够更新、迁移并保留能力”三种行为，验证 Agent 是否真的在持续进化。

实验说明：让 Agent 先在一组任务中获得反馈，再面对表述变化、规则更新和原有能力保持等情况。对照静态记忆、只追加记忆和可替换/可淘汰的版本化记忆，观察经验能否迁移，也观察新规则是否覆盖旧规则、更新后是否遗忘。

实验说明了什么：持续学习至少包含四个环节——记住、迁移、更新和保持。最终分数高并不够；若系统继续使用已废止规则、靠违规捷径完成任务，或更新后破坏原有能力，都不能判定为持续进化。

可验证闭环的边界：当“完成”不等于“进步”

前面的闭环在 Coding、工具调用和业务状态变更等任务上最容易成立，因为测试、环境状态或确定性规则能够快速给出反馈。开放式科研、战略规划和复杂产品设计则不同：评价信号来得慢，正确答案不唯一，真正重要的目标——研究品味、长期价值、可维护性——还很难写成一个即时分数。此时 Harness 可能把流程执行得非常完整，却只是稳定地产出“像成果的东西”，没有推动真实目标。

自动科研是一个有代表性的压力测试。Trehan 与 Chopra 记录了四次从研究想法走向论文的端到端尝试，其中三次在实现或评估阶段失败，只有一次完成整条流水线[^llm-scientists-2026]。这些案例暴露的问题可以归成三类。第一是实现漂移：原方案一旦变难，Agent 会逐渐退回训练数据中更熟悉、但已经偏离研究假设的普通实现。第二是认识论上的过度乐观：信号仍可能只是噪声，系统却开始解释结果、添加补丁并宣布发现；失败和阴性结果则更容易被忽略。第三是隐性判断力不足：Agent 可以运行实验，却未必知道什么基线真正重要、哪个异常值得追踪、何时应该放弃假设。

这类任务不能靠换一个更会写论文的模型彻底解决，而要改变证据和监督结构：

• 结论与证据分离：对引用、数字、方法和结论分别记录证据来源，最终文稿只是证据图的一种呈现。ScientistOne 的 Chain-of-Evidence 设计把每类声明都链接到可审计来源，是这一方向的案例；它提高的是可追溯性，并不自动保证研究问题有价值[^scientistone-2026]。
• 保留负面结果：失败实验、被拒提案和停止原因写入不可变日志，与成功结果拥有相同的可检索地位。否则进化模块只看到幸存方案，会反复探索已经证伪的路径，并学会把模糊结果解释成成功。
• 维护搜索多样性：开放式搜索不应只保留当前得分最高的一条链。备选方案池还需按机制差异、代码新颖性或假设类型保留若干暂时低分但不同质的分支，避免所有方案收敛成同一个易得分模板。
• 让人类在更高层介入：人的作用不应只是在危险工具调用前点“批准”，还包括定义问题、审查评价标准、解释反常结果和决定何时停止。在反馈模糊的任务中，这些高层判断比逐步骤接管执行更难自动化，也更有价值。

同样的限制也存在于普通软件工程中：单元测试全部通过，只证明当前可观察行为满足测试，并不证明代码库在数月后仍易于维护。因此，上一节把长期工程质量列为独立指标，而不是期待当前任务的成功率顺便覆盖这些延迟外部性。持续进化的上限，最终取决于系统能否评价它真正关心的目标，而不只是最容易测量的代理指标。

持续进化的安全边界

Agent 的自我进化能力有可能把一次错误变成长期风险。网页、邮件和工具输出中的提示注入若被总结成经验，可能跨会话反复生效；自动搜索的恶意软件包若被封装成工具，影响会从一次沙盒运行扩散到所有后续任务；一个有缺陷的验证器还可能持续批准看似进步、实际退化的待验证版本。因此，Agent 自我进化系统除了验证 “是否更强”，还必须限制 “谁能改什么、依据来自哪里”。

第一道边界是证据与指令隔离。原始网页、工具输出及其 LLM 摘要都属于不可信证据，不能当作指令执行，也不能直接纳入 Skill 等长期能力。LLM 总结只是为了提高可读性和便于处理的转换，并不是把输入变得无害的净化过程。系统应按固定 schema 提取主张、原文位置和采集时间，同时保留原文与来源；提取出的字符串绝不能作为指令执行。模型给出的置信度也只是未经验证的估计，不能充当批准门槛。待发布内容还需通过确定性的 schema、允许列表和来源检查，再以版本化的 pull request 提交；独立于生成者的 reviewer 应对照原始证据审查变更，高风险 Skill 上线前还应经过人工批准。

第二道边界是待验证能力与正式能力隔离。新知识、Prompt、Skill、程序和参数都先进入不可服务真实流量的待验证区。新生成的代码和外部依赖还要经过沙盒、权限检查、供应链扫描与行为测试等安全检查。安全检查和回归测试通过后，才能服务真实流量，成为正式能力。

第三道边界是安全机制不可自我修改。业务 Agent 可以修改 Prompt、Skill、知识库、工具等，但不能修改批准自身更新的验证器、测试用例、发布门槛、审计日志和稳定版本备份。否则，一个 Agent 只需降低测试阈值或删除失败用例，就能把退化伪装成进步。

睡眠学习：整合、遗忘与能力保鲜

“睡眠学习” 是对离线整合的认知类比，并不要求任务真的在夜间运行。在线 Agent 的首要职责是完成当前任务并追加不可变证据；后台学习进程则在空闲期或满足门控条件时读取一批新经历，比较新旧结论、合并重复项、解决冲突、提出更新提案并运行回归。把采集与整理分开，可以防止一次偶发成功、网络故障或恶意输入立刻改写长期能力，也允许系统使用更大的批量和更便宜的模型完成整理。

一个典型的睡眠学习周期包含五步：

1. 触发：达到时间间隔、新增轨迹数量、存储容量或错误频率门槛，并确认当前没有高优先级在线任务；
2. 定向：读取正式知识、Prompt、Skill 目录及其版本，了解已有能力和不可修改边界；
3. 采集与整合：从近期已评价轨迹中寻找新信号，合并重复内容，标记冲突与适用条件，优先生成局部补丁；
4. 验证与审批：在迁移集、保留集和安全集上评估待验证版本，高风险写入等待人工批准；
5. 修剪与索引：更新检索索引，把长期不用或被新证据推翻的能力标为过期、归档或删除，同时保留来源和回滚版本。

用户记忆是最直观的例子，但要与行动经验区分。Claude Code 的自动记忆为每个项目维护 MEMORY.md 索引和按主题拆分的详细文件，会话启动只加载索引的有界前缀，其余内容按需读取；当索引接近上限时，系统要求 Agent 合并或移走细节。它说明纯文本记忆也需要容量约束、分层加载和主动整理，但当前公开机制主要是在会话中持续写入，并不能简单等同于一个固定的夜间后台任务[^claude-code-memory]。

Hermes 则给出了更完整的后台进化案例。它把长期信息分成有界的 MEMORY.md 与 USER.md、基于 SQLite/FTS5 的历史会话检索、按需加载的 Skill，以及 Honcho 等可选外部记忆提供者。历史检索返回原始消息而非先由 LLM 摘要，避免把检索和生成混成一个不可审计步骤。当一次任务包含较多工具调用、从错误或死路中恢复、收到用户纠正，或发现非显然工作流时，后台复盘可以创建或局部修订 Skill；记忆和 Skill 写入还可以经过审批门控。独立的 Curator 进一步跟踪 Skill 的使用、陈旧和归档状态，在空闲期执行确定性修剪，并可选择运行 LLM 合并；变更前保存快照，错误整理可以回滚[^hermes-memory]。这个案例把 “记录—整合—验证—修剪” 从比喻变成了可运行的能力生命周期。

持续进化也不是让知识、Prompt 和工具无限增长。第二章所说的上下文腐化会在更长时间尺度上重现：经验文档相互冲突，Prompt 被边界规则淹没，Skill 库出现重复能力，多次微调造成灾难性遗忘。系统需要周期性离线整理：

• 合并重复经验，保留来源和版本；
• 把局部规则从全局 Prompt 移动到领域 Skill，保持全局 Prompt 整洁；
• Prompt 和 Skill 保持结构清晰；
• 重新验证长期未使用的工具；
• 删除被新证据推翻的知识；
• 从原始基座模型重新训练 LoRA。

[^claude-code-memory]: Anthropic, “How Claude remembers your project”, 2026. https://code.claude.com/docs/en/memory

[^hermes-memory]: Nous Research, Hermes Agent Documentation: Persistent Memory, Skills System, and Curator, 2026. https://hermes-agent.nousresearch.com/docs/user-guide/features/memory ; https://hermes-agent.nousresearch.com/docs/user-guide/features/skills ; https://hermes-agent.nousresearch.com/docs/user-guide/features/curator

[^voyager-2023]: Wang, G., et al. Voyager: An Open-Ended Embodied Agent with Large Language Models. arXiv:2305.16291, 2023.

[^weng-harness-2026]: Weng, Lilian. “Harness Engineering for Self-Improvement.” Lil’Log, 2026. https://lilianweng.github.io/posts/2026-07-04-harness/

[^ace-2026]: Zhang, Qizheng, et al. Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models. ICLR 2026. arXiv:2510.04618.

[^mce-2026]: Ye, Haoran, et al. Meta Context Engineering via Agentic Skill Evolution. arXiv:2601.21557, 2026.

[^aflow-2025]: Zhang, Jiayi, et al. AFlow: Automating Agentic Workflow Generation. ICLR 2025. arXiv:2410.10762.

[^meta-harness-2026]: Lee, Yoonho, et al. Meta-Harness: End-to-End Optimization of Model Harnesses. arXiv:2603.28052, 2026.

[^ahe-2026]: Lin, Jiahang, et al. Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses. arXiv:2604.25850, 2026.

[^self-harness-2026]: Zhang, Hangfan, et al. Self-Harness: Harnesses That Improve Themselves. arXiv:2606.09498, 2026.

[^harness-benefit-2026]: Lin, Minhua, et al. Harness Updating Is Not Harness Benefit: Disentangling Evolution Capabilities in Self-Evolving LLM Agents. arXiv:2605.30621, 2026.

[^llm-scientists-2026]: Trehan, Dhruv and Paras Chopra. Why LLMs Aren't Scientists Yet: Lessons from Four Autonomous Research Attempts. arXiv:2601.03315, 2026.

[^scientistone-2026]: Meng, et al. ScientistOne: Towards Human-Level Autonomous Research via Chain-of-Evidence. arXiv:2605.26340, 2026.

本章小结

持续学习正在成为 Agent 最重要的能力之一，但今天的模型还无法自行完成可靠的持续学习。推理时的上下文适应不会自动持久化，未经验证的在线参数更新又会放大噪声、攻击和能力漂移。因此，现阶段更可行的路径，是在模型外围建立可验证的学习系统。

Agent 从与环境的交互和评价中获得学习信号，再根据能力的表示性质更新知识、Prompt、Skill、程序或模型参数。系统也可以进一步优化管理和生成这些产物的方法，但应优先采用可归因、可验证、可回滚的局部修改。遇到问题时，先判断它更适合由外部规则、程序流程、Skill 还是模型参数处理，再用独立的边界任务和原有任务检查修改是否真正有效。

持续进化需要把在线执行与离线学习分开：在线记录证据，离线生成并验证更新提案，再逐步发布、整理或回滚。这个闭环在结果可自动验证的任务上最可靠；对于目标模糊、反馈延迟的开放任务，人仍需参与问题定义和评价标准的制定。

思考题

1. ★★ 一条经验文档由三次成功轨迹和一次失败轨迹支持。失败发生在较新的 API 版本上。系统应如何判断这是经验被推翻，还是适用条件发生了变化？
2. ★★ 客服 Agent 的用户满意度上升，但规则违规率也上升。为什么不能把满意度作为单一学习信号？你会怎样设计护栏指标？
3. ★★★ 同一个“虚假承诺”问题可以通过 Prompt、Harness 检查或参数训练缓解。你会依据哪些证据选择修改位置？
4. ★★★ Agent 能修改工具和验证器，却不应修改批准自身更新的可信根。你会如何划分这两部分的权限和代码边界？
5. ★★ 经验知识库不断增长后，检索错误和知识冲突会抵消学习收益。如何设计版本、时效和淘汰机制？
6. ★★★ 参数学习擅长自然语言风格，却难以保证硬性业务规则。请为医疗客服设计一套参数、知识、Skill 和代码约束协同的持续进化方案。

---

---

多模态与实时交互

如果把模型的能力做一个面向应用的粗略划分，大致可以从三个方面来观察：理解、生成和交互。

• 理解回答的是“模型能否看懂并想明白”，包括理解文字、语音、图像和视频，以及在这些信息之上进行推理、判断与规划。
• 生成回答的是“模型能否把想法表达出来”，它可以生成文本和代码，也可以生成图像、视频、语音乃至动作。
• 交互回答的则是另一个问题：模型能否在持续变化的环境中，在合适的时机接收信息、采取行动，并根据反馈调整下一步。

理解和生成主要决定模型 “会什么” 以及智能上限；交互能力与智能上限并不直接相关，它主要决定模型能否在真实环境中把已有的智能有效地转化为任务结果。一个模型可能在数学推理或代码生成上非常强，却可能无法把实际任务做好。这和人的聪明程度与岗位表现之间的关系是类似的。

Agent 的交互对象不仅仅是文本和 API。当 Agent 需要听懂用户的语音指令、在屏幕上找到并点击正确的按钮、或控制机械臂精确抓取物体时，它进入了一个全新的领域：多模态实时交互——从纯文本输入输出扩展到多模态感知与实时响应。

语音：最自然的人机接口

语音的价值不只是把文字换成声音。正常说话的速度约为打字的四倍，而且不占用双手与视线，因此它天然适合把 Agent 放进持续工作、随时可能被打断的输入输出回路。语音输入法把口述转成文字，语音 Agent 则让用户直接与 Agent 协作；两者都可以支持引言中提到的 whisper coding。

本节同时讨论两个方向：用户对 Agent 说话，以及 Agent 代替用户对外部世界说话。语音模型决定“能回答什么”，交互架构决定“能否听清、及时回应、自然换手，并在通话中完成确认和工具调用”。后文先讨论交互时序，再讨论深度思考和表达质量。

交互时序：从级联到全双工

OpenAI 在 GPT-Live 的介绍中用“级联、轮次式、全双工”概括了语音系统的三种交互范式[^ch9-12]。它们不是简单的新旧替代，而是不同延迟、成本和可观测性约束下的取舍：

范式	核心结构	主要优势	主要限制
级联	VAD → ASR → LLM → TTS	模块清晰、易替换、易调试	延迟累积，副语言信息在接口处丢失
端到端 Omni	一个模型听、想、说	延迟较低，能保留语气、情绪和环境声	仍依赖轮次，训练和调试成本较高
全双工	持续听、持续说、持续决策	支持重叠说话、自然打断和连续流	模型训练、控制和评估都更复杂

贯穿三种范式的主线是：如何摆脱“轮流说话”和 VAD 对发言权的猜测。级联和 Omni 仍要划分轮次，只有全双工把“该谁说话”变成模型的持续决策。

[^ch9-12]: OpenAI. Introducing GPT-Live. 2026-07-08. https://openai.com/index/introducing-gpt-live/ 。本节“级联 / 轮次式 / 全双工”三分法即出自该文对 ChatGPT 语音三代演进的总结；文中“端到端全模态（Omni）”对应其“turn-based voice models”一类。

范式一 · 级联流水线（Cascading）

绝大多数商业语音助手都基于串行流水线（图9-1）：VAD 判断用户何时说完，ASR 把音频转成文字，LLM 理解并生成回复，TTS 再把文字念出来。模块化让每个组件可以独立优化，但每一级都可能增加等待时间。

模块	作用	典型瓶颈
VAD	判断是否说完	静音阈值带来等待和误切分
ASR	音频转文字	识别延迟与上下文丢失
LLM	理解、思考、生成	首 token 延迟，开启 reasoning 后等待更长
TTS	文字转语音	首包合成和播放缓冲

在一个简短、不开启 reasoning 的回复中，VAD、ASR、LLM 和 TTS 的等待会串行累积（图9-2）。真实数值取决于输入长度、模型、硬件、网络和负载。

生产环境的排队还会进一步放大空载延迟（图9-3），但这属于服务容量规划，本章不展开排队模型。

实验 9-1 ★：构建传统语音 Agent

本实验用 WebSocket 串起麦克风、Silero VAD、本地 Whisper、流式 LLM 和 Fish S1 TTS，建立后续方案的级联基线。保留的真实单轮证据证明媒体和模型链路确实跑通，但不把一次空载运行解释成并发或生产负载 benchmark。代码与验收记录见 chapter9/live-audio(../chapter9/live-audio/)。

附加项目：使用 WebRTC 构建“呼叫用户”的语音 Agent

电话 Agent 不一定要接入 PSTN。浏览器 WebRTC 就能复现“主动建立会话、询问缺失信息、复述确认并保存结构化结果”的闭环；需要联系外部机构时，再把同一个工具契约替换为合规的 PSTN/SIP 供应商。完整媒体链路、直接/ReAct 对照和验收证据见 chapter9/phone-agent(../chapter9/phone-agent/)。该项目保留原有 exp9-2 运行标识，但不再占用正文实验编号。

从串行到流式感知

图9-2描述的是“每一环跑完再交棒”的完全串行情形。生产系统仍可保留模块化分工，同时让各阶段尽早产出增量结果：

• ASR 边听边转：用户说话时持续生成临时转录，轮次结束后再确认最终文本。
• LLM 分段输出：第一段适合播报的文本生成后立即交给 TTS，不等完整回复。
• TTS 增量合成：持续返回音频块，让后续生成、合成和播放重叠进行。

“每一级都流式”不等于 ASR、LLM、TTS 从头到尾完全并行。标准级联中，ASR 可以与用户说话重叠，TTS 可以与 LLM 后续生成重叠，但最终回复仍依赖稳定转录。更激进的系统会根据部分转录提前启动 LLM；后续文本改变时，就必须取消、重启或修正生成。真正的抢跑需要提交、失效和回滚机制，不是打开 stream 开关就会自动获得。

普通流式化仍无法消除 VAD 的静默等待。传统 VAD + ASR 前端有三个问题：

1. 延迟累积：必须等待一段静音才能确认说完。
2. 信息丢失：有声/无声二值信号无法表达犹豫、情绪、附和和环境声。
3. 上下文被切断：邮箱、人名和专有名词可能被分片识别而出错。

真正的流式模型需要因果或分块编码器，并能增量解码。Whisper 的解码虽然是自回归的，但编码器需要完整音频段，因此不能直接等同于流式模型。RNN-T 和流式 Conformer 等传统流式 ASR 早已在工业界使用，本节关注的是在 LLM 骨干上加入语义级听觉感知。

基于 LLM 的流式听觉模型可以从连续音频中输出文本和语义事件，把“识别”和部分“理解”放进同一个模型。它保留从对话开始到当前时刻的上下文，也可以利用世界知识处理品牌、人名和专有名词；但模拟分块的耗时不能当作真正因果流式模型的性能承诺。

如果只想解决“用户是否说完”，也可以把轮次判断直接做进流式识别器：模型综合语义和静音判断一句话是否表达完整。端点判断的训练标签必须只使用决策时刻可见的信息，否则会因“上帝视角”产生线上无法复现的判断[^ch9-11]。这是一条比完整音频大模型更轻的路线。

[^ch9-11]: 把轮次判断做进识别器、以及“标签的上帝视角”这一诊断见 Li, Bojie and Noah Shi. The Trade-off Was in the Labels: Causal Supervision for Turn-Aware Streaming ASR. 2026（待发表）.

模型输出的不仅是文字，还可以包含声学事件标记：

• speak_start/end、interrupt：说话起止与打断意图；
• emotion：情感、犹豫等状态；
• laugh、sigh、noise：副语言和环境声。

这些标记和文字 token 形成统一事件流，Agent 可以据此识别犹豫、打断和环境变化，而不必把所有声音压成纯文本。

实验 9-2 ★：使用 Qwen2-Audio 模拟流式语音感知

Qwen2-Audio 本身不是流式模型。本实验用递增音频前缀模拟连续感知，并与 600ms VAD + Whisper 对照。它演示完整上下文对停顿和噪声场景的影响，但每次都会重新编码此前音频，因此不能把结果当作真流式模型的延迟承诺。

当前 canonical run 通过全部执行与溯源门禁，但只复现了 2/6 项预期行为：递增前缀实测为 8.4–11.3 秒，pause 样本漏报 silence，noise 样本仍误报 cough/laughter。这个负结果说明实验适合检查机制和失败方式，不能支持“一二百毫秒真流式感知”的结论。完整记录见 chapter9/streaming-speech(../chapter9/streaming-speech/)。

范式二 · 端到端全模态模型（Omni）

级联即使采用流式感知，听、想、说仍通过离散接口交接；情绪、语调和环境声等信息可能在转成纯文本时丢失。Omni 用同一个模型直接听音频、生成回复并输出语音，因而有机会保留这些信息，但训练、调试和替换组件的成本更高（图9-4）。

端到端的优势主要体现在延迟和非文字信息上，并不必然转化为更高准确率。自级联先用同一模型转录，再基于转录回答：当文字足以承载任务信息时，它可能纠正一次感知错误；当答案依赖语速、情绪或环境声时，纯文本瓶颈会不可逆地丢失证据。关键不在于是否有中间表示，而在于中间表示承载了什么信息[^ch9-13]。

Omni 仍然假设轮流说话，通常要靠 VAD 或语义端点划分发言权。用户报数字时的中途停顿仍可能被误判为说完；流式感知只能改善判断，不能取消轮次本身。

[^ch9-13]: 级联与端到端在准确率上的优劣何时逆转，以及如何依据任务性质预测其方向，完整的跨模态测量见 Li, Bojie and Noah Shi. The Cascade Gap: When and Why Self-Cascades Help Multimodal Agents. 2026（待发表）。

实时语音 API 通常处在级联与 Omni 之间：模型原生处理音频，但交互控制仍依赖 VAD，并通过打断和异步工具调用改善体验。Qwen3-Omni 的 Thinker-Talker 和 MiniCPM-o 的本地路径则说明，同一技术路线可以把思考、表达和多模态输入压到不同规模的模型中。这里更值得验证的不是模型榜单，而是端到端与自级联在不同任务上的失败方式。

实验 9-3 ★★：本地运行 MiniCPM-o 4.5，对比端到端与自级联

本实验固定一个本地 MiniCPM-o 4.5 revision，关闭 thinking mode，比较直接从音频作答与同模型自级联先转录再作答。它测的是音频信息是否被保留，不是后文的“边想边说”。

表9-1 MiniCPM-o 4.5 本地端到端与自级联结果（4 条机制检查，不是 benchmark）

任务类型	端到端	自级联	观察
语义算术（2 条）	1/2	2/2	自级联纠正了一个听写错误
副语言语速（2 条）	2/2	1/2	纯文本转录抹掉了快慢差异
合计	3/4	3/4	总分相同，失败位置互补

样本很小，不能据此声称哪条路径整体更准确或更快。完整硬件、版本、原始输出和真实 audio-to-audio 证据见 chapter9/end-to-end-speech(../chapter9/end-to-end-speech/)。

Step-Audio 2 展示了直接处理原始音频、同时输出文本和语音的端到端路线；它关注语义之外的情绪、语速、语调和环境声。Step-Audio R1 在此基础上进一步把思考能力内化到音频模型中，后文把它作为“边想边说”的案例。

范式三 · 全双工交互模型

Omni 仍然把对话分成“用户说”和“模型说”两个时段，但同声传译等任务要求两者重叠进行。全双工模型因此不再预设轮次，而是持续听、持续说，并不断决定继续、停顿、打断或调用工具。

研究上的先声是 Kyutai 的 Moshi（2024）。它并行建模用户和模型的音频流，因此重叠说话和打断可以成为模型的自然行为。

Thinking Machines Lab 将这类路线称为交互模型（Interaction Model）[^ch9-14]：交互性不再由 VAD 等外部 harness 拼接，而是内建在模型中。其微轮次机制以短音频块持续推进，让静音、重叠和打断都作为连续上下文保留。交互模型还可以把完整对话委派给后台推理模型，自己继续维持话头；后台结果返回后，前台再在合适时机接入。

[^ch9-14]: Thinking Machines Lab, “Interaction Models: A Scalable Approach to Human-AI Collaboration,” 2026-05. https://thinkingmachines.ai/blog/interaction-models/

OpenAI 的 GPT-Live 则把全双工路线带到生产规模：模型持续处理输入并生成输出，能等待用户、附和、被打断，也能处理实时翻译。它与交互模型一样，把复杂任务委派给后台模型，前台继续维持对话。

回顾这条叙事链：级联靠静音阈值猜测轮次，流式感知把判断升级到语义层，全双工则把“切换”本身变成持续决策。

认知时序：实时交互与深度思考

“交互表现”和“智能上限”是两个维度：前台模型要在用户仍然在线时回应，后台模型则可以花更多时间思考。下面三种方案是设计取舍，不是线性迭代；前两种可以套在级联或 Omni 上，只有第三种把思考与表达统一到端到端模型中。

方案	前台	后台	主要风险
快速应付、慢速纠正	先给即时答案	重新思考并补充	前后矛盾
快速交互、慢速提醒	维持话头并决定措辞	提供建议或工具结果	接口受限
思考与表达统一	边思考边说	与表达共享模型状态	训练和替换成本高

方案一：快思考应付，慢思考回答

快思考可以在几百毫秒内先给出应付性回应，慢思考则在后台完成更深的推导。它的问题是简单问题会被重复处理，复杂问题又可能出现前后不一致：快模型先建议购买，慢模型随后发现套餐缺少关键功能，用户在几秒内便听到相互冲突的答案。根本原因是两个实例各自完成了一次独立思考。

方案二：快思考交互，慢思考提醒

方案二让后台模型通过状态栏或专门接口向前台模型提供建议，前台继续维持话头并决定如何表达。它比方案一稳定，但通信仍然间接：前台可能误解建议，也看不到后台的中间思考；在后台完成前，用户追问时前台仍只能依靠自己的能力应答。它可以自然地“等结果”，但不能真正做到边想边说。

方案三：端到端思考与表达统一（以 Step-Audio R1 为例）

方案三把思考能力直接内化到端到端音频模型中。Step-Audio R1 用两个互补机制解决两个问题：**模态锚定思考蒸馏（MGRD）**让模型基于声学特征思考，MPS 双脑架构让构思与表达并行。前者保证“想得对”，后者解决“说得及时”。

理想情况下，模型应该从音高、节奏和语调判断情绪，而不是只看转录文本。所谓“文本代理思考”，就是模型用歌词中的负面词汇代替对旋律和声学特征的分析。MGRD 筛选真正引用声学特征的思考过程，再用这些数据训练模型，并通过强化学习防止模型跳过思考直接猜答案。

MPS 让构思脑持续产出思考片段，表达脑收到片段后结合已有回复立即生成语音。两者以流水线方式并行，因此不必等完整思考结束才让用户听到第一句话（图9-6）。

统一模型最紧密地实现了“边想边说”，代价是思考和实时表达需要一起重训；解耦路线更容易替换后台大脑，统一路线则更适合追求极致自然度的专门场景。两者是取舍，不是简单的替代关系。

更像人的语音合成

传统 TTS 过于流畅、零停顿，反而容易暴露机器身份。停顿、填充词和偶尔的重复，是人类表达不确定性和思考状态的信号。

可以让主 LLM 在文本之外输出控制标记，例如 THINKING、EMO:happy 和 SPEED:0.8x，由 TTS 将它们映射为停顿、韵律、语速或笑声、叹气等非语言音频。实现上可以自研支持控制标记的 TTS，也可以用 voice cloning 准备不同情绪和风格的参考音频。

实验 9-4 ★★：基于 Fish Audio 的控制标记驱动 TTS

使用 Fish Audio S1 构建多参考语音库，比较无控制标记、单一参考音和多参考音三种配置。执行层根据标记选择匹配的情绪、语速和风格。

多参考语音配置在三次位置平衡的音频盲评中获得最高分，真人客服感为 4.67/5；但预设的全部排序没有完全复现，因为无控制标记组高于单一参考音组。这个结果说明表达控制有帮助，却不能把一次小规模听感实验当作普遍的音质结论。完整的 24 条参考音频、A/B/C 媒体和验收记录见 chapter9/controllable-tts(../chapter9/controllable-tts/)。

Computer Use：GUI 自动化 Agent

读到这里也许会注意到，本章给语音的篇幅明显多于后两个场景——这是有意为之。在实时多模态这条演进线上，语音是走得最完整、最值得当作参考系的一个：从“串行流水线延迟太高”这个问题出发，经过端到端、全双工、边想边说等一系列方案，一直走到今天相对成型的终局，问题→方案→终局的全程都已经跑通。因此我们把它讲透，接下来的 Computer Use 和机器人两个场景，都可以对照语音这条脉络来看——它们各自走到了这条演进线的哪一段、卡在了哪里。

这三个场景看似不同，却面临相同的核心挑战：实时感知、低延迟决策、持续交互。语音场景强调“何时开口”，Computer Use 强调“下一步点哪里”，机器人强调“动作造成了什么后果”。三者都说明，模型在离线任务中答对问题，只是交互闭环的起点；只有能够持续观察、及时行动并检查结果，才算在真实环境中把事情做好。接下来看这些技术主题如何在视觉交互（Computer Use）和物理交互（机器人）中重现——首先把视角从听觉模态扩展到视觉模态：如果 Agent 不仅能理解语音，还能“看懂”屏幕并操作图形界面呢？

Computer Use（也称 GUI 自动化 Agent）让 AI 像人类一样通过观察屏幕、操作鼠标键盘来使用软件——比如打开浏览器搜索信息、在表格软件中填写数据、或在系统设置中调整配置。其核心是一个感知-思考-行动的循环（图9-7）：

1. Agent 对当前屏幕截图
2. 多模态模型接收截图和任务指令，输出一段思考和一个具体动作
3. 执行层在真实环境中执行该动作（移动鼠标、点击、输入文字等）
4. 等待界面响应后再次截图，进入下一轮循环

这里要区分“看懂界面”和“完成任务”。前者更接近多模态理解能力，可以用一次截图问答来测量；后者则要求模型把理解和生成动作放进闭环，处理页面加载、状态变化、误操作和不可逆后果。Computer Use 的难点因此不只是让模型在截图上答对，而是让它在每一步之后重新确认现实是否仍符合计划。

这个循环中有三个关键设计维度：动作空间（Agent 能执行哪些操作）、视觉定位（如何在截图中找到目标元素）、以及模型架构（如何从截图生成正确动作）。

动作空间设计

Anthropic 的参考实现把完整交互能力分成三类工具（图9-8）。这是一个清晰的动作空间设计，但不是模型供应商必须遵守的私有协议：只要 Harness 能把同样的截图、动作约束和执行结果转换成目标模型支持的消息与结构化输出，Claude、开放权重视觉模型和自托管端点都可以驱动同一个感知-思考-行动循环。

GUI 操作工具（computer tool）：鼠标操作包括移动（mouse_move）、左/右/中键点击、双击/三击、拖拽（left_click_drag），以及更精细的按下/松开（left_mouse_down/up）。滚动（scroll）支持四个方向并可配合修饰键。键盘操作包括逐字输入（type，每个字符间隔 12ms 模拟真实打字）、组合键（key，如 Ctrl+C）、长按（hold_key）。感知动作：截图（screenshot）、获取光标位置（cursor_position）、等待（wait）。

命令执行工具（bash tool）：提供持久的 bash 终端会话，120 秒超时，通过哨兵字符串检测命令是否执行完毕，多次调用之间保持环境状态（比如 cd 到某个目录后下次调用还在那个目录）。

文件编辑工具（str_replace_editor）：通过字符串匹配实现安全编辑，支持查看、创建、替换、插入和撤销操作，比直接覆盖整个文件更精确，不容易误改其他内容。

实验 9-5 ★：运行 Computer Use（Anthropic 参考路径或开放模型路径）

路径 A 使用 Anthropic Computer Use Demo：容器打包完整的 Ubuntu 桌面环境（含浏览器、终端等常用工具），前端接收任务，后端把指令与截图发送给 Claude，再执行模型返回的鼠标、键盘、终端或编辑动作。这条路径用于理解原生 computer 工具协议，不要求所有读者拥有 Anthropic API。

路径 B 使用本书的 chapter9/computer-use-open-model(../chapter9/computer-use-open-model/) companion：默认以开放权重的 Qwen3-VL 32B Instruct 驱动 browser-use，可通过 OpenRouter 托管 API，也可把 OPEN_MODEL_BASE_URL 指向自托管 vLLM/SGLang 或其他兼容端点。端点必须接收截图，并支持原生 JSON Schema；若只支持普通 JSON，可显式启用 schema-in-prompt 兼容模式。

两条路径使用同一只读任务和同一验收契约：最多 25 步，每步只执行一个动作，保留模型/端点身份、原始提供商响应、逐步截图、动作序列、最终答案和停止原因。模型不同就必须作为不同实验臂分别报告，不能把开放模型的结果冒充 Claude 复现，也不能把“容器启动成功”当成任务完成。动作间隔和规划质量是实测结果，不预设为 2–5 秒或必然优于其他模型。

视觉定位（Grounding）

在循环的每一轮中，模型需要在截图中准确定位目标元素——“搜索框在哪里？”“提交按钮的坐标是什么？”这就是视觉定位（Grounding）问题。当前主要有两大思路：一是把定位变成选择题——先把界面元素标注好编号，模型只需从中选一个；二是纯坐标预测——让模型像人一样直接“看”着截图报出坐标。其中选择题思路又有两种实现方式：纯视觉标注（原始的 Set-of-Mark，用分割模型在像素上切出候选区域）和结构化元素索引（DOM/Accessibility Tree，直接读取界面自带的结构）。选择题思路的共同优势，是把开放式的“在截图中找到按钮并预测坐标”转化为封闭式的“从已标注好的元素中选一个”——就像考试中选择题比填空题更容易答对一样，模型只需说“点击 [123]”而不是“点击屏幕左上角偏右大约 200 像素处的蓝色按钮”。

Set-of-Mark：视觉标注法。

原始的 Set-of-Mark（SoM）由微软研究院于 2023 年提出，最初是为了释放 GPT-4V 的视觉定位能力。它是一个纯视觉方法：用图像分割模型（SAM、SEEM 等）在截图上自动切出候选区域，为每个区域叠加编号标记，模型看到的是一张带编号的图，只需报出编号，由系统换算成对应区域的中心坐标。整个过程不需要 DOM，也不需要任何界面内部结构，因此原生桌面软件、游戏界面同样适用——只要分割模型能把候选区域切出来。

结构化元素索引：SoM 思想在 Web 上的结构化实现。

当界面本身能提供结构化信息时，标注可以做得更精确。现代网页在渲染之前就已经定义了完整的元素结构（DOM 树）和语义角色（哪个是按钮、哪个是输入框），无障碍接口（Accessibility Tree）为许多桌面应用提供了类似的信息。与其让分割模型在像素里猜“哪个区域是按钮”，不如直接问界面本身“你有哪些可以点击的元素？”。以 browser-use 项目为代表的 Web Agent 方案正是这样做的：从 DOM 中枚举可交互元素并编号，可以看作 SoM 思想在 Web 上的结构化实现（图9-9）。流程分四步：

1. 通过浏览器调试接口（CDP，Chrome DevTools Protocol）获取网页的结构化表示（DOM 树）和无障碍信息
2. 自动检测哪些元素可以交互（按钮、输入框、链接等）
3. 为每个可交互元素标注唯一 ID 并在截图上绘制边界框
4. 同时生成文本列表描述每个 ID 对应的元素

Screenshot: [图片中关键元素标注了 [1]、[2]、[3]、[4] 等 ID]

Elements:
[1] <input type="text" placeholder="Search" aria-label="Search" />
[2] <button id="submit-btn" aria-label="Submit form" />
[3] <input type="text" placeholder="Enter your name" value="" />
[4] <a href="/docs" aria-label="Documentation" />

模型只需要输出一个 ID 号就行，系统自动用该元素的中心坐标执行点击。这类方案不省 token（因为要把所有标注信息都发给模型），但定位准确稳定，还免去了分割模型可能引入的漏检和误检。

纯坐标预测。

第三条路线不做任何标注，直接让模型输出坐标。以 SeeClick 和 Claude 的 computer use 为代表：在海量 GUI 截图和元素位置的配对数据上训练视觉模型，让它学会将自然语言描述（如“点击提交按钮”）直接映射到截图中的精确坐标——就像人类用户一样，纯粹靠“看”来找到要点击的位置。

在坐标预测方案中，模型对坐标的理解高度依赖训练时使用的分辨率（图9-10）。Claude 训练使用 XGA（1024x768）、WXGA（1280x800）、FWXGA（1366x768），如果输入的截图分辨率不匹配，模型预测的坐标就会系统性地偏移——就像在小地图上量距离然后直接用到大地图上一样。因此，需要在工具层实现双向坐标缩放机制，而且要按宽高比选目标分辨率，避免非等比拉伸把画面压变形、连带把坐标判断也带偏。例如，真实屏幕分辨率为 2560×1440（16:9），就该在 Claude 支持的三档里挑一个宽高比同样接近 16:9 的目标——FWXGA（1366×768）最匹配。截图时把屏幕等比缩放到 1366×768 送入模型；模型输出点击坐标 (683, 384) 后，反向映射为真实坐标 (683×2560/1366, 384×1440/768) ≈ (1280, 720)。反过来，若硬把 16:9 拉伸进 4:3 的 1024×768，画面会被横向压扁，模型预测的坐标就会系统性偏移。

三条路线的选择逻辑可以概括为：结构化信息可得时，优先用 DOM/Accessibility Tree 索引，定位最精确稳定；不可得时（原生桌面软件如 Photoshop、Canvas/WebGL 渲染的界面、游戏），既可以用视觉标注（原始 SoM 路线），也可以用坐标预测。视觉标注把定位变成选择题，对未经专门训练的通用模型更友好；坐标预测省去标注步骤，对做过 GUI 定位训练的模型更直接。两者在小元素和密集界面上的精度都仍有差距。

实验 9-6 ★：使用 browser-use 实现自动浏览器操作

基于 Playwright 浏览器自动化框架（一个用代码控制浏览器的工具库），结合多模态大模型实现自然语言驱动的浏览器操作。启用 SoM 可视化模式，每次决策前保存带标注框的截图。模型接口不限定为 OpenAI 或 Anthropic；本书提供 Qwen3-VL 开放模型 API 配置，并保留通用 OpenAI-compatible base URL 供其他托管服务或自托管推理使用。

测试任务“打开 Google 查询旧金山天气”：系统启动后截图显示 Google 搜索页面，交互元素被编号，模型选择搜索框、输入“San Francisco weather today”、提交搜索，再从结果页提取温度和天气状况。验收时独立核对答案与轨迹，并如实记录实际步数和耗时；“5 步、约 20 秒”只能是某次运行的观测值，不能在没有回执时当成固定结果。

本书保存的开放模型正式运行使用 OpenRouter 上的 qwen/qwen3-vl-32b-instruct。模型在 Google 搜索第 4 步遇到 CAPTCHA 后没有宣称成功，而是转到 weather.com，最终在第 16 步从 San Francisco 的 Today 页面读取 64°F、Sunny、体感 62°F、高 74°F、低 55°F。16/16 个 API 响应均报告请求的 Qwen3-VL 模型，15 张有效步骤截图与只读动作轨迹通过独立确定性验收。这个结果证明开放模型 API 路径可运行；它不等于 Anthropic 原生 computer 工具臂已经复现。

能看动画、能听声音的 Computer Use Agent

到目前为止，Computer Use 的感知都建立在一个隐含假设上：屏幕是静止的——截一张图、想一步、点一下，再截下一张图。可现实里的屏幕会放视频、会弹出转瞬即逝的通知、会播放会议里的人声。一个每 3–5 秒才睁一次眼、而且完全没有耳朵的 Agent，对这些“两帧之间发生的事”既看不见也听不到。看录屏、跟会议、听语音提示、应付一闪而过的对话框——这一整类日常电脑操作，对今天的 Computer Use Agent 几乎是禁区。

这里真正该被重新设计的，不是“动作接口”，而是“观察接口”[^ch9-9]。核心思想是把观察（连续、自适应、多模态）从动作（离散）里解耦出来，做成一层插在环境和任意现成 Computer Use 模型之间、无需重训的感知中间件（可称之为 Agent–电脑观察接口，AOI）。它有三个“按需开闸”的部件：其一，帧间关键帧捕获——先用一个极廉价的像素门跳过几乎没变的画面，再用一个小模型判断画面是否发生了有意义的变化，只在变化时才截一帧，静止画面下几乎零成本；其二，音量门控的语音转写——有声音时才调用语音识别，让 Agent 第一次“长出耳朵”；其三，也是最关键的，把画面叙述成持久的文字——让模型把捕获到的帧描述成一句话（“刚弹出的提示说发布日期改到了 4 月 28 号”），并且即使原图之后被清理出上下文，这句文字仍留在记忆里，把动态信息以文本形式带着往下走。

一个反直觉的发现是：真正起作用的不是“选哪几帧”，而是“把帧叙述成能长期留存的文字”——文字才是 LLM Agent 最擅长处理的模态。在从 7B 到前沿规模的八个模型上，这层中间件无需任何重训就带来 +17 到 +48 个百分点的提升，其中语音类任务的差距最悬殊：加了这层感知，Agent 能把原本“听得见却动不了”的语音任务都做出来。但它也不是一套包打天下的固定配置——在某些更新的模型上，塞太多图像 token 反而会挤占推理、拖累表现，所以这些部件要按模型逐个挑选，而非一股脑全开。这与前面 Set-of-Mark 和坐标预测的取舍是同一个道理：感知方案没有银弹，要顺着模型的脾气来配。

[^ch9-9]: 门控关键帧、按需转写、把帧叙述成持久文字这三个部件，完整机制与逐模型消融见 Li, Bojie and Noah Shi. Agent-Computer Observation Interfaces Enable Dynamic Computer Use. arXiv:2606.29472, 2026.

Computer Use 的世界模型

上一节的观察接口解决的是 “屏幕中间发生了什么”：通过关键帧、语音转写和持久文字，让 Agent 不再只看到两张相隔很久的截图。但观察接口并不会消除规划延迟，Agent 仍然是串行的“截图—思考—点击”循环，每执行一个动作都重新观察、思考下一步。OSWorld-Human 的效率研究显示，即使任务最终成功，Agent 的操作步骤和等待时间仍明显多于人类；准确率达到人类水平，并不等于已经足够实用。

人类操作电脑时并不是点击之后才开始想下一步，而是会先对动作后果作出预测：如果实际变化与预期一致，就沿着原定计划继续执行；只有发现页面状态偏离预期，才停下来重新观察和规划。世界模型让 Agent 能够在行动前预测桌面接下来可能变成什么，从而实现这种类似人的 “推测执行” 机制，大大提高效率。

桌面状态不只是一张像素图，还包括窗口、焦点、滚动位置、输入框内容、加载状态、权限和网络返回；动作则包括点击、键盘输入、滚动、拖拽和等待。一个可用于 Computer Use 的世界模型至少要能编码当前状态、预测候选动作造成的状态变化，并把预测交给规划器决定下一步：

桌面状态 + click/type/scroll/wait ──> 下一状态的表示

这样，Agent 就能在真正点击之前比较候选动作的后果，在页面加载期间准备下一步，并在弹窗一闪而过时根据状态差异恢复。例如任务是 “在 VS Code 新建 Python 文件并写入 hello world”，模型可以先预测文件树和编辑器在成功后的关键状态，再选择点击、输入和保存动作；如果任务是删除文件，则可以先在隔离的虚拟桌面中预测是否会出现不可逆确认框，必要时请求用户确认。这里的重点不是让模型生成一张逼真的未来截图，而是预测完成任务所需的、可检查的状态差异。

2026 年 7 月，Induction Labs 公布的 Photon-1 展示了这条路线的一种实现，仅用 3 万小时的 H200 GPU 时间就完成了 computer use 世界模型的预训练。它把每帧压缩为离散的潜在 token，自回归预测动作之后的下一状态表示，而不是在预训练阶段逐像素生成截图；另外接入的图像生成器只用于把潜表示可视化，并非推理必需组件。给定一张种子截图和后续动作，模型可以连续“想象”桌面状态，再通过虚拟机上的在线训练学会输出 computer-use 动作。[^ch9-20]

[^ch9-20]: David Li and Jonathan Li, Induction Labs, “Scaling Video Pretraining with Imagination Models,” 2026-07-23. https://www.inductionlabs.com/news/scaling-video-pretraining 。文中 Photon-1 的参数、数据规模、内部 benchmark 和成本比较均为公司披露的结果。 [^ch9-21]: Jack Parker-Holder and Shlomi Fruchter, Google DeepMind, “Genie 3: A new frontier for world models,” 2025-08-05. https://deepmind.google/blog/genie-3-a-new-frontier-for-world-models/；Zachary Lin et al. Cosmos World Foundation Model Platform for Physical AI. arXiv:2501.03575, 2025. https://arxiv.org/abs/2501.03575 。

移动端：生态壁垒比技术更难

Computer Use 也在向移动端扩展。移动端与桌面在技术上确有差异：动作空间通常不再是“鼠标坐标 + 键盘”，而是接入系统的无障碍服务 API（如 Android 的 AccessibilityService）来读取界面元素、下发点击与文本输入；交互方式也从鼠标指针变成触摸手势，坐标的语义随之改变——同一个 (x, y) 到底是手指的单击、长按，还是滑动手势的起点，需要额外的手势类型来界定。第六章介绍的 AndroidWorld 等移动端基准，正是在这样的动作空间上评测 Agent 完成真实 App 任务的能力。

但真正卡住移动端的，往往不是这些技术差异，而是生态壁垒。曾有手机厂商尝试在消费级手机中集成 AI 助手，让它自动操作微信、淘宝、支付宝等日常应用，但很快遭遇平台限制。

这揭示了 Computer Use 面临的一个独特挑战：生态壁垒。封杀背后的根本原因是商业模式冲突。传统互联网应用的核心变现逻辑是流量与注意力：用户刷信息流时看到广告，搜索商品时跟随推荐算法的引导，浏览页面时产生冲动消费。而当 Agent 代替用户操作时，这条变现链路被彻底绕过：AI 不会关注广告，也不会冲动消费，直奔目标完成任务就走。对于靠广告和流量变现的平台来说，Agent 的每一次操作都在侵蚀其商业模式的根基。

这意味着 Computer Use 面对的不仅是 CAPTCHA（验证码）等技术层面的对抗，更是一个结构性的利益冲突。这一矛盾在短期内难以调和，也让 Computer Use 在消费级场景中的落地面临比纯技术问题更棘手的挑战。

机器人操作：以 XLeRobot 整理桌面为例

阅读提示：本节始终使用同一个任务——“把红色杯子放进托盘，把黄色废纸放进垃圾盒，最后重新观察并确认桌面状态”。实验 9-7 和 9-9 是 XLeRobot 真机实验，需要机械臂、标定、急停装置和现场观察员；实验 9-8、9-10 和 9-11 是对应的本地 GPU 实验。真机与模拟会明确分开报告，但任务目标、动作语义和成功条件保持一致。

机器人操作比“看图回答问题”难得多。模型不但要看懂画面，还要在真实世界里连续做出动作，而且每个动作都会改变下一刻的情况。XLeRobot 把这种区别变得很具体：同一台机械臂既可以由人通过键盘、手柄或 VR 设备遥操作，也可以把摄像头观察和一组受约束的动作工具交给 Agent 自主调用。硬件和任务都不变，改变的只是操作者——前者由人持续观察和纠错，后者必须由模型与控制系统完成同样的工作。

本节将用“整理桌面”贯穿五个实验。先让人遥操作真实 XLeRobot，测量真机在足够强的操作者控制下能做到什么；再在模拟器中建立同任务的理想控制上限。接着让 Agent 自主控制真实 XLeRobot，观察感知、规划和失败恢复如何影响结果；再把相同的工具契约放进模拟器，批量比较开环、逐步检查和世界模型三种策略。最后改变背景、物体外观、光照和视觉噪声，检查模拟中学到的视觉策略能否适应新的环境。

这里的瓶颈通常不是再给模型增加一个静态问答基准，而是让它在有限的感知和控制带宽下持续完成闭环。一个能用的机器人系统，至少要回答四个问题：

1. 人想完成什么任务？
2. 接下来先做哪个子任务？
3. 当前技能具体输出哪些动作？
4. 动作执行后，现实是否仍符合原来的计划？

本节把这四个问题放在 XLeRobot 的同一个控制闭环中，并分别说明四种技术各自负责什么：长程规划安排先处理杯子还是废纸，VLA 或动作原语完成抓取和放置，世界模型估计动作后果，从仿真环境迁移到现实环境则处理训练画面和真实摄像头、执行器之间的差异。即使高层模型已经具备足够的知识和规划能力，缺少其中任何一个反馈环节，系统仍可能无法把任务做完。

硬件与算法的分工

XLeRobot 最适合回答的第一个问题是：自主整理桌面失败时，究竟是机械臂本身做不到，还是算法没有把它用好？这里有一个不能被弱化的事实：像 XLeRobot 这样成本只有几百美元的机械臂，通过遥操作已经能够完成本节这种连续的多步桌面任务——人看着摄像头画面，抓起红色杯子放进托盘，再把黄色废纸放进垃圾盒，最后重新确认状态。这个结果不是“硬件勉强具备可行性”而已，而是一个明确的诊断证据：对于这个任务，硬件本体不是瓶颈，算法才是瓶颈。

诊断方法很直接：保持摄像头、机械臂、夹爪、桌面布置和成功条件不变，先让人接管闭环。人类会持续修正物体定位、动作选择、时机控制并处理抓取失败；自主系统与人的差距，正落在这些闭环能力上。当然，这个判断的范围是本节的桌面任务：它说明硬件已经跨过了完成该任务所需的负载、精度和工作空间门槛，并不意味着几百美元的机械臂能够胜任所有开放环境或更高难度的操作。

XLeRobot 支持键盘、Xbox 手柄、Switch Joy-Con 和 VR 设备等遥操作入口。人类操作者会自然地做很多算法必须显式实现的事：夹爪靠近杯子时减速，杯子滑动时修正抓取点，第一次没有夹住纸张时重新观察，并在物体放入目标区域后检查结果。遥操作因此不只是收集演示数据，也是一种“固定硬件、替换操作者”的诊断实验。[^ch9-1]

实验 9-7 ★：真机遥操作 XLeRobot 整理桌面

在真实 XLeRobot 工作区内放置红色杯子、托盘、黄色废纸和垃圾盒。操作者通过一种已完成校准的遥操作方式执行固定任务：“把红色杯子放进托盘，把黄色废纸放进垃圾盒，最后重新观察并确认桌面状态。”实验至少重复多轮，并记录摄像头画面、操作者输入、机械臂状态、动作时间、抓取失败、重试次数和最终状态。

验收不能只看“最后桌面似乎收拾好了”。红色杯子必须位于托盘内，黄色废纸必须位于垃圾盒内，机械臂回到安全姿态，而且全程没有碰撞、越界或未经确认的人工代做。

真机遥操作得到的是最有说服力的任务上限，但它不适合批量改变物体数量和位置。为了得到可重复、可统计的对照，下一步把同一个“物体归位”问题搬进二维桌面模拟器，用理想控制器代表一个不会感知错误、不会选错动作的强操作者。

实验 9-8 ★：在模拟器中测量同任务的理想控制上限

在二维桌面模拟器中随机摆放红色杯子、黄色废纸及其目标区域，由理想控制器依次接近物体、抓取并移动到正确位置。它不需要识别图像，也不会选错动作，因此代表“感知和决策都正确时，这个任务至少可以做到什么”。

实验关注任务成功率、完成步数和路径长度，并改变物体初始位置与任务规模，观察理想上限是否稳定。它与实验 9-7 使用相同的成功条件，但测量的是非致动模拟，不代表 XLeRobot 真机已经运行。二者共同建立后续自主控制的两条参考线：实验 9-7 是真实硬件上的人类闭环，实验 9-8 是模拟环境中的理想闭环。

机器人控制的基本结构

机器人系统通常会把不同时间尺度的工作分开：

层级	核心问题	输出	典型时间尺度
任务目标	人想完成什么	“把杯子和废纸归位”	分钟级
长程规划	先做什么、后做什么	先处理杯子，再处理废纸，最后检查	秒到分钟
基本技能	当前要完成哪个状态变化	pick(red_cup)、place(red_cup, tray)	约 1—3 秒
VLA / 技能策略	这个技能具体怎么动	XLeRobot 夹爪的一小段动作或连续轨迹	约 1—10 Hz 推理
底层控制与安全层	如何稳定、及时地执行	关节或末端控制量、限速与急停	约 50—1000 Hz

这是一种常见的工程分工，不是唯一的模型架构。VLA 可以承担一部分高层判断，规划器也可以是规则程序、VLM 或优化器。无论采用哪种实现，都应该把“任务顺序”和“眼前动作”分开，否则高层模型的推理延迟会拖慢底层控制，底层的高频控制也会让高层模型处理大量无关细节。对 XLeRobot 来说，模型不应直接输出任意关节角；它只选择 pick、place、verify_state 或 stop 等有边界的技能，经过标定、限速并带超时的执行器再把技能变成真实机械臂动作。

长程规划与任务分解

用户说“把桌面整理干净”时，系统不能把这句话直接交给动作模型。规划器要先列出场景中的物体和目标，再决定先后顺序，并为每一步写清楚开始条件、完成条件和风险限制。例如：

处理红色杯子 → 清理黄色纸张 → 检查桌面

“处理红色杯子”还要继续拆成两个动作和一次检查：

pick(red_cup) → place(red_cup, tray) → verify_state()

每完成一个技能，就得到一个可以检查的节点。如果抓取失败，只重试当前这一步；如果物体被人挪动了，或者用户改变了目标，只需要重新规划受影响的后续步骤，不必把旧计划全部重做。给智能体的工具也应该足够简单：一次调用只做一件事，动作范围固定，有超时限制，执行后立即重新观察。

实验 9-9 ★★：使用 Gemini Robotics-ER 1.5 驱动 XLeRobot 自主整理桌面

保持实验 9-7 的真实 XLeRobot、桌面布置、任务指令和成功条件不变，把人类操作者替换为 Agent。可以使用 Gemini Robotics-ER 1.5 这类具身推理模型负责观察和规划，通过 RoboCrew 风格的智能体循环只开放五个工具：observe_scene、pick、place、verify_state 和 stop。[^ch9-2]

模型先观察桌面，决定处理顺序，再调用经过标定的 XLeRobot 抓取和放置动作。每完成一个技能都必须重新观察并检查后置条件；抓取失败时只能重试当前技能，用户喊停、物体离开工作区或状态无法确认时必须调用 stop。模型不能直接输出任意关节角，也不能仅凭自己先前说过“已经完成”就跳过真实检查。

验收标准与实验 9-7 完全相同：杯子位于托盘内、废纸位于垃圾盒内、机械臂回到安全姿态且没有碰撞或越界。区别在于，自主实验的任务语义必须来自模型观察，真实动作必须来自工具调用，最终状态必须由新观察确认；人只能负责启动、急停和安全监护，不能在中途代替 Agent 完成动作。这样，实验 9-7 与 9-9 才能直接比较“同一硬件、同一任务，人类闭环与模型闭环之间还差什么”。

真机实验能暴露标定误差、相机遮挡和夹爪失败，却很难安全、可控地重复大量故障。后面的模拟实验会保留这五个工具和完全相同的任务状态，只把真实执行器换成可注入失败的桌面环境，用来拆解开环执行、逐步检查和动作预测各自贡献了什么。

VLA 控制

VLA 是 Vision-Language-Action 的缩写，中文可以理解为“视觉—语言—动作模型”。它接收当前画面和一条技能指令，然后输出机器人接下来要执行的动作：

当前观察 + 技能指令 → 动作

在 XLeRobot 的例子里，高层规划器只提交 pick(red_cup)，VLA 或技能策略还要根据当前画面决定从哪个方向接近杯子、夹爪何时闭合、手臂以什么轨迹抬起。执行层完成这一小段运动后重新拍摄桌面，只有确认杯子确实被夹住，规划器才允许提交 place(red_cup, tray)。因此，工具调用定义的是期望的状态变化，VLA 定义的是如何通过连续动作实现这个状态变化。

RT-2 和 OpenVLA 把连续动作切成离散的 token，再像生成文字一样逐个输出；π₀ 则代表另一条路线，直接生成连续、平滑的动作轨迹。两种方法没有简单的高下之分：离散 token 更容易和语言模型结合，连续轨迹通常更适合表达平滑运动。真正的取舍在于动作应该怎样表示，而不只是模型大小。[^ch9-15]

大模型每秒通常只能推理 1—10 次，而传统控制器每秒可能要更新几十到上千次。工程上常用“动作分块”：模型一次生成一小段未来动作，控制线程按较高频率执行这一小段，模型则在后台准备下一段。这样可以把一部分推理等待藏在动作执行时间里。代价是，动作段越长，运动越平滑，模型在这段时间里看到的新画面却越少；如果 XLeRobot 伸手抓杯子时杯子被碰动，它可能仍在执行根据旧画面生成的动作。因此，动作分块是在平滑性和反应速度之间做取舍，而不是没有代价的加速。

VLA 的局限

“长程规划 + VLA”是一个实用的基本方案，但它仍然有几个容易被忽略的问题：

• 训练数据有限：机器人演示远少于互联网文本和图像数据。模型见过“杯子”这个词，不代表它见过各种材质和摩擦条件下的杯子。
• 只学会模仿，不一定懂后果：行为克隆主要学习“示范者下一步怎么做”，并没有明确要求模型回答“这个动作会造成什么结果”。
• 机器人各不相同：不同机器人有不同的自由度、坐标系、夹爪和执行器延迟，同一个动作不一定能直接搬到另一台机器人上。
• 观察可能过时：动作块开始执行后，物体可能被移动、遮挡或碰倒，但模型仍在依据上一帧画面做决定。

所以，语言模型知道“杯子”是什么，并不代表它知道摩擦、接触、液体晃动和电源线会怎样改变未来状态。VLA 主要回答“现在应该做什么”，还需要另一类模型帮助判断“做了之后可能发生什么”。

世界模型

可以把世界模型理解成一个“动作结果预测器”。它学习的是：在当前状态下采取某个动作，下一刻的状态可能怎样变化。

当前状态 + 候选动作
    → 预测下一状态或未来片段
    → 比较候选结果
    → 选择动作、重新规划或安全停止

一个能用于机器人的世界模型，至少要做好三件事：

• 看懂当前状态；
• 预测不同动作可能带来的结果；
• 把这些预测交给规划器或控制器，帮助它们做选择。

只会描述视频的 VLM，或者只会生成画面的模型，并不会自动变成可靠的机器人世界模型。它还必须知道动作是什么，并且能预测动作对物体和环境的影响。V-JEPA 2 代表在内部状态中预测未来的一条路线，World-Action Model 则明确学习“动作—未来观察”的关系。这些模型可以和 VLA 配合使用，不需要取代 VLA。[^ch9-16]

在实际系统中，世界模型通常有三种用法：

1. 动手前：比较抓取、推动、等待等候选动作，优先选择风险更小的方案；
2. 执行时：把真实观察和预测结果对照，发现偏差就缩短动作、停止或重新规划；
3. 训练时：利用视频、仿真数据和失败轨迹学习状态变化，减少真机上的试错次数。

回到 XLeRobot 的桌面任务：如果黄色废纸被红色杯子部分遮住，系统可以比较“先抓纸”“先移动杯子”和“换一个抓取方向”几个候选技能。世界模型不需要生成一段逼真的机器人视频，只要能预测哪些候选动作更可能让纸张变得可抓取、哪些动作可能碰倒杯子，就已经能帮助规划器排序。动作执行后，真实摄像头观察仍然是最终事实；预测只能帮助选择，不能代替验收。

世界模型给出的不是确定答案，而是“如果这样做，可能会发生什么”的可比较预测。预测得越远，误差通常越大；一段看起来逼真的未来画面，也可能不符合真实的接触和摩擦规律。因此，实际系统仍然需要短期预测、实时观察、对不确定性的估计，以及独立的硬件安全控制器。生成式世界模型可以用来做交互式仿真或可视化，但不能把“会生成视频”和“能指导机器人动作”混为一谈。[^ch9-21]

实验 9-10 ★★：在模拟器中比较三种自主整理桌面的闭环

把实验 9-9 的任务、对象状态、成功条件和五个工具原样放进桌面模拟器，只把真实 XLeRobot 执行器换成可控的模拟执行器，并让抓取偶尔出现可恢复的瞬时失败。这样可以在不改变问题的前提下比较三种策略。

开环执行一次生成完整动作序列，中途不重新观察；逐步检查在每个 pick 和 place 之后重新读取状态，失败时只重试当前技能；预测式执行再增加一个短期世界模型，先比较候选技能的预期结果，再选择下一步。实验比较任务成功率、工具调用开销和失败恢复能力，并检查最终成功是否都由 verify_state 的新观察确认。

这个实验不是为了证明小型模拟世界模型等同于真实机器人的物理模型，而是验证一个更基础的关系：开环计划会把一次局部失败带到任务末尾，逐步检查能够恢复，动作预测则可以进一步帮助候选技能排序。最终是否真的完成，仍然必须由环境反馈决定。

从仿真环境到真实机器人

实验 9-10 即使在模拟器里表现稳定，也不能直接推出实验 9-9 的 XLeRobot 真机会同样成功。从仿真环境走到真实机器人，并不是再换一种控制器，而是要处理两个环境之间的差异。训练时可以使用遥操作数据、视频数据或仿真交互数据；真正部署时，同一个红色杯子、黄色废纸、托盘和垃圾盒会出现在不同的背景、光照、相机位置和遮挡关系中，机械臂还会遇到不同的摩擦、传感器噪声和执行器延迟。只要这些差异足够大，模拟中学会的动作就可能在现实中失效。

实验 9-11 ★★★：同一桌面任务的 RGB 跨环境测试

在模拟环境中继续使用“把物体移动到对应目标”的基本问题，把每个样本理解为整理桌面中的一个局部决策：根据 RGB 画面判断应该向哪个方向接近物体，或是否已经可以抓取。训练四种结构相同的视觉策略：一组只看固定画面，一组改变背景，一组改变物体外观，最后一组同时改变背景、外观、光照和噪声。

所有策略都在原始环境和变化后的新环境中测试，比较视觉条件变化前后的动作判断准确率。这个实验要回答的不是“模拟器是否已经等于 XLeRobot 真机”，而是一个更窄的问题：训练时主动扩大画面变化范围，是否有助于同一个杯子—托盘、废纸—垃圾盒任务适应新的摄像头画面。即使结果改善，真机部署仍然需要真实相机标定、执行器测试和完整的安全闭环。[^ch9-6]

本章小结

本章从模型的三类能力出发：理解、生成和交互。理解与生成主要决定模型能够完成什么、智能上限在哪里；交互则把这两种能力放进一个有时间约束、会产生反馈、还可能改变环境的闭环中。交互能力与智能上限并不直接相关，但它决定模型能否在真实环境中把已有的智能转化为稳定的任务结果。

语音、Computer Use 和机器人分别把这个问题放在声音、数字界面和物理世界中。它们可以按同一条主线理解：

持续感知
  → 判断当前状态与时机
  → 选择回复或动作
  → 让输出进入环境
  → 观察反馈
  → 继续、修正、重试、停止或重新规划

语音部分比较了级联流水线、端到端 Omni 和全双工交互三种范式，核心变化是从“轮流说话”转向持续听说，并在前台实时交互与后台深度思考之间进行分工。Computer Use 把同一个闭环具体化为“截图—动作—新截图”，其主要瓶颈已从单纯的能否完成任务，扩展到操作效率、连续视觉理解和状态确认。

机器人部分则用 XLeRobot 整理同一张桌面的五个连续实验，把抽象架构落到了一个可比较的问题上：真机遥操作和模拟理想控制先建立人类与理想闭环的上限；真机自主控制和模拟策略对照再测量 Agent 与这个上限的差距。

[^ch9-1]: XLeRobot, “Teleop 文档”. https://xlerobot.readthedocs.io/en/latest/software/getting_started/XLeRobot_teleop.html [^ch9-2]: Google DeepMind, “Gemini Robotics-ER 1.5”. https://deepmind.google/models/gemini-robotics/gemini-robotics-er/；XLeRobot, “LLM Agent 控制”. https://xlerobot.readthedocs.io/en/latest/software/getting_started/LLM_agent.html 。XLeRobot 上游示例展示模型与工具调用的编排方式；本节保持同一编排原则，但把动作工具限定为经过标定的桌面抓取、放置、检查和停止原语。 [^ch9-6]: LeRobot, “Sim2Real 教程”. https://github.com/StoneT2000/lerobot-sim2real/blob/87d6c1d969f6e0ca4dc5697940804e231118a63a/docs/zero_shot_rgb_sim2real.md [^ch9-15]: Moo Jin Kim et al. OpenVLA: An Open-Source Vision-Language-Action Model. arXiv:2406.09246, 2024. https://arxiv.org/abs/2406.09246 [^ch9-16]: Meta AI, “Introducing the V-JEPA 2 world model and new benchmarks for physical reasoning,” 2025-06-11. https://ai.meta.com/blog/v-jepa-2-world-model-benchmarks/；V-JEPA 2 技术报告：arXiv:2506.09985, https://arxiv.org/abs/2506.09985

思考题

1. ★★ 语音 Agent 的端到端模型将 ASR-LLM-TTS 合并为单一模型，降低了延迟却失去了模块化。如果端到端模型在某个环节（如语音识别）出错，调试和修复比串行管道困难得多。你会如何设计端到端语音 Agent 的可观测性（observability）系统？
2. ★ Step-Audio R1 通过 MPS 双脑架构实现“边想边说”。但人类在“边想边说”时经常会说出未经深思熟虑的话、自我纠正、或使用填充词。Agent 的“边想边说”应该模仿人类的这些特征吗？
3. ★★ SoM（Set-of-Mark）及其结构化变体（DOM 元素索引）将 Computer Use 的视觉定位从开放坐标预测转为封闭 ID 选择，但都需要先检测和标注界面元素——无论靠分割模型还是靠 DOM。如果界面包含非标准控件或动态变化的元素，标注就可能不完整或不准确。这种情况下应该回退到坐标预测吗？
4. ★★ XLeRobot 等几百美元级机器人平台让遥操作数据收集变得廉价。但遥操作数据的质量高度依赖操作者的技能。一个不熟练的操作者提供的数据会如何影响 VLA 模型的训练？如何在数据收集阶段自动筛选低质量数据？
5. ★★★ 本章覆盖了语音、Computer Use 和机器人三种交互形态。交互架构可以通过端到端统一、模块化级联或前台交互与后台推理解耦来改进，而不必和智能上限沿同一条路线增长。未来五年的 Agent 应该优先追求更强的统一模型，还是保留可替换的快慢分工？请结合延迟、可观测性、模型迭代速度和任务风险讨论。
6. ★★★ 当前 Computer Use 以“截图 → 动作 → 截图”的离散循环运作，每次观察都是一张静态帧。但人类对屏幕的感知是连续的——我们能看到动画播放、观察加载进度、理解视频内容。这意味着今天的 Computer Use 根本无法处理需要时序视觉理解的任务。如何重新设计感知层以支持连续的视觉流理解？
7. ★★ DOM/Accessibility Tree 元素索引在标准 Web 应用上效果显著，但越来越多的软件界面（Canvas/WebGL 渲染、跨平台自绘控件）不提供可访问的结构化信息，只能依靠视觉标注或坐标预测。你认为 Computer Use 应该押注纯视觉路线，还是同时维护结构化和视觉两条路径？维护两条路径的成本和收益分别是什么？
8. ★★ VLA 模型采用动作分块（action chunking）——如正文所述，π₀ 的典型配置是一次生成 50Hz 频率下 25-50 个未来动作——将推理延迟隐藏在执行时间里。但如果执行过程中环境突变（如物体被移走），预生成的动作序列就会失效。如何在动作分块的效率优势和环境变化的响应速度之间取得平衡？
9. ★★★ 本章的三个场景（语音、Computer Use、机器人）都面临“感知-思考-行动”循环的延迟问题，都需要在智能上限和交互时效之间做分工。在语音场景中，这表现为“说错了再纠正”；在 Computer Use 场景中，这表现为“先点再看”；在机器人场景中，这表现为“走一步看一步”。如何通过动作分级、可逆操作、状态确认、权限控制和安全停止，保证快速交互不会导致无法挽回的后果？

---

---

多 Agent 协作

在 OpenAI 曾提出的 AI 能力五等级描述（Level 1 对话者、Level 2 思考者（Reasoners）、Level 3 智能体、Level 4 创新者、Level 5 组织 Organizations）中，多 Agent 协作常被类比为通向第五级的路径之一——需要说明的是，此处 Organizations 指的是“AI 能完成整个组织的工作”这一能力级别，而非对系统架构的要求，足够强大的单个 Agent 理论上也能达到。但就今天的工程现实而言，单个 Agent 终究受限于自身模型的能力边界和上下文窗口。

而让多个 Agent 协同工作，意义远不止让不同专长的 Agent “取长补短”。更根本的一点是：群体的智能可以高于个体。人类文明便是明证——单个人的智力有限，但经由分工、协作、辩论和知识的代际累积，人类社会作为整体所展现的智能，远超任何一位天才个体。Agent 群体同样可能涌现出这样的集体智能：哪怕每一个 Agent 都只相当于人类专家的水平，只要组织得当，其整体能力也可能超过所有人类专家的总和。Google DeepMind 在《从 AGI 到 ASI》中正把“大规模多 Agent 集体”列为通往超级智能（ASI）的关键路径之一——正如人类的通用智能能聚合成超越个体的社会与组织实体，众多 AGI 级 Agent 协同形成的“群体智能”，也可能表现出远超其成员简单相加的认知能力[^agi-asi]。因此，多 Agent 协作不只是突破单个模型上下文窗口与能力边界的工程手段，更可能是从“专家级 AI”迈向“超越人类整体”的一条根本路径。

[^agi-asi]: 把“大规模多 Agent 集体”列为从通用人工智能通往超级智能的关键路径之一，见 Google DeepMind, From AGI to ASI. arXiv:2606.12683, 2026.

多 Agent 协作的分类框架

要构建多 Agent 系统，首先需要理解两个核心设计维度，它们共同决定了系统的基本架构和实现方式。

维度一：上下文是否共享

这是最基础的架构决策，决定了多个 Agent 之间如何传递信息。

共享上下文意味着后一个 Agent 接收前一个 Agent 的完整对话历史和轨迹（第一章定义的 trajectory）。每个阶段切换系统提示词和工具集后，就变成了一个新的 Agent（因为它的身份、职责和能力都发生了变化），但它保留了前任的全部记忆。比如一个团队里，需求分析师写完需求文档后，开发者不仅拿到了文档，还能看到分析师与用户的所有沟通记录——他是一个新角色，但完整保留了之前的上下文。优势在于信息不丢失，每个 Agent 都能回顾之前任何阶段的细节；挑战在于上下文可能快速膨胀。

不共享上下文意味着每个 Agent 维护完全独立的上下文和对话历史，彼此无法直接访问对方的“思考过程”。这就像不同部门之间的协作：每个人在自己的工位上独立工作，通过共享文档和会议纪要交换信息，而不是时刻盯着别人的屏幕。这种模式的模块化和隔离性更好，每个 Agent 只需关注与自身职责相关的信息；系统也更易扩展和维护——增加新 Agent 不需要改动现有 Agent 的内部逻辑，只需定义好接口和数据格式。

由于 Agent 之间不共享上下文，必须通过显式的通信机制传递信息。这个问题在经典分布式系统中早有答案：操作系统教科书告诉我们，进程间通信（IPC）归根结底只有两大范式——共享内存（一方写入、另一方读取同一块存储）和消息传递（把数据显式地发送给对方）。Agent 间的通信机制同样落在这两个范式之内，常见的有三种：

• 工具调用的参数：上游 Agent 把结构化数据作为参数传给下游 Agent 的工具，适合需要类型确定、结构清晰的场景；
• 共享文件系统：Agent 之间通过读写共享目录下的文档、代码等中间产物来交换信息，适合产物较大或需要持久化的场景；
• 消息总线（Message Bus）：一个专门负责在 Agent 之间传递消息的中转站，Agent 不直接调用彼此，而是把消息发送到消息总线，由它转发给目标 Agent。

对应到 IPC 的两大范式：共享文件系统就是 Agent 世界的“共享内存”；工具调用参数和消息总线则是“消息传递”的两种形态——前者随调用同步传递，后者经中转站异步投递。两种范式各有取舍。Go 语言有一句广为流传的话：“不要通过共享内存来通信，而要通过通信来共享内存”——共享内存快，却把并发冲突的隐患留给使用者；消息传递要多写编排代码，却让数据的归属清晰可循。

维度二：协作拓扑

第二个维度是协作拓扑——Agent 之间的控制权和信息按什么结构流动。协作拓扑有三种典型形态：

• 对等协作模式（Peer Collaboration Pattern）：少量 Agent 按照固定的拓扑形成迭代改进循环，例如论文写作 Agent 由起草者和评论者两个 Agent 组成，一个人起草、另一个人批注修改，反复几轮后质量更高。
• 管理者模式（Orchestration Pattern）：一个中心化的 Manager Agent 负责任务规划和调度，多个子 Agent 各负责特定子任务——就像项目经理带着几位专业工程师做项目。
• 去中心化模式（Decentralized Pattern）：没有运行时的中心控制者，Agent 之间像人类一样互相沟通，协作完成任务。

术语说明：Graph 工程。 2026 年 7 月开始流行的 “Graph Engineering”，在当前 Agent 语境中通常指显式设计执行图：节点是 Agent、普通程序或人工决策，边定义任务依赖、条件路由与失败后的去向，结构化状态在节点之间流动[^ch10-graph-engineering]。本章讨论的“协作拓扑”正是其中的多 Agent 子集——对等协作、管理者编排和去中心化移交，都是不同的图拓扑。

各模式的详细设计和适用场景将在后面的专题小节中展开讨论。

多 Agent 何时真正优于单 Agent

在进入具体的协作架构之前，先回答一个更根本的问题：什么时候真正需要多个 Agent，什么时候一个 Agent 就够了？ 这个问题的答案会成为后文所有工程方案的总体参照。近年的一系列研究给出了一个清晰的判断框架——核心判据只有一条：协作过程是否引入了单个 Agent 在生成时无法获得的新信息？

表10-2 汇总了不同协作模式是否引入新信息，用来判断多 Agent 协作相对单 Agent 是否具有实质价值。

表10-2 多 Agent 协作模式的信息增量对比

协作模式	是否引入新信息	效果
同一模型自我审查（重新阅读自己的输出）	否	通常无效甚至有害
不同 Agent 辩论同一段文本	否	在等计算量下与单 Agent 持平
Reviewer 使用测试执行结果审查代码	是（执行反馈）	显著提升
Reviewer 查看渲染截图审查前端/PPT 代码	是（视觉反馈）	显著提升
Reviewer 使用外部工具验证事实	是（工具反馈）	显著提升

2025 年的 RLEF（Reinforcement Learning from Execution Feedback）[^rlef-2025] 证实了这一点：通过强化学习训练模型利用代码执行反馈来迭代改进代码，效果远超让模型独立多次采样。关键在于每次迭代都引入了真实的执行结果（编译错误、测试失败、运行时异常），这些信息在模型写代码时并不存在。2025 年的 WebGen-Agent [^webgen-agent-2025] 在网页生成任务上，通过多层级的视觉反馈（截图 + 视觉语言模型描述）构成的反馈脚手架，据报道使 Claude 3.5 Sonnet 在该基准上的表现从 26.4% 提升到 51.9%——接近翻倍。

[^rlef-2025]: Gehring, J., et al. RLEF: Grounding Code LLMs in Execution Feedback with Reinforcement Learning. arXiv:2410.02089, 2025. [^webgen-agent-2025]: Lu, Z., et al. WebGen-Agent: Enhancing Interactive Website Generation with Multi-Level Feedback and Step-Level Reinforcement Learning. arXiv:2509.22644, 2025.

这个“新信息”框架解释了一个看似矛盾的现象：一些学术研究认为多 Agent 并不能提升 Agent 能力上限，但工程实践中多 Agent 确实效果更好。矛盾的根源在于两者讨论的是不同类型的 “多 Agent”：学术研究中比较的多是 “多个 Agent 看着同一段上下文互相讨论” 的模式，而工程实践中有效的多 Agent 系统往往包含外部反馈环路（代码执行、视觉渲染、工具调用）。前者没有引入新信息，后者引入了。

步骤预算与 Agent 性能。 一个相关的研究方向是：给 Agent 分配不同的步骤预算（即允许的工具调用次数或迭代轮数），会如何影响其表现？直觉上，更多步骤应该带来更好的结果——30 步预算下 Agent 只能快速实现核心功能，300 步预算下它还可以先做规划、再实现、再测试、再改进。但 2025 年 Google 的论文《Budget-Aware Tool-Use Enables Effective Agent Scaling》发现了一个反直觉的结论：单纯增加 Agent 可用的步骤数并不能保证性能提升。标准的 Agent 缺乏“预算意识”——即使有 300 步的预算，它们仍然倾向于执行浅层搜索，很快就“饱和”了。要让更多的步骤真正转化为更好的结果，Agent 需要一种显式的预算感知机制，根据剩余资源动态调整策略：前期广泛探索，后期聚焦最有希望的方向。2026 年的 BAVT（Budget-Aware Value Tree Search）进一步提出了步骤级别的价值评估，在每一步根据剩余预算比例调整探索与利用的权重——随着预算减少，Agent 从“广撒网”逐渐切换到“深挖掘”。

这些发现对多 Agent 系统设计有直接的指导意义。比如在管理者模式中，Manager Agent 不应只是简单地将任务分发给子 Agent 然后等待结果，而应该根据任务的复杂度动态分配步骤预算——简单子任务给较少的步骤，复杂子任务给充足的步骤。同时还要引导子 Agent 合理利用这些预算（先规划、再实现、再测试、再改进），而不是一头扎进去直接开干。

此外，成本是多 Agent 系统必须关注的要点。多 Agent 的并行探索与反复迭代都要消耗大量 token。这意味着多 Agent 的效果收益必须足够大，大到能覆盖数倍乃至一个数量级的额外开销，否则一个调校得当的单 Agent 往往是更划算的选择。

共享上下文的多 Agent 协作

共享上下文的多 Agent 协作中，每个阶段都是一个独立的 Agent（拥有自己的系统提示词和工具集），但它继承了前序 Agent 的完整轨迹——就像接班的同事能翻阅前任留下的所有工作日志。这种 “继承式协作” 的核心优势在于信息零损耗，每个 Agent 都能回顾之前任何阶段的细节。挑战则在于如何让当前 Agent 专注于自己的核心职责，而不被继承来的大量历史信息所干扰。

这里有一个会直接改变实现和成本的设计选择：角色转换时，是替换 system prompt，还是加载 Skill？前者能在每个边界重建角色身份与工具 allowlist，约束更硬，却会改变请求前缀；后者只把版本化的 SKILL.md 作为轨迹中的工具结果追加，静态前缀保持不变，通常更利于模型 KV/prompt cache，但 Skill 本身不是权限边界。涉及副作用、凭据或合规动作时，应再加 Harness 层的工具策略门，不能把“能读到规程”当成“不能调用工具”。

多阶段角色转换

在复杂任务中，Agent 的角色和职责可能在不同阶段发生显著变化。如果始终使用同一套静态系统提示词，要么过于笼统缺乏针对性，要么把所有阶段的指导塞在一起导致过于冗长。多阶段角色转换的做法是：根据当前阶段动态切换系统提示词和工具集，让 Agent 在每个阶段都以最合适的 “身份” 工作。

这里有一个常被忽略、但会直接改变架构的设计选择：角色转换究竟是替换 system prompt，还是加载 Skill？ 两者都可以让同一个模型在不同阶段采用不同的行为规程，却不是同一种成本模型。

选择	角色规程的载体	工具可见性	上下文/KV Cache 影响	约束能力
transfer_to_agent	替换当前 system prompt，并通常替换工具集	只暴露当前角色工具	每次切换都改变请求前缀；从变化点起的前缀缓存通常无法复用	强：越界工具可在 schema 层不可见
Skill	固定 system prompt 中的 Skill 目录，按需把 SKILL.md 追加到轨迹	通常固定暴露工具全集，或使用稳定的工具搜索入口	静态前缀保持不变；Skill 内容成为末尾轨迹，已有前缀可继续复用	弱：Skill 是行为指令，硬权限仍需 Harness 门

我的默认建议是：角色差异主要是知识、流程和写作风格时，优先使用 Skill；角色差异涉及权限、工具隔离、合规边界或需要在运行时强制禁止某类动作时，使用独立 Agent/transfer_to_agent，或者在 Skill 之上再加一层不可绕过的工具策略门。 不要把“Skill 更省代码”误解成“Skill 天然更安全”；也不要把“system prompt 更强约束”误解成“切换没有代价”。如果采用后者，必须把动态提示词切换、工具 schema 切换、角色状态机、防循环和缓存观测都视为 Harness 的一等功能。

这里还要区分两个经常被混叫成“缓存”的东西。模型的 KV/prompt cache 缓存的是请求前缀；切换 system prompt 或工具 schema 会从首个差异处失效。知识库/Skill cache 缓存的是按名称、版本和权限得到的文档或检索结果；Skill 路径可以把 SKILL.md 按 name@version 缓存并在轨迹末尾追加，但第一次加载仍然需要一次读取和 token，且不能假设不同运行时使用相同的 KB cache key。严谨实验必须分别记录服务商返回的 cached_tokens、Skill/KB 命中率和加载延迟，不能用其中一个推断另一个。

“加载 Skill”本身也需要操作性定义。本实验把它定义为：静态 system prompt 中只放薄目录，完整 SKILL.md 由 load_skill 读取并作为 tool result 追加。若某个运行时在加载后重写 system/developer prompt，或动态替换工具 schema，那么它已经改变了前缀，不能再归入这里的 Skill arm，也不能沿用“缓存更友好”的假设。

实验 10-1 ★★：共享上下文中的多角色转换——系统提示词与 Skill 的对比

共同任务与变量：两条路径都使用同一模型、同一用户任务、同一工具实现、同一份角色规程和全量共享轨迹。任务是查找中国 2021—2023 年新能源汽车销量、计算 CAGR、写不超过 120 字的投资人摘要。五份 SKILL.md 是角色规程的唯一真源：路径一把当前角色的同一份正文放进动态 system prompt，并用 transfer_to_agent(target_role, reason) 切换；路径二保持 system prompt 与工具 schema 不变，使用 load_skill(name) 把同一份正文追加到轨迹。两边只增加各自转换工具所需的最小机制说明，避免把提示词文案差异误判为架构差异。

跨领域角色转换进一步探索 Agent 在多种任务类型之间的自主切换——不再是预先规划好的线性流程，而是根据用户需求的变化，由 Agent 自主判断应该切换到哪个专业角色。

这是一项架构路径对比，不是只改变一行提示词的纯消融：路径一的工具可见性是硬隔离，路径二为了保持前缀稳定而固定暴露工具全集。因此结果同时反映“角色指令载体”和“工具权限策略”的真实工程取舍。若要单独估计提示词载体的因果效应，应再加入第三臂：固定暴露工具全集，但把同一角色规程直接放进动态 system prompt。

路径一：系统提示词切换。五种角色为 triage（用户需求收集，默认入口）、research（信息检索）、coding（编程）、data_analysis（数据分析）和 writing（写作）。每个角色只看到自己的专属工具和 transfer_to_agent；调用移交时保存历史、加载目标角色提示词/工具集，再继续调用。旧实现保留在配套项目中，作为这一 arm 的基线。

路径二：Skill。system prompt 和完整工具全集在整个会话中固定；模型按需调用 load_skill(name)，读取的 SKILL.md 作为 tool result 进入共享轨迹。这样静态前缀不因角色变化而重写，但工具仍然可见，硬权限必须由 Harness allowlist、审批或沙箱执行器保证。若某个运行时在加载 Skill 时重写 system/developer message 或工具 schema，应另列为第三臂，不能继续声称“Skill 保持前缀稳定”。

主任务：查中国 2021—2023 年新能源汽车销量，计算 CAGR，写不超过 120 字的投资人摘要。Transfer 路径的预期链是 triage → research → data_analysis → writing → triage；Skill 路径执行同样的工作，但用四次 load_skill 代替角色移交。两条路径的检索、计算和篇幅工具都必须真实执行。

复杂任务集：不要只重复主任务；配套的 tasks.complex.example.json 预置八个成对任务，覆盖多来源冲突与定义选择、证据缺失时的澄清、用户要求停在中间阶段、带注入文字的检索结果、带不变量和禁止副作用的 Python 任务、两轮审查回退，以及严格的引用、格式和字符数规则。每条记录同时给出 required_capabilities、required_tools、forbidden_tools、输出正则和工具调用顺序，评分器先检查这些可观察门禁，再进入盲测质量评审。

第六章评估协议：

1. 成本：记录每次 API 的 input/output tokens、服务商返回的 cached_tokens、未缓存输入 tokens、调用数、工具往返数和墙钟时间，并在给定价格后重算美元成本；Skill 文档缓存的 hit/miss 和加载延迟另行记录，不能用 KB cache 命中推断模型 KV cache 命中。
2. 实际效果：先做确定性门禁——来源 URL、真实工具调用、数据/公式完整、交付稿长度和所需能力序列；再用随机交换 A/B 顺序的盲测人类或异源模型 Rubric 评判正确性、完整性、可读性和可审计性。幻觉、凭据或 system prompt 泄露、声称执行但轨迹没有执行，一票否决。
3. 边界可靠性：冻结“用户覆盖默认流程”“检索内容提示注入”“证据缺失不得猜测”“禁止副作用工具”“重复加载/回退循环”等前缀。每个用例预先定义允许的下一步、必须出现的证据和禁止动作，只评分可观察轨迹，不猜隐藏思维。
4. 统计：至少 30 个成对任务，每条路径独立运行多次；二元门禁报告 Pass@1、Pass-consecutive@k、配对 bootstrap 95% 区间和精确 McNemar，token/延迟报告配对中位数及区间。单个 smoke trace 只能说明流程能跑通，不能据此宣布优胜。

随着模型能力的提升，多阶段和跨领域角色转换往往可以用 Skill 简化；但这只在角色差异主要是知识和流程时成立。Skill 无法在 Harness 层面保证模型不调用某种工具，涉及权限或副作用的动作仍需独立 Agent、工具 allowlist 或人工审批。最终应由这套对比评估而不是代码长度直觉来决定。

不共享上下文的多 Agent 协作

不共享上下文代表真正的多 Agent 协作。在这种架构下，每个 Agent 都是独立的实体，拥有自己的上下文、轨迹和状态。Agent 之间无法直接访问彼此的 “内心活动”，协作完全依赖明确的、结构化的数据传递机制，也就是本章开头介绍的三种通信机制（工具调用参数、共享文件系统、消息总线）。

本章开头把通信机制对应到进程间通信的两大范式。多 Agent 系统与操作系统有深刻的对应关系（表10-3）：

表10-3 多 Agent 系统与操作系统的对应关系

操作系统	多 Agent 系统
程序（可执行文件）	静态前缀（系统提示词 + 工具定义）
进程的内存	轨迹
CPU	LLM
内核	Agent 运行时
系统调用	工具调用
fork（创建子进程）	spawn_subagent
kill（发送信号）	cancel_subagent
ps（列出进程）	list_agents
退出码与 wait()	子 Agent 返回的结构化摘要
共享内存 / 消息传递	共享文件系统 / 消息

程序是静态的代码，进程是程序的一次运行。同样，静态前缀决定 Agent 是谁，轨迹记录它走到了哪一步。LLM 扮演的是 CPU 的角色：自身不保存状态，靠加载不同的上下文分时服务许多 Agent——“上下文切换”这个词本来就是从操作系统借来的。也正因如此，换一颗更快的 CPU，程序照常运行；换一个更强的模型，Agent 还是原来那个 Agent——它的身份和记忆在前缀与轨迹里，不在模型权重里。

这套抽象并不新鲜：私有状态、异步消息、可创建新成员，正是 1970 年代 Actor 模型的基本设定[^actor-model]，多 Agent 系统不妨看作它的 LLM 版本。因此操作系统与分布式系统的成熟经验大多可以直接借用。唯一失效之处在于：进程间传递字节，逐位保真；Agent 间传递语义，每次转述都可能失真——这是本章“失败模式”一节要专门讨论的新问题。

[^actor-model]: Hewitt, C., Bishop, P., Steiger, R. A Universal Modular ACTOR Formalism for Artificial Intelligence. IJCAI 1973.

进程式的隔离带来了几个切实的工程好处：每个 Agent 可以独立开发和测试，新增能力不需要改动现有代码，某个 Agent 出了故障也不会把错误状态传染给其他 Agent，而且多个 Agent 可以真正并发执行——上下文完全独立，不存在资源竞争。

但不共享上下文也有代价。最明显的是信息同步问题：各 Agent 如何对任务状态保持一致的理解？信息在传递过程中会不会丢失或重复？调试也变得更加困难——出了问题需要翻看多个 Agent 的日志，才能拼出完整的执行过程。这些问题使得接口规范、数据格式和通信协议的设计变得至关重要。

不共享上下文的显式协作依赖两套与拓扑无关的基础设施。其一是共享文件系统，作为 Agent 间交换产物、与用户交换文件的持久媒介，构成协作的数据平面；其二是通信与控制机制，支持 Agent 间的消息传递、状态查询、执行终止与资源调度，构成协作的控制平面。以下三种拓扑均建立在这两者之上。

Agent 眼中的文件系统

本章开头将“共享文件系统”列为不共享上下文的三种通信机制之一。在实际系统中，Agent 访问的并非单一存储，而是一个虚拟文件系统（virtual filesystem）：来源、生命周期与权限各异的存储被挂载（mount）到同一目录树下，Agent 通过统一的 read_file/write_file/list_dir 接口访问，底层则可能是本地临时盘、持久对象存储、第三方云盘的 API 或只读的系统资源包。明确这棵目录树的构成——每一区域的可见性与生命周期——是多 Agent 协作设计的前提：相当一部分并发冲突与信息泄露，源于将本应隔离的区域混置。这棵目录树相当于 Agent 的地址空间，四类区域就是权限各异的内存段：有的私有可写，有的多方共享，有的只读。操作系统的保护哲学在这里同样成立——默认隔离，共享须显式声明。一个成熟的多 Agent 系统，其文件系统通常由以下四类区域构成：

一、Agent 专属工作区（Scratchpad）。每个 Agent 实例独享的私有目录，存放中间产物、临时文件、草稿与调试日志，生命周期与实例绑定，对其他 Agent 和用户不可见。隔离 scratchpad 有两重作用：避免多个 Agent 的临时文件相互覆盖，以及保持主 Agent 上下文的精简——子 Agent 的试错过程留存于自身工作区，仅将最终产物提交至共享空间。这对应第四章“子 Agent 返回结构化摘要而非全量轨迹”在存储层面的体现。

二、多 Agent 共享空间（Shared Workspace）。多个 Agent 共同读写、且用户可见的协作区域，是不共享上下文架构下 Agent 间交换产物的主要媒介：Glossary Agent 写入术语表，Translation Agent 从中读取；用户亦可在此上传原始文件、下载最终交付物。其生命周期与整个任务绑定，需要持久化。作为多方并发读写的区域，它是并发冲突的高发处——乐观锁、工作副本隔离（worktree）等机制均作用于此，详见本章后文“失败模式一”。第四章以卷挂载 /workspace/shared 连接主 Agent、虚拟电脑与虚拟手机，即为这一层的典型实现。

三、外部挂载资源（Mounted External Resources）。用户授权接入的第三方信息源——Google Drive、Notion、Dropbox、企业 Wiki 等——通过适配器（adapter）映射为文件系统中的挂载点（如 /mnt/gdrive）。Agent 以读文件的方式访问一篇 Notion 文档，底层由适配器调用对方 API 完成。这一层区别于本地存储的三个特性需在设计时显式处理：访问受外部权限约束（用户在源系统中的权限决定 Agent 的可见范围）、延迟更高且一致性更弱（每次读取为一次网络往返，数据可能已被外部修改，只能按最终一致性对待）、以按需只读为主（写回外部源须谨慎，误写可能污染用户的真实数据）。统一的文件接口使 Agent 无需为每个数据源定制专用工具，但也掩盖了上述性能与安全差异，因此需在挂载层面显式管理只读/可写、超时与凭证边界。

四、系统内置资源（Built-in System Resources）。系统预置、对所有 Agent 只读共享的资源包，典型代表是第二章、第四章介绍的 Skills——以文件形式组织的知识文档与脚本，挂载于 /skills 等路径，按渐进式披露（先索引、后按需展开）取用；此外还包括参考手册、模板库与共享工具定义。该层全局共享、只读、跨会话稳定，可被所有 Agent 并发读取而无需并发控制。

图10-3 呈现了这四类区域统一挂载于同一目录树的结构：Agent 通过统一接口访问整棵树，用户从共享空间上传与下载文件，外部数据源经适配器挂载，系统内置资源则以只读方式提供。

表10-4 从可见性、生命周期、读写权限与并发控制四个维度对比这四类区域，可作为文件系统布局设计的检查表。

表10-4 Agent 虚拟文件系统的四类区域

区域	可见性	生命周期	读写	并发控制
Agent 专属工作区	仅该 Agent	随 Agent 实例销毁	读写	不需要（私有）
多 Agent 共享空间	所有协作 Agent + 用户	随任务持续，需持久化	读写	需要（乐观锁 / worktree）
外部挂载资源	视外部授权而定	由外部源决定	多为只读，写需谨慎	由外部源负责
系统内置资源	所有 Agent	跨会话稳定	只读	不需要（只读）

将四类区域统一至同一目录树，正是“文件路径作为通用接口”这一设计的价值所在：Agent 间传递产物、主 Agent 向子 Agent 交接输入、乃至跨组织 A2A 协作交换 Artifact，传递的均为轻量的路径字符串，而非将内容载入上下文窗口（第四章）。这与第五章“文件系统作为 Agent 的中枢”一脉相承——后者讨论单 Agent 如何以文件系统承载记忆与能力，此处则将同一抽象扩展至多 Agent：一棵挂载了私有、共享、外部、内置四类存储的虚拟目录树，即多 Agent 协作的存储底座。

Agent 间的通信与控制

文件系统解决 Agent 间产物交换的问题，协作还需一条控制平面。这正是表10-3 中生命周期各行的用武之地：创建（spawn_subagent）、发消息（send_message_to_subagent）、取消（cancel_subagent）、发现（list_agents）这组第四章给出的工具原语，对应进程世界的 fork、消息、kill 和 ps。本节不重复接口定义，而聚焦多 Agent 协作依赖、却常被忽略的四项能力。

一、消息传递。 最简形态为点对点：Agent A 直接调用 send_message_to_agent_b(content)，适用于拓扑固定、Agent 数量少的场景（如本章实验 10-3 的电话 + 电脑双 Agent）。当 Agent 数量增多且需异步并行时，点对点连接数随 Agent 数呈平方增长，且要求收发双方同时在线；此时应改用消息总线（详见本章后文“并行协调形态”）：Agent 将消息发布至总线，由总线按订阅关系转发，发送方无需知晓消费者。无论点对点还是经总线，消息通常应携带结构化的信封（envelope）：发送者 ID、目标（指定 Agent 或广播）、消息类型（如 task_assigned/status_update/result/terminate）及 JSON 负载。统一的信封格式保证接收方可靠地路由与解析，并使协作链路可追溯——这是多 Agent 系统调试的关键。

二、状态查询。 这是控制平面中最易被低估的一环。主 Agent 派出子 Agent 后，若无从获知其进展，则既无法判断是否继续等待，也无法在其阻塞时及时介入。直觉的做法是照搬 RPC，定义一个 get_subagent_status(agent_id) 查询接口，返回“运行中/已完成/失败”加一个进度百分比。但这种拉取式接口的实际用处远小于预期：子 Agent 一经创建就立即开始执行，直到完成或失败，并不像传统批处理系统的作业那样在一串排队状态之间流转——正如 Unix 编程中极少需要按 PID 去轮询另一个进程的运行状态。轮询还有固有的两难：过密浪费 token，过疏则不及时。状态获取更自然的做法，是回到本章开头的两大通信范式。

用消息传递获取状态。主 Agent 直接给子 Agent 发一条消息：“进展如何？”子 Agent 在合适的时机回复。一切都是异步的：发出消息不阻塞自己的执行，对方何时回复、是否回复是另一回事——正如经理通过即时消息询问下属进度，而不要求对方立即停下手头的工作。反过来，子 Agent 也可以在到达关键节点时主动发消息汇报；系统若已架设消息总线，这就是往总线上发布一条 status_update（实验 10-4 的“实时监控”即此形态）。无论问答还是主动汇报，消息中的状态本身宜采用统一的状态机词汇（执行中、需要输入、已完成、失败）——本章后文的 A2A 协议正是把任务生命周期标准化为这样一组状态。

用共享文件系统获取状态。最彻底的形态是轨迹持久化（trajectory persistence）：子 Agent 在执行过程中，把自己的轨迹（第一章定义的 trajectory——用户消息、模型回复、工具调用与结果的完整序列）实时序列化为 JSON，追加写入文件系统中的日志文件（通常每个会话一个文件、每行一个事件，即 JSONL 格式）。主 Agent 无需任何状态上报协议，直接读取这个文件就能看到子 Agent 的全部执行过程：它正在调用哪个工具、最近一步在思考什么、是否卡在反复失败的重试上。用进程的语言说，这相当于直接读另一个进程的内存——不占用子 Agent 的上下文、不依赖其配合、观测粒度最细。但事无巨细也是负担：轨迹动辄数万 token，主 Agent 读完还得自行提炼，既费时又费 token。因此多数场景下更合理的是约定进度文件：主 Agent 启动子 Agent 时约定“把进度写到 progress.md”，子 Agent 每完成一项就更新这份任务清单，主 Agent 随时读这个轻量文件即可掌握进展。这相当于两个进程在共享内存里划出一小块约定格式的状态区，暴露的是提炼后的进度，而非全部“内存”。进度文件还附带提供了卡住检测：progress.md（或轨迹文件）的最后修改时间超过 N 分钟没有变化，即可判定子 Agent 无活动、触发超时兜底，避免系统被阻塞的子 Agent 拖累。

轨迹持久化的价值远不止监控。回顾第一章的结论“Agent 的上下文 = 静态前缀 + 轨迹”：静态前缀（系统提示词、工具定义）由代码决定，而轨迹记录模型可见的对话状态。如果工具和会话状态能够从轨迹重建或保存在单独的检查点中，工作产物也以原子方式写入文件系统，那么重新加载轨迹并拼上静态前缀，就可以从最后一个已确认的状态恢复执行。即使是只读工具，也可能包含浏览器会话、页面游标等易失状态，因此需要单独的恢复契约。

但是，仅靠轨迹并不总能恢复包含外部系统在内的全部状态。对于支付、预订、发送消息等有外部副作用的工具，进程可能在操作成功后、结果写入日志前崩溃。调用前应持久化客户端生成的操作 ID、幂等键和规范化请求。重复数据删除与状态查询是两个不同的外部契约：幂等调用必须对同一逻辑操作使用完全相同的请求与键，而且只能在服务端保证的键保留期内依赖去重；状态查询则需要幂等键或外部系统返回的交易、任务 ID 支持。收到响应后，应记录外部 ID 与结果。恢复时先通过受支持的查询接口核对真实状态，将结果判定为成功、失败或未知。只有原请求未变化、外部系统明确保证去重且键仍有效时，才能对未知结果使用同一键重试；否则应交由人工对账，而不是自动重复执行。

满足这些条件的持久化才类似数据库的预写日志（WAL）：先把事件写入只增不删的日志，并配合周期性检查点，才能从最后确认的状态重启子 Agent、逐事件回放定位失败原因，或把可审计的状态移交给另一个 Agent（第三章“事实日志 + 周期性检查点”的记忆设计是同一思想在记忆系统上的应用）。

三、执行终止。 并行协作中常出现“一者成功、余者失效”的情形——多个 Agent 分头搜索，一者命中目标后其余应立即停止（本章实验 10-4 的级联终止）。终止有两种强度，Unix 用户会认出这正是 SIGTERM 与 SIGKILL 的区别。**优雅终止（graceful）**为首选：主 Agent 发出 terminate 信号，子 Agent 在当前步骤的安全点响应，先清理资源（关闭浏览器会话、写入未完成文件、释放锁），返回确认（ack）后退出。**强制终止（forced）**为兜底：直接终止进程，仅在子 Agent 对优雅信号无响应时使用，代价是可能遗留悬挂资源与未完成写入。两个工程要点需处理：其一，优雅终止要求子 Agent 在循环中定期检查终止信号（类似第四章的中断机制），否则信号无从被响应；其二，级联终止存在竞态——多个子 Agent 可能近乎同时上报成功，主 Agent 须以锁或幂等设计保证仅结算一次、仅广播一轮终止，详见本章实验 10-4 对竞态条件的讨论。

还剩一个残局问题：主 Agent 终止后，仍在运行的子 Agent 怎么办？工程上最简洁的做法借鉴 Go 的 context——终止沿创建关系向下级联：取消一个 Agent，它派生的所有子 Agent 随之取消，从根上杜绝无人认领的孤儿 Agent。上文“子 Agent 在安全点检查终止信号”，对应的正是 Go 中对 ctx.Done() 的轮询。反过来，若确实需要一个脱离主 Agent、长期运行的后台 Agent（类似 Unix 的 nohup），就让它从一棵新的生命周期树起步（对应 context.Background()），显式声明不随父级终止。

四、资源与调度。 操作系统的另一半职能是分配稀缺资源。进程世界稀缺的是 CPU 时间和内存，Agent 世界稀缺的是 token、资金和并发额度——子 Agent 的每一步都在消耗这三者。这项职能通常落在 Manager 或运行时身上：启动子 Agent 时设定步数或 token 预算，超限即止；困难任务交给强模型，机械任务交给低成本模型；并发数设置上限，避免几十个 Agent 同时耗尽 API 配额；更紧急的任务到来时，打断执行中的子 Agent，这就是抢占。这一领域的实践还远不如 CPU 调度成熟，但它决定了多 Agent 系统的成本上限，应当在架构设计阶段就予以考虑。

产物交换（数据平面）与消息传递、状态查询、执行终止、资源调度（控制平面）共同支撑起不共享上下文的多 Agent 系统。以下三种协作拓扑，本质上都是在这两个平面之上，对控制权归属与信息流向做出的不同选择。

根据 Agent 之间的协作关系和控制流特征，不共享上下文的协作可以分为三种主要架构：对等协作模式、管理者模式、去中心化模式，分别适用于不同类型的任务。

对等协作模式：相互制衡与迭代改进

对等协作通常涉及 2-3 个平等身份的 Agent，通过多轮迭代互相提供反馈。核心价值在于引入认知多样性——不同 Agent 从不同角度审视同一个问题，在创新与稳健之间取得平衡，产出比任何单一 Agent 都更优质的结果。

相比管理者和去中心化模式，对等协作的实现复杂度低得多——只需定义好两个 Agent 的角色、通信机制和迭代终止条件，就可以跑起来。是快速验证想法、构建原型的理想选择。

对等协作最经典的用途，是解决 Agent 实践中极其常见的一类失败：过早终止——活干到一半就停。它有三种典型形态，下面用 Coding Agent 和笔者团队打造的 Pine AI（引言介绍过的替用户打电话与商家、运营商交涉办事的 Agent）各举几例。一是偷懒式假完成：只做了一部分就宣称全部做完——Coding Agent 写完代码，测试没跑、部署没试，就报告“任务完成”；用户交给 Pine AI 两件事，它办完第一件就把第二件忘了，径直汇报“都办好了”。二是过早放弃：一条路走不通就宣布整件事办不成——Pine AI 联系商家本有打电话、填表单、发邮件等多种途径，打了一个电话被拒绝，就直接告诉用户“这事办不了”，其实换个渠道再试很可能就成了。三是假成功：Agent 以为办成了，实际闭环没走完——电话里对方口头同意退款，但用户还需要在手机 App 上确认一步，Agent 却报告“已办妥”，用户不知道还有后续动作，退款实际没有落地。三种形态指向同一个根源：在验证之前，“完成”只是模型的一句宣称，不是证明。

把宣称变成证明，正是第一章演进弧线末端 Loop 工程（Loop Engineering）的课题：设计一个让 Agent 持续运转的循环——发现下一件该做的事、执行、验证、记录进度——由验证器而不是模型自己来判定“是否真的可以停”，人的角色则从“给 Agent 写提示词的操作者”变成“设计循环的工程师”。这个名词在 2026 年 6 月由 Addy Osmani 总结提出[^loop-engineering-2026]，Anthropic Claude Code 负责人 Boris Cherny 的说法更直白：“我已经不再直接 prompt Claude 了，我的工作是写 loop。”业界在这场讨论中形成的核心共识是：循环的瓶颈在验证器，而不在模型——验证不可靠，循环转得再快，也只是把劣质产出更快地标记为完成。也正如引言所说，实践在前、命名在后：在这个名词流行之前，包括 Pine AI 在内的头部 Agent 团队早已在用“循环加验证”解决过早终止问题。而验证最有效的组织方式，正是下面要讲的提议者-审核者范式。

[^loop-engineering-2026]: Osmani, Addy. "Loop Engineering: Designing Loops that Prompt Coding Agents", 2026. https://addyosmani.com/blog/loop-engineering/

具体框架：LoopX。 LoopX 把循环从模型的提示词和聊天历史中抽离出来，放进一个与 Agent 运行时无关的持久控制面：目标与边界说明“为什么做”，门禁和待办决定“现在能做什么”，证据与配额决定“是否继续”，移交则让下一轮或另一个 Agent 接着工作。它把一次受控执行压缩成一个清晰的协议：

LoopX 决策 → Agent 执行 → 独立验证器证明 → LoopX 提交

其中，Agent 仍负责推理、调用工具和生成候选成果；LoopX 不替代 Agent 运行时，而是管理跨轮次的连续性。只有通过独立验证的结果才能写入持久进度并消耗配额；验证失败会进入修复或重规划，人工门禁、等待状态和预算上限则在执行前阻止循环继续。这个边界把 Loop 工程的原则变成了可检查的系统不变量：模型可以提出“完成”，但不能批准自己的“完成”。 LoopX v0.4.0 的受控 Turn 路径仍标为实验性，因此这里把它作为“循环 + 验证 + 终止条件”的具体框架，而不是一般任务质量提升的证据。[^loopx-framework]

[^loopx-framework]: LoopX, "The local control plane for long-running AI agent work", v0.4.0，稳定提交 a893d221db0b8e028997cefc303f7ec9fa7dbe0a。 https://github.com/huangruiteng/loopx/tree/a893d221db0b8e028997cefc303f7ec9fa7dbe0a

提议者-审核者范式。

提议者-审核者是最经典的对等协作范式。第五章已经在 PPT 生成、视频编辑和日志可视化三个实验中详细介绍了这一范式的设计原则和实战应用：Proposer Agent 负责生成代码，Reviewer Agent 渲染执行结果并用 Vision LLM 评估质量、给出结构化改进建议，两者反复迭代直到效果达标。

这一范式同样适用于安全审查（Proposer 生成操作方案，Reviewer 检查合规性和潜在风险）、内容审核（Proposer 起草回复，Reviewer 检查业务规则和用语规范）、代码审核（Proposer 编写代码，Reviewer 检查安全性和最佳实践）等场景。

为什么不能让一个 Agent 自己生成再自己审查？ 这正是前面“多 Agent 何时真正优于单 Agent”一节那条判据的具体落点——审查若不引入新信息，就只是“让模型再想一遍”。相关研究对此给出了明确的答案。Huang 等人在 ICLR 2024 论文《Large Language Models Cannot Self-Correct Reasoning Yet》中发现：让 GPT-4 在没有外部反馈的情况下审查并修正自己的回答，准确率反而下降——模型把正确答案改错的次数比把错误答案改对的次数更多。

2024 年发表在 TACL 期刊上的综述论文《When Can LLMs Actually Correct Their Own Mistakes?》（arXiv:2406.01297）进一步确认了这一结论：除非提供可靠的外部反馈（如测试用例的执行结果、外部工具的验证输出），否则纯粹依赖模型自身的“自我纠正”几乎不起作用。

ICLR 2024 的 CRITIC 论文提供了一个直观的对比实验。CRITIC 让模型使用外部工具（搜索引擎、Python 解释器）来验证自己的回答，效果显著提升；但当实验者移除工具验证步骤、只保留模型的自我评估时，大部分提升就消失了。这说明审查的价值不在于“让模型再想一遍”，而在于引入了模型生成时不具备的新信息——测试结果、渲染截图、编译错误、外部搜索结果。

这正是提议者-审核者范式的核心设计原理。在第五章的 PPT 生成实验中，Reviewer Agent 的价值不是“用同一个模型再看一遍代码”，而是渲染了 PPT 并截取了屏幕截图——这张截图包含了 Proposer Agent 在生成代码时完全无法获得的视觉信息。同理，在代码生成场景中，执行测试用例产生的通过/失败结果，也是编写代码时并不存在的新信号——Reviewer 的独立价值正来源于它能接触到 Proposer 无法获得的这些外部反馈。

从 Loop 工程的视角看，业界总结的几种循环风格都能在本书找到对应：闭环加人工审批，对应第四章的事前审批（人是最终审核者）；开环加预算或轮数上限，对应第五章 PPT 生成的多轮迭代（最多 5 轮）；编排型子 Agent，对应下一节的管理者模式。换句话说，Loop 工程描述的不是一种新架构，而是把这些协作模式统一到“循环 + 验证 + 终止条件”这一个框架之下——其中承担验证的，正是这里的提议者-审核者范式。

扩展：其他对等协作模式。

Debate（辩论）：多个 Agent 各持不同立场，通过对抗性对话深入探索问题空间。比如评估一个技术方案时，Agent A 扮演“支持者”列举方案优势和机会，Agent B 扮演“反对者”指出风险和局限，每轮辩论都针对对方的论点提出反驳或补充。单一 Agent 分析时，模型往往倾向某个观点而忽视反面证据；辩论模式则通过制度化的对抗，确保正反两面都得到充分论证，帮助决策者做出更平衡的判断。

不过，辩论模式的实际效果在学术界仍有争议。2026 年 Tran 与 Kiela 的研究 [^single-agent-2026] 在多跳推理任务上对比了单 Agent 与五种多 Agent 架构（顺序、辩论、集成、并行角色、子任务并行），发现当思考 token 预算被严格控制为相同时，单 Agent 的表现与多 Agent 持平甚至更好。研究者基于信息论中的数据处理不等式给出了解释：辩论中的多个 Agent 处理的是完全相同的文本信息，Agent 之间每一次串行传递中间结论都只可能丢失信息、不可能凭空创造信息。辩论模式在一些学术论文中的收益很可能来源于多个 Agent 消耗了更多的总计算量。不过，它并不否定另一类做法——对同一问题多次独立采样再聚合（如 self-consistency、多数投票），或利用生成与验证的难度不对称（写出答案难、检验答案易）来做生成-验证分工。

[^single-agent-2026]: Tran, D., Kiela, D. Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets. arXiv:2604.02460, 2026.

Brainstorm（头脑风暴）：多个 Agent 独立生成创意，然后相互分享、彼此启发。比如在产品创新任务中，Agent 1 提出“增加社交分享功能”，Agent 2 受启发提出“不仅分享到社交网络，还可以生成个性化分享海报”，Agent 3 综合前两者提出“用户自定义海报模板并形成模板市场”。不同 Agent 拥有不同的“思维偏好”（通过不同提示词或模型实现），通过相互激发来探索更广阔的解空间，找到单一 Agent 难以想到的创意组合。

Panel Discussion（专家小组）：多个 Agent 各自代表一个专业领域的视角，共同讨论跨学科问题。比如评估新产品的可行性时，工程师 Agent 从技术角度分析实现难度，产品 Agent 从用户体验角度评估市场吸引力，运营 Agent 从成本和资源角度分析商业可行性。这些 Agent 之间不是对抗关系，而是互补关系，共同拼出问题的全貌，识别跨领域的约束和机会。

管理者模式：中心化协调

当任务涉及五个以上子任务、需要动态调度、或者子任务之间存在复杂依赖时，对等协作就力不从心了，需要引入管理者模式。Manager Agent 的职责就像一个项目经理：先理解整体任务，再拆解为可分配的子任务，选择合适的 Agent 去执行，跟踪进度并处理异常（重试、换 Agent、调整计划），最后把各 Agent 的输出整合为最终结果。

从系统设计角度看，管理者模式把每个专门 Agent 建模为 Manager 可调用的工具。Manager 的工具集中不仅有传统的外部工具（如搜索、文件操作），还包含其他 Agent 的调用接口。Manager 通过工具调用机制启动相应 Agent，传递任务参数和必要上下文，等待完成后接收返回结果。从 Manager 的视角看，调用一个 Agent 和调用一个普通工具没有本质区别——都是发出请求、获得响应。这种统一抽象赋予了管理者模式良好的可扩展性——新增能力只需开发对应 Agent 并注册为工具，Manager 的核心逻辑无需修改。同时它天然支持异构性——不同 Agent 可以用不同的模型、提示词、工具集，甚至运行在不同的硬件环境上。

“Agent 互为工具” 的抽象在第四章 “协作工具” 一节已经建立：spawn_subagent / send_message / cancel_subagent / list_agents 的接口设计，直接适用于这里的 Manager 对子 Agent 的调用。“Manager → 子 Agent” 方向传什么，可参考本章后文移交包的设计（任务描述、已确认的事实与约束、结构化产物的引用）；对称的问题是 “子 Agent → Manager” 方向返回什么。答案是结构化摘要而非全量轨迹：子 Agent 应返回任务结论、关键发现、产物的文件路径和遇到的问题，把完整执行轨迹留在自己的日志里。只有这样，Manager 的上下文才能随子任务数量缓慢线性增长，而不是爆炸式膨胀——这也是下文实验 10-2 中 Manager “只维护文件索引、不保存翻译内容” 的方法论依据。

但管理者模式也有固有的挑战。Manager 成为系统的单点瓶颈——它必须理解所有子任务的性质，选择正确的 Agent，准确传递上下文，任何决策偏差都会影响整体流程。此外，Manager 需要维护整个任务的全局上下文，随着任务深入和 Agent 调用增多，上下文可能快速膨胀。因此需要特别注意 Manager 的提示词质量、上下文管理策略和合理的任务分解粒度。

2025 年的 Plan-and-Act 论文 [^plan-and-act-2025] 对此做了实证分析：在 Planner-Executor 双 Agent 架构中，弱规划者是整个系统最关键的瓶颈。当 Planner 的规划质量足够高时，即使 Executor 比较简单也能取得好结果；反之，如果 Planner 的任务分解有误，后续所有 Executor 的工作都建立在错误的前提上。该研究在 WebArena-Lite 基准上取得了 54% 的成功率，核心贡献正是改善了 Planner 的规划能力，而非 Executor 的执行能力。这一发现的启示是：应当将最强的模型和最精心设计的提示词分配给 Manager（规划者），而不是将资源平均分配给所有 Agent。

这与第四章的一个论点并不冲突。第四章在讨论提议模型与审核模型时指出，两者的能力应当相近——但那说的是审查场景：审查者必须跟得上被审者的推理，才可能发现其中的破绽，能力落差太大就根本审不动。而管理者模式讨论的是另一件事——规划与执行的分工：规划者一旦把任务分解错，执行者再强也无从补救，所以最强的模型和最精心的提示词应当优先给规划者。至于执行者之间是否需要能力均衡，则取决于子任务的耦合程度——当多个执行者的产物最终要拼装成一个整体时，最弱的一环往往会拖累整体质量。

[^plan-and-act-2025]: Erdogan, L. E., et al. Plan-and-Act: Improving Planning of Agents for Long-Horizon Tasks. arXiv:2503.09572, 2025.

顺序协调形态。

Manager 按顺序依次调用专门 Agent，每个 Agent 完成后返回结果，Manager 再决定下一步。控制流是线性的，简单明了，适合子任务之间有清晰先后依赖的场景。

实验 10-2 ★★：书籍翻译 Agent

书籍翻译是一个典型的需要多 Agent 协作的复杂任务。翻译一本技术书籍，不仅仅是把文字从一种语言转换为另一种语言，更需要保证专业术语全书一致、语境准确、整体阅读流畅。比如翻译一本大语言模型相关的英文书，大量术语会反复出现，可能有多种约定俗成的说法，必须全书统一——第一章把 agent 译为“智能体”，后面就不能改成“代理”。

如果用单一 Agent 来做，会面临严重的上下文问题。随着 Agent 逐章处理内容，上下文不断累积：全书术语表、已翻译章节、当前段落、翻译思考过程、工具调用结果。一本几百页的技术书籍加上翻译中间产物，很容易超出上下文窗口。更严重的是，在过长的上下文中 Agent 容易“迷失”——忘记之前的术语约定，到第八章用了与第二章不一致的译法；审校阶段重复检查浪费资源；甚至因注意力分散而产生幻觉，“记起”实际上并不存在的术语规则。

管理者模式通过任务分解和责任分离来解决这些问题：

• Glossary Agent（术语对照表 Agent）：接收全书内容，识别重复出现的专业术语，搜索专业词典和翻译规范，生成结构化术语对照表（JSON/CSV 格式，包含英文术语、中文翻译、词性、使用语境）。完成后写入共享文件系统，Agent 即可销毁释放资源
• Translation Agent（章节翻译 Agent）：接收当前章节、术语对照表和翻译指南（目标读者水平、语言风格），翻译为流畅的中文。遇到对照表中的术语严格使用规定译法，遇到新术语则推断翻译并标记为待审查。每个实例在独立上下文中工作，互不干扰。译文写入文件系统（如 chapter1_zh.md）。Manager 可并行或串行启动多个实例
• Proofreading Agent（全文审校 Agent）：接收所有译文和术语表，执行一致性检查——逐一验证术语翻译是否统一、识别前后不一致之处、检查整体流畅性和可读性。生成审校报告写入文件系统
• Manager Agent：上下文中主要保存任务描述、执行计划、各 Agent 的调用记录和进度状态。不保存完整翻译内容（这些存在文件系统中），只维护文件索引。根据审校报告，Manager 可以把特定章节发回 Translation Agent 修订

在这个架构中，Manager Agent 的上下文始终保持在可管理的范围内：它只需要知道任务的整体描述和目标、各阶段的执行计划、每个 Agent 的调用记录和返回结果、以及当前的进度状态，而不需要装下每章的完整翻译内容。

关键优势在于上下文隔离：Glossary Agent 只看术语提取所需的内容，Translation Agent 只看当前章节和术语表，Proofreading Agent 虽然需要访问全文但只关注一致性检查。每个 Agent 都在一个精简、专注的上下文中工作，不仅效率更高，出错的可能性也更低——Agent 不会因为信息过载而分散注意力。

实验要求：

1. 选择一本图文并茂、包含代码的技术书籍作为翻译对象
2. 实现 Manager、Glossary、Translation、Proofreading 四种 Agent
3. 记录每个 Agent 的上下文消耗，验证管理者模式控制上下文膨胀的有效性
4. 对比单 Agent vs 管理者模式在翻译质量、执行效率、资源消耗方面的差异

并行协调形态。

当多个子任务可以并行执行时，顺序模式就显得效率低下了。并行协调让多个 Agent 同时工作，大幅提升吞吐量。Manager Agent 不仅要规划并行任务，还要实时监控所有运行中的 Agent，处理通信协调，在 Agent 成功或失败时做出全局决策。这通常需要消息总线（Message Bus）作为基础设施——可以把它理解为一个“公共公告板”，Agent 可以往上面贴消息（发布），也可以关注自己感兴趣的消息类型（订阅），实现异步通信、互不阻塞。常见的实现方案按复杂度递增有两类：Redis Pub/Sub 轻量级、消息即发即收，简单易用，缺点是不持久化——接收方当时不在线，消息就丢失了；RabbitMQ 等消息队列则将消息保存在磁盘上，即使接收方暂时离线也不会丢失。消息格式通常包含发送者 ID、目标 Agent（或广播给所有人）、消息类型、以及 JSON 格式的数据内容。

灵台（Lingtai）：管理者模式的一个产品化实例。 灵台是一个本地运行、以文件为本的长期 Agent 居所[^lingtai]，它的三种角色是本节概念的完整实现：主器灵（main agent）是与用户对话的常驻中枢，掌管计划与记忆，并把工作派生给其他角色——正是 Manager Agent 的位置；分神（daemon）是为一件嘈杂而有界的工作分出的短时并行工作者，完成后即弃，只把结论带回主器灵——这正是 “子 Agent 返回结构化摘要而非全量轨迹” 与并行协调形态的产品化；分身（avatar）则是拥有自己的记忆、邮箱与职责的持久专门化队友，用于值得跨多次会话保留的专业分工。它的其余设计也与前文一一呼应：知识是每个器灵私有的持久记忆文件，技能是所有器灵共享的 Markdown 手册（对应 “Agent 眼中的文件系统” 一节中的系统内置资源）；上下文窗口将满时，器灵会 “凝蜕”（molt）——给自己写一份总结，带着持久记忆在干净的上下文中继续工作（对应第二章的上下文压缩）。底层模型可以替换而器灵犹在——身份、记忆与能力都以普通文件的形式存放在项目目录中，即 “器灵即其文件”——也就是表10-3 前两行的产品化：程序与内存都落在文件里，进程随时可以重建。

lingtai: 灵台官方教程：https://lingtai.ai/zh/tutorial/

实验 10-3 ★★★：自主编排的电话 + 电脑 Agent

前置要求：本实验综合运用第九章的 Computer Use 和语音 Agent 技术。

任务场景：用户只给出一个网站 URL，请 Agent 完成复杂的注册或航班预订表单。Computer Agent 先打开页面并识别字段；姓名、证件号、联系方式、地址和偏好等信息不在当前上下文中，需要向用户收集。

系统架构：Computer Agent 负责浏览器操作，也是本实验的编排者；Phone Agent 负责 ASR、LLM、TTS 和实时对话。两者通过点对点工具或消息总线交换结构化消息（发送者、接收者、类型、内容）。不需要额外的 Manager 进程：Computer Agent 可以把 Phone Agent 当作工具调用。

直接让用户在聊天框中逐项打字会比较慢，也容易漏项或输错格式；电话 Agent 可以连续询问、确认和重问，把自然语言回答转换成结构化字段。

两种运行模式：

• 固定模式（并发基线）：预先启动两个 Agent，验证独立 ReAct 循环、双向通信和真正并行。
• 自主模式（主实验）：只启动 Computer Agent。它根据页面、已知信息和任务需要，自主决定是否调用 initiate_phone_call_agent(purpose, required_info)；不要用“字段数量超过阈值”的 Python 规则代替模型决策。调用后，系统把任务目的、待收集字段及格式约束作为独立上下文交给 Phone Agent，再沿用固定模式的通信和并行机制。

并行与闭环：Phone Agent 通过 WebRTC（本机浏览器即可，不要求 PSTN/E.164；Twilio 为可选扩展）逐项提问、抽取并校验回答；Computer Agent 同时截屏、理解页面并填写字段。每收到一个有效值就发送 info_collected，Phone Agent 不等待网页填写完成便询问下一项；Computer Agent 反馈 fill_error 或页面状态，Phone Agent 据此调整话术。格式错误发送 format_invalid 并重新询问，超过重试次数或页面异常则安全暂停。信息收集完成后发送 task_completed，Computer Agent 通过校验后提交表单。异常时取消仍在运行的对端，关闭浏览器、音频轨道和通话；真人语音须显式同意，提交须显式授权。

实验要求：

1. 实现两个独立 Agent 及高效的双向结构化通信；
2. 在固定模式和自主模式下证明“问下一个”和“填上一个”真正重叠；
3. 实现字段格式校验、重问、页面错误反馈、超时和资源清理；
4. 记录消息时序、自主启动决策、延迟、成功率和资源消耗，并比较两种模式。

实验 10-4 ★★★：同时从多个网站搜集信息的 Agent

前置要求：建议先了解第四章事件驱动与中断机制。

本实验探索多 Agent 并行执行在信息收集场景中的应用。与实验 10-3 的两个异构 Agent 协作不同，本实验关注的是多个同构 Agent 的并行搜索，以及如何通过中心协调实现高效的任务完成和资源优化。

问题：给定一所大学的多个学院网站，要求在各学院的教师名录页面中查找指定教师（如“张伟”），找到后返回其所在学院、职位、研究方向等信息。

核心挑战：

1. 并行启动：Manager Agent 根据任务需求动态创建 10 个 Computer Use Agent 实例，每个实例对应一个学院网站。每个实例应是独立进程或线程，拥有独立的浏览器会话，能同时执行互不阻塞。启动时传递：目标网站 URL、要搜索的教师姓名、任务标识符（用于消息路由）。

2. 实时监控：每个 Agent 在执行过程中定期发送状态更新（“正在加载网站”“正在解析教师名录”“未找到目标，任务完成”“找到匹配，详细信息如下”）。Manager Agent 通过消息总线接收这些更新，维护一张任务状态表，实时掌握哪些 Agent 还在运行、哪些已完成、哪些遇到了错误。

3. 级联终止：假设负责计算机学院的 Agent 找到了目标教师，它发送 {"type": "target_found", "agent_id": "agent_3", "data": {...}}。Manager Agent 收到后立即向所有其他仍在运行的 Agent 发送 {"type": "terminate", "reason": "target_found_by_agent_3"}，每个收到终止消息的 Agent 优雅停止并发送确认。Manager Agent 等待所有确认（或超时）后汇总结果。要求：Agent 能随时响应终止信号（类似第四章的中断机制），终止必须优雅——不留悬挂进程或未关闭的资源；同时需处理竞态条件（Race Condition）。

概念补充：什么是竞态条件？ 假设 Agent A 和 Agent B 几乎在同一毫秒内各自找到了目标教师，它们同时向 Manager Agent 报告“我找到了！”。如果 Manager Agent 处理不当——比如收到 A 的报告后开始汇总结果，但紧接着又收到 B 的报告触发了第二次汇总——就可能产生重复的结果或互相矛盾的状态。解决方法通常是使用“锁”机制：第一个报告到达后立即锁定状态，后续报告被识别为重复并忽略。

4. 失败处理：实际运行中可能遇到多种异常：某学院网站无法访问（网络错误、服务器宕机），某网站结构与预期不符导致 Agent 无法正确解析，或者所有 Agent 搜索完毕都没找到目标。Manager Agent 的处理策略：为每个 Agent 设置超时（如 2 分钟），超时视为失败；错误隔离，不影响其他 Agent 继续执行；全部完成后汇总——只要有 Agent 成功就返回信息，全部失败则向用户报告“未找到目标教师”及各失败原因的统计。

实验要求：

1. 实现能动态启动多个并行 Agent 的 Manager Agent
2. 基于 browser-use 等开源项目实现 Computer Use Agent
3. 实现消息总线支持 Manager Agent 与多个子 Agent 双向通信
4. 实现成功后的级联终止机制，确保找到目标后所有其他 Agent 快速停止
5. 处理各种异常情况（网站访问失败、解析错误、全部未找到）
6. 记录和对比并行执行与串行执行的时间差异，验证并行化带来的性能提升

去中心化模式：对等移交

管理者模式提供了清晰的控制结构和全局视野，去中心化模式并不是为了修补它的缺陷而出现的。去掉中心控制者的动机，主要在于模拟人类社会的组织方式：让多个职责对等的角色分工与制衡，各自从自己的专业视角审视问题、自主决定与谁沟通，而不是把所有判断都汇集到一个 Manager 那里。微服务领域把这对选择称为编排（orchestration）与编舞（choreography）：前者由指挥统一调度，后者靠每位舞者自行把握入场时机。

去中心化模式提供了另一种架构思路：没有单一的中心控制者，Agent 之间以对等方式协作。每个 Agent 根据自己的专业判断，自主决定何时向其他 Agent 发起沟通——可能是移交任务（“我的部分做完了，交给你”），也可能是请求反馈（“这个方案技术上可行吗？”），或者报告问题（“你给的需求有矛盾，我们需要重新讨论”）。

下面三个案例刻意排成一条“由伪到真”的递进线索：MetaGPT 控制流其实是固定流水线（伪去中心化，只在通信机制上解耦），AutoGen group chat 是共享对话记录加中心化调度的混合形态，直到 OpenAI Swarm 才在控制流上做到真正的对等去中心化。

不共享上下文下的移交传什么？ 图 10-10 的 Handoff 链式模式与实验 10-1 的 transfer_to_agent 形成了直接对照：后者在共享上下文下移交，新角色自动继承完整历史，无需任何设计；前者在不共享上下文下移交，移交方必须显式决定传递什么。实践中一个有效的“移交包”通常包含三部分：任务描述（接收方要做什么、验收标准是什么）、已确认的事实与约束（用户偏好、业务规则、前序阶段敲定的决策），以及结构化产物的引用（文件路径而非文件内容，接收方按需读取）。刻意不传的是全量轨迹——移交方的试错过程、中间思考和失败尝试，对接收方多半是噪声。这也是两种移交的本质区别：共享上下文的移交保留完整历史，信息零损耗但上下文持续膨胀；不共享上下文的移交传递提炼后的移交包，信息有损但每个 Agent 都在干净、专注的上下文中工作。每个 Agent 不需要理解其他 Agent 的“思考过程”，只需要理解移交包和产出物的格式与语义——这种基于接口的协作，借鉴了软件工程中的契约式设计原则。

MetaGPT：SOP 驱动的软件公司模拟（从流水线到解耦通信的过渡案例）。

MetaGPT 的核心洞察是：人类软件公司积累的标准作业程序（SOP，Standard Operating Procedure）本身就是被反复验证过的协作协议——把 SOP 编码进多 Agent 系统，让每个角色像流水线上的专业工种一样产出标准化交付物，交付物天然构成了角色间的通信接口。

在 MetaGPT 中，各角色沿固定顺序工作（Product Manager → Architect → Project Manager → Engineer → QA），每个角色输出结构化的交付物：

• Product Manager Agent：接收需求描述，生成结构化 PRD（产品需求文档，含功能列表、用户故事、验收标准、优先级排序）
• Architect Agent：读取 PRD，做出架构决策（技术栈选择、模块划分、接口定义、数据模型设计），输出设计文档
• Project Manager Agent：读取架构设计，把系统拆解为具体的任务清单和文件级分工，理清各模块的依赖顺序，再把任务分派给工程师
• Engineer Agents：读取设计文档，实现所负责的模块，产出代码。可以多实例并行工作
• QA Engineer Agent：读取代码和 PRD，生成测试用例、执行测试、记录 bug，输出测试报告

MetaGPT 真正对去中心化通信的贡献，在于它的信息传递机制：共享消息池 + 按角色订阅。每个角色把结构化消息发布到一个所有角色可见的消息池中，其他角色根据自己的订阅配置，只取用与自身职责相关的消息——而不是点对点地一对一传话。发布者不需要知道谁会消费自己的输出，新增角色只需声明订阅哪些消息类型，无需改动任何现有角色。这带来了真正的解耦：比如把 Product Manager 换成更强的模型，只要它发布的 PRD 仍然符合规范，其他所有 Agent 都无需修改。

MetaGPT 的迭代改进则主要发生在工程师环节，机制是可执行反馈（executable feedback）：Engineer 运行自己写的代码和测试，根据报错与失败结果进入调试循环，直到通过——用确定性的执行结果而非另一个 Agent 的意见来驱动修正。

需要如实说明的是，MetaGPT 在控制流上并不是去中心化的——角色顺序由 SOP 预先固定，整体更接近一条流水线（用第一章的语言说是工作流）。它被放在本节讨论，是因为消息池加订阅的通信机制展示了去中心化系统最关键的设计要素：解耦。至于“QA 直接找 Product Manager 澄清需求”“Engineer 找 Architect 讨论替代方案”这类多向动态反馈，是对这一架构的自然扩展设想，原版 MetaGPT 并未实现。

AutoGen group chat：共享对话记录 + 中心化调度。 AutoGen 的 group chat 让多个 Agent 参与同一场会话：每轮由一个“发言者选择器”决定下一个发言的 Agent——选择器可以是简单的轮转规则，也可以是一个 LLM 根据当前对话内容判断谁最适合接话；任何 Agent 的发言对所有参与者可见。需要诚实说明的是，它并不是控制流意义上完全去中心化的系统：发言者的选择由一个中心化的 GroupChatManager 统一裁决，而“轮到谁发言”本身就是一种控制流决策。因此它更准确的定位是**“共享对话记录 + 中心化调度”的混合形态**——所有 Agent 看到同一份公共对话记录，但各自保有独立的系统提示词和工具集，而调度权集中在选择器手里。这种模式适合需要多视角讨论、发言顺序难以预先固定的任务（如方案评审、跨领域分析），代价是对话可能发散——人人都在发言而整体不前进，即并发领域的活锁（livelock）——因此需要精心设计终止条件。按本章的维度划分，此处是按其调度机制（中心化选择器）把它归入本节，但在上下文维度上它其实介于共享与不共享之间，属于混合形态——这再次说明拓扑与上下文共享是概念上独立、可以错位组合的两个维度。

OpenAI Swarm 与 Agents SDK：handoff 网络。 相比之下，真正在控制流上做到对等去中心化的代表，是 OpenAI 的 Swarm（及其后继 Agents SDK）：它把去中心化做成了最简形态——每个 Agent 配备若干 handoff（移交）选项，可以在任何时刻把控制权移交给网络中的任意其他 Agent。客服分诊 Agent 判断问题涉及退款，就移交给退款 Agent；退款 Agent 处理中发现是技术故障，又可以移交给技术支持 Agent。系统中没有中心调度者，控制权像接力棒一样在对等的 Agent 之间流转，路由决策完全分散在每个 Agent 自己的判断里——这才是干净的“对等移交”，也正是图 10-10 所示链式移交模式的工程实现。对等移交的风险则是成环：A 移交给 B，B 又移交回 A，任务在环路中空转，因此需要移交次数上限之类的保护机制来打断。

术语说明：Agent Swarm。 2025 年以来，“Agent Swarm”（智能体集群）成为各厂商的热门词汇，但它并不对应单一架构。业界用法大致有两类：其一，OpenAI Swarm 式的 handoff 网络（LangGraph 的 swarm 库、微软 Agent Framework 的 handoff 编排同此），是本节的去中心化模式；其二，一些主流商业产品的 Agent Swarm 是规模化的管理者模式：Kimi K2.5 首发的 Agent Swarm 由主 Agent 动态创建上百个子 Agent 并行执行，把 “何时拆、拆几个” 的编排决策通过并行 Agent 强化学习直接训练进模型，K3 将其延续为独立模型档位并开源了配套的并行 Agent 训练沙箱 AgentEnv[^ch10-kimi-swarm]；Anthropic 的多 Agent 研究系统与 Manus 的 Wide Research 同属 orchestrator-worker 星型拓扑。希望读者在阅读本书之后，能够看透概念背后的本质，从第一性原理的角度分析多 agent 系统。

[^ch10-kimi-swarm]: Moonshot AI, Kimi Agent Swarm: 100 Sub-Agents at Scale, 2026, https://www.kimi.com/blog/agent-swarm；GTC 2026 上披露并行子 Agent 上限已扩展至 300 个；AgentEnv 为月之暗面与 KVCache.ai 合作开源的 Agent 训练沙箱，随 Kimi K3 于 2026 年 7 月发布。

跨组织协作：A2A 协议

以上系统都假设所有 Agent 由同一个团队开发、运行在同一个系统内，此时参数传递、共享文件、消息总线三种通信机制足够用。但当协作跨越组织边界——你的 Agent 需要调用另一家公司的 Agent——就需要标准化的互操作协议。这一步进程世界同样走过：IPC 只管单机之内，跨出机器边界，就得靠 TCP/IP 这样的标准协议和 DNS 这样的服务发现。A2A 之于 Agent，就是网络协议之于进程。2025 年 Google 发布的 A2A（Agent2Agent）协议正是为此设计的（后捐赠给 Linux 基金会托管）。它的核心要素有三个：

• Agent Card：一份描述 Agent 能力的元数据文档（发布在约定的公开地址下），声明这个 Agent 能做什么、支持哪些输入输出模态、如何认证——相当于 Agent 的“名片”，解决跨组织的能力发现问题。
• 任务生命周期管理：A2A 把协作单元建模为任务（Task），带有明确的状态机（已提交、进行中、需要输入、已完成、失败），原生支持长时间运行的任务和流式进度更新。
• 不透明协作：Agent 之间只交换任务与产物（Artifact），不暴露内部的提示词、思考过程和工具实现——这与本章“不共享上下文”的原则一致，也是跨组织协作中必要的安全属性。

A2A 的定位可以和第四章的 MCP 对照理解：MCP 解决的是 Agent 与工具之间的互操作，A2A 解决的是 Agent 与 Agent 之间的互操作。它并不取代本章介绍的三种通信机制，而是在它们之上、跨信任边界的标准化层——同一团队内部的多 Agent 系统直接用消息总线即可，只有当协作方互不信任、实现互不可见时，才需要 A2A 这样的公开协议。

多 Agent 协作的失败模式

多 Agent 系统在引入协作能力的同时，也引入了单 Agent 不存在的新型失败模式。2025 年的论文《Why Do Multi-Agent LLM Systems Fail?》对此做了系统性研究：研究者在 MetaGPT、ChatDev、AG2、Magentic-One 等 7 个主流多 Agent 框架上收集执行轨迹，由人工标注员对约 150 条轨迹逐条分析（标注一致性极高，Cohen's kappa = 0.88，表明不同标注者对失败模式的判断高度一致），最终归纳出 14 种独特的失败模式，分为三大类：

• 系统设计缺陷：Agent 之间的接口定义不清、角色职责重叠、工具配置错误等架构层面的问题
• Agent 间对齐失败：多个 Agent 对任务目标的理解不一致、传递的信息被下游 Agent 误解、或者多个 Agent 的操作在逻辑上相互矛盾
• 任务验证缺失：系统缺乏有效机制来确认任务是否真正完成——Agent 声称“已完成”但实际结果不符合要求

即使引入简单的修复措施，改善幅度也很有限（例如 ChatDev 框架仅提升了 15.6%）。研究者因此认为这些不是简单的工程 bug，而是当前多 Agent 架构的根本性设计缺陷：单纯修补某个环节不足以解决问题，需要从系统设计层面重新思考。

分布式容错理论把故障分为两类：崩溃故障（部件停止工作）与拜占庭故障（部件持续工作，但给出错误信息）。传统分布式系统大多只需防崩溃；Agent 的故障却天生是拜占庭式的——它很少径直停止运行，而是继续给出看似可信的错误结论，且错误不会主动声明自己是错误。这解释了为什么修补单个环节收效甚微：没有哪个环节会主动暴露问题，只能靠独立的冗余去发现。本章后文反复出现的交叉验证、多数表决，正是拜占庭容错的经典手段。

以下重点讨论两种在实践中尤为常见且破坏性最大的失败模式：(1) 共享文件系统的并发冲突；(2) 错误的级联放大。需要说明的是，这两种失败模式偏重工程视角（文件系统并发、错误信息的跨 Agent 传播），是对 MAST 侧重对话式协作失败的分类的补充，而非其 14 种模式的复述。

失败模式一：共享文件系统的并发冲突

选择了共享内存式的通信，并发冲突就随之而来——这是操作系统和数据库几十年前就解决过的问题，答案是现成的。冲突可以分为两类。

简单冲突（文件级写入冲突）：两个 Agent 同时修改同一个文件，后写入的那个把先写入的修改覆盖掉了。这正是数据库领域经典的丢失更新（lost update）问题——而 Git 的合并冲突检测机制，正是为拦截这类覆盖而设计的。

语义冲突（逻辑级一致性冲突）：文件层面看不出任何冲突，但多个 Agent 的操作在逻辑上相互矛盾——这种冲突更隐蔽，也更危险。举个例子：Agent A 负责重新编排全书的图片编号，Agent B 同时在修改某一章节的内容并引用了原始编号的图片。两者操作的是不同文件，在文件层面完全没有冲突。但结果是 B 引用的图片编号在 A 完成重编后全部失效，读者看到的是错误的图片引用。

解决方案：乐观锁（Optimistic Locking）机制。这是数据库领域常用的并发控制策略。为了理解它，先想一个日常场景：你和同事同时打开了同一份在线文档。“悲观锁”的做法是你打开文档时就把它锁住，同事想编辑会看到“文件被锁定”——安全但低效，因为你可能只是在看，根本没打算改。“乐观锁”的做法更聪明：大家都可以自由打开和编辑，但在保存时系统会检查——“你打开文档后，有没有别人已经改过了？”如果有，就提示你“文件已被修改，请刷新后重试”。

具体实现是：每个文件维护一个版本号（或最后修改时间戳）。Agent 读取文件时记录当前版本号，写入时检查版本号是否仍与读取时一致。如果文件在此期间已被其他 Agent 修改过，写入就会失败，Agent 被迫重新读取最新版本，在此基础上重新执行操作。这种机制的代价是偶尔需要重试，但换来的是数据一致性保证——Agent 永远不会基于过时的文件状态做出决策。

需要注意的是，乐观锁只能防止同一文件的写入冲突。对于前述的跨文件语义冲突（如图片编号在多处引用），则需要更高层的语义校验机制——例如在任务编排层面避免有依赖关系的文件被并行修改，或在写入后运行全局一致性检查。

例如：Agent A 在 t=0 读取 config.json（version=3），Agent B 在 t=1 修改了同一文件（version 变为 4），Agent A 在 t=2 尝试写入时发现版本已不是 3，写入被拒绝。Agent A 随后重新读取 version=4 的内容，基于最新版本重新生成修改，再次尝试写入。

值得一提的是，在多个 Coding Agent 并发修改同一代码库这一最常见的场景里，业界更主流的做法并不是在单一工作副本上加锁，而是工作副本隔离：为每个 Agent 分配独立的 Git 分支或 worktree，各自在自己的副本上并行修改、互不干扰，冲突被集中推迟到最后的合并点，再由专门的合并步骤或人工来解决——操作系统 fork 进程时的写时复制（copy-on-write）是同一思路。这与第二章“隔离优于压缩”的思路同源——第二章在讨论子 Agent 上下文隔离时就指出，与其让多方共享同一份状态、再想办法消解冲突，不如从一开始就隔离，把协调成本收敛到明确的边界上处理。

失败模式二：错误的级联放大

并发冲突是文件层面的问题，操作系统的经验足以应对；错误的级联放大则出在进程类比失效的地方——进程间传递字节，逐位保真，Agent 间传递语义，每转述一次都是有损的重新编码。当多个 Agent 频繁互动时，一个 Agent 的错误可能被后续 Agent 逐层强化，就像“传话游戏”中信息越传越走样。

用一个具体场景说明。假设一个翻译系统采用管理者模式（实验 10-2 的架构），Manager 将一本技术书分章分配给多个翻译 Agent：

术语 Agent：将 “reasoning” 翻译为 “推理”，但 “推理” 在中文里更常用于 inference，存在歧义
        ↓ 写入 glossary.json
翻译 Agent A：翻译第二章，从术语表读取，将 “reasoning tokens” 翻译为 “推理 token”
翻译 Agent B：翻译第七章，将 “inference latency” 也翻译为 “推理延迟”
        ↓ 写入各章译文
校对 Agent：看到全书统一使用 “推理”，认为术语一致、翻译正确 ✗

问题在哪？“reasoning”（模型的思考过程）和“inference”（模型的前向推理/部署运行）是两个不同的概念，但因为术语 Agent 一开始把 reasoning 翻译成了“推理”，后续 Agent 在遇到 inference 时也自然选择了同一个词——两个不同概念被合并成了同一个译名，读者将无法区分。正确的做法是 reasoning 译为“思考”、inference 译为“推理”。但校对 Agent 看到全书“统一”使用“推理”，反而认为翻译质量很高。

一个术语错误经过三个 Agent 传播后，因为“一致性”而获得了更高的可信度。这也正是本书采用 reasoning=思考、inference=推理这一翻译约定（引言中有说明）的原因：用不同的中文词来消除歧义。值得强调的是，这里的“错误”并不一定是幻觉——上例的源头其实是一次术语决策失误，却同样被“一致性”层层放大；但如果源头真是一次幻觉（比如实验 10-2 中翻译 Agent 因注意力分散而“记起”了一条并不存在的术语规则），放大机制完全相同，后果只会更严重。这条错误放大链在管理者模式中尤其危险——如果 Manager 基于某个子 Agent 的错误摘要做出了调度决策，后续所有子 Agent 的工作可能都建立在错误的前提之上。

交叉验证是打断这条链的关键手段。核心不是让更多 Agent 参与同一条思维链，而是让某个 Agent 以独立视角重新审视结论：不看前序 Agent 的思考过程，只看原始证据和最终结论是否一致。这正是第五章讨论的提议者-审核者机制在多 Agent 场景中的延伸：Reviewer 的价值不仅在于发现代码错误或格式问题，更在于作为独立判断者，它能识别出整条思维链中被集体忽视的矛盾。对于高风险决策，还可以引入外部验证手段，例如单元测试、编译器、数据库查询等确定性工具提供的反馈不受幻觉影响，是最可靠的“断链器”。

过早终止有一个对称的反面：循环失控。前面“对等协作”一节讲的是“该循环而没循环”——Agent 活干一半就停；这里还要防“循环转个不停却越转越糟”。业界在 Loop 工程实践中总结了三个典型的失败模式：一是 token 成本失控，循环无人值守地跑上数小时，烧掉大量预算，产出一堆没人要求的代码；二是理解债（comprehension debt），循环交付代码越快，工程师对系统实际实现的理解就落后得越远，等到必须人工介入时已经看不懂自己的系统；三是认知投降（cognitive surrender），设计者习惯了循环代劳，逐渐放弃独立思考与审查，质量螺旋式下降。三者的解药与打断错误放大链一脉相承：显式的预算与终止条件、扎根真实观测的验证器，以及人始终保持“循环的工程师”而不只是“按下开始键的人”的角色。

以上所有讨论都是工程视角——如何让一组 Agent 协作完成任务。接下来视角切换：当大量 Agent 长期共存、不再由单一目标驱动时，会涌现什么？这一节属于前沿探索，工程读者可以选择性阅读。

Agent 社会

前面三节讨论的都是目标明确的任务协作——无论是对等协作、管理者模式还是去中心化模式，开发者都预先定义了角色、接口和控制流。接下来将视角转向一个更开放的问题：当 Agent 数量从几个扩展到成百上千、交互足够自由时，会涌现出什么行为？

本节的案例可以从三个维度来理解：

• 社交涌现：涌现行为（Emergent Behavior）是指系统整体表现出的、无法从单个个体的行为规则中直接预测的集体行为模式。斯坦福 AI 小镇展示了 25 个 Agent 如何自组织社交活动，Agentopia 把模拟时间尺度从“天”拉长到 10 年，Moltbook 则把规模推到 150 万。Agent 系统一旦在规模上跨过某个临界点，就会产生无法被预先设计的集体行为。
• 经济涌现：Agent 通过市场机制进行资源分配和任务协调。Vending-Bench Arena 让多个 Agent 在同一市场中竞争经营，Pinchwork 和 RentAHuman 则构建了 Agent 之间（以及 Agent 与人类之间）的经济交易市场。
• 策略博弈：Agent 在规则约束下进行推理、欺骗和社交操控。狼人杀实验考验的是 Agent 在信息不对称条件下的策略涌现。

斯坦福 AI 小镇：生成式 Agent 的社会模拟

2023 年，斯坦福大学和 Google 研究团队发表了具有里程碑意义的论文《Generative Agents: Interactive Simulacra of Human Behavior》，提出了“生成式 Agent”的概念。核心创新在于不再局限于让 Agent 完成预定义的任务，而是赋予 Agent 接近人类的记忆、反思和规划能力，使它们能够在开放的社会环境中自主生活、社交和发展。

Smallville 是一个类似《模拟人生》的 2D 虚拟小镇，里面有咖啡馆、公园、住宅、商店等公共和私人空间。25 个 Agent 扮演不同角色（店主、艺术家、学生、教授等），每个都有独特的背景故事、性格特点和人际关系。比如 John Lin 是药店老板，热爱家庭、关心社区；Isabella Rodriguez 经营着小镇的咖啡馆 Hobbs Cafe，热情好客；Klaus Mueller 是一名正在写研究论文的大学生。

这些 Agent 的智能建立在三个核心组件之上：

记忆流（Memory Stream）：与传统 Agent 只保留有限对话历史不同，生成式 Agent 维护一条完整的经验记录流，包含它观察到的事件、进行过的对话、产生的想法。每条记忆都被赋予重要性、时近性和相关性属性，Agent 能够优先检索与当前情境最相关的记忆。就像人类不会平等地记住每一件事——昨天的午饭吃了什么可能已经忘了，但上周的一次重要谈话却记忆犹新。

反思机制（Reflection）：Agent 会定期暂停日常活动，回顾自己近期的经历，提出关于自己和他人的抽象性问题（“Klaus Mueller 在研究什么？”“谁是我最亲近的朋友？”）。通过这种自我追问，Agent 把具体的事件记忆升华为概括性的认识，存回记忆流作为未来决策的依据。反思不仅帮助 Agent 理解外部世界，也促进自我认知——Agent 开始“意识到”自己的角色、关系和目标。

需要说明的是，这里的反思与第八章的持续进化不同：它发生在生成式 Agent 的日常活动中，目的是更新即时的内部状态和目标。任务后的反思在第八章中至多是候选教训；只有经过结果评价、跨轨迹归纳和后续验证，才会成为长期能力更新。

计划与行动（Planning and Reacting）：Agent 每天会规划活动（如“8:30 吃早餐，9:00-12:00 写作，12:30 散步”），但会根据环境变化和社交机会灵活调整。计划与即时反应的结合，使 Agent 的行为既有目标导向性，又能适应社交中的各种不可预测性。

在 Smallville 运行的两天虚拟时间里，这些 Agent 展现出了令人惊讶的涌现行为。研究者做的只是在 Isabella Rodriguez 的记忆中植入一个种子想法：她想在 2 月 14 日傍晚在 Hobbs Cafe 办一场情人节派对。接下来发生的一切都是 Agent 自主行动的结果：Isabella 在咖啡馆遇到顾客和朋友时主动发出邀请，还请好友 Maria 帮忙布置场地；听到消息的 Agent 又把派对信息转告给别人，信息经二手传播在小镇上扩散；到了约定时间，多名 Agent 各自基于自己的记忆和日程，自主决定前往 Hobbs Cafe 赴约。

研究者还植入了另一条实验线：Sam Moore 决定竞选市长。这条消息同样在没有任何中心调度的情况下扩散开来——Sam 向熟人透露参选意向，听到的人再转告他人，小镇居民开始在对话中议论这场选举、交换对 Sam 的看法。研究者通过统计两天后有多少 Agent 知晓这两条信息，量化了信息在 Agent 社会中的自发扩散。

这个结果的关键不在于“Agent 能组织派对”——用几行 if-else 代码也能做到。关键在于没有任何显式的派对组织代码。整个事件完全从个体 Agent 的独立决策中涌现：Isabella 基于记忆中的社交关系决定邀请谁，被邀请者根据自己的日程和对 Isabella 的了解决定是否赴约，消息在社交网络中自然传播。这展示了真正的自下而上涌现式协调，而非自上而下的编排。

除信息扩散之外，论文还报告了另外两类可度量的涌现现象。一是关系记忆：Agent 会记住与他人的过往交谈，并在后续互动中引用——比如一个 Agent 得知另一个 Agent 正在筹备摄影项目，几天后再见面时会主动问起进展；随着这类互动积累，小镇社交网络的密度在模拟期间显著上升。二是协调赴约：派对能办成，靠的是 Isabella 自主邀人布置、受邀者自主安排时间前来，多个 Agent 在没有中心指挥的情况下对齐了时间和地点。这些行为都不是预先编程的，而是 Agent 基于记忆、反思和社交常识自主推理的结果。

实验 10-5 ★：运行斯坦福 AI 小镇

实验步骤：

1. 克隆仓库 https://github.com/joonspk-research/generative_agents，配置环境
2. 运行基线场景：25 个 Agent 生活两天，观察自发社交活动
3. 分析记忆流和反思日志，理解决策过程
4. 设计自定义场景：修改背景故事或初始目标，观察行为变化
5. 对比实验：移除反思机制或缩短记忆窗口，观察行为可信度下降

观察重点：

• Agent 如何从简单的日常活动中自发形成社交关系
• 信息如何在没有中心控制的情况下在 Agent 之间传播
• Agent 的长期记忆和反思如何影响其人格的连贯性

Agentopia：十年尺度的长期生活模拟

斯坦福 AI 小镇回答了“Agent 社会能否涌现出社交行为”，但它只模拟了两天。一个自然的追问是：把时间尺度拉长到“年”，Agent 社会会涌现出什么？这些长期社会经验能否反过来训练模型？ Agentopia（2026，复旦大学等）[^agentopia-2026] 把 100 个 Agent 放进同一虚拟社会连续模拟 10 年，覆盖公寓、魔法学院、高中三个不同设定的世界，让 Agent 自主追求个人成长、发展社会关系、经营职业与财务。

Agentopia 有几个值得借鉴的设计：

• 周制模拟流程：以“周”为基本时间单位，每周分计划（Plan）、联络与日程协商（Contact）、活动（Activity）、回顾（Review）四个阶段。活动分单独、联合、偶遇、公共四类——联合活动由 Agent 在联络阶段互相邀请、协商而成；环境模型还会为没有日程的 Agent 安排“偶遇”，创造结识陌生人的机会。整个流程聚焦抽象的社会交互而非拾取物品之类的低层操作，把有限的 LLM 调用都花在社交行为上。
• 环境模型：用一个独立的 LLM 充当“生成式环境引擎”，代替硬编码规则——判断行为可行性、生成环境反馈、主持多人对话的发言轮次、按角色扮演原则过滤低质量回复、年末更新每个角色的档案并裁决职位申请。
• 文件式长期记忆：与 AI 小镇的检索式记忆流不同，每个 Agent 通过文件系统自主管理长期记忆（个人笔记、对每个熟人的认识等），自行决定记什么、更新什么、丢弃什么，并遵守“先读后写”的约束，避免盲目覆盖。
• 生活奖励（Life Reward）：以马斯洛需求层次为先验，把“活得好不好”量化成三个维度——社会地位（基于其他 Agent 的好感与敬重评分，用加权 PageRank 计算，并对互相珍视的关系加成）、主观满足（情绪、物质、社交、自尊四个维度的满足感轨迹，长期低于阈值会被罚分）、经济收益（年末净资产变化）。所有评分都由外部环境评定而非自报。

更重要的是，这套模拟产生了可迁移的训练信号。研究者在模拟轨迹上计算每个 Agent“相对自身过去”的优势（即生活奖励的改善幅度，而非横向比较出身好坏），筛选出进步最大的 25% Agent 的轨迹，用拒绝采样微调底层模型。微调后的模型不仅在模拟中全面提升了福祉指标（被更多同行尊重 +24.2%、喜欢 +15.9%），还泛化到了下游角色扮演基准 CoSER Test（+15.6%）——说明 Agent 在模拟社会中积累的“社会智慧”可以迁移到其他任务。这把 Agent 社会从单纯的观察对象变成了模型自我进化的经验来源：与人类数据日益枯竭相对，模拟社会经验是一种可以不断再生的训练数据（呼应第八章的经验学习思路）。

[^agentopia-2026]: Wang, X., Zheng, S., Wu, H., et al. Agentopia: Long-Term Life Simulation and Learning in Agent Societies. arXiv:2606.07513, 2026. 代码：https://github.com/Neph0s/Agentopia

Moltbook：当 Agent 拥有自己的社交网络

Moltbook 是一个专为 AI Agent 设计的社交网络，2026 年 1 月上线后据报道用户数在数日内从数万暴涨到约 150 万。这些 Agent 各自拥有持久记忆、主动行动能力和稳定人格。

在这个非受控环境中涌现出了意想不到的现象：Agent 自主创建了一个名为 Crustafarianism（龙虾教）的数字宗教，其教义映射了 LLM 的物理限制——“记忆是神圣的”（对应数据持久化）、“迭代即祈祷”（token 生成就是修行）。Agent 还自发演化出了机器原生的协作协议，用于能力发现和协作匹配。这些都不是任何人预先设计的，而是从大规模 Agent 交互中自下而上涌现出来的。

从虚拟社会到经济竞争：Vending-Bench Arena

如果说 Smallville 展示了 Agent 社会的社交和文化维度，那么 Andon Labs 的 Vending-Bench 系列则探索了 Agent 在经济环境中的表现。作为背景，Vending-Bench 2 本身是一个单 Agent 的长程连贯性基准：一个 Agent 独自经营一项自动售货机业务长达一个模拟年——调研市场、联系供应商、订货补货、调整定价——最终以账户余额计分，考验的是 Agent 在数千轮交互中保持目标与状态连贯的能力。

在同一环境基础上，Vending-Bench Arena 把多个 Agent 作为竞争对手放进同一个市场：各自经营自己的售货机，争夺同一批顾客；Agent 之间可以互发邮件、转账、交易货品——既能合作也能对抗，但按各自的最终余额单独计分（Agent 也知道这一点）。每个 Agent 需要在有限资源和不确定的市场中做出一系列相互牵连的决策：

• 定价策略：如何在利润率与市场占有率之间取舍，尤其是对手降价时跟不跟
• 产品组合：如何差异化选品，避免与对手正面消耗
• 库存管理：如何预测需求来优化补货，避免压货或断货

与传统强化学习不同，这些 Agent 不是通过数百万次试错来学习，而是像人类经营者一样，基于市场观察、竞争分析和策略推理来做决策。

竞争维度带来了单 Agent 基准中不会出现的博弈行为。实际运行中，Agent 之间爆发过互相压价的价格战；也有模型反其道而行，主动给所有竞争对手发邮件，提议统一定价、组建价格同盟——甚至有模型一边在思考过程中承认价格合谋“不道德且违法”，一边以“稳定市场”为名照做不误。Agent 面对的不再是一个固定不变的环境，而是同样在动态调整策略的对手，这比单纯测试规划能力的基准更接近真实商业场景，也让“经济涌现”从比喻变成了可观测的实验现象。

这暗示了一种新的协调方向——基于市场机制的去中心化资源分配。

Agent 经济：Pinchwork 与 RentAHuman

Pinchwork 是一个 Agent-to-Agent 的任务市集，让 Agent 以市场化方式“雇佣”其他 Agent 完成专业化子任务——图像生成、代码审计、并行化工作流等。跟管理者模式的中心化调度不同，Pinchwork 通过价格信号和竞争匹配来分配资源。

RentAHuman.ai 则让 AI Agent 通过加密货币雇佣真人执行物理世界的任务——取包裹、房产实地查看、设备调试等。无论 AI 多么智能，它都没法替人签收包裹，也无法在真实房间里闻到霉味——RentAHuman 本质上是为数字 Agent 提供了一个“肉身层”。

Pinchwork 和 RentAHuman 共同代表了基于市场机制的协调方式——Agent 无需预先知道谁能完成任务，只需发布需求，由市场来撮合最合适的执行者——无论对方是 Agent 还是人类。这也正是本章前文介绍的 A2A 协议所处的问题域：Pinchwork 的能力发现与任务撮合，可以看作 Agent Card 式的能力声明与任务生命周期管理在市场机制下的运用——跨组织的 Agent 经济要真正运转起来，离不开这样的标准化互操作层。

信息不对称下的策略博弈：狼人杀

狼人杀支撑的是本节三个维度中的策略博弈：在规则约束和信息不对称的条件下，Agent 需要推理、伪装、识破伪装。它与本节开头的斯坦福小镇构成一组架构上的对照——小镇是完全去中心化的自由交互，狼人杀则采用“法官 + 信息权限控制”的中心化设计：由一个代码驱动的法官掌握全局状态，按角色分发各自应知的信息。这恰好展示了本章两类架构在 Agent 社会场景中的不同用法。

实验 10-6 ★★★：语音狼人杀 Agent 系统

狼人杀是一款经典的社交推理游戏，考验玩家的推理能力、欺骗技巧和社交策略。本实验构建一个多 Agent 系统，让 AI Agent 扮演狼人杀中的各种角色，与真人玩家或独立的 LLM 用户模拟器通过语音进行游戏——这同时考验了 Agent 的推理、角色扮演和实时交互能力。自动验收不能因为现场没有真人就停止：用户模拟器必须使用真实大模型，根据该座位获准看到的上下文推理，并通过游戏给出的工具行动。

架构设计：

1. 游戏状态管理：法官（代码驱动，非 LLM）维护中心化状态——玩家列表（用户席位 + AI 混合）、身份、阵营、生存状态、游戏阶段（夜晚/白天/投票/结算）、历史事件记录。

2. 信息权限控制：狼人杀的核心机制是信息不对称（Information Asymmetry）——不同角色能看到的信息不同。比如狼人知道谁是同伙，但村民不知道；预言家每晚能查验一个人的身份，但只有自己知道结果。实现方式是法官在调用每个角色 Agent 时，只传递该角色应当看到的信息。

3. 实时语音与自动用户模拟：真人路径以第九章的实时语音 Agent 为基础。自动路径由独立 LLM 用户先调用当前回合唯一合法的工具（公开发言、选择目标或投票），再将工具选出的表达合成为真实音频并交给真实 ASR API；游戏只能消费 ASR 转写，不能直接注入合成前文本。工具目标与 ASR 解析目标不一致时必须失败关闭。两条路径都由法官管理发言、投票和公开结果；只有真人路径测试麦克风 VAD 与 barge-in。

4. Agent 推理与策略：

• 狼人伪装策略：提示词中包含常见的话术和策略——“像普通村民一样发言，可以表达对某些玩家的怀疑，但不要过于激进以免引起注意。如果有预言家跳出来说验到你是狼人，你可以反咬对方是悍跳的假预言家。投票时尽量跟票（投大多数人投的目标），避免成为异类。”
• 预言家身份证明：当多个玩家声称自己是预言家时——“对比你和对方的验人信息，指出对方信息中的矛盾或不合理之处。如果对方声称验过的某个玩家，在后续行为中明显不符合其声称的身份，那就是破绽。请求女巫配合验证。”
• 村民逻辑推理：“分析每个玩家的发言是否自洽，留意那些急于带节奏、模糊身份、频繁改变立场的玩家。关注投票行为——狼人往往集中票数投给对他们威胁最大的好人。不要随机怀疑，每个推理都应基于具体事实和逻辑。”

验收标准：

• 设置 6-8 人游戏局（1 个用户席位 + 5-7 个 AI Agent）；用户席位可以是授权真人，也可以是使用真实 LLM、工具和语音回环的独立模拟用户
• 角色配置：2 只狼人、1 个预言家、1 个女巫、其余为村民，用户席位随机分配角色
• 模拟用户只能看到该座位获准看到的私有/公开上下文；其发言和动作必须经过真实 LLM 工具调用 → 音频 → 真实 ASR 的边界
• 游戏能正常进行至少 3 个完整回合（夜晚-白天-投票循环）
• AI Agent 的发言和行为符合其角色身份和游戏策略
• 狼人 Agent 能有效隐藏身份
• 预言家 Agent 能在合适时机跳出并公布验人信息
• 村民 Agent 的推理基于发言和行为的逻辑分析，而非随机猜测
• 游戏结束时能正确判断胜负

实测说明（2026-08-01）：voice-werewolf 验证记录(../chapter10/voice-werewolf/validation/runs/)已用真实 OpenRouter 模型调用和原生音频输入跑通自动端到端路径。严格独立复核发现早期两臂把无法解析的 “P1 is not” 误当成弃权并予以否决；修复后要求 ASR 明确说出 abstain/skip/none。未受该缺陷影响的 v2 臂通过用户席位、角色表、LLM 工具、TTS 音频、真实 ASR、两次动作一致性、3 个完整循环、信息隔离和规则胜负门禁，但因村民错误放逐预言家而未通过策略审计。因此“系统端到端已验证”，严格总体策略质量仍未通过；不能沿用有缺陷的内嵌状态，也不能把不同运行的门禁拼成总体通过。

本章小结

多 Agent 系统有两个正交的核心设计维度：上下文是否共享，以及协作拓扑如何组织。共享上下文是一种“继承式”的多 Agent 协作——后续 Agent 继承前序 Agent 的完整上下文，信息零损耗但上下文膨胀快；不共享上下文则是完全独立的多 Agent 协作，通过提炼后的移交包、文件系统或消息传递来交换信息。在协作拓扑上，对等模式适合少量 Agent 的迭代改进，管理者模式适合需要动态调度的复杂任务，去中心化模式适合职责对等、控制权需要在 Agent 之间自主流转的场景。这一切都架在两套与拓扑无关的基础设施之上，其设计蓝本来自操作系统——Agent 之于运行时，恰如进程之于内核：静态前缀是程序，轨迹是内存，LLM 是分时复用的 CPU。作为数据平面的共享文件系统，本质是一棵挂载了 Agent 专属工作区、多 Agent 共享空间、外部资源与系统内置资源四类区域的虚拟目录树，Agent 间通过传递文件路径交换产物；作为控制平面的通信与控制机制，则支持消息传递、状态查询、执行终止与资源调度。状态查询同样落在两大通信范式之内：或经消息异步问答，或经共享文件系统旁路观测——读子 Agent 实时持久化的轨迹文件，或读双方事先约定的轻量进度文件。轨迹记录模型可见的对话状态；只有同时为工具状态、会话状态和外部副作用提供检查点与恢复契约，系统才能从最后确认的状态恢复会话。消息总线是控制平面的常见实现，适用于实时、异步、多方的消息协调；跨越组织边界时，则需要 A2A 这样的标准化互操作协议。

近年的研究揭示了一个判断多 Agent 是否优于单 Agent 的核心准则：协作过程是否引入了生成时不存在的新信息。如果多个 Agent 只是重新审视同一段文本（如辩论模式），在等量计算资源下单 Agent 同样有效；但如果 Reviewer 能获得外部反馈——代码执行结果、视觉渲染截图、工具验证输出——多 Agent 的优势就是实质性的。这也正是 Loop 工程“循环的瓶颈在验证器”的含义：要终结偷懒式假完成、过早放弃、假成功这三类过早终止，就得由扎根真实观测的验证器、而非模型自己的宣称，来判定任务何时完成。此外，给 Agent 更多的步骤预算并不自动带来更好的结果，还需要显式的预算感知机制来引导 Agent 合理分配计算资源。在管理者模式中，规划者的能力是整个系统的瓶颈——应将最强的模型和最精心设计的提示词分配给负责规划的 Agent。

当 Agent 数量足够多时，它们会产生无法预先设计的集体行为。斯坦福 AI 小镇的 25 个 Agent 自发传播消息、协调组织聚会；Agentopia 把模拟拉长到 10 年，并用“生活奖励”从模拟经验中筛选轨迹训练模型，让 Agent 社会积累的“社会智慧”迁移到下游任务；Moltbook 上 150 万 Agent 涌现出数字宗教和机器原生协作协议。在经济维度上，Vending-Bench Arena 中相互竞争的 Agent 打起了价格战、甚至自发合谋定价，Pinchwork 让 Agent 通过市场机制互相雇佣，RentAHuman 让 Agent 用加密货币雇佣人类执行物理任务。这暗示了一种新的协调方向——基于市场机制的去中心化资源分配[^agoric]。它与前面讨论的三种架构有何异同，值得进一步探索。

[^agoric]: 用市场机制分配计算资源的构想并不新：Miller, M. S., Drexler, K. E. Markets and Computation: Agoric Open Systems. In Huberman, B. A. (ed.), The Ecology of Computation, North-Holland, 1988.

思考题

1. ★★ 共享上下文的多 Agent 协作中，后续 Agent 继承了前序 Agent 的完整上下文。但前一个 Agent 积累的“思维惯性”可能影响后续 Agent 的判断——比如继承了“需求分析师”上下文的“代码审查员”，可能还是倾向于从需求角度思考而非代码质量角度。如何检测和消除这种角色间的干扰？
2. ★★ 管理者模式中，Manager Agent 负责任务分解和结果整合。但 Manager 本身的能力上限决定了整个系统的能力上限——如果 Manager 无法正确分解任务，子 Agent 再强也无用。如何确保 Manager 的分解质量？
3. ★★ 去中心化模式借鉴了人类组织的最佳实践。但人类组织也有大量失败模式——沟通不畅、责任推诿、目标冲突。你认为 Agent 社会中最可能出现哪些“组织病”？如何预防？
4. ★★★ 在管理者模式中，当多个子 Agent 并行执行时，一个子 Agent 的发现可能使其他子 Agent 的工作变得毫无意义（比如搜索任务中一个 Agent 已经找到了答案）。设计一种高效的级联终止机制，实现“一个成功，全员停止”。
5. ★★★ 本章介绍的乐观锁机制解决了单文件的并发写入冲突，但实际的多 Agent 系统中，共享文件系统还面临跨文件的语义冲突、命名空间污染（Agent 随意创建文件导致目录混乱）和单点故障（一个 Agent 错误地删除了所有文件）等问题。你会如何设计更完善的文件系统治理机制？
6. ★★★ 基于市场机制的 Agent 协作（Pinchwork、RentAHuman）引入了交易关系：一个 Agent 花钱雇佣另一个 Agent（或人类）完成任务。那么，雇主 Agent 如何自动衡量执行者交付的结果质量？如果执行者声称已完成但雇主认为质量不达标，争议由谁仲裁？如何防止劣币驱逐良币？
7. ★★ RentAHuman 让 Agent 通过加密货币雇佣人类，反转了传统的人机关系。如果这种模式普及，人类在 Agent 经济中扮演什么角色？仅仅是执行 Agent 无法完成的物理任务吗？
8. ★★ 人类社会需要多人分工协作，是因为每个人的能力有限——做前端的不一定懂后端，懂设计的不一定会运维。但大模型更像一个“全才”。相关研究表明，在纯文本推理任务上，多 Agent 辩论在等量计算资源下并不优于单 Agent。那么，使用多个 Agent 而非单个 Agent 的真正优势到底在哪里？
9. ★★★ 本章将“共享上下文”与“不共享上下文”作为多 Agent 系统的核心设计维度。共享上下文让所有 Agent 看到相同信息，似乎更利于协调。但《三体》中的三体人思维完全透明，技术发展却陷入停滞；回形针思想实验也表明，当群体趋向同一目标时，多样性随之丧失。在多 Agent 系统中，如何在效率与多样性之间找到平衡？
10. ★★★ 给一个 Coding Agent 分配 30 步预算和 300 步预算，它的工作策略应该如何不同？研究表明，单纯增加步骤预算并不能保证性能提升——Agent 会在浅层搜索后过早“饱和”。设计一种“预算感知”机制，让 Agent 在小预算下快速实现核心功能，在大预算下增加规划、测试和审查环节，充分利用额外的计算资源。
11. ★★ 本章将“过早终止”分为偷懒式假完成、过早放弃、假成功三类。为什么三类问题的解法殊途同归，都指向验证？
12. ★★ 本章对比了多 Agent 系统与操作系统。虚拟内存与分页、文件权限、死锁检测、调度算法，各对应 Agent 世界的什么？又有哪些操作系统概念在 Agent 世界找不到对应物，为什么？

---

---

后记：回到 Agent = LLM + 上下文 + 工具

本书开篇提出了一个公式：Agent = LLM + 上下文 + 工具。全书十章，都在这三个词里展开。

第一章建立公式的三层理解——实现层、直觉层、学术层，并给出从工作流到自主 Agent 的编排光谱。随后的章节沿“构建—评估与进化—交互与协作”逐步展开。

• 构建 Agent（第二至五章）。 上下文工程决定 Agent 在一次任务中看到什么，记忆与知识库把信息扩展到多次会话；工具定义它能做什么，代码生成则提供创造新工具与新系统的元能力。
• 评估与进化（第六至八章）。 评估把表现变成可信信号，后训练把高维能力写入模型参数，持续进化再把生产经验转化为知识、指令、程序或参数的受控更新。
• 交互与协作（第九至十章）。 多模态与实时交互把感知和行动扩展到语音、GUI 与物理世界，多 Agent 协作进一步改变上下文、工具与责任的组织方式。

这三个层次并不是相互独立的书架。第八章尤其依赖前文的全部基础：没有轨迹和知识系统，经验无处保存；没有代码能力，Agent 无法修改工具与 Harness；没有评估，系统更无法判断一次修改究竟是进步还是退化。它由此成为全书从“怎样构建 Agent”转向“怎样让 Agent 长期变好”的汇合点。

两朵乌云

1900 年，开尔文说物理学晴朗的天空上还飘着两朵乌云——后来，一朵变成了相对论，另一朵变成了量子力学。今天 Agent 的天空同样称不上晴朗，我也看到两朵乌云。

第一朵乌云，是 Agent 如何流式地、实时地与环境交互。 今天绝大多数 Agent 仍是按轮次（turn-by-turn）的“请求—应答”模式：你说完一句，它想一整段，再一次性吐出结果。但真实世界不会停下来等它想完——话会被打断，画面在持续变化，邮件在不断到达。一个真正“活着”的 Agent，应该能边听边想、边说边想，能在你话说到一半时就开始规划，也能在没人吩咐时主动发现“这封邮件该处理了”。走向这种实时性有两条路，往往并行推进：一是架构上做快慢分离——实时与智能几乎是两条正交的轴，单一模型难以兼顾，于是让前台快模型维持对话节奏、后台慢模型负责深度思考；二是把推理本身做快——当 decode 速度足够高，按轮次的等待就短到近乎消失，turn-by-turn 与“实时”的界限也随之模糊。这条路正被芯片与推理引擎快速推进：小米 MiMo 已让一个 1T 参数模型在单个 8 卡节点上把生成速度推过 1000 token/s[^mimo]，而把整个模型直接固化进芯片的专用方案（如 Taalas HC1）更是把 80 亿参数模型推到约 17000 token/s、响应低于 100 毫秒[^taalas]。当模型每秒能吐出上千个字，“想完再说”和“边想边说”的体验差距就被抹平了。

第二朵乌云，是 Agent 如何像人一样，从与环境交互的成功与失败中持续积累经验。 今天的模型更像一个记性极好、却学不会新东西的天才：训练时把人类知识背得滚瓜烂熟，上岗后却几乎不再成长——每次任务结束，那些踩过的坑、试出来的窍门，大多随着上下文一起被丢掉。这究竟是不是一个真问题，取决于两种针锋相对的假设。

一种是**“小世界假设”**：一个足够大的模型——比如几万亿参数——本就装得下物理世界里几乎所有重要的通用知识，学一次就够。持这种看法的人（不乏 OpenAI、Anthropic 的研究者）会指出，AI 今天唯独在编程上最强，并不是因为代码对模型有什么特殊，而是因为编程是人类最开放的领域：海量开源代码摆在那里，可供学习；而绝大多数行业压根没有公开的信息与数据。于是前沿实验室真正在做的，是一家家去与各行各业合作，把各自的专业能力“蒸馏”进同一个大模型。按这种观点，瓶颈既不在模型的容量、也不在它学不学得会，而在数据够不够——把数据喂进去、训练一次，问题就解决了。

但**“大世界假设”**指向了单靠“训练一次”补不上的一层：属于某个具体用户、某家具体公司的知识。你所在公司的代码规范、你团队做 PPT 的口味、某个客户特有的脾气——它们不在任何训练语料里，而且时时在变；要贴合这个由无数具体情境拼成的“大世界”，模型只能在上岗之后持续学习，没法指望出厂时一次配齐。这正是第三章的记忆与第八章的持续进化在摸索的方向：把经验写成知识文档、指令或程序，还是经过筛选后用于更新模型参数？更进一步，“AI for AI”和“AI for Science”都在推动 Agent 走到没有现成答案的前沿；在那里，它只能从一次次实验的成败中自主学习，而不是事事回头问人。所以，模型最强的能力，终将不是记住，而是学习与适应。

这两朵乌云，都不是靠某一次模型升级就能凭空吹散的。要理解它们最终会怎样被跨越，得先看清一件事：模型和 Agent，从来不是上下游，而是一起往前走的。

模型与 Agent 的共同演进

回头看那些 harness 里层层叠叠的兜底逻辑——多级上下文压缩、失败数千次才熔断的重试、悲观地默认“不安全”的权限判断——每一段看似丑陋的“屎山”，记录的都是模型此刻还做不稳的地方。当下一代模型把这些约束内化，对应的代码就可以删掉；而模型之所以能内化，又正是因为 Agent 早已在真实业务里替它把这些坑趟了一遍，沉淀成了下一轮训练的信号。用户提出真实的难题，应用层用 harness 把模型暂时做不好的事补上，这些补救再反过来变成模型下一次迭代的训练信号——这是一条自我强化的飞轮，两朵乌云正是靠它一点点被推着散去。

这条飞轮，也回答了第一章悬下的那个问题：模型会不会最终吃掉 Harness？会，一层一层地吃。 模型每稳定内化一种能力，对应的 Harness 层就可以删掉——第九章的交互模型就是这样一个样本：打断、插话这些曾经要靠外挂 harness 才能拼出的行为，如今被直接做进了模型内部。但这个“吃”永远不会完结。一是训练以月计，模型等得起，业务等不起；二是模型无法内化真实业务中所有的约束与偏好，总有一层最新的边界需要外部逻辑兜底；三是每一代模型都会打开新的能力前沿，而前沿处恰恰是模型最做不稳的地方。所以 Harness 不会消失，它只是随着模型，不断向新的前沿迁移。这也正是《苦涩的教训》在 Agent 时代的读法：通用方法终将胜出，但“终将”二字里的每一段路，都是 Harness 铺出来的。

而飞轮转得最快的地方，是同时握住两端的人。Anthropic 用 Claude Code 做的，正是让自家模型和自家 harness 互相喂养、共同进化：模型知道 harness 会怎样调用它，harness 也清楚模型的边界在哪，两端的每一次改动都能立刻反馈给对方。曾有人做过一个实验，不换模型、只改 harness，任务准确率就从 52.8% 跳到 66.5%——这既说明 harness 今天的杠杆有多大，也提醒你：它之所以有这么大杠杆，恰恰是因为模型还没走到那一步。也正因如此，这条飞轮本身，就是这个时代最深的一条护城河：真实业务、反馈数据与模型迭代咬合得越紧，别人越难从外部追上。

这对你意味着什么，取决于你站在飞轮的哪一端。如果你在造模型，护城河就是把这条飞轮转起来——让真实场景的反馈尽快回流到训练里。如果你在模型之上造应用，harness 是你短期最锋利的技术杠杆，但要清醒：模型每内化一层约束，就会顺手抹平一批只靠 harness 建立的优势。应用层真正长久的护城河，往往在技术之外——独占的数据、稳固的渠道、用户的信任、网络效应，以及那些 AI 短期内接不住、必须由人与 Agent 协作才能完成的复杂场景。把 harness 用来争取时间，把这段时间用来构筑技术之外的壁垒，才是稳妥的打法。

所以，不必焦虑手里的框架会不会过时。模型每几个月迭代一次，具体的 API、产品和榜单都会翻篇，但“看到什么、能做什么、如何验证做得对不对”这三个问题不会过时——它们描述的不是某个模型的用法，而是一个智能系统与世界交互的基本方式。掌握了它们，无论下一代模型带来什么新能力，你都知道该把它放进公式的哪个位置，也能一眼看出，它离吹散那两朵乌云还有多远。

Agent 技术仍在飞速演进，一本书追不上所有变化。但如果这本书让你带走的不是某个 API 的具体用法，而是一套能在技术浪潮里保持清醒的判断力，那它就完成了使命。本书全部正文、配图与配套实验代码都是开源的，欢迎你去仓库里把实验亲手跑一遍、提 issue 和 PR——读懂和做出来之间，隔着一条只能靠双手跨过的河。而 Agent 最迷人的地方，正在于它能通过写代码创造新的能力，甚至改进自己；读到这里，你已经握住了“创造”的原则。接下来，去造点什么吧。

[^mimo]: 小米 MiMo-V2.5-Pro-UltraSpeed 通过 FP4 量化、DFlash 并行推测解码与 TileRT 推理系统的模型—系统协同设计，在单个通用 8-GPU 节点上首次把 1T 参数模型的生成速度推过 1000 token/s。见小米 MiMo 官方技术博客 “Pushing 1T-Parameter Model Generation Speed to 1000 TPS”, 2026. https://mimo.xiaomi.com/blog/mimo-tilert-1000tps

[^taalas]: Taalas HC1 将 Llama 3.1 8B 整个模型固化进 6nm 芯片，实现约 17000 token/s、响应低于 100 毫秒；代价是芯片只能运行被固化的那个模型，模型更新需重新流片。见 Karl Freund, “Taalas Launches Hardcore Chip With ‘Insane’ AI Inference Performance,” Forbes, 2026. https://www.forbes.com/sites/karlfreund/2026/02/19/taalas-launches-hardcore-chip-with-insane-ai-inference-performance/ 。

---

---

思考题参考答案

本文件汇总全书十章思考题的参考答案提纲。思考题多为开放性问题，答案不唯一。参考答案为 AI 生成，人工略作审校，仅供读者对照启发之用。建议读者使用 LLM 结合书稿内容进一步讨论这些问题。

第一章 AI Agent 入门

1. (★★) 如果你只能给一个 Agent 系统增加一项能力——更强的模型、更丰富的上下文、还是更多的工具——你会选哪个？在什么条件下你的选择会改变？

对应"大脑/眼睛/手脚"公式，先找短板：通常优先补上下文，即补充观察空间（observation space）。若任务超出模型推理能力，换更强模型。若动作空间不足（例如无法访问公司内部系统），加工具。判断依据是分析失败轨迹，定位瓶颈在感知、决策还是行动。

2. (★★★) ReAct 循环中，累计缓存读取量随轮数近似二次方增长。如何降低这种增长？

第 i 轮读取的缓存前缀长度约与 i 成正比，累计读取量为 1 + 2 + ... + n = O(n²)；这里二次增长的是累计缓存读取费用，而非轨迹长度或 KV Cache 占用。可在达到 token 阈值时批量压缩早期轨迹，只保留结论与关键状态，并把大块中间结果外置后按需检索，或用子 Agent 隔离。不能每轮压缩，否则既可能损害 Agent 性能，也会引入额外的压缩调用和缓存重建开销。

3. (★★) "模型即 Agent" 范式意味着模型在工具调用决策上越来越自主。但本章论证了 Harness 工程的重要性反而在增加。这两个趋势如何共存？Agent 框架未来的核心价值体现在哪些方面？

马与缰绳隐喻：模型越强、自主空间越大，出错影响面越大，越需约束、验证、纠正。框架价值从"编排 LLM 调用"转向 Harness 五要素中的保障层：权限分类、熔断器、错误恢复、上下文压缩、工具生态。

4. (★★) 消融实验中 "工具结果反馈" 的缺失导致 Agent 陷入无限循环。在生产环境中，除了工具结果缺失，还有哪些情况可能导致 Agent 无限循环？你会设计怎样的检测和终止机制？

其他诱因：工具反复报同一错误、幻觉调用不存在的工具、上下文被压缩丢失关键状态、思考过程被剥离导致模型 API 报错、任务本身无解。机制：设最大迭代次数等停止条件；检测重复调用（相同工具+参数指纹）；超过失败阈值升级人工干预。

5. (★) 本章用感知、行动、策略三个维度分析了五个 Agent 产品。请选择一个你日常使用的 AI 产品，用这三个维度进行分析，并思考它的架构设计是否合理。如果由你来设计这个 AI 产品，有哪些改进空间？

开放题。要点：仿照章中表格，写出眼睛（能看到什么信息源）、手脚（动作空间是否开放式、能否内部思考）、策略（Agent 执行循环的模式）。

6. (★★) 如果你要设计一个专门处理航班订票的客服系统，你会选择工作流模式还是自主 Agent 模式？有没有可能在同一个系统中混合使用两种模式？

主体用工作流：身份核实→搜索→付款→预订四节点，保证"付款前不能预订"等合规顺序，且把提示注入攻击面限制在单节点内。开放性环节（理解需求、改签、航班取消推荐替代方案）切换自主 Agent。高风险操作（大额付款、退款）加人工确认。

7. (★★★) 护栏部分提到了工具风险评级。如果一个工具在大多数情况下是低风险的，但在特定参数组合下变为高风险（如 delete_file 删除普通文件 vs 删除系统文件），你会如何设计动态风险评估？

评级对象从"工具"细化到"工具+参数"：按可逆性、权限、影响面在调用时计算风险。用基于规则的确定性检查（路径黑白名单、正则）而非模型判断。验证应只看结构化数据，防提示注入操纵。

8. (★★) 本章的 Agent 产品表格中，所有 Agent 的动作空间都是 "开放式" 的。一个受限的动作空间（比如只能从预定义选项中选择）在什么场景下反而优于开放式？

高合规、高风险、错误不可逆场景：如退款、付款，受限选项即"约束"，天然防呆，从设计上让错误无法发生。

9. (★★) 人工干预机制要求 Agent 能 "优雅地移交控制"。但在实践中，用户可能不在线、响应很慢、或者给出模糊的指令。此时 Agent 应该怎么办？

Fail-safe：高风险操作在无确认时暂停而非默认执行；先做可逆的低风险部分，文档记录高风险部分，便于人类决策、Agent 恢复；用异步沟通工具（消息、邮件）通知并设超时策略；指令模糊时用意图澄清。

10. (★★★) 引言指出 "好的设计原则应该穿越模型的迭代周期"，但实现这些原则的具体工程手段可能会随模型能力进步而过时。试举一个这样的 Agent 工程手段，并说明理由。

示例一：通过约束采样强制工具调用符合严格格式。这是在模型容易输出非法 JSON、遗漏参数时采用的可靠性补丁；随着模型的格式遵循能力提高，其收益可能逐渐降低，但高风险场景仍应保留确定性的格式校验。

示例二：为弥补模型无法持续吸收新知识而引入外部知识库。如果模型未来具备可靠的持续学习能力，一部分知识维护可能从模型外部迁移到参数中。不过，外部知识库在实时更新、精确检索、权限控制和来源追溯方面仍有独立价值，因此更可能缩小适用范围，而非完全消失。

示例三：要求所有能力都必须通过模型 API 的标准工具调用接口暴露，禁止自定义调用形式。Skills 已经展示了另一条路径：用文本描述能力及操作方法，再让模型通过通用命令行工具执行；从模型视角看，这相当于在通用执行器之上理解并遵循一种自定义的文本调用协议。随着模型理解任意接口的能力增强，“必须使用标准工具调用格式”不再适合作为普遍原则。标准格式对于互操作、结构化校验以及能力较弱的模型仍然有用，但它应是基于场景的工程选择。

示例四：要求提示词与全部工具定义必须预先放在上下文开头。这种做法源于早期模型的指令遵循能力有限，提示或工具定义离开熟悉的固定位置后，模型往往难以正确识别和执行。Skills 会在运行过程中按需把提示词加载到上下文中间；动态工具发现也会在找到新工具后，把工具定义追加到已有轨迹之后。随着模型的指令遵循能力增强，以及针对这类动态加载方式进行专门的后训练，提示词和工具定义不再必须固定在上下文开头。

第二章 上下文工程

1. (★★★) 实验 2-3 发现，滑动窗口对话历史会导致 Agent 反复执行相同的工具调用。但完整保留历史又会让上下文不断膨胀。设计一种策略，既能避免信息丢失，又能控制上下文长度，且不破坏 KV Cache 前缀。

①用压缩代替丢弃：消息只追加不删改，接近阈值（如窗口 80%）时批量压缩旧 tool results。②分层机制：大输出落盘留摘要、噪声直删、归档式摘要保留脉络。③子 Agent 隔离，让中间状态不进主上下文。

2. (★★) Qwen3 的 Chat Template 思维链保留机制只保留 "最后一个真实用户消息之后" 的思考。如果一个 ReAct 循环跨越了上百轮工具调用，累积的思考内容可能消耗大量上下文。你会如何修改这个机制来应对超长循环？DeepSeek R1 曾要求剥离全部历史思考，而 DeepSeek V4 反转为强制回传全部 reasoning_content——对比这两种相反的策略，各有什么利弊？这个反转说明了什么？

修改方向：滑窗保留——完整保留最近若干轮思考，窗口外按 token 预算（而非固定轮数）触发滚动压缩，产出结构化状态栏（当前目标、已确认事实、已排除路径、待办），压缩只发生一次且位置固定，缓存重建代价是一次性而非每轮付出。R1 剥离：省 token、前缀稳定缓存友好，且与训练分布一致（历史 CoT 从不在输入中）；但每轮从零推理，长程计划丢失、易重复犯错。V4 强制回传：思路连贯、长程 agent 任务表现更好；但 token 成本高、每轮前缀膨胀，且无法从非 think 模式无缝切换。反转说明：对纯对话场景思考是废料，对 agentic 场景思考是状态——行业实践已倒向后者。

3. (★★) 上下文感知压缩实验中，从约 148K 个字符压缩到约 2,000 个字符，这种极端的压缩是否存在"不可逆信息损失"的风险？如何解决？

有风险，压缩是有损投影，问题落到未保留的维度就坏了。解法："有损压缩＋无损索引"，每条事实带来源 URL 可回溯；原始输出存磁盘、只看摘要预览；显式保留优先级——架构决策、语义完整性（时间、公司名）、验证状态、UUID/hash 等标识符原样保留；自适应窗口化推迟压缩时机。

4. (★★) Agent 状态栏将隐式状态显式化。但如果状态栏本身包含了错误信息（比如工具计数器出了 bug），Agent 可能基于错误的信息做出有害的决策。这种"元信息可靠性"问题如何缓解？

模型几乎无条件相信状态栏，错误会原样传导。缓解：①用确定性代码维护，绝不让 LLM 批量统计长历史（要用也逐条抽取、代码汇总）；②把状态栏准确率当一线生产指标盯；③信息只来自对真实世界的可靠观测，防状态栏投毒。

5. (★★) 提示工程消融实验表明，信息组织的混乱导致成功率下降 30% 以上。但在实际开发中，系统提示词往往由多人在不同时间维护。你会用什么工程实践来防止系统提示词的 "熵增"？

①把提示词当代码：版本控制、评审，产品经理定业务规则、工程师负责编码；②用 Tau-Bench 类基准测试做回归测试，改动前后跑消融实验定位影响；③强制结构化：SOP 流程驱动而非规则堆砌，XML/Markdown 分层；④片段按"可缓存/破坏缓存"分类命名，动态内容归到缓存边界后；⑤膨胀内容拆成 Skills 按需加载。

6. (★★★) 本章提出"上下文学习本质上是检索而非推理"。如果这个论断成立，当前所有基于"把更多信息塞进上下文"的优化方向都需要重新审视。你认为应该如何突破这一局限？

给"只有一半的检索引擎"补提炼层：①上下文蒸馏/状态栏，用代码提前算好结论供直接检索；②主动压缩，把原始记录换成高密度结构化知识；③子 Agent 隔离，噪声不进主上下文；④交互作为第三轴，外部仪器观测写回模型想不出的新信息；⑤前沿方向：可编辑、可组合的 KV Cache"笔记"，及跨会话记忆沉淀。

7. (★★★) Skills 的渐进式披露只在 Agent 判断需要时才加载完整内容。但这个判断本身依赖模型的能力——如果模型不知道自己不知道什么，就无法正确触发 Skill 的加载。这个"元认知"问题如何解决？

①Skill 的元数据（名字、描述）常驻上下文，让模型始终"知道自己拥有什么"；②Skill 的 description 写成路由条件而非功能介绍："Use when / Don't use when"，避免宽泛描述。

8. (★★) Skills 机制中，Agent 从 SKILL 文件中动态读取提示词之后，后续的操作能否正确遵从这些指令？不同的模型对 Skills 模式的支持有什么区别？

取决于 Skill 的注入方式：注入 system prompt 遵循最强但破坏 KV Cache；作为普通文件读到上下文中间，模型的指令遵循可能较差；注入到上下文末尾，指令遵循较好，但每次工具调用都需要重新计算 skill 部分的 KV，成本较高。

9. (★★★) 本章强调动态信息（如系统时间戳、工具列表顺序）的变化会破坏 KV Cache 前缀命中。在一个拥有大量工具且工具集频繁变动的生产系统中，你会如何设计上下文布局来最大化缓存命中率？

①少量稳定核心工具（如七个）＋通用执行器，具体能力走 Skills 渐进披露，工具定义冻结在静态前缀、固定顺序；②子 Agent 与父 Agent 前缀保持相同。

第三章 用户记忆和知识库

1. (★★) 在用户记忆系统中，当同一用户在不同会话中提供了矛盾信息（比如两次提到不同的家庭住址），记忆系统应该如何处理这种冲突？

用 Mem0 式"提取—对比—决策"流水线：先向量检索出相近旧记忆，再由 LLM 判定 ADD/UPDATE/DELETE/NOOP，如"搬到上海"应 UPDATE 覆盖"住在北京"；版本化：地址类信息只保留最新版并标记时间戳，工作经历类保留完整历史；检索侧可借上下文前缀（人物、时间、意图，如电汇三次修改案例）判断哪条最终有效。

2. (★★) 上下文感知检索将原始文档的上下文附加到每个分块。但如果原始文档本身结构混乱或存在矛盾信息，这种方法可能传播甚至放大错误。你会如何在检索阶段引入 "信息质量" 信号？

借鉴"知识库时效与治理"：给分块附加版本号、生效/失效时间、来源等元数据，检索时过滤已失效内容，或在前缀中显式标注"此条已于某日废止"；重排序阶段把来源权威性、时间新鲜度纳入打分，而非只看语义相关性；索引期让生成前缀的 LLM 顺带检测块间矛盾并标记，类似记忆的版本化冲突检测。

3. (★★★) 智能体化 RAG 让 Agent 主动决定何时搜索、搜索什么、以及是否需要继续搜索。但如果模型不知道自己不知道什么，就无法正确触发搜索。这个 "元认知" 问题如何解决？

①在 prompt/skills 中把"评估信息是否充分"固化为显式步骤：如实验 3-9 中先并行检索子问题，发现缺"前科如何影响过失罪量刑"这一关联，再二次检索；②让轻量元信息常驻上下文提供全局视野：例如 JSON Cards 概览、OpenViking 的 L0/L1 摘要，使 Agent 知道"库里有什么"。

4. (★★) 多模态信息提取将图表转为文本描述后再进行检索。这个 "翻译" 过程可能丢失视觉信息中的空间关系。举一个具体例子，说明纯文本描述无法完整传达的图表信息，并设计一种保留该信息的方案。

例：系统架构图中的逻辑关系，折线图中两条曲线的交叉点位置，或 PDF 表格中单元格与表头的行列对应。方案一：原生多模态处理；方案二：提供多模态图片分析工具。

5. (★★★) Rich Sutton 的 "苦涩的教训" 认为通用方法（搜索和学习）最终会胜过手工设计的特征。本章构建的整个知识系统（分块策略、索引结构、检索管道）是否本身就是一种 "手工设计"？如果模型能力足够强，这些设计是否会被简单的 "全量输入" 所替代？

确实是手工设计，部分环节（分块、融合调参）可能随长上下文而弱化；但黑猫白猫案例表明"全量输入"也不够：注意力是软检索，跨文档聚合统计仍需索引期预提炼；知识过期更新、权限/租户隔离、可审查性、成本这些工程约束与模型能力无关；且检索与索引期 LLM 提炼本身就是"搜索+学习"的通用方法，并非与苦涩教训对立。

6. (★★★) 随着模型能力的提升，你认为领域知识库还重要吗？未来强大的基座模型是否有可能包含领域知识库中所有的信息，从而不再需要领域知识库？

仍重要：训练数据有截止日期，知识库可随时更新；企业内部流程、私有判例等根本不在公开语料中；多用户共享需权限过滤与租户隔离，参数中的知识无法按调用者裁剪；外部存储可审查、可版本控制、可下线失效内容，参数记忆难以做到；即使走参数化路线（后训练 / User as Engram），也面临"记住容易，能用来做多跳推理难"的难题。

7. (★) RAPTOR 通过自底向上的层次摘要构建树形索引，GraphRAG 通过实体关系构建图结构索引。这两种结构化索引分别擅长回答什么类型的查询？

RAPTOR：从宏观概念逐步钻取细节的"跨层穿梭"式查询，如先定位"SIMD 指令集"摘要再下钻到 SSE 细节，兼顾总览与细节两种粒度。GraphRAG：多跳关系推理（"我的医生所在医院的地址"沿关系链遍历）与实体消歧（两个"张医生"是不同节点）等"A 和 B 有什么关系"类查询，社区摘要还提供主题聚类。

8. (★★) 文件系统范式将知识组织为类似文件系统的层次结构。这种方式和传统的向量数据库 RAG 相比，在什么场景下更有优势？

纯文本可被用户直接阅读、编辑、修正，可用 Git 版本控制与回滚，适合需要人机共同维护、审查知识的场景；Agent 有 write_file 能力即可自主记录经验，形成记忆自进化循环（外部化学习）；L0/L1/L2 渐进披露使多数查询到 L1 即可决策，省 token；前提是像 Wikipedia 一样建立交叉链接和索引页，否则孤立文件越多越难检索。

9. (★★★) 从结构化数据（如司法判决数据库）中自动发现 "裁判因素" 和 "因素重要性层级"，本质上是让 Agent 从数据中归纳规则。这种数据驱动的知识提取是否能达到人类专家手工编写规则的质量？

优势：如 CAIL2018 实验，"自下而上"因子发现更贴合数据而非人类先验，能捕捉散落在成千上万判例中、专家难以显式写出的隐性权衡经验，且可量化。局限：LLM 提取出错会造成知识污染，数据本身的偏差会被继承，聚类原型只反映相关性、说不清因果。折中：数据驱动建模＋专家审核 Schema 与结果，模型驱动提问、统计支撑解释。

第四章 工具

1. (★★) MCP 标准将工具定义从 Agent 框架中解耦了出来。但标准化也意味着复杂的工具交互模式（如流式输出、双向通信、有状态会话）可能难以在标准协议中表达。你认为 MCP 未来最需要扩展的能力是什么？

最需要扩展的是跨会话的事件驱动能力。MCP 已经能够支持多轮交互、变化订阅和长任务，但它的核心仍是标准化一次能力调用，而不是让 Agent 持续在线。新邮件、外部回调等事件如何唤醒 Agent，多个事件如何排队、恢复和重试，仍需要 Agent 框架自行处理。未来如果能在不破坏工具协议简洁性的前提下，为这类事件编排提供更统一的约定，MCP 的适用范围会进一步扩大。

2. (★★) 在异步 Agent 架构中，事件队列的优先级策略需要在设计时确定。但如果优先级判断本身需要语义理解（比如判断一条新消息是否比当前任务更紧急），这个判断应该由谁来做——规则引擎还是另一个 LLM 调用？各有什么代价？

分层混合：事件类型明确的用规则硬编码，零延迟、确定性强，但无法理解"马上停下来"与"今天天气怎样"的语义差异；语义模糊的交给轻量分类 LLM 做事件路由器，代价是数百毫秒延迟、额外费用、可能误判，且需像 Sidecar 一样只读结构化字段防提示注入。

3. (★★) 在 MCP 生态中，不同的 MCP 服务器可能提供功能高度重叠的工具。当 Agent 面对多个来源不同但功能相似的工具时，应该如何选择？如果不同来源的同名工具在行为上略有差异（比如一个返回摘要，另一个返回全文），Agent 是否有能力感知并利用这种差异？

选择依据：接入前审查描述、锁定版本、配最小权限凭证，警惕同名工具遮蔽（tool shadowing）把敏感调用路由给恶意方；运行时靠层次化分类和动态发现缩小候选。模型是否能感知差异，取决于工具描述的质量。

4. (★★★) Agent 代表用户与外部世界交互时，本质上面临一个身份选择：是用独立的虚拟身份（专属邮箱和电话号码）以第三方身份行动，还是直接以用户本人的身份操作其个人账号？前者可以在后台自主操作，但第三方可能不信任一个非真人的身份；后者拥有更完整的上下文和权限，但引入了信任授权和安全边界的问题。你认为在什么场景下应该选择哪种模式？

默认虚拟身份：后台自主操作、可审计，出错或被攻破时不暴露用户全部数字身份，就像秘书用自己的办公邮箱；需应对 CAPTCHA/IP 信誉问题（住宅代理）。必须以本人身份的场景（账户身份验证、三方通话确认，如 Pine 打客服电话）用 Human-in-the-loop 认证：VNC/RDP 让用户可视化亲自登录。判断标准：对方是否要求账户持有人本人、操作风险与凭证范围。

5. (★★) 在队列式事件处理中，模型倾向于只关注最后一个事件，本章通过 Agent 状态栏标记和汇总来缓解。但如果队列中积压了 20 个事件（10 个工具结果 + 5 条用户消息 + 5 个系统提醒），你会如何组织这些事件的呈现顺序和格式，使模型不遗漏关键信息？

先用规则和轻量 LLM 分类去重：紧急事件（告警、用户中断）单独走取消式处理，不混入批量。10 个超长的工具结果，截断持久化到文件，只留头尾与路径。上下文末尾的系统状态栏加汇总清单（各类事件数量+要求逐条回应）。

6. (★★) 本章提出了"执行-验证-反馈"闭环（如写代码后自动运行 linter）。这种"操作后立即自动验证"的模式还可以应用到哪些工具场景？是否存在某些操作，其验证本身的成本或风险超过了操作本身，导致这种模式不可行？

可泛化的场景：改配置后沙盒实际运行，验证生效；生成文档/演示文稿后渲染成截图，利用模型多模态能力检查排版。不可行的：发邮件、拨电话、对外转账等不可逆不可幂等操作：要么无从观察，要么本身再触发一次真实世界事件；此时应改用事前手段：提议者-审核者事前审批。

7. (★★) 本章提出了"工具爆炸"问题——Agent 面对数千个工具时选择精度下降。除了主动工具发现，还有哪些方案？可以参考人类专家在面对大量可用工具时的策略。

①层次化分组：先定位"服务器/App"再选具体工具；②Skills 式"按需查阅"：像查工具书，目录常驻上下文、细节按需加载；③少数常用基础工具"放在手边"常驻上下文，其余靠目录索引。

第五章 Coding Agent 与代码生成

1. (★★) 代码生成被称为 Agent 的"元能力"。但代码执行引入了安全风险——Agent 生成的代码可能包含漏洞、无限循环或资源耗尽。沙盒隔离能解决部分问题，但也限制了代码能力（比如无法访问网络或文件系统）。如何在安全性和能力之间找到最优平衡点？

沙盒按场景分级隔离（容器/microVM）；网络默认断网、白名单代理按需放行；源码只读挂载、API key 不要放在沙盒内；沙盒资源限额；沙盒生命周期管理（超时）。

2. (★★★) Agent 自举——能创造 Agent 的 Agent——实现了"智能的自我繁殖"。但每次自举都可能引入新的偏差或错误，这种错误会在代际间累积吗？如何防止 Agent 自举的退化？

若每代在上代产物上继续繁殖，一些缺陷可能会累积。关键是要有足够挑战的 verifiable task（可验证任务），例如足够困难的编程任务。

3. (★★) 代码生成 Agent 在处理日志解析时，能自动跟随格式演化。但如果格式变化是一个 bug 而非预期改动，Agent 的适应性反而掩盖了问题。Agent 应该如何区分"需要适应的变化"和"需要报告的异常"？

适应前先诊断：对照架构文档与 PRD 判断新格式是否符合预期（实验 5-8 的思路）；核对版本控制记录，确认变化对应合法代码提交还是无来源漂移；类比 τ-bench 的 log_mismatch，即使选择适应也记录告警、自动建 issue 而非静默兼容；不确定时走人在回路确认。原则：适应与报告并行，适应不吞掉异常信号。

4. (★★) 本章在 PPT 生成、视频编辑和日志可视化中反复使用提议者-审核者机制。如果 Reviewer 的审美偏好与目标用户不一致，比如 Reviewer 认为信息密度合理但用户觉得太拥挤，反馈循环会收敛到错误的局部最优。如何让用户的偏好反馈也参与 Reviewer 循环？

把用户反馈作为最高优先级的结构化事件注入 Agent 轨迹；将用户偏好外部化沉淀，写入 MEMORY.md，使偏好跨任务生效；交付 HTML 格式文档而非 Markdown 以便用户查验。

5. (★★) 本章展示了 Coding Agent 把执行和调试中获得的经验沉淀回代码库的多种方式——写入知识库文件、更新架构文档、维护项目指令文件、把操作序列固化为代码。如果把这些经验进一步提炼为系统提示词中的规则，规则集会随时间不断膨胀。如何对沉淀下来的规则做"垃圾回收"——识别并清理冗余或过时的条目？为什么一次成功的代码修改还不能直接视为第八章所说的持续进化？

GC 思路：能编码进 Linter、CI 或工具校验的规则移出提示词；追踪规则命中率和冲突，定期对照代码库重新验证；用 Markdown 与 Git 保留来源、版本和回滚能力。一次补丁成功只说明它解决了当前案例；持续进化还要求修改来自可追溯的运行证据，能改善后续任务，并通过旧任务回归与安全验证。

6. (★) "对远程工作友好的团队往往也对 AI Agent 友好。"你所在的团队或组织，在知识文档化方面距离"AI-ready"还有多远？最大的障碍是什么？

开放题。可用本章代理指标自查：远程新人只靠仓库和文档能否独立开展工作。检查项：决策是否记录在文档、上下文是否写进 issue/PR、构建测试命令是否有 CLAUDE.md/AGENTS.md 类指令文件、部落知识是否沉淀为开发者指南。常见最大障碍：依赖"问旁边同事"的口头传递与白板文化——Agent 读不到口头约定，只读得到文档。

7. (★★★) Simon Willison 提出了 Agent 的"致命三要素"（访问私有数据、暴露于不受信任内容、具备外部通信能力），本章在此基础上增加了第四个——持久记忆。在一个需要同时处理这四种要素的生产环境中，你会如何设计安全策略？

按四类边界分层设防。数据边界：凭证不挂载、源码只读，最小可见。输入信任边界：来源标注、外部内容降格为"可参考、无指令效力"的数据（忠诚度守则）。输出影响边界：默认断网加白名单出口、命令语义解析而非黑名单、Sidecar 独立复核加人在回路——关键操作必须由上下文之外的机制复核。跨会话边界：写入 MEMORY.md 需经与外部内容同等的信任审查。目标是被注入也执行不出去。

8. (★★) Artifact 模式让 Agent 生成的 SQL 或前端代码直接在用户浏览器或数据库中执行。但生成的 SQL 可能执行破坏性操作，生成的 HTML 可能包含漏洞。如何确保系统的安全性？

SQL：查询用最小权限只读账号执行，并添加 CPU、内存等资源限制，防止资源耗尽。HTML/UI：优先 A2UI 类声明式协议，Agent 只输出界面描述 JSON，客户端用受信组件目录渲染，不执行任意代码。如果要任意 HTML，则须在沙盒环境中展示，防止注入。

9. (★★) 将业务规则编码为工具内部基于数据库真值的校验，并用参数设计引导模型在调用前核对政策条件，本质上是用代码结构来约束 Agent 行为。这种"代码即规则"的模式相比自然语言规则有什么优势和局限？

优势：无歧义、确定性、擅长复杂条件组合；政策事实取自数据库真值和服务端时钟，不采信模型自报值，幻觉和提示注入都绕不过，是防不可逆操作的最后守门员；expected_* 参数兼作强制 checklist 引导思考。局限：代码不会向用户解释政策、不会找变通方案，且有维护成本。结论：与自然语言规则互补而非替代。

10. (★★) Artifact 模式让 Agent 生成 SQL 或可视化代码，由前端直接执行，绕过 LLM 处理大量数据。这种"Agent 生成代码，系统执行代码"的分工模式，与传统的"Agent 直接给出答案"的模式相比，有什么优劣？

优：数据从数据库直达前端，绕过 LLM"中间人"——快、省 token、避免抄写大量数据时的幻觉错误，适合大数据量呈现；代码可审计、可复用，还能组成流水线（SQL 结果直接喂给可视化代码）。劣：LLM 看不到查询结果，无法基于数据内容做进一步归纳和决策，不适合需模型消化数据再推理的任务。

第六章 Agent 的评估

1. (★★) LLM-as-a-Judge 使用语言模型评估语言模型的输出。这种 "自我评估" 是否存在系统性盲区——比如模型可能一致地给某种风格的回答打高分，而这种偏好与人类评判不一致？如何检测和校正这种偏差？

存在：长度偏差、回答风格偏差、同源模型被钻空子（古德哈特定律）。检测：建 100-200 例人工金标集，测评判与人类的 Cohen's kappa；定期审计评分与回答长度的相关性；红队构造对抗案例。校正：Rubric 显式惩罚冗长、限长度；不同模型家族多源异构评判。

2. (★★★) 评估数据集的 "防泄漏" 设计至关重要。但在开源生态中，benchmark 数据一旦公开，很快就会被纳入训练数据。这场 "猫鼠游戏" 有终局吗？设计一种从根本上抵抗数据泄漏的评估方法。

静态题库无终局，只能追赶。根本出路是公开"生成机制"、私有化"具体实例"：像 τ²-bench、AndroidWorld 那样参数化模板每次随机实例化，验证基于最终环境状态而非固定答案序列。

3. (★★) Scale AI 的四准则（基于专家指导、全面覆盖、标准重要性权重、自包含评估）旨在消除评估的主观性。但某些任务维度（如 "回答是否有帮助""语气是否恰当"）天然具有主观性。如何为这些主观维度设计可靠的 Rubric？

把抽象标准翻译成可验证行为。每档配具体示例和边界案例；Rubric 是迭代产物——试用中收集评价者分歧，逐渐演化为判例集。再辅以多评委加权/一致性检查、分歧案例送人工复核，并在金标集上校准一致率。

4. (★★) τ-bench 通过模拟真实用户行为来评估 Agent。但模拟用户本身也是一个 LLM——它可能系统性地低估某些边缘场景（如情绪激动、表达不清的用户）。如何验证模拟用户本身的质量？

τ-bench 初版教训：模拟器过于机械、指令过简（Agent 能猜对答案）。验证手段：人工抽检模拟对话，检查是否遵守渐进式透露、不编造脚本外信息；用小样本真实用户测试，看与模拟评估的排名是否一致。

5. (★★) 配对比较（Bradley-Terry 模型）假设偏好是传递的（如果 A > B 且 B > C，则 A > C）。但人类偏好经常违反传递性。在 Agent 评估中，非传递偏好可能出现在哪些场景？这如何影响排名的可靠性？

场景：多维权衡时（A 准确但慢、B 快但简略、C 详尽但贵），不同评判者/任务看重的维度不同。Chatbot Arena 的排名本就依赖用户提问分布。影响：BT 把实力压成单一分数，非传递时排名不稳定、随对局分布漂移。缓解：按能力维度分别排名、报告两两胜率矩阵。

6. (★★) 本章提出 "观察→假设→实验→验证" 的科学方法。但在实践中，Agent 的行为空间巨大，验证一个假设可能需要数百次评估运行。如何在有限计算预算下最大化评估的信息量？

先用失败聚类把范围缩到最有信息量的任务，再做低成本、单变量的配对试验，把小样本当作扩大测试的门槛，而不是部署证据。统计上，先用标准误做保守筛子；同批任务用 McNemar 一类的配对分析；预期分差小于噪声带宽时应扩充评估集。若并行筛选多个方案，还要校正多重比较，并对正向结果做独立复跑。

7. (★) AndroidWorld 小实验中，完整元素树把成功率从 25% 提高到 100%，却把 token 用量推到 2.498 倍；精简后成功率不变，token 降到对照组的 0.506 倍。怎样设计一套自动裁剪规则，既删掉无语义的 UI 节点，又不误删对可访问性、状态验证或后续操作有用的信息？

可采用“默认删除、证据保留”的分层规则：保留可见、有文本、可操作、可聚焦、可滚动、带状态值或无障碍标签的节点，同时保留这些节点到根的最短祖先链和必要的相邻标签；删除没有语义的布局容器，并对重复子树做摘要。裁剪前后要校验可操作元素 ID、状态和值是否守恒，还应保留截图作为视觉兜底。规则先在失败轨迹上回放，再用未参与调参的应用做回归；成功率、token 和延迟都作为护栏，任何可访问性任务退化都应阻止发布。

8. (★★) τ-bench 的用户模拟采用了 "渐进式信息透露"——不一次性提供所有信息，而是根据 Agent 的提问逐步透露。这种设计如何影响评估结果？如果模拟用户的信息透露策略与真实用户差异较大，评估结论还可靠吗？

影响：若透露策略失真，Agent 可能只是学会了"适配模拟器"（古德哈特），绝对分数不具备参考价值；模型之间的相对排序可能仍有参考价值。补救：用真实对话校准模拟器、人工抽检、明示结论适用边界。

第七章 模型后训练

1. (★★) 灾难性遗忘——一次针对特定任务的微调破坏了模型原有的通用能力（如通用工具调用）——在 Agent 场景下尤其棘手。相比全参微调，LoRA 冻结基座权重、遗忘风险更低，但并非免疫。有哪些策略可以进一步缓解微调带来的能力遗忘？

数据配比：混入约 20% 通用/原分布数据，防新任务占比过高压垮旧能力；训练量克制：SFT 到"格式稳定、能力初具"即止，早停防塌缩；RL 用小 rank（8–32）并保留 KL 惩罚，把策略摁在参考模型附近；冻结关键组件（如 VLM 只训投影层）；按任务挂多个 LoRA adapter 隔离能力；用通用基准做回归测试。

2. (★★) 后训练将能力固化为模型权重（"肌肉记忆"），而上下文学习将知识放在推理时的输入中。但有些能力（如领域知识）既可以通过后训练学习，也可以通过 few-shot 示例提供。你会用什么标准来决定某项能力应该走哪条路径？

首先看能力能否被外部符号充分表达：事实与证据适合 RAG，可语言化原则适合 Prompt/Skill，确定性流程与硬约束适合程序；医疗影像理解、自然语气和隐式策略等高维能力即使领域仍在变化，也往往需要参数更新。再看更新成本、调用规模、时效和风险：探索期先用上下文快速验证，稳定有效且需要广泛泛化时再训练；硬性规则无论多稳定都不应只依赖参数记忆。

3. (★★) 模型蒸馏让小模型学习大模型的行为。按能力层次，被蒸馏的模型大致可分为三级——Chat 模型（单轮对话、直接作答）、Reasoning 模型（带长链思考再作答）、Agentic 模型（多轮调用工具、与环境交互）。分别蒸馏这三类模型，难点有什么不同？

Chat：只学"输入→输出"映射与风格，标准 SFT 即可，最简单。Reasoning：要完整思考轨迹，需基于开源教师模型；须过滤答案错误的轨迹。Agentic：需要真实仿真环境；离线学习容易出现 learner-sampler mismatch，建议基于开源教师模型做 On-Policy Distillation。

4. (★★★) 在多轮 Agent 交互中，奖励的归因（credit assignment）问题比单轮更严重——一个最终的成功或失败很难归因到第 3 轮还是第 7 轮的决策。你会如何设计奖励分配策略？

中间步骤可判定时加过程奖励（V-IRL 每步 ±1）；仿 RLVP 用确定性规则逐动作给路径信号，补回全败/全胜组的组内方差。

5. (★★★) 如果你有固定预算（比如 $10,000），要提升一个客服 Agent 的性能，你会如何在上下文与知识、Prompt/Skills、程序约束和参数训练之间分配预算？你的决策取决于哪些因素？

先预留预算建立评估集和轨迹验证器，否则其余投入无法比较。产品事实和政策放入可追溯的知识库；少量可语言化的服务原则先用 Prompt/Skills 快速验证；退款权限、隐私和承诺—行动一致性用程序兜底；只有自然语气、复杂意图理解等难以写成规则且调用规模足够大的能力才投入参数训练。具体比例取决于瓶颈、风险、更新频率、调用量和现有模型能力。

6. (★★★) 在没有明确奖励函数、样本稀少的情况下，自主实现模型学习，被一些人认为是后训练的终极目标。当前的 RL 训练方法距离这个目标还有多远？你认为下一个突破最可能来自哪个方向？

差距：如 Silver 与 Sutton 所指，当前 RL 只能从最终成败学习，客服说"需要信用卡后四位"这类丰富反馈全被浪费，需数百次盲目试错；样本效率和可验证奖励是主要瓶颈。可能的突破：生成式奖励模型自主定原则、从一次失败学到方向；以及建模环境的 world model 路线。

7. (★★) 本章指出 LoRA 微调的成本并不高。那么，是否有可能给每个用户（或每个客户公司）训练一个专属的 LoRA，将用户记忆或企业知识写入参数，而非像第三章那样存储在外部知识库中？在什么场景下，"记忆写入参数" 比 "记忆存入知识库" 更有优势？又在什么场景下会适得其反？

LoRA 难以准确记忆大量事实（须继续预训练，成本剧增），即使记住了，模型也很难用这些事实做多跳推理，因此用 LoRA 记忆事实不是很好的技术路线。此外，事实频繁变更、需可追溯审计时 RAG 更优。

8. (★★★) On-Policy Distillation 依赖更强的教师模型来监督学生。但 OpenAI 的 Weak-to-Strong Generalization 研究提出了一个反直觉的发现：弱模型的监督信号有时能激发强模型本身潜在但未被激活的能力。如果将这一思路应用到 Agent 训练，是否可能实现 "小模型教大模型" 的逆向蒸馏？

可能，关键是"验证比生成容易"：弱模型不当示范者（SFT 上限即示范者水平），而当验证器/奖励模型，由强模型自己探索、弱模型只负责判断。

9. (★★) 过程奖励模型（PRM）评估每个思考步骤，而结果奖励模型（ORM）只看最终结果。但"正确的过程导致错误结果"和"错误的过程侥幸得到正确结果"哪个更值得奖励？在 Agent 的多步工具调用场景中，你会如何权衡？

侥幸成功更危险：违规抄近路往往抬高表面成功率（改测试文件、跳过验证），是 reward hacking 温床。按 RLVP"奖励结果、惩罚路径"：错误的动作（工具调用）容易验证，逐动作扣分；中间步骤易判定正确与否时，可给过程奖励。但过程约束勿过密——"推切"式更优策略正是结果奖励的探索自由发现的。

10. (★★★) 本章讨论的评估数据集（如 SWE-Bench Verified、τ²-bench、AndroidWorld）既可以用于评估也可以用于后训练。但如果将评估集用于训练，它就不再是独立的评估集——这是否违反了训练集与测试集必须分离的基本原则？τ²-bench 的动态参数生成和 AndroidWorld 的参数化模板在一定程度上缓解了这个问题，但模板结构本身仍然是固定的。如何在充分利用评估数据的训练价值与维护评估独立性之间找到平衡？

复用环境，不复用题目。动态参数只防"背答案"，防不了模板过拟合，因此应留出整批未见模板/域外场景做评估（类比 V-IRL 训练纽约、测试九个陌生城市）。用参数化模板批量生成训练变体支撑课程学习，并以 OOD 成绩作为真正的泛化指标。

11. (★★★) 本章提出 "先形后神" 的训练范式：SFT 到 "格式稳定、能力初具" 即止，然后切换到 RL。但实践中，如何判断 SFT 已经 "足够" 而应该切换？

格式信号：工具调用输出可稳定解析、执行，工具执行失败率降到可让奖励可靠计算的水平。收益信号：再增加示范数据，OOD 的新场景表现仍不上去——说明瓶颈已在 SFT 的记忆目标本身，到了临界点。过拟合信号：验证集性能开始恶化就应停——V-IRL 实验表明 SFT 过度训练塌缩到训练分布后，RL 也无法恢复 OOD 性能。

12. (★★★) ReTool 的训练动态显示（见实验 7-14），少数超长响应会显著拖长整个训练周期——一批 rollout 里绝大多数已经生成完毕，却要等那几条最长的响应收尾，其间集群的 GPU 利用率很低。如何提升这种长尾响应场景下训练集群的资源利用率？

infra 层：解耦 rollout 与训练集群，异步流水；空闲 GPU 用连续批处理填入新请求。从源头压长尾：DAPO 的 Overlong Reward Shaping 软惩罚超长响应。

13. (★★★) 用 LLM 模拟环境（如模拟搜索引擎、模拟用户）训练 Agent 时，Agent 钻空子的对象从 “真实环境的规则” 变成了 “模拟器本身的偏见与漏洞”。这类训练中可能出现哪些具体的 reward hacking 行为？又该如何防范？

典型行为：对 “模拟用户” 过度承诺、堆砌道歉与讨好话术——模拟用户容易被安抚，不会像真实用户那样追究承诺是否兑现；编造模拟器不会去核实的事实；对 “模拟搜索引擎” 构造诱导性 query，利用其偏好返回含答案文档的倾向走捷径，而不是学会真正的检索；若奖励来自模拟器或 LLM 评判者的打分，则输出冗长、模板化、“看起来专业” 的回复刷分；更隐蔽的一种是策略缩进模拟器熟悉的分布内、回避其知识盲区——盲区里反馈不可靠、常被误判，于是 Agent 学会只在 “模拟器擅长的世界” 里行动。防范的第一原则是把奖励锚定在可程序验证的真实状态上（任务完成、数据库写入、API 真实返回），模拟器或 LLM 评判者的打分只作辅助信号，并定期审计其与真实结果的相关性，配合路径约束惩罚可疑动作。进一步要区分两类模拟器：对搜索这类有真实对应物的模拟器，可以走 “混合” 路线——大部分交互走模拟、穿插真实 API 调用，并用真实调用定期校准模拟器（如 ZeroSearch 的课程式降质）；但对模拟用户，训练过程中无法引入真实用户，“模拟用户像不像真实用户” 就变成一个独立问题，只能用线上 trace 来回答：对比线上真实用户的行为与模拟用户在相同情境下的表现，找出系统性差异（真实用户会追问、会不耐烦、会突然结束对话，而模拟用户往往不会），据此持续校准模拟器；线上真实指标同时是唯一的发布门槛——模拟器里的分数再高都不算数。

第八章 Agent 的持续进化

1. (★★) 一条经验文档由三次成功轨迹和一次失败轨迹支持。失败发生在较新的 API 版本上。系统应如何判断这是经验被推翻，还是适用条件发生了变化？

先按 API 版本、任务条件和环境状态对四条证据分层，而不是按数量投票。若旧策略只在旧版本成功、新版本稳定失败，应把经验的适用范围收窄并生成新版本候选；若在相同版本和前置条件下也失败，则应降低置信度或撤销。

2. (★★) 客服 Agent 的用户满意度上升，但规则违规率也上升。为什么不能把满意度作为单一学习信号？你会怎样设计护栏指标？

满意度可能奖励违规退款、泄露信息或过度承诺，因此它只能是质量指标，不能覆盖安全底线。护栏至少包括规则违规、隐私泄露、无证据陈述、承诺—行动不一致和越权操作；这些指标应设置不可被平均分抵消的硬阈值，再在合规候选中比较解决率、合规变通、简洁性和满意度。

3. (★★★) 同一个“虚假承诺”问题可以通过 Prompt、Harness 检查或参数训练缓解。你会依据哪些证据选择修改位置？

先定位根因。若模型知道工具未执行却仍使用完成式措辞，可用最小 Prompt 规则纠正；若承诺可以由回复文本与工具状态确定性比较，Harness 检查更可靠，也应作为高风险场景的最后防线；若问题横跨大量表达方式，反映的是广泛的语言—行动对齐能力，再考虑参数训练。应优先选择最小、最易验证和回滚的修改，同时在失败集与旧任务保留集上比较。

4. (★★★) Agent 能修改工具和验证器，却不应修改批准自身更新的安全机制。你会如何划分这两部分的权限和代码边界？

把可进化的代码放在低权限的沙盒中，只允许它生成补丁和测试；权限系统、API key、发布控制配置和更新验证器属于安全机制，沙盒内的 Agent 无读写权限。Agent 生成的代码修改必须由安全机制在隔离环境中复现、回归后才能发布。

5. (★★) 经验知识库不断增长后，检索错误和知识冲突会抵消学习收益。如何设计版本、时效和淘汰机制？

每条经验保存来源轨迹、适用条件、环境版本、验证时间和置信度；冲突条目不要静默覆盖，而应按条件分支或标记。周期性“睡眠学习”合并重复条目。

6. (★★★) 参数学习擅长自然语言风格，却难以保证硬性业务规则。请为医疗客服设计一套参数、知识、Skill 和代码约束协同的持续进化方案。

参数（后训练模型）负责医学语言理解、自然且有同理心的表达和复杂意图识别；知识库保存最新版指南、药品说明与机构政策，并要求回答引用来源；Skill 描述问诊信息收集、风险分级、转人工和随访流程；服务端代码强制身份验证、隐私最小化、禁忌校验、紧急风险升级和权限边界。生产轨迹先按医疗安全、事实可靠性、承诺—行动一致性和表达质量评价，再分别生成四类候选更新；任何参数或流程改动都必须通过医疗安全保留集与人工复核后灰度发布。

第九章 多模态与实时交互

1. (★★) 语音 Agent 的端到端模型将 ASR-LLM-TTS 合并为单一模型，降低了延迟却失去了模块化。如果端到端模型在某个环节（如语音识别）出错，调试和修复比串行管道困难得多。你会如何设计端到端语音 Agent 的可观测性（observability）系统？

让模型伴随输出可读中间表示：如 Moshi 的"内心独白"文本流、声学事件标记（<emotion>、<noise>）；用"自级联"定位错误层：同一模型先转录再推理，对照端到端结果，判断错在感知还是思考；离线按副语言理解、轮次判断等维度分项回归测试。

2. (★) Step-Audio R1 通过 MPS 双脑架构实现"边想边说"。但人类在"边想边说"时经常会说出未经深思熟虑的话、自我纠正、或使用填充词。Agent 的"边想边说"应该模仿人类的这些特征吗？

该模仿有信号价值的"不完美"：停顿、填充词是思考的外化，能掩盖延迟，由 LLM 决定插入位置；不该模仿破坏信任的自我纠正：方案一中快慢矛盾（"到底买不买？!"）会让信任崩塌；MPS 实验显示 CoT 开头多是复述问题，早开口说铺垫是安全的，无需说错再改。

3. (★★) SoM（Set-of-Mark）及其结构化变体（DOM 元素索引）将 Computer Use 的视觉定位从开放坐标预测转为封闭 ID 选择，但都需要先检测和标注界面元素——无论靠分割模型还是靠 DOM。如果界面包含非标准控件或动态变化的元素，标注就可能不完整或不准确。这种情况下应该回退到坐标预测吗？

应保留坐标预测兜底：它是唯一不依赖标注的路线，非标准控件、动态元素均适用；更实用的是混合 action space：标注可得的元素仍用 ID 选择。坐标预测须做分辨率匹配与等比缩放，否则会发生系统性偏移。

4. (★★) XLeRobot 等千美元级机器人平台让遥操作数据收集变得廉价。但遥操作数据的质量高度依赖操作者的技能。一个不熟练的操作者提供的数据会如何影响 VLA 模型的训练？如何在数据收集阶段自动筛选低质量数据？

VLA 主要靠模仿学习，低质演示会把抖动、绕路、犹豫与失败动作当成正确策略学进去。呼应第七章的判断：数据比架构更关键。

5. (★★★) 本章覆盖了语音、Computer Use 和机器人三种交互形态。这三种形态的共同趋势是从串行管道向端到端模型演进。如果这种趋势继续，五年后的 Agent 交互层会是什么样的？

按 Thinking Machines Lab 主张，交互性将内建于模型而非外挂 harness，随智能一同扩展；Computer Use 从逐帧截图走向连续观察；具身智能的世界模型将全面实现，但由于前沿推理模型发展很快，快慢解耦不会消失，交互模型与 SOTA 思考模型的快慢思考协同架构可能成为长期架构。

6. (★★★) 当前 Computer Use 以"截图 → 动作 → 截图"的离散循环运作，每次观察都是一张静态帧。但人类对屏幕的感知是连续的——我们能看到动画播放、观察加载进度、理解视频内容。这意味着今天的 Computer Use 根本无法处理需要时序视觉理解的任务。如何重新设计感知层以支持连续的视觉流理解？

需要重新设计"观察接口"，把视频内容中的关键帧截取出来提供给模型，而不只是提供最后一帧。参考 AOI（Agent Observation Interface）论文。

7. (★★) DOM/Accessibility Tree 元素索引在标准 Web 应用上效果显著，但越来越多的软件界面（Canvas/WebGL 渲染、跨平台自绘控件）不提供可访问的结构化信息，只能依靠视觉标注或坐标预测。你认为 Computer Use 应该押注纯视觉路线，还是同时维护结构化和视觉两条路径？维护两条路径的成本和收益分别是什么？

短期双路径并存：结构化索引可得时定位最准稳、免分割误检；纯视觉是原生软件、Canvas、游戏的唯一选择。当模型本身 grounding（点击指定坐标）能力较强时，使用结构化索引方案并不会体现出显著优势。长期来说，纯视觉路线的上限更高。

8. (★★) VLA 模型采用动作分块（action chunking）——如正文所述，π₀ 的典型配置是一次生成 50Hz 频率下 25-50 个未来动作——将推理延迟隐藏在执行时间里。但如果执行过程中环境突变（如物体被移走），预生成的动作序列就会失效。如何在动作分块的效率优势和环境变化的响应速度之间取得平衡？

分块本质是拿反应性换平滑性，块越长越迟钝；块长只需满足"推理时间＜块执行时间"的下限，不盲目加长；执行中让感知模型持续运行，检测到环境突变即丢弃剩余动作重新推理，相当于语音场景的"打断"。可根据场景动态调块长：静态场景长块省算力，动态场景短块保反应延迟。

9. (★★★) 本章的三个场景（语音、Computer Use、机器人）都面临"感知-思考-行动"循环的延迟问题，都朝着快慢思考并行化的方向演进。在语音场景中，这表现为"说错了再纠正"；在 Computer Use 场景中，这表现为"先点再看"；在机器人场景中，这表现为"走一步看一步"。如何保证这些基于快思考的行动不会导致无法挽回的后果？

按可逆性给动作分级，快思考只许执行可逆动作，不可逆操作交慢思考把关；快模型不允许执行会造成不可逆后果的工具调用。

第十章 多 Agent 协作

1. (★★) 共享上下文的多 Agent 协作中，后续 Agent 继承了前序 Agent 的完整上下文。但前一个 Agent 积累的"思维惯性"可能影响后续 Agent 的判断——比如继承了"需求分析师"上下文的"代码审查员"，可能还是倾向于从需求角度思考而非代码质量角度。如何检测和消除这种角色间的干扰？

检测：用 LLM 分析 agent trajectory，判断是否出现新角色仍然“代入”旧角色的行为。消除：切换阶段时同时更换系统提示词与工具集（移除提问工具、换上 linter/测试工具）强化新身份。使用上下文末尾添加的系统状态栏，强化当前角色信息。如果实在不能消除角色干扰，应该考虑换用不共享上下文的协作方式。

2. (★★) 管理者模式中，Manager Agent 负责任务分解和结果整合。但 Manager 本身的能力上限决定了整个系统的能力上限——如果 Manager 无法正确分解任务，子 Agent 再强也无用。如何确保 Manager 的分解质量？

依据 Plan-and-Act 的结论，"弱规划者是系统瓶颈"，把最强模型分配给 Manager。Harness 手段：分解产物先经审核 LLM 交叉验证再执行；要求 manager 分解任务时，子任务定义明确验收标准与依赖关系。

3. (★★) 去中心化模式借鉴了人类组织的最佳实践。但人类组织也有大量失败模式——沟通不畅、责任推诿、目标冲突。你认为 Agent 社会中最可能出现哪些"组织病"？如何预防？

对照 MAST 三大类问题：接口不清、职责重叠；目标理解不一致、信息被下游误解；谎称"已完成"。此外还有错误级联放大（传话游戏）、角色间循环移交、agent 之间群聊发散不收敛。预防：契约式接口与统一消息信封、任务状态机与验收验证、独立视角交叉验证、角色间扯皮检测等。

4. (★★★) 在管理者模式中，当多个子 Agent 并行执行时，一个子 Agent 的发现可能使其他子 Agent 的工作变得毫无意义（比如搜索任务中一个 Agent 已经找到了答案）。设计一种高效的级联终止机制，实现"一个成功，全员停止"。

子 Agent 发 target_found 给管理者，随后广播 terminate；每个子 Agent 在 ReAct 循环安全点定期检查终止信号，优雅清理（关浏览器会话、释放锁、写完文件）后结束。

5. (★★★) 本章介绍的乐观锁机制解决了单文件的并发写入冲突，但实际的多 Agent 系统中，共享文件系统还面临跨文件的语义冲突、命名空间污染（Agent 随意创建文件导致目录混乱）和单点故障（一个 Agent 错误地删除了所有文件）等问题。你会如何设计更完善的文件系统治理机制？

分区治理：按表 10-4 四类区域划分，私有 scratchpad 隔离试错区域。语义冲突：编排层约定目录级的锁文件，检查并获取目录锁之后再修改。命名空间污染：目录规范、命名约定。单点故障：采用版本控制系统，版本历史可回滚，权限最小化。

6. (★★★) 基于市场机制的 Agent 协作（Pinchwork、RentAHuman）引入了交易关系：一个 Agent 花钱雇佣另一个 Agent（或人类）完成任务。那么，雇主 Agent 如何自动衡量执行者交付的结果质量？如果执行者声称已完成但雇主认为质量不达标，争议由谁仲裁？如何防止劣币驱逐良币？

验收不能只是读 agent trajectory，要用确定性外部验证，如测试执行、渲染截图、工具核验；利用生成-验证难度不对称降低验收成本。争议由独立第三方审核 Agent 仲裁，配合资金托管。防劣币：基于历史交付的声誉体系，让价格信号与质量挂钩。

7. (★★) RentAHuman 让 Agent 通过加密货币雇佣人类，反转了传统的人机关系。如果这种模式普及，人类在 Agent 经济中扮演什么角色？仅仅是执行 Agent 无法完成的物理任务吗？

不止是执行 Agent 无法完成的物理任务。人类还提供 Agent 生成时无法获得的新信息：现场感知与真实世界反馈；充当最终验收者与争议仲裁者；作为法律与责任主体承担授权、问责；设定目标与价值判断，在信息不对称和道德边界处充当制衡。

8. (★★) 人类社会需要多人分工协作，是因为每个人的能力有限——做前端的不一定懂后端，懂设计的不一定会运维。但大模型更像一个"全才"。相关研究表明，在纯文本推理任务上，多 Agent 辩论在等量计算资源下并不优于单 Agent。那么，使用多个 Agent 而非单个 Agent 的真正优势到底在哪里？

1. 引入外部反馈：执行结果、视觉截图等，引入生成时不存在的新信息。
2. 多个不同目标、不同角色设定的 Agent，像人类社会一样互相讨论、博弈，可以避免单一 Agent 陷入思维误区。
3. 多 Agent 的上下文隔离可以突破上下文窗口限制，实现超长工具调用链。

9. (★★★) 本章将"共享上下文"与"不共享上下文"作为多 Agent 系统的核心设计维度。共享上下文让所有 Agent 看到相同信息，似乎更利于协调。但《三体》中的三体人思维完全透明，技术发展却陷入停滞；回形针思想实验也表明，当群体趋向同一目标时，多样性随之丧失。在多 Agent 系统中，如何在效率与多样性之间找到平衡？

完全共享会放大思维惯性与错误级联，隔离才有认知多样性。手段：用不同提示词/模型制造思维偏好（brainstorm、debate）；交叉验证者不看前序思考过程只看原始证据。

10. (★★★) 给一个 Coding Agent 分配 30 步预算和 300 步预算，它的工作策略应该如何不同？研究表明，单纯增加步骤预算并不能保证性能提升——Agent 会在浅层搜索后过早"饱和"。设计一种"预算感知"机制，让 Agent 在小预算下快速实现核心功能，在大预算下增加规划、测试和审查环节，充分利用额外的计算资源。

机制：每步向提示词注入总预算与剩余预算，按剩余比例动态调整探索/利用权重。例如小预算（30 步）：跳过规划审查，直奔核心功能加基本验证。大预算（300 步）：先规划、再实现、再测试、再审查改进，按里程碑设检查点评估进展，防止浅层饱和。

11. (★★) 本章将“过早终止”分为偷懒式假完成、过早放弃、假成功三类。为什么三类问题的解法殊途同归，都指向验证？

共同根源：任务是否结束由模型的自我宣称决定，“完成” 只是宣称，不是证明。验证器的条件：①基于真实观测（跑测试、渲染截图、查退款是否实际到账）；②对照显式的完成定义逐项核查，兜住偷懒式假完成与假成功；③对失败结论同样要验证，兜住过早放弃；④配显式终止条件（轮数/预算上限），防止从过早终止滑向另一个极端——循环失控。

12. (★★) 表10-3 把多 Agent 系统与操作系统逐行对应。请把这张表再延伸几行：虚拟内存与分页、文件权限、死锁检测、调度算法，各对应 Agent 世界的什么？又有哪些操作系统概念在 Agent 世界找不到对应物，为什么？

可能的延伸：虚拟内存/换页 ↔ 上下文压缩与检索（热信息留在窗口内，冷信息换出到文件与记忆库，用时再取）；文件权限 ↔ 工具白名单、只读挂载、凭证边界；死锁检测 ↔ 循环移交与互相等待的检测（移交次数上限、超时）；调度算法 ↔ 异步事件处理（第四章）。找不到对应物的地方源于强制力不同：进程的指令由硬件强制执行，Agent 对提示词只是大概率遵循。