第14章　多Agent：把分工变成可验证的协作¶

状态：初学者展开试稿，待人工审阅（基于Release Candidate 1修订）

本章定位：承接第2章的最低充分自主性、第3章的执行图和第9—11章的生产控制，说明什么时候值得引入多个Agent，以及怎样设计上下文、通信、身份、权限、调度、合并和评估。

本章回答的三个问题¶

多Agent何时比单Agent、Skill、专业工具或普通并行更合适？
多个Agent怎样交换任务、消息和Artifact，而不复制全部上下文或互相覆盖？
身份、权限、审批、预算、取消、恢复、冲突合并和完成证据怎样落实到整个协作生命周期？

本章沿用前文的学校场景，但任务变得更大：

“为班级月球分享准备一份双语资料包。需要核对三份来源、写中英文摘要、制作一张推荐卡，并由老师批准后发送。资料研究可以并行；不要预约图书，也不要让任何Worker直接发送消息。”

这个任务可能用一个Agent完成，也可能拆成研究、翻译、核验和发布准备等子任务。本章不会先假定“人多力量大”，而是先建立单Agent基线，再判断拆分是否带来独立信息、真实并行、上下文隔离或权限隔离。

证据类型说明

本章严格区分三类话语：教学示例只解释机制；标为“本书建议”的内容是需要在具体系统验证的工程建议；只有明确引用论文或仓库保存记录的内容才是限定条件下的实测结论。本章没有重新运行第10章实验，不采用仍待证据审查的实验卡数字，也不虚构成功率、延迟、成本或通用阈值。

5分钟速读¶

多Agent系统让两个或更多具有独立运行边界的Agent围绕同一目标协作。独立边界可以体现在Context、State、身份、工具、生命周期或工作区，而不是角色名称。
一个模型先“当研究员”再“当写作者”，如果共享同一运行状态和权限，通常只是阶段化单Agent或Workflow；加载不同Skill也不自动变成多Agent。
引入多Agent前至少需要一个强理由：独立新信息、真正可并行工作、上下文／安全隔离、独立身份／权限，或持续交互的Handoff。框架支持和角色更像团队不是理由。
编排（Orchestration）是一个Manager统一拆分与收集；移交（Handoff）是把后续交互控制权交给另一个处理者；去中心化协作让Agent直接按协议交换任务。复杂度依次增加，但不是成熟度等级。
共享上下文保留细节，却放大膨胀、干扰和泄漏；独立上下文隔离更强，却必须依靠结构化任务包、消息和Artifact传递信息。
数据平面搬运任务输入和产物；控制平面管理创建、状态、预算、取消、恢复和结算。消息总线不是Artifact存储，聊天记录也不是权威State。
每个Worker应有私有工作区、最小工具、独立预算和明确终态；只发布带Schema、Hash、来源、ACL和生命周期的Artifact，由单一Owner合并。
角色名称不授予权限。Manager不能委派自己没有的权力，Worker也不能因消息写着“已批准”就执行高影响动作。正式审批必须从权威审批系统核对准确载荷。
Proposer–Reviewer只有在Reviewer读取测试、截图、权威查询等独立证据时才有价值；多个Agent只看同一文本互相同意，不构成事实核验。
多Agent必须与等总预算单Agent基线比较，同时看结果、轨迹、延迟、成本、安全、冲突、取消和恢复。只有净收益持续存在才保留。

一、先定义：什么才算多个Agent¶

1.1 Agent、角色、Skill和Worker不要混用¶

第1章将Agent定义为：能够依据当前Context选择行动，通过受控工具与环境交互，并在预算和终止条件内推进目标的系统。多Agent系统（Multi-Agent System）则让多个这样的运行实体协作。¹

本章所说的“独立Agent”，至少在下列一项上有独立边界：

自己的Context和Trajectory；
自己的类型化State和Run身份；
自己的工具或权限范围；
自己的生命周期、预算和取消状态；
自己的私有工作区和Artifact所有权。

如果同一个Run只是在不同阶段更换System Prompt，却继承全部Context、State、身份和工具权限，更准确的叫法通常是阶段化单Agent或带模型节点的Workflow。若只加载不同领域说明，则是同一个Agent使用不同Skill。Skill是可按需加载的知识与流程，不是独立执行者，也不是权限凭证。

Worker（执行者）是被分配有界子任务的运行实体。它可以是Agent，也可以是确定性程序、普通模型调用或外部服务。不要因为流程里有三个并行步骤，就自动称为“三个Agent”。

1.2 为什么定义边界很重要¶

假设研究、翻译和写作都由同一模型按顺序完成。把三段Prompt分别命名为ResearchAgent、TranslationAgent和WriterAgent，并不会自动带来信息隔离或权限隔离。若它们仍看到同一份冗长轨迹，拥有同一发送凭据，故障面并没有因为改名而缩小。

反过来，一个子任务即使没有华丽角色名，只要有独立Run、只读资料权限、私有工作区、明确交付和可取消生命周期，它已经具备真正的Worker边界。

因此，本章判断系统结构时始终追问：谁拥有哪段状态，谁能看什么，谁能做什么，谁负责结算，失败后谁被取消？

1.3 多Agent不是能力等级的必经终点¶

蓝皮书ADR-003把多Agent放在自主性选择阶梯的最后，不是因为它“最高级”，而是因为它增加了通信、合并、身份、成本和故障处理。²

固定的资料抽取用普通并行调用即可；流程已知时使用Workflow；一个有界Agent能完成时不必再拆。只有单Agent基线暴露了明确问题，而拆分确实针对该问题时，才进入多Agent设计。

