面试官：Agent意图识别怎么做？95%的人一句话就把自己送走了

面试官：Agent 的意图识别怎么做？

如果是你。

面试官突然问一句：

"Agent 的意图识别怎么做？"

你的第一反应是不是这样？

"就是把所有 Intent（意图）和 Intent Description（意图描述）放进 Prompt，让大模型返回一个 Intent。"

说完。

你以为回答完了。

面试官点点头。

然后继续问：

"线上几十上百个 Agent 怎么办？"

"Intent 很多怎么办？"

"两个 Intent 都很像怎么办？"

"识别错了怎么办？"

......

如果这些问题你一个都回答不上来。

基本上这轮 Agent 面试已经结束了。

很多同学觉得这是自己不会。

其实不是。

而是你的答案停留在 Demo 阶段，而面试官想听的是生产级方案。

今天，我们就来复盘一下，这道题到底应该怎么回答。

第一层答案（95%的人都这么回答）

很多人都会说：

Agent 的意图识别其实很简单。

例如系统里面有几个 Intent。

复制代码

查询天气
查询股票
聊天
知识问答
生成代码

然后给每个 Intent 写一个描述。

例如：

makefile 复制代码

Intent1:
查询天气

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

Intent2:
股票查询

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

然后把所有 Intent 一起放到 Prompt 里面。

例如：

sql 复制代码

System Prompt

你现在负责意图识别。

下面是所有Intent。

......

用户输入：

上海今天天气怎么样？

请返回Intent名称。

LLM 返回：

复制代码

Weather

然后系统进入 Weather Agent。

整个流程结束。

很多 Demo 都是这么做的。

实际上，对于只有几个 Intent 的 Agent，这个方案完全没有问题。

很多开源项目也是这么实现的。

但是。

如果你在面试里回答到这里。

基本已经结束了。

因为真正的线上系统，几乎没人这么干。

面试官真正想听的是什么？

真正的 Agent，并不是几个 Intent。

而是几十个。

甚至几百个。

例如企业 Copilot。

可能有：

erlang 复制代码

HR Agent

财务 Agent

合同 Agent

OA Agent

审批 Agent

CRM Agent

研发 Agent

运维 Agent

......

每个 Agent 又有几十个 Intent。

如果全部放进 Prompt。

马上出现几个问题。

第一个问题：Token 爆炸

假设：

一个 Intent 描述 300 Token。

100 个 Intent。

就是：

ini 复制代码

300 × 100

=30000 Token

用户只问一句：

复制代码

今天上海天气怎么样？

结果先发送三万 Token。

成本直接炸了。

不仅贵。

速度也慢。

很多工程团队都会先做路由，把请求送到更小的能力集合，而不是把所有能力一次性交给 LLM。

所以。

第一件事情。

一定要减少参与分类的 Intent 数量。

第二个问题：Intent 越多，准确率越低

例如：

复制代码

查询天气

天气预报

空气质量

生活指数

未来天气

LLM 很容易分不清。

尤其 Intent 边界不清晰的时候。

准确率会越来越低。

因此生产环境一般都会要求：

Intent 之间必须互斥。

描述必须清楚。

不能存在大量重叠。

这是很多企业做 Intent Design 时最强调的一点。

第三个问题：误识别以后怎么办？

很多人到这里就不会了。

其实真正线上系统。

不会相信一次分类。

因为：

LLM 永远可能判断错。

所以一定有：

复制代码

Confidence（置信度）

例如：

shell 复制代码

Intent：

Weather

Confidence：

98%

如果：

shell 复制代码

98%

直接进入 Agent。

如果：

shell 复制代码

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 的决策链路。

例如一次请求会记录：

scss 复制代码

用户输入
        │
        ▼
Embedding Top-K 召回结果
        │
        ▼
LLM Prompt
        │
        ▼
LLM 输出
(Intent、Confidence、Reason)
        │
        ▼
进入哪个 Agent
        │
        ▼
调用了哪些 Tool
        │
        ▼
最终回复结果

这样做最大的价值是**可回溯（Traceability）** 。

例如某一天用户反馈：

"这个 Agent 怎么总是理解错我的问题？"

这时候，我们可以直接回放这条 Trace。

到底是 Embedding 没有召回正确的 Intent？

还是 Prompt 导致 LLM 分类错误？

又或者是 Confidence 阈值设置得太低？

有了完整的 Trace，整个决策过程都能够被还原，排查问题的效率会高很多。这也是目前很多 Agent 平台首先建设 Tracing 能力的原因，因为后续的评测、调试和优化都依赖于完整的运行轨迹。

② 建立线上可观测体系（Observability）

很多人一提到模型上线，就会想到 Accuracy。

但实际上，线上系统更关注的是：

系统今天运行得是否正常。

因此，我们通常会建设一套 Observability Dashboard，持续监控整个 Intent Routing 的运行状态。

例如：

每分钟 Routing 请求量（QPS）
Router 平均耗时、P95 延迟
Embedding 调用耗时
LLM 调用耗时
Token 消耗
Timeout（超时次数）
Retry（重试次数）
Fallback（降级次数）
Clarify（进入澄清节点的次数）

