Agent 什么时候追问用户 vs 自己推理

P1 · agent_architecture · 🏢 腾讯

🏷 标签：agent, clarification, reasoning, human-in-loop

1️⃣ 考察意图

面试官想看你是否理解 Agent 决策中“人机交互”与“自主推理”的边界设计，而非单纯背概念。考察类型是系统设计 + 工程取舍。刁钻点在于：追问不是技术缺陷，而是设计选择；答好了能展示你对不确定性管理、用户意图建模、成本-延迟-准确率三角权衡的硬实力。核心是：何时把决策权交给用户，何时靠模型内部推理完整流程，背后是信息熵阈值和风险容忍度的工程判断。

2️⃣ 标准答

Agent 追问 vs 自己推理的决策，本质是在不确定性下选择最小化用户认知负担的路径。我按三个维度拆解：信息缺失类型、置信度阈值、上下文成本。

信息缺失类型决定是否可推理****歧义性缺失（如用户说“帮我查下那个文件”）：若 Agent 有足够上下文（如历史对话中提过“上周的周报”），应优先推理，用 LLM 的隐式消歧（如通过 embedding 相似度匹配最近提及）。坑：推理错误会误导用户，需加置信度校准——比如推理结果概率 < 0.7 时转为追问。
关键参数缺失（如“订机票”但没给日期）：必须追问，因为推理会引入幻觉风险。解法：用 slot-filling 框架（如 JSON schema 定义必填字段），缺失时触发追问模板，而非让 LLM 自由生成。
意图模糊（如“帮我优化一下”）：优先追问，因为优化目标（速度/成本/可读性）是用户主观偏好，模型无法合理假设。实际落地：用多轮澄清树（clarification tree），先问“优化哪个维度？”，再根据回答缩小范围。置信度阈值驱动决策
设一个动态阈值：当 Agent 对推理结果的置信度（如 logit 概率均值或自洽性分数）低于 0.6 时追问，高于 0.8 时直接执行。中间区间（0.6-0.8）用反问确认（如“我猜你想查张三的合同，对吗？”），而非开放追问。
工程取舍：低阈值（如 0.4）减少追问但增加错误率，高阈值（如 0.9）降低错误但用户烦。实际项目（如客服 Agent）中，我们根据业务风险调阈值：高风险操作（如转账）阈值设 0.95，低风险（如查天气）设 0.5。
坑：置信度不可靠（LLM 可能过度自信）。解法：用自洽性检查（sampling 3-5 次，看答案一致性），或加外部验证（如调用 API 确认数据是否存在）。上下文成本与用户耐心
追问有交互成本：每次追问增加 2-5 秒延迟，用户耐心通常 < 3 轮。因此，对高频场景（如“查订单”）预定义默认行为（如“查最近订单”），而非每次都问。
推理有计算成本：LLM 推理比追问模板贵 10-100 倍（取决于模型大小）。所以，对简单缺失（如“那个”指代），用轻量级规则引擎（如正则匹配历史实体）先试，失败再走 LLM 推理。
实际落地：在 Agent 中嵌入成本预算器，当推理 token 消耗 > 阈值（如 500 tokens）时，强制转为追问，避免无限推理。

总结：追问是显式降噪，推理是隐式假设。设计时需根据业务风险、用户意图明确度、交互成本画决策边界，并用置信度阈值 + 规则兜底做动态切换。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从三个层面回答：第一，信息缺失类型——关键参数缺失必须追问，歧义性缺失可推理但需置信度校准；第二，置信度阈值——设动态阈值（如 0.6-0.8），高风险场景调高，低风险调低，并用自洽性检查防过度自信；第三，上下文成本——追问有交互成本，推理有计算成本，用规则引擎兜底高频场景。总结一句：追问和推理不是对立，而是根据不确定性、风险、成本动态切换的工程决策。”

4️⃣ 高频追问 & 应对

追问 1：如果用户说“随便”，你怎么处理？是追问还是推理？

这是典型的高不确定性场景。我会先检查上下文：如果历史有明确偏好（如用户之前总选“最快方案”），则推理并加反问确认（“我猜你选最快方案，对吗？”）；如果无上下文，则追问但限制选项（如“选速度优先还是成本优先？”），而非开放提问。工程上，对“随便”这类模糊词，预定义默认策略（如“推荐 Top-1 并解释原因”），减少用户决策负担。

追问 2：你怎么评估追问策略的效果？用什么指标？

核心指标是任务完成率和用户满意度。具体：① 追问轮次：理想 < 2 轮/任务，超 3 轮说明策略过保守；② 推理错误率：用户纠正次数 / 总推理次数，目标 < 5%；③ 用户放弃率：追问后用户离开的比例，高说明追问太烦。A/B 测试时，对比不同阈值（如 0.6 vs 0.8）对完成率的影响，找到 Pareto 最优。

追问 3：如果 Agent 推理错了，用户纠正后，怎么避免下次再犯？

用在线学习或记忆机制。简单方案：在 session 内缓存用户纠正的映射（如“那个文件”->“合同.pdf”），后续同 session 直接复用。复杂方案：用用户画像记录偏好（如“用户总选速度优先”），下次推理时加权。注意：不要过度泛化，避免把一次纠正当成永久规则，需设遗忘机制（如 24 小时后重置）。

5️⃣ 避坑 · 常见错误答法

❌ “Agent 应该尽量自己推理，减少追问，因为追问用户体验差。” → ✅ “追问不是坏事，而是显式确认。关键是区分场景：高风险操作（如转账）必须追问，低风险（如查天气）可推理。盲目减少追问会导致错误率飙升，反而更差。”
❌ “用 LLM 的置信度分数直接判断是否追问。” → ✅ “LLM 置信度不可靠，需结合自洽性检查（多次采样）或外部验证（如 API 返回码）。例如，用 3 次采样，若答案一致率 < 60%，则触发追问。”
❌ “追问时让用户自由输入。” → ✅ “开放追问增加用户认知负担。应设计结构化追问（如选项列表或 slot-filling 表单），例如‘请选择：A. 速度优先 B. 成本优先’，而非‘你想怎么优化？’。”

6️⃣ 简历呼应

如果你有 RAG 项目：从“用户查询消歧”切入，展示你如何用置信度阈值（如 embedding 相似度 < 0.7 时追问）处理模糊查询，并提一个实际坑（如用户说“那个”时，用历史对话实体匹配而非 LLM 推理）。
如果你只做过传统 NLP：用“意图分类 + slot-filling”类比，说明追问是缺失 slot 的显式填充，推理是隐式填充（如用 BERT 做指代消解）。强调传统方法（规则）和 LLM 方法的取舍。
如果你是校招无项目：聚焦论文复现，如引用《WebGPT》中“clarification vs. direct answer”的设计，或《ReAct》中“推理-行动-观察”循环里追问的触发条件。展示你对决策边界的理论理解。

7️⃣ 延伸阅读

《WebGPT: Browser-assisted question-answering with human feedback》—— 追问策略的经典设计
《ReAct: Synergizing Reasoning and Acting in Language Models》—— 推理-行动循环中的不确定性处理
《Toolformer: Language Models Can Teach Themselves to Use Tools》—— 工具调用中的追问触发
《Self-Consistency Improves Chain of Thought Reasoning in Language Models》—— 自洽性检查用于置信度评估
《The Unreliability of LLM Confidence Scores》—— 置信度校准的工程实践

—— 本场面试完 ——