欢迎来到我们的 「每周技术加速器」 专栏！

每周五，我们都会围绕一个前沿技术主题，展开一场深度的内部技术分享会。不仅是为了团队内部的碰撞与成长，也希望通过这样的形式，将我们的思考与实践记录、沉淀、分享给更多同行者。

本周，我们探讨的主题是：路由技术。

当智能体系统从单一模型应答，走向包含多种模型、海量工具和复杂知识源的多智能体协作时，一个根本性问题浮出水面：系统接收到一个任务后，究竟该如何“分发”？  

用哪个模型处理？要不要调用工具，用哪个工具？复杂任务如何拆分、按什么顺序执行？这些看似零散的问题，都可以统一归结为路由。

本次分享，我们系统性地拆解了单智能体系统内部的路由机制，从模型路由、工具路由到任务路由，探讨了其技术实现、评测方法与工程演进。以下为本次分享的核心内容整理。

为什么路由技术是智能体的“中枢神经”？

在讨论具体技术之前，我们先明确路由技术的核心价值。它不仅是技术细节，更是智能体系统从“模型能力展示”走向“工程化落地”的关键。

• 从产品角度看：路由技术可以将庞大的产品能力拆解为可组合、可管控的模块，提升系统的稳定性，并通过对资源的精细化调度来控制成本。

• 从客户需求看：它能将复杂、非标的业务需求，拆解成标准化的能力块，通过灵活组合来应对千变万化的场景。

• 从技术研究看：路由是扩展系统决策能力的核心，它决定了如何优化能力调用，以及如何保障系统在复杂链路中的安全与鲁棒性。

简而言之，路由机制决定了智能体系统的成本、效率和可靠性。设计好路由，是构建可落地Agent系统的基础工作，而不是可以后置的优化项。

模型路由：成本与质量的“动态平衡”

模型路由回答的核心问题是：同一个请求，应当调用哪个模型来处理？ 其核心动机是成本与质量的联合最优。

以Claude API为例，旗舰模型与轻量模型的成本差异可达二十余倍。但用户请求的复杂度分布高度不均，将大量简单请求无差别地路由到旗舰模型，会造成巨大的资源浪费。模型路由的价值就在于，在保持整体输出质量的前提下，将请求分配给最恰当的模型。

1. 两种实现范式：离线路由与在线路由

离线路由在请求到达时即做出路由判断。代表性框架如 RouteLLM，它将路由建模为一个二分类问题：用人类偏好数据训练一个路由器，判断当前请求是由强模型还是弱模型处理。RouteLLM实现了三种技术路线的路由器：表示学习（将请求和模型能力映射到共享空间）、判别式分类（用预训练模型提取特征后分类）、生成式评分（用小模型对请求难度打分）。这种离线方式的优势在于延迟极低，适用于实时对话、高并发调用等场景，但前提是请求类型分布相对稳定，路由器能够通过训练获得较高的预判置信度。

在线决策路由则在执行过程中动态判断是否需要“升级”模型。代表性框架如 FrugalGPT，它提出了模型级联的概念：优先让成本最低的模型尝试处理请求，由一个轻量级评分器评估其输出质量；若不达标，再升级到更高能力的模型，依此递推直到质量满足要求或到达级联末端。这种在线路由的核心组件包括评分器（评估当前模型输出是否达标）和生成选择器（决定各模型的调用顺序）。它适用于对延迟不敏感、但质量要求极高的后台批处理任务，尤其当请求难度分布极不均匀时，在线路由能够用实际输出质量来兜底，避免离线预判失误带来的质量损失。

2. 如何评测模型路由？

评测模型路由是一个典型的双目标优化问题——不能只看质量，也不能只看成本。一个将所有请求都路由到最强模型的策略，在质量维度是完美的，但在成本维度毫无意义；反之亦然。

RouterBench 是目前最系统的模型路由评测基准。它做了一项扎实的基础工作：预先收集了11个不同大语言模型在8个主流测试集上的超过40.5万条推理结果，覆盖常识推理、知识问答、数学、代码、多轮对话等任务类型。每条记录不仅标注了模型是否答对，还附上了本次调用的成本。评测一个路由策略时，只需将其套用到这份数据上，就能计算出它在40万条请求上的成本与质量表现。

我们提炼了四个代表性指标，从不同角度评估路由策略：

