导语：在之前的文章中，我们搞懂了 RAG 的基础（文本向量化）和 Agent 的通信协议（MCP）。但真正在企业落地 Agent 时，你马上会面临一个极其现实的问题：用户提的每一句话，都要去查知识库吗？
显然不是。用户可能会问天气（工具调用）、会闲聊（直接回复）、或者问题太模糊需要补充（引导澄清）。
今天这篇笔记，我们就来聊聊 Agent 的“前台接待员”——意图识别（Intent Recognition）与路由调度（Routing），看看如何让 Agent 聪明地判断用户到底想干嘛。
一、 拆解需求：四种核心意图类型
在构建 Agent 时，我们首先要对用户的输入进行归类。通常，我们会把意图分为以下四种：
1. 知识检索（Knowledge Retrieval）
- 适用场景：用户询问已经沉淀在文档里的内容。
- 处理方式：走完整的 RAG 检索流程（Query 改写 → 向量检索 → 重排序 → 生成答案）。
2. 工具调用（Tool Calling）
- 适用场景：用户需要获取实时数据或执行操作。
- 处理方式：走 Function Call 或 MCP 流程（识别工具 → 传入参数 → 执行工具 → 结合结果生成答案）。
- 💡 小白的经典疑问：怎么区分“知识检索”和“工具调用”？
- 关键看答案的来源！
- 如果答案躺在你的文档库里，属于静态知识（如：退货政策是什么？保修期多久？），那就是知识检索。
- 如果答案需要查数据库、调 API 才能拿到，属于动态数据（如：我的订单到哪了？我年假还剩几天？现在库存有多少？），那就是工具调用。
3. 闲聊对话（Chit-Chat）
- 适用场景：用户说“你好”、“你真聪明”等。
- 处理方式：不需要检索，也不需要调工具，模型直接回答即可。
4. 引导澄清（Clarification）
- 适用场景：用户的指令太模糊，比如“我要退款”，但没说是哪个订单。
- 处理方式：既不检索也不调用工具，直接返回一个引导性的问题，让用户补充关键信息。
二、 技术选型：意图识别的三种方案
判断用户意图，技术上通常有三种做法，适合不同的发展阶段。
方案一：规则匹配（第一层快速过滤）
- 原理：用关键词和正则表达式判断意图。
- 优点：速度极快，零成本。
- 缺点：死板，容易误判，无法处理复杂的语义。
- 定位：适合作为第一层过滤，拦住那些意图极其明显的提问。
方案二：大模型分类（核心主力）
-
原理：把用户的输入交给大模型（配合设计好的分类 Prompt），让大模型返回分类结果。
-
Prompt 设计的 4 个核心要点：
- 明确定义与示例：每种意图都必须有清晰的定义和 Few-shot（少样本）示例。
- 强调结合对话历史：比如用户上一句问“北京天气”，下一句问“那上海呢？” 模型必须结合历史才能识别出“工具调用”意图。
- 强制输出 JSON 格式：方便后续代码解析。
- 谨慎使用 Clarification（澄清）：大模型很容易过度使用“澄清”，导致用户体验变差。
-
🔥 边界情况处理（生产环境极其重要）：
- 结合历史：用户的提问往往依赖上下文，必须让大模型带着对话历史去判断。
- 数量问题：比如问“今年卖了多少件？”，如果有对应 API 就是工具调用，如果没有 API 必须查报表文档，那就是知识检索。
- 操作指令：有些用户的回复是确认执行操作（如“确认退货”），这不是传统的获取知识，必须识别为工具调用。
- 多意图问题：一句话包含多个意图（如“帮我查下订单，再告诉我怎么退货”）。此时可以取主要意图，或者进行拆分分别处理。
方案三：混合方案（生产推荐）
- 原理：规则判断做第一层快速过滤，大模型做第二层精确分类。
- 细节：第一层规则匹配时，可以引入**置信度（Confidence）**机制，置信度不够的交给大模型兜底。
三、 架构设计：问题路由与链路位置
1. 路由器模式（Router Pattern）
意图识别（Classifier）拿到结果后，交给路由器（Router）。路由器的职责就是像交警一样，把请求分发给对应的处理器（Handler）。
- 每个处理器（知识检索、工具调用等）只负责自己的逻辑，互不干扰。
2. 意图识别在 RAG 链路中的位置
理论上，意图识别应该在会话记忆之后、Query 改写之前。
- 为什么在 Query 改写之前？ 因为 Query 改写会消耗资源和时间，只有在确认需要做“知识检索”时，才值得去改写。
- ⚠️ 实战经验（Ragent 的做法）：在实际落地 Ragent 时，往往还是选择**“问题重写在前”**。因为生产环境中，95% 以上的问题都是基于知识库问答。为了优化这 95% 的绝大多数体验，宁愿先重写，再分类。
四、 避坑指南：生产环境的注意事项
纸上得来终觉浅，真实的生产环境往往更复杂。以下三点是必须注意的：
1. 意图分类的准确率监控
不监控的系统等于在黑盒子里开车。你需要监控：
- 分类准确率：整体对不对？
- 各意图的分布比例：如果“闲聊”比例突然飙升，是不是系统被恶意攻击了？
- 误分类的典型案例：收集 Bad Case，反哺到 Prompt 优化中。
- 规则层命中率：规则写得好不好用？
2. 兜底策略（Fallback）
如果大模型没有给出明确结果，或者分类失败了怎么办？
- 默认走知识检索。因为大部分业务场景都是知识问答，走 RAG 至少能给出一点相关信息，总比直接报错好。
3. 意图边界的动态调整（配置化）
意图体系不是一成不变的。
- 前期：四类（知识检索、工具调用、闲聊、澄清）。
- 中期：加入 complain（投诉）、urgent（紧急）等细分类别。
- 后期：不同产品线可能有自己的意图体系（如电商和医疗完全不同）。
- 💡 最佳实践：把意图分类体系做成配置化（Config-driven）。新增意图时，直接修改配置文档或数据库，不需要改动代码逻辑。
总结
意图识别与路由调度，是 Agent 从“玩具”走向“工程”的第一步。一个优秀的架构，应该是“规则过滤 + 大模型兜底”的混合方案，配合灵活的配置化和严密的监控机制。
掌握了这些，你的 Agent 才算真正懂得了“察言观色”，能准确地把问题分发给对的处理器了。
下一篇，我们继续深入 Agent 内部，看看那些复杂的工具（Tools）是如何被调用的。我们下期见！
系列文章推荐： 0基础小白系统学习agent系列之MCP(1) 0基础小白系统学习agent系列之文本向量化 0基础小白系统学习agent系列之意图识别与路由调度（本篇）
觉得有帮助的小伙伴，记得点赞、收藏、加关注，你的支持是我持续更新的最大动力！
