第 11 章 · Multi-Agent 协作与编排

核心观点 + 逻辑框架（运行篇 · 团队协作）

原书章节 ↗

▍速览

一句话版（开场，约 20 秒）

多个 Agent 放在一起不会自然形成团队。编排层把共同目标组织成可执行可验收的任务：异构成员经适配接入并保留各自 Harness，三种组织拓扑决定协调与决策关系，Task Run 记录每次执行、结果聚合回到根 Task；共享的是上下文来源而非相同 Context，A2A / MCP / 内部消息分工协作，身份、委托与入站出站权限贯穿交接。团队价值以整体交付和协调成本共同衡量，最终验收由发起人或授权验收者确认。

一段话版（展开，约 60–90 秒）

多个 Agent 放在一起不会自然形成团队——没有清晰的分工、协作方式和状态管理，参与者越多越容易出现重复执行、信息不一致和责任不清。编排层的价值，是把宽泛目标逐步转化为可执行可验收的任务，建立依赖、汇集状态和产物，需要时并行推进、条件满足再进入下一阶段；但它不介入每个执行细节，成员保留自主执行方式，避免一切判断都汇总到主管的单点瓶颈。接入层面，能改应用代码就加协作 SDK，能装插件就用适配程序，只能调远程 API 就在外部做适配，原有 Harness 全部保留；Coding Agent 与本地个人工作区助手各有接入边界。组织上三种拓扑——主管—执行、对等协作、分层编排——不是演进阶段，按专业分工、工作耦合、决策方式和协调成本选择。执行层面，Task 是持续工作约定，Task Run 记录每次实际执行；计划创建顺序不等于执行顺序，依赖决定何时开始；失败时把用例、产物版本和修订要求关联回子任务，旧结果保留为历史事实，后续只对当前有效版本判断；团队级停止条件在根 Task 开始前约定，触及后暂停委派、转人工判断。共享的不是相同 Context，而是统一的上下文来源，每个成员按角色、任务、权限形成自己的局部视图；消息说明"发生了什么"，Task State 和 Artifact 记录"当前事实是什么"。A2A 做 Agent 间任务交接、MCP 连工具与资源、内部消息传播事件——传输成功不等于协作完成。身份上区分主体、凭证与委托，入站权限与出站权限独立校验；观测用根 Task 串联 Task Run 与调用，评估结论与事实记录分开保存。最终交付是否达到业务目标，由发起人或授权验收者依据约定标准确认——"已完成"不是终态，用户取得产物、确认接受并归档后才真正完结。

• 一个编排层：目标→任务/依赖/状态/产物；不介入执行细节、不替代业务验收
• 三种拓扑：主管—执行｜对等协作｜分层编排——按分工·耦合·决策·成本选择
• 两个概念：Task（持续工作约定）≠ Task Run（一次执行记录）
• 一组共享：共享来源不共享 Context；Task State+Artifact 是协作事实
• 两类权限：入站（谁可调用）≠ 出站（代表谁访问什么），独立校验
• 一条验收链：提交≠接受≠完成——用户归档才真正完结

一句话（收尾）

多智能体不是把执行者变多，而是把分工、状态与责任组织清楚——团队的连续性不依赖某个 Agent 始终在线，而依赖可沉淀的组织与任务关系。

▍逻辑框架（记忆卡片）

① 命题：从单 Agent 到 Agent 团队

专业分工 · 并行执行 · 权限控制 · 结果复核

单 Agent 适合范围明确、上下文关联紧密的任务。真实企业任务横跨需求/设计/实现/测试/安全/审批——交给一个 Agent 就要不断切换专业角色、维护越来越多上下文工具权限，可并行的任务被压进单循环，一步阻塞全局停摆。团队价值=不同能力以更合适的方式组合：每个参与者聚焦擅长部分，只获得完成当前工作所需的信息、工具和操作范围。

• 协作收益：专业分工 + 并行 + 故障隔离 + 过程治理
• 协调成本：任务拆分 · 信息传递 · 状态一致 · 额外模型调用与运行开销
• 适用判断：目标单一 / 上下文集中 / 严格串行时单 Agent 更简单有效；收益覆盖成本团队才真正有价值

