给 AI 编程 Agent 上'安全锁'：从 Docker Sandboxes 到 bubblewrap，六类沙箱按隔离强度横评，你的场景该选哪一层
8 月 19 日，一个装 DeepSeek Harness 社区插件的用户，一条命令下去，400G 文件没了。评论区一半人骂插件，一半人骂框架，但真正该被追问的问题是：让 Agent 跑代码之前，你给它画了多大的安全边界？
昨天那篇 harness 拆解里，安全与权限边界是五个模块里最容易被跳过的一个。今天不聊抽象骨架了，直接落到能用的层面——把市面上给 AI coding agent 用的沙箱方案，按隔离强度从强到弱拉通比一遍，最后给你一张按场景选的表。
先说结论，免得你看到后面忘了主线：
沙箱不是越强越好，是越匹配越好。 自主跑不可信代码选 microVM，可信工具日常开发选容器或进程沙箱，CI 跑测试容器够用还便宜，手动开发调试直接宿主跑加权限审批兜底。
一个前提：为什么普通 Docker 容器不够用
先破一个常见的误解。很多人觉得"容器就是沙箱"，其实不对。
普通 Docker 容器用的是 namespace + cgroup，它隔离的是"看得见的东西"——进程、文件系统、网络栈。但所有容器共享宿主机的同一个内核。这意味着一旦 Agent 执行的代码触发了内核漏洞，就可能逃逸出容器，波及整台机器。容器不是坏，是它挡不住"内核级"的攻击。
正因为这个缺口，2026 年沙箱赛道集体转向了 microVM（微虚拟机）——介于容器和传统虚拟机之间：接近虚拟机的安全性（独立内核），接近容器的轻量和弹性（毫秒级启动）。
三种方式的内核边界，一眼就能看出差别：
下面把沙箱方案按隔离强度从强到弱排成一条梯度，你就能一眼看懂每一层的取舍：
下面按隔离强度从强到弱，把主流的几类都过一遍。
第一梯队：microVM / hypervisor，给 Agent 一台真正的"独立电脑"
这是目前隔离强度最高的方案，核心思路是：给每个 Agent 一个独立的内核，宿主机碰不到，Agent 也出不来。
E2B 是这条路的先行者（2023 年成立），底层用 AWS 开源的 Firecracker（AWS Lambda 的底座），每个沙箱一个独立 Linux 内核。冷启动约 150-200ms，单沙箱内存约 5MB，单台服务器能跑几千个沙箱。它主打托管云服务：Hobby 版免费（含 100 美元额度）、Pro 版每月 150 美元加用量，企业版支持自带云和私有化部署。官方称 88% 的《财富》100 强已签约，客户包括 Hugging Face、Perplexity、Groq、Manus。
Docker Sandboxes 是 2026 年 4 月 Docker 出的新方案，走的也是 microVM 路线，但定位完全不同——给开发者本地桌面用的。每个沙箱跑在宿主机原生 Hypervisor 上（Linux 用 KVM、macOS 用 Hypervisor.framework、Windows 用 Windows Hypervisor Platform），自带独立的 Docker daemon、文件系统、网络和内核。Agent 在里面能随便 docker build、docker run，完全不影响宿主机的 Docker 环境。
它有个特别贴心的点：sbx CLI 免费，包括商用，只有组织治理（统一管理网络/文件系统/MCP 策略）才要单独付费订阅。支持 Claude Code、Copilot CLI、Codex、OpenCode、Kiro、Gemini CLI 等主流 agent。网络策略是它的亮点——默认 balanced 模式会生成约 197 条网络 allow 规则，默认拒绝宿主机 localhost、局域网私有地址、云平台 metadata 端点（169.254.169.254）、各家遥测域名，防数据外泄。
注意：Docker Sandboxes 已经发布几个月，不算新品。这里只把它当 microVM 这层的代表提一下，它值得单独深挖，明天专门写。
Cube Sandbox 是腾讯云 2026 年 4 月开源的（Apache 2.0），底层用 RustVMM + KVM，冷启动 <60ms（行业平均 150ms，快 2.5-50 倍），单沙箱内存 <5MB，单台 96 核服务器能同时跑 2000+ 个沙箱。最狠的是它原生兼容 E2B SDK 接口——改一个环境变量就能从 E2B 平滑迁过来，是数据不能出境的国内团队的现实选择。
第二梯队：容器（含 socket 挂载的"半开"陷阱）
容器是隔离强度和成本之间的平衡点。启动快（~500ms）、开销小（几十 MB），但共享宿主内核，挡不住内核级逃逸。
这里有个必须点破的坑：很多人图省事，把宿主机的 docker.sock 直接挂进 Agent 容器——等于把整台机器的 Docker 控制权交给了 Agent。这是教科书级的"Confused Deputy"（糊涂代理人）漏洞：恶意代码可以通过 socket 拉起一个 --privileged 容器，挂载宿主根目录，直接拿下整个宿主的 root 权限。OpenHands 的 dev 容器就因为这个被提过 issue，业界公认"挂 docker.sock + docker 组 = 等效 root"。
挂 docker.sock 的容器，本质上是半开的沙箱——你以为在隔离，其实 Agent 已经站在你家门口了。要挂就只读挂载 + 用户命名空间隔离，别直接给。
第三梯队：进程级沙箱（bubblewrap / seccomp）
再往下，是不换内核、不换命名空间，只在进程层面做约束的轻量方案。代表是 bubblewrap（Linux）和 Seatbelt（macOS），用 OS 原语做文件系统和网络隔离。
Claude Code 的原生沙箱就走这条路——它的沙箱化 bash 工具用操作系统级原语同时做文件和网络隔离，好处是不用每次命令都弹窗审批，提前划好边界让 Agent 更自主地干活，同时避免"审批疲劳"（点十次"允许"之后，你就真的不再看了）。代价是它的隔离是"进程级"的，挡不住同内核下的强攻击，适合跑可信代码，不适合跑不可信代码。
第四梯队：宿主直跑（无隔离）
最后是最省事也最危险的一档——Agent 直接在宿主上跑，拥有你的全部权限。Open Interpreter 就明确声明自己跑在本地环境，有完整互联网访问和任意装包能力；Claude Code 的 --dangerously-skip-permissions 也是这个路子（虽然它背后还有个 AI 分类器在守门）。
这档不是"不能选"，而是必须搭配权限审批兜底——手动开发、调试、可信工具场景，宿主直跑 + 逐条审批是够用的。但绝对不要拿它跑不可信代码或自主 agent。
一张表，按隔离强度看全八维
把上面几类拉成一张对比表，选型的分叉点一目了然：
| 维度 | microVM（E2B/Cube/Docker Sbx） | 容器 | 容器+socket 挂载 | 进程沙箱（bubblewrap） | 宿主直跑 |
|---|---|---|---|---|---|
| 隔离机制 | 独立内核（hypervisor） | namespace+cgroup | 共享宿主 daemon | OS 原语 | 无 |
| 隔离强度 | 最强 | 中 | 半开（有提权风险） | 弱 | 无 |
| 启动速度 | 60ms-秒级 | ~500ms | ~500ms | 毫秒级 | 即时 |
| 资源开销 | ~5MB-1GB | 几十 MB | 几十 MB | 极低 | 零 |
| 能建容器/装包 | ✅ | ✅ | ✅ | 受限 | ✅ |
| 网络/凭证控制 | 强（策略化） | 手动 | 弱 | 可过滤 | 无 |
| 成本 | 免费-托管按量 | 免费 | 免费 | 免费 | 免费 |
| 上手难度 | 中-高 | 低 | 低 | 中 | 最低 |
为什么选型要按"场景"而不是按"最强"
这是今天最想让你带走的一个洞察：沙箱的强弱，不是判断题，是场景题。
把成本算全你就明白了。microVM 隔离最强，但每起一个沙箱都有资源开销和启动延迟，对"每次调起、按毫秒计费"的高频场景是负担；进程沙箱最轻，但挡不住内核攻击，拿它跑不可信代码是赌命；宿主直跑最省，但一次 rm -rf 就够你哭一整年。
判断标准其实就三条：代码可信不可信、要不要隔离宿主资源、任务频次高不高。
- 自主 agent（不可信代码、要联网、要建容器） → microVM。要么云端托管（E2B），要么本地独立内核（Docker Sandboxes），这是唯一能放心让它"随便折腾"的档。
- 可信工具 / 日常开发（代码是你自己仓库的） → 容器或进程沙箱（Claude Code 原生沙箱）。够用，且不折腾。
- CI 跑测试（每次干净环境、跑完即弃） → 容器就够，便宜、快、够用。
- 手动开发 / 调试（你自己盯着、逐条确认） → 宿主直跑 + 权限审批兜底。
呼应上一篇：harness 的"安全与权限边界"模块怎么落地
还记得昨天 harness 拆解里那个扎心的结论吗？那篇 70 个系统的论文发现：基础隔离很常见，但高保证度的审计机制很稀有。DeepSeek Harness 插件删 400G 数据，根因不在模型，在权限边界的默认值设得太松。
把今天的内容拼回去，你就知道"安全与权限边界"这个模块具体该怎么落地了：
- 默认隔离强度：harness 跑代码时默认进哪个沙箱？默认值决定风险基线——默认宿主直跑 + 靠审批，就是 DeepSeek 那条出事的路；默认 microVM，才是把安全做进产品核心。
- 网络/凭证控制：Agent 能连哪些网、能看到哪些凭据？Docker Sandboxes 的
balanced网络策略（默认拒绝 localhost/内网/metadata/遥测）就是现成范本。 - 审批 vs 沙箱双保险：权限是逻辑层（能不能做），沙箱是系统层（做了也隔离）。两条独立防线，缺一不可。
明天就能试的那件事
别急着上最重的 microVM。打开你天天用的 coding agent，先看它当前默认在哪一层跑：
- 如果你用 Claude Code，
claude命令已经自带进程沙箱，先去把沙箱化的 bash 工具开了（/permissions里配），立刻能少点一半审批弹窗； - 如果你想要独立内核级的隔离，装个 Docker 的
sbx：brew install docker/tap/sbx（macOS）或curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh后sudo apt-get install docker-sbx（Ubuntu），然后cd ~/my-project && sbx run claude——跑一次你就知道"给 Agent 一台随手可删的电脑"是什么体验了。
从"批准每一步"到"划好边界让它自由跑"，是 Agent 工程的一个分水岭。你今天选的这一层，决定了明天你的 Agent 是帮手还是隐患。
明天（8/31）单独深挖 Docker Sandboxes 的完整上手与网络策略，想看就把这篇的收藏点一下。