Multi-agent 协同

0. multi-agent 不是"更强",是一个 trade-off

先纠正一个直觉。#1 Ch4 教过 Subagent、Multi-Agent、Orchestrator-Worker 这些词,它们听起来像是"把 agent 做强的进阶手段",好像多几个 agent 一起干总比一个强。这一章的整个脊柱,就是要纠正这个直觉:multi-agent 不是免费的午餐,是一个有明确收益和代价的架构选择。它用 token 成本爆炸、协同复杂度、上下文碎片化的风险,去换并行吞吐、突破单个上下文窗口、关注点隔离。值不值,完全取决于你的任务长什么样。

这条 thesis 之所以是脊柱,是因为 2025 年有两家顶级工程团队,对"该不该上多 agent"给出了几乎相反的公开结论,而两边都对,只是适用的任务不同。这一章不站队,而是诚实地把这场分歧摆出来,再给你一个框架判断自己落在哪一边。它也精确咬合 #1 Ch4 认知弧的第四条:曾以为 multi-agent 总更好,后来被 subagent 的上下文丢失和协同成本证伪,于是转向选择性使用。这就是它的 why-now,2025 年那场公开辩论,正是这个认知被纠正的时刻。它还和 Anthropic 那条简单性原则同源:从简单的提示开始,只在简单方案不够时才加多步 agent 系统。multi-agent 是这条原则最极端的检验场。

1. 核心张力:何时有用,何时有害

这一节是全章的灵魂。把两份一手公开文当作一场诚实的工程辩论来读,你会比记住任何拓扑都更受用。

1.1 PRO 侧:Anthropic 的多 agent 研究系统

Anthropic 公开了他们怎么搭一个多 agent 研究系统。架构是 orchestrator-worker:一个 lead agent 分析查询、定策略,然后并行 spawn 多个 subagent,每个用搜索工具独立探索一个子方向,返回发现,lead 再综合、决定要不要继续研究。这是一个中心化协调的模型。收益数字很亮眼(注意都是发布时点值、内部评测):这个多 agent 系统在内部研究评测上比单 agent 高了约 90%;代价是 token,agent 比聊天多用约 4 倍 token,多 agent 比聊天多用约 15 倍。还有一个极有教学价值的数字:在一个浏览检索任务上,单是 token 用量就解释了约 80% 的成绩方差。这句话本身就是多 agent"为什么贵但有时值"的量化锚:并行多 agent 等于投入更多 token,在 token 起决定作用的任务上,买到了更高的分。

但 Anthropic 自己很诚实地划了 sweet spot。值的场景是广度优先、能拆成多个互相独立子方向、而且任务价值高到付得起 15 倍 token 的任务。不值的场景,是需要所有 agent 共享同一份上下文、或者 agent 之间依赖很多的任务,而且他们明说,大多数编码任务里真正可并行的子任务,远比研究任务少;再加一句,目前的 agent 还不太擅长实时地互相协调和委派。最后这句话,几乎就是下一节那场反方论点的预告。

1.2 CON 侧:Cognition 的"别造多 agent"

做 Devin 的 Cognition 团队,2025 年发了一篇针锋相对的文章,标题就叫"别造多 agent"。它建立在两条原则上。第一,要共享上下文,而且要共享完整的 agent 轨迹,不只是单条消息。第二,每个动作都隐含着决策,当并行的 agent 基于各自没明说的假设做出冲突的决策,最终结果就会崩。它有一个招牌反例:让两个 subagent 并行做一个 Flappy Bird,一个误解了任务做成了马里奥风格的背景,另一个做的鸟和游戏美术不匹配,最终 agent 面对两个根本不一致的产出,无法调和。根因是,subagent 并行时看不到彼此的工作,各自从上游没约定好的冲突假设出发。

Cognition 还批判了"让 agent 互相对话来协同"这条路,认为它不可靠,因为今天的 agent 还做不到那种长上下文、主动的对话协同,可靠性并不比单个 agent 高。核心病灶是,决策太分散,上下文没法在 agent 之间充分共享。所以它推荐的替代方案是:首选单线程线性 agent,让上下文全程连续不碎;任务太长时,引入一个专门的模型,把动作和对话历史压缩成关键的细节、事件、决策,而不是切成多个独立 agent。注意,这其实正是 Ch6 的上下文压缩和 Ch7 的 memory,Cognition 把它当作多 agent 的替代品。

