智能体接住用户请求之后的第一件事不是调模型，而是判断这条请求该走哪条路径。 Anthropic 在《构建高效智能体》里把这件事单列为一种基础工作流——路由（Routing）：先对输入分类，再定向到专门的后续任务，好处是关注点分离、每条路径可以单独优化提示词，避免为照顾一类输入而牺牲另一类的效果。
为什么路由值得单独做一层
不做路由的系统通常是一个大而全的提示词加一堆工具，结果有三类症状：
- 为了兼容所有场景，提示词越写越长，最终谁都不讨好；
- 工具表一大，模型选错工具的概率明显上升；
- 出问题时无法定位——到底是理解错了还是执行错了，日志里看不出来。
加一层路由之后，每个分支只需要面对一类输入，提示词短、工具少、可测。这是用一点架构复杂度换可维护性，在分支超过三个之后通常就划算了。
三层结构：分类 → 分发 → 兜底
第一层：分类
分类器的输出必须是受控枚举，不是自由文本。实践中让模型直接输出类别标签，再用代码校验标签是否在白名单内，比解析自然语言描述可靠得多。输出格式的约束可以复用结构化输出 schema的做法，把类别、置信度、理由三个字段固定下来。
两个实用约束：
- 类别数量控制在 5 到 12 个。太少等于没分，太多分类本身就会出错；
- 必须有一个「其他」类。不允许模型硬塞进最接近的类别，兜不住就明确走兜底。
第二层：分发
分发是纯代码逻辑，不应该再交给模型决定。一个类别对应一个处理器：固定提示词、固定工具子集、固定输出格式。这样做的好处是单条路径可以独立评测和灰度，改动一个分支不会波及全局。
第三层：兜底
兜底分两种情况，处理方式不同：
- 低置信度：不要猜，直接向用户澄清。澄清话术要给出可选项，而不是问「你想做什么」；
- 执行失败：重试、降级、转人工三选一。重试要有次数上限并区分可重试错误，这一层的设计可以参考工具调用重试与降级。
分类器用模型还是用规则
| 方式 | 适用 | 代价 |
|---|---|---|
| 关键词/正则 | 类别边界清晰、量大的头部请求 | 覆盖不到长尾，维护成本随规则数上升 |
| 传统分类模型 | 有标注数据、要求低延迟低成本 | 需要训练与持续迭代 |
| 大模型分类 | 边界模糊、冷启动、长尾多 | 每次请求多一次调用，要控制提示词长度 |
推荐组合：头部高频请求用规则硬匹配（快且零成本），剩下的交给模型。规则层同时充当回归测试的基线——模型分类改动后，规则能兜住的部分不应该漂移。
落地步骤
- 从真实日志里采样两百条请求，人工归并出 5 到 12 个类别，并保留一个「其他」。
- 为每类写一句判据，判据必须能被第二个人复现，否则类别划分不成立。
- 实现分类器：先上规则层覆盖头部请求，剩余部分走模型分类。
- 强制结构化输出并校验枚举值，非法值一律落到兜底而不是就近归类。
- 写分发表：每个类别绑定固定提示词、工具子集与输出格式，分发逻辑用代码实现。
- 设置置信度阈值，低于阈值触发澄清话术并给出可选项。
- 记录路由日志，每周抽样复盘分类错误，把错例回灌进判据或规则层。
和状态机、编排的关系
路由解决的是「入口分流」，一旦请求进入某条路径之后的多步流转，就属于状态机或编排层的事了。两者不要混在一起：路由是无状态的单次判断，编排要维护执行状态。如果业务确实需要多步流转，可以在路由之后再接一层状态机编排，职责边界会清楚很多。
另外，路由层天然是安全边界的好位置：在进入任何工具之前，先在这一层做一次输入与权限校验，比在每个处理器里各做一遍更可靠。具体做法可参考智能体护栏实现。
分类一定要用大模型吗
类别数量多少合适
置信度低的时候该猜还是该问
路由会让响应变慢吗
结论：路由是整个智能体系统里投入产出比最高的一层。它不产生智能，却决定了后面每一层能不能被独立优化、独立评测、独立回滚。没有路由的智能体，本质上是在用一个提示词赌所有场景。
评论 (0)