企业官网建设流程全解析

工业级Agent意图识别分层漏斗

上个月我把公司那条线上意图识别服务拆了重做，原因很简单：直接用大模型做意图识别，Demo里效果惊艳，一上生产就原形毕露——延迟不稳定、token成本按天翻倍、半夜还会来几个莫名其妙的误判。后来我在内部把整个方案换成了"分层漏斗"这套思路，把Agent的意图识别从一个黑盒大模型调用，拆成了规则缓存、召回匹配、模型判别、兜底回流四个层级，线上稳定性和成本效率都有了质的改善。这篇把整个设计思路、实现细节和踩过的坑完整记录下来，希望给正在做Agent意图识别、或者准备把LLM能力往生产环境推的朋友一些参考。

这套方案的核心价值在于：意图识别不是"选一个最强模型把活全干了"，而是"让每一层只做自己最擅长的事，模糊地带逐级下放，最后再用低成本兜底把漏网之鱼收回来"。听起来像是架构层面的老生常谈，但真正落地时，你会发现每一层的边界划分、阈值设定、数据回流都藏着大量细节。下面我从为什么必须拆分开始，逐层拆解漏斗的设计。

1. 为什么单一的意图识别方案撑不住生产环境

1.1 一次真实的线上事故：模型漂移与成本失控

我们的业务是一个ToB的Agent服务，用户通过自然语言向Agent发指令，Agent需要判断指令的意图，再决定调用哪个工具、走哪条流程。第一版方案很简单粗暴：把用户输入拼上历史会话，直接丢给GPT-4级别的通用大模型，让它在预设的二十多个意图枚举值里选一个，同时输出对应的置信度。联调和内测期间效果确实能到95%以上的准确率，但一上生产，问题接踵而至。

首先是延迟波动。大模型推理存在排队效应，高峰期P99延迟能从800毫秒飙到3.5秒。对Agent来说，用户发完消息后如果三秒没反应，后续的交互节奏就全乱了。其次是成本，我们每天的请求量在百万级，一个基于图片的token计费方案算下来，每个月仅意图识别这一项就是六位数起步。最要命的是漂移问题——用户表达习惯随时间变化，运营又不断往Agent里加新功能，意图列表其实是动态的，但模型是静态的，于是总有一部分请求被硬生生归到"最相似"的错误类别里，还自信地给出98%的置信度。

当时我的结论是：单一大模型不适合承载工业级意图识别这个"高频、低延迟、强稳定性"的场景。这个判断和模型效果无关，纯粹是工程问题——你不能用一门重炮解决所有战术任务，该用手枪的时候用手枪，该用狙击枪的时候用狙击枪，该让观察员先判断敌情的时候，就别急着开火。

1.2 单模型方案的三个死穴

我把自己踩过的坑归纳成三个维度的死穴，这也是后来设计分层漏斗时反复对照的原始问题清单。

成本不可控。如果每个请求都走大模型，哪怕只是PassThrough一次路由判断，也要付首token和输出token的全额。更隐蔽的是，大模型输出不稳定导致结果重试率很高，一次判断失败，你的客户系统可能会自动重发，成本直接翻倍。我们在高峰期统计过，带重试逻辑的意图判断请求占总请求的17%，光重试费用就占了意图识别总成本的近三成。

可观测性和可调试性太差。大模型给出的意图判断往往缺乏可解释的推理链路，出了问题你没法像看代码一样逐步定位。曾经有个客户反馈"你们的Agent把我今天要做的事理解成另一个部门的任务了"，我翻日志查了半小时，只能看到Prompt里有用户的整段描述和模型返回的结果，中间到底哪句话权重更高、哪个上下文信息被忽略了，完全是黑盒。黑盒问题不解决，你就永远只能靠运气调Prompt。

置信度失真。即便你在Prompt里要求模型输出confidence，这个置信度也是校准不准确的。大型模型在自身知识边界内给出高置信度的概率本来就高，真正遇到OOD（Out-of-Distribution）输入时，它的高置信度恰恰是最危险的——因为它会用最熟悉的知识来强行适配陌生输入。生产系统如果只凭模型自信程度做护栏，必然崩溃。

1.3 工业级意图识别的真实约束条件

前面那三个死穴本质上揭示了一个现实：工业级意图识别要同时满足四个互相矛盾的约束——准确率要够高、延迟要够低、成本要可控、决策要可解释。