② 编排层：价值与边界

• 职责：宽泛目标 → 可执行可验收任务；建立依赖；汇集成员状态与产物；并行推进、条件满足再进入下一阶段
• 不介入执行细节：统一目标/分工/约束/验收标准，成员自主选择执行方式
• 避免单点决策：一切信息先汇总到主管=主管成新瓶颈；协调与自主平衡——阻塞 / 冲突 / 资源不足 / 高风险时才协调或人工
• 显式记录协作过程：目标 / 任务 / 依赖 / 状态 / 产物沉淀——成员变化、重启、中断后可恢复，不依赖对话历史

最终交付是否达到业务目标，由任务发起人或授权验收者依据约定标准确认——编排层不自动替代业务验收。

③ 异构接入：保留执行方式 + 适配层

• 左：按可控范围接入 能改应用代码 → 协作 SDK / 任务接口 能装插件 → 插件 + 适配程序 只能远程 API → 外部适配程序

• 右：适配层职责 转接请求与结果 · 记录远端任务编号 把原生进度/等待/结束转换为团队状态 取消、恢复以远端实际能力为准

• 保留原有 Harness：模型/工具/业务流程沿用；指令说明职责、工具给任务入口、长步骤放 Skill；确定性代码/工作流也可以

• Coding Agent：插件装配协作能力，保留原生任务循环；内部子代理仍归当前 Harness，不自动成为团队成员

• 个人工作区：团队任务用个人工具需用户明确选择；权限靠沙箱与权限控制而非目录参数；文件走约定交付通道+可访问引用；本地≠数据留本机

• 请求已经开始返回内容后，后续工具操作仍归属同一任务——进度与成果不得记入其他任务

**任务状态由谁维护要约定；任务写入由任务服务按身份 / 归属 / 状态检查权限。**接入后用实际交接验证五项：任务到达 / 连续交互 / 状态反馈 / 成果交付 / 控制与恢复。

④ 组织拓扑：三种模式

• 左：主管—执行：集中协调，分散执行 适合目标明确、责任集中归口；优势=责任清晰、聚合路径稳定；注意避免局部判断都等 Leader

• 右：对等协作：直接协商，共同决策 适合探索性强、专业相对平等；优势=沟通路径短、局部自治高；注意预先约定分歧处理与最终交付责任

• 分层编排：按专业小组组织交付；适合规模较大、小组可完整交付；优势=降低根 Leader 协调宽度；注意跨层信息损耗与汇报延迟——只有小组能承担完整交付责任时增加层级才有意义

• 选择依据：专业分工 / 工作耦合 / 决策方式 / 协调成本——三种拓扑不是从低级到高级的演进关系

• 团队 vs 成员：Team=稳定组织连续承接任务；专业能力（擅长什么）≠ 组织角色（负责什么）；同一 Agent 可在不同团队承担不同角色

• 四类关系分开记录：团队成员关系 / 任务参与关系 / 执行责任 / 审核责任——加入团队≠参与每项任务；能查看≠负责执行

组织管理身份不替代业务决策与最终验收；人可承担需求澄清 / 专业判断 / 关键决策，不只是 Agent 无法继续时的兜底。

⑤ 协作机制：Task / Task Run / 调度 / 聚合

• Task=持续工作约定（目标/范围/交付物/验收条件/负责人/约束）；Subtask 只在独立交付 / 不同责任 / 明确依赖时拆分

• Task Run=一次实际执行记录；一个 Task 可多个 Run（重试/恢复/重新分派）；Session 与 Run 可关联不一一对应；消息发送成功≠任务被承接

• 计划：创建顺序≠执行顺序，依赖与可用条件决定何时开始；明确测试基于哪个补丁版本；执行者选择=专业能力+可用权限+当前负载

• 调度：按 Task State 判断（负责人/依赖/有效版本）；失败记录阻塞原因，可独立推进的继续；需求变化保留有效进展与版本关系

