第十章学习笔记：多叫几个 Agent，真的就能把事情做得更好吗？
本文是对第十章《多 Agent 协作》的学习整理。
上一篇：第五章学习笔记：代码是 Agent 的元能力，但可靠性来自验证。
文中的实验数字来自仓库保留的报告与结果文件，本次没有重新运行实验；架构取舍是基于这些材料的学习思考。
翻译一本书，为什么会越做越累？
假设我要把一本带代码和插图的技术书翻译成中文。第一章还很顺利：Agent 读原文、选术语、输出译文。到了后面，它开始需要同时记住前面章节的译法、编辑部的要求、图片路径、代码保留规则，以及已经返工过哪些段落。
这时，“再找几个 Agent 帮忙”很有吸引力：一个整理术语，一个翻译，一个审校，再安排一个经理。看起来像组建了一家小型出版社。
但角色名字一写好，工作就会自动变好吗？翻译者拿到的是哪一版术语表？审校者怎样知道一张图的路径被改错了？经理收到“已完成”，能不能直接交稿？
读第十章时，我最感兴趣的正是这个落差：分工很容易描述，可靠的协作却需要把信息、权限、交接和验收都设计清楚。 多 Agent 的难点，经常出现在两个角色之间。
我给本章留下的一条主线是：
每增加一个 Agent，都应该说清楚它贡献什么、需要知道什么、凭什么判断它做完了。
先问它增加了什么，再决定要不要“组队”
本章把“是否引入新信息”作为判断协作价值的重要标准。这个角度很实用：如果五个 Agent 看着同一段文字，互相复述同一种推理，讨论再热闹，也不等于结论更可靠。
比如，一个 Agent 生成了网页，另一个只读代码并说“看起来不错”；换成审核者打开网页、实际点击按钮、检查渲染截图，反馈的性质就变了。它能指出“窄屏下按钮被遮住”“表单提交没有更新状态”，这些都是生成代码时尚未得到的环境证据。
CRITIC 论文展示的也是这条路径：模型先生成回答，再与外部工具交互，依据验证反馈修正输出。它支持外部反馈的价值，但不能据此断言一定要使用多个 Agent——单个 Agent 同样可以搜索、执行代码和查看结果。
因此，我会把本章的判据再补一层：新增证据是判断验证是否有效的关键；采用多 Agent，还需要说明为什么把这件事拆开更划算。 常见理由有三个：
- 可以并行。 搜索多个独立网站时，同时探索能缩短等待时间。
- 需要隔离。 翻译者只处理当前单元，经理只维护进度，避免所有历史挤在同一个窗口里。
- 需要独立的职责与权限。 执行者修改候选成果，审核者读取实际结果，验收门槛由运行时保护。
这三个理由可以叠加，也可以只成立一个。相反，如果任务很短、步骤之间强依赖、结果容易检查，拆成多个 Agent 可能增加交接与调度成本。
比较方案时，还要给单 Agent 一个合理的基线：相同的工具、必要资料和可比的资源预算。让多 Agent 多花几倍 token，再把胜出全部归因于“团队智慧”，会混淆架构收益和计算量收益。
“大家都知道”与“各自负责”，是两套信息设计
第二章提醒我，上下文是在决定 Agent 当前能看见什么。到了第十章，这个问题变成了：哪些信息应该所有人都看见，哪些只该进入某个角色的窗口？
接班时带走全部历史，还是只拿交接材料？
共享上下文可以理解为接班：下一阶段继承前一阶段的对话和工具轨迹，再切换职责。它适合连续性很强的短流程，例如先查资料、再分析、最后写摘要。但完整历史也会带来累计 token 开销、无关细节和前序判断的影响；继承了全部记录，并不保证每个细节都被有效利用。
独立上下文则更像不同工位：每个 Agent 有自己的工作记录，通过参数、文件或消息交换必要信息。它降低了单个窗口的信息负担，却把难题转移到了接口上。原始需求漏传一句，后续角色可能认真完成一个错误任务。
书籍翻译实验给出了一个具体的拆法：术语 Agent 产出术语表，翻译 Agent 读取当前单元和术语表，审校 Agent 检查译文，Manager 保存计划、文件索引和报告摘要。完整译文落到文件系统中，Manager 按需读取。
这里真正节省上下文的是让长内容留在产物里，让调度信息留在经理的窗口里。路径传递很轻，但接收方读取正文仍然消耗上下文；Manager 的索引与调用记录也会随任务增长，仍需整理，不能理解成无限长任务下上下文恒定。
角色转换，未必需要创建一个新 Agent
本章实验 10-1 比较了两条共享轨迹的路径：切换 system prompt 和工具集，或者保持静态前缀、按需加载 Skill。它让我意识到，“现在按分析师的流程工作”和“启动一个有独立状态的分析师”是不同的设计选择。
| 角色变化主要涉及什么 | 可以考虑的做法 | 需要额外检查什么 |
|---|---|---|
| 知识、步骤、写作风格 | 按需加载 Skill | 指令是否被加载并遵循 |
| 不同阶段的工具范围 | 切换角色和工具集 | 执行层是否拒绝越界调用 |
| 独立任务、私有信息或并发执行 | 独立 Agent 上下文 | 信息交接、资源与权限隔离 |
Skill 有利于保持请求前缀稳定，但缓存是否命中仍取决于实际接口与请求结构。工具在 schema 中不可见，也只是减少模型选择它的机会；硬权限仍应在执行层检查。
这与第四章的工具设计连在一起：工作手册告诉 Agent 应该怎么做，运行时决定它实际上能做什么。
好的协作，首先要有一份不会让人猜的交接材料
我很喜欢本章把多 Agent 系统类比为操作系统：Agent 有私有状态，需要创建、通信、等待、取消，也需要共享存储。这使很多问题从“模型为什么不听话”变成了可以具体处理的工程问题。
不过，这只是类比。独立上下文并不自动隔离文件、浏览器、数据库或 API 配额；错误结论仍可能随消息传播。真正的隔离需要运行时落实。
大产物放文件，小状态走消息
沿用翻译场景，我会把交接材料写成这样。以下是用于说明的约定，不是仓库中的现成接口：
{
"task_id": "translate-chapter-10",
"goal": "翻译第十章，保留代码内容和图片目标路径",
"source_ref": "input/chapter10.md",
"glossary_ref": "shared/glossary-v3.json",
"output_ref": "shared/chapter10.zh.md",
"acceptance": ["无遗漏段落", "代码内容不变", "图片目标路径不变"],
"unresolved": ["新术语需在审校报告中标记"],
"max_revision_rounds": 2
}接收者需要目标、事实、约束、产物引用和剩余问题。长篇思考记录可以留作诊断材料，日常交接则应尽量给出简明状态，并保留原始证据的入口。
文件空间也需要分区：临时草稿留在角色的私有目录，交付物进入任务共享目录，外部挂载资源遵守源系统的授权，内置 Skill 和模板按只读资源管理。同样是文件路径，生命周期和权限可以完全不同。
发出任务以后，系统还得知道怎样收回来
共享文件承载产物，是“数据平面”；任务分配、状态事件、取消和预算，则构成“控制平面”。后者决定系统能不能收尾。
本章的电话与电脑双 Agent 实验很直观：电话 Agent 询问下一项信息时，电脑 Agent 可以填写上一项。如果网页发现格式错误，就要把字段和原因传回来。只有两边的动作真正重叠，才能算并行；预先启动两个角色却让它们轮流等待，收益可能很小。
并行搜索则有另一种收尾方式：一个 worker 找到目标，其他搜索可能不再需要。但必须先验证候选匹配是否正确，再原子地确定唯一结果，随后取消其余 worker、等待确认并关闭资源。否则同名误匹配会让搜索提前停止，几乎同时到达的两份结果也可能触发重复结算。
还有一个前提容易漏掉：“找到一个就停”适用于找到任一合格目标的任务。 如果用户要的是完整名录，或需要比较不同网站的证据，第一个成功结果并不能代替剩余工作。
预算同样要由运行时执行。步数、轮数、并发数、时间和费用应有上限；进度文件长时间不更新可以触发检查，但不能仅凭修改时间认定任务没有活动——它也可能正在等待一次较慢的工具调用。
组织结构可以换，验收责任不能消失
本章介绍了对等协作、管理者模式和去中心化模式。我更愿意用“谁决定下一步”来区分它们。
| 模式 | 谁决定下一步 | 适合解决的问题 | 主要代价 |
|---|---|---|---|
| 对等协作 | 少量角色按约定互相反馈 | 生成与审核、方案评议 | 反馈趋同、循环难以终止 |
| 管理者模式 | Manager 分解、调度、整合 | 大量子任务、依赖与并行搜索 | 规划瓶颈、全局状态负担 |
| 去中心化模式 | 各角色决定何时交接或求助 | 动态路由、自主协商 | 成环、责任不清、目标冲突 |
审核者的价值，在于它真的检查了结果
第五章的提议者—审核者循环，到这里变成了一条通用原则：审核者应访问原始证据或实际环境，给出可定位的修复条件。
对翻译任务，“语言不够自然”很难指导修改；“本段把 latency 译成了延迟，与当前术语表要求不符”就明确得多。代码保留、图片目标和链接这些可机械检查的要求，则可以直接交给程序验证，再让模型处理语义准确性和可读性。
审核者也会错。不同提示词、不同模型和先独立判断后汇总，可以增加视角差异，但不能保证判断独立，更不能把多个模型赞同直接当成事实。验收标准和证据采集器应受到保护，执行者不能通过放宽标准让自己通过。
Manager 应该理解全局，不必抄一遍全局
经理的工作是拆任务、提供必要信息、识别依赖与处理异常。如果它把每个子 Agent 的全部输出和轨迹重新读一遍，上下文隔离的收益就被吃掉了。
但只收摘要也不够。Manager 必须能沿引用回到原始证据，特别是在子任务边界有遗漏、输出互相矛盾或审校发现跨章节问题时。平时用摘要调度，遇到争议按需取证，是我从本章得到的一个实用取舍。
“Swarm”这个名字，没有告诉我信息到底怎样流动
消息采用发布订阅，并不意味着控制权去中心化；角色自己发起 handoff，也不意味着上下文自动隔离。判断一个系统，仍要看谁掌握路由、哪些历史被传递、失败由谁接管。
跨系统协作时，A2A 把一些接口约定标准化：Agent Card 描述能力与认证要求，Task 承载可跟踪的工作生命周期，Artifact 表示具体产物；远端 Agent 的内部记忆和工具可以保持不透明。这些概念见 A2A 官方文档。协议帮助双方交流，授权、验收与争议处理仍需系统设计。
最危险的故障，可能长得像“大家都做对了”
两个 Agent 同时覆盖同一个文件，问题比较容易发现。更难的是它们分别完成了自己的工作，却共同破坏了系统。
比如一个 Agent 重新编号图片，另一个依据旧编号更新章节。Git 合并没有冲突，引用却已经失效。worktree 能隔离工作副本，乐观锁能防止同一对象的旧版本覆盖，但跨文件关系还需要合并后的检查。
我把本章的失败模式整理成了几组需要同时观察的信号：
| 失败模式 | 看起来可能发生了什么 | 需要补上的机制 |
|---|---|---|
| 文件与语义冲突 | 文件各自正确，组合后引用或接口失效 | 工作副本隔离、版本检查、集成验证 |
| 错误级联 | 未核实的推测被下游写成确定事实 | 保留来源与不确定性，回到原始证据核查 |
| 同质趋同 | 多个角色给出相同错误判断 | 区分信息源与职责，避免先相互暗示 |
| 互相扯皮 | 人人都在解释为何该由别人修 | 明确产物责任、目标优先级和裁决规则 |
| 循环失控 | 重复交接、反复返工、持续创建子任务 | 预算上限、无进展检测、取消机制 |
| 理解债 | 交付越来越快，人越来越难解释系统 | 保留关键决策、证据与人工理解的机会 |
其中“错误级联”最值得警惕。通信层可以完整送达一条消息，但模型转述时可能把“可能如此”改成“已经确认”。消息送达与语义可信是两回事。
理解债则提醒我，协作成本还包括人的审查时间。收到五份报告，最终仍要有人理解哪些结论相互依赖、哪些只是模型判断。产物越多，越需要保留能解释关键决策的证据。
实验让我相信机制，也让我收起“全面更优”的想象
本章配套实验最有价值的部分，是它没有把不符合预期的结果删掉。下面几组数字来自不同任务与运行配置，不能跨行比较，也不代表普遍性能结论。
| 实验与证据入口 | 仓库保留的结果 | 我会怎样解读 |
|---|---|---|
| 10-1：角色切换与 Skill | 30 对任务中，Skill 完整确定性验收通过 15/30，Transfer 为 2/30；Skill 增加了未缓存输入和时延 | 当前模型与修复后的 Harness 中，Skill 路径更好；provider 报告的缓存输入始终为零，不能声称已验证缓存收益 |
| 10-2：书籍翻译 | Manager 主上下文峰值 4,618 token，单 Agent 为 94,355；翻译流程总 token 为 203,277 与 1,317,808；耗时 270.829 秒与 254.127 秒 | 隔离显著降低了这次比较中的主上下文与翻译 token，但增加了耗时；总 token 这里不包含独立质量裁判开销 |
| 10-4：多网站搜索 | 当前保留的 v2 运行实测加速 1.872 倍，并验证了取消确认与资源关闭 | 证明这批站点上的并行收益和收尾机制；不意味着启动十个 worker 就能加速十倍 |
| 10-5：AI 小镇 | 25 个角色的模型盲评中，基线获偏好 17 次，关闭反思组获偏好 8 次；自定义工作坊只出现在发起人的记忆中 | 反思在这次评估中有帮助，但活动扩散并非必然；角色可信度也不是现实社会预测能力 |
翻译实验还有一组容易被“上下文缩小约 20 倍”掩盖的结果：管理者组的匿名质量均分略高，指定译法遵从率为 75%，单 Agent 为 0%；但宽泛字符串术语一致率分别为 50% 和 87.5%。两组都保留了代码块数量，却都改变了代码内容，管理者组还改变了图片目标路径。相关指标与逐章检查保留在正式证据文件中。
这几项并不矛盾。“按照指定译法写”和“全书始终用同一种译法”不是同一指标；代码块数量相同，也不代表内容原样保留。质量裁判的高分，不能替代可确定检查的结构要求。
还要注意，这次翻译比较同时改变了术语表供给、上下文组织和审校流程。它支持两条具体流水线之间的比较，不能单独证明所有差异都来自 Agent 数量。若要进一步判断架构本身的收益，可以增加一个拥有相同术语表、相同验收规则，但定期整理上下文的单 Agent 基线。
这些结果改变了我看实验的方式：完成对照实验，意味着获得了可分析的结果，不意味着最初的质量假设全部成立。
从“项目团队”走向“Agent 社会”，评价标准也变了
前面的协作有明确交付物：译文、表单、搜索结果。Agent 社会则把多个角色放在同一环境里，让它们长期交互，观察关系、信息扩散和策略行为。
Generative Agents 原论文把 25 个 Agent 放进 Smallville，结合记忆、反思与规划。研究报告了从一条派对意图出发，邀请自行传播、角色协调赴约等行为。这很有启发性：协调可以来自个体之间的局部互动，不必把所有行动都写成中心计划。
但这里的“可信”主要是在评价模拟角色的行为。它不能直接推导出意识，也不能证明这个小镇能预测真实人群。模型、初始记忆、环境规则和评分方式，都会影响我们看到的“涌现”。仓库中自定义工作坊没有扩散的结果，也提醒我：精彩案例揭示了一种可能，不是每次运行都会复现的保证。
本章的语音狼人杀则把另一条边界讲得很清楚：法官由代码维护真实身份、阶段和胜负规则，每个角色只收到自己获准知道的信息。模型负责发言与策略，规则执行和私有信息分发由运行时承担。
这个设计也适用于普通业务协作：如果两个 Agent 本来不该知道同样的信息，就应在构造上下文时隔离，而非把完整状态交给它们后再要求保密。
当群体交互进一步包含竞争、交易和各自不同的目标，协作效率就不再是唯一问题。系统还要回答：谁决定交付质量，争议由谁裁决，个体获得奖励时有没有损害整体目标？群体行为需要单独评价，不能只把单个 Agent 的成绩相加。
写在最后：我会先写协作契约，再写角色提示词
读完第十章，我对多 Agent 的兴趣更具体了。它可以让长任务的上下文变得可管理，让独立工作真正重叠，也可以让验证得到单次生成时缺少的证据。与此同时，每一次拆分都增加了交接、同步和验收的责任。
如果下一次要设计这样的系统，我会先写清楚：每个角色拿到什么输入、交付什么产物、谁来验证、失败怎样恢复、预算耗尽怎样停止。再判断哪些边界值得用独立 Agent 承担，哪些用 Skill 或确定性程序就足够。
一支值得信任的 Agent 团队，应该让分工的收益可以测量，让结论的证据可以追溯，让没做完的部分仍然清楚可见。 对我来说，这比团队里有多少个听起来专业的角色，更能说明它是否适合接下一项真实工作。
第十章配套实验记录
实验10-1：共享上下文中的角色切换与 Skill 对比
GPT-5.6 Luna 完成 30 对真实任务后，Skill 路径的确定性门禁通过率为 16/30，Transfer 为 1/30；Skill 同时增加了延迟和费用，并在边界测试中出现一次违反禁止联网要求的真实工具调用，因此不能只凭通过率判定其全面更优。