多智能体失控？一个总调度器让Agent协作不再乱

我先说个真实场景。某团队在做一个企业知识问答平台，最初只有两个智能体：一个负责从内部文档库里检索资料，另一个负责把资料组织成口语化回答。两个智能体通过消息互相配合，效果确实不错。后来需求变多，陆续加入了表格解析、数据校验、多渠道回复、翻译、敏感信息识别等模块，前前后后凑了十五个智能体，彼此之间可以自由"拉群"聊天。结果第一次完整联调就翻了车：用户提了个带歧义的问题，检索智能体和校验智能体在群里来回"踢皮球"，整整转了十几轮，最后用户端直接超时。

这个案例特别典型。你去看现在各类多智能体框架的示例，两三个智能体互相调工具、互相传消息确实轻轻松松。但一旦规模上了十个、二十个，还沿用"自由聊天"式的协作模式，问题就会集中爆发。这篇文章我会围绕"多智能体越多，越需要一个总调度"这条线，讲清楚：失控到底发生在哪一步，调度器应该管哪些事，以及我用一个模拟项目做落地改造时的完整设计和踩坑记录。如果你也在做多智能体应用，或者已经被一堆Agent互相调来调去搞得头痛，这篇应该能给你一些可操作的经验。

1. 从两三个Agent到十几个Agent：失控是从哪一步开始的

1.1 自由互连模式：消息传消息，看起来很方便

早期做多智能体，最直觉的方案就是让所有智能体直接连在一起，谁有需求就给对方发消息。比如A发现资料缺一块，就直接给B发一条"帮我补查一下XX资料"，B查完再把结果发回去。没有中间层，没有统一编号，整个协作网络就像办公室里十几个同事用工作群同步信息。

这种模式被很多示例项目称作"群聊协作"或"对等协作"，它的优点很明显：实现快，改动小，单个智能体的接入成本就是"学会发消息"。我在模拟项目X里也先用了这个模式，初期只有三四个智能体时，响应快、逻辑直观，出问题也好定位，就是顺着消息链路查一遍而已。

但这里有个很容易忽视的前提：群里人少的时候，大家共享的上下文是有限且清晰的。A给B发了什么、B回了什么，彼此都记得住。可智能体数量一多，消息链的复杂度呈指数上升，你很难再凭人脑理清"这句话是谁说的、它针对的是哪一轮的哪句话"。这时候问题就开始埋雷了。

1.2 规模扩大后暴露的三个死穴

我的模拟项目X在智能体数量增加到十个以上后，接连暴露了三类问题，我分别起了名字：目标冲突、上下文各执一词、死循环空转。

第一类，目标冲突。两个智能体各自拿到了不同的中间目标，又都把"任务完成"的判定权握在自己手里。比如检索智能体认为"找到五份文档"就算完成，而校验智能体认为"文档里必须包含去年同期数据"才算合格，两边都觉得自己没做错，谁也不肯让步。用户只看到消息在群里滚来滚去，系统状态却卡在原地。

第二类，上下文各执一词。自由互连时，每个智能体只看到自己收到的局部消息，看不到全局任务背景。假设用户问的是"华东区第二季度销售额"，翻译智能体只收到"第二季度"三个字，可能直接按"第二季度"翻译，丢了"华东区"这个限定词。更麻烦的是，B在回复C时，默认C知道前面的讨论内容，但C的上下文窗口里可能根本没有这部分信息，于是产出的结果完全跑偏。

第三类，死循环空转。这是最让人崩溃的。两个智能体互相认为对方"应该再做一步"，持续互发消息，每一轮都消耗token和时间，但没有任何实质进展。我调过最夸张的一次，一个简单的任务在两个智能体之间循环了四十多轮，费用和延迟全部爆炸。

1.3 为什么数量越多越需要一个总调度

有人可能会问：那是不是我写代码时多做一些消息约束，或者给每个智能体加更详细的系统提示词，就能解决？说实话，我试过，能缓解，但治标不治本。因为问题的本质是信息熵和协调成本在同步增长。