• 返工：失败用例+产物版本+修订要求关联回子任务；旧结果保留为历史事实，后续验证只对当前有效版本判断

• 团队级停止条件：时间/成本预算 · 最大委派深度 · 派生任务数 · 重试次数 · 返工轮次 · 连续无有效进展——触及后暂停新委派与自动返工，保留结果/阻塞/剩余预算，转人工判断

三层结果语义不互相替代：执行者提交=候选成果产生；Leader 接受=可向下游使用；根 Task 完成=当前有效版本共同覆盖目标。"已完成"不是终态——用户取得产物、确认接受、归档后才真正完结。

⑥ 共享上下文、记忆与协作状态

• 共享的是上下文来源不是相同 Context：统一维护目标/约束/任务状态/已确认事实/产物；每个 Agent 按角色/任务/权限/执行阶段选择——Context 是团队状态在某个成员、某个时刻的局部视图

• 最小充分原则：包含任务所需，避免完整项目历史/无关工具输出/他人全部推理

• Handoff 四类：目标（范围/交付要求）· 已知事实 · 待处理事项 · 可用引用；搜索过程/工具调用记录/未验证推理不原样传递

• 团队记忆：只沉淀经过验证的信息（任务结果/外部数据/其他成员/人工确认）；保留来源与边界、可更新降级淘汰；"什么可成为记忆、谁维护、何时失效"比存储技术重要

• Workspace ≠ Environment：Workspace=工作目录 / 文件 / 分支 / 快照与获准资源引用，可跨运行实例重新挂载延续；Environment=计算 / 网络 / 文件系统 / 凭证映射与隔离条件，随运行实例或部署配置变化

• 左：Task State：推进到哪里——责任/依赖/进度/验收状态，随 Task 持续

• 右：Artifact：产出了什么——报告/代码/数据/测试结果，由业务应用定义

消息说明"发生了什么"，Task State + Artifact 记录"当前事实是什么"——成员通知完成，其他成员仍读任务当前状态；报告生成应经可访问的 Artifact 引用取得，不依赖消息摘要。

⑦ 通信与协议：A2A / MCP / 混合路由

• A2A：能力发现 + 持续任务 + 成果交付统一协议；Agent Card 提供发现信息，不能仅凭声明建立可信身份
• A2A Task / Artifact 需与业务 Task / Artifact 映射——同名不代表生命周期和权威来源相同
• Message 表达客户端与 Agent 之间的一次通信，contextId 关联同一交互上下文中的多个 Message 和 Task；二者仅承担协议交互关联，不替代业务 Task 或 Session 定义，同名不等于业务对象生命周期
• 更新方式：Streaming（连接保持）/ 轮询（稍后查状态）/ Push Notification（不维持连接）——按运行条件组合
• 分工：MCP 连接工具与资源；内部消息传播状态通知；适配层把协议标识映射到业务 Task/Session/Artifact 并保留来源与权限
• 通信模式：Direct/Handoff · Shared Message Space（订阅+角色过滤）· Event-driven/Pub-Sub（处理重复投递/顺序变化/消费恢复）
• 混合路由：语义判断（模型理解任务/候选建议）+ 确定性校验（团队边界/权限/数据范围/可用性/成本/安全）——校验后留痕

**协议接通后仍要验证任务承接 / 产物可读 / 恢复路径——传输成功 ≠ 协作完成。**消息平面与协作状态分离：普通通知不是任务完成依据，接收者查询任务与产物；事件溯源可作权威但需完整事件/顺序/保留/重建契约，不能把消息队列当任务账本。

⑧ 治理与可观测：身份 / 权限 / 追踪

