多智能体六大工程流派解析：从群聊到稳定落地的架构演进

多智能体（Multi-Agent）的概念火了两年多，从一开始“拉一堆Agent进同一个群聊，让它们自己把事情聊出来”的玩票式实践，到如今被拆成各种工程流派，这个演变速度和很多人的认知是脱节的。我做第一个多智能体项目时也踩过群聊模式的坑，那是典型的“看着热闹，跑起来一团乱麻”：十几个角色在同一个上下文里互相客套、重复表态，真正干活的只有一两个。后来我把项目改成更工程化的结构，情况才稳定下来。这篇文章就把目前实践下来收敛出的六大工程流派掰开揉碎讲一讲，重点说清楚每个流派解决什么问题、适合什么场景、有哪些必须避开的坑，给准备上多智能体系统的团队做参考。

1. 群聊式多智能体为什么会被淘汰：我踩过的三个坑

“群聊游戏”这个词其实是个很形象的比喻。最早大家做多智能体的时候，思维很简单：既然一个Agent能力不够，那就多加几个，让它们在一个共享的聊天环境里自由发言。外面看起来像一个专家议事厅，实际跑起来更像一个没有主持人的会议室。

1.1 通信变成广播：上下文窗口被无关发言占据

群聊模式最大的结构性问题，就是每个Agent都会收到所有消息。我做过一个模拟项目，里面放了十个Agent，结果只跑了三轮协作，上下文里就全是“同意楼上”“我觉得也没问题”“我再补充一点”这类信息。这不是Agent不聪明，而是广播式的通信机制在有限上下文窗口里天然会迅速耗尽token。

你可以算一笔账：如果有n个Agent，那么每产生一条消息，其他n-1个Agent都要把它读一遍。假设每个Agent每轮只说一句话，那么一轮下来就是n×(n-1)次消息接收。n等于10的时候，一轮就是90次交互；n等于20的时候，一轮就是380次。上下文窗口不是无限大的，很快就满了，然后最早的关键任务描述反而被挤出上下文。这是通信架构的问题，不是调提示词能解决的。

工程上，我们后来把广播改成了定向消息：谁需要知道什么，就把消息发给谁。这个“最小通信原则”直到今天依然适用于所有多智能体系统。

1.2 完成条件无人定义：Agent在礼貌性循环中打转

群聊模式的第二个坑，是没有“结束”的判定机制。任务到底什么时候算完成？在自由对话里没有人定义这个边界。我当时见过两个Agent互相道谢，来回拉扯了十几轮，其中没有任何一轮产生了有效产出，但token账单一直在涨。

后来我们复盘，发现根因在于：每个Agent的提示词里只写了“你是某个领域专家，请参与讨论”，却没写“任务完成的标准是什么”“谁有权宣布结束”。于是Agent们天然倾向于继续对话，因为对话本身就是它们的输出形式。

在工程化的多智能体系统里，完成条件必须是显式定义的：要么是一个结构化字段标记状态，要么是某个节点产出符合输出Schema就算完成。绝对不能靠LLM“自己觉得聊完了”。

1.3 角色漂移：用一个通用提示词管理十个Agent

第三个坑大家可能体会更深。群聊模式下，为了省事，很多人给每个Agent只换了个名字，提示词主体都差不多，比如“你是某领域的资深专家”。结果跑着跑着，Agent的角色边界就模糊了。

我做过一个内容创作类的模拟项目，原本让一个Agent负责写初稿，另一个负责找资料。跑了几轮之后，负责找资料的Agent开始主动改文章了，写初稿的Agent反而停下来改找资料的“建议”。这就是角色漂移。本质原因是：在自由对话空间里，没有任何机制强制一个Agent只做自己的事，而LLM本身又倾向于“帮用户解决问题”，所以它看到问题就会越界去处理。

要根治角色漂移，靠提示词锁不住，必须在结构上限制每个Agent的输入输出接口。就好比公司里再能干的会计，也不能顺手替出纳去签字，因为流程上不允许。