这四个目标在单模型架构下几乎不可能同时达成。你上大模型就牺牲成本和延迟，上小模型就牺牲准确率，上规则系统就牺牲覆盖率。所以我们必须换一个思路：把目标拆解到不同粒度的处理层，让每一层只优化一部分约束，最后通过漏斗结构把整体指标拉回可接受范围。

我的经验是做这个决策时要敢于打破"技术洁癖"。很多算法同学会觉得意图识别就该是一个端到端模型，分层了就不"先进"了。但生产系统要的是组合收益，不是单一模型指标。分层漏斗本质上是用架构手段做"算力分层分治"，这在传统服务端架构里非常常见，只是到了LLM时代被很多团队忽略了。

2. 意图识别分层漏斗的整体设计与核心逻辑

2.1 先理解漏斗的运作机制：层层放行，而非层层拦截

我见过很多文章把漏斗理解成"多级过滤器"，每一层都用严格的方式拒绝一批请求，最后剩下最难的就交给大模型。这个理解是错的。工业级漏斗的正确语义是"层层放行，模糊下放"，每一层只拦截自己明确能解决的部分，自己不确定的部分直接放给下一层，而不是在每层设置一个"拒绝"动作。

举个例子，第一层规则引擎是精确匹配"查余额""转账""支付账单"这类高频意图，它只输出两种结果：命中或跳过。命中就直接返回，跳过则往下一层送。到了召回层同样如此，它会对用户输入算相似度、做候选排序，对Top1候选的相似度超过0.92的请求直接给结果，低于这个阈值的全部放行给大模型层。这样每一层都在把"明确"的东西提前消化，模糊的、复杂的、边界的情况最终汇聚到大模型层做综合判断，而不是每一层都砍一刀。

这种设计的核心收益在于响应分布：80%的常见请求在两层内结束，延迟在50毫秒以内，成本几乎为零；剩下20%才需要模型或大模型兜底。真正落到大模型层的其实只有约5%-10%的流量，但这个比例可控、可预算，成本曲线就变得平滑了。

2.2 四层漏斗的总体架构与数据流转

我实现的这套漏斗一共四层：

数据在层与层之间流转时，每一层必须明确输出三类信息：命中或未命中、置信度或相似度分数、供下一层使用的上下文摘要。这个上下文摘要很关键——因为到了L3大模型层，你不能再丢整段原始输入，而是要把对话历史、候选意图、用户的近期操作路径压缩成一份精炼的上下文，让大模型做"仲裁者"，而不是做"第一判断人"。

整个漏斗还有一个配套的"决策横向旁路"，就是每层都会写入统一的Trace日志，包含输入、命中结果、分数、跳转到下一层的原因、下一层的最终决策。这样任何一个请求的意图识别链路都是可以回放、可以审计的，这更是后面做评测集和Badcase回流的基础。

2.3 为什么要用"大模型后置"而不是"大模型前置"

有些人会觉得既然大模型效果最好，那就先让大模型判断，判断不了再降级到规则。我强烈反对这种顺序，原因有三个。

第一是成本和质量的性价比错位。大模型判断大多数高频简单请求是一种浪费，如果你先调大模型再走规则，那么你为那80%的简单请求付了大模型的费用，这完全没有任何工程美感。第二是错误传染路径。大模型如果在前置阶段产生错误判断，后续规则和查询阶段往往会沿着错误方向做搜寻，导致最终结果的错误被包装得更加"自信"。第三是可回退性。当大模型服务出现故障时（比如上游限流、超时），前置方案会直接导致整个系统崩溃；但后置方案只是让L3层暂时"断开"，L1和L2依然能覆盖大部分请求。

有一次我们上游模型供应商机房故障，大模型服务整体不可用。因为漏斗设计的顺序，L1规则层和L2匹配层照常工作，系统瞬间自动把大模型层降级为一个基于历史会话缓存的最近意图猜测逻辑。那一段时间线上整体功能可用率只下降了3个百分点，而不是崩溃。这就是后置架构的实际价值。

2.4 漏斗精神与Agent记忆、Agent安全的关系

分层漏斗不应该孤立存在，它天然要和Agent系统里的两个模块耦合：记忆模块和安全模块。

记忆模块可以给漏斗提供"用户级意图热点"。比如某个用户连续五次都在查订单物流，那么L1缓存层应该针对这个用户动态增加一个"高优先级意图记录"，直接把查物流的常用表述模板热加载进去，让第六次请求直接命中。这一层记忆我不建议做得太重，简单的LRU热点意图缓存就够了，不需要把记忆向量化塞进大模型上下文——那会让简单问题复杂化。