• AIQ（平均质量提升率）：以“全部走最差模型”为下界、“全部走最强模型”为上界，AIQ衡量路由器填补了这两条线之间差距的比例，数值在0到1之间越高越好。它的关键设计是综合所有预算水平打分，而非只看某个固定预算点。

• NDCH（非递减凸包）：在成本-质量坐标系中划出帕累托最优边界线，落在线上说明策略已达到当前性价比最优，落在线下则意味着存在更划算的替代方案。

• CPT@95%：在允许整体质量降至强模型95%的前提下，路由器实际需要调用强模型的比例。比例越低，说明路由器越能精准区分哪些请求真的需要强模型。

• APGR（平均性能差距恢复率）：在各预算水平下，路由器把“弱模型→强模型”质量差距弥补了多少的均值。数值越高，说明在有限成本下获得的质量收益越大。

CPT与APGR互为补充：前者回答“质量目标固定时，成本能压多低”，后者回答“成本固定时，质量平均能拉多高”。

工具路由：从“感知”到“编排”的全链路拆解

如果模型路由回答的是“找谁来处理”，那么工具路由回答的就是“用什么手段处理，具体怎么处理”。一次完整的工具路由，可以分解为五个连续的阶段：工具感知、检索、选择、参数生成、调用编排。

1. 工具感知：解决“上下文污染”问题

最根本的工程挑战之一是：工具定义本身会消耗大量上下文窗口。一套典型的MCP多服务器配置，仅工具定义部分就可能消耗5.5万tokens，若再加入Jira等工具，总消耗轻松突破10万tokens。这些token的消耗发生在对话开始之前，上下文中还没有写入任何实质性的用户内容。这带来两类问题：其一，上下文窗口空间被大量预占，留给任务推理的有效空间被压缩；其二，推理准确率会随工具数量的增加而下降。

解决这一问题的方法有多种：对工具描述进行压缩裁剪、按类别分组加载、基于检索的静态过滤。这里重点介绍一种由Anthropic提出的动态工具发现机制。其设计思路类似于软件工程中的按需加载：初始化时只加载一个“工具搜索工具”本身（约500 tokens）；其余所有工具标注延迟加载，完全不进入初始上下文；当模型判断需要某类能力时，调用搜索工具返回语义相关的Top-K工具定义（约3000 tokens）；只有被实际调用的工具才最终进入上下文。实测效果显著：token消耗节省85%，模型工具调用的准确率也同步提升。

2. 工具检索：从精确匹配到语义覆盖

工具检索负责从庞大的工具集中召回候选工具。目前常见的方案分为三类：

• 关键字与BM25检索：最轻量的方案，维护工具名称和功能描述的倒排索引，用正则或BM25进行关键词匹配。优势是无需额外向量化计算，检索延迟极低；缺点是语义覆盖能力弱——用户说“帮我查天气”，未必能匹配到工具名为weather_fetch的函数。

• 语义向量检索：将每个工具的完整描述编码为语义向量存入向量数据库，用户请求同样编码为向量后计算相似度。这是当前工程实践中最主流的方案。

• 混合检索：将BM25和语义向量检索的结果合并，通过RRF（倒数排名融合）等算法重新排序，取综合得分最高的Top-K工具。这种方案兼顾了关键词检索的精确性和向量检索的语义覆盖能力，是生产级方案的首选。

3. 工具选择与参数生成：超越Schema的战场

工具选择不仅考验模型选对工具的能力，更考验其感知能力——即判断“何时不应当调用工具”。大量评测数据显示，顶级大模型在工具选择精度上表现尚可，但在感知层面仍存在明显不足。针对这一点，BFCL评测基准专门引入了 Irrelevance Detection 类别，测试当系统提供的工具集与用户请求完全不匹配时，模型应当拒绝输出任何工具调用，而不是强行选择一个“语义最接近”的工具。这与真实工业场景高度吻合：在配备了有限工具集的Agent系统中，错误调用一个不相关工具所产生的负面后果，通常远大于直接拒绝并说明无法处理。

参数生成面临的问题是：JSON Schema定义了参数的数据类型和必填字段约束，但无法表达调用惯例层面的要求。以一个工单系统的create_ticket工具为例，Schema规定due_date字段是字符串类型，但开发者需要知道的是：这个字符串的具体格式应当是“2024-11-06”还是“Nov 6, 2024”？这些问题Schema无法回答。

