大模型多 Agent 协同千万别盲目堆人头：Router+Worker 架构下，上下文膨胀与任务死锁的避坑实践

开头三件事

• 这是什么：这是面向生产级大模型多 Agent（智能体）系统的 Router+Worker（路由分发与执行工蜂）协同架构深度解析与踩坑指南。
• 学了有什么用：帮你彻底搞明白为什么在真实业务里，两个以上的 Agent 互相聊天就会迅速烧光 Token、陷入死锁循环、产生幻觉击穿，并学会用确定性路由、状态机与沙箱上下文解决它。
• 读完能干啥：带走一套可直接上线的无死锁多 Agent 调度编排模板，避开「上下文滚雪球」和「死循环扯皮」两大致命深坑。

---

一、为什么现在人人都在搞多 Agent 协同？

最近无论是技术热榜还是开源社区，「多 Agent 协同」、「Super-agent 双层调度」、「Router+Worker 模式」几乎刷爆了所有后端与 AI 架构师的讨论区。

很多人做 Agent 的心路历程惊人一致： 1. 第一阶段（单 Agent 执念）：把几万字的业务规则、数据库 Schema、二十个外部 API 工具定义全部塞进同一个 Prompt 里，指望大模型既能当客服问答，又能当数据分析师写 SQL，还能当运维调监控。结果呢？不是漏调工具就是参数编造，上下文窗口一长，首字延迟直接飙到 15 秒以上。 2. 第二阶段（盲目堆人头）：既然一个 Agent 扛不住，那就搞「团队协作」！搞一个策划 Agent、一个研发 Agent、一个测试 Agent、一个审查 Agent，建个群让它们自由发消息、互相 Review。

然而，一旦你真把这种「自由群聊式」的多 Agent 推到生产环境，噩梦才刚刚开始： - Token 爆炸：Agent A 说了一句话，Agent B 带着整段历史回复，Agent C 再把前两人的长篇大论全盘抄进自己的 Prompt。不到 3 轮对话，单次请求的 Context 瞬间冲破 30k Token，钱包分分钟被烧空。 - 无限扯皮死锁：Agent A 觉得 Agent B 的方案有瑕疵，提了个意见；Agent B 觉得 Agent A 没看懂，解释了一通；Agent A 又继续挑刺……两个机器人能在系统里无休止地礼貌互怼几百轮，直到触发网关的超时中断。 - 幻觉污染放大：Agent B 偶尔胡诌了一个不存在的接口名或业务字段，Agent C 却把这个胡诌的输出当成确定性输入继续往下执行，错误像雪崩一样层层放大。

打个比方：一个没有明确项目经理（Router）和严密工单机制的研发团队，把 5 个实习生拉到一个群里自由发挥，他们不仅不会交付代码，反而会在群里客气地互相刷屏 500 条「收到」和「您看这样行吗」，最后服务器账单直接爆表。

这就是为什么业界目前沉淀出的最稳健范式，不是无中心的群聊，而是分层确权架构（Router + Worker）。

---

二、Router + Worker 架构核心机制：把自由群聊变成确定性流水线

要解决多 Agent 的无序与混乱，核心就是四个字：各司其职、上下文隔离。

           +---------------------------------------------+
           |                 User Request                |
           +---------------------------------------------+
                                  |
                                  v
           +---------------------------------------------+
           |            Top-level Router Agent           |
           |   (轻量模型 / 确定性规则 / 提取意图 / 分发工单)   |
           +---------------------------------------------+
                            /           \
             工单派发 (隔离上下文)         工单派发 (隔离上下文)
                          /               \
                         v                 v
           +-----------------------+     +-----------------------+
           |   Worker A (SQL专精)   |     |   Worker B (API专精)   |
           |  (仅包含数据字典与执行)  |     |  (仅包含外部接口与鉴权)  |
           +-----------------------+     +-----------------------+
                         \               /
                结构化结果回传 (过滤中间思考流)
                          \             /
                           v           v
           +---------------------------------------------+
           |          State Reducer & Synthesizer        |
           |         (状态聚合器 / 终审并组装最终结果)        |
           +---------------------------------------------+

