意图：

现在做 Agent 意图识别，很多同学上来就喜欢堆 Prompt、Few-Shot 或者 RAG。但如果复盘一下这项技术的演进史，其实有一条非常清晰的升级路线：从早期的“关键词硬匹配”，到“单句意图分类”，再到如今必须结合多轮上下文去“推理”用户的真实任务。

这种演进，本质上是被日益复杂的业务场景倒逼出来的。用户表达越来越口语化、意图标签无限膨胀、对话上下文越拉越长，系统还得兼容意图突变、多任务组合、槽位缺失和执行风控。

所以，在动手写代码选型前，建议先对自己进行四个“灵魂拷问”：

• 意图规模：标签池到底有多大？
• 迭代频率：业务标签是不是三天两头在变？
• 数据家底：手里有没有足够的高质量标注数据？
• 上下文深度：判断一次意图，到底需要回溯多少轮对话？

1：分层治理：将确定性请求拦截在推理链路之外

做 Agent 意图路由，别一上来就盲目堆 Prompt 或 RAG。在实际工程落地中，意图分类的技术路线演进，本质上是业务复杂度、数据积累量与工程维护成本三者博弈的结果。下面按落地阶段拆解不同方案的适用边界：
规则引擎：冷启动与高确定性的“定海神针”
业务刚跑起来时，关键词/正则匹配往往是最稳妥的起手式。命中“退款”、“取消订单”直接路由，推理零延迟、白盒可解释，产运同学自己就能配。适合高频、确定性极高、对风控敏感的场景。
️ 边界与代价：规则对口语化表达天然不敏感（“这单我不要了”、“地址填反了”直接漏网）。一旦叠加多意图（既要退款又要查物流），优先级冲突和维护成本会指数级爆炸。
 结论：规则只用来兜底最确定的流量，长尾表达交给模型。
传统机器学习：高并发与稳定标签的“性价比之选”
当意图体系跑稳，手里也攒了一批标注数据，就可以上 TF-IDF/FastText + LR/SVM/浅层NN。这套路子训练快、推理延迟极低，扛客服分流、工单打标、FAQ 路由等高并发场景完全没问题。
边界与代价：它吃历史数据，决策边界是学出来的。必须盯紧类别不均衡和线上长尾新词。离线刷分再高，一遇到大促、新业务上线或政策调整，泛化能力掉得很快，需要建立勤快的重训流水线。
 深度学习/预训练模型：复杂语义与联合抽取的“重型武器”
业务表达越来越野，上下文越来越长，CNN/LSTM 乃至 BERT 类预训练模型就该上场了。预训练模型能捕捉词序和深层语义，同一句“我要退了”，放在电商、机票或会员体系里，模型能打出完全不同的表征。此时可引入 Intent + Slot 联合训练，一步到位抽出结构化参数（intent=book_flight, dep=杭州, dest=北京, date=周五）。
️ 边界与代价：适合标签固定、数据粮草充足、QPS 大的核心链路。代价是重：标注成本高、训练烧卡、版本管理麻烦。标签体系一动，基本得补数据重训，迭代周期长。
向量检索与少样本学习：新意图冷启动的“敏捷方案”
遇到新业务冷启动，标签定了但样本就几十个，深度学习根本喂不饱。这时候 Embedding、原型网络（Prototypical Networks）或对比学习 是正解。核心思路是把意图映射到向量空间，同类语义拉近，异类推开。上新意图时，扔几个 seed example 就能进检索池，扩展速度极快。
 核心避坑：语义相似 ≠ 业务等价（混合架构才是正解）
这里有个极易踩的坑：语言相似度与业务动作并不总是一致。
“怎么取消订单”和“为什么订单被取消”在向量空间里可能贴得很近，但下游走的 SOP 完全两码事。因此，Embedding 的正确姿势是做粗召回（Top-K 候选），拿到候选集后，再扔给精细分类器或 LLM 做最终裁决。别指望一个向量模型包打天下，“向量召回 + 分类器/LLM 精排” 才是工业级意图路由的标准架构。
 选型前建议先摸清 4 个底
动手写代码前，建议用这 4 个问题快速对齐技术路线：
意图规模：标签池是几十个还是几千个？
迭代频率：业务标签是不是三天两头在增删改？
数据家底：手里有没有足够的高质量标注语料？
上下文依赖：判断一次意图，到底需要回溯多少轮对话？
答案清晰后，技术栈自然就能定下来，避免陷入“拿着锤子找钉子”的工程内耗。

2：告别 Prompt，高效训练 Agent

• 搞定LLM意图识别的“上下文灾难”：意图RAG两阶段实战
• 别让Prompt撑爆LLM：意图识别的两阶段RAG架构设计
• LLM意图识别避坑：如何用意图RAG缩小决策空间？

我们将系统的诊断拆解为召回与判断两个正交维度，以实现误差的快速定位：

1. 召回失效：若目标意图未进入 Top-K 候选，则属召回链路故障。此时无论后续判别模型多么强大，都属于“巧妇难为无米之炊”。

2. 判别偏差：若目标意图已被召回但判定错误，则问题通常指向意图定义的决策边界（Decision Boundary）不清、训练样本的标注噪声，或是Prompt Engineering的缺陷。

意图库的构建同样需要遵循“真实世界”的分布。除了规范定义，必须重点收录口语化表达、邻近意图（Near-intents）及对抗性样本。虽然利用 LLM 批量生成同义句有助于扩充长尾分布，但线上真实 Query始终是意图库迭代的黄金标准。

3：多轮理解中状态判断的关键技术