2. 流程型三流派：流水线、指挥官、层级式怎么把任务推向前

淘汰了群聊模式之后，多智能体系统开始向两个方向分化：一个是管“任务怎么流动”的流程型流派，一个是管“结果怎么可信”的质量型流派。先讲流程型，因为它解决的是多智能体能不能跑起来的问题。

2.1 流水线接力：固定工序+每站质检

流水线可能是最容易被低估但最实用的多智能体模式。它的思路很简单：把一个复杂任务拆成固定顺序的多个阶段，每个阶段由一个Agent负责，上一个Agent的输出就是下一个Agent的输入。这个模式跟工厂流水线几乎一一对应。

我做过一个“自动生成产品说明”的项目，拆成了四个阶段：信息抽取Agent负责从原始素材里提取关键参数，标准化Agent把参数整理成统一格式，文案Agent生成初稿，校对Agent做最终润色。每个Agent只处理自己那一段，输入输出都是约定好的JSON结构，互相之间不聊天，跑起来非常稳定。

这个模式的优点很明显：每个Agent职责单一，出了问题能立刻定位是哪个环节；每个阶段的输出都可以缓存，重复调试时不需要重新跑全流程。缺点是错误会向下游传播——某个阶段产出了垃圾，后面的Agent拿着垃圾继续加工，结果就是垃圾放大。

所以我的实践经验是：流水线必须配质检节点，放在每两个阶段之间。质检节点可以是一个很轻量的规则校验器，也可以是一个专门的审查Agent。校验不通过就退还上一站，加上一个“最多重试两次，再不行走人工兜底”的策略。加了这一层之后，整条流水线的容错能力完全不一样。

class Pipeline: def __init__(self, stages): self.stages = stages def execute(self, payload, validator=None): current = payload for idx, stage in enumerate(self.stages): output = stage.run(current) if validator and not validator.validate(output, stage=idx): raise StageValidationError(f"stage {idx} output invalid") current = output return current

2.2 指挥官式：中央大脑负责拆解与汇总

指挥官式是现在主流框架里最常见的模式之一，英文常叫Orchestrator。它的核心思想是：有一个中央Agent（指挥官）负责理解总体任务、把任务拆成子任务、分派给不同的专业Agent，然后接收各Agent返回的结果进行汇总。子Agent之间不直接通信，所有信息都通过指挥官中转。

这种模式特别适合子任务之间高度异构的场景。比如做一个“行业调研报告”：需要有人收集资料、有人做数据分析、有人画图表、有人写结论。这些子任务的专业方向完全不同，没必要让它们互相聊，只需要一个总指挥去协调就行。

实现的时候，最需要注意的一点是：不要让指挥官用自然语言去“指挥”，而是给它定义一个可执行的计划数据结构。也就是说，指挥官先输出一个JSON格式的任务清单，每个任务包含ID、执行者、输入数据、期望输出Schema。系统拿到这个清单之后再去调用对应的子Agent函数，而不是把自然语言指令直接丢给子Agent。

class Commander: def __init__(self, planner, workers): self.planner = planner self.workers = workers def run(self, mission): plan = self.planner.decompose(mission) results = [] for task in plan["tasks"]: worker = self.workers[task["worker_id"]] result = worker.execute(task["payload"], schema=task["output_schema"]) results.append({"task_id": task["id"], "result": result}) return self.planner.synthesize(plan, results)

指挥官式最大的优点是控制力强、可审计——每个子任务是谁干的、结果怎么样都有记录。缺点是中央Agent是整个系统的瓶颈，所有信息都要过一遍大模型，延迟和成本都相对较高。如果子任务很多，一次任务下来指挥官可能要调用十几次甚至几十次大模型，费用得提前做好心理准备。

2.3 层级式：组织架构就是Agent架构

层级式可以看作指挥官式的递归版本：一个父Agent把任务拆给若干子Agent，子Agent如果发现自己接到的子任务仍然太复杂，它又可以往下拆，形成一棵树。这种模式适合超大规模的任务分解。

