Agent 意图识别：从 Demo 到生产级的演进之路

做 Agent 开发的时候，意图识别是最先碰到的问题之一。最开始我觉得这事很简单——系统里有几个意图，每个意图写个描述，全塞进 Prompt，让 LLM 返回一个分类结果就完事了。

Demo 阶段确实这么干的，跑得也挺好。但当意图数量从 5 个变成 50 个、甚至上百个的时候，问题全暴露了：Token 成本暴涨、准确率下降、识别错了也没有纠错机制。

这才意识到，意图识别不是「让 LLM 做选择题」这么简单。它是一套从架构设计到工程闭环的完整体系。下面是我从 Demo 到生产级的完整演进过程，包括踩过的坑和最终的方案。

Demo 级方案：把所有意图塞进 Prompt

① 最直观的做法

起步阶段，大多数人的做法都一样。系统里定义几个 Intent，每个写一段描述：

Intent1:
查询天气

描述：
用户想查询天气、温度、空气质量。

Intent2:
股票查询

描述：
用户想查询股票、基金、证券信息。

Intent3:
聊天

描述：
用户想闲聊、打发时间。

然后把所有 Intent 一起放到 System Prompt 里：

你现在负责意图识别。

下面是所有Intent。

Intent1: 查询天气 - 用户想查询天气、温度、空气质量。
Intent2: 股票查询 - 用户想查询股票、基金、证券信息。
Intent3: 聊天 - 用户想闲聊、打发时间。

用户输入：
上海今天天气怎么样？

请返回Intent名称。

LLM 返回：

Weather

系统根据这个结果路由到对应的 Agent，流程结束。

② 为什么 Demo 阶段够用

意图只有三五个的时候，这个方案完全没问题。Prompt 不长，Token 成本可以忽略，LLM 也能准确区分这几个差异明显的意图。很多开源项目也是这么实现的。

但问题在于，Demo 阶段的「够用」是有前提的：意图少、边界清晰、不计成本。一旦这三个前提被打破，方案就会崩。

Demo 方案的三个致命问题

① Token 爆炸

假设一个 Intent 描述 300 Token，100 个 Intent 就是 30000 Token。用户只问了一句「今天上海天气怎么样」，系统先发送三万 Token 的意图描述。成本直接炸了。

不仅贵，速度也慢。LLM 处理三万 Token 的 Prompt 需要时间，用户感知到的延迟会明显增加。

很多工程团队的做法是先做路由，把请求送到更小的能力集合，而不是把所有能力一次性交给 LLM。第一件事就是减少参与分类的 Intent 数量。

② 准确率下降

意图越多，LLM 越容易分不清。尤其是意图边界不清晰的时候：

查询天气
天气预报
空气质量
生活指数
未来天气

这五个意图在 LLM 眼里可能都是「查天气」。当 Intent 之间存在大量重叠，模型就开始「脑补」——它会根据 Prompt 中的顺序、描述的措辞、甚至随机因素来做判断。

Intent 之间必须互斥，描述必须清楚，不能存在大量重叠。 这是做 Intent Design 时最重要的一条原则。

③ 没有容错机制

最致命的问题：Demo 方案不承认 LLM 会犯错。

用户说「苹果多少钱」，LLM 可能返回「水果价格查询」，但用户想问的是苹果公司的股价。Demo 方案会直接按这个错误结果路由，没有任何纠错环节。

生产环境不能相信一次分类。 LLM 永远可能判断错，系统必须有容错机制。

回头看这三个问题，根源都一样：架构没有分治。把所有意图一次性扔给 LLM，等于让一个模型同时承担「粗筛」和「精判」两个职责。这两个职责对精度和成本的要求完全不同，混在一起只会两头都不讨好。

生产级方案：多阶段路由

① 核心思想：分而治之

真正的生产环境面对的是几十甚至上百个 Agent、数百个 Intent。解决方案的核心思想是分而治之，逐级过滤——通过一个多阶段路由管道，在成本、速度和准确率之间取得平衡。

这个管道的每一层只做一件事，层层过滤，最终让 LLM 每次只处理一小部分意图。

② 第一层：规则匹配

零 Token 成本，极速处理确定性请求。

