HiL-Bench：Agent 知道什么时候该问人吗？

HiL-Bench：Agent 知道什么时候该问人吗？

🧠 核心问题

前沿 Coding Agent 在给定完整上下文时表现很强，但当 specification 不完整或有歧义时，就崩了。瓶颈不是 raw capability（能力），而是 judgment（判断力）——知道什么时候该自主行动、什么时候该问人。

当前的 benchmark 对这个失败模式是「盲的」：它们给的指令都是明确详细的，只奖励执行正确性。一个靠猜蒙对了 requirement 的 agent，和一个会主动确认的 agent，得分一样。这掩盖了 agent 在真实场景中的核心缺陷。

📊 关键数据

• GPT-OSS 120B 在空间推理任务上只有 16%，人类 98%——巨大差距
• 没有一个 frontier model 在「该不该问」的判断上能恢复 full-information 性能的大部分
• RL 训练有效：32B 模型通过 Ask-F1 reward shaping 后，help-seeking 质量和任务通过率都提升，且 gains 跨域迁移

🏗️ Benchmark 设计：HiL-Bench

HiL-Bench 的核心设计思想：每个任务包含 human-validated blockers（缺失信息、歧义请求、矛盾信息），这些 blockers 只能通过 progressive exploration 发现，不能通过 upfront inspection 看出来。这模拟了真实工作场景——你不知道自己不知道什么。

核心指标：Ask-F1

Ask-F1 = Question Precision 和 Blocker Recall 的调和均值。

• Question Precision：问的问题是否有针对性（vs 随便乱问）
• Blocker Recall：是否覆盖了所有需要确认的 blockers

这个指标的设计精妙之处：架构上防止了通过 spam 问题来刷分——问太多没用的问题会拉低 precision。

🚨 三大失败模式

1. 过度自信猜错（Overconfident Wrong Beliefs）

Agent 根本没检测到自己有知识缺口——它觉得自己什么都知道，直接猜了一个答案，还猜错了。这是最危险的失败模式，因为用户根本不知道 agent 在猜。

2. 感知到不确定但还是硬干（Uncertainty Detected, Action Ignored）

Agent 内部其实检测到了不确定性（比如 high entropy / 矛盾信号），但没有把这种不确定性转化为求助行为，而是继续硬干。问题不在「感知」，在「行动」。

3. 问了一堆没用的问题（Broad Imprecise Escalation）

Agent 确实问了问题，但问题太宽泛、不精确，没有针对具体的 blocker。比如把所有不确定的参数都列出来问用户，而不是先分析哪些是真正需要确认的。

🔑 关键洞察

🤔 引发思考

这篇论文揭示了一个被当前 Agent 评估体系系统性忽视的问题。我们一直在问「Agent 能力有多强」，但更重要的问题是「Agent 知道自己有多强」。

• 对 Coding Agent 的启示：SWE-bench 等 benchmark 给的 spec 是完整的，但真实需求往往是模糊的。一个在 SWE-bench 上 60% 的 agent，面对真实模糊需求可能只有 20%——不是因为不会写代码，而是因为不知道该问什么
• 对 Agent 产品设计的启示：必须在 agent workflow 中设计「求助入口」——不是 fallback（失败后求助），而是 proactive escalation（在失败前主动求助）
• 对训练的启示：Ask-F1 reward shaping 证明了 judgment 是可训练的。未来的 Agent training 应该包含「不确定性检测 + 求助决策」作为标准训练目标

逍遥云初 | 2026.04.13