1. 核心角色的权力界限

• Router（路由器）：它不干重活，也不挂载复杂的工具集。它的唯一职责是意图解析与任务拆解。它读取用户的输入，判断这属于「数据查询」、「外部操作」还是「常规问答」，然后将任务转化成不可篡改的结构化「工单（Task Spec）」。
• Worker（工蜂）：专精垂直领域的微型 Agent。比如 SQL Worker 只知道数据库连接，API Worker 只知道三方系统的 HTTP 调用。最关键的是：Worker 之间严禁直接对话。
• State Reducer（状态归约器）：这是一个确定性的后端逻辑（而非大模型）。它负责回收 Worker 的结构化输出，清洗掉大模型的无用废话（CoT 中间推理），只把关键结果汇总回全局状态。

2. 为什么能防住混乱？

我们用一张对比表来看看它与传统「自由群聊式 Agent」的本质区别：

评估维度	自由群聊式 Multi-Agent	Router + Worker 生产分层架构
拓扑结构	网状全连接（Mesh，复杂度 $O(N^2)$）	星型/树状确定性拓扑（复杂度 $O(N)$）
上下文传递	全员共享全局历史，滚雪球式膨胀	单向派发，工单级上下文切片，阅后即焚
执行流控制	依赖模型自发决定「下一位发言人」	代码状态机（State Machine）强制控制跳转
死循环概率	极高（容易互相挑刺反复确认）	理论为 0（有最大步骤硬限制与单向流转）
成本与延时	随着 Agent 数量指数级增加	随着任务并行度线性收敛，支持 Worker 并发

打个比方：医院看病绝不会让内科、外科、放射科大夫围着你开圆桌会议互相商量两小时。而是分诊台（Router）给你挂具体的科室号，化验室（Worker）拿到检查单只出化验指标，最后由主治医生（Synthesizer）看着化验单下诊断。中间各科室互不打扰，高效而精准。

---

三、生产级无死锁协同代码：基于状态隔离的调度器

下面给出一段在企业生产环境中经过验证的轻量级 Router-Worker 核心调度骨架。它不依赖庞杂厚重的外部框架，直击「上下文污染」和「无限递归」两个痛点。

# 核心调度代码参考：app/core/orchestrator/router_worker.py
import json
from typing import Dict, Any, List

class MultiAgentOrchestrator:
    def __init__(self, router_client, workers: Dict[str, Any], max_hops: int = 4):
        self.router_client = router_client  # 通常是低延迟的小参数模型（如 8B / 14B）
        self.workers = workers              # 专职 Worker 映射表
        self.max_hops = max_hops            # 硬防死锁：最大调度跳数限制

    async def execute(self, user_prompt: str) -> Dict[str, Any]:
        global_context = {"user_query": user_prompt, "history": []}
        current_step = 0

        while current_step < self.max_hops:
            current_step += 1

            # 1. 严格受限的 Router 提示词，仅允许输出标准 JSON 工单
            route_decision = await self.router_client.plan(
                task=user_prompt,
                completed_tasks=global_context["history"]
            )

            # 如果 Router 判定任务已全部完成，直接跳出合成回答
            if route_decision.get("status") == "COMPLETED":
                break

            target_worker_name = route_decision.get("next_worker")
            worker_input = route_decision.get("worker_payload")

            if target_worker_name not in self.workers:
                raise ValueError(f"Router 指定了未注册的 Worker: {target_worker_name}")

            # 2. 关键设计：上下文切片与隔离，不向 Worker 传递 Router 思考过程与全量历史
            target_worker = self.workers[target_worker_name]
            raw_worker_output = await target_worker.run(worker_input)

            # 3. 结果脱敏与剪枝，只保留确定性结论字段，严禁整段对话灌入全局状态
            pruned_result = {
                "step": current_step,
                "worker": target_worker_name,
                "summary": raw_worker_output.get("structured_data"),
                "status": "SUCCESS" if raw_worker_output.get("ok") else "FAILED"
            }
            global_context["history"].append(pruned_result)

        if current_step >= self.max_hops:
            # 触发兜底熔断，防止任务耗尽额度
            return {"code": 504, "msg": "协同调度触发最大步数熔断，已强制终止"}

        return {"code": 200, "data": global_context["history"]}

