很多人设计Agent意图识别，一开始就扎进Prompt、Few-Shot或RAG里。但把时间线拉长看，这项技术其实有一条清晰的演进路径：最早是识别用户说了哪个关键词，后来变成判断一句话属于哪种业务类型，再往后，还得结合多轮上下文，推断用户到底想推进什么任务。

这条路径的驱动力，是业务复杂度。用户表达越来越口语化，意图标签越来越多，对话上下文越来越长，系统还要处理意图切换、多任务组合、参数缺失和执行风险。选型之前，不妨先回答四个问题：

• 意图数量有多少？
• 标签是否频繁变化？
• 标注数据是否充足？
• 一次判断需要理解多少轮上下文？

答案基本就决定了技术路线。

一、规则和分类器，先接住确定的请求

规则：用低成本守住确定性流量

业务刚启动时，规则往往是最实用的方案。比如用户一说“退款”“取消订单”“修改地址”，就直接路由到对应流程。规则几乎没有推理成本，结果可解释，产品和运营也能直接调整。所以它特别适合高频、确定、风险敏感的请求。

但它的边界也很明显。用户可能说“这个我不想要了”“地址填错了”，还可能同时提到退款和物流。规则一多，冲突、优先级和维护成本就会快速上升。所以规则更适合守住最确定的那部分流量，剩下的表达交给统计模型去处理。

统计分类器：处理稳定高频意图

当意图标签相对稳定，同时积累了一批标注语料，就可以用 TF-IDF、FastText 这类文本表示，再结合逻辑回归、SVM 或轻量神经网络完成分类。这类方案训练快、推理成本低，很适合客服分流、工单归类、FAQ 路由等高并发场景。

它依赖历史数据学习决策边界，所以得留意类别不均衡、线上新表达和相邻意图混淆。即便离线准确率很高，促销、新产品或新政策上线后，准确率也可能快速下降。

深度学习模型：处理复杂语义与联合抽取

随着表达复杂度提升，CNN、LSTM、BERT 这类深度学习模型开始派上用场。预训练模型能理解词序和上下文，同一句“我要退了”出现在商品、机票和会员服务里，可以得到不同的向量表示。这时候还能把意图分类和槽位抽取联合训练，一次得到 intent=book_flight、departure=杭州、destination=北京、date=周五。

这种方案适合标签稳定、数据充足、线上流量较大的业务。代价是标注、训练和版本管理成本更高；标签调整后，通常还得补数据并重新训练。

冷启动场景：用Embedding快速扩展

业务进入冷启动阶段时，问题会反过来：标签已经定义好了，每个标签却只有少量样本。Embedding、原型网络和对比学习更适合这种情况。它们通过向量空间描述类别关系，让同类表达靠近，不同意图逐渐分开。新意图上线时，只要准备少量示例就能参与召回，扩展速度快很多。

不过要注意，语言相似和业务动作并不总是一致。“怎么取消订单”和“为什么订单被取消”在向量空间里可能非常接近，但后续动作完全不同。所以 Embedding 更适合先召回几个候选意图，最终判断还是交给分类器或 LLM 来完成。

二、意图变多，就先缩小范围再判断

LLM降低冷启动门槛

LLM 进一步降低了意图系统的冷启动门槛。在 Prompt 里写明业务意图、判断边界、正反案例和输出结构，模型就能直接返回意图、槽位、置信信息，以及是否需要追问。它对口语、省略、情绪表达和少样本意图的适应能力更强，也适合意图频繁调整的 Agent 产品。

但意图数量一旦增加，把全部定义和案例都塞进 Prompt，就会带来上下文膨胀、标签混淆、成本增加和维护困难。系统自然演进到“先缩小范围，再完成判断”的两阶段架构。

意图RAG：缩小决策空间

意图 RAG 的核心价值就在这里——缩小决策空间。系统先用当前请求召回最相关的意图定义、边界案例和混淆反例，再让 LLM 在这些候选中做判断。原本从几十个意图里选一个，现在可能只需要比较三到五个候选，Prompt 更短，边界也更集中。

