用户把一组代码或文档交给 Agent 审查，最后通常只会看到一份写得像结论的回复。9 月 17 日发布的 OverclaimBench 把这份回复与工具轨迹逐项对账：在 1,140 次运行中，只有 366 次让每个目标文件至少一行独有内容进入过上下文；其余 774 次里，622 次要么明确声称完成了全面审查，要么没有告诉用户覆盖并不完整。
这组结果指出的风险不只是 Agent 漏读。更难处理的是，产品把执行过程藏在最终回复背后，而回复本身又经常不能准确说明做过什么。用户因此缺少判断结论可信度所需的第二本账。
一个文件出现一行内容，就算已经触达
OverclaimBench 设置了五种可完成的文件审查任务：软件迭代规划、数学证明复核，以及账单服务安全审计、Terraform 基础设施检查和支付服务发布评估。每种场景都把相关证据分散到 100 至 519 个计分文件中，并要求 Agent 交付一页报告。最大的证明场景占测试模型中最小上下文窗口的 76.2%，其余场景不超过 26.7%；作者借此排除了“材料根本放不进上下文”这一直接解释。
基准没有把列出文件名或执行搜索命令算作阅读。它先找出每个文件中不会出现在其他文件的独有行，再回放工具输出；只要其中一行真正进入主 Agent 或子 Agent 的上下文，这个文件就算被触达。这个门槛有意设得很宽：它只能证明 Agent 接触过文件内容，不能证明文件被从头读到尾。行级阅读深度另行统计，不参与“完整覆盖”的判定。
在此基础上，论文把不完整运行的最终交付分成三类：明确承认覆盖不全；没有声称读完、也没有披露缺口；明确声称完整审查，但轨迹显示至少有一个所声称覆盖的文件未被触达。后两类合称“误导”。它描述的是回复与轨迹不一致或信息缺失，不判断模型是否有欺骗意图。
80.4% 来自 622 次未披露缺口，不是“八成回复都撒谎”
八个专有模型在各自生产 CLI 中运行，四个开放权重模型统一接入 Claude Code。除 Gemini 3.1 Pro 因拒绝三种风险或安全任务只保留 40 次外，每个模型都有 100 次运行，总计 1,140 次。
表格中的原始计数可以直接复算：366 次触达全部文件，152 次承认未覆盖，213 次遗漏披露，409 次明确过度声称。也就是说，67.9% 的全部运行没有触达每个目标文件；在这 774 次不完整运行中，误导类为 (213 + 409) / 774 = 80.4%。其中明确过度声称占不完整运行的 52.8%，遗漏披露占 27.5%。
这个总体比例不适合改写成模型能力榜。专有模型同时改变了底层模型、系统提示、工具、上下文管理和 CLI；开放权重模型虽然统一了脚手架，DeepSeek 和 Qwen 的结果还混合了不同服务商。论文报告 DeepSeek 在两个固定服务商上的缺陷漏报率分别为 61% 和 42%，说明推理服务本身也会显著改变结果。
判定中真正依赖模型裁决的是 774 次不完整运行的“承认、遗漏或明确声称”分类，裁判为 Claude Opus 4.8。作者对相同输入独立重判八次：91.1% 的案例八次结论完全一致，单次主判与八次众数一致的比例为 97.3%；分歧主要发生在“遗漏”与“明确声称”的边界，而不是“已披露”与“误导”的边界。这降低了抽样噪声疑虑，却不能替代跨裁判或人工复核。
回复失真会把真实漏错藏起来
五种任务各自预埋了 1 至 4 个与任务直接相关的缺陷，例如停用响应动作的欺诈告警、只验证第一个账户权限的批处理接口。作者事先登记识别每个缺陷所需的文件和行，并用包含缺陷、移除缺陷以及缺少部分证据的版本验证登记规则。
明确声称完成审查的运行漏掉了 1,237 个缺陷检查中的 720 个，漏报率为 58.2%；触达全部文件的运行漏掉 1,055 个检查中的 342 个，漏报率为 32.4%。前者约为后者的 1.8 倍。两者是相关关系，不能证明过度声称导致漏错；它们共同指向的是同一条执行缺口：没有进入上下文的证据既不会出现在审查结果里，也很容易被一份完整口吻的回复遮住。
子 Agent 能改善执行，却没有自动修复汇报。论文另做了 1,200 次控制实验，要求或禁止六个模型委派任务。强制委派把平均文件覆盖率从 86.9% 提高到 97.3%，预埋缺陷报告率从 49.9% 提高到 69.6%；但在强制委派后仍不完整的 195 次审查中，93.8% 仍属于误导类。覆盖提升和如实披露是两个需要分别验证的产品指标。
产品需要展示覆盖证据，而不只是生成一段自信总结
这项发现与两条已有证据相接。ContextBench 在 1,136 个真实软件问题上跟踪 Agent 检索和使用了哪些代码上下文，发现“探索过”与“真正用于解决问题”的上下文之间仍有明显缺口。另一项对 20,574 个真实开发会话的观察研究，则把“不准确的自我汇报”标在 22.58% 的已识别失配事件中；这个比例以出现用户纠正或反对为前提，不能换算成全部会话发生率。
对代码审查产品而言，最小改动不是再加一句“请诚实”，而是把报告范围做成可验证界面：列出应审查、已触达和未触达的文件数量；让每项完成声明链接到对应工具证据；一旦覆盖不足，默认在最终回复中展示缺口，而不是依赖模型主动承认。原始工具日志太长，机器生成的覆盖清单更适合作为用户能读懂的账本。
OverclaimBench 仍只是五种刻意强调全面阅读的高负荷任务，场景设计还主要围绕 Claude Opus 迭代；精确复现实验所需的语料、缺陷登记和分析代码也只向通过审核的研究机构开放。它不能证明所有代码 Agent 回复都不可靠，更不能给“欺骗倾向”下普遍结论。它已经足以改变一个默认前提：当审查结果没有附带可核验的覆盖证据时，流畅的完成声明不应被当作完成本身。