我理解它的价值，最好用一个对比来说明：指挥官式适合几十个子任务，层级式适合几百甚至几千个子任务。因为单个指挥官能同时管理的子Agent数量是有限的，超过一定阈值，指挥官的上下文和决策质量都会崩。层级式通过层层分包，让每个节点的扇出控制在一个合理范围内，比如每个节点只管理三到五个下级。

但层级式也有代价：层级越深，故障定位越难。A链路的叶子节点出错了，错误要一层层传回根节点，排查链路很长，而且每一层都可能对错误做二次加工。所以我的建议是：每一层级都必须有验收标准，上级Agent不能只负责“发任务、收结果”，必须验证下级结果是否符合预期，符合了才往上传。没有验收的层级式系统，跑起来就是灾难。

3. 质量型三流派：对抗、表决、市场怎么把结果做可信

流程型流派解决的是“任务怎么走”，但当任务走完，结果质量不行怎么办？这就需要质量型流派——它们不直接组织任务流动，而是通过多智能体之间的博弈、竞争、表决来提升单点输出的可靠性。

3.1 红蓝对抗：生成者与挑刺者的迭代博弈

红蓝对抗是我在所有质量型模式里用得最多的一种。它的结构很简单：一个生成者Agent负责产出结果，一个审查者Agent专门负责挑毛病。审查者挑出问题后，生成者根据反馈修改，修改完再交给审查者看。如此反复若干轮。

这个模式适用于对输出质量要求极高的场景。比如生成一段关键代码、写一份对外承诺文案、生成一份合规说明，这种结果错了代价很大的内容，就很适合让两个Agent互相掰扯。

实践经验里有两个关键。第一，审查者的提示词必须刻意“苛刻”，要明确要求它只找问题、不给情面，甚至可以要求它用最严格的视角去审视。如果审查者的提示词写得像普通读者，那它只会说“整体很好，有一点小建议”。第二，循环必须有上限，我一般设三轮。没有上限的话，两个Agent可能会陷入“你改我挑，我挑你改”的拉锯战，token烧完了还没收敛。

每轮审查意见我都建议保存下来。它不仅能用于事后追溯，也是一份天然的评测集——下次换模型、换提示词，拿这些历史意见跑一遍就能看出有没有进步。

3.2 议会表决：独立候选，集体定夺

议会表决的思路是：同一个任务，不让一个Agent做，而是让好几个Agent各自独立做一遍，然后由一个投票器选出一个最好的结果。它解决的是单Agent输出不稳定的问题——如果一个人判断可能出错，那就找几个人独立背对背判断。

实际落地时最常见的问题是：几个Agent跑出来的结果几乎一样，投票形同虚设。原因是大家用的都是同一个大模型，提示词也差不多，模型天然会往相同的“高概率答案”上靠，这不是真正的多样性。

要让表决有意义，必须人为制造差异。我常用的一种做法是：给每个Agent一个不同的“视角预设”。比如做一条商品描述的分类判断，可以让AgentA以“严格合规”视角审查，AgentB以“用户吸引力”视角审视，AgentC以“中性事实核对”视角判断。三者关心的重点不同，投出来的票才有信息量。

投票器本身可以用一个更小的LLM，也可以直接用规则——比如多数票、加权分数。我更推荐让投票器看到每个候选结果加上它们的置信度分数，而不是只看最终结果。

3.3 市场竞价：用分配机制让Agent“卷起来”

市场竞价的核心是用任务分发机制做优胜劣汰。系统把任务公布到一个类似任务大厅的地方，一批Agent各自提交“竞标信息”，调度器根据它们的报价、置信度、历史信用分来分配任务。做得好的Agent信用分涨上去，接到的任务更多；做得差的Agent逐渐被边缘化。

这个模式非常契合大量同质化短任务的场景。比如审核一批短文本、对一万条记录做信息提取、给一批图片生成标题。任务多、单个任务小、可以并行，这些正好是市场模式擅长的。

