全部 · 2026-07-20

这篇文章把“为什么需要沙箱”拆得很清楚，核心逻辑是：审批只能看命令开头，管不了命令启动后实际执行的代码。作者沿着一次修 bug 任务走了一遍，从 npm install 的生命周期脚本，到测试框架加载的第三方插件，再到推送代码时的凭证风险，每一步都解释了为什么黑名单、逐条审批和专用工具都不够用。 文章引用了 Anthropic 和 Cursor 的工程实践，提到 macOS 用 Seatbelt、Linux 用 bubblewrap 做操作系统隔离，Docker Sandboxes 把凭证留在宿主机侧代理，这些都有出处。但全文没给任何性能数字——沙箱会增加多少延迟、快照恢复要多久、资源开销多大，这些都没提。对实际选型来说，这些缺失挺关键的。 另外，文章把“虚拟机守不住合法权限”这点讲得很实在：即使进程关在沙箱里，只要带着有效 Token 推代码，远端仓库照样会被改。它把网络策略、凭证代理和外部权限策略分成三道闸门，这个分层思路对做 Agent 安全设计的人有参考价值。整体判断都挂在具体机制上，没有画饼，值得一读，但别指望拿到可以直接对比的指标。