智能体意图识别：三层漏斗架构工程实践解析

一道让面试官打叉的经典问题

"智能体是如何进行意图识别的？"这是大模型岗位面试中的高频考题。B站UP主Jack在其分享中指出，很多候选人一开口就说"丢给大模型让它判断不就行了"，结果面试官心里已经暗暗给出了差评。

这里需要先厘清一个基础概念：意图识别（Intent Recognition）是自然语言理解（NLU）的核心任务之一，目标是判断用户一句话背后的真实目的。与之紧密配套的是槽位填充（Slot Filling），即从用户话语中抽取执行任务所需的关键参数。例如"帮我订明天早上去北京的机票"，意图是"订机票"，槽位则包括出发时间"明天早上"、目的地"北京"。这两个任务在传统对话系统中往往由独立模块串行处理，但在大模型时代逐渐被合并到同一个模型中联合建模，既减少了误差传递，也降低了系统调用次数。理解这一对概念，是搞懂后文优化思路的前提。

为什么"全丢给大模型"这个回答不行？因为在真实的生产环境里，如果每一句用户输入都交给大模型去猜测意图，延迟、成本、稳定性这三个关键指标会同时崩盘。这道题真正考察的，从来不是你会不会挑模型，而是你能否在高准确率、低延迟、可控成本三者之间找到工程上的平衡点。

意图识别最怕两个极端：一是全靠写死的规则，灵活性为零，用户换一种说法就识别失败；二是全靠大模型硬扛，每句话都过一遍模型，既慢又贵还不稳定。工程化的答案在于分层设计。

核心思路：把意图识别做成漏斗

整套架构的核心可以用一句话概括——把意图识别做成一个漏斗。简单的请求用规则秒级拦下来，常规的请求用上下文理解兜住大头，只有复杂、模糊的请求才交给大模型做深度判断。

这个漏斗有一个清晰的特征：越往下越聪明，但也越慢越贵。因此设计的目标是让绝大多数请求在上层就被解决，只有真正难的才往下沉。这种"简单的便宜解决，复杂的才付出大模型成本"的取舍思路，正是区分"真做过线上系统"和"只会调API"的分水岭。

第一层：规则层，快速拦截高频命令

规则层负责处理那些意图明确、表达固定的请求，靠关键词、正则表达式和状态机这些最朴素的手段。用户说"打开设置""查一下余额""转人工"，这类命令没有歧义，规则一匹配就能秒级路由。

这些技术手段都是NLP工程中历史悠久且高度成熟的确定性方法。正则表达式（Regular Expression）通过模式串匹配文本，能以极低的计算开销捕获固定结构的表达；有限状态机（FSM）则通过预定义的状态转移图来管理多轮交互的流程走向。它们的最大优势是响应快、结果可解释、零推理成本，但代价是缺乏语义泛化能力——它们只认字面，不懂含义。

但规则层有两个经典的翻车点，也是面试中最能体现深度的地方，本质上都源于这种字面匹配的固有缺陷：

否定语义的陷阱

用户输入"我不要查余额"，纯关键词匹配命中了"查余额"，系统直接路由到查余额流程，用户当场懵掉。纯关键词匹配没有否定语义判断能力，一个"不要"就能让整条规则失效。工程上必须加一层轻量的句式约束——把高频否定词与关键词的组合直接排除，不进入命中列表。

多意图被吞的陷阱

用户说"我套餐余量还有多少兆、还有多少分钟"，规则层命中了流量关键词就直接跳到流量查询，把"分钟剩余"这个意图给吞掉了。因此规则层不能命中一个关键词就结束判断，必须做完整的数据扫描，识别出所有可能的高频意图标签。如果同时命中多个，就标记为多意图，交给下游继续处理，绝不做单一截断。

第二层：上下文层，承接常规意图大头

真实对话里，大部分意图并不是孤立的一句话，而是要结合上文来判断。用户说"那就这个吧"，"这个"到底指什么，得看上一轮聊了什么；用户说"还是不行"，是对哪件事不行，也得靠对话历史来还原。

这一层通常用一个微调过的轻量小模型，结合对话状态和历史做意图分类与参数（槽位）提取。这里的"小模型"通常指参数量在数亿到数十亿级别的预训练语言模型（如BERT、RoBERTa或小型化的开源LLM），通过在特定业务标注数据上做监督微调（Supervised Fine-Tuning）来适配具体的意图分类任务。相比动辄千亿参数的大模型，小模型推理延迟可控制在几十毫秒内，且能私有化部署在企业自有服务器上，避免了数据外泄和按调用量计费的高成本。

有人会问：小模型够用吗？答案是可以，但前提是基于你自己的业务场景，用高质量标注数据做定向微调，然后私有化部署一个专门做意图分类的轻量模型，效果和延迟都能兜住。业界普遍认为，在垂直场景下，几千到上万条精标数据配合小模型，往往能达到甚至超过通用大模型的意图分类准确率，这也是本层能承接九成流量的底气所在。

这一层的工程关键在于状态管理。对话状态维护不好，上下文一乱，意图就会识别歪。因此对话状态机的设计和维护，是上下文层能否稳定承接九成常规意图的核心。

第三层：工具层，大模型兜底复杂需求

前两层都拿不准的请求，才轮到大模型出场。它负责理解复杂、模糊甚至跨领域的需求，之后直接选出该调哪个工具、参数怎么填，一步到位路由到执行动作。

这里"选出该调哪个工具、参数怎么填"，对应的是当前智能体（Agent）领域的核心机制——工具调用（Tool Use / Function Calling）。OpenAI、Anthropic等主流模型厂商都提供了结构化的函数调用能力，让大模型能够根据用户需求自动选择预注册的API，并输出符合JSON Schema的参数，这使得大模型从"只会聊天"进化为"能干活"的执行体。

这一层最聪明，能处理规则和小模型都搞不定的边缘情况，但也最慢最贵。正因为每次工具调用都涉及一次完整的大模型推理，其延迟通常在数百毫秒到数秒之间，单次成本也远高于规则和小模型。它的定位是"少量复杂请求的最终防线"，绝不能扛主流量。一旦用户量上来还把它放在第一层，成本账单分分钟教你做人。

值得注意的一个优化点是：参数提取可以和意图分类合并到同一个模型里做，减少一次额外的调用，进一步压低延迟和成本。

智能体意图识别的面试回答框架

如果被问到这道题，Jack给出的标准回答框架是：

1. 先亮观点：意图识别不做全模型硬扛，而是做成"规则—上下文—工具"三层漏斗。
2. 规则层：处理高频固定命令，用关键词加正则加否定句式约束，注意多意图扫描不截断。
3. 上下文层：用微调小模型承接九成常规意图，兼顾速度和灵活性。
4. 工具层：用大模型兜底复杂模糊需求，直接打通"意图到执行"。
5. 点明核心：简单的便宜解决，复杂的才付出大模型成本，在准确率、延迟、成本三者之间求平衡。

这套讲下来，面试官就知道你是真正做过线上系统的人。意图识别拼的不是谁更会调大模型，而是谁更懂分层和取舍。

结语

这套三层漏斗架构的价值，本质上是把工程约束前置到了系统设计中。它提醒我们：在大模型时代，能力上限固然重要，但落地能力的关键往往在于"什么时候不用大模型"。对于任何要面对真实流量的智能体系统，理解成本、延迟、准确率的三角权衡，比追求单点的模型效果更能决定项目成败。

核心要点