路由(Routing)— 让 AI 学会“先判断,再分工”

一、先说结论:路由是 Agent 系统的“分诊台”

路由模式,说人话就是:先让 AI 判断用户想做什么,再把这个请求交给最合适的处理流程。

它不是让一个 AI 什么都干,而是让 AI 先当“分诊台”“前台接待”或“导航路口”。用户来了,先判断他是要查订单、退货、投诉、咨询商品,还是需要人工帮助。判断清楚后,再交给对应的“专员”处理。

这就是 Agent 设计模式里的 Routing,路由模式

想象你去医院看病。

你不会一进门就直接冲进手术室,也不会随便找一个医生开药。正常流程是:

患者来到医院

分诊台询问症状

判断该去内科、外科、急诊还是检查科

对应科室继续处理

AI 系统里的路由也是类似逻辑。

它的核心不是“回答问题”,而是“判断问题该交给谁”。

流程图画布 · 115%
Mermaid 流程图加载中...

一句话概括:

路由不是干活的人,而是派活的人。

二、为什么需要路由:一个 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. 兜底:处理不确定情况

真实用户输入很复杂,系统不可能每次都判断准确。所以一定要有兜底分支。

用户:我这个情况你们看着办吧。

这种表达不够明确,系统就应该继续追问:

我需要再确认一下,您是想查询订单、申请售后,还是反馈使用问题?

而不是强行猜测。

完整流程可以这样理解:

流程图画布 · 115%
Mermaid 流程图加载中...

兜底分支不是失败。它是系统避免误判的安全阀。

四、什么时候适合用路由

只要你的 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 路由
不确定请求 → 兜底追问或人工

这就是“先用大模型摸清业务,再把稳定路径降本”的思路。

八、如何评估路由是否可靠

只说“路由更准”没有意义。你需要一组评估样例。

用户输入期望标签实际标签是否命中备注
我想取消昨天的订单refundrefund明确售后
快递三天没动了orderorder明确物流
你们一直不处理,太差了complaintorder投诉优先级没生效
这个怎么弄unclearproduct信息不足,应追问

建议至少准备 30-100 条样例,覆盖每个标签、边界表达和混合意图。

评估时重点看四个指标:

  • 准确率:标签是否命中;
  • 混淆矩阵:哪些标签最容易互相混;
  • unclear 占比:是不是过于保守;
  • 人工升级率:多少请求需要人处理。

路由评估不是一次性工作。每次新增业务分支,都应该补样例,否则标签会越来越乱。

九、路由和提示词链、工具调用有什么关系

这三个概念容易混在一起,可以这样区分:

概念解决的问题例子
路由这个请求该走哪条处理路径退款问题进入售后流程
提示词链一个任务内部先做什么、后做什么检查订单状态 → 判断是否可退 → 生成回复
工具调用什么时候调用哪个外部工具查询订单、查库存、创建售后单
多 Agent 协作谁负责哪类工作coding agent 写代码,review agent 审稿

所以,路由通常是“分工”的入口。它先决定方向,后面的链路、工具或 Agent 再继续处理具体任务。

十、一句话记住路由模式

路由不是让 AI 回答问题,而是让 AI 先判断问题应该交给谁处理。

好的路由系统不追求每次都猜中,而是做到:

能明确判断时稳定分发;
不能明确判断时安全兜底;
分错以后能通过日志和评估样例继续修。