我先说个真实场景。某团队在做一个企业知识问答平台最初只有两个智能体一个负责从内部文档库里检索资料另一个负责把资料组织成口语化回答。两个智能体通过消息互相配合效果确实不错。后来需求变多陆续加入了表格解析、数据校验、多渠道回复、翻译、敏感信息识别等模块前前后后凑了十五个智能体彼此之间可以自由拉群聊天。结果第一次完整联调就翻了车用户提了个带歧义的问题检索智能体和校验智能体在群里来回踢皮球整整转了十几轮最后用户端直接超时。这个案例特别典型。你去看现在各类多智能体框架的示例两三个智能体互相调工具、互相传消息确实轻轻松松。但一旦规模上了十个、二十个还沿用自由聊天式的协作模式问题就会集中爆发。这篇文章我会围绕多智能体越多越需要一个总调度这条线讲清楚失控到底发生在哪一步调度器应该管哪些事以及我用一个模拟项目做落地改造时的完整设计和踩坑记录。如果你也在做多智能体应用或者已经被一堆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_requestuser_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_retries2。一旦某个智能体反复校验不通过状态就转移到FAILED调度器不再无脑重试而是启动降级策略——换一个备用智能体或者直接向用户说明该环节失败原因。这就把原先两个智能体无限互踢的噩梦变成了可控的有限次重试。3.3 三个关键机制轮次预算、超时熔断、信息摘要下面这三个机制是我在真实运行环境中练出来的保命招缺一个都会有问题。轮次预算。整个任务执行流程要设置一个全局执行轮次上限。比如一个用户请求最多拆成8个子任务每个子任务最多重试2次整个流程超过20个执行轮次就强制终止。我见过最典型的反面教材是某个智能体一直返回我这边需要更多信息另一个智能体一直反问你需要什么信息两边在轮次上无限消耗。有了轮次预算走到上限就直接终止然后让调度器生成一份部分结果失败说明返回给用户至少不会卡死。超时熔断。智能体调用模型接口时单次响应经常会发生意外延迟。如果不做超时控制整个链路会被一个慢吞吞的智能体拖垮。我给每个智能体设了单步超时阈值比如代答任务的智能体最多等30到60秒超过就把这次调用标记为超时调度器直接走降级逻辑。这里也建议引入连续失败计数如果某个智能体连续三次调用异常调度器会把它暂时移出路由表不参与后续任务。信息摘要。这是我认为性价比最高的机制。很多多智能体框架都支持直接把上一步的输出原封不动传给下一步听着很全量保真实际上会让上下文越滚越长连带着token消耗猛增而且智能体反而容易被冗余信息干扰判断。我在调度器里加了专门的摘要模块每个子任务产出后摘要模块会把它压缩为3到5条要点再更新进全局上下文。实测下来token成本能降三到四成而任务完成准确率反而小幅提升。4. 团队规模与调度策略的匹配不变的模式没有不变的优势4.1 三种协作模式的适用边界直接调用、群聊协作、总调度我在多个项目里反复调整过协作模式概括下来有三种直接调用、群聊协作、总调度。它们没有绝对的优劣关键看规模。直接调用适合极少数固定流程比如只有三四个智能体而且流程固定不变A永远调BB永远调C。这种场景写一个直连调用就够了引入调度器反而增加复杂度。群聊协作适合讨论型、探索型任务比如头脑风暴、多方案对比几个智能体围绕一个开放问题来回交流目的不是一次性交付而是在碰撞中找到思路。这种场景如果强行套调度器会让探索欲望被流程限制住反而不好。总调度适合大体量、流水线型、对稳定性和可追溯性有要求的任务流。比如我做的知识问答平台任务拆解、检索、校验、汇总环环相扣任何一个环节出错都会影响最终结果。此时必须用一个统一的调度器来兜底。我在模拟项目X中就是直接调用和群聊协作跑偏之后才下决心换成总调度模式。我把三种模式的对比整理成了表格方便快速参考模式适用智能体数量优缺点典型场景直接调用3-5个实现最快、开销低但流程写死扩展性差固定流水线A调B群聊协作5-10个灵活、适合探索容易出现死循环和上下文失控开放讨论、方案对比总调度10个以上可控、可追踪、可降级但需要额外开发调度层复杂检索、组合任务链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时就是从两个智能体聊得很好一路走到十五个智能体乱成一锅粥再一步步收敛到一个清晰的调度器 各司其职的智能体。调度器不是要取代各个智能体的能力而是给它们一条更清晰的前进路径。多智能体越多这种清晰就越值钱这大概就是总调度最朴素的意义。