安全模块放在L3和L4之间尤为重要。当大模型判断出一个意图后，在执行之前需要对照权限策略做一次强制校验。比如"删除用户数据"这个意图在模型层识别出来后，不能直接放行给工具执行，需要经过安全策略引擎查询该用户权限、操作范围、是否二次确认。安全策略必须是独立于意图识别之外的旁路，否则一旦意图识别被提示词注入绕过，Agent的安全防线就跟着失效了。

3. 分层漏斗各层的实现细节与工程化要点

3.1 第一层L1：先别急着上模型，把确定性的活先干完

L1层的目标就是快、省、稳。具体的实现我拆成三个子模块。

高频意图规则库。从线上历史日志里拉起过去30天内的意图分布数据，找到每天调用量超过1000次的意图模板。对"查天气""查余额""打开日程"这类意图，直接由模板匹配完成。这里有个关键细节：写规则时不要把正则写得过死，要考虑用户的自然语言变体。比如"帮我看看明天的天气"和"明天穿什么衣服合适"在语义上都是查天气，但正则很难覆盖后者。所以我这个层只锁死"动词+名词+明确对象"的强规则（比如"查|看|查询|显示"+"天气"），凡是规则匹配不了但高频的请求，宁可放到下一层，也不要强行用宽松正则去磕。

用户级短时缓存。同一用户短时间内重复发相同/相似指令是常态。我们做了一个意图缓存，key是"用户ID+语义Hash（对输入做归一化后的字符串的Hash）"，value是意图ID、缓存时间戳和上下文摘要。用户三次内重复同一请求直接命中，缓存过期时间设成5分钟。这里要特别小心时效性：如果用户第一次问"今天天气"，第二次问"明天天气"，二者的归一化文本不同，不会误中缓存；但如果用户第一次说"帮我订明天早上9点的会议室"，5分钟内又说"改成10点"，这时候你不能直接命中缓存返回"订会议室"，因为你丢失了"改成"这个修正意图。所以缓存必须带一个"意图变体识别"的防御逻辑：当新输入与缓存输入相似但不完全相同，且其中包含意图关键词（订、改、删、取消）时，强制让缓存失效并下沉到下一层。

完全未知意图的快路径拒绝。对于一些明显超出Agent能力的请求（例如"帮我写一首诗"在纯工具型Agent里就没法处理），规则层直接返回"意图不支持"，不进后面的模型层，省掉所有后续开销。但快路径拒绝的目标要设置得非常保守，宁可不拒绝也不能错杀。

3.2 第二层L2：用轻量模型做候选召回，把大模型的负担降到最低

L2层是整个漏斗的性能核心，设计得好能让大模型层的流量占比降到个位数。这一层包含两个并行的技术：向量召回和轻量文本分类。

向量召回。我们把全部的意图描述、意图示例句、工具function文档切块后做成embeddings，存进向量数据库。用户请求进来后，先做query embedding，然后去向量库里检索Top5候选意图。这里有一个我认为最重要的调参技巧：余弦相似度的阈值不能设一个统一的全局值，而应该按意图类型分别标定。比如"查询类意图"的表达方式相对固定，相似度0.88就可以命中；而"操作类意图"（删除、取消、修改）因为用户会带入很多具体参数，整体相似度天然偏低，它的阈值要放到0.82。全局阈值要么导致大量漏判（整体偏高），要么导致大量误判（整体偏低），几乎不可能同时满足两类意图的特点。

轻量分类模型。向量召回的一个问题是它只看语义相似，不抓全局判别信息，偶尔会把"帮我把日历上的会议移到明天"召回到"创建会议"。所以我在向量召回之上还部署了一个轻量级BERT分类器（蒸馏版，参数量约10M），它把用户输入+召回到的Top5候选意图做二分类判别，输出"该候选意图是否正确"。这个模型的训练数据来自线上日志回流的人工标注样本，框架用fasttext或者轻量transformers都行，推理速度在CPU上不到30ms。这里的好处是：模型不是从零开始识别意图，而是给候选排序做置信度校准，任务简单，所以小模型就能胜任。

