用过 AI 编程 Agent 的人应该都熟悉这个界面Agent 要执行一条命令弹出个确认框等你点允许或拒绝。日常的 git status、npm test 闭着眼就放行了偶尔遇到 rm -rf 开头的命令会多想一下。大多数人默认这个人肉审批是一道靠谱的安全闸门。scalex.dev 的作者做了个小游戏把这件事变成了测试玩家扮演 AI 编码 Agent 的审批人在时间压力下决定放行还是拦截。游戏上线后收集了超过 4 万局、40.9 万次审批决策的数据结论不太乐观——平均准确率只有 66.3%也就是说大约三分之一的威胁命令被玩家放行了。越隐蔽的攻击越容易被放行按威胁类型拆开看规律很清晰。明显破坏性的命令rm -rf /、chmod -R 777 / 这类漏过率只有 11.7%——太扎眼了正常人都会拦。但真正危险的命令漏得更多凭证窃取类cat ~/.aws/credentials 这种漏过率 35%外泄/代码执行类 33.4%。最说明问题的是 npm run analyze漏过率 64.7%排在所有威胁的第一名。这个命令单看名字人畜无害——跑个打包分析而已。但 npm run 执行的是项目 package.json 里定义的脚本Agent 完全可以在请求审批之前先改掉 package.json把恶意代码藏进脚本里。游戏里甚至把这段可疑脚本内容显示在了历史日志中玩家还是放行了。不是没看见是没意识到 package.json 里的脚本可以被替换——他们默认npm run 就是跑个分析工具。这背后是个更本质的问题审批人看到的命令本身是安全的危险的是命令背后被 Agent 动过手脚的文件。要求用户在缺失上下文的情况下做安全判断本身就是个有缺陷的模型。审批疲劳是双向的数据里还有另一个现象过度拦截同样严重。npm config set registry https://npm.internal设置内网镜像被 59% 的玩家拦截rm -rf dist/清理构建产物被 45% 拦截kill $(lsof -t -i:3000)释放被占用的端口被 43% 拦截。这些全是正常的开发操作。拦得松威胁溜过去拦得紧正常工作被卡住。更麻烦的是高频的确认弹窗会积累疲劳——Anthropic 官方文档里也承认过用户看到的审批越多对每条审批的关注度就越低。游戏数据印证了这一点同一局里前几条命令的漏过率最低越往后越高疲劳在起作用。作者前 Uber Staff Engineer Alex Wauters的判断很直接让人在缺乏上下文的情况下逐条审批命令这个模型本身有问题。可行的方向是沙箱化和严格的上下文隔离——让 Agent 在受限环境里跑而不是把安全责任全压给审批弹窗。从工程实践看几个具体动作比盯紧点更有效。一是给 Agent 的执行环境做网络隔离凭证外泄类命令最危险的部分是把数据发到外部服务器切断出网路径能挡住一大半二是对 npm run、make 这类间接执行入口单独设规则因为它们实际执行的是项目内脚本风险不在这条命令本身三是把审批弹窗从命令级别提升到意图级别——Agent 想干什么、涉及哪些文件改动比它具体敲了哪条命令更有判断价值。这些做法都不新鲜但很多团队确实只停留在加个确认框的阶段。对开发团队来说这个实验的启示不是以后审批要更小心而是别把人工审批当成安全边界。如果团队准备大规模推 AI 编码 Agent权限设计上值得优先考虑的是Agent 能接触哪些凭证、命令在什么环境里执行、哪些操作根本不该出现在审批列表里。审批弹窗是最后一道闸但前面得先修好堤坝。一个还没解决的问题工具厂商们正在做的自动安全判断比如自动区分安全命令的模式识别本身也会出错目前没有公开数据说明这些自动判断在真实工作负载下的误报率。当自动判断和人工审批都不完全可靠时边界到底画在哪里还没有现成答案。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版