同样是智能体两类失败在客服场景里反复出现。一类是该问的时候不问用户只说了帮我查一下订单既没给订单号也没给时间范围智能体不追问直接挑了一个最近的订单把物流信息念出来用户一看根本不是自己要查的那笔。另一类是不该问的时候反复问用户已经明确说出要退货智能体还在追问请问您是换货还是维修把一次简单操作拖成了好几轮。两类失败的用户体验都差但团队排查时往往把它们当成两个互不相关的问题分别处理。这两类失败看似相反根源其实是同一个缺少一套判断信息是否足够、该不该澄清的标准。智能体在面对模糊需求时要么把缺失信息默认填上一个猜测值要么对已经明确的信息再次确认。澄清策略缺位智能体的提问就变成了随机动作问不问、问什么、问几轮都没有确定的规则可循。团队事后复盘时也往往只能归因于模型理解能力不够而看不到真正的问题是澄清这个环节没有设计。澄清没设计好损失的不只是这一次对话的准确率还有用户对智能体的信任用户被追问两次之后下次更倾向于直接转人工。一类原因是缺少澄清触发判定。系统没有定义什么情况下需要向用户提问判断依据应该是任务执行所必需的信息是否齐全而不是凭模型的临时判断。订单查询需要订单号或收货人退换货处理需要确认退货还是换货这些必需字段如果没有预先定义智能体就无法可靠地判断当前信息够不够。没有判定标准模型就只能靠概率去猜猜错的代价就是要么硬着头皮给一个错误答案要么问一个用户已经回答过的问题。另一类原因是缺失信息没有结构化。用户表达里缺什么、缺几项、每项对应哪个字段如果没有被显式地识别出来澄清提问就只能笼统地说请提供更多信息。用户不知道到底要补什么智能体也不知道拿到信息后该填到哪里一轮澄清往往不够于是只能再来一轮。如果字段定义清晰一轮澄清就能把信息补齐字段定义缺失同样的信息往往要来回好几轮。还有一类原因是澄清没有次数上限和兜底。智能体反复追问会把简单问题拖成多轮对话用户在第三轮之后通常就放弃了。如果澄清失败后没有兜底路径比如给出基于默认条件的回答并明确标注假设用户就只能卡在提问循环里既得不到结果也退不出去。澄清是需要成本的每一次追问都在消耗用户的耐心没有上限的澄清本质上是在用体验换准确性。这类问题在青山不语AI工作室的部分企业AI应用定制项目方案中被归纳为澄清策略与缺失信息结构化整个处理流程分为四个环节。起始环节是澄清触发判定。系统为每类任务定义必需字段和可选字段用户请求进入后先做字段提取判断必需字段是否齐全。齐全则直接执行不齐全则进入澄清流程。判断由规则和字段表驱动模型不自行决定是否需要澄清。澄清触发判定的输出不只是该不该问还包括缺了哪些字段、缺的是哪几项为下一步的缺失信息结构化提供输入。字段表的维护跟着业务走新增一个业务动作就同步补充这个动作对应的必需字段。接下来是缺失信息结构化。系统把缺失的字段、字段类型、候选值范围整理成结构化的澄清项逐项列出。这样澄清提问不再是笼统的请补充信息而是指向具体的缺口比如请提供订单号或者请确认退货还是换货。结构化之后缺失信息从一句模糊的话变成了一组明确的字段后续的提问生成和用户补充都能对着这个清单来不会再出现补了信息却填不对位置的情况。再往后是澄清提问生成。系统按缺失字段的重要程度和依赖顺序把澄清项组织成不超过一轮可以说完的问题。一次澄清尽量覆盖全部缺口避免用户答一项又被追问下一项。对于有候选值范围的字段直接把选项列出来让用户选择减少用户输入成本。提问的措辞由模板生成同一个字段的澄清表述保持一致用户看多了能形成一致的预期。最后是澄清次数上限与兜底。系统设置澄清轮次上限达到上限仍未补齐必需字段时不再继续追问而是给出基于默认假设的回答并在回答开头明确标注以下结果基于某某假设。用户不满意时可以自行补充信息重新查询。这样既避免了无限追问也避免了用户卡在提问循环里让用户始终能拿到一个可用的结果。各任务的必需字段和候选值范围由业务团队定义业务规则变化时需要同步更新。澄清触发和字段提取的逻辑由工程团队实现。澄清提问的措辞模板由业务或运营团队维护。如果智能体需要跨系统查询字段定义还要和下游系统的接口字段对齐避免澄清出来的信息拿到下游却用不上。智能体本身不参与澄清判定它只根据结构化后的缺失信息生成提问并处理用户补充的信息。澄清策略看起来只是对话体验的细节实际上决定了智能体在模糊需求下是靠谱还是添乱。把该不该问交给模型结果往往在两个极端之间摇摆。我更倾向于把澄清当成一条确定的流程必需字段驱动、有次数上限、有兜底路径。这样智能体既不会在信息不足时硬猜也不会在信息充足时反复确认用户的操作路径会顺畅得多。