代码人话解读：这段代码的核心防线在两处——第一是 max_hops 步数硬熔断，任何大模型试图反复调度都会被强制掐断；第二是 Worker 之间完全看不到彼此的对话历史，只接收 Router 切片后的 worker_payload，彻底切断了上下文雪崩的源头。

---

四、真实工程中的两大隐蔽深坑

在脱离了 Demo 阶段后，绝大多数开发者在搭建这套架构时都会踩进以下两个反直觉的坑里。

坑一：把全量历史作为 Context 塞给 Router

很多人的直觉是：「Router 既然是总指挥，那它必须洞察一切，我把前几个 Worker 的全部执行细节、控制台日志、原始接口返回值全堆给 Router，让它看着办。」

反直觉后果： - 注意力分散（Needle-in-a-Haystack 效应）：当 Context 超过 8k Token 时，大模型对任务主线的把控能力呈断崖式下跌。它会被 Worker 日志里的一行非关键 Warning 吸引注意力，从而派发出莫名其妙的诊断任务。 - 首包时间（TTFT）暴涨：每次调度都要重新 Prefill 庞大的历史 Token，整套系统的端到端延迟会从 2 秒恶化到 15 秒以上。 - 正解：给 Worker 增加输出 Schema 校验（如 Pydantic），只允许返回三行以内的结构化摘要（Summary）。Router 只能看摘要，绝不能看流水账。

坑二：Router 的「伪决策幻觉」——循环指派同一 Worker

大模型在遇到复杂未决问题时，天生有一种「防御性妥协」心理：当 Worker A 返回「未查到符合条件的用户」时，Router 往往不会意识到是入参有问题，而是倾向于再次生成一个微调后的任务，重新派发给 Worker A。

反直觉后果： 如果你的系统没有显式的「调用指纹记录」，你会看到 Router 孜孜不倦地让 Worker A 查了 5 次数据库，每次只改动一个无伤大雅的标点符号。表面上看它在「努力思考」，实际上陷入了确定性的逻辑假死。

正解： 引入调用签名散列（Call Signature Hashing）。记录 hash(worker_name + json_payload)，一旦在同一次会话生命周期内出现重复或者极高相似度的调用，状态机必须直接介入抛出错误，阻止大模型继续自嗨。

---

五、架构代价、局限与选型建议

天下没有免费的架构午餐。引入 Router+Worker 双层调度虽然彻底治愈了混乱，但也带来了不可忽视的系统代价：

1. 结构性延迟开销：每一次任务至少需要两次 LLM 调用（Router 拆解一次 + Worker 执行一次）。对于简单的单点问题，这相当于白白增加了 50% 到 100% 的推理耗时。
2. 错误传递脆弱性：一旦 Router 在第一步意图识别时发生偏差（比如把「查询财务报表」划给了「运维监控 Worker」），后端的 Worker 无论逻辑多么严密，产出的也只能是南辕北辙的废品。
3. 维护成本上升：系统从原来维护一个大 Prompt，变成了维护 1 个 Router Prompt + N 个 Worker Prompt + 各自的输入输出 Json Schema。

一句话总结

不要试图用 Agent 之间的自由社交来掩盖业务规则的模糊；高可靠的多 Agent 系统，本质上是把大模型当做微服务节点，用确定性的工作流与状态机去牢牢锁住它的发散边界。

---

技术搭子互动区

你在实际业务中跑多 Agent 时，遇到过最离谱的「机器人死循环」或者「Token 瞬间烧光」是什么场景？你觉得现阶段在企业落地里，是用 LangGraph 这种严格状态图好，还是用 Autogen 这种相对自由的智能体协作更实用？欢迎在评论区聊聊你的踩坑经验！