1.3 两边都对:一个决策框架

把这场分歧归约成两根轴,矛盾就消解了:任务的可拆性(子任务有多独立),乘以共享上下文的需求。

读多写少、子任务互相独立、信息超过单个窗口、任务价值高,倾向多 agent,这是 Anthropic 的域,典型是广度优先的研究;因为子任务独立,冲突决策的风险低,并行就纯赚吞吐。写得重、子任务互相依赖、需要全程一致的设计决策(比如写代码),倾向单线程线性,这是 Cognition 的域;因为一致性比吞吐重要,并行会让冲突假设无法调和。中间地带,可以用 orchestrator-worker,但要严格约束 subagent 的边界、在上游就把共享假设定死,Anthropic 的委派提示工程(第 3.2 节)做的正是这件事。

这里有三条横切的素养。第一,多 agent 的第一成本不是钱,是上下文碎片化。Cognition 的洞见比"贵"更深:并行让决策分散、轨迹不共享,于是 agent 各自基于不同假设行动,结果不一致。token 贵是表象,决策一致性丢失才是本质。第二,研究类任务和编码类任务恰好分居两端,这解释了为什么深度研究是多 agent 的招牌案例,而 Devin 团队反对在编码里堆多 agent,同一个技术,workload 决定成败。第三,让前沿模型自己在运行时决定何时委派,正在成为新的默认,与其人手把任务切成固定的多 agent 拓扑,不如给一个强模型一个 subagent 工具、让它运行时决定开不开、开几个,这是 2026 年的思潮转向。

2. 拓扑阶梯

2.1 从一个到一群

守着简单性原则,看拓扑的正确次序是从"单 agent 够不够"问起,每升一级先证明上一级不够。从简到繁有六级。单 agent 加工具是默认起点,绝大多数任务够用。Pipeline 顺序是固定的流水线(研究到起草到评审到发布),适合任务能静态分解成固定阶段,它其实是 workflow 不是 agent。Orchestrator-worker 是中心 lead 动态派活、聚合结果,适合子任务运行时才知道、可并行、需要中心综合,Anthropic 的研究系统就是它。去中心 handoff(也叫 swarm)是任意 agent 把控制权移交给另一个专长 agent,适合任务能按专长分段、流程像专家接力(客服里从分诊到账单到技术)。Network 对话是多个 agent 在一个群聊里多方对话,适合需要多方讨论或协商、且能容忍 token 膨胀。Debate 辩论是多个 agent 多轮辩论后收敛到共识,适合数学和策略推理、用 token 换准确率和抗幻觉。

2.2 第一分水岭:中心化还是去中心化

六种拓扑里最重要的一刀,是中心化和去中心化的分界,它恰好对应上一节那两个案例。中心化的 orchestrator-worker,lead 持有全局视图,worker 只看见自己被派的子任务;好处是 lead 能保证子任务边界不重叠、能综合,坏处是 lead 是瓶颈、worker 之间互不可见,这正是 Cognition 批的并行碎片化。去中心的 handoff,控制权像接力棒在 agent 间传,当前持棒的 agent 拥有完整的对话历史,因为 handoff 转移的是整个会话,所以天然不碎(只要协议把上下文带全);好处是没有中心瓶颈、上下文连续,坏处是没有全局协调者,难做"同时探五个方向"的并行广度。

Anthropic 的中心化(并行、会碎)和 OpenAI 的去中心 handoff(连续、串行),恰好是上一节那个张力在拓扑层的两个解:并行吞吐和上下文连续,你只能侧重一个。

2.3 框架的押注

主流框架各自把"协调"建模成了不同的抽象,这本身是一张有用的工程坐标(竞品对比数字需打折,框架状态会变)。

引用 Swarm 时务必标"教学用",它官方明示是实验性的、非生产,只是教 handoff 心智模型的最小实现。