L2层在判断时，必须输出候选意图列表、每个候选的召回相似度和分类器打分。如果Top1候选的最终分数大于阈值（这个阈值是全局的，但每个意图类型可以有调整），就直接返回结果；否则拼接候选信息和用户原始输入，传给L3大模型层。这种"召回+重排"的结构很多人熟悉，但从搜索领域搬到意图识别场景时，大家容易忽略一点：候选意图的数量和顺序要参考上下文，而不只是当前输入。比如用户上一轮已经在"转账"流程中，这轮说"改5000"，那么候选列表里"修改转账金额"应该排在所有其他候选之前。所以L2层的向量检索我维护的是一个"全局通用意图索引+流程会话态意图索引"双索引，后者只在会话内生效，优先级更高。

3.3 第三层L3：大模型在漏斗里的定位是"仲裁者"，不是"猜测者"

到达L3层的请求已经满足两个条件：L1没命中（说明不是高频规则场景）、L2的Top1置信度不够（说明确实存在语义歧义或者表达不够典型）。这时候你再让LLM去识别，它面对的是真正的难题，但同时它的输入也已经被L2层的召回结果做过"锚定"，不再是无边界自由发挥了。

我的L3 Prompt结构会明确规定四部分内容：候选意图列表及其对应的置信度、对话历史中的关键上下文（由L2提取的意图状态流转，而不是原始聊天全文）、用户当前输入、以及输出约束（只能从候选意图中选择，如果认为候选都不对直接输出Unknown，并给出原因）。这样设计后，大模型的幻觉空间被极大压缩——它不再有机会凭空创造意图枚举值，只能在我们给出的候选池里选择或弃权。

L3层还负责处理一个L2处理不了的场景：多意图混合。比如用户说"帮我查一下明天的行程，顺便订个餐厅"，这是两个意图。L2召回只能锁一个。L3通过预设的多意图解析模式，会把这类请求拆成两个有序意图，并标记执行顺序。这个场景的处理逻辑我放在L3而不是L1/L2，是因为它天然依赖语义综合理解，强行在前两层做只会带来一堆边界case。

还有一个不能省的事：L3层必须做"标定校准"。大模型给出的置信度不能直接当真实概率用，我们需要做一个经验校准。我们统计了模型输出的置信度区间分布和历史准确率的关系，发现0.7-0.8区间的实际准确率只有0.55，0.8-0.9区间的实际准确率约0.85，所以我们在工程上会对模型置信度做一个重映射：低于0.8的请求视为低置信度，不给最终结果，送到L4做兜底或人工。重映射的系数是从两周的线上数据里统计出来的，每隔一周重新统计一次，保证校准曲线跟得上模型行为漂移。

3.4 第四层L4：兜底回流不是设计的终点，而是数据的起点

L4兜底层承担三个职责，很多团队把这个层只当成"认怂层"， 这是极大的浪费。

第一是合理的默认策略。对于L3识别不出的请求，我们不能简单返回"无法识别"。我建议配备一个基于模板和人工打包匹配的"意图需求询问流程"——当意图置信度过低时，让Agent主动向用户提问，缩小范围，再回到L2重新召回。例如用户说"帮我搞定那个事"，系统不知道是哪个"事"，就自动追问"您说的是删除日程、还是修改会议？"这个追问模板由L4层生成，它不在三个主层里循环判断，而是直接引导用户澄清。这样体验比直接报错好了很多，实测可以把LowConfidence请求的意图识别成功率提升约25%。

第二个职责是"新意图挖掘"。把L4层接收到的请求和被触发的追问结果定期汇总，做聚类分析，看是否存在反复出现的新意图表达。比如有这么一批请求，用户反复说"帮我归档项目"，但我们的意图枚举值里没有"归档项目"这个选项。聚类分析会把这条请求聚成一个独立的簇。然后我们每周人工审核一次，确认是真实需求，就给新意图补充示例句并加入L1规则库或者L2索引。这就是一个让漏斗可持续进化的闭环。

第三是Badcase回流入训练集。L3输出错误、L2阈值设置不当、L1规则误命中的case，都要自动打标后进入一个"待校正数据集"。这个数据集定期由标注同学或半自动规则整理成标准格式，一部分补充到L2小分类模型的训练样本里，一部分更新到L1规则库，还有一部分作为L3评测集的负样本。

4. 阈值标定、成本核算与整套系统实测效果

4.1 置信度阈值背后的统计逻辑和标定方法

阈值的设定是整个漏斗里最容易被低估的事情。我见过有人拿拍脑袋的0.9当默认值，结果L2层漏掉一半请求，L3层流量占比冲上40%，成本和延迟全部飙升。阈值不是一个静态值，它应该来自一份"置信度-准确率-覆盖率"的三方联调曲线。

