Agent 意图识别怎么做？什么时候应该先澄清，而不是直接执行？

知识点详解：从一句话走到一次安全的工具调用

先把“意图”和“参数”分开

咱们假设系统支持查询活动、暂停活动和删除活动三类能力。

“看看上周活动的效果”，大致属于查询；“把上周那个活动关掉”，则需要进一步理解。动作可能是暂停，也可能是删除；对象还没有唯一确定。

因此，意图识别结果至少要区分三层信息：任务类型、执行需要的参数、仍然存在的歧义。不能让模型只返回一个工具名，就把问题交给工具猜。

任务类型正确，参数错误，最终仍然会操作错对象。

规则、分类器和大模型，怎么选？

任务少、表达明确时，规则容易检查，也适合处理固定指令。任务种类比较稳定但表达较多，可以训练分类器，并用真实样本检查误判。

大模型更适合处理较开放的表达，还可以结合上下文提取信息。但它不是一套权限系统。输出结构合法，只能说明格式符合要求，不能证明任务理解正确。

实际系统可以组合使用：确定的指令走明确路径，开放表达由模型解析，再由应用验证。不要为了“都是 Agent”，把固定路由也全部交给模型自由决定。

什么情况应该追问？

继续使用关闭活动的例子。系统查到三个候选活动，这时应该把能帮助用户区分的信息展示出来，问“你要暂停的是哪一个活动”。

还要确认“关掉”的含义。如果产品规定关闭就是暂停，并且这个约定在界面中清楚可见，可以按这个定义处理；没有约定，就不能擅自把关闭解释成删除。

信息缺口	合适处理
展示列表没有指定排序	使用公开、可调整的默认排序
操作对象有多个候选	提供可区分的候选，请用户选择
动作含义会改变后果	解释差别，再确认具体动作
权限不足	明确拒绝或引导申请，不能靠追问取得权限
执行结果难以撤销	参数完整后，按规则增加执行确认

澄清解决信息缺口，确认解决知情授权。这两步可以衔接，但不是一回事。

为什么不能只看模型说的置信度？

模型输出“95%”可能只是生成了一段看起来合理的文字。没有校准与评测，它不等于在这类任务上确实只有 5% 的错误率。

传统意图系统也会设置匹配阈值，例如 Dialogflow CX 的意图匹配说明。但这是该系统的匹配机制，不能把阈值照搬成任何大模型的安全许可。

更可靠的做法是检查可观测条件：对象是否唯一、必需参数是否齐全、用户是否有权限、动作是否可撤销。再用真实样本评测哪些情况容易误判，为它们设置专门的澄清规则。

问完以后，怎样继续原任务？

用户回复“第二个，先暂停就行”，系统需要把这个回答接到之前的候选列表和待完成任务上。

候选列表应该有稳定标识，不能在重新查询后把“第二个”映射成另一个活动。等待期间活动状态变化，也要在执行前重新检查。

同时，保存的是必要任务状态，不是把全部历史聊天原样塞回模型。原目标、待补参数、候选对象和已确认动作，才是恢复任务所需要的内容。

怎么检查方案有没有把用户问烦？

不要只统计意图分类准确率。还要看高风险任务有没有漏问、正常任务有没有反复追问、澄清后是否正确执行，以及用户中途取消时有没有停止操作。

可以准备一些对象重名、否定表达、改口、多意图和上下文指代的测试任务。把“能识别一个关键词”和“能完成真实任务”分开验证。

面试官继续追问

用户一次说“查一下效果，不好的就关掉”，怎么办？

先把查询与修改拆开。查询结果如何定义“不好”，需要业务规则或进一步确认。不能让模型看一眼结果，就自行决定关闭哪些活动。

用户嫌麻烦，说“你看着办”呢？

这不代表所有操作都有授权。可以在明确范围内采用默认策略，但高风险动作仍受权限、预算和确认规则限制。

模型识别错了，工具参数校验能兜底吗？

格式校验能拦住缺字段和非法值，却未必发现合法 ID 指向了错误对象。因此对象绑定、澄清和执行确认仍然重要。

面试速记卡

• 意图确定目标，参数确定对象与执行条件。
• 缺信息先澄清，高风险执行再确认。
• 权限由应用检查，不能从用户的一句话中推断。
• 自报置信度未经校准，不等于真实正确率。
• 澄清后保留稳定对象标识，执行前重新检查状态。
• 同时评测漏问、误问和任务恢复。