3. 协同六机制

把协同展开成六个机制面,每一面都有清晰的选择。

第一,handoff 协议:控制权移交时到底传什么状态。去中心拓扑的核心原语,OpenAI 给了最干净的契约:handoff 就是一个返回"另一个 agent"的函数,调用即把控制权连同当前完整对话历史移交给目标 agent。设计维度是传多少:传全量历史,上下文连续但 token 累积;只传过滤后的相关片段,省 token 但有丢决策上下文的风险;或者传一个结构化的"任务交接单"(目标加约束加输出格式)。要记住,handoff 不是换个提示继续,而是一次状态转移决策,传太多等于贵加噪声,传太少等于丢一致性。

第二,context-sharing:full、summary、还是 none。中心化拓扑里,lead 给 worker 多少上下文、worker 还回多少,是决定成败的旋钮。Anthropic 的委派工程是一手范本:派活时每个 subagent 必须拿到一个目标、一个输出格式、用什么工具和来源的指引、以及清晰的任务边界,含糊的"研究一下芯片短缺"会让多个 subagent 重复劳动,细化任务描述才能消除重叠。这正是工程化地补 Cognition 指出的那个洞:把假设在派活时就定死。它还把"开几个 agent"写进提示里的显式预算(简单事实查找一个 agent,直接对比两到四个,复杂研究十个以上且职责清晰),呼应 Ch2 的预算。worker 还结果时,把发现压成精炼摘要再返回,而不是回灌原始轨迹。三档共享:full 最一致但最贵最易超窗,summary 是 Anthropic 默认的平衡,none 完全隔离最省但最易碎,只适合真正独立的子任务。

第三,subagent 的上下文隔离,既是扩容手段也是碎片化根源。正面看,每个 subagent 有独立的上下文窗口,整个系统就能处理远超单窗口的信息量,这是 Ch6 讲的隔离作为一种 context 策略 的直接实例。负面看,独立窗口等于 subagent 互相看不见,正是 Cognition 的并行不一致根源。这一章只取这个张力面:隔离同时是多 agent 最大的收益(扩容)和最大的代价(碎片化),压缩和隔离的机制深挖归 Ch6,跨会话 memory 归 Ch7。

第四,状态、同步与失败,这些全是 Ch2 的 durable execution 在多 agent 语境下的放大。Anthropic 诚实列了几块硬骨头:当前 lead 同步执行 subagent,等一批做完才继续,后果是 lead 没法实时引导 subagent、subagent 之间也没法协调,这是多 agent 协同当前的一堵墙(Ch12 外推素材);异步能让 agent 并发、动态新建,但带来结果协调、状态一致性、错误传播三重复杂度。失败恢复上,长跑的多 agent 出错时不能从头重启(又贵又烦),要能从出错点恢复(连 Ch2 的检查点)。lead 还要把计划存进 memory,以防上下文超限被截断。部署上用彩虹部署,新旧版本同时跑、流量渐迁,避免杀掉在飞的 agent。

第五,冲突解决与结果聚合:确定性还是 LLM 合并。当多个 agent 的产出要合并,有两条路。确定性聚合用程序规则合并(多数投票、schema 校验后拼接、去重),可靠、可审计、便宜,但只适合结构化、可机械比对的产出。LLM 合并是让一个 agent(通常是 lead)读所有产出、在语义层综合成一份连贯结果(Anthropic 的 lead 综合就是这个),能调和语义冲突,但贵、可能引入新错误,而且碰上根本不一致的产出会失败(Flappy Bird 那个例子,最终 agent 无法合并两个不一致的产出,说明 LLM 合并不是万能,上游一致性才是前提)。所以冲突解决的根治在上游:与其下游合并冲突,不如上游就不产生冲突,把共享假设在派活时定死,或者干脆单线程。Debate 拓扑则反过来,故意制造分歧再投票收敛,用冲突本身提纯答案。

4. Planner/Executor 与模型混搭降本