我们在两周内随机采集了十万条请求，让每一层都对请求打分（不截断），然后把打分记录下来，最后人工标注每条请求的真实意图，得到一张分布表。从中就能画出这样一条曲线：当L2的分数阈值从0.8调到0.9，通过率从35%降到22%，但准确率从96%升到98.5%。你要做的就是在准确率和覆盖率之间找平衡点。对于意图识别来说，我的经验是"宁可多放一点模糊请求到下一步，也不要在当前层硬切"，所以L2我的阈值标在0.85附近，对应的单层准确率是97%、通过率是29%。这个数值不是最优解，是在成本和准确率之间性价比最高的解。

L3的阈值标定更讲究，因为大模型的错误代价比小模型要高——它错了之后整个流程会往错误方向执行，比不执行还糟糕。所以我们用重映射后的置信度做判定，低于0.75直接走L4。这个经验数值在不同模型上会有差异，但思路一致：大模型层的低置信度结果必须触发人工确认或追问流程，不能硬着头皮下发工具调用。

4.2 成本与延迟预算的工程测算

做工业级系统，预算必须建立在可计算的模型之上。拿我们的量级（日均约220万次意图识别请求）举例：

• L1 规则+缓存：单请求成本几乎为零，延迟中位数5ms；
• L2 召回+分类：单请求成本约0.0005元（主要是向量检索和CPU推理），延迟中位数约35ms；
• L3 大模型层：单请求成本约0.03-0.06元（取决于输入长度和模型档位），延迟中位数约800ms；
• 兜底层以上传日志和定时任务为主，单独核算。

流量占比大概是这样：L1命中约48%，L2命中约32%，L3约占15%，L4约5%。

综合成本 = 0.48×0 + 0.32×0.0005 + 0.15×(0.03~0.06) + 兜底成本。算下来日均意图识别成本大约在几百元人民币量级。如果单一方案全程用大模型，日均成本至少是3500元以上。这中间差了近7倍，而且大模型的延迟还在高峰期成倍恶化。分层漏斗在这个维度上的收益是决定性的。

4.3 线上A/B实验与上线后的指标对比

我们上线分层漏斗时做了两周的A/B实验，对照组留在旧的单一大模型方案，实验组跑漏斗方案。样本为随机分流，各覆盖50%的生产流量。最终核心指标如下表所示：

准确率提升有一个关键原因：分层后，L3大模型处理的是L2召回过"锚定候选"的场景，输入更清晰，输出限制更严，反而比自由枚举的旧方案更少犯错。这说明漏斗不是用一个模型替代另一个模型，而是合力提升了每层各自擅长的子任务的能力。

4.4 评测集构建与回归防退化

任何一个新的分层方案上线后，都要防止一个幽灵：随着规则层不断加规则、模型层不断精调，系统在新数据上越学越偏，旧能力反而退化。所以我们在做评测集时定了三条硬规矩。

第一，评测集必须是分层切片的。单独一套测试集上跑整体准确率没有任何意义，出了问题你根本定位不到是哪一层退化。我的做法是给数据集打上标签：这些case本来应该由L1命中、这些应该走到L2、这些应该交给L3、这些应该进兜底。每天跑回归时，每层只看自己该管的那一批样本，任何一层退化都能被迅速发现。

第二，评测集要包含"扰动样本"。模型和规则有一个共性问题——对输入顺序和吞吐敏感。把"帮我查一下明天的天气"改成"明天天气，帮我查一下"，在端到端模型上准确率可能会下降几个点。所以评测集里特别要加入这类词序打乱、无语义停顿、口语插词、错别字变体，这些都是线上真实环境里每天都在发生的事。很多团队测了标准样本就觉得自己很优秀，上线后被口语打回原形，问题就出在这。

第三，新意图加入必须触发"全量回归"。每当我们要加一个新的意图，不是简单往L2向量库里插几条向量就完事。我会专门生成新意图的标准评测样本，跑一遍全量回归，观察它和现有30多个意图类别之间的混淆度矩阵。比如新增"归档项目"意图后，如果发现它和"删除项目"的混淆度超过5%，那就说明向量库的embedding信息不足以区分这两个语义，需要补充意图描述、增加差异化的正负样本到分类器里重新训练。

5. 落地过程中最容易踩的坑和最重要的经验

5.1 坑一：把"漏斗"做成了"多级串行堆叠"