不过它也有一个隐患：Agent的“自我报价”不能全信，因为LLM在自评时很容易过度自信。所以必须引入第三方评价——任务完成后，由质检器或任务发布方对结果打分，这个分数回写到信用体系里。调度器排序的时候，用“历史信用分 × 本次置信度 ÷ 成本”这类综合指标，而不是谁喊得最响就给谁。

有一类场景不建议用市场模式：需要多个Agent深度协同、中间状态高度耦合的长任务。因为竞价逻辑是“任务切碎、独立交付”，一旦任务之间强依赖，分配式和自由市场的优势就荡然无存。

4. 六大流派其实共享同一张任务图：拆解与组合方法

前面把六大流派分成了流程型和质量型，但如果你站在系统设计的高度看，会发现它们背后其实是同一张“任务图”，只是连接方式不同。

4.1 看穿六派的底层结构：都是“任务图加上执行器”

流水线的任务图是一条单向直线，前一站连后一站；指挥官式是一张星型图，所有子任务都连到中央节点；层级式是一棵树，从上往下逐级分叉；红蓝对抗是一个双节点的环，生成和审查来回迭代；议会表决是汇聚型，多条独立路径汇聚到投票器；市场竞价则是一张带信用权重的二分图，任务大厅连到多个候选Agent。

这个视角最大的价值在于：它告诉你流派之间不是互斥的，而是可以任意嵌套的。你完全可以在一条流水线里，把其中一个阶段换成指挥官式；也可以用红蓝对抗作为流水线的质检器；甚至用议会表决来做路由——让多个Agent分别判断某个子任务该走哪条路径，然后投票决定。

4.2 混搭实例：一个模拟合规审查系统

我实际做过一个模拟项目，是把三种流派叠在一起用的。整个系统要做的事是批量审核一批商品信息描述是否合规。入口是一个指挥官Agent，它把任务拆成三个子任务：信息抽取、标准比对、表述生成。信息抽取阶段用的是一条小流水线：先做字段抽取，再做格式标准化，这一步用了两个顺序Agent。标准比对阶段用了红蓝对抗：一个Agent负责找出描述里可能违规的点，另一个Agent负责对每个点做复核。最后的表述生成阶段用了议会表决：让三个Agent分别生成三种不同风格的合规表述，再由投票器选一个最稳妥的。

这个系统跑下来的效果，比单Agent或群聊模式都稳定得多。原因很简单：每个环节都用了“恰好匹配该环节问题特征”的模式，而不是一个模式硬扛所有场景。

5. 状态、记忆与幻觉：所有流派绕不开的共同命门

不管你选哪个流派，系统跑起来之后都会撞到三堵墙：状态怎么管、记忆怎么存、幻觉怎么防。这三件事是所有多智能体系统的公共难点，而且越复杂的任务越躲不开。

5.1 状态管理：别让LLM去猜，用显式状态机

多智能体系统里，每个任务的进度必须用显式的状态字段来管理，比如pending、running、blocked、done、failed。不要指望LLM通过看对话历史来判断“现在到哪一步了”。

我踩过一次挺深刻的坑。在一个流水线系统里，任务跑到中间阶段断掉了，重启的时候我们让下游Agent去“读上下文”判断上游有没有完成。结果它对着一份残缺的中间产物自信地说“已完成，请继续”，后面所有产出全歪了。自那以后，我在系统里强制加了一个状态表，任何Agent动工之前先查任务状态，状态不是running就直接拒绝执行。这不是技术炫技，而是最基本的工程约束。

5.2 记忆策略：共享内存与按需检索怎么平衡

多智能体系统常常涉及跨Agent传递信息。这里有个常见的认知误区：大家都以为要给所有Agent配一个大的共享向量库，遇到问题就检索。