一个很流行的省钱想法是把 agent 拆成 planner 和 executor:强模型当 planner,把大任务分解成多步计划;便宜的弱模型当 executor,执行单步、调工具。省钱的逻辑是,对比标准的 ReAct(每次调完工具都要大模型再推理一遍),planner-executor 把重复的执行交给便宜模型,大模型只在规划和生成最终回复时才被调用,于是每事务的平均成本降下来。它有几个设计陷阱:计划太粗,executor 会缺指引而失败(弱 executor 尤其危险,粗分解会让它幻觉);计划太细,token 膨胀加延迟;必须设一个重新规划的次数上限,否则遇到无解的错误会无限循环烧钱(连 Ch2 的终止与预算);而且环境多变时它会崩,固定的计划只适合能在上游分解的可预测任务。

但这一章的脊柱说过,多 agent 不是免费午餐,模型混搭的省钱承诺也得诚实对待。2026 年有一份动手实测直接挑战了流行叙事("我用强模型规划、便宜模型执行来省钱"):三轮实验的结论是,在一个成熟的 harness 里,强前沿 planner 加便宜 executor 在质量上输给了单用一个前沿模型,而且没有任何混搭组合在同等质量下更便宜。唯一的例外是当你被锁在某个特定生态里时,混搭能降成本但要掉几分质量。作者的总建议正好回扣前面那条横切洞见:让前沿模型自己决定何时委派,比人手固定的模型混搭拓扑更好。这份实测是单一作者的动手 benchmark、和 workload 与时点强相关,要按你自己的场景复核;但它的方向和整章的诚实基调一致。这里也要诚实标注一句:坊间常引"某家用 planner-executor 降本数倍"的具体倍数,但不少出自闭源 harness、没有可核的一手出处,模型混搭能降本是公开的方向,但别轻信某个写死的倍数。

5. A2A:跨边界的 agent 互联

前面讲的协同都发生在一个进程、一套框架内。但当你的 agent 要和另一个框架、另一个组织、另一朵云上的 agent 协作时,进程内的拓扑就不够了,需要一个线上的、标准化的 agent 对 agent 协议,这就是 A2A。Ch3 已经给过它在协议栈里的坐标,一句话区分:MCP 是 agent 连工具和上下文(用能力),A2A 是 agent 连 agent(作为对等方协作)。官方的分层类比很贴切:HTTP 没有取代 TCP,它跑在 TCP 之上,A2A 也不取代 MCP,参考架构是 A2A 做 agent 协调加 MCP 做工具接入。

A2A 解决的是"跨边界 handoff"的几个具体问题。发现:每个 A2A agent 在一个固定路径发布一张 Agent Card(JSON,声明名字、能力、输入输出类型、鉴权要求),像 agent 版的名片或 OpenAPI spec,这正是去中心 handoff 在跨组织场景缺的那块,进程内 handoff 靠代码硬连,A2A 靠 Agent Card 动态发现一个你不拥有的 agent。不透明:agent 协作时不暴露内部的 memory、逻辑、工具,对跨组织关键(你的供应链 agent 能和供应商的 agent 谈价下单,无需任一方暴露内部状态)。任务隔离:被委派的任务在接收方的上下文内运行,不隐含访问调用方的数据和工具,所以跨组织时反而要少共享、靠结构化任务而不是裸轨迹。跨组织信任靠内建的 OAuth 和签名的 Agent Card 防伪造。什么时候需要 A2A?单组织单框架内的多 agent,进程内 handoff 就够,A2A 是过度工程;跨框架、跨组织、跨云时才需要它。2026 年它已是 1.0 版、有上百个组织在生产里用、进了 Linux Foundation;但要诚实标注,A2A 和 MCP 本质都是传输层(搬任务和上下文),不创造治理化一致的上下文,跨组织的去中心身份还没生产就绪,是路线图不是现实。一句话,A2A 就是 第 2.2 节 那个去中心 handoff 的跨边界标准化版。

6. eval 钩子:跨 agent 的轨迹