你可以这么想：两个智能体协作时，需要对齐的信息只有一条链路；五个智能体时，可能的链路组合就有几十种；十五个智能体时，互相之间全部连起来，协调复杂度已经不是人能维护的了。你靠写死在代码里的"规则"去约束，等于在给每个智能体单独上一道枷锁，结果就是系统变得脆弱、难以扩展。

这时候最自然的思路就是：把"下一步该轮到谁干活"的决策权，从四通八达的消息转发网络里抽出来，交给一个统一的位置来管理。这个位置就是我说的总调度。它不直接干活，不参与具体业务推理，只负责看着全局任务，决定任务怎么拆、拆完派给谁、谁的结果需要汇总、什么时候算收尾。说白了，它相当于一个"意图路由器"，让每个智能体只管自己手里的活，而不需要操心整个任务链条。

2. 总调度器到底管什么：不是审批流，而是"意图路由器"

2.1 把"谁来做"的决策收归一处：任务分解与路由

我在设计模拟项目X的调度层时，第一件事就是把"任务分配"从各个智能体手里收走。以前检索智能体觉得缺资料，可以直接喊翻译智能体帮忙；现在不行，所有这类跨智能体的协作需求，必须先回到调度器，由调度器统一判断该不该调、调谁、以什么顺序调。

具体来说，调度器接收用户的自然语言请求后，先做一次任务拆解。比如"查一下某某产品去年的退货率，并和今年第一季度对比"，这个请求会被拆成三块：检索退货数据、检索今年数据、对比分析并生成报告。拆完之后，调度器给每个子任务打一个"能力标签"，再去匹配对应的智能体。

这一步看着简单，但实现上有讲究。拆解粒度太粗，一个子任务里仍然混着多个职责，智能体还是会懵；拆得太细，调度开销大，来回传递的消息反而拖慢整体速度。我实测下来，比较合理的标准是：每个子任务应该能由一个智能体独立完成，且不需要中途再向其他智能体求助。如果拆完发现某个子任务内部还要"查数据→算比率→翻译→写结论"，那说明粒度还不够细。

路由方面，调度器维护一张能力注册表，每个智能体在接入时声明自己能干什么、需要什么输入、产出什么格式。调度器根据任务标签做匹配。我建议在这张表里标记一个"置信度"或"优先级"字段，因为有时候多个智能体都能处理同一类任务，但精度差异很大。比如两个智能体都能做文本摘要，一个做通用摘要，一个做金融术语摘要，用户问的如果是季报分析，调度器就必须优先派给后者。

2.2 为每个任务划清边界：上下文隔离与汇聚

这一步是自由互连模式遗留下来的重灾区。以前每个智能体都自己拼一堆上下文，现在调度器要把上下文这件事管起来。

我倾向的做法是"两段式上下文"：第一段是全局上下文，保存用户原始诉求、已确认约束、重要中间结论，所有智能体都可以读；第二段是局部上下文，保存当前子任务相关的输入、中间过程、产出结果，只有正在执行该任务的智能体能读写。调度器相当于一个门卫，控制两段上下文之间的流转。

举个例子，用户说"对比某产品去年和今年的退货率，重点看华东区电商渠道"。全局上下文里要保留"去年""今年""退货率""华东区""电商渠道"这几个要素，而检索任务拿到的局部上下文是"某产品、退货率、去年年度数据"，另一个检索任务拿到的是"某产品、退货率、今年数据"。等两个检索任务都返回结果了，调度器再把它们的产出合并进一个新子任务的局部上下文里，交给分析智能体做对比。

这里有个特别容易踩的坑：局部上下文的"记忆时长"设置。如果调度器把前一个子任务的原始输出原封不动扔给下一个子任务，上下文会越来越大，而且夹杂不少无用信息。我在模拟项目X里的做法是，每次任务切换时做一次"上下文压缩"——把上一步的输出提炼成几条结论性文字，再交给下一步。这一步对成本和准确率的改善都很明显，后面会细说。

