路由模式（Routing）
路由让智能体从「预定义序列的静态执行器」进化为「能在变化条件下选择最优行动的动态系统」。
🎯 什么是路由？
路由（Routing）是智能体系统中的关键控制机制，它为系统引入了条件分支能力，让智能体能够根据实际情况动态选择最优的处理路径。
从提示链到路由的进化
| 模式 | 执行方式 | 比喻 |
|---|---|---|
| 提示链 | 线性顺序，固定路径 | 流水线 |
| 路由 | 条件分支，动态选择 | 交通枢纽/调度中心 |
提示链适合确定性任务，但现实场景中，智能体需要根据环境状态、用户输入或上一步的执行结果，从多个可选方案中选择合适的行动路径。
核心流程
┌─────────────┐
│ 用户输入 │
└──────┬──────┘
│
▼
┌─────────────┐
│ 分析 & 分类 │ ← 路由器（Router）
└──────┬──────┘
│
┌──────┴──────┬──────────┬──────────┐
▼ ▼ ▼ ▼
路径A 路径B 路径C 路径D
(订单查询) (产品咨询) (技术支持) (追问澄清)🔧 四种路由实现方式
1. 基于大语言模型的路由（LLM-based Routing）
通过提示词引导LLM分析输入并输出分类结果：
系统提示：
"分析以下用户查询，仅输出类别：订单状态、产品信息、技术支持、其他"
用户查询：我的快递到哪了？
LLM输出：订单状态| 优点 | 缺点 |
|---|---|
| 理解能力强，处理复杂表述 | 速度较慢 |
| 开箱即用，无需训练 | 成本较高 |
| 能处理新颖输入 | 有时会出错 |
2. 向量路由（Embedding-based Routing）
将输入转换为向量，与预设的「路由向量」比较相似度：
| 路由 | 代表性语句 |
|---|---|
| 订单查询 | "查订单状态"、"快递到哪了" |
| 退款处理 | "我要退款"、"订单取消" |
精妙之处：「帮我退款」和「订单有问题想取消」措辞不同，但向量距离相近，都会被路由到退款处理。
| 优点 | 缺点 |
|---|---|
| 基于语义，更智能 | 需要预先准备代表性语句 |
| 速度快，成本低 | 边缘情况处理有限 |
3. 规则路由（Rule-based Routing）
使用预定义的关键词、模式或逻辑规则：
如果 输入包含 ["订单", "快递"] → 订单模块
如果 输入包含 ["退款", "退货"] → 退款模块
如果 输入包含 ["故障", "坏了"] → 技术支持
否则 → 通用问答| 优点 | 缺点 |
|---|---|
| 速度最快，成本最低 | 不灵活 |
| 完全可控，易调试 | 需要人工维护规则库 |
4. 机器学习路由（ML Model-Based Routing）
训练专门的分类器模型执行路由任务：
| 与LLM路由的区别 | LLM路由 | ML路由 |
|---|---|---|
| 决策方式 | 推理时执行提示 | 路由逻辑编码在权重中 |
| 模型类型 | 生成式模型 | 判别式模型（分类器） |
| 速度 | 较慢 | 快 |
📊 四种方式对比
| 维度 | LLM路由 | 向量路由 | 规则路由 | ML路由 |
|---|---|---|---|---|
| 速度 | 慢 | 快 | 最快 | 快 |
| 成本 | 高 | 低 | 最低 | 低 |
| 灵活性 | 最高 | 高 | 低 | 中等 |
| 准确性 | 高 | 中高 | 取决于规则 | 高 |
| 适用场景 | 复杂分类 | 语义匹配 | 简单明确 | 高频调用 |
选择建议
- 初期开发/原型验证：用LLM路由
- 语义理解要求高：用向量路由
- 场景简单明确：用规则路由
- 生产环境高并发：用ML路由或规则路由
🎯 路由的应用时机
入口路由
在最开始对任务进行分类：
用户输入 → 入口路由 → 销售/技术/账户/通用中间路由
在处理链的中间点决定下一步：
理解问题 → 中间路由 → 查数据库 or 直接回答工具选择路由
在子程序中选择最合适的工具：
获取天气 → 工具路由 → 天气API / 搜索引擎 / 本地缓存📋 实际应用场景
| 场景 | 路由逻辑 | 价值 |
|---|---|---|
| 人机交互 | 分析意图 → 信息检索/操作执行/转人工 | 上下文相关响应 |
| 数据处理 | 分析格式 → JSON解析/CSV处理/紧急升级 | 自动分类分发 |
| 多智能体 | 分析任务 → 搜索/总结/分析智能体 | 专业分工协作 |
🔄 路由 vs 提示链
核心区别
| 维度 | 提示链 | 路由 |
|---|---|---|
| 执行方式 | 线性顺序 | 条件分支 |
| 路径 | 固定 | 动态选择 |
| 比喻 | 流水线 | 调度中心 |
| 适用场景 | 确定性任务 | 多样化输入 |
两者的关系
路由和提示链是互补的：
- 路由决定「走哪条路」
- 提示链决定「这条路怎么走」
用户输入
│
▼
┌──────────┐
│ 路由 │ ← 决定走哪条路
└────┬─────┘
│
┌────┴────┬────────┐
▼ ▼ ▼
提示链A 提示链B 提示链C🔬 实战案例：智能客服系统
场景描述
构建一个电商平台的智能客服系统，需要处理：
- 订单查询（查物流、查状态）
- 退款退货（申请退款、退货进度）
- 产品咨询（规格、功能、对比）
- 投诉建议（不满意、要投诉）
- 闲聊问候（你好、谢谢）
系统架构：路由 + 提示链组合
┌─────────────────────────────────────────────────────────────────────┐
│ 智能客服系统 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ [用户消息] │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────┐ │
│ │ 🔀 入口路由（LLM路由） │ │
│ │ "分析用户意图，输出类别" │ │
│ └──────────────┬───────────────────────┘ │
│ │ │
│ ┌────────────┼────────────┬────────────┬────────────┐ │
│ ▼ ▼ ▼ ▼ ▼ │
│ │
│ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │订单查询│ │退款退货│ │产品咨询│ │投诉建议│ │闲聊问候│ │
│ │ 提示链 │ │ 提示链 │ │ 提示链 │ │ 提示链 │ │ 提示链 │ │
│ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ │
│ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ │
│ │
│ [详见下方各提示链详细流程] │
│ │
└─────────────────────────────────────────────────────────────────────┘提示链A：订单查询流程
┌─────────────────────────────────────────────────────────────────┐
│ 📦 订单查询提示链 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 步骤1：提取订单信息 │
│ ┌────────────────────────────────────────┐ │
│ │ 角色：信息提取专家 │ │
│ │ 任务：从用户消息中提取订单号或手机号 │ │
│ │ 输出：JSON { "order_id": "...", │ │
│ │ "phone": "..." } │ │
│ └──────────────────┬─────────────────────┘ │
│ │ │
│ ▼ │
│ 步骤2：🔀 中间路由（信息完整性检查） │
│ ┌────────────────────────────────────────┐ │
│ │ 有订单号/手机号？ │ │
│ │ ├─ 是 → 继续步骤3 │ │
│ │ └─ 否 → 跳转到「追问信息」子链 │ │
│ └──────────────────┬─────────────────────┘ │
│ │ │
│ ▼ │
│ 步骤3：调用订单API │
│ ┌────────────────────────────────────────┐ │
│ │ 工具调用：order_query_api │ │
│ │ 输入：订单号或手机号 │ │
│ │ 输出：订单详情JSON │ │
│ └──────────────────┬─────────────────────┘ │
│ │ │
│ ▼ │
│ 步骤4：🔀 中间路由（查询结果判断） │
│ ┌────────────────────────────────────────┐ │
│ │ 查询结果？ │ │
│ │ ├─ 找到订单 → 继续步骤5 │ │
│ │ ├─ 未找到 → 生成"未找到"回复 │ │
│ │ └─ API异常 → 转人工客服 │ │
│ └──────────────────┬─────────────────────┘ │
│ │ │
│ ▼ │
│ 步骤5：生成友好回复 │
│ ┌────────────────────────────────────────┐ │
│ │ 角色：客服专家 │ │
│ │ 任务：将订单信息转换为用户友好的回复 │ │
│ │ 要求：包含物流状态、预计到达时间 │ │
│ └────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘提示链B：退款退货流程
┌─────────────────────────────────────────────────────────────────┐
│ 💰 退款退货提示链 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 步骤1：意图细分 │
│ ┌────────────────────────────────────────┐ │
│ │ 角色：意图分析师 │ │
│ │ 任务：判断是申请退款、查询进度还是取消 │ │
│ │ 输出：{ "sub_intent": "apply/query/cancel" } │
│ └──────────────────┬─────────────────────┘ │
│ │ │
│ ▼ │
│ 步骤2：🔀 子意图路由 │
│ ┌────────────────────────────────────────┐ │
│ │ sub_intent = ? │ │
│ │ ├─ apply → 退款申请子链 │ │
│ │ ├─ query → 进度查询子链 │ │
│ │ └─ cancel → 取消退款子链 │ │
│ └──────────────────┬─────────────────────┘ │
│ │ │
│ ┌─────────┼─────────┐ │
│ ▼ ▼ ▼ │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 退款申请 │ │ 进度查询 │ │ 取消退款 │ │
│ │ 子链 │ │ 子链 │ │ 子链 │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ [每个子链都是完整的提示链，包含信息收集、 │
│ API调用、结果处理、回复生成等步骤] │
│ │
└─────────────────────────────────────────────────────────────────┘提示链D：投诉建议流程（含升级路由）
┌─────────────────────────────────────────────────────────────────┐
│ 😤 投诉建议提示链 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 步骤1：情绪分析 │
│ ┌────────────────────────────────────────┐ │
│ │ 角色：情绪分析专家 │ │
│ │ 任务：分析用户情绪强度（1-10） │ │
│ │ 输出：{ "emotion_level": 8, │ │
│ │ "keywords": ["骗子","投诉"] } │ │
│ └──────────────────┬─────────────────────┘ │
│ │ │
│ ▼ │
│ 步骤2：🔀 情绪强度路由 │
│ ┌────────────────────────────────────────┐ │
│ │ emotion_level = ? │ │
│ │ ├─ 1-4（轻微）→ AI安抚回复 │ │
│ │ ├─ 5-7（中等）→ 记录+安抚+跟进 │ │
│ │ └─ 8-10（强烈）→ 立即转人工 │ │
│ └──────────────────┬─────────────────────┘ │
│ │ │
│ ┌─────────┼─────────┐ │
│ ▼ ▼ ▼ │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ AI安抚 │ │ 记录跟进 │ │ 转人工 │ │
│ │ 子链 │ │ 子链 │ │ 流程 │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘完整对话示例
用户：我的订单到哪了？订单号是 2024122201234
系统处理流程：
1. 入口路由
输入："我的订单到哪了？订单号是 2024122201234"
LLM分析 → 输出："订单查询"
路由决策：进入「订单查询提示链」
2. 订单查询提示链 - 步骤1
提取信息 → { "order_id": "2024122201234" }
3. 订单查询提示链 - 步骤2（中间路由）
有订单号？→ 是 → 继续
4. 订单查询提示链 - 步骤3
调用API → 获取订单详情
{
"status": "配送中",
"courier": "顺丰",
"tracking_no": "SF1234567890",
"eta": "今天18:00前"
}
5. 订单查询提示链 - 步骤4（中间路由）
找到订单？→ 是 → 继续
6. 订单查询提示链 - 步骤5
生成回复系统回复：
您好！您的订单（2024122201234）正在配送中 🚚
📦 物流信息：
- 快递公司：顺丰速运
- 运单号：SF1234567890
- 预计送达：今天18:00前
您可以点击[查看物流详情]实时追踪包裹位置。还有其他问题吗？
关键设计要点
| 要点 | 说明 |
|---|---|
| 层级路由 | 入口路由分大类，子链内部再细分 |
| 结构化传递 | 每一步都用JSON传递，确保数据完整 |
| 容错路由 | 每个关键节点都有异常处理路径 |
| 情绪感知 | 根据用户情绪动态调整处理策略 |
| 人机协作 | 复杂/敏感问题及时转人工 |
📝 核心要点
| 要点 | 说明 |
|---|---|
| 动态决策 | 路由使智能体能根据条件动态决定下一步 |
| 多样化处理 | 允许智能体处理多样化输入，超越线性执行 |
| 多种实现 | 可用LLM、规则、向量相似度或ML分类器实现 |
| 与提示链互补 | 路由决定走哪条路，提示链决定怎么走 |
🔧 工具支持
| 框架 | 特点 |
|---|---|
| LangGraph | 基于图的状态机架构，适合复杂多步骤路由 |
| Google ADK | 基于工具定义，框架自动路由到对应处理器 |
| LangChain | 丰富的链式调用和路由组件 |
🔗 相关阅读
参考资源：