多 agent 难评,但"怎么评"的全套(judge 工程、benchmark 全景、judge 可靠性)归下一章 Ch9。这一章只立一个钩子:多 agent 把评测的基本单位,从"单个 agent 的轨迹"变成了"跨多个 agent 的轨迹"。一次多 agent 运行的轨迹横跨 lead 加 N 个 subagent、加上可能的 handoff 链,失败可能发生在任何一个 agent、或者它们的交接处(handoff 丢了上下文、派活假设冲突),归因比单 agent 难一个量级,这连向 Ch10 的失败模式。Anthropic 给过一个一手的评测配方(Ch9 会展开):用 LLM 当裁判加一套评分量规(事实准确性、引用准确性、完整性、来源质量、工具效率),单次调用、单个提示、输出一个分数加通过或不通过最一致,先用约二十个查询的小样本抓大效应,再用人工测试去抓自动评测漏掉的(幻觉、来源选择偏差)。但 judge 的偏见、校准、家族多样性这些全套工程归 Ch9,这一章只把"跨 agent 轨迹是新的评测单位"这一句立住。

综合 · 第三站收官:让 agent 扛住长任务

回头看这一章,也回头看整个第三站。这一章你接受了一个被两家顶级团队用相反结论检验过的判断:多 agent 不是更强,是一个 trade-off,用 token 和碎片化风险换并行和扩容,值不值取决于任务的可拆性和共享上下文需求。你拿到了从单 agent 到六种拓扑的阶梯,知道了中心化和去中心化是第一分水岭、恰好是那个张力的两个解。你把协同展开成了六个机制(交接传什么状态、共享多少上下文、隔离的双刃、同步与失败、冲突与聚合),理解了冲突的根治在上游。你看了模型混搭省钱承诺为什么常常兑现不了,以及 A2A 怎么把进程内的 handoff 推广到跨组织。

把这一章接到前面,第三站就完整了。第三站要解决的是"让 agent 扛住长任务":Ch6 给了它管理工作记忆的能力(context engineering),Ch7 给了它跨会话的记忆、技能和自我改进,Ch8 给了它在一个 agent 扛不动时调动一群 agent 的判断力。你那台 harness 现在不只是能跑、安全、抗劫持,它还能在长程、大信息量、需要分工的任务里站住脚。

但有一件事,我们从第二站到现在一直在用、却还没正面讲透:你怎么知道这台 harness 到底跑得好不好?前面每一章都在依赖"评测信号"(Ch5 的对抗 eval、Ch7 的自我改进闭环消费的反馈、这一章的跨 agent 轨迹),但"怎么造一个可靠的评测信号"本身,是一门独立的、而且出乎意料地难的工程。这正是第四站(运维)的开篇主题。合上书,去想一个问题:你给前几章那个 agent 接一个会读多个网页的研究任务,先用单 agent 跑,再用 orchestrator-worker 并行三个 subagent 跑,对比一下质量、token、和耗时;然后挑一个写代码的任务,试着并行两个 subagent 分别写两个模块,看它们的接口假设会不会对不上。带着"workload 决定成败"这把尺子,进 Ch9。

本章关键术语

下面按本章顺序复习。加粗是术语,后面是一句话解释;带链接的词可点进术语表看更完整的解释。

核心张力与拓扑

• multi-agent trade-off 多 agent 不是更强,是用 token + 碎片化风险换并行吞吐 + 扩容;决策框架=可拆性 × 共享上下文需求;Anthropic(+90%/15× token,研究)与 Cognition(单线程,编码)两边都对,workload 决定
• 拓扑阶梯(topology ladder) 单 agent → pipeline → orchestrator-worker → 去中心 handoff → network 对话 → debate;每升一级先证明上一级不够
• Orchestrator-Worker 中心 lead 派活 + 聚合,能并行广度但 worker 互不可见 → 碎片化;靠委派工程补洞
• Handoff 去中心:控制权像接力棒在 agent 间传,带走整个对话历史 → context 连续不碎,但难做并行广度
• 上下文碎片化(context fragmentation) 多 agent 的第一成本(比钱更深):并行让决策分散、轨迹不共享 → 各自基于冲突假设行动 → 结果不一致
• Debate 辩论 多 agent 多轮辩论投票收敛;故意制造分歧再聚合,用冲突提纯推理、抗幻觉

协同与降本

