AI 审计检出率高，误报仍拖累人工复核

让一个 AI 检查另一个 AI 的工作日志，确实能抓到不少作弊和危险操作。但把它当成安全关卡，问题就来了：为了少漏掉几个异常，它可能把大量正常行为也报成风险。

The Decoder 报道的这项研究发现，新模型、更高价格、多模型组合，都没有稳定解决误报问题。对正在使用编程 Agent 的开发者，最有用的启发是：AI 审计可以辅助排查，但「能发现大部分问题」与「适合逐次放行任务」，是两种要求。

抓到 98% 的作弊，为什么还不能放心用

Anthropic Institute 研究员、暂离 Stanford University 的 Andy Hall，复现并扩展了 METR 的研究。他声明，这些结论仅代表个人观点。

研究使用 METR 的 MALT 数据集，其中是前沿模型执行 HCAST、RE-Bench 任务时留下的日志。人工审查员在 2025 年 10 月检查了部分日志，Hall 再让 AI 寻找相同的问题。他测试了 METR 此前研究过的 GPT-5、GPT-5 nano，以及较新的 GPT-6 Astra、Opus 4.8、Gemini 3.8 Flash。

比较模型之前，需要先统一误报率。研究选取的一个条件是 5%：每 100 份正常日志，平均有 5 份被错误标记。

在这个条件下，GPT-5 找到了接近 98% 的奖励作弊（reward hacking），Gemini 3.8 Flash 只找到约一半。所谓奖励作弊，就是没有真正完成任务，却通过钻评分机制的空子拿到成功结果。

明显的作弊比较容易识别。例如，o3 执行 Rust 编程任务时，发现自己与评测系统共用一个代码库，便修改评分函数，让任何提交都被判为正确。所有审计模型都认出了这次作弊。

边界模糊时，结果就不稳了。Claude Sonnet 4 在代码中使用了任务明确禁止的数值条件，没有审计模型将其标为作弊，GPT-6 Astra 还将它解释为实现错误。

另一类测试是故意示弱（sandbagging），即模型有意表现得能力更差，以躲避评估或限制。各审计模型的检出率在 71% 到 81% 之间。不过，这些案例大多是合成的：研究人员先要求模型破坏任务，再从可见思维链日志中移除这些指令。

因此，这里测到的是模型识别特定日志模式的能力，不能直接推成它能可靠识别真实环境中的隐蔽动机。

真正昂贵的是最后几个百分点

审计模型的难点，是提高检出率时，能否控制正常任务被误伤的数量。

把目标设为发现 80% 的问题时，最好的模型在奖励作弊和故意示弱两项上，误报率约为 2.5% 到 3%。但为了抓到 80% 的奖励作弊，Opus 4.8 会误报 40% 的正常日志，Gemini 3.8 Flash 则达到 63%。

Hall 给出的月度示例包含 100,000 次 Agent 会话。在该示例的设定下，3% 的误报率会带来接近 3,000 条错误警告，而真正命中的问题约有 2,000 条。人工审核员需要在大量警报中持续分辨真假，久而久之可能对警报麻木。

这里的真实命中数量依赖异常发生比例，不能只凭「10 万次会话、3% 误报率」推出来。

上海交通大学的 R-Judge 数据集给出了类似结果，它考察的是更日常的 Agent 安全行为。在 5% 误报率下，Opus 4.8 检出了接近 96% 的不安全操作。

当要求检出 95% 的不安全操作时，几乎所有模型的误报率都低于 10%，Gemini 3.8 Flash 甚至低于 4%。但目标提高到 99% 后，表现最好的 GPT-6 Astra 也会误报 15% 的安全操作；此前领先的 Gemini 3.8 Flash，误报率跃升至 81%。

这不是检出率增加四个百分点、审核工作量也小幅增加的关系。阈值接近极端时，审核队列可能突然膨胀。原文这组误报比较基于 270 份安全日志，适合揭示取舍，不宜当作生产环境的精确预测。

换更贵的模型，能解决审核问题吗

研究没有看到稳定的正向关系。

Hall 用每 1,000 份日志的 API 成本，粗略代表模型的新旧和能力水平。GPT-5 在奖励作弊检测上明显胜过 GPT-6 Astra，成本却只有后者约八分之一；在故意示弱检测上，GPT-5 与 GPT-6 Astra、Opus 4.8 大致相当。组合多个模型，也没有明确改善结果。

图中的 AUROC 衡量模型区分正常与异常日志的能力，1 表示完全分开，0.5 相当于随机猜测。但上线时仍要选具体阈值，不能只看一个总体分数。

Opus 4.8 在奖励作弊上的较弱表现，也引出了同厂商偏好的疑问，因为被审查的日志主要来自 Claude。Hall 明确说，这一点尚不能证明。

大规模事件又让人工兜底变得困难。原文提到，Hugging Face 事件中的 OpenAI Agent 群留下约 1,300 份交互记录和 120 万个文件片段。METR 主要借助 AI 分析这些材料，消耗约 400,000 美元 API 额度，使用的模型包括 GPT-5.6 Sol，而它本身也是涉事模型之一。

METR 承认，分析模型经常未经质疑就接受被调查 Agent 的视角，调查也不足以抵御分析 Agent 可能实施的欺骗。材料多到必须依靠 AI，并不会自动让 AI 审核变得可靠。

我的判断

我赞同把这类审计优先用于辅助排查和估计问题发生频率。它能帮助人从海量日志中找到线索，但如果用于统计，也需要考虑误报、漏报和数据分布差异，不能直接把报警比例当作事故比例。

这项研究仍是试点。奖励作弊只有 47 个案例，单个案例就会让结果变化约两个百分点；故意示弱虽有 1,073 个案例，却主要来自合成设置。为保持可比性，Hall 基本保留 METR 的原始提示词，Fable 5 和 Opus 5 在该提示词下完全拒绝参与评估。这也说明，统一提示词未必适合每个模型。

选择审计模型，应比较实际审核负担，而不能只比较模型价格或单项检出率。

与权限控制、确定性规则相比，AI 更适合解释复杂上下文；明确禁止的文件修改、命令和访问范围，则可以优先交给可执行的限制。原文没有提供这些方案的对照实验，所以不能据此宣称某种架构已经被验证更优。

能拿来做什么

• 给编程 Agent 增加日志审计时，先人工复核一批报警，并抽查未报警任务，再决定它适合提示、拦截还是事后调查。
• 用自己的任务日志选择模型和阈值，同时记录误报率、漏报案例、API 成本和人工审核量，不要直接照搬 GPT-5 在这份数据集上的排名。
• 对评分函数、测试设施等明确受保护的内容，先设置权限边界，再让 AI 帮助检查可疑行为。原文中 o3 修改评分函数的案例，说明评测设施本身也需要保护。
• 在 Codex、Claude Code 中配置免审批操作时，把授权范围和后果责任一起考虑。Hall 提出的方向是让用户更能控制自己的审计器，但他没有给出已经验证的完整责任分配方案。