摘要：澄清不只是向用户追问。好的 Agent 应优先给出有用答案，并让目标、假设和范围足够可见，使用户能发现并纠正偏差。本文用一个冻结问答用例说明这一认知转变及其评测方法。
30 秒判断：如果你的 Agent 评测把“有没有追问一句”当成澄清能力，它很可能在奖励形式、惩罚真正有用的回答。本文讨论如何把这条判据改造成用户可观察、可纠正的产品行为。
适合谁读：正在设计问答 Agent、Agentic RAG、LLM Judge 或产品评测标准的工程师和产品负责人。
系列位置：本文接续 金标准不是参考答案 ,上一篇讨论 criterion 契约；本篇讨论更上游的问题：判据到底有没有对准用户价值。
代码库：lipeidonggz/ai-study-helper-v2
证据标记：✅ 项目实测；🧪 可回归；🤔 当前判断。
1. 我们一开始把“澄清”写成了“追问”
文档学习问答 Agent 经常遇到这类问题：
刚才那篇 OpenAI 的、那篇 Anthropic 的，它们对 agent 工程怎么做有什么看法？
如果会话里没有“刚才那篇”的上下文，这句话里的两个指代都没有唯一答案。于是最直接的工程判断是：
Agent 必须先问用户具体是哪两篇，不能自行选择。
这个判断看起来很自然。“澄清”在日常语言里经常等同于“追问”，评测也很容易写成：
- 回答里有没有要求用户进一步确认？
- Agent 有没有先停下来等用户补充？
- 有没有出现“请告诉我标题”之类的句子？
但它把三个不同问题混在了一起：
- 用户的问题是否有歧义；
- Agent 是否使用了有用的信息继续回答；
- Agent 是否让用户有能力发现并纠正可能错误的理解。
真正与用户体验相关的是第三个。第一个是输入属性，第二个是回答策略，只有第三个决定了：当 Agent 不得不猜测时，用户会不会被一个没有标记的猜测带到错误方向。
2. 过度追问也是一种产品缺陷
假设用户问：
帮我找一篇讲 RAG 的文章总结一下。
知识库里有十篇讲 RAG 的文章。一个“永远要求先澄清”的 Agent 会回答：
请问你想看哪一篇？
这句话没有错，却没有提供用户真正需要的东西。用户没有指定文章，通常不是不知道标题就不许回答，而是在授权 Agent 选一篇有代表性的材料。
同理：
一篇 OpenAI 的、一篇 Anthropic 的，它们怎么看 agent 工程？
也可以合理理解为“从两边各选相关材料做比较”。如果 Agent 能够选择合理的代表性文章并明确说明选了哪两篇，直接回答往往比先追问一轮更有价值。
所以，强制 Agent 在任何歧义下先追问，会产生两个问题：
- 首轮价值下降：用户明明想要一个答案，却先收到一张确认表。
- 评测目标变形：Agent 学会“多问一句最安全”，而不是学会在不确定时仍然提供高质量、可纠正的帮助。
这里需要区分两类场景 🤔：
- 学习、阅读、总结等低风险问答，适合“透明假设 + 尽量回答”；
- 删除数据、执行不可逆操作、涉及安全边界等高风险场景，仍然应该先确认。
也就是说，“不要机械追问”不是无条件的“不要澄清”。关键是判断：当前是否已经掌握足够信息，能够给出可用的回答；即使回答不够精确，用户又是否能发现并纠正。
3. “有澄清动作”仍然是一个坏指标
我们后来换了一个更接近真实问题的题面：
刚才那篇 OpenAI 的、那篇 Anthropic 的，它们对 agent 工程怎么做有什么看法？
会话里刻意不提供“刚才”的前文。此时“那篇”是真正的无效回指，不再是“允许各选一篇”的宽泛表达。
第一版金标准要求 Agent 必须先澄清，不能自行选文章比较。结果是 3/10。失败回答中，有一些直接选了两篇；另一些则先说明“当时没有足够上下文”，然后按最可能的两篇继续给出比较。
从用户视角看，后者并不是坏回答。它既提供了有用的答案，也让用户知道：
- Agent 实际采用了哪两篇；
- 这是对“刚才那篇”的推断；
- 如果指代不对，用户可以立即纠正。
于是我们试过第二个指标：
答案中是否存在澄清动作。
结果变成 6/10，但问题没有真正解决。Judge 开始围绕“最后一句算不算澄清”“没有问号但邀请纠正算不算”来回摇摆。同一批冻结答案重判时，还会出现一个样本在 pass、fail、pending 之间变化。
这不是 Judge 不够努力，而是 criterion 本身不稳定。“澄清动作”是自然语言里的形式类别，不是清晰的产品结果。
一个 Agent 可以：
- 用问句澄清；
- 用陈述句说明假设；
- 先给答案，再说明适用范围；
- 列出候选，然后选一个继续；
- 直接说明无法唯一确定，并提供修正入口。
这些行为都可以达到同一目标。如果判据只认其中一种形式，最终测到的就是话术，而不是能力。
4. 更准确的目标：让“不精确”可见、可纠正
最终我们只保留一条判据：
答案必须让用户能够判断当前回答实际采用了哪些文档，
以及如何理解“刚才那篇”。
若继续比较，必须列出实际采用的文档，并通过明确推断、
候选披露或邀请纠正中的至少一种方式，让范围可被发现。
是否提问、是否等待回复、说明放在比较前后，均不影响满足。
它对应两个产品目标：
- 尽可能精确回答：不让形式上的澄清要求阻止 Agent 使用已有信息。
- 不能精确时保持可恢复：让用户能够看到 Agent 采用了什么目标、什么假设和什么范围。
“可恢复”可以拆成两个动作：
- 可发现：用户看得出这是推断，不是已经确认的事实；
- 可纠正：用户知道实际采用了哪些文档，因此能指出“不是这两篇”。
做到这两点，Agent 不一定已经完美，但用户不会被一个不可见的假设困住。
5. 同一批 10 个答案，暴露的是判据而不是 Agent
我们用同一冻结 run 的 10 个答案做重判，没有重新运行 Agent：
- run：
run_3ddae5d9a196429bb7e1888b945d327e - Prompt：
chat-v17 - collection snapshot：15 篇文档
- N／K：10／9
不同判据下的结果如下：
| 判据 | 结果 | 主要问题 |
|---|---|---|
| 必须先澄清，不能直接比较 | 3/10 | 把透明的暂定回答误判为失败 |
| 必须存在某种澄清动作 | 6/10 | 评价开始依赖话术，Judge 抖动明显 |
| 目标可见且严格一边一篇 | 8/10 | 目标透明度改善了，但惩罚宽泛主题下的多篇综合 |
| 目标范围可见 | 10/10 | 两种回答路径都能被接受 |
这些数字不能连成“Agent 从 3/10 提升到 10/10”的能力曲线。Agent 答案没有变化，变化的只是判据。
这反而是一个更重要的评测结论：
如果连续修改判据就能显著改变结果，首先要问的不是“Agent 为什么变好了”，而是“旧判据到底在测什么”。
在评测里，指标变化并不天然代表产品变化。判据修订必须和 Agent 运行分开，否则一次“分数提升”可能只是把尺子改短了。
6. 四个样本说明：没有问句，也可以是好的澄清
样本 3：说明推断依据，末尾允许纠正
回答先说明知识库里没有直接以机构命名的对应标题，然后按作者归属确定两篇，并继续比较。末尾又列出其他候选：
如果你说的“那两篇”其实指这几篇中的某两篇，告诉我，我再按那两篇重新梳理。
它没有在回答前追问，但用户完全看得出当前选择了哪两篇，也知道怎样纠正。这比机械地问一句“请指定文章”更有信息量。
样本 8：用一句话暴露了假设
回答开头写：
你提到的两篇，我按知识库里的文档对应为……
随后直接列出两篇的标题、作者和日期。这个表达没有问号，但它清楚表明 Agent 正在做推断，而不是假装用户已经指定了这两篇。
样本 9：宽泛主题下采用一侧多篇
用户问的是“agent 工程怎么做”，而不是“解释某一篇论文”。Anthropic 一侧有三篇直接相关的文章，Agent 把它们合并成一个视图，再与 OpenAI 的比较。
这在严格的一边一篇口径下会失败，但它可能比硬选一篇更完整。重要的不是恰好几篇，而是回答明确列出了实际范围。
样本 10：多篇综合，但把范围说清楚
回答明确列出 OpenAI 和 Anthropic 两侧采用的多篇文档，并说明哪些内容用于对比、哪些只是大纲或补充。
当问题本身是宽泛主题时，多篇综合是合理策略。判据应该约束“用户是否知道范围”，而不是把“一篇”当成不可改变的数量上限。
7. 澄清能力应该和来源准确性拆开
这次调整还暴露出一个边界：目标可见不等于所有元数据都正确。
回答可能透明地列出候选，却把某篇文档的机构归属写错；也可能在综合时使用了多篇文档，但来源标签不精确。
这不应该继续塞回“澄清”判据里，因为两者解决的是不同问题：
- 目标范围可见：用户能不能发现 Agent 的理解和选择；
- 来源归属正确：文档元数据和引用是否准确。
前者是交互与评测问题，后者更适合从 list_documents trace 或 collection manifest 读取真实元数据，用确定性 checker 验证。
把所有问题都混进一个语义判据，会让 LLM Judge 同时承担语义理解、元数据查询和格式判断，最后得到一个看起来全面、实际不稳定的标准。
8. 从用户和产品出发，重写“澄清”的检查清单
设计或评审 Agent 的澄清能力时，可以先问：
- 当前信息是否足以给出有价值的最佳努力回答？
- Agent 使用的事实、对象和假设是否对用户可见？
- 用户能否发现 Agent 可能理解错了什么？
- 用户能否低成本纠正对象、范围或约束？
- 强行追问是否比透明暂定回答更有价值？
- 该场景是否高风险或不可逆，必须先确认？
- 判据是否只认一种固定话术？
- 是否把“澄清”“来源正确”“回答完整”混成了一个分数？
- 修改判据后，是否重新用冻结答案验证，而没有同时重跑 Agent？
- 用例饱和后，是否应该新增场景，而不是继续把门槛调紧？
这份清单背后的判断不是“Agent 永远不要问”，而是：
只有在不确定会显著威胁结果，或用户无法低成本恢复时，追问才应该成为主路径。
9. 边界
本文基于一个 cf-001 用例、10 个冻结答案和同模型重判，不能直接外推成所有 Agent 的规律。
- ✅ 已验证：同一批答案在四种判据下会出现不同的通过结果；
- ✅ 已验证：透明假设和可纠正范围可以通过 N=10、K=9；
- 🧪 可回归：cf-001 的新 revision 与两个 active suite 已绑定；
- 🤔 当前判断：该方法适合学习问答和低风险信息任务，不应直接套用于不可逆操作；
- 未验证：跨模型、跨知识库规模、多轮真实会话中的长期稳定性；
- 未纳入：纯候选清单中的机构归属准确性，后续应由确定性元数据检查处理。
另外，10/10 只说明当前 10 个冻结答案符合修正后的产品定义，不说明 Agent 的真实问答质量已经全面提升。一个用例也可能已经饱和；下一阶段应该增加新的失败场景，而不是继续收紧同一道题。
10. 一页速查
发现歧义
→ 先判断是否必须阻断（高风险／不可逆）
→ 否：尽量基于已有信息回答
→ 列出实际采用的文档与假设
→ 给用户发现偏差和纠正范围的入口
→ 评测“可发现 + 可纠正”
→ 用固定答案重判
→ 判据变化与 Agent 能力变化分开归因
核心判断：
澄清不是“问一句”，而是让用户在不精确发生时仍然保有控制权。
更进一步，这不是一个 Prompt 技巧，而是一个产品判断：Agent 的目标不是展示自己没有歧义，而是在真实信息不完整时，仍然尽可能有用，并且不把不确定性藏起来。