• 委派工程(delegation) 派活给 subagent 必须给:目标 + 输出格式 + 工具指引 + 清晰边界;effort-scaling 把"开几个 agent"写进预算;在上游定死共享假设防冲突
• 结果聚合(result aggregation) 确定性合并(投票/schema/去重,可靠便宜)vs LLM 合并(语义综合,能调和但贵、碰根本不一致会失败);根治在上游
• Planner / Executor 强模型规划 + 便宜模型执行;省钱逻辑成立但实测常兑现不了(成熟 harness 里单前沿模型常胜混搭)→ 让模型自己决定何时委派
• 模型混搭(model mixing) 不同模型分工降本;方向公开但具体倍数多无一手出处,别轻信写死的数字
• A2A · Agent2Agent agent↔agent 跨边界协议(对照 MCP 的 agent↔工具);Agent Card 发现 + 不透明 + 任务隔离;= 去中心 handoff 的跨组织标准化版(Ch3 给栈坐标)

进阶词汇(trajectory eval / judge 工程 / 失败归因等)归后续章节,完整术语见术语表 /glossary。

参考文献

Mode A · 引用出处(正文 inline,集中列在此)

• How We Built Our Multi-Agent Research System(Anthropic)· 第 1.1 节 PRO 主源 —— orchestrator-worker + 90.2% + 15× token + 80% 方差 + breadth-first sweet spot + 第 3.2 节 委派 4 要素/effort-scaling + 第 3.4 节 同步瓶颈/恢复 + 第 6 节 LLM-judge 配方 · 数字为发布时点值/内部评测
• Don't Build Multi-Agents(Cognition · 2025-06)· 第 1.2 节 CON 主源 —— 两原则 + Flappy Bird 并行不一致 + 单线程线性 + 压缩模型替代 · 与 PRO 等量呈现
• Building Effective Agents(Anthropic)· 第 0 节 简单性原则(只在简单方案不够时才加复杂度)
• OpenAI Agents SDK(handoff 即工具,去中心进程内)+ LangGraph(图拓扑 + reducer + checkpointer)· 第 2.3 节 / 第 3 节 框架坐标
• A2A Protocol + A2A vs MCP(Linux Foundation)· 第 5 节 Agent Card + opacity + 任务隔离 + HTTP/TCP 分层类比 · 150+ 组织生产
• Improving Factuality and Reasoning through Multiagent Debate(Du et al. · ICML 2024)· 第 2.1 节 / 第 3.5 节 debate 拓扑 —— 多轮辩论提升推理、降幻觉

深 dive 资源(可选 · 想往下走再看)

• Is It Worth Mixing 2 Models? (Planner + Executor)(2026-04 · 二手 hands-on)· 第 4.3 节 负面实测 —— 成熟 harness 里单前沿模型常胜混搭 · 单作者动手,按 workload 自测
• OpenAI Swarm(实验/教学用,非生产,已被 Agents SDK 取代)· 第 2.3 节 教 handoff 心智模型的最小实现 · 引用务必标"教学用"

说明:本章纯 Mode A,脊柱是 Anthropic(pro)与 Cognition(con)两份一手对立 doctrine 的诚实并陈。Anthropic 的 90.2%/15× token/80% 方差均为发布时点值 + 内部评测;框架状态(AutoGen 维护模式、Swarm 教学定位)、A2A 生产数(150+ 组织)、模型混搭负面实测都随时点/workload 变,引用前 pin。坊间"降本 N×"的具体倍数若无一手出处,按定性方向用,勿写死。

下一章

下一章(Ch9)进入第四站 · 运维:度量、失败、真实系统、外推,从 Trajectory Eval 工程开始。这一章你反复在用"评测信号"却没正面讲它;Ch9 会讲为什么给 agent 做评测出乎意料地难(部分给分、非确定、两类假阳、emergent),benchmark 在 2026 年的全景(SWE-bench 因污染退役、τ²-bench、以及"所有 benchmark 都能被刷爆"的警钟),以及最关键的——怎么让 LLM 当裁判而不被它骗(Cohen's κ、judge 的偏见、版本契约)。评测是通往 production 的桥,也是反自欺的工具。