路由模式（Routing）

相比提示链模式的固定线性流程，路由模式能根据输入动态选择不同的处理路径。它通过一个路由器对输入进行分类或评估，然后将其导向最合适的专用处理器，使系统从固定执行路径转变为动态决策系统。

这种动态决策能力——即根据特定条件将控制流导向不同的专用函数、工具或子流程——就是通过"路由"机制实现的。路由为智能体的操作框架引入了条件逻辑，使其从固定执行路径转变为动态决策系统。这种机制使智能体能够根据输入数据的特征、上下文信息或外部环境的变化，选择最合适的工具或子流程来处理任务。

核心思想：条件分发 —— 先判断"这是什么类型的请求"，再决定"交给谁处理"。

例如，一个用于客户咨询的智能体，在具备路由功能后，可以对用户查询进行分类以判断意图。根据分类结果，查询可以被导向专门的问答智能体、用于账户信息检索的数据库工具，或者用于复杂问题升级的流程。

与提示链的关系

路由模式的核心组件

路由模式的核心组件是执行评估并引导流程的机制，其实现方式包括以下五种：

1. 基于 LLM 的路由

通过提示语言模型分析输入，并输出指示下一步或目标标识符或指令。

示例 Prompt："分析用户查询，仅输出类别：'订单状态'、'产品信息'、'技术支持'或'其他'。"

智能体系统读取输出并据此引导工作流。

优点：灵活，能处理复杂和新颖的输入 缺点：有延迟和成本，结果可能不稳定

2. 基于嵌入的路由

利用嵌入向量（RAG）来表示输入数据，并通过计算与不同工具或子流程的嵌入向量之间的相似度来决定路由。例如，智能体可以将用户查询转换为嵌入向量，并计算与预定义工具或子流程的嵌入向量之间的相似度，以确定最相关的工具或子流程来处理查询。

优点：语义理解能力强，适合模糊匹配 缺点：需要预先计算各路径的嵌入表示

3. 基于规则的路由

通过预定义的规则或条件（如 if-else、switch-case）来指导路由决策，根据关键词或者结构化数据进行路由。

优点：比 LLM 路由更快、更确定，无 LLM 调用成本 缺点：处理复杂或新颖输入的灵活性较低

4. 基于机器学习模型的路由

采用如分类器等判别模型，在小规模标注数据集上专门训练以实现路由任务。与嵌入方法类似，但其特点是监督微调过程，路由逻辑编码在模型权重中。与 LLM 路由不同，决策组件是一个独立的判别模型，而非提示引导的语言模型输出。LLM 可用于生成合成训练数据，但不参与实时路由决策。

优点：快速且准确，适合高频场景 缺点：需要标注数据和训练过程

5. 混合路由

结合上述多种方法以实现更鲁棒的路由机制。例如，系统可以首先使用基于规则的路由进行快速分类，如果输入不符合任何规则，则退回到基于 LLM 的路由进行更深入的分析。

流程示意

                    ┌→ [处理器 A] → 结果 A
输入 → [路由器] ──→├→ [处理器 B] → 结果 B
                    └→ [处理器 C] → 结果 C

路由机制可以在智能体操作周期的多个阶段实现：既可用于分配初始任务分类，也可在处理链中间决定后续动作，或在子流程中选择最合适的工具。

适用场景

路由模式是设计自适应智能体系统的关键控制机制，使其能够根据输入和内部状态动态调整执行路径，广泛应用于多个领域：

人机交互场景

在虚拟助手、AI 教师等场景中，路由用于解析用户意图。系统对自然语言查询进行初步分析，决定后续动作，如调用信息检索工具、升级到人工、或根据用户表现选择下一个课程模块，从而实现超越线性对话流的上下文响应。

自动化数据与文档处理

路由承担分类与分发功能。系统根据内容、元数据或格式分析（如邮件、工单、API 数据），并将其导向相应工作流，如销售线索导入、针对 JSON/CSV 的数据转换、或紧急问题升级。

多工具/多智能体协作系统

路由充当高级调度器。例如，研究系统由检索、摘要、分析等智能体组成，路由器根据当前目标分配任务。同样，AI 编程助手会先识别编程语言和用户意图（调试、解释、翻译），再将代码片段交给对应工具处理。

总之，路由为系统提供了逻辑仲裁能力，是构建功能多样、具备上下文感知系统的基础。它将智能体从静态执行者转变为能根据变化条件做出决策的动态系统。

代码示例

示例 1：LangChain 实现（2.1路由示例_LangChain.py）

使用 LangChain + OpenAI GPT 构建路由系统：

• 协调者（coordinator）：通过 LLM 将请求分类为 booker/info/unclear
• 子处理器：三个模拟函数分别处理预订、信息查询、不明确请求
• 路由机制：RunnableBranch 根据分类结果将请求委托给对应处理器

用户请求 → [LLM 分类] → booker / info / unclear → [对应处理器] → 结果

代码利用 LangChain 和 GPT 构建了一个简单智能体系统。定义了 booking_handler、info_handler、unclear_handler 三个模拟子智能体处理器，分别处理不同类型请求。核心组件 coordinator_router_chain 通过 ChatPromptTemplate 指示语言模型将用户请求分类为 booker、info 或 unclear。RunnableBranch 根据分类结果将原始请求委托给对应处理函数。coordinator_agent 组合上述组件，先路由请求，再交由选定处理器，最终输出处理结果。

示例 2：Google ADK 实现（2.2路由示例_GoogleADK.py）

Agent Development Kit（ADK）是用于工程化智能体系统的框架，提供结构化环境定义智能体能力与行为。与显式计算图架构不同，ADK 路由通常通过定义一组代表智能体功能的"工具"实现。用户查询由底层模型匹配到合适工具，框架内部自动完成路由。

使用 Google ADK 构建多智能体路由系统：

• 协调者智能体（Coordinator）：分析请求并自动委托
• 子智能体：Booker（预订）和 Info（信息），各自配备 FunctionTool
• 路由机制：ADK 的 Auto-Flow 根据 sub_agents 的描述自动完成委托，无需显式编写分支逻辑

脚本包含一个主协调者智能体和两个专用子智能体。每个子智能体配备 FunctionTool，分别模拟预订和信息检索。协调者智能体的主要职责是分析用户消息并自动委托给 Booker 或 Info，ADK 的 Auto-Flow 机制会根据 sub_agents 自动完成委托。run_coordinator 函数设置 InMemoryRunner，创建用户和会话 ID，通过 runner 处理请求并提取最终响应文本。

两种实现的核心区别

LangChain 需要显式编写路由分支逻辑（RunnableBranch），而 ADK 通过智能体描述 + Auto-Flow 自动路由。

局限性

• 分类错误：路由器判断失误会导致请求进入错误的处理路径
• 维护成本：路径增多时，路由规则和处理器的维护复杂度上升
• 单层限制：简单路由只做一次分发，复杂场景可能需要多层路由或与其他模式结合

相关笔记

• 上一章：提示链模式
• 下一章：并行化模式
• AI MOC