速成课 · No. 29
单个智能体在一个循环里处理一个目标。有些问题比这更大——工具太多、需要的不同技能太多、一个上下文装不下。Multi-agent 系统把工作拆分给由一个 orchestrator 协调的多个专门智能体。做对了,它更可靠、更可扩展;条件反射式地上,它会成倍放大每一种故障模式。这里讲的是:多个智能体何时胜过一个,以及如何把它们接起来。
只讲精髓 · 每个想法一个画面 · 可靠性高于魔法
在把智能体接到一起之前,先理解它要解决的问题。Multi-agent 系统的存在有一个具体的理由——没有那个理由就伸手去用,正是它出错的方式。
一个什么都做的智能体什么都做不好
一个工人被要求同时当建筑师、水管工、电工和验收员——对比一支各自只把一件事做好的小型专家团队。
一个被赋予过于宽泛职责的智能体——所有工具、所有种类的任务、一个巨大的提示词——在每一步都有太多出错的可能。随着任务变大,它的可靠性下降。把工作拆分给各自职责狭窄的 专门智能体,可以让整个系统更强、更可靠,就像一支专家团队胜过一个被拉得太开的多面手一样。专门化是 multi-agent 存在的核心理由。
上下文和工具会让单个智能体不堪重负
一张桌子上堆满了十种不同工作所需的所有文件和所有工具——工人花在整理这堆杂物上的力气,比真正干活还多。
有两个具体的限制把问题推过了单个智能体的边界。一个智能体的 上下文窗口 会被任务每个部分的所有东西塞满,而塞得过满的上下文会让质量下降(上下文工程问题)。而一个握着 所有 工具的智能体,每一轮都得在一份巨大的菜单里挑选,工具越多它挑得越差。拆分让每个智能体只携带它那份狭窄工作所需的上下文和工具——干净、专注、可靠。
专门化是重点——而代价是协调
一支接力队比一个人跑完四棒更快——但前提是交接练熟了;掉一次棒就输掉整场比赛。
multi-agent 带来的收益是专门化:每个职责狭窄的智能体都只把一件事做好。代价是 协调:现在得有东西来拆分工作、分派工作、在智能体之间传递上下文、并把结果组装起来——而这套协调本身就是复杂度和故障的来源。整门功夫,就是在守住专门化收益的同时,别让协调成本把它吃掉。当收益盖不过成本时,单个智能体才是正确答案。
一个什么都做的智能体什么都做不好——上下文太多、工具太多。多个专门智能体可以更强,但代价是协调,而协调必须对得起这份收益。
multi-agent 系统最常见的形态,是中心有一个协调者。理解了 orchestrator,就理解了这类系统是怎么接起来的大部分。
一个分派工作的协调者
建筑工地上的总承包商:他们不砌砖、也不接电箱——他们把项目拆成一项项活,把每项派给合适的专家。
orchestrator(或称协调者)是掌控全局的那个智能体:它接过整体目标,把它拆成子任务,并把每个子任务分派给合适的专门智能体。它自己不做那些专门的活;它的工作是分解和指挥。这正是智能体课里 plan-and-execute 思路的放大版——一个有能力的智能体规划并委派,而专注的 worker 执行各个部分。
它组装各个 worker 的结果
一位编辑向不同的作者约写各个章节,再把它们合成一篇连贯的文章——各部分回来了,得有人把它们拼成整体。
orchestrator 的第二项工作是 组装:收集 worker 智能体返回的东西,并把它们合成一个连贯的最终结果。一个研究型 orchestrator 可能把若干子主题派给几个智能体,然后把它们的发现综合成一个答案。这一步收集并合并,是各路分开的工作变成单一输出的地方——而把它做好(化解冲突、去掉重复)和拆分一样重要。
协调层才是真正的架构
一支管弦乐团不是一堆出色的独奏者凑在一起——而是指挥和总谱在决定谁在何时演奏。协调才是音乐。
在一个 multi-agent 系统里,价值和难点都转移到了 协调层:谁在何时运行、用什么输入、结果如何合并。被关注的是一个个智能体,但系统能不能跑通,是由围绕它们的编排决定的——分派、上下文传递、错误处理。和单个智能体一样,模型是容易的部分;围绕它的结构,才是可靠性被赢得或失去的地方。
orchestrator 分解目标,把每个子任务分派给一个专门的 worker,并组装它们的结果。协调层——而非一个个智能体——才是真正的架构。
orchestrator 所指挥的那些智能体,在每个都职责狭窄时最有用。让 worker 保持专注的那份纪律,正是让整个系统可靠、可测试的原因。
每个 worker 都有一项清晰的工作
一间厨房里每项任务都有一个工位——一个厨师管酱汁、一个管烤架、一个管摆盘——各自精通自己那份狭窄的角色,而不是样样都手忙脚乱。
一个 worker agent 是职责狭窄、定义明确的专门智能体:搜文档、写代码、核事实、格式化输出。因为它的职责很小,它的提示词很专注,它的工具很少,它的行为可预测。orchestrator 递给它一个清晰的子任务,它做那一件事,然后返回结果。狭窄的 worker 是积木——每一块都简单到能做对、能信得过。
狭窄的智能体更容易测试和信任
你可以彻底检查一个专家的工作,因为他的活又小又明确——这远比审查一个样样都沾点边的多面手要容易。
一个狭窄的智能体,比一个铺得很开的,在评测、调试和信任上都要容易得多。有了一项清晰的工作,你可以为它写评测、看清它到底在哪里失败、并把它隔离开来修复——这和智能体课里那套可靠性论证一样,只是用在了每一块上。一个 multi-agent 系统只有在它的 worker 各自可靠时才可靠,而当每个 worker 只做一件界定清楚的事时,这要容易达到得多。
在一件事上的深度胜过在很多事上的广度
一个只做一种手术、做了几千次的外科医生,胜过一个偶尔上手的多面手——专注产生的可靠性,广度给不了。
贯穿这一切的原则是 深度胜过广度:一个专注的智能体反复做一件事,比一个铺得很开的偶尔做很多事更可靠。这正是你为什么要分解——不是为了多几个智能体而多,而是为了让每一个都狭窄到能真正把它那块做好。如果一个 worker 的活仍然宽到不可靠,答案通常是把它进一步拆开,而不是往上堆更多工具。
worker 智能体是狭窄的专家——一项清晰的工作、一个专注的提示词、很少的工具——这让每一个都可测试、可信任。在一件事上的深度胜过在很多事上的广度。
智能体的好坏,取决于它们彼此传递的东西。工作和上下文如何在它们之间流动——干净还是凌乱——决定了系统是保持连贯,还是退化成噪声。
handoff 在智能体之间传递工作
一名接力跑者交棒:这次交接本身就是一项技能,而干净的传递——不只是跑得快的选手——才是赢得比赛的关键。
一次 handoff 是一个智能体把工作传给另一个的那一刻——orchestrator 传给一个 worker,或一个智能体直接传给下一个。被传递的是子任务,以及完成它所需的上下文。handoff 是很多 multi-agent 故障发生的地方:如果接收的智能体没拿到它需要的东西,或拿到了一个糊成一团的版本,那么不管这个智能体多好,它的输出都是错的。这次交接是设计中头等重要的一部分。
传递干净、结构化的上下文——而不是全部
一份好的简报,给下一个人的恰好是他的任务所需要的——而不是把之前每一次对话的全部记录都塞给他去趟。
诱惑在于把至今为止的全部历史都传给每个智能体,但这会在每个智能体内部重建那个塞得过满的上下文问题。更好的是 干净的 handoff:给接收的智能体一份专注、结构化的摘要,只含它需要的——相关的事实和具体的任务——而不是原始的水龙头。这让每个智能体的上下文都保持紧凑、专注,而这恰恰是当初拆分值得去做的原因。
context isolation 让智能体保持专注
一间间独立的工作室,每间只放那间活所需的材料——这样没人会被其他所有任务的杂物分心或搞糊涂。
multi-agent 的一个真实好处是 context isolation:每个智能体在自己干净的上下文里工作,只看到它的活所需要的,而不是整个系统积下来的那一团乱。这是拆分能提升可靠性的一部分原因——它防止了那种在一个长跑智能体里堆积起来的上下文腐烂。但你只有在 handoff 有纪律时才拿得到这个好处;把所有东西传给所有人,你就把那个单一过载智能体的问题原样重建了一遍,还多绕了几步。
handoff 在智能体之间传递工作,而它正是 multi-agent 常常失败的地方。传一份干净、结构化、只含所需的摘要,让每个智能体保住拆分本应给它的那份专注的上下文。
multi-agent 系统是按几种反复出现的形态接起来的。知道这三种主要的——以及各自何时合适——就是知道如何构建协调的大部分。
sequential:一条分阶段的流水线
一条装配线:每个工位做自己那部分,按固定顺序把产品传给下一个,直到末端出来成品。
sequential 模式把智能体按固定顺序串起来:智能体 A 的输出喂给智能体 B,B 的输出喂给智能体 C。一个起草智能体,然后一个编辑智能体,然后一个核事实智能体。它是最简单的 multi-agent 形态,也最可预测,当工作有必须按顺序发生的自然阶段时最理想。它本质上是一条专家流水线——而当各步骤是固定的,它比一个每次都重新决定顺序的循环更可靠。
parallel:fan-out 再汇集
把同一个研究问题同时发给几位助手,再把他们的发现一起收集起来——许多人同时工作,结果在末端合并。
parallel 模式让多个智能体在互不相关的几块上同时运行,然后汇集它们的结果——一次 fan-out 之后是一次汇集。研究五个子主题、处理许多条目、获取几份独立的视角:这些并行做都比一个接一个快。orchestrator 拆分工作,worker 同时运行,然后结果被合并。当各块彼此不依赖、且速度重要时,parallel 大放异彩。
hierarchical:orchestrator 之上的 orchestrator
一张公司组织架构图:一位经理指挥若干团队主管,而每位主管又各自指挥自己的 worker——为一件单层搞不定的活,把协调分层嵌套起来。
hierarchical 模式把协调嵌套起来:一个顶层 orchestrator 委派给若干子 orchestrator,每个子 orchestrator 管理自己的 worker。这通过分层拆解,处理真正庞大、复杂的任务,就像一个组织那样。它是最强大的形态,也最复杂——更多的协调、更多出错的地方——所以你只有在任务真的大到需要嵌套分解时才伸手去用。大多数系统用 sequential 或 parallel 就够了;层级是留给那少数不够用的。
sequential 把智能体串成一条固定流水线;parallel 把互不相关的工作 fan-out 出去再汇集;hierarchical 为大任务嵌套 orchestrator。用工作真正需要的最简单形态。
multi-agent 很诱人,也常被滥用。更多智能体不只是增加能力——它们成倍放大系统出错的方式,而无视这一点,正是这类系统悄悄失败的方式。
更多步骤累积更多错误
一场更长的接力,交接更多,掉棒的机会也更多——每多一次交接,就是整场跑可能失败的又一个地方。
一个智能体在一条长链上本来就只在一小部分时候成功(智能体课里的可靠性问题),而 multi-agent 把链拉得更长:更多智能体、更多 handoff、更多步骤,每一处都可能失败并把错误往下游传。可靠性沿着链成倍衰减,所以加智能体可能反而 降低 整体成功率,除非每一块和每一次 handoff 都扎实。更多智能体是更多可累积故障的表面积,而非自动地更多能力。
协调有它自己的开销和成本
一场协调五个团队的会议,可能比工作本身花的还多——过了某个点,协调就盖过了干活。
每个智能体都是它自己的模型调用、自己的延迟、自己的成本——而编排在这之上又加了一层。对同一件任务,一个 multi-agent 系统可能比单个智能体慢得多、贵得多,有时还一点都不更好。协调开销是真实的:分派、handoff、组装、重试。如果专门化的收益不能明显盖过这份额外的成本和延迟,那个更简单的单个智能体才是更好的工程选择。
它更难追踪和调试
追踪一个包裹很容易;在一张由仓库、卡车和交接织成的网里追查一个故障,是另一桩难得多的活。
当一个 multi-agent 系统出问题时,找出 在哪里 比在单个智能体里难得多:故障可能在任何一个 worker、任何一次 handoff,或编排本身。可观测性——跨智能体追踪一个请求、记录每一次 handoff——变得必不可少,也更难。这份调试成本是代价中真实的一部分。一个你追不了的系统,就是一个你修不可靠的系统,而 multi-agent 让追踪实实在在地更难了。
更多智能体成倍放大故障模式:更多步骤累积错误、真实的协调开销和成本、以及难得多的追踪。条件反射式的 multi-agent 降低可靠性,而非提升它。
multi-agent 对的问题是一件强大的工具,对错的问题是一个昂贵的错误。用好它,大部分是克制——只在单个智能体真的应付不来时才拆分。
只在一个智能体真的应付不来时才拆分
你不会为了回答一个简单问题就组个委员会——只有当活真的大到一个有能力的人搞不定时,你才请一支团队进来。
默认应该是 单个智能体,只有当一个真的搞不定这件活时——不同技能太多、工具太多、上下文太多以至于装不连贯——你才伸手去用 multi-agent。如果一个建得好的单个智能体能做到,那么 multi-agent 版本只是平添成本、延迟和故障模式,却没有任何收益。问题从来不是「我能不能把它拆开?」——几乎什么都能拆——而是「在这里一个智能体是不是真的力有不逮?」
让每个智能体狭窄、每次 handoff 干净
一支运转良好的队伍有清晰界定的角色和练熟的交接——是结构,而非逞英雄,让它靠得住。
当你确实上了 multi-agent,让它跑通的两项纪律是:让每个 worker 狭窄(一项清晰的工作、很少的工具、能隔离测试),让每次 handoff 干净(一份只含所需的专注摘要,而非全部历史)。大多数 multi-agent 故障都追溯到一个太宽的 worker 或一次太糊的 handoff。把这两件做对,再配一个清晰的 orchestrator 和合适里最简单的模式,系统就能在扩展时保持可靠。
- 一个智能体是不是真能做这件事——还是它真的会在负载下崩掉? - 有没有一个清晰的 orchestrator 来分解、分派和组装? - 每个 worker 是否狭窄——一项工作、很少的工具、能单独测试? - handoff 是否干净——一份专注的摘要,而非把全部历史倒过去? - 哪种模式合适——sequential、parallel 还是 hierarchical——它是不是能用里最简单的? - 收益是否盖过成本——更多步骤、延迟、花费,以及 更难的追踪?
- multi-agent / orchestrator——把工作拆分给多个智能体,由一个指挥来协调。 - worker agent / 专门化——一个职责狭窄、只有一项清晰工作的智能体;深度高于广度。 - handoff / context isolation——干净地传递工作;每个智能体在自己专注的上下文里。 - sequential / parallel / hierarchical——流水线、fan-out-再汇集、嵌套协调。 - fan-out——把工作拆开,让几个智能体同时运行。 - 协调开销——编排所带来的 额外成本、延迟和复杂度。 - 累积错误——更多步骤和 handoff 成倍放大失败的几率。
- 你 只在一个智能体真的应付不来时 才伸手去用 multi-agent。 - 一个清晰的 orchestrator 分解、分派并组装工作。 - 每个 worker 都狭窄——能单独测试、信得过。 - handoff 干净,传递专注的上下文,让每个智能体的窗口保持紧凑。 - 你用合适里 最简单的模式,并能跨智能体 追踪 一个故障。
multi-agent 是一项深思熟虑的决定:只在一个智能体真的应付不来时才拆分,给它一个清晰的 orchestrator,让每个 worker 狭窄、每次 handoff 干净,并用最简单的模式——因为你每加一个智能体,都会成倍放大成本和故障模式。