• 身份：人员 / 服务 / Agent / 执行四类主体 + 临时凭证 + 委托授权；凭证不是身份、委托不是身份；审计关联主体+委托+凭证指纹，不记凭证秘密
• 权限：稳定角色（长期职责）+ 动态策略（环境/数据等级/时段/成本/审批/风险）；六层组织——组织/团队/Agent/运行/资源/观测审计
• 有效权限 = 人员权限 ∩ 团队边界 ∩ Agent 策略 ∩ 资源策略 ∩ 委托范围，显式拒绝优先；Agent 交接不扩大权限
• 入站权限（谁可调用、发起什么）≠ 出站权限（代表谁、访问哪些资源）：独立配置分别校验；入站鉴权不自动转化为出站权限；出站按有效委托给临时凭证，不持有用户长期凭证
• 每次 Task Run 固化策略版本；拒绝返回可理解原因；审计形成"谁发起→谁执行→访问了什么"责任链，任一环节失败拒绝执行
• 观测指标五类：运行（成功率 / 端到端耗时 / 排队 / 重试 / 交接 / 阻塞）· 模型 · 工具 · 资源 · 治理事件；日志需脱敏、采样与访问控制；评估分线上发现异常与离线版本回归，评估结论与事实记录分开保存
• 开放协作网络中，能发现和调用某个 Agent ≠ 默认信任其声明；Identity · Delegation · Policy · Data Boundary · Audit 共同决定连接是否可发生

观测回答协作是否有效：责任交接 / 阻塞 / 返工 / 结果接受；根 Task 关联 Task Run 与调用；跨 Trace 用任务标识+产物引用关联，父子 Span vs Span Links 保留真实因果；评估结论与事实记录分开保存，模型判断不是不可质疑的运行事实。

⑨ 小结：组织与责任决定团队连续性

• 团队连续性依赖清晰的组织与任务关系：成员保留不同 Harness 与运行环境，经适配接口承接工作
• 组织拓扑决定协调与决策关系；任务计划表达依赖；结果接受把局部交付连接到共同目标
• 共享上下文/记忆/状态/产物/工作区各有职责；通信传递可关联信息；身份/委托/权限贯穿交接；观测定位阻塞/返工/成本
• 团队规模由实际分工需要决定，协作效果以整体交付和协调成本共同衡量

▍逻辑全景图（总览 · 先读图 1 主线，再看图 2 组合与横切）

图 1 · 团队协作全景：发起人 → 编排层 → 成员层 → 运行连接基础 → 验收归档，治理贯穿全程

• 用户 / 业务验收
• 编排层 / 团队
• 执行 / 运行连接
• 治理 / 观测
• 中性 / 连接

示意 · 按原书图 11-1 重绘并合并正文主线（编排 → 成员 → 运行连接 → 验收闭环）；与下文『书中关键图』不重复

▍逻辑全景图 · 图 2 · 通信与治理横切

MCP / A2A / 内部消息三通道分工 → 混合路由 → 消息平面与协作状态分离 → 审计责任链

示意 · 按正文重构（对应 11.6 通信协议与 11.7 治理观测）

▍书中关键图（SVG 重绘版 · 示意）

原书图 11-1 的总体架构已并入上文『逻辑全景图 · 图 1』，此处不重复；本节保留组织拓扑与协作流程两张关键图。

图 1｜Agent 团队的三种组织拓扑（重绘自原书图 11-2）

维度	主管—执行	对等协作	分层编排
组织结构	Leader 统筹目标 · 依据 · 结果；Worker A / B / C 执行	Agent A / B / C 各持专业能力，共享规则与任务状态	根 Team Leader → 小组 Leader A / 小组 Leader B → 各自 Workers
协调与决策方式	集中协调，分散执行	直接协商，共同决策	按专业小组组织交付
适合场景	目标明确、责任集中归口	探索性强、专业相对平等	规模较大、小组可完整交付
优势	责任清晰、聚合路径稳定	沟通路径短、局部自治高	降低根 Leader 协调宽度
注意事项	避免局部判断都等 Leader	预先约定分歧处理与交付责任	控制跨层信息损耗与汇报延迟

选择依据：专业分工 · 工作耦合 · 决策方式 · 协调成本；三种拓扑不是从低级到高级的演进关系——按实际工作特点选择

示意 · 按原书图 11-2 重绘

图 2｜依赖修复任务的协作与验收流程（重绘自原书图 11-3）

示意 · 按原书图 11-3 重绘