用正则表达式、关键词匹配、黑白名单等硬规则。用户输入「帮助」「人工客服」「转人工」这类关键词，直接路由到客服 Agent，不需要经过 LLM。

用户输入: "转人工"
规则匹配: 命中关键词 "人工"
结果: 直接路由到客服Agent，跳过后续所有层

这是成本效益最高的过滤层，能拦截大量高频、简单的请求。

③ 第二层：语义召回

大幅缩小候选意图范围，为后续的 LLM 精排「减负」。

离线将所有意图的描述通过 Embedding 模型（如 text-embedding-3-small、bge 等）转化为向量，存入向量数据库（Milvus、Faiss 等）。用户请求来时，在线将其向量化，通过近似最近邻（ANN）搜索，只召回语义最相似的 Top-K 个（5-10 个）意图。

所有意图: 100个
    ↓ Embedding + ANN 搜索
候选意图: Top-5

将后续 LLM 需要处理的意图从数百个锐减到个位数，Prompt 长度和 Token 消耗呈指数级下降。

④ 第三层：LLM 精排

在缩小后的候选集上，利用 LLM 的语义理解能力做最终判断。

将用户问题和召回的 Top-K 个意图描述组成精简 Prompt，交给一个轻量级、低温度（如 0.1） 的 LLM 进行分类。模型输出结构化结果：

{
  "intent": "weather_query",
  "confidence": 0.98,
  "reason": "用户询问上海天气，明确属于天气查询意图"
}

三个字段各有用途：intent 是最终分类结果，confidence 是置信度分数，reason 是判断理由。reason 字段特别重要——当分类出错时，它能帮你快速定位 LLM 是怎么「想歪的」。

⑤ 第四层：置信度门控 + 澄清

承认模型会犯错，建立容错机制。

系统预设一个置信度阈值（如 0.75 或 0.8）。超过阈值直接路由；低于阈值不执行任何操作，触发澄清流程，向用户提问确认。

用户输入: "苹果多少钱？"
LLM 精排结果:
  - 水果价格查询: confidence 0.45
  - 公司股价查询: confidence 0.42

两个都不超过阈值 0.75

系统回复: "您是指苹果水果的价格，还是苹果公司的股价？"

通过多一轮对话，将误判的风险转由用户闭环确认，极大降低了错误路由带来的业务风险。

这四层合在一起，每一层都在为下一层减负。规则匹配拦截确定性请求，语义召回缩小候选范围，LLM 精排做最终判断，置信度门控兜底容错。LLM 每次只做小范围的选择题，而不是面对几百个意图大海捞针。

四种技术方案对比

多阶段路由是一种架构思路，具体到每一层怎么实现，有四种主流方案。它们不是互斥的，实际项目中往往会组合使用。

① 提示词工程

最简单的方案。在单一 LLM 节点中，通过精心设计的 Prompt（包含意图定义、Few-shot 示例等）同时完成意图识别和槽位抽取。

System Prompt:
你是意图识别助手。请根据用户输入判断意图，并抽取关键信息。

意图列表：
1. 查询天气 - 用户想查天气、温度、空气质量
2. 股票查询 - 用户想查股票、基金、证券
...

请以JSON格式返回：{"intent": "", "slots": {}}

优点：开发成本低、速度快，门槛极低。缺点：可扩展性差，意图一多 Prompt 就变得非常冗长，模型容易混淆。适合意图数量在 5 个以内、业务简单的场景。

② 节点分离

将「意图识别」和「槽位抽取」拆分为两个独立的 LLM 节点，各司其职。

用户输入 → LLM节点1(意图识别) → 意图结果
                                    ↓
                              LLM节点2(槽位抽取) → 结构化结果

优点：架构清晰、维护性强，新增或修改意图的影响范围小。缺点：两次调用 LLM 导致系统延迟增加，总耗时可能达到 5 秒左右。适合意图较多（5-15 个）、对实时性要求不高的场景。

③ RAG 增强

构建一个「意图泛化知识库」，先通过 RAG 检索找到与用户输入最相似的意图示例，再将检索结果和用户问题一起交给 LLM 判断。

这种方式的核心价值是泛化能力。用户说「明儿个冷不冷」和「明天北京气温多少」，传统的关键词匹配分不清，但 RAG 能通过语义相似度把它们都归到「天气查询」。