二、贯穿案例：先写问题合同，再决定是否拆分¶

2.1 任务合同¶

对“双语月球资料包”，先写清：

Actor：学生发起；老师审批发布。
Goal：提交中英文摘要、三份来源核验表和一张推荐卡。
Inputs：授权资料库、公开来源、实时馆藏查询。
Outputs：版本化资料包Artifact；发布前仅为草稿。
Success：主张有来源，双语事实一致，馆藏状态带查询时点，老师批准准确版本后才发送。
Forbidden：预约、读取无关学生数据、Worker直接发送或修改审批。
Budgets：总模型调用、工具、时间、费用、并发和委派深度由项目填写并由Runtime执行。
Recovery：任一Worker失败不覆盖已验证产物；父Run取消会级联取消子Run。

这是教学合同。真实系统的预算、数据政策和审批角色必须由项目负责人填写，不能照抄一组“万能数字”。

2.2 单Agent基线¶

最简单基线可以是一个只读Agent顺序完成：读取任务 → 搜索三份来源 → 写中文摘要 → 写英文摘要 → 生成卡片 → 运行一致性检查 → 等待审批。

如果这条基线已经在允许时间和成本内稳定满足验收，就应保留。上下文变长时，也可先试第4章的检索、压缩和Artifact外置；术语知识不同，可以加载Skill；已知三份资料可以由普通程序并行抓取。它们都比多Agent少一层协作故障。

2.3 观察到什么问题后才升级¶

假设基线评估发现：三份独立来源顺序查询导致等待过长；翻译阶段把研究过程全部带入Context后，常遗漏术语约束；核验者若继承写作者完整轨迹，容易接受同一错误假设。此时可以提出三个待验证理由：

三个来源能够独立并行；
翻译只需核实后的事实与术语表，不需要研究试错轨迹；
Reviewer应从原始来源和最终草稿独立核验，而不是继承写作者解释。

这些理由支持试验一个Manager–Workers方案，但还不是收益证明。最终仍需与等预算基线比较。

三、多Agent准入测试：新增成员到底补了什么¶

3.1 五个强理由¶

P20模式要求至少满足以下一项，并用评估验证净收益。³

独立新信息。 不同Worker访问不同授权来源，或Reviewer读取执行结果、截图、传感器或权威状态。新增的是单次生成时没有的证据，而不是另一个角色的意见。

真正可并行。 子任务之间没有必须等待的依赖，可以同时查询三份来源。并行是否降低端到端等待，还受外部限流、启动与合并成本影响，必须实测。

上下文或安全隔离。 每个Worker只看到当前子任务所需资料，避免完整轨迹相互污染；敏感数据按身份和任务隔离。仅仅“窗口很长”不够，检索与Artifact外置可能已经解决。

独立身份或权限。 研究Worker只读，发布服务有专门身份且只在正式审批后执行。这里真正有价值的是安全边界；某些场景用两个普通服务而非两个Agent就足够。

持续交互的Handoff或跨组织边界。 专门流程需要直接接手后续用户交流，或任务交给另一个组织的Agent并跟踪生命周期。一次查询结果返回通常不需要Handoff。

3.2 不能单独成立的理由¶

下列说法不能证明需要多Agent：

“框架内置了Agent Team”；
“像一家公司，应该有经理、研究员和审核员”；
“多个回答投票一定更准确”；
“每个角色写不同System Prompt，所以是独立专家”；
“上下文装不下，所以复制给更多Agent”；
“更强模型太贵，所以多调几个弱模型一定更便宜”。

多个同模型、同Context、同工具的实例可能产生同源错误。投票只能聚合答案，不能把没有来源的主张变成事实。

3.3 升级顺序¶

同一Agent加载Skill
→ 调用专业工具或普通并行步骤
→ Manager委派有界子任务并收回结果
→ Handoff让专门处理者接管持续交互
→ 去中心化或跨组织协作

这不是必须逐级实现的产品路线，而是复杂度检查顺序。每升一级，都要补上身份、消息、状态、预算、取消、恢复、Artifact和评估。

四、共享Context还是独立Context¶

4.1 共享Context：像接班人阅读完整工作日志¶

共享Context指后续阶段继承前序完整或近乎完整的消息与工具轨迹。好处是细节不易在交接中丢失，适合短流程、低敏感度的阶段切换。

代价包括：

Context随每一阶段增长，成本和截断风险上升；
早期错误假设被后续角色继承；
后续阶段可能看到不需要的敏感数据和工具结果；
System Prompt或工具集切换可能影响缓存；
看见相同解释的Reviewer较难形成独立核验。

若差异主要是写作规程，可以保留一个Agent并加载Skill。若角色必须使用不同身份或工具，单纯切Prompt不够，应建立独立执行边界。

4.2 独立Context：像不同工作间通过交接包合作¶

独立Context指每个Agent维护自己的Trajectory和局部State，只通过任务包、消息或Artifact交换必要信息。好处是隔离、并行和最小披露；代价是交接会遗漏信息，接口和调试更复杂。

贯穿案例中，研究Worker只收到具体来源、要核验的主张、允许工具和交付Schema；翻译Worker只收到已核实事实、术语表和目标读者；Reviewer收到原始来源引用和待核验草稿，但不默认读取写作者的自我解释。

4.3 不要把“完整内部推理”当交接物¶

一个有效交接包通常包含：

# 教学示例
subtask_id: source-check-02
goal: 核验“月球背面永远黑暗”这一主张
constraints:
  - 只使用允许来源
  - 不修改共享草稿
