【第四部分：Agentic 智能体设计模式】17. Agent 路由模式详解：从意图识别到动态模型选择

上一篇介绍了 Prompt Chaining（提示链模式），通过将复杂任务拆分为多个职责明确的步骤，配合结构化输出、中间结果校验和局部重试，提高多阶段模型调用的可靠性。

但在实际 Agent 应用中，并不是所有请求都适合采用相同的处理流程。例如，一个企业知识助手可能同时接收制度查询、项目数据分析、文档处理和审批操作等任务。这些请求使用的数据来源不同，对模型能力、工具权限、响应速度和执行流程的要求也存在明显差异。

如果全部交给一个通用 Agent，让模型从大量 Tool 中自行选择，虽然开发初期比较方便，但随着业务能力增加，很容易出现工具选择错误、上下文冗余、简单任务成本过高以及高风险操作控制不足等问题。

Routing（路由模式）就是针对这类场景，将任务识别与具体执行过程分离：首先判断请求属于哪种类型，再根据预先定义的策略选择合适的 Workflow、Tool、模型或专业 Agent。

本篇重点介绍 Routing 的分类、实现方式、异常处理和评估方法，并结合 BaseMetas EKA 企业知识助手说明其在实际业务中的应用。

一、Routing 模式的基本原理

Routing 可以理解为 Agent 应用中的任务分发机制。它根据当前请求及相关业务上下文，选择后续执行路径，而不是让所有请求进入同一条处理链路。例如，企业知识助手接收到以下请求：

这些任务虽然都可以通过自然语言提出，但实际处理方式完全不同。因此，Routing 要解决的问题是：在执行任务之前，先选择适合当前请求的处理策略。

与上一篇的 Prompt Chaining 相比，二者的职责有所不同。

Routing 并不替代后续的执行模式。一个请求经过路由以后，仍然可以进入 Prompt Chaining、Agent Loop、状态机或其他工作流。这里还需要明确一点：Routing 不一定需要大模型。如果请求中已经包含可靠的业务标识，直接通过程序规则分发通常更加简单、准确。

二、Routing 的四个主要层次

在现代 Agent 系统中，Routing 已经不再局限于简单的意图分类。根据路由目标不同，可以分为以下四种类型。

Task Routing主要解决业务流程选择。例如，制度查询直接进入 RAG，而合同风险分析进入多阶段文档处理工作流。

Model Routing主要解决不同任务对模型能力和成本的要求。简单分类可以使用轻量模型，复杂推理则可能需要更强模型，但具体选择应该以实际评估为依据。

Tool Routing主要解决工具数量增加以后，怎样让模型只接触当前任务需要的工具，而不是每次都加载所有 Tool Schema。

Agent Routing则适用于需要将任务交给不同专业 Agent 的情况，例如客服系统根据请求类型将任务交给订单、售后或技术支持 Agent。

这四种路由并不是彼此替代的关系。一个完整的 Agent 应用可以先通过 Task Routing 选择业务流程，再在具体流程内部执行 Model Routing 或 Tool Routing。但在实际开发中，通常应该先建立稳定的业务任务路由，再根据需要增加其他层次，避免一开始就引入过多动态决策。

三、规则路由、模型路由与混合路由

Routing 最常见的实现方式包括规则路由、模型路由和混合路由。

规则路由

规则路由根据明确的业务条件进行判断，例如 API 的operation、文件类型、前端选择的操作类别、用户角色或业务状态。假设业务请求已经明确指定：

{ "operation": "travel.submit", "projectId": "P-1001" }

程序可以直接识别为出差申请提交任务，不需要额外调用大模型进行意图判断。这种方式具有确定性强、执行延迟低和容易测试等优势，但对于自由自然语言请求，往往难以覆盖复杂语义。

模型路由

对于自然语言请求，可以利用模型的语义理解能力进行分类。例如：

帮我检查这几份采购合同中有没有不合理的付款和违约条款。

模型可以将其分类为：

{ "route": "DOCUMENT_ANALYSIS", "reason": "需要进行多文档合同风险分析" }

这里建议使用 Structured Output，将路由结果限制在预定义枚举范围内，而不是让模型自由生成处理路径名称。模型只负责输出分类结果，真正执行哪一个 Handler 仍然由程序决定。