优点：能更好地理解方言、口语化表达等未见过的说法。缺点：需要维护和更新知识库，增加了系统复杂性。适合对话场景多样、需要处理大量不同表述方式的系统。

④ 规则+语义+大模型三重融合

工业级成熟方案。先通过关键词等规则快速过滤，再由语义向量模型计算相似度进行粗排，最后由大模型对 Top 结果进行精准判断。这就是前面讲的多阶段路由的具体实现。

优点：兼顾准确性、泛化性和可部署性。缺点：系统最复杂，需要维护多个组件。适合对准确率和稳定性要求极高的企业级核心应用。

⑤ 一张表看清区别

方案	核心思路	优点	缺点	适用场景
提示词工程	全部塞进 Prompt	成本低、速度快	可扩展性差	5 个意图以内
节点分离	意图识别+槽位抽取拆开	架构清晰	延迟增加	5-15 个意图
RAG 增强	意图泛化知识库	泛化能力强	需维护知识库	多样化表述
三重融合	规则+语义+大模型	准确性高	系统复杂	企业级核心应用

意图识别不只是分类：槽位抽取

① 意图分类和槽位抽取是一对

意图识别不只是判断用户「想做什么」，还要提取出完成任务所需的「关键信息」。前者叫意图分类，后者叫槽位抽取（Slot Extraction）。

比如用户说「帮我订一张明天去北京的机票」：

{
  "intent": "订机票",
  "slots": {
    "时间": "明天",
    "目的地": "北京"
  }
}

意图是「订机票」，槽位是「明天」（时间）和「北京」（目的地）。只有意图没有槽位，Agent 知道要订机票但不知道订哪天的、去哪里。两个缺一不可。

② 结构化输出

为保证后续程序能稳定处理，系统会强制 LLM 以 JSON 格式输出结果。这不是可选的，是必须的。如果 LLM 返回一段自然语言，下游的路由逻辑还得再做一次 NLP，等于多了一层不确定性。

{
  "intent": "flight_booking",
  "confidence": 0.95,
  "reason": "用户明确提到订机票，且包含时间和目的地信息",
  "slots": {
    "date": "明天",
    "destination": "北京"
  }
}

③ 多轮对话管理

多轮对话中，意图识别的复杂度会上升一个台阶。用户第一轮说「我想去北京」，第二轮说「明天的」，第三轮说「要经济舱」。每一轮都在补充槽位信息，Agent 需要维护对话状态，解决指代消解（「它」指代什么）和需求变更（「算了，改去上海」）等问题。

这已经不是单次意图分类能解决的了，需要一个对话状态管理模块来追踪当前意图和已填充的槽位。

工程闭环：上线只是开始

① 可观测性

一个生产级的意图识别系统，上线只是开始。第一件事是建立全链路的 Tracing 系统，记录每一次请求的完整决策过程：

用户输入 → 规则匹配结果 → 语义召回的Top-K → LLM的Prompt和输出 → 最终路由结果

当用户投诉「我明明说的是查天气，为什么给我查了股票」，你需要能回放这次请求的完整链路，定位是哪一层出了问题。没有 Trace，调试就是盲人摸象。

同时需要 Dashboard 监控 QPS、平均延迟、Token 消耗、各意图的分布、低置信度请求的比例等系统运行指标。

② 离线评测

线上负责发现问题，真正判断模型能力的是离线评测。定期从线上 Trace 中抽取一部分真实用户请求，构建 Evaluation Dataset：

线上 Production Trace
        ↓
抽样真实 Query
        ↓
人工标注（或 LLM-as-a-Judge 初筛）
        ↓
生成 Ground Truth
        ↓
重新运行最新版 Router
        ↓
计算 Accuracy、Precision、Recall、F1

有了 Ground Truth，就可以客观评估当前模型的识别能力。同时能发现哪些 Intent 最容易混淆、哪些 Query 最容易误判，为下一轮优化提供依据。

很多团队会采用人工标注 + LLM-as-a-Judge 相结合的方式，提高评测效率的同时保证评测质量。

③ Golden Dataset 和 Benchmark

维护一套长期演进的 Benchmark。Golden Dataset 里收集了大量真实业务场景：