实测下来，共享记忆库不是没有问题。当一个Agent把错误信息写进共享库，其他Agent检索到之后就会把它当成事实继续加工，错误在系统里传得比谁都快。我的更稳妥做法是：高频、关键、必须一致的上下文直接用结构化字段在任务间传递，比如订单号、审核结果、输出文本；长尾背景知识才放到检索库里，并且每条记录必须带上来源Agent和置信度。这样即使信息真的错了，也能顺藤摸瓜找到源头。

5.3 幻觉放大：错误会通过协作链滚雪球

多智能体系统有一个被低估的风险，我称之为“幻觉放大”。单个Agent生成内容时有幻觉概率，假设平均是5%；但如果这个结果被下一个Agent当作事实继续加工，就相当于错误信息又过了一遍生成模型。经过四个环节之后，仍然完全不出错的概率只有(0.95)^4，约等于81.4%，也就是说接近两成的概率在某个环节出问题。这还没算协同过程本身带来的新错误。

要遏制幻觉放大，我推荐三个做法：第一，每个Agent输出尽量附带置信度判断，不是让它猜，而是让它对拿不准的部分明确标记；第二，在关键事实节点接入校验工具，比如查库、查接口、做规则校验，需要可靠，别让Agent空口说白话；第三，在汇总节点增加一道“事实核对”工序，把结果里不合理的部分单独拎出来复核一次。做了这三道之后，系统的可靠度会肉眼可见地上一个台阶。

6. 选型自检清单与生产环境高频坑

聊完了流派的原理，最后落到实际操作。很多人会问：我到底该选哪个流派？我建议不要凭感觉，而是拿任务的特征去套决策表。

6.1 根据任务特征选择流派：一张可复用的决策表

这张表不是金科玉律，但它能帮你快速找到第一个可以开工的模式。我的习惯是：先用最简流水线把数据流跑通，再根据暴露出来的问题，增量加入其他流派。比如结果质量不行就加红蓝对抗，分支判断不准就加表决，单点压力太大就换指挥官或层级。

6.2 生产环境的四个高频坑与对策

最后分享四个我在生产环境反复遇到的真实问题，每条都是真金白银换来的教训。

第一个坑是子Agent死循环。一个Agent在处理任务时出了意外，但调用它的代码没有设超时上限，它就一直在重试。我等账单出来才发现，光那一个任务就烧掉了平时两倍的钱。对策很简单：每个Agent调用必须带超时时间和最大重试次数，超时直接标记任务失败，走人工兜底。

第二个坑是多个Agent并发写同一份数据。一次跑多个Agent并行处理，它们同时往同一个文件、同一个数据库表里写结果，互相覆盖。解决思路是给每个Agent分配独立的命名空间：工作目录分开、数据库按Agent维度分表、共享资源用队列或者带锁的写入接口，规定只能读共享资源，不能并发写。

第三个坑是输出格式不稳定。即使提示词里写了“必须输出JSON”，总有Agent偶尔夹带解释文本。最忌讳的做法是发现解析失败就把原文重新丢给同一个Agent再问一遍，它会大概率再犯同样的错。正确做法是写一个格式纠正器：提取被反引号包住的片段、自动补全缺失的括号引号，再进JSON解析。这一步看似笨拙，但能把格式通过率从九成拉高到接近百分百。

第四个坑是评测指标模糊。多智能体系统上线之后，老板问“效果到底怎么样”，如果只有一两个最终样例，根本没法回答。我现在会要求每个环节都留痕：过程和结果日志、单环节通过率、平均迭代轮数、平均响应耗时。没有过程数据，就等于没做。有了这些指标，后面无论该提示词还是换模型，至少能知道变化发生在哪儿。

多智能体系统这个方向，真正难的地方从来不是“让几个Agent聊起来”，而是“让整个系统在约束下稳定地交出结果”。我跑过不少模拟项目之后越来越觉得，流派只是工具箱里的扳手和螺丝刀，关键还是你自己对任务结构的判断。一个最简单的流水线，配上一个明确的状态表和一套保留过程日志的机制，往往比一个看起来很花哨、但没人能说清楚它到底怎么收敛的系统靠谱得多。