夜雨聆风很多人聊 AI Agent，还停留在一个很早期的阶段。
比如：
模型够不够聪明 会不会自己规划任务 能不能调用更多工具 MCP 接得全不全 能不能自己写代码、跑浏览器、做长任务
这些当然都重要。
但如果你真的往下做，很快就会发现，真正决定一个 Agent 能不能从 demo 走向生产的，往往不是模型，而是沙箱。
因为一个只会聊天的 Agent，风险还只是“说错话”。
一个会执行命令、改文件、联网、跑浏览器的 Agent，风险就变成了“真的能把事做坏”。
这时候你讨论的就不再是提示词，不再是上下文，也不再是模型排行榜。真正的问题只有一个：它到底跑在哪。
图 1：Agent 能不能安全上线，核心不只是模型能力，而是执行环境和治理边界。
为什么说沙箱才是 AI Agent 的真正分界线
先把话说死一点：只要一个 Agent 真能动手，它就迟早要进沙箱。
这里说的“真能动手”，不是只会调几个只读 API，而是它已经开始：
执行 shell 命令 读写文件 安装依赖 跑脚本 联网抓数据 调浏览器 调用外部工具和 MCP
到这一步，Agent 就不再只是一个对话界面里的回答器，它已经变成了一个会操作真实系统的执行体。
这个真实系统里有什么？文件系统、网络、密钥、登录态、git 仓库、浏览器 Cookie、shell 配置、数据库连接、第三方 API 凭证。
如果没有边界，Agent 一旦做错事，伤到的就不是一段输出文本，而是整台机器、整个工作区，甚至你的线上环境。
所以沙箱不是一个“做大了再补”的安全 feature。它是 Agent 一旦开始执行真实动作之后，最基础的一层边界。
为什么现在主流 Agent 都在补沙箱
如果只有几个安全创业项目在讲沙箱，这事还可能只是个概念。但问题是，现在主流 Agent 基本都已经默认在做这件事了。
Codex
从本地代码能看到，Codex 在 Linux 上不是简单起一个子进程，而是明确有：
bubblewrap seccomp no_new_privs Landlock 相关路径
更关键的是，它不是只有一个模糊的“安全模式”，而是把边界做成了几种显式等级：read-only、workspace-write、danger-full-access、external-sandbox。
这说明 Codex 已经把“执行环境边界”当成产品本身的一部分，而不是一个附属设置。
Claude Code
Claude Code 的路线不太一样。它不是只做一个壳，而是把产品里的权限模型、文件系统规则、域名规则都映射到真正的 sandbox runtime 里。
从本地代码能确认它会处理这些东西：
allowedDomains / deniedDomains allowRead / denyRead allowWrite / denyWrite settings 文件保护 .claude/skills这类敏感目录的保护 特定命令的 override / excludedCommand
这背后其实是一个很强的信号：Claude Code 在做的，不是“给 Bash 加个罩子”，而是把沙箱纳入了整个权限系统。
OpenClaw
OpenClaw 更像平台型 Agent。它不是“全部都在本机原地执行”，而是把 gateway 和 tool execution 拆成两层：
gateway 继续在宿主机上 工具执行进 Docker sandbox backend
这非常像服务端 Agent 的思路：当 Agent 不只是服务一个本地用户，而是要服务多个会话、多个通道、多个工具，执行面就必须被隔离出去。
E2B
E2B 更直接。官方公开说自己基于 Firecracker microVM。它等于明说了一件事：如果你真的要给 agent 一个可执行、可联网、可跑代码、还能尽量强隔离的环境，容器不是唯一答案，microVM 才是更稳的一条路。
Manus
Manus 则把这件事做成了面向大众产品的表达。它官方对 sandbox 的描述非常直白：
fully isolated cloud virtual machine 每个任务分配 可以并行执行 具备文件系统、网络、浏览器和工具能力
翻成人话就是：它不是给 Agent 一个 REPL，而是给它一台云电脑。
更有意思的是，Manus 的官方 credits 说明里，直接把 virtual machines 列成主要消耗项之一。这意味着在真正的云端 Agent 产品里，沙箱不是边角功能，而是核心基础设施，也是核心成本中心。
真正的问题不是“要不要沙箱”，而是“沙箱放在哪一层”
很多人第一次理解沙箱，会把它想成一个统一方案。但现实不是这样。今天 Agent 沙箱至少已经分成了几条路线，而且每条路线背后对应的产品目标完全不同。
第一条，本地原生沙箱。最典型的就是 Codex、Claude Code。它们尽量贴宿主操作系统做隔离，比如 macOS 的 Seatbelt，Linux 的 bubblewrap、seccomp、Landlock，Windows 的专用沙箱/ACL 路径。
这条路的优势非常明显：启动快、交互顺、对本地开发体验最好。但它也有边界：强依赖宿主 OS，跨平台一致性差，更适合个人本地工具，不适合直接做多租户 SaaS 后端。
第二条，容器路线。就是 Docker / containerd / K8s。执行环境被放进容器，再配合非 root 用户、只读挂载、网络白名单、资源限制。
这条路为什么流行？因为工程成熟：好部署、好复现、好并发，很适合平台型 Agent 和团队内部私有部署。但它的问题也很清楚：共享宿主内核，多租户强隔离能力有上限，一旦再叠浏览器、长会话、DinD、复杂工具链，复杂度会上升得很快。
第三条，外置 sandbox / workspace 路线。代表是 E2B、Daytona、Modal。这条路线最核心的优势，不只是“安全一点”，而是它把控制面和执行面真正拆开了。主服务负责模型调用、编排、权限决策、状态管理，执行环境负责命令、文件、浏览器和运行时依赖。这是今天 SaaS Agent 特别自然的一种形态。
第四条，VM / microVM / cloud computer 路线。这条路更重，但上限也更高。如果你希望 Agent 真跑代码、真跑浏览器、真跑文件系统、真执行长任务，而且还是多租户场景，那独立 VM / microVM 基本就是很难绕开的方向。
这也是为什么今天 Agent 基础设施已经慢慢分成了两派：轻沙箱路线更便宜、更快、更偏本地和容器；重沙箱路线更强隔离、更完整执行能力、也更贵。真正的分野不在“有没有沙箱”，而在“你愿意为隔离和能力付出多少代价”。
真正把 Agent 推进沙箱的，不是安全口号，而是四类现实风险
很多人会把沙箱理解成“谨慎一点更好”。但真正让主流 Agent 补沙箱的，不是理念，而是很具体的工程风险。
误操作
改错目录 删除不该删的文件 把 git 仓库改坏 把 shell 配置、SSH 配置、环境变量文件覆盖掉
数据外泄
只要 Agent 能读文件、能联网，它就可能把不该发出去的东西发出去。比如读到 .env、~/.ssh、数据库配置、token 缓存、浏览器登录态，再通过 curl 或第三方 API 发走。
资源失控
死循环跑满 CPU 无限写文件打满磁盘 无限重试导致账单爆炸 起太多进程导致宿主机失稳 长任务一直不退出，执行环境持续占用资源
工具链放大
现代 Agent 很少是单点能力。它经常会把 shell、文件系统、浏览器、第三方 API、MCP、部署脚本、包管理器和系统依赖串起来。单看每个能力都不吓人，但组合起来就很强。
这也是为什么今天越来越多人开始接受一个判断：Agent 的真实风险不在“它会不会说错”，而在“它会不会做错”。而沙箱的价值，就是先把“做错”的伤害半径收小。
为什么只有沙箱还远远不够
这恰恰是最容易被误解的一点。很多人第一次谈 Agent 安全，会把希望都压在沙箱上。但沙箱主要解决的是：“别让它直接打到宿主机。”它并不能自动解决：
凭证被偷 数据外发 资源耗尽 高权限挂载 低信任 skill 拿到太多能力
图 2：真正可商用的 Agent 安全，不只是沙箱，还要叠加凭证、网络、资源、权限和治理策略。
所以如果你要做真正可商用的 Agent，至少还要再补几层。
第一层，凭证代理
不要把真实 API Key、生产凭证直接放进沙箱。更稳的做法是：Agent 不直接拿 key，只通过受限接口和外部 proxy 通信，由 proxy 动态注入凭证，并同时做审计记录。
第二层，出站网络过滤
沙箱不等于默认断网。如果你的 Agent 既能读文件又能发请求，那它完全可能在沙箱里“合法地”把数据送出去。更稳的默认策略应该是：默认 deny all，只放行白名单域名。
第三层，资源配额和分层超时
你得防的是死循环、无限重试、大量垃圾文件、长时间占用资源。这部分不能靠提示词约束，必须靠基础设施硬限制：CPU、内存、磁盘、单次工具超时、会话总时长。
第四层，最小权限和系统硬化
很多事故并不是沙箱被攻破，而是你自己把高权限送了进去。比如以 root 跑 Agent，挂 ~/.ssh、.env，给过多 Linux capability，给可写宿主目录。所以默认原则应该是：非 root、丢掉高危 capability、只挂必要目录、能只读就只读。
第五层，技能信任分级
不是每个 skill、每个工具、每份来源都该拿同样权限。更合理的做法是做分层：未验证 skill 强隔离，企业审核 skill 给受限文件系统能力，官方认证 skill 才考虑给受控网络和完整执行权。
真正值得记住的一句话
AI Agent 之所以一定要有沙箱，不是因为大家想把安全说得更好听，而是因为 Agent 一旦从“会回答”变成“会执行”，它就必须被放进一个独立、可控、可限制、可回收的执行面里。
但如果再往前走一步，真正可商用的 Agent 安全，永远不是“有沙箱就够了”。它至少还要再加上：凭证代理、网络出站收口、资源硬限制、最小权限、技能信任分级、审计和可观测性。
所以更完整的说法应该是：沙箱是 AI Agent 安全的起点，不是终点。
这也是为什么现在从 Codex、Claude Code，到 OpenClaw、E2B、Manus，大家虽然走的技术路线不同，但都已经默认接受了一件事：Agent 可以没有花哨界面，但不能没有沙箱。