混合路由

对于企业应用，更推荐使用混合方式：明确的业务字段优先走规则，无法确定的自然语言请求再进行模型判断。例如：

这种方式能够减少不必要的模型调用，同时避免把所有路由决策都交给概率性模型。特别需要强调：路由分类与业务授权是两个不同的环节。即使模型正确识别出“删除文件”或“提交审批”，也不能据此认定当前用户拥有对应的执行权限。

四、Java 中实现一个简单的 Router

这一篇不展开完整的模型 SDK 或 Agent Framework，而是使用 Java 展示 Routing 最核心的工程逻辑。首先定义允许的任务类型：

enum Route { KNOWLEDGE, BUSINESS_DATA, DOCUMENT_ANALYSIS, BUSINESS_ACTION, MULTI_STEP, CLARIFY }

这里分别表示知识查询、业务数据查询、文档分析、业务操作、复合任务和需要补充信息的请求。再定义简单的数据结构和接口：

record RouteDecision( Route route, String reason ) {} record UserRequest( String userId, String text, String operation ) {} interface IntentClassifier { RouteDecision classify(String text); } interface TaskHandler { String handle(UserRequest request); }

其中：

• IntentClassifier负责模型意图分类；

• TaskHandler由具体业务处理器实现；

• RouteDecision保存分类结果；

• UserRequest保存当前请求信息。

最小路由逻辑如下：