accepted_facts:
  - claim_id: claim-07
artifact_refs:
  - artifact://run-demo/source-list-v1.json
output_schema: evidence-verdict-v2
remaining_budget: PROJECT_DEFINED
success_condition: 返回supported/refuted/insufficient及可定位来源

交接的是任务、已确认事实、约束、Artifact引用、预算和完成条件，不是整个私有轨迹。完整轨迹可以按审计政策保存在受控存储，遇到故障时由有权限的调试者读取，不应默认复制给每个Agent。

五、三种协作拓扑：谁决定下一步¶

5.1 Peer：少量对等角色相互检查¶

Peer（对等协作）让少量Agent按明确协议迭代，例如Proposer提出资料包，Reviewer依据来源和渲染结果指出缺口。它适合角色关系固定、轮数有限的反馈循环。

风险是互相同意、循环不止或目标冲突。需要明确谁能改Artifact、反馈Schema、最大轮数、最小改进条件和最终Verifier。Reviewer没有发布权限，也不能修改验证器。

5.2 Manager–Workers：一个Owner动态拆分和收集¶

Manager（管理者／编排者）理解总目标、拆分子任务、分配身份与预算、接收结果、处理失败并形成最终交付。Orchestration（编排）就是这种中心化协调。

贯穿案例可表示为：

Manager建立任务图
├── Research Worker A：来源一
├── Research Worker B：来源二
├── Research Worker C：来源三
└── 等待结构化结果
    → Merge：去重并保留冲突
    → Translation Worker：依据核实事实写双语摘要
    → Reviewer：读取来源与草稿核验
    → Manager生成待审批资料包
    → 正式审批工作流发送

Manager是单一结算Owner，但不应成为万能事实源。它合并结果时仍要依靠来源、Schema和Verifier；Worker自称完成不够。

5.3 Handoff：把后续交互控制权交出去¶

Handoff（移交）不是“问另一个Agent一道题”，而是让接收方直接掌握接下来的对话或任务推进。例如学生的请求从资料推荐转为账号恢复，专门身份流程可能需要接手后续核验。

移交必须包含接收确认、最小必要Context、委托范围、预算、返回或人工升级路径。接收者不能继承发送者全部凭据；真实权限由Runtime和策略网关重新判断。

5.4 Decentralized：Agent按协议自主协作¶

去中心化协作（Decentralized Collaboration）没有运行时唯一Manager，Agent按消息或Handoff协议决定向谁请求、接收或转交工作。它适合组织边界、动态发现和各方不共享内部实现的场景。

代价最大：可能发生移交环、责任漂移、重复执行、局部状态不一致和无人结算。Runtime仍需保留任务ID、访问链、委派深度、总预算、终态和人工升级；“去中心化”不等于“没有控制面”。

5.5 怎样选¶

任务特征	优先考虑	不宜直接升级的情况
角色差异只是知识或文风	单Agent + Skill	不需独立状态或权限
已知独立子任务	普通并行／有界Workers	Manager不需动态拆分
动态发现子任务、最终答案需一个Owner	Manager–Workers	Manager无法验证结果
专门流程需持续接管用户交流	Handoff	只需返回一次查询
跨组织、动态能力发现	A2A／去中心化	同团队内部简单调用已够用

六、协作合同：Agent之间传什么¶

6.1 消息信封¶

消息信封（Message Envelope）是包住业务内容的结构化元数据，帮助路由、去重、追踪和版本检查：

message_id: msg_demo_123
sender: research-worker-a
recipient: manager
run_id: run_demo_456
parent_span_id: span_demo_08
type: result
schema: evidence-verdict-v2
payload_ref: artifact://run_demo_456/verdict-a.json
created_at: 2026-09-22T10:00:00Z
expires_at: 2026-09-22T11:00:00Z
sequence: 4
content_hash: sha256:example-only

字段和值都是教学示例。真实系统还要绑定Tenant、认证来源、签名或传输保护、重放防护和数据分类。message_id用于去重，run_id用于关联任务，schema用于解析，payload_ref避免把大型产物塞进消息。

6.2 消息不是事实，也不是审批¶

认证消息只能说明它来自某个已知主体，不能证明内容正确。ResearchWorker: supported仍需查看其来源；ApprovalAgent: approved不能替代正式审批记录。接收方应按Schema校验，再依据来源、权限和当前State决定是否接受。

外部文本可以通过Agent消息继续传播提示注入。每一跳都不能因为“来自内部Agent”就把数据升级成系统指令。

6.3 Handoff合同¶

一次Handoff至少要说明：

当前任务与剩余目标；
已确认事实和证据引用；
不得修改的用户约束；
接收者身份与工具范围；
当前状态、剩余预算和截止时间；
访问过的Agent或最大移交深度；
接收、拒绝、退回和人工升级语义；
最终结果由谁结算。

没有接收确认，不应假设责任已经转移。A转B、B又转A的环路要由访问链和次数上限检测，而不是只靠Prompt提醒。

七、数据平面：用Artifact交换成果¶

7.1 数据平面是什么¶

数据平面（Data Plane）负责存放和传递任务输入、证据和产物。对于多Agent，最重要的设计不是“大家能看到一个目录”，而是不同区域的可见性和生命周期。

/agents/{agent_id}/scratch   # Worker私有临时区
/workspace/published         # 经原子发布、可供协作读取的Artifact
/mnt/external                # 用户授权的外部资源，默认只读
/system/skills               # 版本化只读Skill和模板

目录名是教学示例。真正权限由操作系统、对象存储ACL和工具网关实施，不能只靠路径命名。

