现在，编排就是架构

上一次我主张，你应该把 god-agent 拆开，拆成一个个小而专注、各自只把一件事做好的 agent——而我在结尾留了个钩子：这么做并不会消灭你的问题，只是把它换成了一个新问题。你现在有了十个 必须协同工作的 agent，而要让它们做到这一点，结果比任何单个 agent 苦苦挣扎的任何事都更难。

这种协调正是本文的主题，因为大多数团队处理它的方式，就是他们的多 agent 系统悄无声息地垮掉的原因。

协调不是水暖管道。它就是系统。

当人们搭建一套多 agent 方案时，他们把 agent 当成系统，把 agent 之间的连线当成管道—— 把输出接到输入上，就算搞定了。这是本末倒置。一旦工作被拆给各个专家，agent 反倒是简单的部分。 现在协调就是架构——而这恰恰是几乎没人有意去设计的部分。

这一层有个名字：编排。它不是一根线，而是一组实打实的职责—— 任务拆解、路由、状态管理、结果聚合，以及错误处理与升级。 生产中占主导地位的形态是 编排器-工作者（orchestrator-worker） 模式——大约占 70% 的部署—— 其中一个有能力的模型接收任务，把它拆开，把每一块派发给一个廉价的专家工作者，再把结果组装起来。 （这种拆分，即一个聪明的规划者管着一群廉价的执行者，也正是 很多成本节约的来源——在已报告的案例中达到 40–60%。） 那个编排器不是胶水。它是你将要写的最重要的组件。

它是一个分布式系统，而且会像分布式系统那样失败

让整件事变得可处理的心智转变在这里：一个多 agent 系统 就是 一个分布式系统。独立的组件、传递消息、 持有状态、局部失败。一旦你这样看它，它那些吓人的失败模式就不再是神秘的“AI 问题”，而变成了你早就熟悉的 经典分布式系统问题：

• 级联。 一个 agent 产生幻觉，把它的错误答案当成事实交给下一个，错误沿着链条不断放大—— 一条损坏的消息在流水线里一路传播。
• 失控循环。 两个 agent 把一个任务来回踢，或者一个 agent 永远重试， 悄悄把你的 API 账单越堆越高—— 一个挂着计价器的无界重试。
• 静默消息丢失。 一次交接把上下文窗口撑爆，关键信息在没人察觉的情况下被截断， 下游的一个 agent 拿着半截消息就动手了——丢了包，却没有报错。
• 死掉的升级路径。 那条人人都设计了、却没人测试过的“升级给人工”的路径，从来没真正触发过—— 那个从不在 happy path（顺利路径）上的错误处理器。

这不是假设出来的脆弱。在生产中，多 agent 系统的失败率经测量 介于 41% 到将近 87% 之间， 其中 仅协调崩溃一项就占了全部失败的 36.9%——不是模型笨，而是 协调 没人管。 解法是把这些失败模式正在苦苦呼唤的纪律带进来：agent 之间显式的契约、有界的循环与重试、可观测的状态， 以及你真正会去演练的错误与升级路径。分布式系统的问题，想要的是分布式系统的答案。

在你能说清瓶颈之前，别急着上它

还有第二个陷阱，与把协调当成管道恰恰相反：因为多 agent 听上去很强大，就一头扎进去。它确实强大， 而且它 很贵。协调有实打实的代价——多 agent 系统可能烧掉 单 agent 交互 15 倍的 tokens， 外加光是来回倒腾状态就产生的大量开销。2024 年那个“agent 越多 = 越聪明”的梦，在生产中基本上死了。

取而代之的共识，是五家主要厂商—— Anthropic、OpenAI、Cognition、LangChain、AutoGen 一致汇聚到的 一条有用的规则：举证责任在多 agent 一方，而不在单 agent 一方。 先从一个 agent 开始。只有当你能说清那个逼你不得不加的具体瓶颈时，才加第二个——领域隔离、真正可并行的工作、 一条合规边界。“感觉更高级”不是瓶颈。你加的每一个 agent 都买来了能力，并以协调为代价偿付， 而这笔交易只有在某个具体的东西要求它时才值得。

真正的失败，是在不经意间把它做出来

把这两个陷阱放在一起，真正的问题就清晰起来了。大多数团队不是 决定 去建一个多 agent 系统； 他们是把它 长 出来的。他们往一个 agent 上拴一个 agent 来补个洞，然后再拴一个，编排就这样隐式地冒了出来—— 没有选定的模式，没有契约，没有失败处理，只有一堆没人设计过、层层累积的连线。这正是你怎样落进那 86% 那一栏的。 针对多 agent 系统的探询已经 爆炸式增长，但其中的协调大多是即兴拼凑的， 而即兴拼凑的分布式系统会失败。

解法不是一个框架。它是一种姿态：把编排当成头等的设计产物。有意地选定模式。写下每个 agent 要恪守的契约。 决定当某一步陷入循环、被截断或失败时会发生什么——在它发生之前就决定好。编排器值得你给任何关键系统的那种 深思熟虑的设计，因为它本来就是那样的东西。

当构建变得廉价、你把工作拆给一个个专家时，你并没有移除架构——你只是把它挪了个地方。它过去住在某一个 agent 的 prompt 里；现在它住在众多 agent 之间的协调里。把那份协调当成它本来的分布式系统去设计，有意地—— 要么就眼睁睁看着它像一个你假装只是管道的分布式系统那样崩掉。