# 现在，编排就是架构 把一个 god-agent（上帝智能体）拆成十个专注的小 agent，你就把一个模型问题换成了一个系统问题：现在它们必须协同工作，而协调比任何单个 agent 都更难。大多数团队把这套连线当成管道。它不是——它就是架构，它是一个分布式系统，并且会像分布式系统那样崩溃。本文讲清楚编排到底是什么、它如何崩坏，以及为什么在你能说清瓶颈在哪之前，不该急着去用它。 - **Author:** Fedor Chishchin - **Published:** 2026-06-03 - **Tags:** agents, architecture, methodology - **Source:** https://fedorthinks.com/zh/blog/orchestration-is-the-architecture --- 上一次我主张，你应该把 [god-agent 拆开](/blog/one-agent-that-does-everything)，拆成一个个小而专注、各自只把一件事做好的 agent——而我在结尾留了个钩子：这么做并不会消灭你的问题，只是把它换成了一个新问题。你现在有了十个 必须协同工作的 agent，而要让它们做到这一点，结果比任何单个 agent 苦苦挣扎的任何事都更难。 这种协调正是本文的主题，因为大多数团队处理它的方式，就是他们的多 agent 系统悄无声息地垮掉的原因。 ## 协调不是水暖管道。它就是系统。 当人们搭建一套多 agent 方案时，他们把 agent 当成系统，把 agent 之间的连线当成管道—— 把输出接到输入上，就算搞定了。这是本末倒置。一旦工作被拆给各个专家，agent 反倒是简单的部分。 **现在协调就是架构**——而这恰恰是几乎没人有意去设计的部分。 这一层有个名字：编排。它不是一根线，而是一组实打实的职责—— [任务拆解、路由、状态管理、结果聚合，以及错误处理与升级](https://atlan.com/know/multi-agent-system-orchestration/)。 生产中占主导地位的形态是 **编排器-工作者（orchestrator-worker）** 模式——大约占 [70% 的部署](https://medium.com/@Micheal-Lanham/multi-agent-in-production-in-2026-what-actually-survived-f86de8bb1cd1)—— 其中一个有能力的模型接收任务，把它拆开，把每一块派发给一个廉价的专家工作者，再把结果组装起来。 （这种拆分，即一个聪明的规划者管着一群廉价的执行者，也正是 [很多成本节约的来源](/blog/cheap-model-most-of-the-work)——在已报告的案例中达到 40–60%。） 那个编排器不是胶水。它是你将要写的最重要的组件。 ## 它是一个分布式系统，而且会像分布式系统那样失败 让整件事变得可处理的心智转变在这里：一个多 agent 系统 _就是_ 一个分布式系统。独立的组件、传递消息、 持有状态、局部失败。一旦你这样看它，它那些吓人的失败模式就不再是神秘的“AI 问题”，而变成了你早就熟悉的 经典分布式系统问题： - **级联。** 一个 agent 产生幻觉，把它的错误答案当成事实交给下一个，错误沿着链条不断放大—— 一条损坏的消息在流水线里一路传播。 - **失控循环。** 两个 agent 把一个任务来回踢，或者一个 agent 永远重试， [悄悄把你的 API 账单越堆越高](https://www.digitalapplied.com/blog/multi-agent-orchestration-5-patterns-that-work)—— 一个挂着计价器的无界重试。 - **静默消息丢失。** 一次交接把上下文窗口撑爆，关键信息在没人察觉的情况下被截断， 下游的一个 agent 拿着半截消息就动手了——丢了包，却没有报错。 - **死掉的升级路径。** 那条人人都设计了、却没人测试过的“升级给人工”的路径，从来没真正触发过—— 那个从不在 happy path（顺利路径）上的错误处理器。 这不是假设出来的脆弱。在生产中，多 agent 系统的失败率经测量 [介于 41% 到将近 87% 之间](https://www.augmentcode.com/guides/why-multi-agent-llm-systems-fail-and-how-to-fix-them)， 其中 **仅协调崩溃一项就占了全部失败的 36.9%**——不是模型笨，而是 _协调_ 没人管。 解法是把这些失败模式正在苦苦呼唤的纪律带进来：agent 之间显式的契约、有界的循环与重试、可观测的状态， 以及你真正会去演练的错误与升级路径。分布式系统的问题，想要的是分布式系统的答案。 ## 在你能说清瓶颈之前，别急着上它 还有第二个陷阱，与把协调当成管道恰恰相反：因为多 agent 听上去很强大，就一头扎进去。它确实强大， 而且它 _很贵_。协调有实打实的代价——多 agent 系统可能烧掉 [**单 agent 交互 15 倍的 tokens**](https://www.augmentcode.com/guides/why-multi-agent-llm-systems-fail-and-how-to-fix-them)， 外加光是来回倒腾状态就产生的大量开销。2024 年那个“agent 越多 = 越聪明”的梦，在生产中基本上死了。 取而代之的共识，是五家主要厂商—— [Anthropic、OpenAI、Cognition、LangChain、AutoGen 一致汇聚到的](https://towardsdatascience.com/the-multi-agent-trap/) 一条有用的规则：**举证责任在多 agent 一方，而不在单 agent 一方。** 先从一个 agent 开始。只有当你能说清那个逼你不得不加的具体瓶颈时，才加第二个——领域隔离、真正可并行的工作、 一条合规边界。“感觉更高级”不是瓶颈。你加的每一个 agent 都买来了能力，并以协调为代价偿付， 而这笔交易只有在某个具体的东西要求它时才值得。 ## 真正的失败，是在不经意间把它做出来 把这两个陷阱放在一起，真正的问题就清晰起来了。大多数团队不是 _决定_ 去建一个多 agent 系统； 他们是把它 _长_ 出来的。他们往一个 agent 上拴一个 agent 来补个洞，然后再拴一个，编排就这样隐式地冒了出来—— 没有选定的模式，没有契约，没有失败处理，只有一堆没人设计过、层层累积的连线。这正是你怎样落进那 86% 那一栏的。 针对多 agent 系统的探询已经 [爆炸式增长](https://towardsdatascience.com/the-multi-agent-trap/)，但其中的协调大多是即兴拼凑的， 而即兴拼凑的分布式系统会失败。 解法不是一个框架。它是一种姿态：把编排当成头等的设计产物。有意地选定模式。写下每个 agent 要恪守的契约。 决定当某一步陷入循环、被截断或失败时会发生什么——在它发生之前就决定好。编排器值得你给任何关键系统的那种 深思熟虑的设计，因为它本来就是那样的东西。 当构建变得廉价、你把工作拆给一个个专家时，你并没有移除架构——你只是把它挪了个地方。它过去住在某一个 agent 的 prompt 里；现在它住在众多 agent 之间的协调里。把那份协调当成它本来的分布式系统去设计，有意地—— 要么就眼睁睁看着它像一个你假装只是管道的分布式系统那样崩掉。