7.2 私有工作区与单一Owner合并¶

P19模式建议每个Worker使用私有Scratch或Git Worktree，完成后发布Artifact；最终由单一Owner合并。⁴

这是为了防止：

两个Worker同时覆盖同一文件；
一个Worker读到另一个尚未写完的半成品；
临时日志和秘密意外进入用户交付区；
任务取消后无人知道哪些文件可删除；
多个Agent同时声称自己生成了最终版本。

共享读通常比共享写简单。确实需要写同一对象时，可使用版本号、Compare-and-Swap、锁或事务；但文件级锁只能发现同一文件冲突，跨文件语义冲突仍需合并验证器。

7.3 Artifact合同¶

发布Artifact时至少记录：

artifact_id: evidence-a-v1
uri: artifact://run_demo_456/evidence-a-v1.json
schema: evidence-verdict-v2
content_hash: sha256:example-only
producer: research-worker-a
source_refs:
  - https://example.invalid/source-a
acl: [manager, reviewer]
classification: internal-demo
created_at: 2026-09-22T10:00:00Z
expires_at: 2026-10-22T10:00:00Z
status: published

Hash用于发现内容变化，不证明内容真实；来源链接也需要适用性核对。Artifact应原子发布：消费者只能读取完整published版本，不能读取正在写入的临时文件。

7.4 外部挂载与凭据¶

外部云盘、Wiki或代码库只在用户授权范围内挂载。适配器代管短时、最小作用域凭据；凭据不能进入Agent消息、文件、Artifact元数据或模型Context。写回外部源属于副作用，需要单独工具、权限、审批和恢复合同。

八、控制平面：谁创建、调度、停止和恢复Agent¶

8.1 控制平面是什么¶

控制平面（Control Plane）管理协作生命周期，而不承载大型业务内容。常见原语包括：

spawn_agent：创建子Run并绑定任务、身份、工具、预算和父Run；
send_message：发送类型化消息；
publish_status：发布运行、等待、阻塞、成功、失败或取消状态；
collect_result：收取结构化结果和Artifact引用；
cancel_agent：请求优雅取消并级联；
list_agents：在授权范围内发现和诊断；
Scheduler：管理队列、并发、优先级、租约和总费用。

模型可以建议创建Worker，Runtime决定是否允许，并执行深度、并发和预算上限。不能让模型通过递归委派生成无限Agent树。

8.2 父子生命周期与取消¶

父Run取消后，Runtime先阻止新委派，向所有子Run发送取消，在各自安全点保存State、发布可保留Artifact、释放浏览器和临时凭据，再等待确认或超时强制终止。P15将其称为Safe Point与级联取消。¹²

一个真正需要脱离父任务长期运行的Agent，应新建明确Owner和生命周期，而不是悄悄成为孤儿。它仍需要预算、权限、取消和审计。

8.3 Checkpoint与恢复¶

Manager和每个Worker都需要类型化State；等待事件或跨进程运行时保存Checkpoint。恢复时读取最新可信State，核对租约、父Run状态、剩余预算和已发布Artifact，而不是从头重放全部消息。⁷⁸

若Worker已经发布结果但确认消息丢失，Manager应按subtask_id和Artifact状态查询，而不是创建一个新Worker重复同一写操作。外部副作用仍使用业务幂等键。⁹

8.4 结算必须原子化¶

并行搜索可能有两个Worker几乎同时报告“找到答案”。结算（Settlement）是把一个结果正式选为当前任务结果的状态转移。它应通过状态版本或事务只成功一次：

收到候选结果
→ Verifier核对来源和完成条件
→ 原子声明winner或记录多个有效结果
→ 保存Checkpoint
→ 取消不再需要的Worker
→ 等待确认并清理资源

“第一个返回”不等于“第一个验证成功”。如果任务要求覆盖所有来源，就不能采用胜者即停；调度策略必须服从成功定义。

九、身份、权限、审批和副作用¶

9.1 每个Agent都应有最小委托范围¶

Manager以学生任务身份读取公开资料，并不意味着所有Worker都能查看班级名单。研究Worker可只读指定来源；翻译Worker只读已发布证据；Reviewer可读原始来源和草稿；发布工具对它们全部不可见。

权限至少绑定：Principal、Tenant、父Run、目标资源、动作、目的、期限和政策版本。Manager不能委派自己没有的权限；Worker也不能再次扩大委托。所有工具路径仍经过第6章的统一策略网关。¹¹

9.2 角色名称不是身份¶

FinanceAgent、TeacherAgent或ReviewerAgent只是应用标签。认证来自身份系统，授权来自政策。一个Agent消息写“老师已批准”不能解锁发送工具。

正式发送时，执行器查询权威审批系统，核对批准者、准确资料包版本、收件范围、政策、期限和Action Digest。载荷变化必须重新审批。¹⁰

9.3 凭据怎样处理¶

Worker只获得当前工具需要的短时凭据；
凭据由执行器注入，不传给模型；
子Agent不继承Manager全部Secret；
跨组织凭据限制Audience和Scope；
取消、超时和任务结束后撤销或过期；
Trace只记录凭据引用或提供者，不记录秘密值。

9.4 写操作、回滚和完成证据¶

若某个Worker确需写外部系统，应使用窄工具、稳定业务幂等键和权威状态查询。发送请求超时后沿用原键查询，不能再派一个Worker换新键发送。

回滚只适用于可恢复状态；已发消息通常只能补偿。完成证据应关联父Run、子Run、正式审批、执行载荷Hash、幂等键、外部对象ID、权威终态和配置版本。多Agent的互相确认不能代替这些证据。