这些指标都可以直接从系统运行过程中采集，不需要人工参与。

例如，当 Clarify Rate 在短时间内突然大幅上升时，虽然不能直接说明模型分类错误，但至少说明最近进入澄清流程的请求明显变多了。

这时候，我们就可以进一步分析：

是不是最近修改了 Prompt？

是不是新增了一批容易混淆的 Intent？

还是模型升级之后，Confidence 的分布发生了变化？

因此，线上 Observability 的作用不是直接判断模型对不对，而是尽早发现异常，帮助研发快速定位问题。当前主流 Agent 平台也强调在线阶段以 Trace、系统运行指标和参考答案无关（Reference-free）的评估为主。

③ 建立离线评测（Evaluation）体系

线上负责发现问题。

真正判断模型能力的，则是在离线完成。

通常，我们会定期从线上 Trace 中抽取一部分真实用户请求，构建 Evaluation Dataset。

整个流程如下：

csharp 复制代码

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

有了 Ground Truth 之后，就可以客观评估当前模型的识别能力。

同时，也能够发现哪些 Intent 最容易混淆、哪些 Query 最容易误判，为下一轮优化提供依据。

目前很多团队都会采用 Human Review + LLM-as-a-Judge 相结合的方式，提高评测效率，同时保证评测质量。

④ 建立自己的 Benchmark，保证每次升级都不会退化

最后，我还会维护一套长期演进的 Benchmark。

例如维护一份 Golden Dataset，里面收集了大量真实业务场景，包括：

正常请求
歧义请求
错别字
口语表达
中英文混输
未知 Intent
长文本输入

每次修改 Prompt、调整 Intent、升级 Embedding 模型或者切换新的 LLM，都必须重新跑完整套 Benchmark。

只有当准确率没有下降、性能没有明显退化、成本仍然符合预期时，新版本才允许上线。

这样就形成了一套完整的持续优化闭环：

markdown 复制代码

Production Trace
        │
        ▼
Offline Evaluation
        │
        ▼
Golden Dataset
        │
        ▼
Benchmark
        │
        ▼
Regression Test
        │
        ▼
上线新版本

这也是很多成熟 Agent 团队采用的工作方式：生产环境持续沉淀真实数据，不断丰富 Benchmark，每一次版本升级都经过完整的 Regression Test，确保新版本解决了旧问题，同时不会引入新的问题。

最后一分钟总结

如果让我用一分钟总结，我会这样回答：

一个生产级的 Intent Routing 系统，并不是把意图识别出来就结束了，而是要建立一套持续优化的工程闭环。首先，通过 Trace 完整记录每一次 Routing 的决策过程，保证问题能够快速回放和定位；其次，通过 Observability 持续监控系统运行状态，及时发现异常；然后定期从线上抽样真实数据，结合人工标注或 LLM-as-a-Judge 建立离线 Evaluation，客观评估模型能力；最后维护 Golden Dataset 和 Benchmark，每次升级 Prompt 或模型都进行 Regression Test，确保系统能力持续提升而不是不断退化。我认为，一个真正优秀的 Intent Routing，不只是一次分类，而是一套能够持续演进的工程体系。

最后，用这一段结束面试

如果让我用一分钟总结，我会这样回答：

Agent 的意图识别，最基础的方案就是将所有 Intent 及其 Description 一起交给 LLM 做分类。这种方式实现简单，适合 Demo 或 Intent 数量较少的场景。

但真正的生产环境，我更倾向于采用多阶段 Intent Routing 架构：首先通过规则匹配快速处理确定性的请求；对于未命中的请求，再利用 Embedding 进行语义召回，将几十甚至上百个 Intent 缩小到少量候选；最后再交给 LLM 做精确分类，并输出 Intent、Confidence 和 Reason。对于低置信度的场景，不会让模型继续猜，而是主动发起 Clarify，与用户确认真实意图，避免错误路由。

除此之外，我还会建立完整的工程闭环。线上通过 Trace 记录整个路由决策过程，并结合 Observability 持续监控系统运行状态，及时发现异常；离线则定期基于生产环境的真实 Trace，结合人工标注或 LLM-as-a-Judge 构建 Evaluation Dataset，持续评估模型效果，并沉淀 Golden Dataset 和 Benchmark，每次升级 Prompt、Embedding 或模型版本之前，都进行完整的 Regression Test，确保系统能力持续提升，而不是不断退化。

所以，我认为 Agent 的意图识别，并不是一个简单的 Prompt Engineering 问题，而是一个集 Routing、Observability、Evaluation 和 Benchmark 于一体的工程系统设计问题。真正优秀的 Intent Routing，不只是让模型识别一次意图，而是建立一套能够持续观测、持续评测、持续优化的闭环体系。

当你回答到这里的时候，面试官听到的已经不是一个"会调用大模型 API"的人。

而是一个真正参与过 Agent 系统设计，懂得如何把一个 Intent Router 从 Demo 打磨成生产级系统的工程师。