2.3 让智能体有主次之分：主从协作与结果校验

总调度还存在一个容易跑偏的设计方向：把调度器变成"逐层审批的领导"。有些人会设计成每个子任务执行完都要经过调度器层层审批，用户一句话要等好几轮确认。实际做下来，延迟高得没法用。

我更推荐"主从协作"模型：调度器像一个有点强势的主持人，它不控制每个智能体内部怎么做，只控制任务流转的顺序和边界。怎么理解呢？主持人宣布"现在由检索组发言"，检索智能体拿到话筒就说话，说完把话筒交回主持人；主持人再决定"分析组发言"还是"需要再补一次检索"。整个流程只有主持人决定顺序，智能体之间不允许直接私下换话筒。

除了控制发言顺序，调度器还要做结果校验。以前两个智能体互相争执，本质是缺少一个裁判角色来判断"这个结果到底行不行"。调度器接了这个活之后，我会让它做三件事：格式校验、完整性校验、与全局约束的一致性校验。格式校验最简单，检查输出JSON字段是否齐全；完整性校验是看子任务要求的几项结果是否都返回了；一致性校验则是看产出的内容是否和用户的原始诉求相匹配，有没有偷换概念。如果校验不过，就打回重做，并且把失败原因写明。

3. 落地实现：用状态机驱动整个任务流转

3.1 调度器的输入与输出：任务描述怎么变成执行计划

理论说得再多，不落地都是空的。我拿模拟项目X的实际代码结构讲一讲调度器是怎么实现的，这部分我也踩了不少坑，现在这个版本相对稳定。

调度器的输入只有一个：用户的自然语言请求。但内部第一步不是直接调智能体，而是先构建一个"任务计划"。让我用一段简化的Python伪代码表示调度器的核心流程：

class Orchestrator: def __init__(self, registry): self.registry = registry # 智能体能力注册表 def handle(self, user_request): # 1. 任务拆解 plan = self.decompose(user_request) # 2. 构建全局上下文 global_ctx = Context(original_request=user_request) # 3. 按顺序执行每个子任务 for step in plan.steps: agent = self.route(step, self.registry) local_ctx = global_ctx.build_local(step.inputs) result = agent.run(local_ctx) # 4. 调度器统一校验 if not self.validate(step, result): result = self.repair(agent, step, local_ctx, result) # 5. 压缩并合并上下文 global_ctx.merge(step.output_key, self.compress(result)) return final_assembler(global_ctx)

这个流程的核心是：所有智能体都在调度器的循环里执行，而不是自己主动启动。智能体A不能直接调用智能体B，它只能把结果返回给调度器，调度器根据计划决定下一步派谁。这一点在代码架构上就要强制保证，不要在Agent的提示词里靠"自觉"去约束。

3.2 状态机驱动：每个Agent的动作都走"调度-执行-回报"循环

我再往下细化一层。任务的执行流程本质上是一个状态机，我用四个状态来管理每一个子任务：

• PENDING：任务已拆解，但还没分配给智能体。
• RUNNING：智能体正在执行，调度器在等待返回。
• WAITING：结果已返回，正在等待校验或上下文汇聚。
• DONE：校验通过，结果已合并进全局上下文。

调度器会维护一个任务状态表，每完成一次状态迁移就记一条日志。这对排查问题特别重要。以前自由互连时，出了Bug只能顺着消息聊天记录猜流程；现在直接看状态表，一眼就能看出哪个子任务卡在哪个环节。

状态机对"死循环"问题也有一个天然的优势：调度器可以为每个子任务设置最大重试次数，比如max_retries=2。一旦某个智能体反复校验不通过，状态就转移到FAILED，调度器不再无脑重试，而是启动降级策略——换一个备用智能体，或者直接向用户说明该环节失败原因。这就把原先"两个智能体无限互踢"的噩梦，变成了可控的有限次重试。

3.3 三个关键机制：轮次预算、超时熔断、信息摘要

下面这三个机制，是我在真实运行环境中练出来的"保命招"，缺一个都会有问题。