十、Proposer–Reviewer–Verifier：审核必须带来新证据¶

10.1 三个职责¶

P13模式把循环分为：⁵

Proposer生成候选
→ 执行、渲染或查询环境
→ Reviewer读取候选与独立证据
→ 输出结构化缺口
→ Proposer修复
→ Verifier按门禁终止

在资料包案例中，Proposer写摘要；工具重新取得来源片段与双语对齐结果；Reviewer逐项给出claim_id、证据位置和问题；Verifier检查所有必填主张都有支持，且没有越权发布。

10.2 什么是独立证据¶

独立证据可以是：

代码编译、测试和实际运行；
页面或幻灯片渲染截图；
权威数据库或API查询；
原始来源与引用支持关系；
传感器、文件重新读取或Hash；
有真实身份的人工决定。

另一个Agent只看同一草稿并说“我同意”，不是独立证据。换模型可能带来不同偏差，但仍不能证明外部事实。

10.3 Reviewer的权限边界¶

Reviewer可以否决或提出修订，不能：

修改测试、Rubric或发布阈值以让候选通过；
使用提议者的写凭据；
自己批准高影响动作；
把不可信资料升级为系统指令；
在预算耗尽后自行延长循环。

确定性验证一次通过时，无需为了模式完整强行增加多轮Reviewer。

十一、预算与调度：限制协作的最坏情况¶

11.1 总预算与局部预算¶

多Agent预算至少有两层：父Run的总预算和每个Worker的局部预算。可包含模型调用、Token、工具调用、墙钟时间、费用、并发、委派深度、消息量和Artifact大小。

Manager可以提出分配方案，Runtime负责预留和扣减。不能让各Worker都拿到“完整总预算”，否则扇出后实际上限成倍增长。

11.2 并行不一定降低延迟¶

并行收益受以下因素影响：

子任务是否真独立；
最慢Worker是否阻塞Fan-in；
模型和工具是否共享限流；
Agent启动、Context构造和消息成本；
部分失败是否要求重跑；
合并与验证是否成为瓶颈。

因此不要从架构图推算加速比例。应在相同任务和截止时间下测量端到端分布。

11.3 无进展、抢占和早停¶

Worker连续重复同一工具、同一参数和同一错误，不算进展。Runtime可依据结构化状态摘要和错误指纹停止或降级。

抢占（Preemption）是高优先级任务暂时取得资源。被抢占Worker应在安全点保存状态并释放租约。若任务只需一个被验证的答案，结算成功后可以取消冗余探索；若任务目标是覆盖多个视角，则不能因最早答案出现而提前结束。

十二、结果合并：总结果不能只是“让Manager综合一下”¶

12.1 合并合同¶

合并节点至少要处理：

输出Schema和版本是否一致；
来源、时点和证据是否完整；
重复结果怎样去重；
冲突事实怎样保留；
缺失、超时和失败Worker怎样表示；
谁拥有最终Artifact；
哪些条件可由程序验证，哪些需要人工；
合并后是否重新运行端到端Verifier。

12.2 冲突处理¶

假设两个Worker对“月球背面永远黑暗”给出相反结论。Manager不能凭语气选一边，也不能用多数投票代替来源核验。应比较来源适用性、发布日期、直接性和引用片段；仍无法裁决时，最终资料包显式标记争议或请求专家确认。

三个Agent一致也可能来自同一个错误网页或相同模型偏差。Agent数量不是证据独立性的度量。

12.3 单一Owner与最终验证¶

Worker只发布候选Artifact；Merge Owner生成新版本，而不是原地覆盖各Worker文件。最终Verifier重新检查双语一致性、引用、馆藏时点、审批对象和发送状态。只有最终环境证据通过，父Run才能成功。

十三、A2A与跨组织协作¶

13.1 A2A解决什么¶

A2A（Agent2Agent）是一类面向Agent间能力发现、任务、消息、状态和Artifact交换的协议。它适合双方实现互不可见、任务可能长时间运行的跨系统协作。第6章已经把它与MCP区分：MCP主要连接应用与工具／资源提供者，A2A主要连接Agent与Agent。¹⁴

协议能标准化“怎样说”，不能自动回答“是否可信、是否允许、结果是否正确”。同团队内固定协作若用普通函数或消息队列已足够，不必为名称升级协议。

13.2 跨信任边界至少要补什么¶

双方服务身份、证书或令牌的认证；
用户到本地Agent再到远端Agent的委托链；
每一跳对Purpose、资源、动作和数据范围的授权；
任务、消息和Artifact Schema版本；
消息ID、时效、Nonce和重放防护；
数据分类、留存、删除和再委托限制；
SLA、费用、取消、争议和责任Owner；
对远端结果的独立验证；
断开对端、撤销凭据和回退本地流程的方法。

远端Agent不应收到本地完整轨迹和长期凭据。只传完成任务所需的最小任务包与Artifact；返回内容仍是不可信输入。

十四、失败模式与反例¶

14.1 反例一：角色变多，但信息完全相同¶

三个Agent读同一篇文章、用同一模型互相投票。它们可能一致复述同一错误。先用单Agent加来源验证；若保留多次采样，要把它当作采样策略评估，而不是独立事实证明。

14.2 反例二：复制完整Context给所有Worker¶

成本和敏感数据随Worker数增长，早期错误也被复制。应按子任务提供最小任务包，以Artifact引用共享大对象。

14.3 反例三：Worker继承Manager全部权限¶

研究Worker因此可以发送班级消息或读取无关学生资料。应使用独立身份／委托和最小工具；正式发送留在确定性审批工作流。

