多智能体不是“多 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 更强”，而是一个更老、也更残酷的问题：

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