Agent 的意图识别模块如何实现？

核心回答

意图识别模块把当前请求和必要会话状态，转换成可校验的任务类型与参数，再交给后续路由。实现时我会把它分成四步：

1. 定义业务意图与边界：根据真实请求和系统能力确定类别，写清每类做什么、需要哪些字段，并保留无法识别和需要澄清的情况。
2. 选择识别方式：明确指令可以用规则；类别稳定、标注充分且延迟要求高时可以训练小模型；表达开放或冷启动时可以用 LLM 配合类别说明和 few-shot。多种方式可以组合。
3. 输出结构化结果并校验：返回意图、实体或槽位、缺失字段及下一步动作。类型、枚举和业务字段由程序检查，缺关键条件就澄清，多意图则按可执行子任务拆分。
4. 更新状态并路由：把确认过的信息写入状态，通过受控映射选择查询、检索或其他流程；后续根据工具结果继续处理，识别错误和用户纠正再回流评测。

例如“查一下布洛芬销量”可以识别为业务数据查询，但缺少时间范围时应先问清，不能直接猜时间并执行 SQL。意图识别决定用户想做什么，实际执行权限仍由工具和业务服务检查。

展开说明

1. 先确定模块的输入和输出

输入通常包括最新用户表达、当前任务阶段、已经确认的实体与参数，以及必要的近期对话。若用户说“那上个月呢”，就需要知道上一轮正在查询哪个商品和指标；如果上一轮对象尚未确定，就不应凭空补齐。历史信息也要记录来源和是否仍然有效，避免把旧任务条件带进新任务。

类别应从业务可处理的目标出发，而不只是按关键词命名。以研搜场景为例，可以区分内部业务数据查询、私有文档问答和公开资料检索，再识别用户是否要求生成报告。它们的区别是目标与数据来源；“药品”这个词本身不足以判断应该查数据库、查知识库还是查网络。

输出可以约定为以下结构，示例只说明契约：

{
  "intents": ["business_query"],
  "slots": { "product_name": "布洛芬", "metric": "销量", "period": null },
  "missing_fields": ["period"],
  "next_action": "clarify"
}

意图表示要完成的目标，槽位表示执行所需参数，next_action 表示继续、澄清或回退。后续还可以通过商品目录把名称解析成唯一对象、把时间表达规范化；不要让识别模型直接编造数据库主键或任意节点名。

2. 规则、小模型和 LLM 按约束选择

规则适合边界明确、要求高精度的控制指令或约束，例如当前任务中的取消、重置。它容易解释，但面对同义表达和复杂上下文，单纯关键词匹配容易混淆。

监督分类器适合类别相对稳定、已有足够标注数据的场景，可以训练文本分类模型，再单独或联合提取槽位。需要看各类数据覆盖和类别变化成本；新增业务类别后，仍要补数据与重新验收。

LLM 可以在输入中接收类别定义、边界说明、必要状态和代表例子，再按 Schema 输出分类与参数，适合冷启动和表达多样的任务。代价是调用延迟、费用和输出波动；结构约束解决可解析性，识别是否正确还要靠业务样本验证。

一种组合是规则处理明确控制指令，小模型处理稳定高频类别，模糊或新表达再交给 LLM；也可以直接使用一个 LLM 识别节点。是否增加多层识别，应看误判、延迟和成本，不能默认层数越多越好。

3. 缺信息、歧义和复合请求要有明确行为

缺少必填槽位时，先从可信且相关的会话状态补全，仍缺失就询问用户；可选字段可以使用已说明的默认值。例如“昨天”需要结合业务时区和当前日期解析，“查销量”还需要商品范围与统计口径。格式正确不表示这些条件已经明确。

多个意图相近时，可以给出简短澄清选项；超出系统范围则返回无法处理或交给合适入口。允许使用分类得分辅助判断，但阈值要结合验证集上的误分和拒识代价选择，不能把 LLM 自报的置信度直接当作准确概率。

复合请求需要保留目标之间的关系。例如“查上个月销量，再结合内部补货规则给出分析”，包含数据查询与文档查询。如果它们的对象和范围已明确，可以分别获取信息；若补货规则检索依赖先确定商品类别，就先完成相应步骤。不能强行把所有复合请求压成一个标签，也不应无差别启动全部分支。

4. 识别结果怎样进入后续流程

识别节点可以把意图、槽位、缺失字段和待确认状态写入工作流 State；条件边读取这些字段，从预先登记的处理器中选择下一步。需要澄清时进入对话分支，信息齐全时进入相应工具或子图。路由映射由程序控制，执行前继续检查业务条件和权限。

研搜参考代码通过专家 description 让主 Agent 判断调用哪类助手，没有单独展示一套训练好的意图分类器。若希望分类结果能单独评估和调试，可以增加上述显式识别节点；这属于一种扩展设计，不是项目已有模型训练结论。

评测时把意图识别与最终任务分开观察。前者看各类别的精确率、召回率和混淆情况，槽位是否完整正确，以及应拒识或澄清的请求有没有被直接执行；后者检查这些输出能否支撑任务完成。错误样本按类别边界、上下文缺失、实体解析和参数校验分别分析，再补数据或调整规则。

常见追问

few-shot 示例怎样选？

选择能说明类别边界的代表表达，尤其是相近意图、缺字段、无需调用和复合请求，并保持标签与字段格式一致。例如“公开药品政策”和“公司药品销量”词语接近但数据来源不同，比重复多个简单正例更能说明边界。示例用开发数据选择，最终用未参与调整的样本验证。

为什么不让主 Agent 直接决定调用哪个工具？

任务简单时可以直接决定，不必额外增加分类调用。独立意图模块适合需要稳定分类口径、多个分支复用、单独评测或更精确状态控制的场景。它提供的是可观察的中间结果，不会自动提高语义判断能力。

用户反馈说“你理解错了”，怎么处理？

先修正当前意图和相关槽位，清除不再适用的条件，再决定是否重跑后续步骤。反馈记录应保留原表达、必要上下文、原判定和修正原因，经核对后用于补充样本；不能把每条用户反馈不加判断地直接作为训练标签。

对应教程

参考资料