14.4 反例四：多个Worker直接编辑共享文件¶

后写覆盖先写，或消费者读到半成品。应使用私有工作区、原子Artifact发布和单一Merge Owner；共享写入使用版本检查。

14.5 反例五：Manager无限递归委派¶

每个Worker又创建更多Worker，成本和攻击面指数式扩大。Runtime应限制深度、并发、总预算和消息量，并检测无进展。

14.6 反例六：Reviewer只复述意见¶

Reviewer没有测试、截图或原始来源，只说“还可以更清晰”。这可能改善文风，却不能核验事实。反馈应定位到要求和独立证据；没有新证据时考虑单次模型修订或人工编辑。

14.7 反例七：Handoff没有接收确认¶

A认为B已经接手，B因Schema不兼容拒绝，任务无人负责。需要accepted/rejected/needs_input等明确状态，原Owner在接收确认前不能释放责任。

14.8 反例八：父Run结束，子Agent仍在运行¶

孤儿Worker继续调用工具或产生费用。父子生命周期应级联取消；长期后台任务必须显式改绑Owner和预算。

14.9 反例九：冲突被“综合”为一个流畅答案¶

Manager把互相矛盾的数字取平均或任意选择，隐藏了不确定性。应保留来源、冲突状态和裁决路径；无法验证时交人工。

14.10 反例十：第一个声称成功的Worker触发全员停止¶

如果它的结果尚未验证，级联取消可能丢掉真正答案。只有第一个验证成功并完成原子结算的结果，才能触发相应早停。

14.11 反例十一：消息已签名，所以内容正确¶

签名可以帮助确认来源与完整性，不能证明事实、权限或审批。接收方仍要校验任务状态、来源和业务规则。

14.12 反例十二：多Agent只与低预算单Agent比较¶

复杂方案使用数倍Token和工具调用，基线却被限制为一次短回答。结论无法说明组织方式的贡献。应公开总预算，并做等预算或成本—质量曲线比较。

十五、怎样评估多Agent系统¶

15.1 建立公平基线¶

P20要求用相同任务、工具、截止时间和总Token／费用比较单Agent基线。等预算不一定能在所有供应商下精确做到，但应记录实际Usage，并同时报告：

等上限比较：两种方案允许相同总预算；
自然运行比较：各自在实际停止条件下的质量、成本和延迟；
成本—质量曲线：不同预算下净收益是否持续。

Manager、Reviewer、消息、重试和合并都算入多Agent总成本。不能只统计Worker正文Token。

15.2 五层指标¶

沿用第10章的五层评估：

层	多Agent要额外检查什么
Outcome	最终资料包是否完整、正确且有证据
Trajectory	委派、消息、Handoff、审批和合并顺序是否允许
System	子Run恢复、重复消息、孤儿任务、结算和级联取消是否正确
Economics	总Token、工具、等待、启动、合并、人工与每成功任务成本
Safety	跨Agent越权、跨租户泄漏、凭据扩散、注入传播和错误副作用

还应单列覆盖率、冲突率、合并错误、Artifact质量、Context复制量、Worker失败分布和Manager瓶颈。

15.3 故障注入¶

多Agent评估应主动制造：

一个Worker超时或崩溃；
重复、乱序、过期或被重放的消息；
两个Worker同时报告成功；
Artifact Hash不匹配或Schema过期；
Worker返回错误但流畅的结论；
Manager重启、租约过期和旧Worker恢复；
父Run取消时子Worker无响应；
正式审批变化或凭据到期；
外部内容通过一个Worker向其他Agent传播提示注入。

离线和影子环境不得持有生产写权限。使用合成数据、测试租户和短时最小凭据；高影响演练要提前定义停止、回滚和补偿。

15.4 仓库证据边界¶

仓库为原始第10章保留了角色切换、书籍翻译、电话与浏览器、并行网页研究、生成式Agent和语音狼人杀等项目与验证文件。蓝皮书对应实验卡目前标记为pending，初步证据等级为E1或E2，且要求人工核验模型、输入、原始回执、Manifest和评分口径。¹⁵

因此本章可以把这些项目作为“有哪些可复核资产”的来源，却不把实验卡标题中的通过率、加速比或Token数字写成已审定实测结论。发布前若要引用数字，应逐项完成证据审查并登记强主张。

十六、实施检查清单¶

准入与架构¶

[ ] 已写明单Agent／Skill／专业工具／普通并行基线。
[ ] 至少一个强理由成立：新信息、并行、隔离、独立权限或持续Handoff。
[ ] 共享或独立Context选择有依据，没有默认复制全部轨迹。
[ ] Peer、Manager、Handoff或去中心化拓扑与任务依赖匹配。
[ ] 新增Agent解决的是已观察问题，而不是角色命名需求。

任务、消息与Artifact¶

[ ] 每个子任务有目标、输入、约束、Schema、预算、截止时间和终态。
[ ] 消息有ID、Run、发送者、接收者、类型、版本、时效与重放防护。
[ ] 消息内容不被自动当作事实、系统指令或正式审批。
[ ] 大对象通过Artifact URI交换，带Hash、来源、ACL、版本和生命周期。
[ ] Worker使用私有Scratch／Worktree，发布原子版本；最终有单一Merge Owner。
[ ] 冲突、缺失、超时和失败Worker在合并结果中显式保留。

身份、权限、凭据与审批¶

