多 Agent 如何通信：任务书、结构化回传与 A2A 协议

把一个问题交给三个 Agent，可能得到更丰富的证据，也可能得到三份重复搜索。多 Agent 的价值在于并行探索、隔离上下文和分工；能不能清楚拆任务、收结果、处理失败，比 Agent 数量更重要。

简单任务先用单 Agent 基线；任务确有独立子问题、不同工具或不同上下文需求时，再比较多 Agent。本文讨论系统设计，协议与框架能力按所用版本验证。

模式由任务依赖决定

任务暂时拆不清，不代表必须让 Agent 群聊。也可以先让一个规划步骤厘清依赖；自由交流会增加轮次和验证难度。

图 1 · 编排者负责预算、依赖和验收，子任务输出需要可验证。

任务书与回传要形成接口

任务书至少说明目标、输入与可信来源、允许工具与操作、范围边界、输出结构、预算和验收条件。例如“核对 A 方案的数据库过滤行为；只读官方文档；给结论、出处和未确认项；不要修改代码”。

结果可以包含：

{
  "task_id": "research-filtering-1",
  "attempt_id": "attempt-2",
  "status": "completed",
  "summary": "已核对目标版本的过滤顺序。",
  "evidence": [{ "source_id": "official-doc-1", "locator": "filtering" }],
  "artifact": { "id": "report-7", "revision": 2 },
  "unresolved": [],
  "usage": { "estimated_cost": 0.03, "currency": "USD" }
}

这是业务契约示例，不是 A2A 原生消息。状态含义固定，失败、部分完成与需要输入不能统一写成“完成”。结论、证据和推测分开，编排者检查引用与授权后再采用。

OpenAI 的 manager 与 handoff：控制权在哪里

Agents SDK 编排文档^[6]区分管理者把其他 Agent 当工具调用，以及把控制权交给另一个 Agent 的 handoff。前者由管理者继续组织任务和汇总，后者由接手者继续对话；它们不自动等价于跨机的 A2A 服务。

工程推导：需要统一输出、预算和验收时，管理者模式便于集中控制；需要不同专长接管当前交互时可以比较 handoff。两者都要验证传递的上下文、执行身份、审批规则和总费用；使用哪种模式不能免除外部工具授权。

文件引用：同一机器可用，跨机需要交付机制

共享目录里的“路径加摘要”可以避免把长报告塞回主上下文，但路径只是位置，不是不可变成果。两个 Agent 覆盖同名文件后，摘要可能指向另一版本。

为成果保留 task ID、版本、内容摘要与写入完成标志；大文件原子替换或先写临时文件再发布。跨进程、容器和组织不能假定共享文件系统，应使用受控对象存储或 artifact API，带权限和有效期。收件人无法读取的本地路径不算成功交付。

上下文继承也因框架不同：有的子代理只拿任务输入，有的 fork 完整历史。启动前明确携带什么，避免把机密或无关历史扩散给所有工人。

状态、重试与取消也是通信的一部分

子任务要有排队、运行、等待输入、完成、失败、取消等状态。每次重试有独立 attempt，逻辑 task 保持稳定；回传去重，晚到结果不覆盖已取消或更新的任务。

并行任务设置软截止时间、总预算与部分成果规则。一个慢任务超时后，编排者可以汇总已验证部分并明确缺口，不一定一直等所有工人。父任务取消应传到子任务和工具；任务树限制并发与深度，防止无界扇出。

对付共享写冲突，优先按文件或模块分工；需要隔离时用独立工作区再合并。worktree 只隔离文件状态，并不隔离数据库、端口或外部 API 副作用，这些资源也要划分。

MCP 与 A2A：职责互补，不能替代授权

MCP 统一应用与工具、资源等能力的连接；A2A 统一独立 Agent 服务间的发现与任务交互。MCP server 也可能包装一个 Agent，因此这只是主要职责区别，不是技术上禁止交叉。

A2A 的 Agent Card 描述能力，Message 承载交互，Task 表达生命周期，Artifact 交付成果；流式和传输绑定按协议版本选择。不能把某个旧版本的 JSON-RPC/SSE 形态写成所有实现唯一支持的传输。A2A 规范^[3]

发现能力不等于授予权限。卡片自述、任务元数据和模型输出不作为可靠身份；每次调用仍校验身份、scope、数据访问与目标地址。协议不能消除提示注入，也不能让跨租户成果天然安全。MCP 安全说明^[4]

成本与质量：并行不一定更快

Anthropic 的研究系统报告了特定模型组合与基准下的收益及更高 token 消耗。这是该系统的实测，不是“任何多 Agent 都提升 90%”或“必花 15 倍”的定律。原始复盘^[1]

并行墙钟时间约为最慢关键路径加汇总开销，总 token 则包括子任务与编排、汇总的全部调用。评测时固定总预算，对照单 Agent、分工多 Agent 和独立评审：看正确率、证据覆盖、重复工作、总费用、延迟与冲突率。

投票不是事实核验：多个同模型可能犯同一个错。合并适合互补成果，择优适合可比较答案，评审适合找缺陷；最终由明确的验收规则裁决。

落地检查

1. 单 Agent 基线先跑，证明任务有并行或隔离收益。
2. 输入、输出、状态、预算和验收条件写成契约。
3. 成果带版本，跨机通过有权限的 artifact 交付。
4. 重试、取消、晚到消息和部分完成可恢复。
5. 工作区和外部副作用都隔离，合并后再验证。
6. 子代理结果按不受信任输入处理，按任务统计成本。

参考资料