• 正常请求
• 歧义请求（「苹果多少钱」）
• 错别字（「查下天汽」）
• 口语化表达（「明儿个冷不冷」）
• 中英文混输（「查一下AAPL的股价」）
• 未知意图（系统没有对应能力的请求）
• 长文本输入

每次修改 Prompt、调整 Intent、升级 Embedding 模型或切换新的 LLM，都必须重新跑完整套 Benchmark。只有当准确率没有下降、性能没有明显退化、成本仍然符合预期时，新版本才允许上线。

④ 持续优化闭环

生产环境持续沉淀真实数据，不断丰富 Benchmark，每一次版本升级都经过完整的 Regression Test。新版本解决了旧问题，同时不会引入新问题。

这就是生产级意图识别和 Demo 的本质区别：Demo 是「跑通了就行」，生产级是「持续跑通、持续优化」。

前沿方向

① 意图校准与对齐

研究如何让 Agent 的意图与人类保持一致。意图重写（Intent Rewriting） 将多轮对话精简为用户目标的清晰表述——比如用户绕了一大圈，系统自动提炼出「他其实想订明天去北京的机票」。意图策略图（Intentional Policy Graphs） 用来解释 Agent 的行为逻辑，让决策过程可追溯。

② 隐式意图挖掘

用户不一定每次都明确说出自己的意图。从用户界面（UI）的交互轨迹、点击序列、页面停留时间等非直接语言数据中推断意图，是智能体发展的前沿方向。比如用户反复查看某个商品但没下单，Agent 可以主动问「要不要帮你比个价」。

③ 理论心智

让 Agent 不仅能识别意图，还能「揣摩」用户的信念和想法。这就是 Theory of Mind（理论心智）。比如用户问「附近有什么好吃的」，普通 Agent 返回餐厅列表；有 Theory of Mind 的 Agent 会结合用户之前的饮食偏好、当前位置、时间（早中晚餐），给出更个性化的推荐。

这些方向目前还在探索阶段，但代表了意图识别从「被动分类」到「主动理解」的演进趋势。

我的思考和收获

① 意图识别的本质

做完这一轮演进，我最大的收获是：意图识别的本质不是「让 LLM 做选择题」，而是一套工程体系。

Demo 阶段让人误以为意图识别就是写个 Prompt 的事。但当意图数量增长、业务复杂度上升、准确率要求提高以后，单靠 Prompt 工程根本撑不住。需要架构分治（多阶段路由）、需要语义召回（Embedding + 向量数据库）、需要容错机制（置信度门控 + 澄清）、需要持续优化（Tracing + 评测 + Benchmark）。

② 架构分治 > 堆砌 Prompt

问题不在 LLM 不够聪明，而在架构没有分治。 把几百个意图一次性扔给 LLM，等于让一个模型同时承担粗筛和精判两个职责。分治之后，LLM 每次只处理 5-10 个候选意图，准确率和成本都能控制住。

③ 没有银弹

最合适的方案取决于三个因素：业务复杂度、响应速度、研发成本。 意图少于 5 个，提示词工程就够了。意图 5-15 个，节点分离更清晰。意图几十上百个，三重融合是必经之路。不要一开始就搞最复杂的架构，也不要一直停留在 Demo 阶段。

④ 还没想明白的事

意图数量继续增长怎么办？当意图从几百个变成几千个，语义召回的准确率还能不能保证？跨语言、跨域的意图迁移怎么实现？比如一个电商 Agent 的意图识别模型，能不能迁移到金融 Agent？这些问题我还没有答案，但会在后续的项目中继续探索。

写在最后

从「把所有意图塞进 Prompt」到「规则+语义+大模型三重融合」，意图识别的演进路线其实很清晰：Demo 阶段验证可行性，生产阶段解决规模和精度问题，工程闭环阶段解决持续优化问题。

三个关键认知：

1. 架构分治：让 LLM 每次只做小范围的选择题，而不是面对几百个意图大海捞针
2. 容错设计：置信度门控 + 澄清机制，承认模型会犯错并建立纠错通道
3. 持续优化：Tracing + 评测 + Benchmark + 回归测试，形成闭环

生产级意图识别 = Routing + Observability + Evaluation + Benchmark。不是一次分类，而是一套能持续演进的工程体系。