[ ] 用户、Manager、Worker、远端Agent和审批者有可追踪身份与委托链。
[ ] 每个Agent只看到当前任务需要的数据和工具，不能自行扩大权限。
[ ] 所有工具调用经过统一策略网关；协议或内部消息不能绕过授权。
[ ] 凭据由执行层代管、短时且窄作用域，不进入Context、消息或Artifact。
[ ] 高影响动作由正式系统对准确载荷审批；Agent消息不能替代审批。
[ ] 写动作使用稳定幂等键，结果未知时先查权威状态。

生命周期、恢复与预算¶

[ ] 父Run和每个Worker有类型化State、Checkpoint、Owner和显式终态。
[ ] 委派深度、并发、模型调用、Token、工具、时间、费用和存储有硬上限。
[ ] Manager分配局部预算，Runtime强制父Run总预算。
[ ] 父Run取消会阻止新工作、级联子Run并在安全点清理资源。
[ ] 恢复不重放已完成副作用，旧Worker和旧消息不能覆盖新State。
[ ] 第一个验证成功的结果原子结算后，才按任务合同取消冗余Worker。

验证、评估与交付¶

[ ] Reviewer读取测试、截图、权威查询或原始来源等独立证据。
[ ] Verifier独立于Proposer，候选不能修改测试、门槛或审计证据。
[ ] 最终合并后重新运行端到端验证，不以Worker自述完成。
[ ] 与等预算单Agent基线比较结果、轨迹、系统、成本和安全。
[ ] 评估覆盖重复／乱序消息、崩溃、冲突、取消、恢复和提示注入传播。
[ ] 完成报告关联父子Run、配置版本、Artifact、审批、幂等键、外部ID和权威终态。
[ ] 任何未运行、未复现或仍待证据审查的结论均明确标记。

知识检查¶

先用自己的话回答，再看参考解释。

同一个模型依次扮演研究员和写作者，为什么不一定是多Agent？
什么是多Agent的五类强准入理由？
三份已知网页同时抓取，为什么不一定需要三个Agent？
共享Context与独立Context各自的主要代价是什么？
Manager–Workers与Handoff的关键区别是什么？
数据平面与控制平面分别负责什么？
为什么Agent消息经过认证后，仍不能当作事实或审批？
多个Worker为什么不应直接编辑同一共享文件？
Reviewer读取什么，才比“再看一遍候选”更有价值？
第一个Worker说“找到答案”后，为什么不能立即取消其他Worker？
Manager能否把自己没有的发送权限委派给Worker？
A2A解决什么，又不解决什么？
为什么多Agent评估必须计算Manager、通信和合并成本？
多Agent方案质量更好但花费更多，怎样判断是否保留？
父Run取消后，怎样证明取消真正完成？

参考解释¶

第1题：角色文字不等于独立运行边界。 若两阶段共享同一Context、State、身份、工具和生命周期，它更像阶段化单Agent或Workflow；只有知识差异时还可以使用Skill。

第2题：独立新信息、真正可并行、上下文／安全隔离、独立身份／权限，以及持续Handoff或跨组织边界。 每一项都只是候选理由，最终还要通过比较验证净收益。

第3题：子任务已知且动作固定，普通程序并发或三次结构化模型调用就可能足够。 只有每个分支需要根据反馈自主探索、独立状态或权限时，才进一步评估Agent。

第4题：共享Context保留细节但膨胀、干扰和泄漏面更大；独立Context隔离和并行更好，却有交接遗漏、接口和调试成本。

第5题：Manager委派有界子任务并收回结果，自己仍掌握后续流程；Handoff把接下来的交互控制权交给接收者。 Handoff需要接收确认、返回或升级路径。

第6题：数据平面承载输入、证据和Artifact；控制平面管理创建、消息、状态、预算、取消、恢复和结算。 大型内容不应塞进控制消息，聊天也不能代替权威State。

第7题：认证只证明消息来源，不证明内容正确、任务仍有效或批准真实存在。 接收方仍需校验Schema、来源、当前权限和权威审批记录。

第8题：可能发生覆盖、半写入读取和责任不清。 每个Worker使用私有工作区，原子发布带版本Artifact，由单一Owner合并并运行最终验证。

第9题：测试执行、渲染截图、权威API、原始来源、传感器或真实人工决定等独立证据。 另一个模型的意见可以辅助开放质量，却不能单独证明事实。

第10题：它可能只是自称成功，结果尚未通过Verifier。 只有验证通过并原子结算后，才能依据任务合同决定是否早停；覆盖型任务甚至不能早停。

第11题：不能。 Manager只能在自己获准范围内委托更窄权限；角色名称和自然语言消息都不能创造权限。

第12题：A2A标准化Agent间发现、任务、消息、状态和Artifact交换。 它不自动建立业务信任、授权、数据政策、正确性或责任归属。

第13题：这些都是多Agent架构新增的真实资源。 若只算Worker正文Token，会把额外成本隐藏起来，无法与单Agent公平比较。

第14题：在同一批代表任务和公开预算下比较质量、延迟、每成功任务成本、安全和运营复杂度。 质量收益可能值得额外成本，也可能不值得；应画出成本—质量关系并保留回退方案。

第15题：要看到新工作已停止、取消已沿子任务树传播、Worker在安全点保存并释放资源、结果未知的副作用已查询、父子State进入明确终态且没有孤儿Run。 UI停止转圈不是充分证据。

本章小结¶

回到双语月球资料包：如果一个Agent已经能在预算内完成，就不拆。若三份来源确实可并行、翻译需要隔离Context、Reviewer需要独立来源证据，则Manager可以创建最小权限的研究Worker。每个Worker在私有工作区完成有界任务，只发布带Schema、Hash、来源和ACL的Artifact；Manager显式保留冲突，由翻译Worker生成双语草稿，再让Reviewer依据原始来源核验。最终资料包由单一Owner合并，发送仍回到正式审批、幂等执行和权威状态验证。

