多智能体协作不是简单分工：复杂任务中如何避免重复执行

多智能体协作听起来像是把任务拆开、分给几个智能体各干各的，但在实际搭建系统时，最让人头疼的往往不是“分”，而是“重复”。同一个任务被两个智能体各执行了一遍，消息发了两次，工单建了两张，数据写了两份——这些问题在单智能体时代几乎不存在，一旦引入多智能体，反而成了高频故障。

原因并不复杂：智能体本身是概率模型，它对自己“是否已经完成某件事”的判断并不可靠。如果系统里没有清晰的共享状态和确认机制，两个智能体完全可能基于各自的上下文，得出“这件事该由我来做”的结论。所以，多智能体协作的核心问题，从来不是怎么把任务拆得更细，而是怎么让每个智能体都清楚“别人做到哪一步了、哪些事不该再做”。

串行、并行与带协调者：三种组织方式的真实代价

先看最常见的三种任务组织方式，它们各自的适用场景和代价差异很大。

串行执行是最直观的方式：智能体 A 完成分析，把结果交给智能体 B 继续处理，B 再交给 C。这种方式的好处是状态天然清晰——每个智能体接手时，前一步的产出已经是确定的事实，不需要担心重复。但代价是慢，而且一旦某个环节出错，整条链路都要停下来。串行适合步骤之间有强依赖、且每一步都依赖前一步完整结果的场景，比如“先调研、再写大纲、最后成文”。

并行执行则是把互不依赖的子任务同时分给多个智能体，比如同时让三个智能体分别调研三个不同方向。它的优势是快，但问题也随之而来：如果任务边界划分得不够清楚，两个智能体可能同时去查同一个数据源、写同一份文档。并行模式真正考验的不是智能体本身，而是任务拆解时边界是否足够互斥——如果两个子任务天然有重叠，并行就会放大重复。

带协调者的模式是目前工程上更稳妥的选择。协调者不直接干活，它负责接收任务、拆解、分派、收集结果，并在出现冲突时做裁决。这种方式的额外成本是增加了一次“中转”，但换来的是全局状态的可控性。协调者手里有一份任务认领清单，哪个智能体领了哪个子任务、做到什么程度，都有记录，重复执行的概率会明显下降。代价是协调者本身可能成为瓶颈，而且它自己也需要被设计得足够可靠。

这三种方式不是越复杂越好。很多团队一上来就搭协调者，结果发现任务本身很简单，协调开销反而超过了收益。判断标准其实很朴素：如果任务拆开后子任务之间几乎没有重叠，并行就够了；如果步骤之间依赖很强，串行更简单可靠；只有当任务既有并行空间、又存在状态共享和冲突可能时，才值得引入协调者。

任务拆解：边界清晰比角色多更重要

很多多智能体系统出问题，根源不在执行环节，而在拆解环节。角色定义得再花哨，如果任务边界模糊，执行时一定会互相踩脚。

举个例子，假设要做一个“市场调研报告”，你拆成“数据收集智能体”和“报告撰写智能体”。听起来很合理，但问题来了：数据收集智能体在收集时会顺手做初步分析，报告撰写智能体发现数据不够又自己去补查——重复就发生了。真正的拆解应该基于“产出物”而不是“动作”：数据收集智能体的产出是一份结构化数据表，报告撰写智能体的产出是最终文档，两者之间通过数据表交接，谁都不该越界。

拆解时有一个实用原则：每个子任务都应该有明确的“完成定义”，也就是什么情况下这个任务算结束。没有完成定义的子任务，智能体就会凭感觉判断“我是不是做完了”，而感觉恰恰是最不可靠的。比如“收集竞品信息”就不如“收集竞品 A、B、C 的定价、功能列表和发布时间，输出为指定格式表格”清晰——后者让智能体知道做到什么程度就可以停手。

交接确认：防止“我以为你做了”

任务拆解得再清楚，交接环节如果没有确认机制，依然会出问题。两个智能体之间的交接，本质上是状态的传递，而状态传递最怕的就是“我以为你做了，你也以为我做了”。

工程上常用的做法是给每次交接加一道显式确认。比如智能体 A 完成任务后，不是直接把结果丢给 B，而是先写入一个共享状态（标记为“已完成”），B 在开始前先检查这个状态，确认无误后才启动。这听起来像多了一步，但恰恰是这一步能拦住大量重复执行。

更严格的做法是引入幂等机制。所谓幂等，就是同一个操作执行多次和执行一次效果相同。比如给每个业务动作分配一个固定编号，第一次执行时用这个编号写入，后续重试或重复请求都带着同一个编号，接收端先查编号是否已经处理过，处理过就直接返回已有结果。这样即使智能体因为超时重试、或者两个智能体误发了同一个请求，系统也能识别出来，而不是重复执行。

失败回滚：重复执行的最后防线

即便前面都做好了，智能体依然可能出错，所以失败回滚是必须考虑的。关键问题不是“会不会失败”，而是“失败后系统处于什么状态”。

一个常见的坑是：智能体 A 执行到一半失败了，但它在失败前已经写入了部分数据。此时如果系统直接让 A 重试，就可能重复写入；如果让 B 接管，B 又不知道 A 写了什么。所以失败处理的第一步，是让系统能准确判断“这个任务到底执行到哪一步了”。这依赖于前面提到的共享状态和操作编号——有了编号，就能查到这次操作的真实进度，而不是靠猜。

回滚的设计原则是“先查结果，再决定重试还是转人工”。对于读取类操作，重试基本安全；对于写入类操作，尤其是发消息、扣款这类会产生副作用的动作，必须先确认上次是否真的执行成功。如果无法确认，宁可转人工处理，也不要让智能体盲目重试——一次重复扣款远比一次人工介入代价高。

什么时候不值得增加智能体数量

最后回到那个更实际的问题：是不是任务越复杂，就越该多上几个智能体？答案是否定的。

判断标准可以归结为三点：第一，任务拆开后子任务之间是否有足够的独立性，如果拆完发现每个子任务都依赖其他子任务的结果，那并行和协调带来的收益就很小；第二，系统是否具备可靠的共享状态和确认机制，如果没有，多智能体只会放大混乱；第三，协调成本是否低于重复执行带来的损失，如果任务本身很简单，一个智能体加几次重试就能搞定，引入协调者反而得不偿失。

多智能体不是灵丹妙药，它是一套需要配套工程能力的组织方式。在决定增加智能体数量之前，先问自己一个问题：如果现在这套系统里只有一个智能体，重复执行的问题是不是已经解决了？如果连单智能体的状态管理都还没做好，多智能体只会让问题更复杂。

多智能体协作的价值，不在于“用了几个智能体”，而在于系统是否能把“谁该做什么、谁已经做了什么”这件事讲清楚。任务拆解给边界，交接确认给状态，失败回滚给兜底——这三件事做扎实了，再谈增加智能体数量才有意义。否则，多一个智能体，只是多一个重复执行的可能。