多智能体路由评测解析：指标与落地指南 核心结论前置当前多智能体系统的路由评测正从任务完成率单一指标向效率—质量—成本三维联合评估演进。RouterBench、BFCL V4 和 MasRouter 等框架各有适用边界但没有一个能开箱即用地覆盖真实企业场景。本文系统梳理评测维度体系、主流框架的实测数据表现与局限性并给出选型建议。问题的根源路由评测为何如此棘手1.1 业务痛点多智能体系统已逐渐从学术原型走向企业落地。医疗问答、代码生成、客服自动化、金融分析……越来越多的垂直场景在用多个专业 Agent 协作完成复杂任务。路由层——决定哪个任务交给哪个 Agent、以什么拓扑结构协作——直接决定了系统的最终表现。然而工程团队普遍反映同一个困境调了半天的路由策略换个数据集就崩。路由模型在内部测试集上准确率 92%上线后实际意图覆盖度不足 70%。指标好看钱烧得也很快。某些路由方案把所有任务都推给最强模型评分高但 Token 成本是能用方案的 35 倍。没有统一的基准方案之间无法横向比。A 团队说自己的路由准确率 95%B 团队说自己 88%用的却是完全不同的测试集和评分口径。这三个痛点指向同一个技术缺口缺乏覆盖任务难度—资源约束—质量下界的系统性评测方法论。1.2 路由评测的独特挑战普通模型评测已有成熟体系MMLU、HumanEval 等但多智能体路由评测面临三重额外复杂度第一路由决策具有级联效应。路由错误不只是这个任务做得差而是会触发下游 Agent 的连锁失败。单跳任务中的误路由导致成功率下降 10%在五跳以上的复杂工作流中同等误路由率可能导致整体任务崩溃率超过 40%Zhuge et al., 2024, GPTSwarm。第二评测目标天然多目标。路由系统同时需要优化任务完成质量高、延迟低、Token 消耗低、Agent 负载均衡均匀。这四个目标之间存在明显的取舍关系很难同时做到最优。第三动态分布下的泛化问题。企业环境中的用户意图分布会随业务演进漂移评测集固化于某一时间切面模型在其上的表现不代表线上长期稳定性。评测维度体系比什么、怎么比系统性的路由评测需要在四个维度上同时度量缺一不可。2.1 路由决策质量Routing Decision Quality这是最基础的维度衡量路由器把对的任务送给对的 Agent的准确程度。核心指标Top-1 路由准确率Routing Accuracy1在有标注的合成测试集上路由器将子任务分配给最优 Agent 的比例。这是最直观的决策质量指标类比分类任务中的 Top-1 Accuracy。Top-K 召回率最优 Agent 出现在路由器给出的 Top-K 候选中的比率适用于系统允许多个 Agent 协同兜底的场景衡量路由能力的上界而非单点决策的精度。意图覆盖率Intent Coverage路由器能识别并正确处理的意图类型占总意图空间的比例反映系统对业务场景的覆盖完整性在企业级意图路由系统中尤为关键。拒绝率Abstention Rate当所有 Agent 均不适合处理当前任务时路由器主动拒绝分配的比率在安全敏感场景中用于评估系统识别边界、避免错误兜底的能力。决策一致性Decision Consistency对语义等价但表述不同的输入路由器给出相同路由结果的概率反映系统在用户输入多样化和多轮对话意图延续场景下的稳定性。2.2 系统效率System Efficiency路由的核心价值在于用更低代价换等价结果效率指标量化这一价值主张。没有效率维度路由器的存在意义就无从证明。核心指标Cost Reduction RateCRR成本节省率与全量使用最强模型相比路由方案节省的 Token 费用百分比。RouteLLMOng et al., 2024在 MMLU 上报告其最优路由器在保持 95% GPT-4 质量的前提下实现了约40%50%的调用成本节约。需要警惕一个常见的评测陷阱CRR 必须和任务质量指标联合解读。只报 CRR 而不报质量变化和只报质量而不报成本同样不完整。平均路由延迟Routing Latency路由决策本身的耗时通常要求 P99 延迟远小于任务执行时间。在实际工程中一般的经验阈值是 50msP99否则路由层本身会成为整个系统的延迟瓶颈。轻量级路由器如基于嵌入分类的方案在这个维度上天然占优延迟通常在 10ms 以内基于 LLM 推理的路由器如让一个小模型判断任务类型延迟往往在 100ms 量级在高并发场景下需要额外的缓存和批处理设计。Agent 负载均衡系数Load Balance Score衡量请求在各 Agent 之间是否分配均匀避免出现个别 Agent 过载、其他 Agent 闲置的情况。常用的量化方式是各 Agent 接收请求量的变异系数CV或基尼系数数值越低说明负载越均衡。这个指标在生产环境中的重要性常被低估。一个准确率高但负载严重不均衡的路由器会在高峰期将大量请求压到同一个 Agent导致尾延迟飙升最终用户体验的损失远超路由准确率带来的收益。协调轮次效率比Coordination Efficiency Ratio比值越接近 1.0说明路由越高效越接近理论最优调度。这个指标的难点在于 Oracle 下界的获取——对大多数开放性任务最优通信路径无法提前枚举。目前只在有限的合成数据集如任务结构固定的数学推理、代码生成上有实验数据支撑。2.3 任务完成质量Task Completion Quality路由是手段最终质量是目的。此维度直接评估路由后任务的实际完成情况。核心指标端到端成功率E2E Success Rate在多跳协作任务中整个 Pipeline 最终完成率。这是任务完成质量的基础指标也是当前最主流的代理性路由评测指标。AgentBenchLiu et al., 2023提供了跨 8 类环境OS 操作、数据库查询、知识图谱、网页购物、游戏等的标准化测试框架是当前评测多 Agent 完成能力的主要基准之一。GAIA、HumanEval、MATH、LiveCodeBench 等也被广泛用于多 Agent 路由的任务质量验证。输出质量评分Output Quality Score使用 LLM-as-Judge 或人工打分对路由后的最终输出进行语义质量评估。相比二元的成功/失败判断质量评分能捕捉到完成了但完成得一般与完成得很好之间的差距。在具体实现上GPT-5 或 Claude 4.6 Sonnet 等公认强模型作为评判模型已成为常见选择评分维度通常包括准确性、完整性、相关性、格式规范性等。需要注意的是LLM-as-Judge 本身存在位置偏差position bias和自我偏好self-preference问题建议使用多模型交叉评判并报告一致性指标。任务失败原因归因区分路由错误导致的失败与被路由 Agent 能力不足导致的失败是评测闭环的关键。这也是当前最难解决的工程问题之一。一种可操作的近似方法在失败案例中将同一任务改为路由到最强 AgentOracle 路由若结果转为成功则判定为路由失误若仍然失败则归因为 Agent 能力边界。这种反事实归因需要额外的推理成本但对于识别路由瓶颈具有重要价值。2.4 鲁棒性与泛化性Robustness Generalization一个在测试集上表现优秀的路由器在生产环境中面对真实用户输入的多样性和系统的动态变化时是否仍然可靠这一维度回答的正是这个问题。核心指标OOD 性能Out-of-Distribution Performance在训练分布外的意图或任务类型上路由准确率的衰减幅度。这是泛化能力最直接的量化指标。评测方法将测试集按任务类型分层留出训练集中未见过的任务类别作为 OOD 子集单独报告 OOD 子集上的路由准确率并与 In-Distribution 性能做对比。衰减幅度超过 15% 的路由器在业务快速演进新增意图类型频繁的场景下风险较高。对抗扰动下的稳定性用户输入存在拼写错误typo、语序颠倒、语义歧义、口语化表达时路由决策的一致性。具体评测方式参考对同一批意图样本生成多种扰动变体EDA 数据增强、Back-Translation、人工改写等计算原始输入与扰动输入路由结果的一致率。一致率低于 85% 的路由器在真实用户场景下通常会出现较明显的随机性问题。这个指标对基于精确字符串匹配或规则的路由器尤为关键——此类路由器对输入的微小变化极为敏感而基于语义嵌入的路由器则相对更稳健。冷启动表现新 Agent 加入系统zero-shot 场景时路由器无需重训即可正确引流的能力。这在业务快速扩张、频繁新增专项 Agent 的场景下是刚性需求。评测方式参考在路由器训练完成后向系统引入若干从未见过的 Agent配合其能力描述文档在不重新训练路由器的情况下评测路由器将匹配任务正确分配给新 Agent 的比例。基于 LLM 推理读取 Agent 描述做语义匹配的路由器在冷启动上通常优于纯分类模型代价是延迟和成本更高。分布漂移适应性Distribution Drift Adaptation线上流量的意图分布会随时间演变节假日、产品功能迭代、用户群变化等。路由器在分布发生偏移后性能衰减速率及恢复所需的重训成本是衡量系统长期可维护性的重要指标。目前这一维度缺乏标准化评测方法多数工作仅做离线快照评测无法反映真实在线漂移情况。建议工程团队建立路由决策的线上监控如滑动窗口内的路由分布熵、各 Agent 接收量环比变化作为漂移预警信号。验证过程设计如何构建可信的路由评测评测指标选好了还需要回答一个更实际的问题数据从哪来、指标怎么组合用、结果怎么解读。这三个问题对应评测设计的三个核心环节。3.1 评测数据集构建原则评测集的质量决定了评测结论的可信度上限。一个设计粗糙的评测集即便你的指标体系再完善得出的结论也无法指导实际决策。企业内部构建路由评测集需遵循以下三条原则。原则一分层采样Stratified Sampling按业务意图类型分层抽取样本确保头部高频意图和长尾低频意图都有足够的代表性。建议的样本量下限头部高频意图 ≥ 200 条/类长尾低频意图 ≥ 30 条/类。这背后的逻辑是纯随机采样会导致评测集由高频意图主导长尾意图的路由错误被平均掉而恰恰是长尾意图的路由失误在生产中最难被发现、造成的用户体验损害也最集中。分层采样保证了对长尾场景的评测覆盖是识别系统盲区的基础手段。原则二难度梯度标注对每个样本标注难度等级Easy / Medium / Hard难度判定的参考维度包括意图歧义度单一明确 vs. 多义混淆、跨领域混合度单一领域 vs. 跨多个 Agent 职责边界、所需推理步骤数直接响应 vs. 多跳推理。评测报告必须分难度层次呈现性能数据而不只报总体准确率。一个路由器在 Easy 样本上表现出色、在 Hard 样本上严重退化和另一个路由器在三个难度层次上均匀表现两者的总体准确率可能相同但实际生产价值截然不同。难度分层是识别这种差异的唯一手段。原则三动态更新机制评测集每季度从线上流量中采样新出现的意图模式增量更新。静态评测集的主要风险是与业务真实分布的累积偏差——业务在演进用户行为在变化六个月前构建的评测集很可能已经无法反映当前的路由挑战。一个可操作的工程实现在线上路由层埋点记录低置信度路由决策置信度低于阈值 θ 的样本定期人工复核并标注后补充进评测集。这类路由器自己觉得没把握的样本往往是评测集中最有价值的困难样本来源。3.2 评测指标的组合使用单一指标的路由评测必然产生误导。只看准确率会忽视成本失控只看成本节省会掩盖质量下滑只看平均表现会忽视长尾崩溃。推荐以下四层指标组合主指标 端到端任务成功率E2E Success Rate效率指标Cost Reduction Rate 路由延迟 P99质量下界Output Quality Score ≥ 阈值 τ由业务方确定鲁棒性 OOD 意图路由准确率衰减幅度这四层指标的关系是主指标决定方向效率指标衡量价值质量下界是硬约束鲁棒性决定能否上生产。一个路由方案只有在质量下界约束满足的前提下才值得比较主指标和效率指标只有鲁棒性通过压测才具备上线资格。评测结论的输出形式建议以Pareto 曲线质量-成本替代单点数字。单点数字给决策者的信息是这个方案好不好而 Pareto 曲线给出的是在不同成本预算下可以选择哪些工作点Operating Point后者才是真正可操作的决策依据。一个常见的评测陷阱需要特别说明在同一个测试集上同时做路由器训练和评测会导致严重的数据泄漏——路由器实际上记住了测试集的分布评测数字虚高。正确做法是严格的训练集/验证集/测试集三路划分测试集在整个开发周期内保持封存只在最终对比实验时使用一次。结语在混沌中建立评测秩序多智能体路由评测今天的处境和两年前 RAG 评测的处境高度相似——技术在快速落地但评测体系的成熟度远远落后于工程实践。大量系统带着任务完成率看起来不错就上了生产却对路由层真正消耗了多少成本、在哪些场景下会失效、Agent 缺席时会如何降级一无所知。这篇文章试图回答的核心问题只有一个如何把路由好不好从一个主观判断变成一个可以量化、可以对比、可以用来做决策的工程问题。我们给出的答案可以浓缩为以下几个核心结论结论一任务完成率是必要条件但远远不够。它解决不了归因问题——你永远不知道失败是路由送错了人还是 Agent 本身能力不足。在任务完成率之上至少需要补充成本效率和鲁棒性两个维度才构成一个最低可用的评测体系。结论二Pareto 曲线比单点数字更有决策价值。路由优化的本质是成本-质量权衡单点数字掩盖了这种权衡关系。把不同路由策略画在同一张成本-效果散点图里才能真正回答我多花 20% 的成本能换回多少质量提升这类可操作的问题。结论三评测集的质量是评测结论可信度的上限。分层采样、难度梯度标注、动态更新——这三条原则缺少任何一条评测数字都会失真。尤其是长尾意图的覆盖是企业级路由系统最容易忽视、也最容易在生产中暴雷的盲区。结论四鲁棒性指标决定能否上生产而不只是锦上添花。OOD 性能、对抗扰动稳定性、冷启动表现——这三类指标在研究论文里经常被省略但在真实业务环境里用户输入的多样性、业务意图的持续演变、Agent 的动态增减恰恰是系统面对的常态。一个在干净测试集上表现优秀、但鲁棒性指标从未被测过的路由器等同于一辆只在平整跑道上测试过的汽车。结论五多智能体路由评测的标准化体系目前是研究空白也是工程机会。RouterBench 在单智能体路由层面做到了标准化数据集 统一对比协议 AIQ 指标体系但多智能体版本至今没有对应工作。这意味着现在做这个方向的团队既要自己踩坑摸索也有机会在方法论层面做出真正有价值的贡献。对于当下正在落地多 Agent 系统的工程团队我们的建议很简单先把评测做起来哪怕不完美。从任务完成率 总 token 成本的双维度基线开始画出你的第一张 Pareto 图建立第一个分层评测集。评测体系的价值在于持续迭代等待一个完美的评测框架出现再动手代价是在没有度量的情况下持续优化一个你看不清楚的系统。度量先行优化才有方向。参考文献RouterBenchHu, Y., et al. (2024). RouterBench: A Benchmark for Large Language Model Routers. arXiv:2403.12031.RouteLLMOng, I., et al. (2024). RouteLLM: Learning to Route LLMs with Preference Data. arXiv:2406.18665.MasRouterChen, X., et al. (2024). MasRouter: Learning to Route LLMs for Multi-Agent Systems. arXiv:2412.18510.AgentBenchLiu, X., et al. (2023). AgentBench: Evaluating LLMs as Agents. arXiv:2308.03688. ICLR 2024.GPTSwarmZhuge, M., et al. (2024). GPTSwarm: Language Agents as Optimizable Graphs. arXiv:2402.16823. ICML 2024.G-DesignerZhang, X., et al. (2024). G-Designer: Architecting Multi-agent Communication Topologies via Graph Neural Networks. arXiv:2410.11782.AgentPruneZhang, et al. (2024). Cut the Crap: An Economical Communication Pipeline for LLM-based Multi-Agent Systems. arXiv:2410.02506.LLM-as-JudgeZheng, L., et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023. arXiv:2306.05685.Chatbot ArenaChiang, W.L., et al. (2024). Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference. arXiv:2403.04132. ICML 2024.