4.1. 多 Agent 协作不是简单拼接，而是一种系统设计

多 Agent 协作不是简单拼接，而是一种系统设计

2024 年第三季度，我第一次尝试用多个 Agent 协同完成一个复杂的工单处理流水线时，犯了一个非常典型的错误：把三个专门处理不同问题的 Agent 一个接一个串起来，用 if-else 切换调用，以为这就是“多 Agent 协作”。结果在第二天压测就翻了车——一条告警被重复三遍、分类结果被下一个 Agent 无意覆盖，而调试日志里混杂着 7 个 Agent 的输出，根本无从定位。那一刻我才意识到，把几个 prompt 链式拼接，和真正设计一个多 Agent 系统，是两回事。

这次教训让我回到分布式系统的原点，从头理解多 Agent 协作的本质：它不是“提示词的排列组合”，而是在多个具有自主动作、记忆和目标的实体之间，建立一套可靠的通信协议、协调机制和一致性保障。这一章，我们就来系统拆解这个话题，并明确一条分水岭——什么时候你只是在拼接，什么时候你真正开启了系统设计。

经验框：警惕“为协作而协作”
调研中可以反复看到一个现象：很多团队只是因为“主流框架支持 Multi-Agent”，就把一个本可以由单个 Agent 完成的简单拆解任务强行切成多个 Agent。结果引入了不必要的通信开销、状态同步问题和调试地狱。判断是否需要多 Agent 的第一准则，是问题本身是否具有独立的专业壁垒、并行的执行路径或需要协商的冲突决策。 如果都没有，单 Agent + 多 Skill 就足够。

通信模式：直接对话、发布订阅与黑板系统

无论你使用哪种框架，多 Agent 首先要解决一个基础问题：它们怎么说话？ 这一层设计的优劣，直接决定了系统的耦合度、可扩展性和可观测性。三种经典通信模式各有适用场景，却常被开发者混淆。

每种模式没有绝对的好与坏，但在设计时必须有明确的选择意识。我见过不少项目从“直接对话”起步，随着业务增长逐渐变成一团乱麻——因为最初选择了强耦合的 Agent 标识直接调用，后面增加一个 Agent 就要修改所有可能的发送者逻辑。如果你预期未来 Agent 数量会从 3 个变成 30 个，那么第一天就应该用事件总线代替点对点调用。

核心建议框：从 Day 1 就设计通信层
不要在 Agent 内部直接写死其他 Agent 的调用方式。抽象出一个轻量级的通信中间件，哪怕只是一个消息队列的简单封装，能极大减少后续重构成本。今天你用 LangGraph 的 State Channel，明天你换框架，只要接口不变，底层逻辑就不需要动。

协调策略：中心化编排 vs 去中心化编排

通信是“怎么传递信息”，而协调是“谁决定下一步做什么”。这是多 Agent 系统设计的精髓所在，也是各种框架差异化的真正战场。根据当前调研资料，所有多 Agent 模式都可被归纳为两个核心流派：中心化编排和去中心化编排。

中心化编排（Orchestration）：存在一个“指挥者” Agent（或编排器），它握有全局视野，负责解析任务、分解步骤、分配工作并等待结果。典型实现如 CrewAI 的 Sequential/Hierarchical 流程，以及 AutoGen 的 GroupChat——截至当前调研资料，AutoGen 的 GroupChat 采用 GroupChatManager 作为中心控制器来决定发言顺序，是典型的中心化编排，而非去中心化设计。LangGraph 中的 Supervisor 模式也属于此类。

去中心化编排（Decentralized）：没有单一控制点，Agent 之间通过协商、投票或市场机制共同决定下一步。例如基于市场的任务竞标、或通过共识协议达成一致。这类模式在学术论文中常被提及，但在当前的主流生产框架中，真正意义上的去中心化实现还比较少见。

对比两者的优劣势，可以帮助你做出选择：

