AI Agent 在你电脑上跑命令，你真的放心吗？
上周我尝试让 Agent 帮我重构一个项目（其实就是想偷个懒）。它跑了大概 20 分钟，中间噼里啪啦执行了四十多条 shell 命令——装依赖、改配置、跑测试，甚至还动了 .git 目录。 跑完我回头看了一眼日志，冷汗直接下来了：中间有好几步，如果它命令写偏了一个字符（比如把 rm -rf ./tmp/ 写成了 rm -rf /），我的本地环境大机率当场报废。 这还不是最可怕的。最可怕的是，当 Agent 每一步都弹窗问我“允许执行吗”的时候，我发现自己根本没仔细看——点了二十次“允许”之后，那个确认按钮已经变成了我的肌肉记忆。 这就是今天要聊的问题：Agent 越来越能干活了，但谁来管住它的手？ 弹窗确认，其实是个心理安慰 很多人觉得，让 Agent 每执行一步都弹窗确认就够了。看起来很“民主”，实际上有两个致命问题。 第一，中断疲劳。一个正经的重构任务，可能涉及十几次文件读写、几十条 shell 调用。如果每一步都确认，Agent 的自动化价值就直接归零了。你雇了个助手，结果它每个动作都要你签字，那跟你自己干有什么区别？（这还不如我自己手写呢。） 第二，弹窗防不住真正的风险。你真的能在 1 秒钟内审完一长串 bash 命令吗？被混淆过的脚本、链式调用、隐蔽的数据外带——肉眼根本看不出来。本质上，弹窗确认是在把安全责任甩给用户，而不是在系统层面建立边界。 🔑 核心观点：车速越快，护栏越重要。你不能靠“每次变道都问一下副驾”来解决安全问题。 真正可持续的方案是：把 Agent 放进一个边界明确的区域，边界内自动跑，越界直接拦——不打扰，不甩锅，靠机制而不是靠注意力。 这就是 Agent 沙箱要干的事。 三条路线，各有各的算盘 目前行业里做 Agent 沙箱，大致有三条路线。它们不是谁淘汰谁，而是各适合不同的场景（或者说坑位）。 1. 容器型：Docker 一把梭 把代码执行环境塞进独立容器，通过 API 和 Agent 主流程解耦。 优点很明显：环境一致性好、多租户调度方便。很多云端 Agent 平台（比如那些做代码执行服务的）都走这条路。 但如果你要做的是“让 Agent 在我的本地项目里帮我干活”，Docker 就有点笨了。Volume 映射、路径同步、宿主文件和容器视图的一致性……一堆问题等着你。它更适合“把任务送进隔离盒子执行”，不太适合“在我当前工作区无缝协作”。 ...