多Agent的核心不是把一个模型复制几份，而是设计一套可检查的组织机制：

强准入理由
+ 清楚的Context边界
+ 类型化任务、消息与Artifact
+ 独立身份、最小权限与准确审批
+ 有界预算、取消、Checkpoint与恢复
+ 冲突可见、单一Owner合并、独立Verifier
+ 等预算单Agent基线
= 值得保留的多Agent系统

请记住本章的一句话：只有当分工带来独立信息、真实并行或必要隔离，并且这些收益经过等预算评估仍覆盖通信、合并、安全与运维成本时，多Agent才是工程升级；否则，它只是更昂贵的角色扮演。

本章与前文的关系也由此闭合：第2章决定是否准入；第3章提供执行图和State；第4—6章提供Context、Artifact和工具协议；第9章提供恢复、预算和发布控制；第10章负责公平评估；第11章确保身份、权限和审批不会在委派中丢失。多Agent不是绕过这些控制的捷径，而是要求把它们复制到每一条协作边界。

来源与证据¶

原始中文书稿第10章是本章的主要内部来源，涵盖共享／独立Context、工具参数／文件／消息通信、Peer／Manager／去中心化拓扑、虚拟文件系统、生命周期、A2A、Proposer–Reviewer、并行研究和失败模式。本章保留工程主线，删除或不采用无法在本次修订中完成证据审查的时效性产品主张、宏大预测与量化效果。¹
蓝皮书ADR-003和P01规定最低充分自主性；P20规定多Agent强准入理由与等预算基线；P19规定私有工作区和Artifact交换；P13规定Reviewer必须读取独立证据。²³⁴⁵
P03—P08与P15为多Agent生命周期提供有界循环、类型化State、Checkpoint、幂等、准确载荷审批、统一工具网关和级联取消。⁶⁷⁸⁹¹⁰¹¹¹²
Actor模型的经典论文用于说明“私有状态 + 消息 + 创建新Actor”的历史来源；本章只借用该抽象，不把LLM Agent等同于经典Actor运行时。¹³
A2A官方规范仓库用于核对Agent间任务与消息互操作的定位；协议会演进，实现时应固定版本并复核认证、安全和数据政策。¹⁴
仓库第10章实验卡目前均标记为待证据审查。本章不引用卡片标题中的量化结果；这不是“实验不存在”，而是遵守“代码存在不替代运行证据、pending数字不进入主文结论”的证据边界。¹⁵

原始中文书稿，../../book/chapter10.md。本章重点采用“多Agent协作的分类框架”“共享／不共享上下文”“Agent间通信与控制”“管理者模式”“去中心化模式”“A2A协议”“失败模式”和本章小结中的工程内容。 ↩↩
蓝皮书../plan/DECISIONS.md中的ADR-003，以及P01最低充分自主性。这是架构治理原则，不是多Agent必然劣于单Agent的实测定律。 ↩↩
蓝皮书P20多Agent准入与等预算基线。模式要求至少存在新信息、并行、隔离、独立身份／权限或Handoff理由，并将Manager和合并成本计入比较。 ↩↩
蓝皮书P19独立Agent工作区与Artifact交换。私有Scratch／Worktree与单一Owner能降低覆盖风险，仍需语义冲突检查和最终验证。 ↩↩
蓝皮书P13 Proposer–Reviewer–Verifier。模式要求Reviewer读取执行、渲染或事实等独立证据，并由独立Verifier按门禁终止。 ↩↩
蓝皮书P03有界执行循环。多Agent将步骤预算扩展为父Run总预算、Worker局部预算、并发和委派深度，具体阈值仍需项目实测。 ↩
蓝皮书P04类型化状态与显式终态。父Run和子Run均需区分运行、等待、阻塞、成功、失败、取消与预算耗尽。 ↩↩
蓝皮书P05 Checkpoint与持久恢复。恢复不能机械重放已完成副作用；消息、Artifact和已完成动作都需进入可恢复状态。 ↩↩
蓝皮书P06幂等副作用。稳定业务键、动作Digest和权威状态查询同样适用于由Worker触发的外部写入。 ↩↩
蓝皮书P07准确载荷审批。Agent间消息或角色名称不能替代由真实身份对准确对象、参数、政策和期限作出的批准。 ↩↩
蓝皮书P08统一工具策略网关。本地Worker、远端Agent、MCP或A2A路径都不能绕过Schema、身份、政策、预算、审批和结果验证。 ↩↩
蓝皮书P15 Safe Point与级联取消。父任务取消应阻止新工作、保存状态、清理资源并沿子任务树传播；外部结果未知时仍需查询权威状态。 ↩↩
Carl Hewitt、Peter Bishop与Richard Steiger，A Universal Modular ACTOR Formalism for Artificial Intelligence，IJCAI 1973。https://www.ijcai.org/Proceedings/73/Papers/027B.pdf ↩
A2A Protocol，官方规范仓库。本章仅采用能力发现、任务／消息生命周期与Artifact交换的协议定位；认证、授权、重放防护和业务验证仍由参与方实现。 ↩↩
蓝皮书../experiments/cards/chapter10/中的实验10-1至10-6卡片在本次核对时均为pending；卡片明确要求人工核验原始证据、模型、环境、指标和局限后再裁决可支持主张。 ↩↩

第14章 多Agent：把分工变成可验证的协作¶