当前多数实用多 Agent 系统采用中心化编排，正是因为业务对可预测性、可维护性和快速迭代的强烈需求。除非你的场景需要 Agent 之间真正平等协商（比如多个竞标商自动议价），否则不要轻易引入去中心化编排——它会让你徒增分布式共识的复杂度。

一致性、分歧解决与最终决策

一旦多个 Agent 同时对同一个问题给出不同的判断或建议，你会立刻撞上分布式系统最经典的问题：如何在没有统一真理的前提下达成决策？ 这已经不是“提示词微调”能解决的范畴，它要求你设计一套分歧解决机制。

常见的解决策略可以分为三个层次：

1. 投票机制（Majority Voting）：让多个专家 Agent 各自给出答案，取票数最多者。简单高效，但有局限——如果两个 Agent 各自 50% 票数，就陷入平局。此时可以引入加权投票，按照 Agent 在历史任务中的准确率或置信度赋予不同权重。

2. 仲裁者模式（Arbiter/Supervisor）：当投票无法决出时，由一个更高级别的“裁判” Agent 依据规则或上下文做出最终裁决。这个仲裁者并不需要知道所有细节，它的逻辑通常很简单：“在 A 和 B 的分歧中，优先选择更保守/更激进/风险更低的方案”。这种模式非常契合中心化编排——编排器天然可以作为最终仲裁者。

3. 共识算法与自主协商：如果 Agent 是完全去中心化的，就需要借鉴分布式系统里的共识协议（如 Paxos、Raft 的简化版），或者让 Agent 通过多次对话、交换证据，自行达成一致。这在当前多 Agent 系统中尚属前沿，但已出现基于 LLM 的协商模拟研究。

在实际工程中，我强烈推荐“投票 + 仲裁兜底”的组合。投票能解决大部分可量化分歧，而仲裁者则作为“断死锁”的最终手段。设计仲裁者时，务必让它的决策逻辑极其透明且记录完整，否则你会发现自己把不可解释性从单个 Agent 扩散到了整个系统。

注意框：分歧不可怕，沉默才是
多 Agent 系统中最危险的状况不是 Agent 吵个不停，而是所有 Agent 都保持沉默或返回“我不知道”，导致任务卡死在某一步。必须在超时或空结果时就触发仲裁或降级逻辑，保证系统最终能产生一个可用的输出。

适合谁，不适合谁

读到这里，你可能会问：“我现在的项目到底该不该引入这种系统设计思维？”以下是基于角色和痛点的判断：

适合这样做的你：

• 你的业务需要 3 个以上拥有独立知识边界的 Agent 共同完成一个复合任务，且任务之间存在依赖或并行关系。
• 你已经在单 Agent 中完成了 Skill 的工程化（错误处理、状态管理），现在面临“多条生命线”之间的协调问题。
• 你希望系统能在未来自由增减 Agent，而不需要每次重构核心代码。

不适合（或需要三思）的你：

• 你的任务可以被一个强 Agent 按顺序完成，且没有并行或协商的必要。强行拆成多 Agent 只会让你陷入上面提到的“为协作而协作”的陷阱。
• 你还没有解决单个 Agent 的可靠性和状态管理问题——此时引入多 Agent 只是把不稳定乘以 N。建议先回顾上一章关于事务性和状态管理的内容。

我会在多 Agent 协作这件事上反复强调：它不是对单 Agent 的升级，而是对系统复杂性的应答。 当你真正需要它时，你会发现之前为单 Agent 做的所有工程化工作，都是为了这一刻——让你有底气去设计通信协议，而不是在混乱的消息风暴里救火。

在下一章，我们将落地本章的理论，进入 LangGraph 让你用状态机精确控制 Agent 流转。我们会看到，LangGraph 如何以状态和边的方式，把这里讨论的中心化编排、通信模式以及分支决策直接编译为确定性工作流，让你的多 Agent 系统不再依赖隐式的提示词约定，而是走向可调试、可回放的工程级控制。