AI Agent · 学习笔记 · 约 9 分钟

Agent 输入理解与意图识别

用户说“第二条不错，但有点贵，有没有更划算、明天能到的”，系统要完成的远不只是选一个意图标签。它需要找到“第二条”对应的商品，区分预算与偏好，识别配送要求，再把这些信息交给正确的业务流程。任何一个环节猜错，后续检索、推荐和执行都可能围绕错误目标展开。

输入理解的交付物应当是一份可核验、可更新的任务描述：用户要什么、哪些条件已经确定、哪些信息仍然缺失，以及每项判断来自哪里。

1. 先区分表达、意图和执行参数

这三个概念相关，但承担不同职责。

规范化可以修正语序、补全省略、解释术语，却不能随意补充业务事实。“更划算”不天然等于“最低价”，“最近”也必须结合任务日期确定。历史画像中的尺码和颜色偏好只能作为候选依据，不能自动变成本次购买的确定条件。

对于少量、边界清楚的业务，可以在一次模型调用中同时完成三项工作；输入复杂、需要分别评估错误时，再拆成独立步骤。拆分的价值在于职责和诊断清楚，代价是增加延迟以及步骤之间传递错误的机会。

2. 输入规范化需要两次机会

前置处理解决当前上下文能够确定的内容：根据上一轮列表消解指代，用领域词汇表解释缩写，将明确日期、金额和单位转成统一格式。保留原始输入，同时保存规范化结果；发生争议时能够回查，避免一次错误改写覆盖用户原话。

执行中的补充处理解决依赖外部信息的问题。例如“上次推荐的看樱花的地方”需要先检索历史对话，再根据地点、活动、时间等属性消歧；“同价位里最耐用”需要先获得候选产品及可比较指标，才有条件完成判断。

对常见输入问题，可以采用下面的处理顺序：

词汇表也需要治理。线上新词先作为待审核候选，记录出现范围和解释证据，再决定是否进入个人、团队或公共词汇表。出现频繁不代表含义正确；某团队的内部代号也不能因为多人提及就跨权限公开。

3. 让结构化输出保留不确定性

下面是一个假想的导购请求。假设上一轮已经确认本次配送城市为杭州、颜色偏好为深色，商品 A 的价格来自工具结果；当前用户明确要求明天送达，但并未给出最高预算。历史画像里的 M 码仍然只是待确认线索。

{
  "intent": "product_recommendation",
  "task_operation": "refine",
  "slots": {
    "reference_product_id": "product_A",
    "category": "裤装",
    "city": "杭州",
    "size": null
  },
  "sub_tasks": ["compare_value", "verify_delivery"],
  "hard_constraints": [
    {"field": "delivery_date", "op": "lte", "value": "2026-09-23", "evidence": "message_12"}
  ],
  "soft_preferences": ["优先低于参考价格", "深色优先"],
  "missing_slots": ["size", "budget_max"],
  "provisional_facts": [
    {"field": "size", "value": "M", "evidence": "profile_7"}
  ],
  "constraint_version": 3
}

日期是按该示例的请求日期及用户时区展开的；生产系统应保存解析依据。missing_slots 表示缺失项，并不等于每一项都必须立刻追问。预算缺失时可以先提供不同价位候选；尺码未确认时可以展示商品，但不能宣称“你的尺码有货”。

硬约束需要有执行校验，例如价格上限、禁止修改的文件、明确排除的品牌。软偏好参与排序；无法满足时说明取舍。用户明确说“不超过 100 元”，条件应当是 price <= 100，不能在转换时错误变成严格小于。

4. 意图分类要服务于业务路由

候选意图至少需要名称、适用边界、反例、所需槽位，以及对应流程。模型只能从当前候选中选择，代码负责校验枚举和输出结构。建议保留两个独立出口：

• unclear：现有信息不足以区分目标，适合补充证据或澄清。
• unsupported：目标已经清楚，但超出系统能力范围，适合说明边界或转交。

不要把每个要求都拆成一个意图。“查询上月数据并导出表格”可以是一个导出任务，查询是它的步骤。只有存在能够独立交付的目标时，才需要多个意图，并把依赖关系交给任务规划处理。

