5.1 单智能体的天花板：什么时候需要团队

5.1 单智能体的天花板：什么时候需要团队

本节摘要：多智能体是过载的解药，不是高级的装饰。本节列出单体系统到达极限的四类信号——工具过载、角色混杂、误差滚雪球、视角单一——同时讲清组队的真实代价，并给出一个最小路由器实现：多数"伪需求"在路由器这一层就该止步。

工具从五个加到二十个之后，很多团队观察到同一个现象：智能体变笨了。不是模型换了，是选择环境变嘈杂了——每轮决策都要在二十个工具里挑一个，描述文本挤满窗口，相似工具互相干扰。这类问题在单体架构里无解，因为病根就是"一个上下文装太多事"。

四类过载信号

工具过载：选对率随工具数下滑。实测经验，工具超过十个，选中准确率开始可感知地下降；超过二十个，模型经常在语义相近的工具间摇摆。解法是按领域分家——订单类工具归订单智能体，物流类归物流智能体，每个只背自己那十来个。

角色混杂：一份系统提示词打多个工。"你既要做数据清洗，又要写营销文案，还要符合法务口径"——这样的契约没有模型能稳定执行，因为三种身份的判断标准互相冲突。拆成三个角色各管一段，每个契约重新变得锋利。

误差滚雪球：长链任务里无人校对。单上下文里，第 3 步的小偏差到第 12 步可能被放大成方向性错误，而且没有第二双眼睛。独立的审校角色拿到的上下文更干净（只有结论与依据，没有过程噪声），反而更容易发现毛病。

视角单一：缺自我批评。同一个上下文里的模型既当运动员又当裁判，倾向于为自己的产出辩护。让一个"只挑毛病"的角色用独立上下文重审，是给系统加了一道外置的反思回路。

代价清单：组队不是免费的

⚠️ 常见坑：为了架构图好看而组队。评审会上"我们用了多智能体"确实好听，但如果两个智能体其实可以合并成一个函数调用，多出来的那一份就是纯亏损——通信成本实打实，产出原地踏步。

路由器：多数场景的止步线

判断完成之后，大量真实需求其实只需要按领域分流，不需要真正的协作——分流之后每个智能体独立干活，互不通信。这就是路由器模式，它以多智能体的形貌出现，复杂度却与单体无异：

ROUTES = [
    (["订单", "退款", "发货"], "order_agent"),
    (["报销", "发票", "差旅"], "expense_agent"),
    (["代码", "报错", "部署"], "dev_agent"),
]

def route(message: str) -> str:
    scores = llm.classify(message, labels=[r[1] for r in ROUTES] + ["other"])
    if scores.top == "other" or scores.confidence < 0.7:
        return general_agent(message)        # 低置信度兜底给通用助手
    return dispatch(scores.top, message)     # 高置信度定向派发
​

路由器与真协作的分界线是队员之间要不要交换中间结果。不交换，就是路由器加若干单体，放心用；要交换（撰稿人需要调研员的清单才能动笔），才进入下一节的协议与拓扑话题。

案例：一次从单体到分家的改造

背景：内部知识助手单体运行三个月，用户投诉集中在两类："问合同的问题，它用产品手册的口径回答"和"工具明明有却查不到"。

操作：盘点发现单体注册了十八个工具，系统提示词混着法务、产品、IT 三套口径。改造方案：按领域拆成三个智能体（法务、产品、IT），前面加路由器；每个智能体只保留本域工具（平均六个）与本域口径；跨域问题由路由器并行问两个域再合并。

结果：工具选中错误率从一成三降到百分之二以下；口径串味投诉消失；总调用成本上升约四成，但重试与返工的隐性成本下降更多，总账为负。

解读：这次改造里"拆"解决的是上下文质量，路由器解决的是入口分流——全程没有用到队内协作。这提示一个务实的顺序：先分家（路由器），不够再协作（协议与拓扑），最后才考虑辩论这类重型机制。复杂度阶梯要一级一级爬，跳级的多智能体项目大多死在调试上。

变式：拆分维度不止领域一种。按流程阶段拆（收集、加工、审核）适合内容加工链；按立场拆（提案者、批评者）适合决策类任务。选哪个维度的判断依据是：哪个维度上的错误最伤业务，就在那个维度上设检查岗。

本节要点回顾

• 四类过载信号：工具多到选错、角色杂到契约失效、误差无人校对、视角缺乏批评——出现即考虑分家。
• 组队是税：通信成本、误差接力、调试复杂度、一致性风险，四项都要计入收益账。
• 路由器止步：不需要队员交换中间结果的场景，路由器加分家就够，别急着上协议。
• 拆分维度跟着风险走：哪个维度出错最伤业务，就沿哪个维度设角色与检查岗。

决定组队之后，第一件工程事是让队员把话说清楚——下一节的消息协议与协作拓扑，就是队伍的普通话。

信号误判：两类"假天花板"

四类过载信号之外，有两种容易被误判成"需要组队"的情况，值得单独辨认。

第一种，提示词写不动了。单一角色的系统提示词膨胀到几千字、规则互相打架，真实病因往往是任务定义不清——"既要又要"的需求被压给了同一个角色。先做需求拆解（哪些要求其实属于不同的子任务），很多情况下拆完发现两个子任务根本不需要同时在线，一个路由器或两次顺序调用就解决了。

第二种，想用多智能体解决评测暴露的质量问题。评测显示回答质量不稳，团队的第一反应常常是"加一个审核智能体"。但质量不稳的根因若在工具返回太脏或检索不准，加角色只是给脏数据多加一道转述——每次转述都是一次失真机会。正确的次序依然是本册的定位三步：先归因（第 1 章）、再修对应模块、组队永远是最后的选择。

辨别真假天花板的试金石：把两个角色的任务分别交给两个独立的单体智能体跑，结果是否比合并跑更好？ 如果独立跑没有增益，协作层不会凭空创造增益——它只会增加通信与失真的机会。