String dispatch( UserRequest request, IntentClassifier classifier, Map<Route, TaskHandler> handlers) { Route route; // 1. 明确业务操作优先使用规则 if ("travel.submit".equals(request.operation())) { route = Route.BUSINESS_ACTION; } else if (request.operation() != null) { route = Route.CLARIFY; } else { // 2. 自然语言请求交给模型分类 RouteDecision decision = classifier.classify(request.text()); route = decision == null ? Route.CLARIFY : decision.route(); } // 3. 无法确定任务类型 if (route == null || route == Route.CLARIFY) { return "请补充具体的业务目标或操作内容"; } // 4. 根据分类结果找到业务处理器 TaskHandler handler = handlers.get(route); if (handler == null) { return "当前不支持该类型的任务"; } // 5. 交给对应处理流程 return handler.handle(request); }

这段代码中，handlers是程序提前注册的业务处理器集合，各 Handler 负责进一步验证当前用户的权限和具体业务参数。代码表达的核心是：规则或模型产生路由决策，Router 选择业务处理器，Handler 负责执行具体任务。实际生产环境还应增加分类结果 Schema 校验、超时控制、Trace 及统一异常处理，但这些不改变 Routing 的基本结构。

五、复合任务与不确定分类的处理

实际业务请求不一定只包含一种意图。例如：

按照公司差旅制度，查询 Project-A 的剩余预算，如果满足要求，就帮我生成并提交出差申请。

这个请求同时包含制度查询、业务数据查询、条件判断和业务写入。如果简单路由到KNOWLEDGE，系统可能只返回制度内容；如果直接路由到BUSINESS_ACTION，则可能跳过预算检查。

因此，遇到复合任务时，更合理的做法是路由到MULTI_STEP，再由 Workflow 或 Planning 负责拆解任务、处理执行依赖。Router 负责识别任务性质，不应该在入口处承担所有任务规划工作。另一个常见问题是分类不确定。例如用户只说：

帮我处理一下这个文件。

系统无法判断用户是希望生成摘要、转换格式、提取数据还是进行风险分析。此时不应该强制猜测某一种处理路径，而应要求用户补充任务目标。对于模型分类结果，开发者也可以设置不同等级的处理策略：

如果采用模型返回的confidence进行路由控制，需要注意它不一定等于真实的分类正确概率。阈值应结合业务数据和模型表现进行验证，不能直接认为某个固定数值以上就一定安全。

六、BaseMetas EKA 中的任务路由设计

以 BaseMetas EKA 企业知识助手为例，可以将统一用户入口与具体执行能力分离。用户通过 Web、企业门户或其他业务入口提交请求，由 Router 根据任务类型选择后续处理路径。

这些路径不需要统一经过一个通用 Agent Loop。普通知识问题可以直接检索并返回；文档分析可以通过确定性的多阶段流程执行；需要动态规划的复杂任务再引入 Agent；涉及业务写入时，则必须增加权限校验和审批控制。同时，Permission、Trace 和 Evaluation 应作为公共能力，贯穿不同的执行路径，而不是由各业务 Agent 自行决定是否启用。在此基础上，可以继续将模型选择和工具选择纳入统一的路由体系，但要避免将它们直接与 Task Routing 混为一谈。

七、2026 年 Routing 技术的几个新变化

最近一段时间，Routing 技术的发展已经从传统的意图分类，逐渐扩展到专用决策模型、动态模型选择和工具按需发现等方向。

1. 专用决策模型：以 Jev 为例

2026 年 9 月发布的 Jev 是 TypeSafe AI 推出的 System One 决策模型。它与传统生成式大模型有所不同，主要面向范围明确的结构化判断，而不是生成长文本。

Jev 通过输入当前 State 和预定义问题，返回程序可以直接处理的决策结果，主要包括：

例如，在企业知识助手中，可以让 Jev 从KNOWLEDGE、BUSINESS_DATA、DOCUMENT_ANALYSIS、BUSINESS_ACTION等预定义类型中选择最匹配的路径。这种方式与使用通用 LLM 进行分类并不冲突。两者解决的都是结构化判断问题，只是模型设计和输出机制不同。

2026 年 9 月 28 日，1Panel AI 网关 v1.3 已经引入 Jev 智能路由模式，由管理员定义业务目标，Jev 负责目标选择，网关负责对应模型组调度、权限控制和失败兜底。这一案例说明，Routing 中的简单分类和评分任务，正在出现专门优化的模型实现方式。但 Jev 并不是 Routing 的代名词，也不能替代复杂任务规划、内容生成和真实业务执行。即使其返回的是符合类型约束的结果，也仍然需要处理分类错误、信息不足和权限控制问题。

2. 动态模型路由：结合任务复杂度选择模型

传统系统往往对全部请求使用同一个模型，但实际任务对模型能力的要求存在明显差异。例如，简单意图分类和普通字段提取可能不需要最强的推理模型，而复杂代码分析、多文档推理等任务可能更加依赖高能力模型。

2026 年 10 月 1 日，LangChain 发布了 Open SWE 编码 Agent 的模型路由实践，通过任务类型、执行轨迹和模型能力评估选择不同模型层级。在其实验中，相比固定使用高能力模型的方案，任务中位成本下降约 64%，同时未观察到明显的质量变化。这个结果来自特定 Coding Agent 和任务分布，不能直接推广到其他业务，但说明模型路由已经开始从简单的价格分流，发展为结合任务特征、模型表现和运行成本进行动态选择。

值得注意的是，模型路由未必只能部署在统一 AI Gateway 中。部分判断依赖任务状态、代码上下文和历史执行轨迹，因此也可以位于 Agent Runtime 或 Harness 层。

3. Tool Search：工具按需发现

随着 MCP 和企业业务系统接入能力增加，一个 Agent 可能拥有几十甚至上百个 Tool。如果每次请求都把全部 Tool Schema 加入模型上下文，不仅增加 Token 成本，还可能影响工具选择准确率。因此，近年的 Tool Routing 开始向Tool Search / Progressive Tool Disclosure演进：根据当前任务检索工具目录，按需加载相关工具定义，而不是一次性暴露全部工具。

OpenAI 已提供 Tool Search 能力；Spring AI 2.0 也提供ToolSearchToolCallingAdvisor，支持工具索引和渐进式工具发现。这里需要区分两个概念：

Tool Search负责找到当前任务可能需要的工具。

Tool Calling负责模型如何生成并执行具体的工具调用。

在企业应用中，还需要确保工具发现只在当前用户有权访问的工具范围内进行。工具能够被发现，不代表当前用户一定拥有执行权限。

4. 专业 Agent 路由：从分类走向任务委派

OpenAI Agents SDK 提供 Handoff 和 Agents as Tools 两种专业 Agent 编排方式。Handoff 适用于将后续执行控制权交给某个专业 Agent；Agents as Tools 则由主 Agent 保持整体控制权，将部分任务交给专业 Agent 完成。

因此，Agent Routing 除了决定由谁处理任务，还需要明确最终结果由谁负责、执行权限如何传递以及上下文如何隔离。但这并不意味着企业知识助手必须拆分出多个 Agent。对于职责简单的任务，直接调用普通 Handler 或 Tool 往往更容易维护。

八、误路由处理与效果评估

Routing 的工程风险不只是模型分类错误，更重要的是错误分类可能导致后续流程使用了错误的数据来源或操作方式。例如，将实时预算查询路由到知识库，可能得到过期结果；将合同分析路由到普通问答，可能遗漏风险检查；把查询请求错误识别为业务写入，则可能触发不必要的操作流程。因此，Router 应该拥有独立的评估体系。

例如，可以准备一批真实业务请求，人工标注正确 Route，分别测试规则路由、通用 LLM 分类和专用决策模型，再比较准确率、响应时间与整体成本。对于 Jev 这类提供概率分布的模型，还可以分析分类不确定性与实际错误率之间的关系，确定需要人工确认或进一步分类的条件。

这里尤其要注意，“查询报销申请状态”和“提交报销申请”虽然包含相似词汇，但一个属于只读查询，另一个属于业务写入，错误路由可能造成完全不同的后果。因此，在生产环境中，除了分类准确率，还应该重点关注错误路由的业务代价和安全风险。同时记录 Router 输入、分类结果、所选 Handler、最终执行结果及失败原因，才能根据真实任务数据持续优化路由策略。

九、Routing 的适用范围与设计原则

Routing 并不是所有 Agent 应用都需要的独立组件。如果系统只有一个固定的知识查询流程，直接执行 RAG 通常更加简单。只有当应用存在明显不同的任务类型，并且这些任务在数据来源、模型、工具、成本或权限方面存在差异时，Routing 才能体现明显价值。

实际开发时，可以遵循以下原则：

首先，优先使用确定性规则。对于已经明确的业务操作，不要再调用模型重新猜测意图。

其次，将分类与执行分开。Router 只负责选择合法处理路径，具体业务能力由 Handler、Workflow 或 Agent 实现。

再次，允许不确定结果。对于语义不明确、复合任务或模型判断不稳定的请求，应该支持澄清、降级或受控路由，而不是强制分类。

最后，以实际任务效果评估路由策略。不同模型和技术方案的价值，应通过准确率、成本、延迟和任务完成率验证，而不是仅根据模型宣传指标选择。

还需要避免职责重叠：Routing 负责选择路径，Planning 负责任务拆解，Tool Calling 负责具体工具执行，State Machine 负责状态和流程控制。它们可以组合，但不应该让多个组件重复作出相互冲突的决策。

十、本篇小结

Routing 模式通过规则或模型判断请求类型，为不同任务选择合适的执行路径，是复杂 Agent 应用中常见的任务编排方式。

它与上一期 Prompt Chaining 的区别在于：Prompt Chaining 主要解决任务如何分步执行，Routing 则负责决定请求应该进入哪个处理流程。在工程实现中，需要重点考虑规则与模型结合、结构化分类结果、复合任务、异常兜底、权限控制与路由评估。

最近的技术发展也说明，Routing 正在从简单的意图分类逐渐扩展为多层决策体系：专用决策模型可以承担简单分类和评分任务，模型路由可以根据任务复杂度动态选择模型，Tool Search 可以减少大规模工具集合带来的上下文开销，而 Agent Routing 则支持更加专业化的任务分派。但无论采用传统规则、通用 LLM，还是 Jev 这样的专用决策模型，核心原则都没有改变：

路由器负责选择处理路径，业务程序负责验证和执行；模型提供判断能力，但不能替代确定性的业务边界。

对于企业应用，合理的做法仍然是从简单规则开始，随着业务复杂度增加，再逐步加入模型分类、动态模型选择和工具按需发现，而不是一开始就构建复杂的多层 Agent 路由体系。

上一篇回顾：

【第四部分：Agentic 智能体设计模式】16. 一个 Prompt 搞不定复杂任务？试试 Prompt Chaining-CSDN博客

下一篇：并行化模式——多个独立任务的并发执行与结果汇总。

Routing 解决了请求进入哪条执行路径的问题，而 Parallelization 将进一步讨论多个独立任务如何并发执行，以及并发控制、部分失败、结果合并和执行成本之间的关系。