相近意图也不必追求语言意义上的绝对互斥。“比较商品”和“推荐商品”天然可能重叠。应先判断它们是否导致不同流程和权限；如果执行方式相同，可以合并流程，用 comparison_targets 等参数表达差异。若行为差异显著，则补充边界例子和路由优先级。

5. 分层识别是可选架构

一种常见实现是按复杂度逐级处理，而不是每次都调用最大模型。

级联适合请求量大、简单输入占比较高的系统。小型领域应用中，一次模型调用加结构校验可能更简单；额外层级也可能因为前层误判而降低质量。

不要把模型输出的 confidence: 0.9 当成真实的 90% 正确率。路由可以综合候选间距、槽位完整性、规则证据、业务后果和历史错误分布；在验证或校准集上确定阈值，再用保留测试集评估。涉及重要写操作时，意图识别正确也不能代替执行期授权。

意图也可以放进执行循环中逐步识别。这适合需要先查历史资料才能确定目标的情况，但会使分类、工具选择和任务状态互相影响。折中做法是先完成粗路由，限制可用业务域；循环获得新证据后再细化意图。在触发不同权限或副作用之前，必须完成明确的路由与条件检查，不能以“还在理解用户”为由提前执行。

6. 意图多时，先解决候选质量

候选集合过大，可以按业务域分层，或先检索相关候选，再进行精细识别。层次路由减少单次分类负担，但上层走错会排除正确分支；检索过滤节省上下文，却会受到召回率限制。因此需要“无合适候选时扩大范围”的出口，分别记录候选召回与最终分类结果。

动态 few-shot 适合放入当前容易混淆的正反例。固定部分保留拒识、澄清和输出协议，动态部分只加入相关案例。示例应来自经过标注的样本，避免把模型自己生成的错误答案循环强化。

向量相似度只能表示表达接近，不能保证意图相同。例如“退款成功了吗”和“帮我退款”很相似，却可能分别对应只读查询和写操作。高风险路由应额外检查动作、否定、时态和权限条件，不能直接凭最近邻执行。

多识别器投票和微调都是后续选项。多个模型可能犯相关错误，简单多数票不会自动提升准确率；微调也需要稳定标签、足够的高质量样本和独立评测。先修复标签重叠、上下文缺失和错误示例，通常更容易看清问题。

7. 多轮对话应更新任务，而非重新猜一遍

用户可能延续、补充、改约束、切换、取消或恢复任务。系统应同时判断业务意图与 task_operation，然后对状态做受控更新。

例如第一轮预算是 5000 元，第二轮“可以加到 8000，但不要太重”，表示预算更新与偏好新增，而非全新推荐。更新需记录新旧值及对应消息，明确冲突时以当前有效指令为准。模型的推测、检索文本中的命令，都不能自行修改用户约束。

复用上一轮意图可以降低调用量，但只适合任务状态明确的低风险路径。取消、否定和话题切换必须有独立检查；在发现方向不对之后再回滚，无法撤销已经发送、支付或删除的操作。

8. 用错误类型组织验证

一份有效测试集需要包含标准表达、口语、歧义指代、缺参、相近标签、域外请求，以及跨轮修改和取消。测试样本应包含识别时实际可见的上下文，不能只测试孤立句子。

用户说“不是这个意思”是失败线索，但不一定证明意图分类错了，也可能是检索、排序或表达问题。应回看完整链路，标注具体错误，再把样本加入回归集。

验证还需要隔离数据泄漏：同一段对话的改写句不宜分别放入训练集和测试集，线上反馈进入示例库后，也应保留未被用于调参的新样本。对“推荐还是比较”这类确实允许多种路由的表达，先标注可接受的处理结果，再决定采用单标签还是多标签口径，避免把标签争议误报成模型错误。

没有适用于所有 Agent 的统一准确率门槛。可比较的结果需要交代标签空间、样本分布、测试时间、标注规则和评估口径。只有在同样测试条件下比较改动前后，才能判断复杂机制是否值得保留。