路由(Routing)— 让 AI 学会“先判断,再分工”
一、先说结论:路由是 Agent 系统的“分诊台”
路由模式,说人话就是:先让 AI 判断用户想做什么,再把这个请求交给最合适的处理流程。
它不是让一个 AI 什么都干,而是让 AI 先当“分诊台”“前台接待”或“导航路口”。用户来了,先判断他是要查订单、退货、投诉、咨询商品,还是需要人工帮助。判断清楚后,再交给对应的“专员”处理。
这就是 Agent 设计模式里的 Routing,路由模式。
想象你去医院看病。
你不会一进门就直接冲进手术室,也不会随便找一个医生开药。正常流程是:
患者来到医院
↓
分诊台询问症状
↓
判断该去内科、外科、急诊还是检查科
↓
对应科室继续处理AI 系统里的路由也是类似逻辑。
它的核心不是“回答问题”,而是“判断问题该交给谁”。
一句话概括:
路由不是干活的人,而是派活的人。二、为什么需要路由:一个 AI 不可能用同一套流程解决所有问题
很多刚开始做 AI 应用的人,会习惯性地把所有请求都丢给同一个大模型:
用户问什么 → AI 直接回答这个方式做演示可以,但一到真实业务就容易出问题。
比如一个电商客服机器人,用户可能会问:
我下的订单什么时候发货?
这件衣服能退吗?
你们商品质量太差了,我很不满意。
这双鞋还有 42 码吗?
优惠券在哪里领?
我想找人工客服。这些问题看起来都属于“客服”,但背后的处理方式完全不同:查订单要连订单系统,退货要走售后流程,投诉要先安抚情绪,商品咨询要查商品库,优惠券问题可能要查营销活动。
如果所有问题都走同一条流程,就会出现这种情况:
用户:我下的订单怎么还没发货?
机器人:这款商品有黑色和白色两个颜色。
用户:我要退货。
机器人:请问您想了解哪款商品?
用户:你们服务太差了!
机器人:请提供订单号。问题不在于 AI “不聪明”,而在于系统没有先判断“这是什么类型的问题”。
有了路由,系统就变成这样:
查订单 → 订单流程
要退货 → 售后流程
强烈不满 → 投诉流程
问商品 → 导购流程
看不懂 → 兜底澄清或转人工这就是路由模式存在的原因。
三、路由到底在做什么:听、判、派、兜底
路由模式通常可以拆成四个动作。
1. 听:接收用户输入
系统先拿到用户的原始请求。
我买的羊毛衫掉毛很严重,想退掉。这句话里同时包含两个信息:用户对商品质量不满意,用户想退货。如果系统只看关键词,可能会把它分到“退货”;如果系统更关注情绪和投诉,也可能把它分到“投诉”。这就需要下一步判断。
2. 判:识别用户意图
路由器要判断这句话最应该归到哪一类。比如提前定义好这些标签:
order:订单、物流、发货时间
refund:退货、换货、退款
complaint:投诉、不满、严重负面反馈
product:商品信息、尺码、颜色、参数
coupon:优惠券、活动、折扣
human:明确要求人工
unclear:无法判断或其他问题注意,这里非常关键:路由器不要自由发挥,只能在给定标签里选。
如果它一会儿输出 order,一会儿输出 物流问题,一会儿输出 shipping_issue,后面的程序就没法稳定处理。
3. 派:交给对应处理模块
判断出标签之后,系统把请求交给对应的处理流程。
refund → 售后流程
complaint → 投诉流程
order → 订单查询流程
product → 商品咨询流程
coupon → 营销活动流程
human → 人工客服
unclear → 追问澄清路由器自己不处理业务。它只是决定“往哪走”。
4. 兜底:处理不确定情况
真实用户输入很复杂,系统不可能每次都判断准确。所以一定要有兜底分支。
用户:我这个情况你们看着办吧。这种表达不够明确,系统就应该继续追问:
我需要再确认一下,您是想查询订单、申请售后,还是反馈使用问题?而不是强行猜测。
完整流程可以这样理解:
兜底分支不是失败。它是系统避免误判的安全阀。
四、什么时候适合用路由
只要你的 AI 系统里存在“不同问题需要不同处理方式”,就适合使用路由。
| 场景 | 是否建议路由 | 原因 |
|---|---|---|
| 只有一个固定问答流程 | 不建议 | 加路由只会增加复杂度 |
| 用户输入很短但标签很多 | 谨慎 | 容易误分,需要先追问 |
| 标签之间边界不清 | 谨慎 | 先重新设计标签体系 |
| 不同请求需要不同工具或权限 | 建议 | 路由能先隔离处理路径 |
| 高风险场景需要人工兜底 | 建议 | 路由可以识别升级条件 |
一个实用判断是:
如果不同问题需要不同资料、工具、权限、流程或负责人,就应该考虑路由。
如果所有问题最终都用同一套上下文和同一套回答方式,路由可能只是额外复杂度。五、常见实现方式:先可控,再智能
路由不是只有一种做法。根据系统复杂度、成本、速度和准确率要求,常见有四类实现方式。
| 方式 | 适合阶段 | 优点 | 典型风险 |
|---|---|---|---|
| 规则路由 | 标签少、关键词明显 | 快、便宜、稳定 | 覆盖不了隐含表达 |
| LLM 路由 | 早期探索、语义复杂 | 理解能力强,上手快 | 输出不稳定,需要校验 |
| 语义路由 | 高频相似问题 | 比 LLM 便宜,速度更快 | 样例质量决定效果 |
| 分类器路由 | 成熟大规模系统 | 推理成本低,输出稳定 | 需要标注数据,标签变化时维护成本高 |
新手可以按这个顺序走:
第一阶段:规则 + LLM 路由
第二阶段:积累真实样例和错误案例
第三阶段:高频路径用语义路由降本
第四阶段:标签稳定后再训练分类器不要一开始就追求“最智能”。路由系统第一目标是可控,第二目标才是智能。
六、完整案例:做一个电商客服路由器
下面用一个电商客服系统做完整例子。
目标是:
用户输入一句客服问题。
系统先判断意图。
再交给订单、售后、投诉、商品、优惠券或人工流程。1. 先定义业务分支
先不要写提示词,先定义标签。
| 标签 | 包含 | 排除 | 优先级 | 示例输入 |
|---|---|---|---|---|
complaint | 投诉、差评、强烈不满 | 普通咨询 | 0 | 你们一直不处理,太差了 |
refund | 退款、退货、取消订单 | 单纯咨询物流 | 1 | 我想退掉这个订单 |
order | 订单、物流、快递状态 | 已明确要求赔偿 | 2 | 我的快递三天没更新 |
product | 商品规格、库存、使用方式 | 售后投诉 | 3 | 这款支持 Type-C 吗 |
coupon | 优惠券、活动、折扣 | 订单退款 | 4 | 优惠券在哪里领 |
human | 明确要求人工客服 | 能自动处理的普通问题 | 5 | 帮我转人工 |
unclear | 信息不足、意图不明 | 能明确归类的问题 | 99 | 这个怎么弄 |
注意 complaint 的优先级最高。因为真实系统里,强情绪和投诉通常需要更谨慎的处理。
2. 写一个可复制的路由提示词
你是电商客服系统的路由器。
你的任务是判断用户输入属于哪个 intent。
只能从下面标签中选择一个:
- order:订单、物流、发货时间
- refund:退货、换货、退款
- complaint:投诉、强烈不满、要求升级处理
- product:商品规格、尺码、颜色、库存
- coupon:优惠券、促销活动、折扣
- human:用户明确要求人工客服
- unclear:无法判断或需要继续追问
判断规则:
1. 如果用户有强烈负面情绪或投诉,优先选择 complaint;
2. 如果用户明确要求人工,选择 human;
3. 如果信息不足,选择 unclear;
4. 不要输出标签列表之外的内容。
输出 JSON:
{
"intent": "...",
"confidence": 0-1,
"reason": "一句话说明判断依据"
}
用户输入:
{{message}}这个提示词里最重要的是两点:标签固定,不确定时允许输出 unclear。
3. 用简化代码理解实现逻辑
路由要接程序,必须把模型输出清洗、校验和分发串起来。
ALLOWED_INTENTS = {
"order",
"refund",
"complaint",
"product",
"coupon",
"human",
"unclear",
}
def normalize_intent(raw_intent):
if not raw_intent:
return "unclear"
intent = raw_intent.strip().lower()
return intent if intent in ALLOWED_INTENTS else "unclear"
def route_message(message):
raw = call_router_model(message)
result = parse_json_or_none(raw) or {}
intent = normalize_intent(result.get("intent"))
confidence = result.get("confidence", 0)
if confidence < 0.6:
intent = "unclear"
log_event({
"type": "router_decision",
"message": message,
"intent": intent,
"confidence": confidence,
"raw_output": raw,
})
handlers = {
"order": handle_order,
"refund": handle_refund,
"complaint": escalate_complaint,
"product": handle_product,
"coupon": handle_coupon,
"human": transfer_to_human,
"unclear": ask_clarifying_question,
}
return handlers[intent](message)这段代码只是最小骨架,但已经包含几个生产里很关键的点:非法标签转 unclear,低置信度转 unclear,原始输入传给后续处理器,每一次路由都记录日志。
七、工程上最容易踩的坑
路由看起来像一个提示词问题,但真正上线时,它更像一个小型分类系统。下面这些点最好一开始就定清楚。
| 坑点 | 错误写法 | 为什么错 | 正确做法 |
|---|---|---|---|
| 让 AI 自由输出 | “判断用户意图并解释” | 程序无法稳定解析 | 只允许固定标签 |
| 没有兜底分支 | 每条都必须分类 | 模糊输入会被硬分 | 增加 unclear |
| 分支职责重叠 | refund 和 complaint 都接强不满 | 同一句话会左右摇摆 | 写清包含、排除和优先级 |
| 一开始拆太细 | 拆 20 个标签 | 样例不足,混淆严重 | 先粗分,再细分 |
| 只传标签 | 后续模块只拿 intent | 丢失用户原文细节 | 同时传 message |
| 不清洗输出 | 直接相信模型 JSON | 可能非法、缺字段 | parse + validate |
| 没有日志 | 分错也不知道 | 无法复盘和调优 | 记录输入、输出、版本 |
如果每天请求量很大,也可以做降本分层:
简单高频请求 → 规则或语义路由
复杂低频请求 → LLM 路由
不确定请求 → 兜底追问或人工这就是“先用大模型摸清业务,再把稳定路径降本”的思路。
八、如何评估路由是否可靠
只说“路由更准”没有意义。你需要一组评估样例。
| 用户输入 | 期望标签 | 实际标签 | 是否命中 | 备注 |
|---|---|---|---|---|
| 我想取消昨天的订单 | refund | refund | 是 | 明确售后 |
| 快递三天没动了 | order | order | 是 | 明确物流 |
| 你们一直不处理,太差了 | complaint | order | 否 | 投诉优先级没生效 |
| 这个怎么弄 | unclear | product | 否 | 信息不足,应追问 |
建议至少准备 30-100 条样例,覆盖每个标签、边界表达和混合意图。
评估时重点看四个指标:
- 准确率:标签是否命中;
- 混淆矩阵:哪些标签最容易互相混;
- unclear 占比:是不是过于保守;
- 人工升级率:多少请求需要人处理。
路由评估不是一次性工作。每次新增业务分支,都应该补样例,否则标签会越来越乱。
九、路由和提示词链、工具调用有什么关系
这三个概念容易混在一起,可以这样区分:
| 概念 | 解决的问题 | 例子 |
|---|---|---|
| 路由 | 这个请求该走哪条处理路径 | 退款问题进入售后流程 |
| 提示词链 | 一个任务内部先做什么、后做什么 | 检查订单状态 → 判断是否可退 → 生成回复 |
| 工具调用 | 什么时候调用哪个外部工具 | 查询订单、查库存、创建售后单 |
| 多 Agent 协作 | 谁负责哪类工作 | coding agent 写代码,review agent 审稿 |
所以,路由通常是“分工”的入口。它先决定方向,后面的链路、工具或 Agent 再继续处理具体任务。
十、一句话记住路由模式
路由不是让 AI 回答问题,而是让 AI 先判断问题应该交给谁处理。
好的路由系统不追求每次都猜中,而是做到:
能明确判断时稳定分发;
不能明确判断时安全兜底;
分错以后能通过日志和评估样例继续修。