做 Intent Routing 这几年我最大的感触是很多团队的 Demo 跑得飞起一上线就被流量和边界情况打回原形。这里的核心不在模型有多强而在**意图路由Intent Routing**这个“交通枢纽”有没有把请求送到对的地方。今天想从一个实操过的案例说起完整拆一下“生产级 Agent 意图路由”从 Demo 原型演进到工业级三层漏斗架构的整个过程包括设计思路、关键参数、踩过的坑以及能直接抄作业的落地配置。先说清楚这篇文章解决什么问题。你如果正在做 Agent 产品客服机器人、Copilot、流程自动化助手之类大概率会遇到一个场景用户输入千奇百怪有的要查数据有的要调用工具有的只是闲聊还有的是完全不相关的垃圾输入。Demo 阶段你可以把所有请求都丢给大模型让它自己判断。但生产环境里模型判断不稳定、延迟不可控、成本高企、安全审计缺失——这些问题会集中爆发。三层漏斗架构就是为了解决这些问题出现的。它把“用户意图到具体执行”的路径拆成三层入口分类层 → 语义意图识别层 → 技能参数路由层。每一层各司其职用不同粒度的策略做决策。我自己的项目里这套架构把路由准确率从 Demo 阶段的 82% 提到了生产环境的 97.5%单次路由延迟从平均 1.5s 降到了 220ms成本更是降了一个数量级。下面我会把每一层的设计逻辑、关键技术参数、以及从 Demo 迁移时的改造清单全部翻出来讲。1. 为什么 Demo Agent 撑不起生产流量1.1 意图路由智能体的“交通枢纽”先回到最基础的问题Agent 应用里意图路由到底是什么简单说它就是决定“用户这句话应该交给哪个处理器”的机制。比如用户说“帮我查一下昨天的订单量”系统要决定这条请求是走 SQL 查询引擎、还是走报表服务、还是直接回绝。这个决策的准确性和速度决定了整个 Agent 体验的下限。很多人以为意图路由是 Agent 框架自带的功能。确实像 LangChain、Semantic Kernel 这些框架里都有类似 Router 的组件但生产级工程里框架自带的 Router 通常太“薄”只做简单的 prompt 分类或者工具名选择根本没有层与层之间的缓冲、校验、兜底和缓存。真正常见的工业级做法是自研一层路由逻辑把框架的编排能力作为底层执行引擎来用。我见过一个很有代表性的反例有个团队直接让 LLM 在每次请求时从 30 多个工具里选一个Demo 里看起来没问题。一上线用户一句话里往往包含两种以上意图比如“帮我对比一下昨天的订单和上周的顺便发个周报邮件”。LLM 选了一个工具把两个任务拆得七零八落或者选了邮件工具但没查数据更麻烦的是有一批用户输入了模糊表述LLM 开始“编造”工具名导致下游直接报错。这个问题的本质是没有分层所有复杂性一次性压给模型模型在边界情况下立刻失守。而意图路由解决的就是这个核心矛盾——用分层策略把不确定性问题拆成多个确定性子问题。1.2 Demo 阶段的隐性问题硬编码、单点失效、无兜底Demo 程序最典型的三个问题我在多个项目里都见过一是硬编码路线。Demo 阶段为了演示效果最常见的写法是直接判断关键词“如果用户输入包含‘订单’就走订单查询流程”。这种方案在小范围演示时没问题因为演示数据都是精心准备的。但用户一旦换了说法比如“最近卖得怎么样”关键词匹配立刻失效。我见过有人把关键词列表从 10 个维护到 300 个最后还是漏这就是典型的把简单问题复杂化。二是单点失效。所有请求一股脑进入同一个 LLM 调用模型一抖动整个 Agent 就瘫了。有一次我调试一个 Demo发现只要用户的 prompt 稍微长一点模型就超时。明明只是一个小原型却因为所有的判断、抽取、生成都在一次模型调用里完成导致一个环节出问题就全链失败。三是没有任何降级策略。Demo 可以允许失败生产不行。用户问了一个超出预设范围的问题Demo 会直接返回“我不明白”但生产环境里这可能意味着丢单、客诉、甚至安全事故。工业级的做法是必须有兜底策略再不确定的情况下宁可转人工也不能硬答。这三个问题叠加在一起就构成了一个事实Demo 的架构形态和生产级的架构形态本质上不是量变是质变。下面要讲的三层漏斗架构就是为了在架构层面根本上解决这些问题而设计的。2. 三层漏斗架构拆解从请求到精确执行的完整链路2.1 第一层入口分类层的设计与取舍三层漏斗的“漏斗”含义是每往下一层处理的粒度更细、但流量逐步收窄。第一层我称之为“入口分类层”它解决的核心问题是这条请求是否需要进入 Agent 处理流程。别觉得这层多余。生产环境里Agent 服务承接的流量中有相当一部分是无效请求——测试请求、恶意输入、乱码、用户误触、无关话题。如果这些全部进入语义识别层会白白消耗模型调用成本还会让系统对垃圾输入做出不可预期反应。入口分类层的实现不必依赖大模型。我常用的方案是三层信号并联规则信号长度过滤、正则匹配特殊字符、黑白名单关键词。比如“xcvb123”这种乱码直接拦截。小模型信号用 fastText 或 BERT 这类轻量分类器做二分类有效请求 / 无效请求。实测在 5 万条标注数据上准确率可以到 98% 以上。元数据信号来源渠道App/Web/API、用户等级、是否登录、请求频次等。比如一个用户在 1 秒内发了 10 条相同请求基本可以确定是压测脚本直接截断。这三路信号并联任何一路命中“拦截”就走拒绝通道。这里有个设计要点拦截的路由决策要留痕不能静默丢弃。工业级系统里路由日志是一种重要的数据资产它不仅能帮你做安全审计还能反过来做数据挖掘——你会发现很多用户“乱说话”的背后其实是没有找到入口。第一层出来的流量大约能过滤掉 20%-40% 的垃圾请求。剩下的有效请求进入第二层。2.2 第二层语义意图识别层如何做到快而准第二层是漏斗的核心也是最容易做“重”的一层。它的任务是把有效请求分类到预设的意图类别中比如“订单查询”“商品咨询”“投诉处理”“闲聊”等。这一层的技术选型有两条路线传统分类模型和基于大模型的分类。传统分类模型比如 TextCNN、FastText、Sentence-BERT 分类头的优势在于延迟极低毫秒级、成本几乎为零、行为完全可预测。我最早对它的认知也比较保守总觉得“这年头不用 LLM 做分类是不是太土了”。但有一次压测让我彻底打消了这个念头模型调用做分类单次消耗 800ms 起步成本按 token 计费而 Sentence-BERT 分类200 条请求并发平均延迟不到 30ms成本接近为零。生产环境的流量是 Demo 的千百倍这个差距会直接反映在账单和响应时间上。但传统模型也有天花板对训练集之外的表达容易误分类。所以真正稳妥的方案是“双轨制”第一轨Sentence-BERT 将用户输入 embedding 化和预定义的意图中心向量做余弦相似度取 Top-3 候选。第二轨小模型分类器直接输出意图分布取 Top-3 候选。两轨的结果做加权融合再设定一个置信度阈值我常用的初始值是 0.6。高于阈值直接进入第三层低于阈值但高于某个“模糊区间”比如 0.3-0.6说明用户意图不够清晰先走澄清对话流程低于 0.3说明超出 Agent 能力范围转人工兜底。这里要特别强调意图识别层绝不能把所有决策权交给单个模型。我踩过的最大一个坑是只依赖单个分类模型结果用户在某个特定产品线的说法特别刁钻模型持续给出低置信度但 Top-1 匹配的请求全部被打到错误意图用户白等了几秒然后得到一台回答不对的客服。后来加上双轨 Top-K 候选融合机制这个问题才根治。融合机制的设计不复杂但参数调优要对业务数据有感觉。我的经验是从 0.5 的阈值起步观察一周误报率和漏报率再逐步微调。不必追求一次到位但必须有降级策略兜底。2.3 第三层技能与参数的精确路由到了第三层意图类别已经确定接下来要做的是把请求分派给具体的执行器并完成参数抽取。这一层是“路由精度”的最后一道关卡也是很多工程师容易忽略的环节。举个例子用户说“帮我查一下最近一周上海地区的订单量”意图是“订单查询”没错但具体要查哪个业务域、按什么维度和时间粒度聚合、调用哪个数据源都是这一层该决策的。如果只做意图分类不分派到具体参数下游执行器还是会手足无措。第三层的实现方式我推荐用LLM 做结构化输出 显式工具注册表的组合。核心设计是一个“能力清单”{ skill: order_query, description: 查询订单数据支持按时间、地区、状态过滤, parameters: { start_time: {type: string, required: true}, end_time: {type: string, required: true}, region: {type: string, required: false} } }每次请求进来在第二层已经确定意图的情况下把可用的“能力清单”作为 few-shot 示例喂给模型让模型输出“调用哪个技能 参数 JSON”。这样设计有几个好处第一模型不必从 30 个技能里选只需从 3-5 个候选技能里选准确率大幅提升。我实测把候选列表控制在 Top-3 之后参数抽取准确率从 71% 提升到了 94%。第二参数校验可以程序化。模型输出参数后立马做 JSON Schema 校验。字段缺失、格式错误现场让模型补充而不是让下游 crash 之后再来追责。第三新技能的接入是声明式注册不用改代码。每加一个技能只要注册一份描述路由层自动感知。有人会问第二层用了传统模型第三层又用 LLM是不是多此一举我的回答是两层解决的问题完全不同。第二层做的是“这件事属于哪一类”需要稳定、低成本传统模型完全能胜任。第三层做的是“这一类请求具体要干什么”涉及参数抽取和生成LLM 的泛化能力无可替代。这就是分层架构的本质让强模型做少量关键决策让弱模型做大量重复决策。3. 从 Demo 到生产级的关键改造点3.1 路由决策的确定性从“看心情”到“可解释”Demo 阶段的 Agent 决策本质是“看心情”——LLM 温度高一点同一个问题可能走不同分支。这在演示时没人在意生产环境却是致命伤用户昨天问客服“退款到账时间”系统给了 A 答案今天同样的问题给了 B 答案。信任感直接崩塌。三层漏斗架构的重要优势就是让路由决策变得确定和可解释。具体做法路由决策的全过程写日志来源渠道、规则命中详情、特征向量长度、Top-K 候选及其相似度得分、最终分流节点、处理耗时。每一次路由都有一条完整的“决策链”可追溯。需要解释时第一时间翻日志而不是让模型“回忆”。有一次用户投诉 Agent 处理有误我 2 分钟就从日志里定位到是意图分类置信度低于阈值走了澄清流程用户预期却是直接给出结果。这就是可解释性带来的直接价值。工业环境的 Agent 决策不能是黑盒。没有可解释性的路由就像没有刹车的汽车——演示可以开上路迟早出事。这句话是我做生产级落地后最大的体会。3.2 可观测性的落地实践链路追踪与质量评估可观测性听起来是运维话题但意图路由的可观测性有它自己的特殊性。传统 API 监控看 QPS、延迟、错误率就够了但意图路由还要看路由质量——分流到最终执行器的请求是不是真的被正确执行了。我做一个项目时初期只盯“路由成功率”结果发现数据很好看但用户满意度却在下降。深挖才发现系统把大量请求路由到了“正确”技能但技能内部的参数限制导致了执行失败率很高更隐蔽的问题是“模糊意图”处理不当——用户被反复追问体验极差。后来我建立起三条质量指标线路由层指标各意图类别的流量分布、置信度分布、澄清率、兜底率。执行层指标各技能执行成功率、参数校验通过率、业务结果达成率。反馈闭环用户会话后满意度评价、人工接管率、复购或转化率等业务层指标。这三层指标要联起来看。比如“订单查询”的澄清率异常升高八成是入口分类层把一些无关请求放行了也可能是用户对查询条件表达模糊需要在交互界面加引导。没有这三层指标的联动你可能根本发现不了问题出在漏斗的哪一层。日志和链路追踪工具方面工业界比较成熟的是 OpenTelemetry 标准配合 Grafana 全家桶。我们项目的实时链路数据落 ES聚合指标落 Prometheus每一个请求都有唯一的 trace_id 贯穿三层漏斗查问题相当舒服。3.3 性能与稳定性缓存、并发控制与降级开关生产环境不像 Demo没有“稍等一下再试”的容错空间。意图路由要承受真实流量峰值尤其是促销季、热点事件流量可能瞬间翻 10 倍。我总结的性能保障三板斧缓存是第一个必须做的。意图分类层的 embedding 计算可以缓存同一用户短时间内重复表达相同意图比如“再查一次”“还是刚才那个问题”直接走缓存不需要重新走模型。我在“重复触达”场景下缓存命中率达到 35%等于白送 35% 的性能容量。参数抽取层也可以用语义相似度做缓存但要注意业务上下文可能变化缓存时效一般控制在 5 分钟内。并发控制是第二板斧。意图路由内部涉及多路模型调用需要做并发池管理。我对第三层 LLM 调用用了一个非常保守的策略把并发数压到模型服务稳定承载的 70%剩下的流量排队。很多人担心排队会增加延迟但实测下来排队带来的延迟增量远小于模型超时重试带来的抖动。合理的并发池容量配置是生产部署里最容易被低估的一环。降级开关是第三板斧也是最容易被忽略的。我用一个配置中心统一管理路由行为当模型服务的 P95 延迟超过阈值时自动切换“快速模式”——直接用第二层的传统分类结果选择技能第三层 LLM 参数抽取改成模板参数填充当模型服务彻底不可用时所有请求直接转人工兜底。这套三级降级策略让我们的 Agent 在最恶劣情况下也能保住基本盘而不是全站崩。我见过太多团队在模型供应商故障时全站瘫痪就是没有降级意识的典型结果。4. 工具选型与三层漏斗的落地路径4.1 路由实现的技术选项规则、嵌入、还是大模型技术选型没有银弹每一层都有适合自己的实现方式。我按“成本-性能-可控性”三角做评估给出三条路的适用场景纯规则适合入口分类层的部分场景。比如“长度超过 500 直接转人工”“包含恶意标签直接拦截”。规则的优点是零成本、零延迟、完全可控缺点是覆盖面窄只能处理边界清晰的二进制判断。Embedding 相似度适合意图分类层的主路径。Sentence-BERT 这类模型的优势是不需要为每个意图准备大量标注数据几个示例就能建立一个意图中心。它还有一个规则和关键词方案没有的优势语义泛化。用户说“最近卖得怎么样”和示例句“最近销售情况如何”embedding 相似度会很高这是传统方案做不到的。缺点是对同义但结构差异极大的表达可能失效所以需要双轨融合兜底。LLM 分类/抽取适合参数层和模糊意图处理。它能理解复杂指代、上下文关联、多意图混叠。但代价是慢、贵、不可控。所以我的铁律是能用规则和 embedding 解决的不轻易上模型能用小模型解决的不轻易上大模型。这句话看起来容易落地时很多团队会不自觉地把所有问题丢给 LLM然后被账单和延迟教育。4.2 框架选择LangGraph、Semantic Kernel 还是自研路由层讨论 Agent 框架绕不开 LangGraph 和 Semantic Kernel。我的经验是框架负责执行编排路由决策尽量自研。LangGraph 的设计哲学是“图”节点、边、状态机。用它可以非常优雅地表达三层漏斗的 flow请求先进入分类节点根据分类结果边跳转到意图识别节点再跳到技能执行节点。它内置了状态管理、流式输出、人工介入机制这一点很好。但它的路由逻辑本质是静态图想动态调整分流策略必须改代码重新发布这在快速迭代的生产环境里很痛苦。Semantic Kernel 的定位是“轻量编排 Planner”它的 Planner 能根据用户目标自动生成计划。听起来很美但生产环境的 planner 不稳定计划一旦生成的策略和执行器不匹配排错极难。我个人的建议是如果你只需要做规则明确的 AgentSemantic Kernel 可以做但像意图路由这种要精细控制决策链的场景不要把核心放在框架的自动规划上。我推荐的自研方案是用框架处理“执行态”用配置中心处理“路由态”。路由规则、阈值、意图中心向量、技能注册描述全部放在配置中心代码只负责“读配置→走流程”。这样生产的调参不需要发版运营人员改配置就能调整系统行为。有一次我们想调整某意图的澄清阈值产品经理直接在后台配置改完5 分钟内就生效了运营效率明显提升。4.3 从 Demo 迁移到底层架构的改造清单如果你已经有一个 Demo Agent想迁移到三层漏斗架构我总结了一个可以直接对照的改造清单流量盘点先统计你的真实或预期流量类型哪些是核心意图、哪些是边界输入、哪些是纯垃圾。没有这个盘点后面三层设计都是空中楼阁。意图清单把业务方预期的意图列成表格每个意图带 5-10 个种子问题。这是第二层模型的训练集基座。能力注册把所有执行能力技能/工具按标准格式注册成声明式清单。这一步最枯燥但最重要后续所有路由都依赖它。先切入口层把第一层入口分类先上线配好拦截规则和日志。这一步能立刻过滤无效流量降低后两层的压力。再切意图层用小模型 embedding 双轨方案搭建意图分类跑一段时间积累真实路由日志人工抽检分类质量。最后切参数层确认前两层稳定后接入 LLM 参数抽取配上 JSON Schema 校验每个技能逐一点验。配置降级开关与告警不管你多信模型先把降级开关和告警配上。我认为这一条是不能妥协的底线——宁可降级也不裸奔是我做生产系统最基本的职业素养。这个顺序的核心是先让漏斗通起来再让漏斗准起来最后让漏斗细起来。每一层改造完都要有回归数据和监控告警才能放心推进下一步。5. 常见问题与排查技巧实录5.1 路由误判率居高不下的原因与调优路径最常见的误判有两种一种是用户输入被分到了完全错误的意图另一种是模糊输入被强行归入某个意图而不是触发澄清。前者通常是因为种子示例太少或者意图之间边界不清晰后者往往是因为置信度阈值设得太低。针对意图重叠问题我有一个方法论意图之间要有“互斥样例”。比如“退款咨询”和“投诉建议”在字面上高度相关就必须准备一批“这两个意图最容易混淆的样本”放在训练集里让模型学出区分边界。一个场景下我加了 12 条互斥样板误判率直接掉了 6 个百分点。调阈值的时候不能只看离线指标。我试过把离线测试准确率从 94% 调到 97%但上线后澄清率暴增用户体验变差。原因很简单离线测试集里所有样本都是真实意图而线上流量有大量“半真实意图”——用户自己也说不清楚想要什么。这类请求正确地走澄清流程比硬着头皮猜一个结果更好。所以阈值的调整一定要结合线上的“澄清率”和“用户后续是否成功解决问题”一起看不能为了调准确率就牺牲模糊度容忍。5.2 模型调用失败与超时降级设计能救命的场景生产环境我见过两次比较典型的模型服务故障。一次是模型供应商侧大面积超时所有调用 P95 从 300ms 飙到 8s如果不去管它整个 Agent 服务会跟着堆积。另一次是模型侧响应内容格式异常返回了非法 JSON导致下游解析直接崩溃。应对前者的方案是两级超时控制第一级是单次调用的超时我用的 3s第二级是整个路由链路的超时5s。超时后立刻触发降级分支跳过硬解析用模板答案回复同时通知用户“当前正在缓存中查找”。虽然体验打折但至少不会让用户转圈等 10 秒。应对后者的方案是输出校验 重试机制。模型输出 JSON 后先做 Schema 校验不过则自动重试一次带上错误信息提示模型修正。如果第二次还是不行就走模板参数兜底而不是报错。整个机制就像一个自动修复管道让模型偶尔“犯迷糊”不至于影响到用户。5.3 路由日志不完整导致的排障难题做生产级工程我最大的一个教训就是日志不完整等于没有日志。有一次排查用户投诉“Agent 回答错误”结果路由日志里只写了“意图分类成功”却没有任何关于候选序列和置信度的记录也看不到模型调用日志。最后只能靠瞎猜耗时两天发现是参数抽取时把时间范围理解错了。从那以后我强制要求在路由层每一层都打全量日志原始请求、预处理后文本、特征向量哈希、Top-K 候选分数、最终决策、耗时明细、模型输入输出、参数校验结果。这会让日志量翻倍但换来的是“每次排障都是可视化的”效率提升的幅度远超日志存储成本。我曾经整理了一套标准路由日志模板包含大约 20 个结构化字段。团队新成员接手时靠日志模板上手能快速定位问题是规则命中不对、模型延迟高还是下游执行器脏数据比之前到处问人高效得多。5.4 测试与回归三层路由的效果如何持续保障三层漏斗上线之后最大的风险是“改一处动全身”。比如为了提升某个意图的识别准确率你调整了种子示例结果另一个意图分布被带偏。所以我后来建立了一套“路由回归测试集”包含核心意图的正例、边界情况的模糊例、已知的垃圾输入、历史误判样本每次调整后先跑一遍回归。这套测试集的重要性可以在一次真实事故里体现运营改了一个关键词拦截规则第二天客服上线后发现大量“我要投诉物流”的请求被拦截了。回滚排查才发现新关键词规则和“物流”的近义词撞了。从那之后我的原则是任何路由规则调整必须过回归任何模型调参必须过回归任何配置变更必须过回归。这不是方法论层面的建议是从事故里总结出来的活教训。另外回归测试的断言不要只盯着“分类对不对”还要看“分流后有没有走正确执行器”。我曾经遇到一个情况分类对了但第三层把参数抽错了导致执行器报错而测试只验证到分类层就停了。所以三层漏斗的回归每一层都要有自己的断言指标这是保证端到端质量的关键。6. 一个可直接参考的落地案例与扩展方向6.1 案例拆解电商客服 Agent 的三层漏斗怎么搭把这个架构落到一个具象项目里是最能让人理解的部分。我拆一个电商客服场景业务背景某电商平台要做一个售前售后智能客服 Agent用户输入可能是“怎么退款”“物流到哪了”“有没有优惠码”也可能只是“在吗”。第一层入口分类先过滤“在吗”“你好”“测试”这种无效话术规则命中和长度过短的输入长度阈值。大约过滤掉 25% 流量。第二层意图分类剩余流量进入意图识别主要类别有“售前咨询”“订单查询”“售后问题”“优惠活动”“其他业务”。Sentence-BERT embedding 与类别中心向量算相似度配合分类器双轨融合。最高置信度超过 0.6 的直接分流0.3-0.6 的触发澄清问题如“您是想咨询商品、还是查询订单呢”。第三层参数抽取“订单查询”类请求进入数据查询技能LLM 从用户话里抽取订单号、用户 ID、时间范围。如果没找到订单号就反问用户提供订单号抽到非法日期就用默认最近一周代替不让流程中断。这套系统上线后人工接管的会话量从总流量的 38% 降到 11%会话一次性解决率从 46% 升到 79%用户明显感觉到“机器人真的听懂了我在说什么”。数据带来的正向反馈又推动了业务方更愿意把复杂场景交进来形成一个正循环。6.2 扩展方向多 Agent 协作、记忆分层与长上下文路由三层漏斗并不只是单 Agent 内部的路由方案它还可以作为更大系统的底座。举例来说多 Agent 协作时每个 Agent 的能力本身就是一个“技能”意图路由变得更加重要——用户的一句话可能要被分发到多个 Agent 协作完成。我比较关注的一个方向是记忆分层与路由的结合。用户的短期上下文、长期偏好、持久知识积累每一层应该在哪里读取、放多大权重这也是路由决策的一部分。比如一个老用户说“还按上次的标准来”意图识别很容易但要“按上次的标准”就要去取长期记忆。这个需求已经把路由从“选择技能”扩展到了“选择记忆体 技能”的复合决策。长上下文场景是另一个有意思的扩展用户上传了一份长文档问“第三部分的主要结论是什么”。这种场景意图路由层需要决定是全文摘要、还是局部检索、还是先咨询澄清“第三部分指的是哪个章节”。这里的路由已经不只是漏斗更像一个决策引擎。我自己的实验里把三层漏斗的能力抽象成一套“策略容器”每个策略可以嵌套组合扩展性比固定的三层结构更灵活。这些方向目前还属于进阶探索但底层的分层思维始终一致把复杂决策拆小、分层、保持每层的独立性与可观测性在此基础上再考虑组合与扩展。这是我把这套架构从 Demo 一步步推向生产级的过程中觉得最有价值、也最想分享出去的经验。做生产级意图路由这几年我个人的体会是架构本身的价值远比模型的选择更重要。很多人以为 Agent 强不强取决于模型但真正决定体验耐受度的是系统在模型“犯迷糊”的时候还能不能稳定运行、可解释、可降级、可迅速定位问题。三层漏斗不是一个多高深的理论它是一个非常朴素的工程常识——把不确定性分段消化把决策拆细然后用观测数据持续调优。希望这篇文章里那些踩坑记录、参数细节和配置思路能帮你在自己的 Agent 项目里避开弯路少熬夜排障。