面试官：Agent意图识别怎么做？95%的人一句话就把自己送走了
面试官：Agent意图识别怎么做？95%的人一句话就把自己送走了
神奇小汤圆 2026-07-22 0 阅读13分钟面试官：Agent 的意图识别怎么做？
如果是你。
面试官突然问一句：
“Agent 的意图识别怎么做？”
你的第一反应是不是这样？
“就是把所有 Intent（意图） 和 Intent Description（意图描述） 放进 Prompt，让大模型返回一个 Intent。”
说完。
你以为回答完了。
面试官点点头。
然后继续问：
“线上几十上百个 Agent 怎么办？”
“Intent 很多怎么办？”
“两个 Intent 都很像怎么办？”
“识别错了怎么办？”
......
如果这些问题你一个都回答不上来。
基本上这轮 Agent 面试已经结束了。
很多同学觉得这是自己不会。
其实不是。
而是你的答案停留在 Demo 阶段，而面试官想听的是生产级方案。
今天，我们就来复盘一下，这道题到底应该怎么回答。
第一层答案（95%的人都这么回答）
很多人都会说：
Agent 的意图识别其实很简单。
例如系统里面有几个 Intent。
查询天气
查询股票
聊天
知识问答
生成代码
然后给每个 Intent 写一个描述。
例如：
Intent1:
查询天气
描述：
用户想查询天气、温度、空气质量。
Intent2:
股票查询
描述：
用户想查询股票、基金、证券信息。
然后把所有 Intent 一起放到 Prompt 里面。
例如：
System Prompt
你现在负责意图识别。
下面是所有Intent。
......
用户输入：
上海今天天气怎么样？
请返回Intent名称。
LLM 返回：
Weather
然后系统进入 Weather Agent。
整个流程结束。
很多 Demo 都是这么做的。
实际上，对于只有几个 Intent 的 Agent，这个方案完全没有问题。
很多开源项目也是这么实现的。
但是。
如果你在面试里回答到这里。
基本已经结束了。
因为真正的线上系统，几乎没人这么干。
面试官真正想听的是什么？
真正的 Agent，并不是几个 Intent。
而是几十个。
甚至几百个。
例如企业 Copilot。
可能有：
HR Agent
财务 Agent
合同 Agent
OA Agent
审批 Agent
CRM Agent
研发 Agent
运维 Agent
......
每个 Agent 又有几十个 Intent。
如果全部放进 Prompt。
马上出现几个问题。
第一个问题：Token 爆炸
假设：
一个 Intent 描述 300 Token。
100 个 Intent。
就是：
300 × 100
=30000 Token
用户只问一句：
今天上海天气怎么样？
结果先发送三万 Token。
成本直接炸了。
不仅贵。
速度也慢。
很多工程团队都会先做路由，把请求送到更小的能力集合，而不是把所有能力一次性交给 LLM。
所以。
第一件事情。
一定要减少参与分类的 Intent 数量。
第二个问题：Intent 越多，准确率越低
例如：
查询天气
天气预报
空气质量
生活指数
未来天气
LLM 很容易分不清。
尤其 Intent 边界不清晰的时候。
准确率会越来越低。
因此生产环境一般都会要求：
Intent 之间必须互斥。
描述必须清楚。
不能存在大量重叠。
这是很多企业做 Intent Design 时最强调的一点。
第三个问题：误识别以后怎么办？
很多人到这里就不会了。
其实真正线上系统。
不会相信一次分类。
因为：
LLM 永远可能判断错。
所以一定有：
Confidence（置信度）
例如：
Intent：
Weather
Confidence：
98%
如果：
98%
直接进入 Agent。
如果：
55%
怎么办？
不是继续执行。
而是：
反问用户。
例如：
请问你是想查询今天的天气，
还是未来七天的天气？
或者：
你说的苹果，
是苹果公司，
还是水果？
不要猜。
让用户确认。
这是线上 Agent 非常重要的一步。
真正让我满意的答案，是这一套分层架构
如果我是面试者。
我会这样回答。
最简单的方案，确实是把所有 Intent 和 Intent Description 一起交给 LLM 分类。
但是这种方案更适合 Demo。
如果是生产环境，我一般会采用多阶段 Intent Routing。
整个流程如下：
整个流程其实可以分成三层。
首先，用户输入一句话，比如这里说的是：
“苹果多少钱？”
注意，这句话其实是有歧义的。
它既可能是在问苹果水果的价格，也可能是在问苹果公司的股价，甚至还有可能是在问 iPhone 的价格。
所以，如果一上来就把所有 Intent 丢给大模型去判断，不仅成本高，而且还容易误判。
因此，生产环境一般不会这么做。
第一层叫规则匹配（Rule Matching）。
这一层的目标只有一个：快速过滤那些确定性的请求。
比如 Regex、关键词匹配、黑白名单等等。
如果一句话能够通过规则直接确定意图，例如用户输入”天气预报”、”帮助中心”这种固定表达，那么系统就直接返回结果或者进入对应 Agent，根本不需要调用大模型。
这样做最大的好处就是速度快、成本低。
如果规则没有命中，再进入下一层。
第二层是 Embedding 语义召回。
这一层非常关键。
假设你的系统里有 100 个 Intent，如果全部交给 LLM 去比较，不仅 Prompt 很长，而且 Token 消耗也会非常高。
所以这里会先利用 Embedding 计算用户输入和所有 Intent 的语义相似度。
比如从 100 个 Intent 中，只召回最相关的 Top 5。
这一层并不是最终做决策，而是负责缩小搜索范围。
你可以把它理解成搜索引擎里的”初筛”，把明显不相关的 Intent 全部过滤掉。
第三层才是真正交给 LLM 做分类。
不过这个时候，大模型已经不用面对 100 个 Intent 了，而是只需要在刚刚召回的 5 个候选 Intent 中做选择。
因此，它可以输出三个结果：
第一个是最终识别出来的 Intent；
第二个是 Confidence（置信度） ；
第三个是为什么这么判断，也就是 Reason。
这样不仅准确率更高，而且 Prompt 更短，推理速度也更快。
最后，系统会根据置信度做不同处理。
如果置信度很高，比如超过 80%，那么就直接进入对应的 Agent 执行业务逻辑。
但是，如果置信度比较低，就千万不要猜。
而是进入 Clarify（澄清） 阶段，主动向用户确认真实意图。
比如这里的例子：
“你说的苹果，是苹果公司，还是水果？”
等用户回答之后，再重新进行一次意图识别。
虽然多了一轮对话，但是可以大幅降低误判带来的业务风险，这也是很多企业级 Agent 都会采用的设计。
所以，这张图最核心的思想其实就一句话：
不是一开始就让 LLM 判断所有 Intent，而是通过”规则过滤 + Embedding 召回 + LLM 精排 + Clarify 兜底”的多阶段路由架构，在准确率、Token 成本和响应速度之间取得最佳平衡。
这也是为什么很多人做出来的是 Demo，而真正上线的 Agent，几乎都会采用这种分层的 Intent Routing 架构。
为什么要加 Embedding？
很多人会问：
既然最后还是 LLM 分类。
为什么还要加 Embedding？
答案只有两个字：
降本。
例如：
线上：
500 个 Intent
Embedding 一次召回：
Top10
LLM 只需要比较：
10个
Prompt 大幅缩小。
Token 大幅下降。
速度更快。
成本更低。
很多生产系统都会采用”Embedding 初筛 + LLM 精排”或者”轻量分类器 + LLM 兜底”的两阶段、三阶段路由，而不是让 LLM 每次面对完整的意图集合。
如果面试官继续追问：”还能继续优化吗？”
如果回答到这里，很多候选人已经不知道该说什么了。
但真正的企业级 Agent，远远不是把 Intent 识别出来就结束了。
在生产环境中，一个优秀的 Intent Routing 系统，还必须具备持续观测、持续评测和持续迭代的能力。
如果是我，我会继续这样回答。
① 建立完整的 Trace，能够完整回放每一次决策过程
首先，我会为每一次请求建立完整的 Trace。
记录的不仅仅是最终识别出的 Intent，而是整个 Routing 的决策链路。
例如一次请求会记录：
用户输入
│
▼
Embedding Top-K 召回结果
│
▼
LLM Prompt
│
▼
LLM 输出
(Intent、Confidence、Reason)
│
▼
进入哪个 Agent
│
▼
调用了哪些 Tool
│
▼
最终回复结果
这样做最大的价值是**可回溯（Traceability）** 。
例如某一天用户反馈：
“这个 Agent 怎么总是理解错我的问题？”
这时候，我们可以直接回放这条 Trace。
到底是 Embedding 没有召回正确的 Intent？
还是 Prompt 导致 LLM 分类错误？
又或者是 Confidence 阈值设置得太低？
有了完整的 Trace，整个决策过程都能够被还原，排查问题的效率会高很多。这也是目前很多 Agent 平台首先建设 Tracing 能力的原因，因为后续的评测、调试和优化都依赖于完整的运行轨迹。