多轮交互的核心挑战在于上下文消歧。孤立看待“换成明天吧”这类指代不明的语句，系统将陷入严重的决策困境。

解决方案是引入对话状态跟踪（DST）机制。系统需持续维护一个包含以下字段的结构化状态机：

• Current Task：明确当前业务域（如机票/酒店）。

• Filled Slots / Missing Slots：追踪参数完备性。

• Last Tool Output：记录上一轮工具执行的客观结果。

• User Corrections：捕捉用户对系统的否定反馈。

在此架构下，意图识别不再是独立的分类任务，而是演化为一次基于事件的 State Update——即根据最新输入，对当前状态进行增量修正。

{
  "active_intent": "modify_shop",
  "intent_transition": "continue",
  "slot_updates": {
    "departure_date": "next day",
    "confidence": 0.95 // High confidence in this update
  },
  "missing_slots": [],
  "next_action": "confirm_change"
}

我们将对话进程抽象为四种核心元动作：延续（Continue）、切换（Switch）、取消（Cancel）与完成（Complete）。模型的核心职责不仅是意图分类，更是对对话生命周期（Dialogue Lifecycle）的管理。

此外，模型需具备参数级的差分识别能力，精准定位用户修正了哪些 Slot。这种细粒度的状态控制，使得 Agent 能够基于当前流程状态（Flow State）进行决策，从机制上杜绝了因意图残留（Intent Sticky）导致的上下文污染问题。

在实现上，我们不建议让 LLM 直接输出‘切换’或‘取消’这种结论。更好的做法是定义一个 System Action​ 枚举，让模型去填槽。

比如，当用户说‘算了，不订了’，模型输出的 JSON 里应该包含 {"action": "cancel_task", "task_id": "xxx"}。这样，状态管理器收到这个指令后，可以显式地将该 Task 标记为 ARCHIVED，并从 Active Memory 中剔除。这种显式状态清理机制，比单纯依赖模型‘忘记’要可靠得多。”

4：从单意图到多意图：复杂 Agent 的级联架构实战

多意图场景：一句话里的"连环套"

真实业务里，用户可不会乖乖地一次只说一件事。比如这句："查一下余额，超过一万就转五千到储蓄卡。"

拆开看，这里面藏着三层意图：

这三个动作之间还有明确的依赖关系——查不到就没法判断，判断不通过就不能执行。

这时候，传统的单标签分类直接歇菜，因为它会把整个句子硬塞进一个意图标签，任务结构全丢了。正确的输出形式应该是命令序列（Command Sequence）或者执行图（Execution Graph），把拆解后的子任务、执行顺序、条件分支、参数依赖全给表达出来。

架构演进：从"识别"到"规划"

到了这个复杂度，意图识别早就不是简单的分类问题了，它已经演化成语义解析 + 任务拆解 + 执行规划的复合体。模型不仅要理解用户到底想干啥，还得：

• 确定动作的先后顺序
• 理清参数之间的依赖关系
• 识别出哪些是高风险步骤需要二次确认
• 处理多轮对话中的状态跟踪

生产落地：级联架构才是王道

在真实的生产环境里，指望一个模型包打天下是不现实的。成熟的方案都是级联架构（Cascade Architecture），让不同技术栈各管一摊：

关键细节：每一层都要留后路

这个级联架构里，每一层都必须具备三个能力：

1. 拒识（Reject）：搞不定就往下游丢，别硬扛
2. 追问（Clarification）：参数缺失或歧义时，主动找用户要信息
3. 升级（Escalation）：置信度太低时，转人工或触发更高级的模型

别小看这三个机制，它们决定了整个系统的鲁棒性。单层模型准确率再高，没有这些兜底机制，上线后照样会被各种 corner case 搞崩。

搞意图识别，千万别一上来就堆大模型，那是土豪的做法。我们这套级联架构，核心逻辑就是“能省则省”。简单的活儿让规则和小模型干，搞不定的再惊动大模型。最爽的是，每层都能单独调参、回滚，加新意图也就是改改路由表，不用全量重训。

不过，有个坑必须填上：权限隔离。以前出过事故，模型理解了“删除数据”的指令，就直接调用了删除接口。后来我们学乖了，把流程切成三段：意图层（想干嘛）、权限层（能不能干）、执行层（何时干）。查天气这种无伤大雅的直接过，涉及钱（转账）、涉及命（删库）、涉及对外发声的，必须校验身份，甚至搞二次确认。千万别让模型觉得“我懂你意思=我有权执行”。

对外接口我们也收敛成了四个：直接执行、追问细节、直接拒绝、请求确认。逻辑清晰，边界明确。

评判系统好坏，别盯着 Accuracy 自嗨。我们盯的指标细得很：

• 类别不平衡？看 Macro-F1。

• 意图长得太像？看混淆矩阵。

• 召回够不够宽？看 Recall@K。

• 参数抽得准不准？看字段级 F1。

• 多轮对话跟不跟得住？看状态转移准确率。

• 线上跑得稳不稳？看拒识率、追问率、工具成功率。

• 用户体验好不好？看端到端完成率、延迟和成本。

现在的系统，得像老司机开车，知道什么时候踩油门（执行），什么时候踩刹车（追问/拒识），什么时候换车道（升级模型）。越是复杂的系统，越要对“拿不准”的事情保持敬畏。

归根结底，

这套架构的演进就是一个责任下放的过程：规则管死（确定性），分类器管熟（高频），Embedding 管搜（粗排），LLM 管难（语义），RAG 管新（知识），状态机管长（上下文），规划器管繁（拆解）。意图识别做得稳，靠的是这套班子的默契配合，而不是某一个明星模型的单打独斗。