主题
多 Agent 协作与分布式通信
一句话：多 Agent 的价值来自组织，不来自数量；分布式通信的价值来自语义分层，不来自上一个更重的协议。前者要先把任务、责任和结果说清，后者要先把“连接”和“状态”分开。
对应原书：第 11 章《Multi-Agent 协作与编排》、第 12 章《Agent 分布式通信》。
为什么需要
单 Agent 撞到三种墙时，才会考虑多 Agent：上下文装不下不同角色的材料、需要能力与权限隔离、需要并行缩短墙钟时间。但这三种收益都有代价——任务拆分、信息传递、状态一致、额外的模型调用与运行开销。
很多团队跳过“收益是否覆盖成本”这一步，直接按角色数量堆 Agent，结果得到的是一个更贵、更难排障的单 Agent：信息全都汇到主管，主管成了瓶颈；每个成员都“完成”了，但没人对整体结果负责。
分布式通信的问题更底层：用同步 HTTP 串起所有环节，一旦某一步要等人工审批三天，连接、进程、上下文全都撑不住。此时加消息队列，又容易把“消息送达”当成“任务完成”。
核心机制
一、三种拓扑，不是演进关系
| 拓扑 | 协调方式 | 适用 | 主要风险 |
|---|---|---|---|
| 主管—执行 | 集中协调、分散执行 | 目标明确、责任集中 | 所有局部判断都等主管 |
| 对等协作 | 直接协商、共同决策 | 探索性强、专业对等 | 分歧处理与最终责任未约定 |
| 分层编排 | 按专业小组逐层交付 | 规模较大、小组能独立交付 | 跨层信息损耗、汇报延迟 |
选择的依据是专业分工、工作耦合度、决策方式和协调成本，不是“高级程度”。增加层级只有在小组能承担完整交付责任时才有意义，否则只是增加信息损耗。
二、Task 不等于 Task Run
Task 是持续的工作约定：目标、范围、交付物、验收条件、负责人、约束；Task Run 是一次实际执行，重试、恢复、重新分派都会产生新的 Run；Session 与 Run 可以关联，但不一一对应。一个 Task 有多次 Run，才能区分“任务失败了”和“这次执行失败了”。消息发送成功也不等于任务被承接——那只是传输完成。
三、协作的停止条件要提前约定
团队级停止条件必须在根任务开始前写清楚：时间与成本预算、最大委派深度、派生任务数上限、重试次数、返工轮次、连续无有效进展的判定。触发之后：暂停新的委派与自动返工，保留已有结果、阻塞项和剩余预算，转人工。没有这些条件，多 Agent 系统会以一种“每个 Agent 都很努力”的方式无限扩张。
四、共享上下文，不是相同上下文
共享的是上下文来源，不是同一份 Context。统一维护目标、约束、任务状态、已确认事实与产物，每个成员按角色、任务、权限和执行阶段形成局部视图，遵循最小充分原则。
Handoff 只传四类信息：目标与范围、已知事实、待处理事项、可用引用。搜索过程、工具调用记录、未验证的推理不原样传递——它们会污染接收方的判断。团队记忆只沉淀经过验证的信息，保留来源、边界，并且可更新、可降级、可淘汰。
五、三层结果语义：提交、接受、完成
| 层 | 谁做 | 含义 |
|---|---|---|
| 提交 | 执行者 | 候选成果产生 |
| 接受 | Leader | 可向下游使用 |
| 完成 | 根任务 | 当前有效版本共同覆盖目标 |
在此之上还有一层：用户取得产物、确认接受并归档，才算真正完结。把“提交”当“完成”，是多 Agent 最常见的虚报来源。
六、四个通信面与四档语义
四档语义是谱系而不是成熟度阶梯，要按每一面自己的矛盾选择，而不是统一升到最高档：
- S1 请求—响应：响应期内耦合，依赖可达端点；
- S2 请求域流式：解决增量可见，但流依赖连接，断连后不保证补齐；
- S3 任务句柄：提交后凭标识查询或订阅，执行与首次请求解耦；
- S4 持久通道：按通道订阅、确认、补读，生产与消费解耦。
一个系统可以同时使用多档：人机面默认 S2、能力面默认 S1、协作面的持续交接用 S3、内构面按职责选 S1 或 S3。统一上最高档位，会引入不必要的队列、保留与运维成本。
七、通信契约的六个要素
- 标识：会话、任务、轮次、消息各有标识与从属关系。任务标识直接绑消息线程标识，会限制后台执行与跨渠道续接。
- 顺序：通常只保证任务或会话内有序，不承诺跨会话全局顺序。
- 投递保证：至少一次、至多一次、恰好一次，配合去重键；不同通道可以不同强度。
- 续传点：断连或换节点后从哪里继续，要和任务查询能力分开声明。
- 生命周期：通道与任务何时创建、过期、销毁，回收前核对活跃任务与未确认消息。
- 背压：过载时减速而不是崩溃，协议限流信号、客户端重试、网关准入、队列共同参与。
八、协议演进与职责边界
MCP 从会话级常驻推送，走到单端点流式，再到无状态核心 + 应用层显式任务句柄。协议无状态不等于应用无状态：状态责任转移到了应用层的显式句柄，传输续传与应用恢复是两层责任。A2A 则相反，任务本身就是有状态、可长跑的工作单元，状态包含提交、执行中、需要输入、需要授权、完成、失败、取消、拒绝，产物通过 Artifact 关联。两者的方向不同，不是路线优劣：MCP 垂直连接工具，A2A 水平交接任务。编排 Agent 通过 A2A 委派，专业 Agent 通过 MCP 调工具，可以组合。
九、内构面：通道键决定治理粒度
服务端组件之间的通信没有统一协议，关键是选对通道键：
- 会话标识：适合语音等需要保序、响应隔离的场景；
- 用户（或用户×模型）：适合网关限流、资产中心按用户治理；
- 会话 + 环境：适合控制面与执行面的异步交接。
规模化后的典型反模式是“每会话一个标准主题”——元数据先于业务压垮控制面；以及“会话绑死常驻进程”，形成有名字、有状态、不能替换的宠物实例。对应的解法是轻量通道：按业务标识声明通道，挂到少量父主题上，服务端只存字符串键与轻量索引；首次发送自动创建、空闲自动回收、单通道挂起释放线程。
十、手脑分离
四层各司其职：Runtime 决定做什么，MQ 负责把任务稳定送达并承担等待，Worker 只做计算，State 保存事实。任何一层试图兼任另一层，都会在扩容或故障时暴露。
最小上手
yaml
team:
topology: supervisor # supervisor | peer | hierarchical
stop_conditions: {budget: 2h, max_delegation_depth: 3, max_runs: 20, max_rework: 2}
handoff_fields: [goal, known_facts, pending_items, references]
transport:
human: S2
capability: S1
collaboration: S3
internal: {channel_key: session_or_user, persistent: false}验收看四件事：一次任务有多次 Run 时能区分是哪一次失败；子任务提交后必须被 Leader 接受才进下游；取消能沿父子传播；断连后能从续传点补读。
生产动作
- 先把责任写清，再拆角色。团队关系、任务参与、执行责任、审核责任四类关系分开记录。
- 权限按交集算，策略版本随 Run 固化。有效权限 = 人员权限 ∩ 团队边界 ∩ Agent 策略 ∩ 资源策略 ∩ 委托范围，入站权限不自动转成出站权限；每次 Run 记录策略版本，否则复盘时无法判断是策略变了还是执行变了。
- 消息说明“发生了什么”，Task State 与 Artifact 记录“当前事实是什么”。两者不能互相替代。
边界
- 多 Agent 不天然更优。目标单一、上下文集中、严格串行时，单 Agent 更简单。
- 协议接通不等于任务承接。Agent Card 只是发现信息，不能仅凭声明建立可信身份。
- 流式结束不等于任务结束。流只说明结果怎么到达，不说明任务独立于连接。
- 消息重播不恢复进程，也不撤销副作用，重放只是把消息再送一遍；经验也会过期——拓扑、通道键、协议版本都随规模变化，去年的最优解今年可能是瓶颈。
讲清楚
多 Agent 的第一件事不是分工，而是把 Task、Task Run、Session 分清，把提交、接受、完成三层结果语义定死。拓扑按专业分工与协调成本选，不按“高级程度”选；停止条件要在根任务开始前约定，否则系统会以努力的方式失控。
分布式通信先做分层：人机面、能力面、协作面、内构面各有矛盾，S1 到 S4 是谱系不是等级。通信契约要写清标识、顺序、投递保证、续传点、生命周期与背压六件事。
协议只负责连接：MCP 管工具，A2A 管任务交接，二者方向不同可以组合；状态、幂等、授权与恢复仍然由应用和运行时负责。最后把手脑分开——Runtime 决策、队列传递、Worker 计算、State 持久化，任何一层都不兼任。
适用：多 Agent 协作与跨节点任务通信设计 | 初稿 2026-10