四层漏斗架构：生产级Agent意图路由系统设计指南

你的 Agent 真的听懂用户在说什么了吗？用户说"我卡被偷了"，系统调用了挂失流程而非盗刷报告；用户同时提了退款和积分查询，Agent 只处理了第一个；情绪词"太慢了"把退款请求劫持到了投诉流程——这些都是意图路由系统的典型翻车现场。

本文基于B站「造物工坊」系列第二期内容，系统拆解一套生产级的四层漏斗意图路由架构，从设计思路、踩坑经验到可落地的代码方案，帮你构建一个真正能听懂人话的 Agent。

意图路由的四种死亡模式

在深入架构之前，我们需要先诊断清楚问题出在哪里。意图路由系统有四种典型的失败模式，每一种都对应着真金白银的损失。

第一种：意图混淆。 相似意图的语义边界太近，单一模型无法区分。Banking77 数据集里，仅 card_arrival 和 card_delivery_estimate 两个意图就贡献了 30% 的错误路由——不是模型不聪明，是意图本身太近了。

第二种：多意图盲区。 研究数据显示，18% 的用户会话包含两个以上意图，但传统单标签训练让模型天然只输出一个结果，第二条指令直接被吞掉。

第三种：情绪词劫持。 高权重的情感词（如"太慢了""态度差"）干扰了语义路由的注意力分布，把正常的业务请求错误地截流到投诉流程。

第四种：路由雪崩。 这是最隐蔽的死法。Agent 第一次路由错误，重试加重错误，错误路由变成重复请求，重复请求打满 CPU，CPU 过载导致更多错误路由。A/B 测试数据显示，没有熔断机制的情况下，负载能增长 40%-60%。系统返回 200，日志干净，但 80% 的请求已经被错误路由了。

这四种死亡模式指向同一个根因：你把所有请求当成了同一个代价。 修复方案不是换更大的模型，而是建一个漏斗。

核心认知转变：从分类问题到漏斗工程

在动手搭建之前，必须先扭转一个关键认知：意图识别不是 NLP 分类问题。

NLP 分类追求的是准确率 99%，但路由系统的目标是拦截率 × 延迟 × 成本的三目标联合优化。你要思考的核心问题是：什么样的请求可以零模型开销解决？什么样的请求值得花一两秒调大模型？

行业已经达成共识：小模型层被淘汰了。原因有四个——比向量路由慢（小模型推理 500ms vs 向量匹配 30-100ms）、比大模型 FC 不准（分类漂移、无法提取槽位、不能反问澄清）、总成本不低（小模型+主模型两次调用 ≥ 单次大模型 FC）、维护成本高（训练数据+模型更新+部署）。

所以现在只剩两条路：向量语义路由是快路径，大模型 FC 是慢路径。 80%-85% 的问题在快路径解决，只有真正需要推理理解的请求才进慢路径。

四层漏斗架构详解

L0：预编译正则 + Trie 前缀树（<1ms，拦截 60%-80%）

这是整个系统最便宜的一层。用户输入 /天气，一秒都不用想，直接走天气路由。所有斜杠命令、固定语义短语都在这里直接命中。

实现方式是预编译正则表达式 + Trie 前缀树。但这里有一个致命的坑：正则必须在模块加载时预编译，作为模块级变量，而不是在函数内部每次调用时重新编译。

这个坑的代价有多大？最初的实现把 re.compile 放在路由函数里，测试环境几十个请求完全正常。上到生产环境日均 10 万请求，一条斜杠命令 CPU 打了整整两秒才匹配——因为每个请求都在重新编译整条正则链。修复就是一行改动：把 compile 提到模块顶层变成常量，CPU 瞬间从 95% 降到 2%。

一个变量的作用域，决定了你全站 60% 流量的 CPU 账单。

L1：向量语义路由（30-100ms，再拦截 15%-25%）

这是目前最被低估的一层。原理很简单：为每个意图定义 3-20 条例句，编码成 embedding 后，该意图在向量空间里形成一个清晰的语义区域。新查询进来，编码后求余弦相似度，直接落到最近的意图区域。

关键细节是例句数量不能太少。比如"退款"这个意图，你需要注入"退款""退钱""我要退货""这个订单帮我取消""钱退哪里"等多种表达方式，3-20 条例句才能覆盖足够的语义空间。

性能数据相当可观：CLINC150 基准上，80 条微调数据就能做到 85.9% 的准确率，完整 fine-tune 能达到 96% 以上。注意，完全不需要 LLM，纯数学计算，30-100ms 完成。

实现上可以直接使用 Python 的 semantic_router 库，核心代码只有五行：定义意图路由对象、配置示例句、创建路由器、传入编码器、调用返回命中意图。

