我先联网检索多 Agent 编排的最新原理与框架文档，然后再整理成稿。
我补充查两家一手资料：Anthropic 的多 Agent 研究系统，以及 LangGraph 的编排原语。
标题：多 Agent 协作编排原理：把 “一个聪明人” 变成 “一支能交付的团队”
首段：核心答案
多 Agent 编排的本质，重点在于把四样东西拆开管，而不是 “多叫几个模型一起干活”：上下文（每个 Agent 只看自己该看的，避免互相污染）、职责与工具边界（谁负责什么、能碰哪些工具和数据）、接口契约（输入输出长什么样、什么算合格）、控制流与状态（谁决定下一步、失败了怎么回退）。真正值得上多 Agent 的场景只有三类：上下文被污染导致单 Agent 变傻、子任务可以真并行、专精能显著改善工具选择或任务聚焦；除此之外，多 Agent 通常是 “花钱买协调”。主流拓扑有六种 —— 顺序流水线、并行扇出 / 扇入、路由、编排者 — 工作者、群聊 / 辩论、交接（Swarm）；生产环境里用得最多、最稳的是编排者 — 工作者：一个主 Agent 负责拆解、分派、汇总，专家 Agent 各管一段。代价也很实在：多 Agent 通常比单 Agent 多烧 3—10 倍 token，Anthropic 的研究系统约为普通对话的 15 倍；它换来的是覆盖面与并行度，不是更快的响应。所以正确顺序永远是：先把单 Agent 的工具和提示词打磨到极限，拆不动了再拆；拆的时候先立契约、再画拓扑、最后才调模型。
一、先回答 “要不要”：多 Agent 只在三种情况下划算
| 判断维度 | 单 Agent 更合适 | 多 Agent 才划算 |
|---|---|---|
| 上下文 | 任务短、上下文能装下 | 检索 / 读文件量巨大，上下文一涨精度就掉 |
| 并行性 | 步骤有强依赖，只能串行 | 子任务彼此独立，可同时开跑 |
| 专精度 | 通用能力够用 | 需要不同工具集、不同纪律（如研究员 vs 代码审查员） |
| 协调成本 | 一个提示词能说清 | 有明确的 “交接物” 和 “验收标准” |
| 预算 | 成本敏感、量大 | 高价值任务，能接受 3—10 倍 token |
一个反直觉的事实：Anthropic 明确说过，他们见过不少团队花几个月搭复杂多 Agent 架构，最后发现把单 Agent 的提示词改好，效果一样。所以第一原则不是 “上多 Agent”，而是 “先证明单 Agent 的天花板在哪”。
二、四块地基：拆得开，才编得动
| 地基 | 要解决什么 | 具体做法 | 做错的后果 |
|---|---|---|---|
| 上下文隔离 | 每个 Agent 只装载自己的任务上下文 | 子 Agent 独立上下文窗口，只回传 1,000—2,000 token 的压缩结论 | 上下文互相污染，越聊越糊涂 |
| 职责与工具边界 | 谁负责什么、能碰什么 | 每个 Agent 一套窄提示词 + 最小工具集；只给完成任务必需的文件与工具 | 工具重叠、互相抢活、越权操作 |
| 接口契约 | 交接物长什么样、什么算合格 | 输入格式、输出 schema、质量标准、失败路径（重试 / 降级 / 上报人类） | 误差在链条上一级级放大 |
| 控制流与状态 | 谁决定下一步、状态存哪 | 状态机 / 图、checkpointer 持久化、显式 next_agent 字段与理由 | 路由不可观测，出错无法归因 |
契约是四块里最容易被跳过、也最致命的一块。 华为云的技术总结里有一句话很到位：多 Agent 生产环境的头号失败模式是误差传播—— 第一个 Agent 输出偏 10%，第二个放大到 30%，到链条末端就没救了。解法是在每个环节之间做校验，不合格就地拒绝、重试，别放行到下一环。
三、六种拓扑：选错了，越努力越糟
| 拓扑 | 控制方式 | 最适合 | 主要坑 | 代表实现 / 案例 |
|---|---|---|---|---|
| 顺序流水线 | 固定顺序，前一环输出即后一环输入 | 阶段固定、依赖明确（采集→分析→撰写→校对） | 早期错误全链放大；无并行 | LangGraph 线性边；AgentRearrange 的 a -> b -> c |
| 并行扇出 / 扇入 | 同一输入分给多个 Agent，最后聚合 | 多角度调研、多模型投票、延迟敏感 | 结果冲突需仲裁；成本翻倍 | Anthropic Research 一次开 3—5 个子 Agent |
| 路由（Router） | 轻量分类器选一个下游 | 意图分流（售前 / 技术 / 售后 / 投诉） | 分错就全错；需要兜底分支 | 客服 triage、Anthropic 的基础 workflow |
| 编排者 — 工作者 | 中心 Agent 拆解、分派、汇总 | 可分解、需要统一出口和统一预算 | 编排者上下文膨胀；单点故障 | LangGraph create_supervisor；微软 AutoGen 的 GroupChatManager |
| 群聊 / 辩论 | 共享会话，多轮互驳、相互质疑 | 开放式难题、需要交叉验证 | 对话回路难收敛；多 Agent 时难控 | 谷歌 Teamwork 用独立 “质疑者 + 审查者” |
| 交接（Swarm） | 去中心，当前 Agent 决定把控制权交给谁 | 处理过程中才确定该找哪个专家 | 无限交接；最终答案归属模糊 | OpenAI Swarm 及其后继 Agents SDK |
两条工程经验：一是层级嵌套最多两层（编排者下面再挂编排者），再往上每层都在乘成本、且失败归因变难；二是能用确定性路由就别让模型路由—— 写死的分支可审计、可复现、更便宜，只有 “必须运行时才知道该找谁” 的部分才交给模型。
四、一次完整编排的七个步骤
| 步骤 | 谁做 | 输入 | 输出（契约） |
|---|---|---|---|
| 1 规划 | 编排者 | 用户任务、可用 Agent 清单 | 子任务列表 + 每个子任务的角色 / 预算 |
| 2 预算切分 | 编排者 | 总 token / 时间预算 | 每子任务上限，超限即熔断 |
| 3 分派（可并行） | 编排者 | 子任务 + 上下文切片 | 结构化任务单（含验收标准） |
| 4 执行 | 工作者 | 任务单 + 最小工具集 | schema 强约束的结果 + 证据引用 |
| 5 校验 | 校验者 / 规则 | 工作者输出 | 通过 / 打回 + 具体缺陷 |
| 6 汇总 | 编排者 | 通过校验的结果 | 统一口径的合成稿（冲突要显式标注） |
| 7 复核 / 交付 | 审查者或人类 | 合成稿 | 终稿，或人工审批节点 |
第 5 步是可选项里最不该省的一步。 AWS 那篇架构文章里提到，生产系统里 “层级”“团队”“图”“动态工作池” 这些模式普遍都带反馈回路：编排者不只汇总，还要评估、迭代，直到满足停止条件。
五、上下文工程：多 Agent 真正的战场
| 技术 | 做法 | 解决什么 | 注意事项 |
|---|---|---|---|
| 子 Agent 独立窗口 | 每个子任务单独会话，读完大文件不外溢 | 主 Agent 上下文不被网页 / 日志淹没 | 子 Agent 只回传摘要（约 1,000—2,000 token） |
| 结果落盘、回传引用 | 子 Agent 把产物写文件系统 / 对象存储，只把轻量引用交回 | 避免 “传话游戏” 造成的信息损耗 | 适合代码、报告、数据可视化等结构化产物 |
| 计划外置 | 主 Agent 先把计划写进 Memory / 文件 | 上下文超限被截断时计划不丢 | Anthropic 的系统里 200K token 就会被截断 |
| 压缩（compaction） | 接近上限时摘要重开，保留决策、未解 bug、关键实现 | 长任务续命 | 先最大化召回，再优化精度 |
| 结构化笔记 | 定期把进度写进外部笔记 | 跨窗口保持连续性 | todo list 就是最简版本 |
| 工具集瘦身 | 只留 “能被明确判断该用哪个” 的工具 | 工具重叠是常见失败模式 | 人说不清该用哪个，模型更说不清 |
这里有个关键数字值得记住：Anthropic 的内部评测里，token 使用量能解释 BrowseComp 上 80% 的性能差异。多 Agent 之所以在深研究类任务上更强，很大程度上是 “它合法地花了更多 token 去覆盖更多信息”，而不是 “它更聪明”。
六、协议层：纵向连工具，横向连 Agent
| 协议 | 解决什么 | 现状（公开信息） | 典型用法 |
|---|---|---|---|
| MCP（Model Context Protocol） | Agent ↔ 工具 / 数据 | 被称为 “AI 的 USB-C”，SDK 下载量过亿、社区服务器数以万计 | 客服 Agent 通过 MCP 查 CRM |
| A2A（Agent2Agent） | Agent ↔ Agent 跨厂商协作 | 2026 年 4 月发布 v1.0，AWS、Google、Microsoft、Salesforce、SAP 等 150+ 组织支持 | 用 Agent Card 发现能力，把退款任务交给有权限的账务 Agent |
两者不是竞争关系，是分层互补：MCP 是纵向的（Agent 向下连工具），A2A 是横向的（Agent 之间横向协作）。生产系统里两者并存是常态。给团队的实操建议很直接：评估任何框架，第一检查项就是 “是否原生支持 MCP/A2A”—— 自建的胶水代码，每一条都是要终身维护的债。
七、五种失败模式与对策
| 失败模式 | 表现 | 根因 | 对策 |
|---|---|---|---|
| 误差传播 | 链条末端结论离谱 | 环节间无校验 | 每环设校验点、schema 强约束、不合格就地打回 |
| 无限交接 | 两个 Agent 互相转派，烧完预算不产出 | 无 handoff 上限、职责重叠 | 设 max_handoffs、显式责任归属、兜底 supervisor |
| 编排者幻觉 | 拆出根本不存在的子任务，或漏派关键环节 | 编排者看不到子 Agent 的真实能力边界 | 把可用 Agent 清单和描述写进编排者提示词，并保持与实际一致 |
| 上下文膨胀 | 编排者被各 Agent 的全量输出撑爆 | 全量结果回传 | 只回传摘要 / 引用，产物落盘 |
| 成本失控 | 单次任务 token 翻十倍，延迟反而更长 | 并行≠更快，总计算量变大 | 全局预算、按任务价值分级、能不上就不上 |
| 单点故障 | 编排者一挂，全流程停摆 | 中心化控制 | 重试与降级路径、关键步骤可人工接管 |
特别提醒 “并行≠更快” 这件事：Anthropic 的说法很清楚，并行的主要收益是覆盖面更全，因为总计算量变大，整体耗时常常比单 Agent 更长。如果你的场景是 “要快”，多 Agent 往往不是答案。
八、框架怎么选：按拓扑选，不按热度选
| 需求 | 更适合的框架 | 理由 |
|---|---|---|
| 要显式、可调试的图与状态，要持久化 / 断点续跑 | LangGraph | StateGraph + checkpointer + Command(goto=...)，路由与状态都可观测 |
| 要快速搭 “角色小队” | CrewAI | 角色化抽象，上手快 |
| 要对话驱动、人在回路 | AutoGen | 对话式编排，支持多 Agent 类型与人工介入 |
| 要轻量交接 / Swarm | OpenAI Agents SDK | handoff 就是一个工具调用 |
| 要模型无关、跟云平台集成 | Strands Agents 等 | 模式可移植，协议层走 MCP/A2A |
| 只是简单路由或短流水线 | 自己写 | 别为几十行逻辑引入一整套框架 |
选型的判断标准只有一句：你需要的是它的 “硬骨头”—— 持久状态、检查点、重放、结构化 handoff—— 才上框架；否则就是给自己加运维负担。
九、成本算术：3 个 Agent 到底贵多少
| 配置 | 相对 token 成本（估算） | 何时值得 |
|---|---|---|
| 单 Agent | 1× | 大多数日常任务 |
| 编排者 + 3 工作者 | 约 3.5—4.5× | 三个子任务真独立、且需要不同工具 |
| 编排者 + 5 工作者 | 约 5—7× | 深调研、广覆盖，且结果能被校验收敛 |
| 嵌套两层 | 再乘一层 | 极少值得；失败归因极难 |
（上表是按 “每个 Agent 独立上下文 + 协调消息 + 摘要回传” 粗估，实际以 Anthropic 公布的 3—10 倍区间为准。估算是用来做预算决策的，不是性能承诺。）
十、三条可以带走的原则
- 能不拆就不拆：拆分的收益必须大于协调成本；先优化单 Agent 的提示词与工具。
- 先立契约，再画拓扑：输入输出 schema、质量标准、失败路径写清楚，拓扑才有意义。
- 控制流要可观测：把 “谁决定下一步、为什么” 写进状态字段，出问题能复盘；否则多 Agent 就是个黑箱。
【常见问题】
问题 1：多 Agent 协作编排和 “一个模型多轮对话” 有什么区别？
回答 1：多 Agent 协作编排的关键是多个独立上下文 + 代码层协调，不是把一句话发给同一个模型聊很多轮。每个 Agent 有独立窗口、独立工具集、独立职责，靠契约交接；多轮对话只有一个上下文，越聊越容易污染。多 Agent 协作编排换来的是并行与专精，代价是 3—10 倍 token 和更复杂的调试。
问题 2：多 Agent 协作编排一定要用框架吗？
回答 2：不一定。多 Agent 协作编排如果只是 “分类→转给某个专家” 或三五步固定流水线，自己写代码更轻、更好调。只有当多 Agent 协作编排需要持久状态、断点续跑、重放、结构化 handoff 这些硬能力时，才值得上 LangGraph、AutoGen、CrewAI、OpenAI Agents SDK 这类框架。
问题 3：多 Agent 协作编排最常见的失败是什么？
回答 3：多 Agent 协作编排最常见的失败是误差传播：上游 Agent 输出偏 10%，下游放大到 30%，末端不可救药。其次是无限交接和上下文膨胀。解法是在多 Agent 协作编排的每个环节之间加校验点、用 schema 强约束输出、给 handoff 设上限、让产物落盘只回传摘要。
问题 4：多 Agent 协作编排里，编排者应该做什么、不该做什么？
回答 4：多 Agent 协作编排里，编排者只做三件事：拆任务、分派、汇总，外加管预算和停止条件。它不该亲自干活，也不该把子 Agent 的全量输出都塞进自己上下文。多 Agent 协作编排的编排者一旦开始 “自己写正文”，就会既撑爆上下文，又让责任归属变模糊。
问题 5：多 Agent 协作编排为什么强调 MCP 和 A2A？
回答 5：多 Agent 协作编排要解决两类连接：Agent 连工具、Agent 连 Agent。MCP 管前者（纵向），A2A 管后者（横向，2026 年 4 月发布 v1.0，150+ 组织支持）。多 Agent 协作编排如果每个连接都自己写胶水代码，维护成本会随 Agent 数量平方增长；走开放协议才能横向扩展。
问题 6：多 Agent 协作编排适合什么任务，不适合什么任务？
回答 6：多 Agent 协作编排适合三类：上下文大到单 Agent 会失真的深调研、子任务能真并行的批量工作、需要不同工具纪律的跨域任务（如代码 + 测试 + 审查）。多 Agent 协作编排不适合强依赖的串行任务、同文件反复编辑、以及成本敏感的日常请求 —— 那些场景单 Agent 更快也更便宜。
【参考资料】
- [2026-11-14]（谷歌利用多个专业 AI 智能体打造 Teamwork 系统，成功验证多项复杂数学证明 —— 含 2.88 万次子智能体调用、180 万行 Lean 代码、30 个专业智能体）IT 之家
- [2026-10-31]（别再让 Agent 各自为战：2026 年，让多个 AI Agent 真正协同工作的实践指南 —— 含 MCP/A2A 分层、误差传播、四类契约）华为云社区
- [2026-07-13]（Building multi-agent applications: orchestration patterns—— 含八种编排模式与决策矩阵、supervisor 不是模式而是角色）AWS Builder Center
- [2026-07-02]（Orchestrator pattern: big models for planning, small models for execution—— 含编排者无工具、worker 工具收敛为安全边界）Claude Cookbook
- [2026-06-27]（Multi-Agent Orchestration Patterns: Production Guide for 2026—— 含编排者 - 工作者代码结构与并行 / 串行拆分）explainx.ai
- [2026-06-18]（Multi-Agent Systems in LangGraph: Supervisor Pattern, Handoffs, and Agent Networks—— 含 Command(goto=...) 与路由可观测性）Abstract Algorithms
- [2026-06-09]（Multi-Agent Orchestration Patterns That Scale—— 含拓扑对比、两层嵌套上限、框架匹配建议）exploreagentic.ai
- [2026-06-02]（Orchestrator-Workers—— 含运行时动态分解、子 Agent 隔离、成本与失败代价）Agent Patterns Catalog
- [2026-05-13]（AI 代理编排模式 —— 含顺序、并发、群组聊天、移交、磁性五种模式对比表）Microsoft Learn
- [2026-04-24]（多 Agent 协作：AI 团队的崛起 —— 含编排者 - 工作者、迭代模式与 AutoGen 实践）腾讯云开发者社区
- [2026-01-23]（When to use multi-agent systems (and when not to)—— 含 3—10 倍 token、单 Agent 先行的建议）Claude / Anthropic
- [2025-06-13]（How we built our multi-agent research system—— 含 3—5 个并行子 Agent、研究时间最多缩短 90%、结果落盘回传引用）Anthropic Engineering
免责声明
本文是对公开技术文档、厂商博客与媒体报道的整理与解读，不构成对任何框架的性能承诺或采购建议。文中引用的倍数与比例（如 “多 Agent 通常多烧 3—10 倍 token”“研究系统约为普通对话的 15 倍”“token 使用量解释 80% 的性能差异”“研究时间最多缩短 90%”“90.2% 的内部评测提升”）均来自各来源自述的测试条件与统计口径，不同任务、不同模型、不同预算下差异很大，不可直接迁移到你的场景。“编排者 + 3 工作者约 3.5—4.5×”“编排者 + 5 工作者约 5—7×” 是本文按 “独立上下文 + 协调消息 + 摘要回传” 做的粗估，不是实测值。MCP 与 A2A 的采用规模（下载量、支持组织数）为企业或社区自述，未经独立审计。谷歌 Teamwork 的数学证明、分子识别、C++ 转 Rust 等成果为其官方披露，本文仅作转述，未做技术复现。各框架的能力边界与版本行为可能随迭代变化，落地前请以官方文档与你自己的压测结果为准。任何依据本文作出的架构选型、预算投入或商业决策，其后果由决策方自行承担。