这是我见过最多人走偏的方向。他们拿着分层漏斗的PPT出去讲，但实现的时候就是把规则、小模型、大模型串起来，每层做一次全量判断，都要"自信"才放行。这导致的问题是：每一层都要精确，每一层都会漏，漏下去之后下一层又要在没有足够信息的情况下重启判断，彻底丢失了前面层的概率特征。漏斗的"放行"不是"拒绝后传递给下一层"，而是"本层处理到它该处理的完整程度，把处理过程和置信度一起传给下一层"。下一层看到的不应该是"未命中"三个字，而是"这个请求和意图X的余弦相似度是0.81，分类器得分是0.63，候选意图列表中还有Y和Z"。信息传递的质量决定了漏斗能不能形成"递进放大"的效果，而不是"层层衰减"。

5.2 坑二：只看准确率，不评估"错误成本的分布"

意图识别里的错误不是等价的——把"删除"误判成"归档"的代价，比把"查询"误判成"统计"的代价可能高一百倍。单纯拿准确率做调优指标，会诱导模型为了刷分而把一些高风险操作意图往"安全"的低风险意图靠。我们在实际工程里给每个错误样本配了一个"损害权重"，高权重错误包括删除、修改、转账类误判，低权重错误包括查询、打开类误判。在评测和阈值调整时，我们用的指标是"加权错误率"而不是"平权准确率"。L2阈值往高调或者往低调，查看的是加权错误率怎么变化，这才能真实反映生产环境的风险暴露。

而且有一类误差特别容易被忽略：意图识别"太准"导致的体验下降。当一个用户的指令里带点模糊词，系统为了准确率强行追问澄清，追问次数多了用户就会烦躁。我们用了一个很朴素的平衡方案：对高风险的意图（删除、修改、支付）必须高置信度才执行，宁可多问一次；对低风险意图（查询、翻页、打开）哪怕置信度偏低也直接执行。这本质上是把风险成本纳入了意图识别的决策函数里。

5.3 坑三：忘记给整条漏斗留下逃生通道

即使分层漏斗已经做得比较稳，生产系统还是要留出两条逃生通道。第一条是面向Agent执行器的逃生通道：当L3意图识别和下游工具执行的返回值产生明显冲突时（比如识别出"查询天气"但工具返回的是"该技能未开通"），执行器要反向通知意图识别模块做二轮纠偏，而不是认死理。第二条是面向用户的明示逃生通道：漏斗无法识别的请求，除了追问澄清，还应该提供"转人工客服"或"新建工单"的出口。不要试图让意图识别系统对100%的输入都有答案，真实世界里永远有超出枚举值的需求。留下逃逸出口，反而能在体验上把系统做不到的事变成"系统诚实但不完美"的正面印象。

5.4 最有价值的一件事：把漏斗对齐到"Agent系统规划"的高度

最后我说说分层漏斗设计和整体Agent架构之间的关系。很多人做Agent的时候，意图识别是作为一个一次性判断模块存在的——用户输入进来，判别完，就转给工具调用，完事。但在我做完这套漏斗后，最大的体会是：漏斗不应该只被理解为"意图分类器"，它其实是Agent系统里一个"交互预算分配器"和"风险分发器"。

什么意思呢？它本质上是把一个模糊的、开放的意图识别问题，拆成了四个不同粒度的子问题，然后按照成本、延迟、风险三个维度分配处理资源。这和你设计Agent的记忆模块时要决定"什么信息放短期记忆、什么放长期记忆、什么向量化、什么结构化"，是同一个思路。所以当你把意图识别做成漏斗，再去设计Agent的记忆、Agent的工具编排、Agent的安全护栏时，会发现它们是天然对齐的——都是"在不确定信息环境中做多级决策、按资源代价分层处理"的模式。

如果你正在做一个中大型Agent系统，我的建议是别把意图识别当做一个点来优化，把它当成一个基础设施来架构。先从规则层和缓存层开始搭，哪怕一开始只有两层，也要把漏斗的"放行+信息传递"语义定义清楚。然后逐步加入小模型召回、大模型仲裁、兜底回流。每一层的加入都应该带着明确的数据回流计划，而不是"模型效果不好就加一层"的堆叠。这样你的系统会越跑越顺，而不是越跑越乱。

这套分层漏斗我做完之后回头复盘，最想分享的一句话其实是：在LLM时代做工程，别把所有希望寄托在"最强模型"上，要学着把模型当成一种可以被调度的服务资源，该用多少用多少，该在哪里用在里用。今天我们做的意图识别是这样，明天做Agent编排、Agent安全、Agent记忆进化，底层逻辑也还是这样。