Anthropic提出的 Tool Use Examples 机制允许开发者在工具定义中直接嵌入示范性的调用样例。内部测试数据显示，引入使用示例后，复杂参数处理场景的调用准确率从72%提升至90%。示例设计需遵循几条原则：覆盖三种典型模式（最小化调用、部分填写、完整参数调用）；使用真实数据而非抽象占位符；每个工具保持1到5个示例，聚焦在Schema表达不清晰的歧义点。

4. 调用编排与Agent Skills：范式的演进

真实任务往往需要多个工具按照特定顺序和结构协同调用。调用编排方式可分为两类：

• 贪心编排（如ReAct框架）：每一步都选择当前状态下最优的工具，逐步推进。优点是实现简洁、推理延迟低；缺点是早期错误会沿调用链传播，且无回溯机制。

• 搜索编排（如蒙特卡洛树搜索）：在执行前展开多条候选调用路径，综合先验评分和执行反馈择优选择。

在中间结果处理方面，Anthropic的**程序化工具调用（PTC）**提供了一种新思路：让模型直接生成一段Python编排代码，在沙盒执行环境中并行调用多个工具，最终只将汇总后的结果返回给模型上下文，中间的所有原始数据均不进入上下文。实测数据表明，PTC在复杂研究类任务中将平均token消耗从43,588降至27,297，减少约37%，同时消除了19次以上的冗余推理pass。

近期，工具路由领域出现了一个重要的范式演进：从单一函数工具向可组合的技能包（Agent Skills）过渡。Skill本质上是一个文件夹，包含SKILL.md指令文件以及可选的脚本和资源文件。其核心创新在于三级渐进式加载机制：启动时仅加载每个Skill的元数据（名称和描述摘要）；当某个Skill被判定为相关时，再加载其完整的SKILL.md指令；仅在Skill实际执行时，才加载其绑定的脚本或资源文件。这意味着即便系统配备了超过100个Skill，初始上下文中来自Skills系统的信息总量仍然可控。

有了Skills之后，路由问题在层级上得到扩展：先由元数据匹配决定激活哪个Skill，再由Skill内部的逻辑决定调用哪些工具。在这个两级路由中，Skill的description字段是路由决策的唯一依据，因此描述的写法至关重要。一个好的Skill描述应包含三个要素：触发条件（什么情况下应该用）、核心能力（能做什么）、排除条件（什么情况下不应该用）。排除条件往往是最容易被忽略却最重要的部分——它直接决定了路由器在相似Skill之间能否做出正确区分。

5. 工具路由如何评测？

BFCL是目前最权威、最全面的工具测评体系，已演进至V4版本。其核心评测类别涵盖Simple（单工具调用）、Multiple（多选一）、Parallel（并行调用）、Parallel Multiple（并行与多选一复合）、Irrelevance Detection（无关检测）、Multi-Turn（多轮对话）以及V4新增的Agentic（多跳推理、记忆管理、错误恢复）。

BFCL的主要评测方法是抽象语法树（AST）匹配：不依赖字符串的精确匹配，而是比对函数调用的语法结构——函数名、参数名、参数类型和参数值——能够容忍语义等价的不同表达形式，评测结果更接近真实调用的正确性判断。其优势在于评测粒度非常细致：不仅能识别参数值错误，连语法层面的问题（如括号缺失、非法字符、小数格式不合规等）都能精准定位并给出具体提示。从BFCL Leaderboard的数据中可以观察到，不同模型在Simple类别上差距很小，而在Parallel Multiple和Multi-Turn类别上差距非常显著。这意味着，如果工具路由场景涉及并行调用或多轮交互，基于通用benchmark的模型选型结论可能并不适用，应当优先参考BFCL的分类结果。

除BFCL外，ToolBench/ToolLLM（覆盖16,464条真实RESTful API，分三个难度层级）和MetaTool（专注于工具感知能力评测）也是重要的补充性评测资源。

任务路由：复杂任务的“导航图”

当任务需要多步执行时，任务路由面临三个核心挑战：分解粒度控制（划分过细会增加开销，划分过粗会提高失败率）、依赖关系建模（识别先后顺序，减少串行等待）、失败恢复路由（决策重试、回溯修正或寻找替代路径）。

三个代表性框架的演进路径

ReAct是任务路由的基础范式，确立了“思考→行动→观察”的循环结构。其中“行动”的本质就是一次路由决策——模型根据当前推理状态决定下一步流向哪里。ReAct的核心洞察是：纯粹的思维链推理没有外部交互，路由决策缺乏真实反馈；而纯粹的行动序列没有推理支撑，路由容易失去方向。两者结合，让每一次路由决策都能基于上一步的真实观察结果。但ReAct的路由方式是贪心的，每一步都需要完整的LLM推理，执行延迟随调用次数线性增长，且无回溯机制。