三层成本对比一目了然：L0 正则 <1ms、零成本；L1 向量 30-100ms、每条请求 $0.0001；L2 大模型 1-2s、$0.002。L1 在 Top20 高频意图上准确率能达到 95% 以上，比 L2 只差 1.5 个百分点，但延迟降到 1/30，成本降到 1/30。

L2：大模型 FC + 结构化输出（1-2s，处理最后 5%-15%）

只有长尾意图、多意图混合、需要槽位填充的复杂查询才值得花大模型的费用。这层的关键不是选什么模型，而是用什么格式限制输出。

绝不用自由文本输出意图名。 自由文本等于邀请幻觉——模型可能输出一个你没定义过的、拼写错误的、甚至用另一种语言写的意图名。正确做法是用 Enum + JSON Schema 约束：OpenAI 的 strict: true + response_format: json_schema，数学上保证不可能输出枚举值之外的结果。Anthropic 的 function calling、Gemini 的 JSON Schema 模式同样提供格式保证。

L2 还有一项关键能力：槽位填充。用户要定机票，目的地、出发地、日期三个槽位缺任何一个都不能执行。系统需要识别意图→检测缺失槽位→反问补充→接收填充→执行。这里有三个边界条件必须处理：活跃槽位检测（用户说"北京"是在填充上一轮的出发地，不是新意图）、取消检测（"算了不定了"要清空所有槽位）、上下文继承（上轮意图未变时直接填充）。

还有一个最容易被忽略的参数：Temperature 必须设为 0。默认值 0.7 会导致同一句话三次输出三个不同意图。你要的是分类，不是多样性。这行代码的改动，可能比 L0+L1+L2 三层加起来对路由稳定性的贡献都大。

SafeNet：安全网（<3% 请求）

安全网做三件事：置信度分级、OOD 检测、熔断机制。

置信度分三级： >0.8 直接执行；0.6-0.8 执行但标记待复核，同时送入复核队列定期扩充 Few-Shot；<0.6 不执行，反问澄清。核心逻辑是：低置信 + 瞎执行 = 生产事故，低置信 + 反问 = 零风险。

OOD（域外）检测： 用户说"帮我写首诗"，所有业务意图置信度全部低于 0.3。没有 OOD 检测的后果是模型被硬分类到最接近的意图——"写诗"里有"请求"这个字，被路由到退款请求，调了 API，报错参数不合法。正确做法：所有意图置信度最大值 < 0.4，判定 OOD，直接回答"我只能处理退款、订票相关问题"。

熔断机制： 同一 session 连续三次低置信度（<0.6），关闭 L2 层五次请求，只保留 L0+L1 降级服务，五次后再放开 L2 验证是否恢复。这是 Netflix Hystrix 的电路断路器模式直接搬到 Agent 路由，防止恶意输入打满 LLM 调用，防止一个糟糕的 session 拖慢整个服务。

可观测性与持续优化

意图路由的失败不表现为 500 错误，而是返回 200 但意图是错的。传统健康检查完全检测不了，你需要三个独立指标：

1. 错误路由率： 每天抽样 100 条请求，人工标注真实意图对比路由结果，日错误率超过 5% 就告警。
2. P95 延迟： 超过 300ms 说明太多请求穿透到了 L2。
3. 意图分布 KL 散度： 监控 Top10 意图的日环比变化，超过 20% 说明业务在变但路由没跟上。KL 散度是一个 silent killer，没人监控它，直到三个月后才发现新产品线 80% 的查询被错误路由到旧分类。

持续优化依赖数据飞轮：用户说"你理解错了"自动标记为负样本，用户点击推荐方案自动标记为正样本；负样本进标注队列扩充对应意图的 Few-Shot 示例，正样本直接加入 Golden Set；每月用 Golden Set（每个意图 50-100 条）重新校准 L1 的 Embedding 和 L2 的 Few-Shot。每次修改路由规则必须过 Golden Set 回归测试，防止修好一个边缘 case 破坏 90% 的常见场景。

四条意图路由铁律

1. 规则优先，模型兜底： 能 0ms 解决的别花 1-2 秒。
2. 意图用枚举，永远不用自由文本： 数学保证比 Prompt 承诺可靠一万倍。
3. 低置信反问，不高置信瞎猜： 一句反问的成本是 0，一个错误路由的成本是订单丢失。
4. 上线第一天就埋监控： 意图漂移是 silent killer，你永远不知道它什么时候开始，但你知道它一定会来。

四层架构合在一起，延迟只是全大模型方案的 1/3，成本只有 1/4。一个能听懂人话的 Agent，不是在 Prompt 里解释出来的，是一层层过滤出来的。