做工业级Agent最容易被低估的不是模型能力而是意图识别。模型再强如果搞不清用户到底想干什么、这个请求该不该执行、执行到什么程度Agent就只是一个会说话但没脑子的执行器而且是个敢乱动的执行器。我自己的项目里最早用单模型做意图识别上线第一周就出了三个线上问题把查询接口的请求误判成删除动作、多轮对话中把用户补充的信息当成新任务、还有一次被恶意文本干扰导致意图输出完全跑偏。后面痛定思痛把意图识别整个重构成了分层漏斗的结构才算是把这块稳住了。这篇文章想把整套工业级Agent意图识别分层漏斗的设计思路、分层逻辑、技术选型、落地参数和真实踩坑经验完整写出来。适合正在做Agent应用开发、对话系统、智能客服、AI中控层的开发者和架构师参考。不管你用的是LangChain、Dify、CrewAI还是自研框架这个漏斗的核心思路都是通用的——先解决要不要接、接去哪、能不能干三个问题再谈怎么干得好。1. 为什么单模型的意图识别撑不起工业级Agent1.1 单模型方案背后的三座大山很多从demo起步的团队一开始都会选择所有请求都丢给大模型让模型直接判断用户意图。Demo阶段没毛病数据量小、并发低、用户都是自己人模型偶尔犯傻你还能忍。但一旦放到生产环境单模型意图识别会同时撞上三座大山。第一是延迟。全量请求过LLM推理单次几百毫秒到几秒不等高峰期用户交互体验直接崩掉。意图识别本身是一个浅层理解任务它不应该消耗模型全部的理解能力更不该让每个请求都走一遍完整推理。第二是成本。所有请求都调用最强模型做意图分类意味着你为大量查一下、这是什么之类的简单请求支付了最贵的token费用。账单会教你做人。第三是失控。模型输出天然是概率性的没有硬约束。你让它输出一个意图标签它在边界场景可能给出完全离谱的答案而且你很难在链路中拦截这种离谱输出——因为在它进入执行链路之前没有一道闸门能拦住它。这三座大山是结构性的不是调prompt能解决的。你需要从架构层面把意图识别从一个大模型做所有事改造成多个层级协同、层层收敛的管道。1.2 漏斗的核心逻辑把复杂度拆到各层消化分层漏斗的思路其实不复杂。类比一下机场安检所有乘客先过第一道闸机完成身份和基础违禁品初筛有疑点的行李再进X光机细检高危品才会落到人工开箱检查。如果把所有安检动作都放到每一个人身上机场早就瘫痪了。意图识别也一样。在设计漏斗时我把处理过程分层为流量前置-领域粗判-细粒度识别-上下文与参数解析-安全与授权决策。每一层只干一件事输入是上一层的输出输出是结构化、带置信度和风险标记的决策结果。大量简单请求在前两层就被直接命中并分流只有少数复杂、高危、不确定的请求才会走到后几层由更重的手段来处理。这个结构带来的直接好处有三个低层用便宜、快速的手段拦截大多数简单流量把昂贵的大模型推理留给真正需要它的请求每一层的输出都独立可观测线上定位问题的时候你能看到问题到底出在漏斗的哪一级安全约束可以分布在多个层级中而不是指望模型自己具备安全判断能力。2. 工业级意图识别分层漏斗的分层设计与职责划分2.1 五层结构总览与统一结果协议整个漏斗我按L0到L4编号每一层职能都泾渭分明。先看总览表层级职责定位典型延迟预算核心技术手段L0流量与安全前置判断请求要不要进入Agent体系5ms以内规则、词表、频控、长度限制、注入特征匹配L1领域粗分类判断请求属于哪个大业务方向10-30ms文本embedding、轻量分类器、路由表L2细粒度意图识别输出具体意图标签与置信度200-500msLLMLLM结构化输出、微调意图模型、意图语义库召回L3上下文与参数解析补全槽位、约束、执行条件300-600msLLM槽位解析、会话记忆注入、工具Schema约束L4安全与授权决策判断能否执行、执行范围、是否需要二次确认10-50ms能力映射表、权限校验、风险等级判定每一层的输出都必须遵循同一个协议这是整个漏斗可落地的根基。我在工程里定义了AGENT_INTENT_FRAGMENT结构包含trace_id全链路追踪ID、layer当前层编号、intent意图候选、confidence置信度、reason判断依据、risk_level风险等级、next下一跳动作。所有层都按这个协议输出线上排查时一条链路串下来哪层做了什么决策一目了然。{ trace_id: 7f8a1c2e-4b3d-4a1e-9f2a-6b3c4d5e6f7a, layer: L2, intent: sales_order.cancel, confidence: 0.82, reason: 用户明确表达要取消订单包含订单号3265, risk_level: high, next: L3 }2.2 L0流量与安全前置层先决定这单要不要接L0是整个漏斗的第一道闸门它处理的不是用户想干什么而是这单值不值得接。大量无意义流量、攻击性输入、恶意指令、异常频率请求都应该在这一层被拦掉。这层我坚持只用规则和确定性手段不引入模型判断因为这些都是高确定性的判断题规则能完美解决没必要动用模型更没必要为它付出延迟和成本。具体拦截项可以包括空请求和纯符号请求、超长文本截断、明显的外部指令注入特征比如忽略之前的指令这类模式、频率异常暴增的请求、来自黑名单来源的流量。注意这一层要保守再保守只拦零容忍的内容。因为L0的误杀直接意味着用户根本见不到Agent体验损失不可逆。我在项目里给L0定的原则是宁可放过、不可错杀放过之后后面的层还能补救但错杀了用户就真的流失了。有个细节值得单独讲L0拦截不是简单的返回错误给用户而是要走一个降级路径。比如被限频的用户系统不是冷冰冰地拒绝而是降级为排队处理或者稍后重试的话术被识别为疑似注入的文本也不是直接拒绝而是标记为高风险后转发给L2做二次确认同时强制不启用工具调用能力。这个设计让L0从粗暴的墙变成了灵活的道路管制。2.3 L1领域粗分类层判断用户从哪个口进来过了L0的请求进入L1领域粗分类。这一层的目标是回答这个请求属于哪个大方向而不是精细的意图。举个例子在客服场景里L1只需要区分这单是售前咨询、售后问题、投诉反馈、闲聊寒暄还是知识问答具体的退货换货开发票这些细意图不在这一层处理。L1之所以独立于L2存在是因为它的技术选型可以非常轻。我用的是文本embedding加轻量分类器或者直接用一个fastText级别的模型延迟压在20毫秒以内。即使准确率只有90%到95%也完全够用因为它的职责是缩小范围而不是精确定位后面还有L2做细粒度兜底。但这里有一个关键指标必须盯死漏判率要低宁可把请求分错领域也不能把请求卡在这一层。分错域L2还能用候选意图列表来纠正卡在中间用户请求就消失了。设计L1时还有一个容易被忽视的点要输出不确定分支。很多工程团队把L1做成硬分类器非A即B这其实违反漏斗设计的初衷。我在L1里专门设置了domain_conf_low标记当置信度低于0.6时请求会跳过L2的领域限定直接走全量意图匹配模式。这种做法看似多花了L2的成本但有效避免了领域误判导致的意图识别失真性价比非常高。2.4 L2细粒度意图识别层确定用户到底想干什么L2是整个漏斗的核心也是Model能力真正发挥价值的地方。它的任务是在L1确定的领域范围内输出具体的意图标签、候选排序和置信度。比如在售后问题这个域内识别出用户是想查物流、申请退款、修改地址还是投诉人工客服。技术实现上现阶段最优的选择是LLM结构化输出。我会在prompt里明确给出候选意图清单、每个意图对应的语义说明、few-shot示例、输出Schema要求模型严格按照JSON格式返回。核心是候选意图列表一定要穷举且互斥。如果两个意图的语义边界模糊模型就会在这两个意图之间随机横跳线上看起来就是同样的用户话术今天识别成A明天识别成B非常影响体验。这层我踩过最大的坑是让模型强行输出唯一意图。后来改成输出Top3候选意图置信度置信度不足标记之后整个漏斗的稳定性大幅提升。因为工业场景下正确率不可能做到100%与其让模型硬猜一个答案不如让它诚实地告诉你我不确定。当Top1置信度低于0.75时漏斗会直接触发澄清策略——反问用户您是想查物流还是申请退款而不是自作主张去执行某一个操作。这比模型硬猜然后执行错动作要安全得多用户也不会觉得Agent很蠢。2.5 L3上下文与参数解析层补齐槽位和执行条件意图识别出来了但识别意图和可执行之间还隔着一条河。用户说取消那个订单意图清晰是取消订单但取消哪个订单订单号是多少这个订单当前是否在可取消状态这就是L3的职责把意图实例化补全执行所需的所有参数和约束条件。L3的工作方式不是让大模型自由发挥而是受工具Schema严格约束。每个意图预先定义好它需要的参数列表比如cancel_order需要order_idchange_address需要new_address、order_id模型在解析时只能从工具Schema定义的字段里取数据不能凭空捏造参数。同时L3要把多轮对话的上下文和用户画像记忆注入进来用户上一轮报过的订单号这轮说就刚才那个L3必须能从会话状态中取出来。这里也顺带看了一眼社区里讨论的agent skills话题实际上意图L3解析的结果就是在选择要激活哪一项技能——技能激活前的一些准备工作越明确后面执行越不会跑偏。槽位不全的时候不是直接报错而是输出参数缺失清单触发Agent向用户发起追问。例如请提供您的订单号而不是说系统错误请重试。这层做得好不好直接决定Agent给人的感觉是聪明靠谱的助手还是一个bug很多的玩具。2.6 L4执行安全与授权决策层决定能不能干、干到什么程度最后一层L4不做语义理解做的是权限与影响面控制。这层的输入是L2的意图、L3的参数输出是允许执行拒绝执行需要二次确认三类决策之一同时附上风险级别。工程上我维护了一张能力映射表每个意图都对应到具体的Agent能力或工具调用链路并标记影响等级。影响等级高的操作比如删数据、发消息、转账、覆盖文件即便L2的置信度高达0.9也必须走二次确认影响等级低的操作比如查天气、查日历L2置信度0.7就可以直接放行。这里的关键是不是模型判断操作风险而是规则表来定风险因为风险等级是一个相对稳定的业务属性不该每次请求都让模型重新推理一遍。L4还承担了权限校验和沙箱决策的职责。用户在当前身份下是否有权限执行这个动作、这个动作是否只能对授权范围内的数据生效、执行过程中是否要启用更严格的沙箱隔离都在这一层决定。我之前在项目里遇到过一个特殊情况用户意图识别得完全正确参数也提取正确但他在访客模式下试图执行一个管理员才能执行的操作。如果L4不做授权校验这次调用就会直接越权。所以L4对于工业级Agent来说不是可选项是必选项。3. 技术选型与主流Agent框架的配合方式3.1 规则、轻模型与LLM的混合选型策略整个漏斗的选型逻辑不是哪里都用最贵的模型而是给每个层级匹配最合适的工具。L0必须用规则和确定性手段这是为了保证安全底线不受概率波动影响L1用轻量模型追求低延迟高吞吐L2和L3才用LLM承担真正的自然语言理解任务L4又回到规则和映射表保证决策稳定、可审计。有个对比值得单独列出来方案优势劣势适合层级纯规则/正则零成本、零延迟、确定性泛化差、维护成本高L0、L4辅助轻量分类模型延迟低、成本低、可批量训练语义理解上限低L1Embedding向量召回可以快速更新意图库依赖向量质量边界意图易混L1辅助、L2辅助LLM结构化输出语义理解强、泛化好延迟高、成本高、输出不稳定L2、L3映射表策略引擎稳定、可审计、易调整需要人工维护L4这个组合的本质是把预算花在刀刃上90%的流量在L0和L1就被消耗掉只有真正复杂的10%会花LLM的钱。3.2 漏斗与LangChain、Dify、CrewAI的对接方式很多人问意图识别漏斗应该放在Agent框架内部还是外部。我的建议始终是放在框架入口之前作为独立的前置网关。LangChain、Dify、CrewAI负责的是拿到意图之后怎么编排和执行而漏斗回答的是该不该进入执行链路、进入哪条链路。如果把意图识别放在框架内部的Agent循环里它会被Controller吞掉变成整个编排逻辑的一部分最终结果是意图识别和执行的边界模糊出了问题很难定位。具体对接上LangChain可以在入口处自定义一个Router回调根据漏斗返回的intent字段决定加载哪条ChainDify可以在工作流的最前面接入一个HTTP外部节点调用漏斗接口输出结果作为后续流程的输入变量CrewAI则可以在Crew运行的开始阶段先跑一次漏斗预分类根据结果创建不同的Task列表。这些做法的本质都一样漏斗是独立的框架是插件式的。另外有人问基于Rust实现的高性能Agent怎么集成其实更简单。我见过不少团队用Rust写Agent核心意图识别漏斗如果做成独立HTTP服务Rust侧只需要在入口发一次请求即可而且L0和L1这种轻量层可以用Rust自己实现把L2/L3的LLM调用留在Python服务里两边通过统一协议通信性能基本不损失。3.3 意图识别、技能选择与记忆的关系意图识别在现在社区讨论里已经不只是一个分类任务了它和skills、记忆、工具选择紧密耦合。一个正确的意图判断决定了Agent接下来激活哪些技能而技能的执行结果又会写回记忆反过来影响下一轮的意图理解。举例用户让Agent画一张柱状图L2识别为数据可视化L3解析出数据范围和图表类型然后Agent才会调用画图工具对应的skill。如果意图识别错了后面工具调对了也是南辕北辙。在多Agent协作的场景下A2A协议相关讨论里经常提到意图识别往往是第一个关卡外部Agent发来的请求先要判断意图和信任级别再决定是否与之协作。所以把意图识别作为独立的、分层的服务来做长远看是在为Agent生态的复杂度提前铺路。4. 从设计到落地的三个关键实操步骤4.1 第一步定义统一的层间协议落地漏斗的第一件事不是写代码而是先把层间数据结构定死。俯视整个漏斗每一层都是输入一段文本输出一个结构化决策。如果每一层各写各的数据结构后续做可观测性和调试就是灾难。我用的协议就是前面提到的AGENT_INTENT_FRAGMENT所有层共用层与层之间通过一个上下文对象传递里面除了结构化的意图结果还保留原始输入快照、会话状态引用、知识库召回结果等元数据方便最后一层统一做审计日志。这个协议的威力在调试时才会真正体现。有一次线上用户反馈Agent答非所问我把trace_id一串发现L2输出明明是complaint意图但L3因为会话状态取不到当前订单参数直接放弃了参数解析跳到了一个兜底的generic_response。问题一分钟定位到而不是翻半天日志瞎猜。4.2 第二步给每层做阈值、超时与降级配置阈值设计是分层的核心工程之一。我的经验是不要凭感觉定阈值要基于验证集和线上采样数据画PR曲线来找平衡点。比如L2层我们收集了过去两周的1万条线上请求日志人工标注真实意图然后跑模型预测画出准确率和召回率随置信度阈值变化的曲线选择召回率不低于0.95且误判次数最少的点作为阈值。下面是我在项目中的一套参考配置可以直接抄去改改用层级关键配置项参考值说明L0拦截范围只拦零容忍项频率异常、注入特征、黑名单L0超时5ms超过直接放行绝不卡住请求L1分类置信度阈值0.6低于则跳过领域限定走全量L2Top1意图置信度0.75低于则触发澄清策略L2高风险意图置信度0.9高风险动作必须有更高置信度L2超时500ms超时则降级为不确定走澄清L3参数完整度100%缺参数只追问不猜测执行L4风险等级high/medium/low高影响操作强制二次确认注意超时和降级策略同样重要。线上系统最怕的不是模型不准而是模型卡住。我给每一层都设立了超时时间超时之后统一走不确定分支。这个分支会引导用户做澄清而不是放行一个未经确认的动作。任何一个动作宁可让用户多说一句话也不要让Agent多做一件不确认的事。这在工业级Agent里是一条铁律。4.3 第三步建立回流闭环让漏斗越用越准漏斗设计完成后最容易被低估、但长期来看最重要的就是反馈回流。意图识别不是一个一次性的模型任务它需要持续用线上bad case去迭代。我的做法是每天自动从线上捞取漏斗决策失败的样本包括L2置信度低但用户后续行为证明理解正确的、L2置信度高但执行阶段Clarify率高的、用户明确表示我不是这个意思的。这些样本进入一个BadCase池每周抽一批做人工标注标注结果回流到L2的few-shot示例、L1的分类训练集、以及意图语义库的向量召回索引里。同时要建立意图评测集不要只看线上准确率这种模糊指标。评测集合包含固定回归集和每周新增的bad case集每次改动模型、调整prompt、修改阈值都要先用评测集跑一遍冒烟测试。我团队之前有一次改了L2的prompt自测没问题结果评测集上一跑发现退款和退货两个意图的混淆率上升了15%。如果没有评测集这个问题大概率要等用户骂了才被发现。5. 常见问题与排查经验实录5.1 高频问题速查表长期维护这个漏斗我把常见的线上问题整理成了排查表遇到问题先按表操作能省下大量时间现象可能的根因排查方式解决方案大量请求没走到Agent层L0误杀查看L0拦截日志与拦截规则命中详情立即收窄L0规则只保留零容忍项用户反复表达同一需求但Agent答非所问L2置信度低触发澄清太频繁观测L2置信度分布抽样bad case补充few-shot示例或微调模型每天固定时段延迟飙高L2超时导致大量降级查看LLM供应商侧延迟和超时日志提前扩容、设置备用模型通道意图识别正确但执行出错L3参数解析缺失检查工具Schema和解析结果补参数规则加参数缺失追问用户被重复要求确认L4二次确认过于激进查看L4风险等级标注与实际执行成功率调低中风险动作的确认频率同一句请求表现不稳定L2模型输出抖动查看置信度变化和温度参数降低温度增加候选意图约束5.2 两个让我印象深刻的线上事故复盘第一个事故和置信度阈值有关。用户说帮我把主页那个报表删掉重新拉一份L2识别出核心意图是生成报表但模型在Top3候选里混了一个删除报表的意图Top1置信度只有0.78刚好过了默认放行阈值。Agent在L3解析时发现用户提到删掉报表就把它当成了删除操作来执行。后面加了两条规则高风险动作的置信度阈值提高到0.9第四层L4在遇到删除/覆盖/发送这类动作时强制走二次确认。这两条规则上线后再没出现过同类问题。第二个事故和L1领域误判相关。用户问你们这个平台能干嘛L1把它分到了闲聊域L2在闲聊域里找不到合适的意图最后直接走了兜底回答我是一个智能助手。用户觉得Agent听不懂人话一连给了三个差评。后来我们调整策略所有被L1判定为闲聊的请求如果词法上包含干嘛功能这类疑问词就强制跳转到知识库问答域。这种规则覆盖模型判断的动作是漏斗架构里特别重要的一种设计——规则不一定能解决所有问题但在关键场景下必须能兜底。5.3 长期维护避坑清单最后总结几条长期维护漏斗的心得都是踩过坑才明白的。第一不要在漏斗后面再挂另一套判断逻辑。很多人为了让某些特殊场景通过绕过漏斗直接加了旁路规则结果旁路越加越多最终旁路的请求量超过漏斗本身整个分层体系形同虚设。任何策略改动都要回到漏斗配置里统一管理保证一条请求只走一条可审计的链路。第二原始输入快照必须保留。每一层处理完后都要把原始输入、层间中间结果、最终决策一起落日志。没有原始快照bad case分析就只能靠猜。我们一开始没做这一步后面补日志方案花了两周期间很多问题都没法定位。第三阈值和策略配置要外置不要硬编码。我把所有阈值、规则、映射表都放到配置中心可以热更新。线上意图分布是会变化的比如每年大促期间优惠券查询意图突然暴增如果没有外置配置你就要改代码重新上线黄花菜都凉了。第四关注漏斗流失率而不是单点准确率。统计每一层从流入到交给下一层的比例你会发现大多数问题在某层分流失真而不是单层模型不准。流失率才是漏斗整体的晴雨表。结尾的个人体会做这个分层漏斗我最大的体会是工业级Agent意图识别的目标从来不是把某个模型的准确率刷到99%而是把不确定性和风险均匀地分配到每一层去消化。准确率这个单点指标会骗人漏斗整体的流失率、误杀率、澄清率才是更真实的度量。最后分享一个实战经验漏斗上线之后请留出至少两周时间只干一件事——把线上bad case的trace串起来逐条分析每一层的决策日志。你会发现意图识别的问题根源往往不在模型本身而在层与层之间的边界和数据流上。想通了这一点你调模型的次数会少一半漏斗的稳定性会上一个台阶。这个架构后续还可以往多模态输入、多Agent协作信任机制的方向扩展但核心的分层决策骨架不会变。