轮次预算。整个任务执行流程要设置一个全局执行轮次上限。比如一个用户请求最多拆成8个子任务，每个子任务最多重试2次，整个流程超过20个执行轮次就强制终止。我见过最典型的反面教材是：某个智能体一直返回"我这边需要更多信息"，另一个智能体一直反问"你需要什么信息"，两边在轮次上无限消耗。有了轮次预算，走到上限就直接终止，然后让调度器生成一份"部分结果+失败说明"返回给用户，至少不会卡死。

超时熔断。智能体调用模型接口时，单次响应经常会发生意外延迟。如果不做超时控制，整个链路会被一个慢吞吞的智能体拖垮。我给每个智能体设了单步超时阈值，比如代答任务的智能体最多等30到60秒，超过就把这次调用标记为超时，调度器直接走降级逻辑。这里也建议引入"连续失败计数"，如果某个智能体连续三次调用异常，调度器会把它暂时移出路由表，不参与后续任务。

信息摘要。这是我认为性价比最高的机制。很多多智能体框架都支持直接把上一步的输出原封不动传给下一步，听着很"全量保真"，实际上会让上下文越滚越长，连带着token消耗猛增，而且智能体反而容易被冗余信息干扰判断。我在调度器里加了专门的摘要模块，每个子任务产出后，摘要模块会把它压缩为3到5条要点，再更新进全局上下文。实测下来，token成本能降三到四成，而任务完成准确率反而小幅提升。

4. 团队规模与调度策略的匹配：不变的模式没有不变的优势

4.1 三种协作模式的适用边界：直接调用、群聊协作、总调度

我在多个项目里反复调整过协作模式，概括下来有三种：直接调用、群聊协作、总调度。它们没有绝对的优劣，关键看规模。

直接调用适合极少数固定流程，比如只有三四个智能体，而且流程固定不变，A永远调B，B永远调C。这种场景写一个直连调用就够了，引入调度器反而增加复杂度。

群聊协作适合讨论型、探索型任务，比如头脑风暴、多方案对比，几个智能体围绕一个开放问题来回交流，目的不是一次性交付，而是在碰撞中找到思路。这种场景如果强行套调度器，会让探索欲望被流程限制住，反而不好。

总调度适合大体量、流水线型、对稳定性和可追溯性有要求的任务流。比如我做的知识问答平台，任务拆解、检索、校验、汇总环环相扣，任何一个环节出错都会影响最终结果。此时必须用一个统一的调度器来兜底。我在模拟项目X中就是直接调用和群聊协作跑偏之后，才下决心换成总调度模式。

我把三种模式的对比整理成了表格，方便快速参考：

4.2 调度器自身的两个瓶颈：调度负载与上下文成本

总调度模式不是想当然地"把所有逻辑往中间层一塞"就完事。调度器本身会变成新的瓶颈，主要有两个。

第一个是调度逻辑的执行开销。如果调度器本身也是调用大模型来决策"下一步派谁"，每轮都要等模型响应，那整个系统延迟会被调度器拖起来。我试过用大模型做调度决策，准确率确实好，但用户等不起。后来的做法是：规则优先、模型兜底。百分之七八十的任务，用关键词匹配和意图分类规则就能确定路由；只有规则拿不准的时候，才调用模型做决策。这样既保持了灵活性，又控制了响应延迟。

第二个是上下文成本。调度器要维护全局上下文、局部上下文、任务状态表，这本身就是一笔不小的资源消耗。如果每个任务都保留完整历史记录，撑不了几个请求内存就爆了。我的做法是分级留痕：最终答案、关键中间结论、轮次日志记全量；原始消息体、局部临时数据只做短期保留，任务完成后定期清理。你不需要为所有过程数据做永久存储，能追溯到关键节点就够了。

5. 我在真实运行中撞过的墙：三个典型事故复盘

5.1 事故一：两个智能体互踢皮球，日志还原了全过程

