多智能体不是“多 LLM”，而是组织结构问题

专栏推荐｜Agent 工程，不是能力问题，而是结构问题

当 Agent 从 Demo 走向生产，真正暴露的问题往往并不在模型能力上。不可预测、状态混乱、责任失焦，这些现象反复出现，其根因是：工程结构尚未建立。

本专栏以真实工程实践为线索，系统梳理 Agent 系统从“能用”到“可治理”的演化路径：从一次性 Prompt 调用，到 Workflow 化执行；从上下文堆叠，到显式 Memory 与状态责任；从单 Agent 承担任务，到多 Agent 协作所引发的分布式复杂性；再到接口、协议与组织结构如何决定系统上限。

专栏不提供捷径，也不兜售“更聪明的 Agent”。 它关注的是：当 Agent 必须为结果负责时，哪些约束不可回避，哪些问题无法绕开。

这是一组写给工程负责人、架构师与 Agent 系统实践者的结构性思考。

第一篇为什么你的 Agent 系统一旦上线就开始变得不可预测？

第二篇没有 Memory 的 Agent，不是“健忘”，而是根本不存在

第三篇从 Prompt 到 Workflow —— Agent 何时不再是“一次性调用”？

第四篇当一个 Agent 不够用，你就已经进入了分布式系统世界

多智能体不是“多 LLM”，而是组织结构问题

在第四篇中，我们已经跨过了一个不可逆的工程门槛。

当一个 Agent 不够用，你引入了多个 Agent； 而当多个 Agent 同时存在，你继承的已经不再是“模型能力问题”，而是分布式系统的全部现实。

但很多团队在这里，会犯一个更隐蔽、也更昂贵的错误：

他们以为自己在“增加智能”，实际上是在“制造组织混乱”。

1. 一个反直觉的事实：多 Agent 的第一失败点，不是通信

在多数工程复盘中，多 Agent 系统的失败往往被归因于：

• 消息没发到
• 状态没同步
• 延迟太高

这些问题当然存在，但它们不是最早发生的崩溃点。

真正最先失效的，是这一条：

系统不知道“谁对结果负责”。

在单 Agent + Workflow 的阶段，这个问题是被天然掩盖的：

• 决策在一个执行上下文里完成
• 状态在一个逻辑空间里演进
• 出错时，你知道“就是这个 Agent 干的”

一旦你把职责拆分给多个 Agent，这个“默认责任中心”就消失了。

而你如果没有显式补上它，系统的失败将不再是异常，而是常态。

2. 一个常见但注定失败的多 Agent 设计直觉

在设计评审会上，几乎所有团队都会提出类似的方案：

“我们让每个 Agent 都各司其职，大家平等协作。”

于是，系统被拆成这样：

• 意图 Agent：负责理解用户
• 规划 Agent（Planner）：负责推理步骤
• 执行 Agent（Executor）：负责调用工具
• 校验 Agent（Critic / Reflection）：负责检查结果

从《Agentic Design Patterns》的角度看，这些角色本身并没有错。

错的是一种隐含假设：

只要把能力拆开，系统就会变得更可靠。

工程现实恰恰相反。

当这些 Agent 之间没有明确的权责关系时，你得到的不是“协作”，而是：

• 决策被无限推迟
• 失败被无限转移
• 每个 Agent 都有“合理解释”，但系统整体不可用

这不是智能问题，而是组织结构失效。

3. 第一次真正的工程觉醒：Agent 必须是“角色”，而不是“能力集合”

《Agentic Design Patterns》中反复强调一个被很多人忽略的前提：

模式的价值不在于“多聪明”，而在于“谁控制流程”。

这正是多 Agent 系统的分水岭。

在生产环境中，一个 Agent 如果只是：

• 会推理
• 会调用工具
• 会生成文本

那它仍然只是一个“能力模块”。

而一个角色型 Agent，必须至少具备以下之一：

• 决策权：是否继续执行流程
• 否决权：拒绝某个下游结果
• 提交权：写入最终状态
• 终态责任：对用户结果负责

例如：

• Supervisor Pattern 并不是“更聪明的 Planner”， 而是唯一允许推进或终止流程的角色。
• Coordinator 的存在意义，不是生成内容， 而是收敛分散的执行结果。

一旦你意识到这一点，你就会发现：

多 Agent 系统设计，本质上是在设计一套“权力分布”。

4. 为什么“民主式多 Agent 协作”在工程上必然失败

很多关于 Multi-Agent 的演示系统，会刻意强调：

• 多个 Agent 讨论
• 相互补充
• 最终达成共识

在研究环境中，这很迷人； 在生产系统中，这是一个危险信号。

原因非常简单：

分布式系统里，如果没有明确的最终裁决者，失败就无法被收敛。

当多个 Agent 平等发言时：

• 谁决定最终输出？
• 谁为错误结果负责？
• 谁在异常时有权中止流程？

如果这些问题的答案是“大家一起”，那工程结论只有一个：

没有人负责。

这也是为什么《Agentic Design Patterns》在 Multi-Agent 场景中，始终强调 Supervisor / Orchestrator 的存在—— 不是为了“更强推理”，而是为了结构收敛。

5. 多 Agent 系统中，最稀缺的不是智能，而是“责任中心”

当系统规模扩大后，很多团队会产生一种错觉：

“是不是再加一个 Agent，就能兜住这个问题？”

但现实是：

• Agent 越多
• 决策路径越长
• 责任越分散

最终你会得到一个看似很忙、但没人能解释结果的系统。

这也是为什么在成熟的多 Agent 架构中，往往会出现一种“反智能”的设计趋势：

• 决策 Agent 很少
• 执行 Agent 很多
• 写状态的 Agent 极少

这不是能力不足，而是工程自保。

6. 一个冷静但必须接受的工程结论

到这里，其实可以给出第五篇的核心判断了：

多智能体系统的成熟标志，不是“讨论变多”，而是“决策变少”。

当你真正把 Agent 当作工程组件，而不是智能展示窗口时，你会发现：

• 好的多 Agent 系统，像一家组织清晰的公司
• 坏的多 Agent 系统，像一个没有老板的会议室

而组织问题，从来不是靠“多说话”解决的。

阶段性小结：你已经不再是在“设计智能”

当你的系统走到多 Agent 这一层时，有一个认知必须被明确写下来：

你当前面对的核心问题，已经不再是“模型够不够聪明”， 而是“系统是否允许它犯错”。

这恰恰引出了下一篇的主题。

下一篇预告

在第六篇中，我们将暂时放下 Agent 本身，转而讨论那些最近频繁被提及的关键词：

A2A、MCP、工具调用

它们真正解决的，从来不是“怎么让 Agent 更强”， 而是一个更老、也更残酷的问题：

如何通过接口，把不可靠的执行体，限制在一个可控的边界之内。