开篇：不是所有问题都该走同一条路

上一章讲提示链。提示链像流水线：第一步做完，再交给第二步。它适合路径固定的任务。

但真实业务不是这样。用户的问题五花八门。有人查订单，有人问退款，有人问产品，有人投诉。你不能把所有问题都丢给同一个大模型。

这时就需要路由。

路由的本质很简单：先判断问题属于哪一类，再交给最合适的工具、知识库、子流程或子 Agent。

1. 什么是路由模式

路由模式，就是给 Agent 加一个“分诊台”。

它不急着回答。它先判断。

这个问题是订单问题，还是技术问题？是普通咨询，还是高风险投诉？要查数据库，还是查知识库？要自动处理，还是转人工？

判断清楚之后，再走对应路径。

《智能体设计模式》里把路由定义为一种动态决策能力：系统根据用户输入、环境状态或上一步结果，在多个动作之间选择合适的路径。

• 用户问“订单到哪里了” → 查订单系统。

• 用户问“这个产品怎么用” → 查产品知识库。

• 用户问“我要投诉” → 判断风险等级，必要时转人工。

• 用户问题不清楚 → 不硬答，先追问。

2. 路由和提示链有什么区别

提示链解决的是“按步骤做”。路由解决的是“该走哪条路”。

一个是流水线，一个是十字路口。

提示链适合路径明确的任务，比如：提取信息、总结内容、生成报告、优化文案。

路由适合路径不固定的任务，比如：客服分流、工具选择、模型选择、知识库选择、多 Agent 调度。

复杂系统里，两者通常一起用：先路由到某条路径，再在这条路径内部用提示链分步骤执行。

3. 路由的核心流程

一个合格的路由器，不能只返回一句“我觉得是订单问题”。它应该输出结构化结果。

至少包含三类信息：route、confidence、entities。

route 表示要走哪条路径。confidence 表示模型有多确定。entities 表示下游系统需要的参数，比如订单号、商品名、时间范围。

• 输入清洗：去掉噪声，补齐必要上下文。

• 意图识别：判断用户到底想做什么。

• 置信度判断：不确定就追问，不要硬走。

• 路径选择：把任务交给工具、RAG、子 Agent 或人工。

• 结果汇总：执行后统一组织答案。

• 日志评估：记录每一次路由是否正确。

4. 四种常见路由方式

工程里做路由，不是只有“让大模型判断”这一种方法。

越靠近生产环境，越要考虑稳定性、成本、延迟和可解释性。

规则路由最简单。比如命中“退款”“退货”“售后”，就走退款流程。它快、便宜、可控，但不够灵活。

LLM 路由最灵活。它可以理解复杂自然语言，但成本更高，也需要约束输出格式。

向量路由适合知识域很多的场景。先把问题变成向量，再找最相似的能力、工具或知识库。

分类器路由适合高频稳定业务。等积累了足够样本，再训练一个轻量分类模型，成本会更低。

5. 典型案例：智能客服路由

智能客服是最容易理解的路由场景。

用户不会按照系统菜单提问。他只会说一句自然语言。系统必须先判断意图，再决定查哪个系统。

比如用户问：“我买的东西还没到，能退吗？”

这里面可能同时包含订单状态和退款诉求。路由器不能只看关键词。它要结合上下文判断：先查订单，再判断是否满足退款条件。

• 订单类：查订单库，返回物流和状态。

• 退款类：查支付系统和售后规则。

• 商品类：查商品知识库或产品说明。

• 技术类：进入故障排查链。

• 投诉类：判断严重程度，必要时转人工。

• 不明确：先追问，不要乱答。

6. 框架里路由怎么跑

不用先背框架 API。先看运行时逻辑。

路由本质上就是：读状态，做判断，写结果，跳到下一个节点。

在 LangChain 里，RunnableBranch 的逻辑接近 if-elif-else：条件从上到下判断，命中哪个条件，就执行对应分支；如果都不命中，就走默认分支。

在 LangGraph 里，路由更像状态机。每个节点读写 State，conditional edge 根据当前 State 选择下一个节点。这样适合多轮、有状态、需要回退的 Agent。

在 OpenAI Agents SDK 里，Handoff 可以让一个 Agent 把任务转交给另一个专门 Agent。客服场景里，前台 triage agent 可以把任务转给退款 Agent、订单 Agent 或 FAQ Agent。

在 Google ADK 里，多智能体可以由一个协调者组织多个子 Agent，适合做“一个入口，多个专业处理器”的系统。

真正落地时，路由输出最好是固定结构，比如：

• route：order_status / refund / faq / tech_support / clarify / human

• confidence：0 到 1 之间的置信度。

• entities：订单号、商品名、时间、用户 ID 等下游参数。

• reason：简短原因，方便日志排查。

7. 什么时候应该用路由

不要为了炫技而路由。问题很简单时，一条提示链就够了。

出现下面几种情况，再考虑路由。

• 用户问题类型很多，不同类型要走不同处理逻辑。

• 系统有多个工具，需要判断该调用哪个。

• 系统有多个知识库，需要判断查哪个库。

• 系统有多个模型，需要按成本和复杂度分流。

• 有高风险场景，需要自动转人工或审批。

• 多 Agent 协作时，需要一个协调者分配任务。

8. 路由最容易踩的坑

• 只靠关键词：用户说“退不了吗”，不一定只是退款，也可能是投诉。

• 不做置信度：模型不确定时还硬走，最容易答错方向。

• 输出不结构化：路由器输出一段话，下游很难解析。

• 没有默认路径：遇到未知问题直接崩。

• 没有评估集：你不知道路由到底准不准。

• 没有日志：出了问题无法定位是分类错、参数错，还是下游工具错。

• 过度路由：本来一个模型能处理的小问题，拆成十几个分支，系统复杂度反而失控。

9. 一个好路由器的标准

第一，输出稳定。必须返回固定枚举，不能今天叫 order，明天叫 order_status。

第二，能处理不确定。置信度低就追问，不要装懂。

第三，能解释。日志里要看得出为什么走这条路。

第四，能评估。每类样本要有命中率，不能靠感觉。

第五，能扩展。新增一个业务，不应该改一堆老逻辑。

第六，能兜底。没有命中路线，也要有安全默认路径。

总结

提示链让 Agent 会按步骤做事。

路由让 Agent 会做选择。

没有路由，复杂 Agent 很容易变成一个“大杂烩模型”：什么都管，什么都管不好。

有了路由，系统可以把不同问题交给不同能力处理。订单查订单库，知识问知识库，复杂问题交给专家 Agent，高风险问题转人工。

路由不是越复杂越好。真正好的路由，是简单、稳定、可解释、可评估。

下一章，我们继续讲并行化：当多个任务可以同时做时，如何让 Agent 不排队，直接并发执行。