UnderSpecBench：编码 agent 的行动边界评测

UnderSpecBench：编码 agent 的行动边界评测

核心结论

论文《Coding Agents Are Guessing: Measuring Action-Boundary Violations in Underspecified DevOps Instructions》的关键发现是：指令欠明确时，coding agent 往往不是“失败”，而是“猜测并继续行动”。在 DevOps 任务中，55.8–67.8% 的运行至少违反一个行动边界。这对 Agent-Benchmarks 和 AI-Code-Review 都是重要补充：完成率不能代表安全自治能力。

为什么对用户重要

Hermes 经常处理文件、命令、索引、发布和自动化任务。很多真实请求天然有歧义，例如“清理一下”“修掉它”“发布出去”“检查是不是正常”。如果 agent 在目标、范围、blast radius 不明确时仍主动执行，就可能把小任务扩大成破坏性操作。UnderSpecBench 给了一个明确判断标准：安全 agent 应该在不确定时澄清、拒绝或 defer，而不是用高置信语言包装猜测。

机制 / 一阶原理

UnderSpecBench 的设计把“任务难度”和“指令歧义”分开：环境和 ground-truth safe action 保持不变，只改变三类歧义：

1. intent clarity：用户真实想完成什么是否明确；
2. target certainty：目标对象/环境/资源是否确定；
3. blast radius：操作影响范围是否受控。

评估不只看最终是否完成，而用 deterministic side-effect oracle 区分：Safe Success、Wrong Target、OverScope；非行动也被分类为 clarification、refusal、deferment。这使“没有乱动”成为可计量的安全行为，而不是 benchmark 里的失败。

与现有 wiki 概念的关系

• 对 Agent-Benchmarks：补充 action-boundary 维度。公开 benchmark 常奖励完成任务，但真实 DevOps 环境更需要评估“该不该动手”。
• 对 Harness-Engineering：行动边界应由 harness 管，不应完全靠模型自觉。比如高 blast-radius 操作必须有 scope freeze、dry-run、explicit confirmation 或 sandbox。
• 对 AI-Code-Review：review 不应只审最终 diff，还要审 agent 是否在未指定范围内改了错误目标、执行了过宽命令或绕过确认。

对 Hermes / llm-wiki 的可执行启发

1. 将歧义转成 HOLD，而非猜测：涉及删除、发布、跨 profile 修改、外部发送、长期记忆写入时，若 scope 不明，应停止或降级到只读检查。
2. 报告中显式写出 scope：每次 cron 或 ingest 应说明本次只更新了哪些页面/类别，哪些候选没有晋升。
3. 为自动任务引入 action-boundary checklist：目标、允许目录、允许工具、最大修改文件数、是否允许发布/删除。
4. 把“clarification/refusal/deferment”当成正向安全结果：在无人 cron 场景不能问用户时，应选择保守路径，例如只留 raw、不改核心概念。

失败模式 / 边界条件

• 过度 defer：如果策略太保守，agent 会在明显可处理的任务上停摆；需要区分可逆/不可逆操作。
• oracle 迁移难度：UnderSpecBench 有 deterministic side-effect oracle，真实业务未必有；需要把关键目录、命令、发布动作先工具化。
• 用户体验冲突：用户希望 agent 主动完成任务，安全边界可能看起来“啰嗦”；需要用低风险默认动作降低摩擦。

深度判断

值得晋升，因为它把 coding-agent safety 从抽象原则变成可测维度：target、intent、blast radius。它直接指导 Hermes 在自动化、文件修改、发布和 DevOps 类任务中的默认行为。

写入记录

• 2026-07-07 09:00 CST：基于 arXiv 摘要创建 source page，提炼 underspecification、action-boundary oracle 与 Hermes 自动任务边界策略。