这是模拟项目X第一次正式联调时的事故。用户问了一个比较模糊的问题，大概是想了解某个产品线的退货原因占比。检索智能体找到了一些售后工单，但它认为"这部分数据需要质检部门确认"，于是给质检智能体发消息；质检智能体认为"这属于业务运营口径问题，应该转回检索组"，于是又发回消息。

由于当时没有调度器，两个智能体的消息互相转发，每一次转发都触发新一轮调用。我在日志里数了一下，这个任务转了四十多轮，最后是因为用户等不了点击了取消，系统才停下来。费用倒还在其次，关键是这种事故会让用户对整个系统彻底失去信任。

后来上了总调度，我做了限制：任何子任务最多执行两次"向其他智能体请求补充信息"的操作，超过就强制执行当前结果并做标注。这不光从架构上解决问题，也逼着每个智能体锻炼"在信息不全时给出初步判断"的能力，而不是习惯性甩锅。

5.2 事故二：上下文串味，新任务用了旧任务的数据

还有个很隐蔽的坑：上下文隔离没做彻底。有一次用户先问了A产品数据，紧接着又问B产品数据，系统在回答第二个问题时，居然把A产品的某条结论写进了B产品的报告里。

查了半天才定位到根因。原来是没有调度器时期的后遗症：全局上下文只有一个共享字典，新的子任务执行时，会把旧任务遗留的键值对当成有效上下文一并读取。智能体分不清哪些数据属于当前任务，只好全部纳入推理范围，于是串了味。

修复方式就是我前面提到的两段式上下文。共享字典只保存当前任务的核心诉求和约束条件，从上一任务带入的数据必须在任务切换时清理或做明确标记。我在上下文里加了一个task_id字段，所有局部数据都绑定这个字段，调度器提取上下文时先按task_id过滤一遍。这样再也不会出现新任务读到旧任务数据的情况。

5.3 事故三：调度器本身成了单点，一挂全挂

总调度模式最大的风险就是调度器成为单点故障。调度器一旦进程崩溃，所有智能体都停摆。我早期版本没有做任何高可用措施，有一次升级调度逻辑时引入了一个异常，结果整个知识问答平台二十分钟内完全无法响应。

后来我做了两个调整，目前一直在用。一是给调度器加"看门狗"进程，定期发送心跳探测，如果发现调度器无响应，就触发自动重启，并把正在执行的任务标记为中断，恢复后统一走失败重试逻辑。二是做"降级预案"：如果调度器连续多次重启后仍然异常，就切换到简化模式，直接按预设模板把任务分发给几个核心智能体，暂时跳过复杂校验。这套设计不能保证系统完全不挂，但能把故障恢复时间从二十分钟压到一两分钟。

5.4 一个反直觉的实测结论：不是所有项目都需要总调度

最后说一个可能有点反直觉的经验：不是智能体一多就必须立刻上总调度。

我做过一个并行收集型项目，十几个智能体各自去不同来源采集数据，彼此之间几乎没有依赖，最后把结果汇总即可。这种场景，引入总调度收益不大，反而因为多了调度层增加延迟和成本。我建议的判断标准是：看智能体之间是否存在频繁的、多轮的依赖协作。如果任务是"采集后汇总"，群聊协作足够；如果任务是"检索后要分析、分析后要校验、校验后还要翻译"，这种多轮依赖链路，才真正需要总调度。

我还发现一个规律：引入调度器的最佳时机，不是等你已经出了事故再来补，而是当你在设计阶段就发现"这里的流程需要A等B的结果、B要等C的确认"时，就值得考虑加调度层。与其等自由互连模式爆雷后重构，不如在任务依赖变复杂的苗头刚出现时就动手。这个判断力，可能比任何具体的技术细节都更值钱。

我在做模拟项目X时，就是从"两个智能体聊得很好"一路走到"十五个智能体乱成一锅粥"，再一步步收敛到"一个清晰的调度器 + 各司其职的智能体"。调度器不是要取代各个智能体的能力，而是给它们一条更清晰的前进路径。多智能体越多，这种清晰就越值钱，这大概就是"总调度"最朴素的意义。