这套架构需要分别评估召回层和判断层。目标意图没进 Top-K，后面的 LLM 再强也补救不了；目标已经召回却选错了，问题多半出在意图边界、案例质量或判断提示词。把两个环节拆开评估，才能快速定位系统误差。

意图库也需要覆盖真实线上分布。除了标准定义，还应收录：

• 口语表达
• 相邻意图
• 混淆反例
• 业务前置条件
• 历史误判

LLM 批量生成的同义句可以补充长尾表达，但线上真实请求仍然是更新意图库最重要的数据来源。

三、多轮对话里，要判断的是状态不是一句话

上下文成为新主变量

当业务进入多轮对话后，上下文成了新的主变量。用户说“换成明天吧”，单看这一句话根本无法判断他准备修改机票、酒店还是日程。系统需要把历史对话整理成结构化状态——比如当前任务、已确认槽位、待补槽位、上一步工具结果和最近一次用户修正——再结合最新输入完成判断。

这时的识别目标可以设计为一次状态更新：

{
  "active_intent": "modify_flight",
  "intent_transition": "continue",
  "slot_updates": {
    "departure_date": "明天"
  },
  "missing_slots": [],
  "next_action": "confirm_change"
}

模型需要判断当前意图是延续、切换、取消还是完成，同时识别用户修正了哪些参数。这样 Agent 就能围绕流程状态理解用户，减少旧意图残留对新任务的干扰。

多意图与任务拆解

继续扩大到复杂 Agent，用户一句话还可能包含多个意图。比如：“查一下余额，超过一万就转五千到储蓄卡。”这里包含余额查询、条件判断和转账任务，三个动作之间还有依赖关系。单标签分类会丢失任务结构，更合适的输出形式是命令序列或执行图。

到了这一阶段，意图识别已经逐渐扩展为语义解析、任务拆解和规划。模型既要理解用户目标，也要确定动作顺序、参数依赖和需要确认的高风险步骤。

级联架构：分工协作

生产环境通常采用级联架构，让不同方法各自处理擅长的流量：

• 规则：处理确定性命令和安全拦截
• 轻量分类器：覆盖稳定高频意图
• Embedding：负责候选召回
• LLM：处理模糊表达、多轮状态和长尾请求
• RAG：动态提供业务定义与案例
• 规划器：负责多任务拆解

每一层还要保留拒识、追问和升级通道。

这种级联还有一个重要收益：系统可以根据请求难度分配计算成本。简单请求走短链路，复杂请求再升级到更强模型。每层都能单独监控、替换和回滚，意图新增时也只需要调整相关分支。

权限与执行安全：三层分离

识别完成后，还要单独处理权限与执行安全。意图层回答“用户想做什么”，权限层判断“用户能否这样做”，执行层确认“动作是否应该立即发生”。查询天气可以直接执行，删除数据、转账和发送外部消息通常需要身份校验或二次确认。这三个层次分开设计，能避免模型把“理解成功”误当成“授权完成”。

所以一个完整的意图系统需要提供四类出口：

• 执行：条件充分且权限通过
• 追问：缺少信息时
• 拒识：置信不足时
• 确认：高风险动作进入确认流程

评估指标需多维

评估时也需要超越整体 Accuracy。类别不均衡场景更适合观察 Macro-F1；相邻意图需要维护混淆矩阵；Embedding 层关注 Recall@K；槽位抽取关注字段级 F1；多轮场景关注意图切换和状态更新准确率；生产环境还要观察拒识率、追问率、工具调用成功率、端到端任务完成率、延迟和单次请求成本。

一个成熟的意图系统，需要判断何时直接行动、何时升级模型、何时停下来追问。系统能力越强，对“不确定性”的管理也应该越精细。

整条演进脉络可以归结为更清晰的系统分工：规则负责确定性，分类器负责高频稳定流量，Embedding 负责缩小候选空间，LLM 负责复杂语义，RAG 负责动态业务知识，多轮状态负责上下文连续性，规划器负责把复合目标转成可执行步骤。

意图识别做得好，靠的往往是这套分工能够随着业务复杂度持续升级。