Plan-and-Execute的思路是：在任何一个工具被调用之前，先把整条路由路径确定下来。它分为三个阶段：Planner负责生成完整的路由地图（将用户目标分解为有序的子任务列表）；Executor按路由地图逐步执行；Re-planner负责在执行过程中动态修订路径——若某个子任务的实际结果与预期不符，会调整后续方向。与ReAct的本质区别是：路由决策的时机从“每步执行后”提前到了“执行开始前”，整条路由路径在启动时就是可见的、可检查的，这使得复杂多步任务的路由过程更可控，出错时也更容易定位问题。

LangGraph将任务路由显式建模为图结构。它的路由逻辑由三个要素驱动：节点是执行单元（工具调用、LLM推理、代码执行或人工确认节点），每个节点完成后都会触发一次路由决策；边就是路由规则本身，固定边代表无条件流转，条件边读取当前状态动态决定下一步流向；状态是贯穿全图的共享上下文，每个节点执行后都会更新状态，驱动后续条件边做出不同的路由判断。LangGraph将路由逻辑从模型推理中剥离出来，写成明确的条件判断，带来两个工程优势：每一次路由决策的输入输出都可追踪，可观测性大幅提升；同时可以在任意节点暂停，插入人工审核后再继续流转。

任务路由如何评测？

任务路由评测的核心关注点是端到端的任务完成率，而非中间步骤的准确性。

GAIA是复合任务端到端评测的代表性基准，将任务分为三个难度层级：L1（1-2步）、L2（2-5步工具调用）、L3（5步以上跨工具长时域推理）。其重要设计特点是问题的标准答案通常是简短且客观的（如一个数值、一个人名或一个日期），从而规避了开放式生成任务中主观性评测带来的噪声，使评测结果更具可比性。

SWE-bench是目前任务路由能力评测中难度最高、最接近工程实际的基准。它以真实GitHub代码仓库中的issue修复任务作为评测对象，覆盖问题理解、代码定位、方案制定、patch生成、回归验证全链路。这一评测任务对模型路由、工具路由、任务路由三个层次的能力进行了全链路综合考验。

展望：多智能体路由

当系统中存在多个Agent时，路由问题的复杂度上升了一个层级。决策对象不再是“调哪个模型”或“用哪个工具”，而是“如何在多个Agent之间分配任务、协调执行、传递中间结果”。

多智能体路由目前可以归纳为四类主要架构模式：

• 层级路由：一个主控Agent接收总任务，将子任务分发给多个专业执行Agent。代表性框架包括AutoGen Swarm和MetaGPT。

• 流水线路由：任务按预定义的顺序在Agent之间依次流转，每个Agent处理特定阶段的子任务。代表性框架是CrewAI的Sequential Process。

• 竞争路由：将同一任务并行分发给多个Agent，汇总各方输出后综合决策，以提高结果质量。代表性工作是Together AI的Mixture of Agents。

• 动态图路由：任务在Agent之间的流转路径在运行时根据当前状态动态决定，支持分支、循环和条件跳转。代表性框架是LangGraph的多Agent模式，以及OpenAI Agents SDK的Handoff机制。

多智能体路由对应的评测体系，包括清华大学的AgentBench（覆盖多领域任务的端到端完成率评测），以及MasRouter在ACL 2025中提出的多智能体系统路由形式化评测框架。

多智能体路由是当前学术界和工业界最活跃的研究与工程方向之一。OpenAI、Anthropic、Google、微软均在近期密集发布了相关的基础设施和框架更新，方向已经非常清晰，但如何让动态路由在生产环境中做到可靠、可观测、可调试，仍然是工程实践中高度开放的问题。

结语

从单体模型到复杂智能体系统，路由机制已从“可选项”变为“必选项”。它不仅关乎成本与效率，更决定了系统能否在复杂、真实的业务环境中稳定运行。

我们今天的分享，将单智能体系统的路由拆解为模型、工具、任务三个层次，并分别探讨了其实现范式与评测方法。我们相信，对路由技术的深入理解与工程化实践，是构建下一代可靠、可控、可扩展的AI系统的基础。

本期分享到此结束，欢迎留言交流与探讨！