E层第1篇:AI Agent 沙箱架构总览

AI Agent 执行环境——为什么需要沙箱？有哪些方案？怎么选？

一、为什么 Agent 需要沙箱？

Coding Agent 不是帮你"看代码的搜索引擎"。它是一个能执行任意命令的程序——它会 git commit、npm install、运行测试、创建文件、修改配置。

如果不加约束，一个 Agent 可以：

rm -rf / 删除你的整个工作目录
读取生产数据库的密钥
把你的代码发送到外部服务器
发起 fork bomb 让系统崩溃

这里的核心矛盾是：Agent 需要足够的自由度才能干活，但自由度越大，风险越高。 沙箱就是在"能干活"和"不出事"之间画一条线。

Luis Cardoso 在"A Field Guide to Sandboxes for AI"（2025）中给出了一个精确的定义：

Sandbox = Boundary + Policy + Lifecycle （沙箱 = 边界 + 策略 + 生命周期）

也就是说，沙箱不只是"隔离"，还需要定义"允许做什么"以及"何时创建、何时销毁"。

二、五种隔离方案，从弱到强

先看全景图

Luis Cardoso 画了一张经典的 syscall 路径对比图，清晰地展示了不同隔离方案下 Agent 如何访问宿主内核：

从左到右，Agent 直接暴露给宿主内核的系统调用接口（syscall ABI）越来越少。容器直接暴露宿主内核的完整 syscall ABI（只是用策略过滤）；gVisor 在中间插了一个用户态内核；MicroVM 在硬件虚拟化后面放了一个客户内核；WebAssembly 模块根本拿不到 syscall ABI——它们只能调用宿主显式提供的函数。

下面逐一拆解。

2.1 进程沙箱（Process Sandbox）

原理： 不创建新环境，直接在宿主系统上限制进程的系统调用。

Linux 进程级隔离工具全景：

优点： 零额外开销，启动速度毫秒级，工具链成熟 缺点： 共享宿主内核，内核漏洞等于全面失守

代表产品：OpenAI Codex（Linux 版）——使用 Landlock + seccomp，而且是目前唯一默认开启沙箱的主流 Coding Agent。

2.2 容器沙箱（Container Sandbox）

原理： 用 Linux namespace + cgroups 创建隔离视图。看起来像独立系统，实际共享宿主内核。

Docker / Podman 是最主流的容器运行时，OCI（Open Container Initiative）是容器镜像和运行时的标准规范。

优点： 生态最成熟、镜像丰富、启动快（秒级）、工具链完善、开发者熟悉度高

缺点： 核心问题是共享宿主内核——内核漏洞可导致容器逃逸（container escape）。有一个社区共识非常重要：

Docker is not a sandbox — there is strong community consensus that shared-kernel containers do not provide adequate isolation for untrusted AI-generated code. — Bunnyshell Coding Agent Sandbox Guide (2026)

代表产品： Gemini CLI（可选 Docker/Podman，默认关闭）、Claude Code（可选 Bubblewrap/Seatbelt，默认关闭）、Daytona（Docker/OCI 容器）

2.3 gVisor（用户态内核）

原理： 在用户态实现一个"假内核"（叫 Sentry），拦截所有系统调用，由 Sentry 处理后再转发给宿主内核。Agent 看到的是 gVisor 的 syscall 接口，不是宿主内核的。

Agent 进程 → gVisor Sentry（用户态内核）→ 宿主 Linux 内核。系统调用在 Sentry 层被拦截和过滤，只有一小部分经过验证的 syscall 才会到达宿主内核。

优点： 比容器强（不直接暴露宿主内核的 syscall ABI），比 MicroVM 快（不需要完整虚拟化），兼容 OCI 运行时 缺点： I/O 密集型工作负载有 10-30% 性能损耗，不是所有系统调用都支持

代表产品：Modal（50,000+ 并发会话，gVisor 隔离）

2.4 MicroVM（微虚拟机）

原理： 每个工作负载启动一个最小化的虚拟机，有自己的独立内核。通过 KVM 硬件虚拟化实现。

关键工具：

Firecracker（AWS 开源）：专为 serverless 设计，~125ms 启动，<5MB 内存开销
Kata Containers：容器体验 + VM 隔离（Kubernetes 生态，Google Agent Sandbox 选用）

优点： 最强隔离——每个 Agent 有独立内核，内核漏洞不影响宿主；硬件级隔离（KVM），攻击者需要逃逸客户内核 + hypervisor 两层；启动快（~100-150ms） 缺点： 需要硬件虚拟化支持（KVM），快照/恢复比容器复杂，生态不如容器成熟

代表产品： E2B（Firecracker，~~150ms 冷启动）、Bunnyshell hopx（Firecracker，~~100ms 冷启动）

2.5 运行时沙箱（Runtime Sandbox）

原理： 不依赖操作系统内核，由运行时环境提供隔离。

关键技术：

WebAssembly (Wasm)：Wasm 模块没有 syscall ABI，只能通过宿主显式提供的函数与外界交互
V8 Isolates：Chrome 使用的进程隔离模型

优点： 最小攻击面——不给系统调用就没有 syscall 漏洞；跨平台 缺点： 性能受限，生态不成熟，不适合需要完整 OS 环境的场景

2.6 一张表看全貌

维度	进程沙箱	容器	gVisor	MicroVM	运行时沙箱
隔离边界	系统调用过滤	Namespace/cgroups	用户态内核	独立内核+KVM	无 syscall ABI
内核共享	✅ 共享	✅ 共享	❌ 不直接暴露	❌ 独立	❌ 无内核
冷启动	<1ms	1-5s	1-3s	100-150ms	<50ms
内存开销	极低	低	中	低(<5MB)	极低
隔离强度	⭐	⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
兼容性	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐
适用场景	本地开发	信任代码	平衡方案	不受信代码	轻量计算

三、主流 Coding Agent 怎么选沙箱？

3.1 OpenAI Codex — 三个平台三种方案

Codex Windows "Elevated Sandbox" 架构：

Linux（最成熟）： Landlock + seccomp，默认开启，网络 default-deny（白名单放行包管理器和 VCS 主机）

macOS： Seatbelt，系统调用级过滤

Windows（2026 年 6 月刚发布）： 自研 "elevated sandbox"。OpenAI 评估了 Windows 上所有原生方案后都不满意：

AppContainer：隔离太强但太受限——Codex 需要驱动 shell、Git、Python、包管理器等任意工具
Windows Sandbox：隔离强但需要独立的桌面环境，无法直接操作用户的实际工作区
MIC 标签：不够强

最终选择了自研方案。

Codex 的三个关键设计原则：

每个 Codex 命令都从沙箱启动，所有子进程继承相同边界
网络默认阻断，显式放行（package registries, VCS hosts）
文件系统：几乎任意读，只在 workspace 内写

3.2 Claude Code — 本地进程沙箱，默认关闭

Linux 用 Bubblewrap，macOS 用 Seatbelt。但默认不开启，依赖的是权限模型（用户逐条确认）而非隔离。设计哲学是信任用户环境，通过交互确认控制风险。

3.3 Devin — 容器化全栈环境

每个任务运行在独立容器中，容器内包含 shell、编辑器、浏览器，模拟完整开发者环境。支持容器快照和跨会话恢复。Devin 2.0 支持并行启动多个容器化 Agent。

3.4 行业趋势

一个关键发现：截至 2026 年中，默认开启沙箱的只有 Codex 一家。

Today, most major coding agents lack sandboxing by default — Claude Code uses Bubblewrap/Seatbelt (opt-in), Gemini CLI uses Docker/Podman (opt-in), and only OpenAI Codex (Landlock + seccomp) ships with sandboxing enabled by default.

行业目前更倾向于权限模型（交互确认）而非隔离模型（默认沙箱）。但随着 Agent 自主性增强，沙箱隔离会越来越必要。

四、文件系统隔离策略

沙箱不只是"能不能执行命令"，还有"能访问哪些文件"。三种策略：

4.1 读写白名单（最安全）

Agent 只能读写白名单内的路径，其他路径完全不可见。

允许读：/workspace/**, /usr/lib/**, /usr/local/**
允许写：/workspace/**
禁止：其他所有路径

4.2 默认读 + 限定写（Codex 方案）

Agent 可以读几乎任何文件，但只能写到指定目录。

允许读：/**（全系统）
允许写：/workspace/**（仅工作区）

兼顾了能力和安全——Agent 能了解系统环境，但不能修改系统。OpenAI Codex 用的就是这个策略。

4.3 版本化文件系统（最灵活）

每次修改都版本化，改错了可以一键回滚。类似 Git 的快照机制作用于整个文件系统，底层用写时复制（Copy-on-Write）技术。代表产品：Daytona（容器快照）、E2B（文件系统快照）。

五、网络隔离策略

5.1 默认阻断（Default-Deny）

Agent 默认没有网络访问，需要什么域名逐一放行。

默认：所有出站连接被阻断
放行：registry.npmjs.org, pypi.org, github.com
阻断：其他所有域名

OpenAI Codex 就是这个策略：

The default-deny network posture allowlists package registries and VCS hosts and blocks everything else. That default is what makes autonomous execution safe to enable in the first place.

5.2 DNS 级别控制

通过自定义 DNS 解析限制可访问域名，DNS 查询本身也可以被记录和审计。

5.3 代理模式

Agent 的所有网络流量经过代理服务器，可以检查、记录、按域名/端口/协议精细控制。

5.4 无网络模式（Air-Gapped）

完全切断网络。适合离线任务（代码分析、重构、测试），安全性最高，但无法安装依赖。

六、沙箱的三个决策维度

回到 Luis Cardoso 的框架，选沙箱实际上要做三个独立的决策：

问题 1：边界（Boundary）——隔离在哪里执行？

内核级（容器、进程沙箱）
硬件级（MicroVM）
运行时级（Wasm）

问题 2：策略（Policy）——允许什么、禁止什么？

系统调用白名单
文件系统路径
网络访问规则
资源限制

问题 3：生命周期（Lifecycle）——何时创建、何时销毁？

每次任务创建新沙箱（Codex 模式）
沙箱持久化跨会话（Daytona 模式）
闲置自动销毁（15 分钟无活动 → 停止）

Sandboxing is three separate decisions that people blur together, and keeping them distinct prevents a lot of bad calls. — Luis Cardoso (2025)

七、关键认知总结

1. Docker 不是沙箱。

这是本篇最重要的结论。容器是隔离，但不是安全的隔离——共享内核意味着内核漏洞可导致容器逃逸。对不受信任的 AI 生成代码，需要更强的隔离。

2. 行业默认不开启沙箱。

截至 2026 年中只有 Codex 默认开启。行业仍处于"权限确认 > 强隔离"阶段，但趋势在向隔离方向移动。

3. 没有银弹，选型看场景：

本地开发、信任 Agent → 进程沙箱够用
多租户、不受信代码 → MicroVM 或 gVisor
需要完整 OS 环境 → 容器（接受风险）或 MicroVM
超轻量计算 → 运行时沙箱（Wasm）

4. 沙箱 = 边界 + 策略 + 生命周期，三者缺一不可。

隔离只是第一步，还得配好"允许什么"和"何时销毁"。

5. 网络隔离和文件系统隔离同样重要。

OpenAI Codex 的 default-deny 网络策略是其安全架构的核心支柱。

下篇预告： E 层第 2 篇将深入"进程级沙箱与权限模型"——当不需要完整容器或 MicroVM 时，如何用 deny/allowlist/full 三级权限控制 Agent 的执行范围？Claude Code 和 OpenClaw 分别是怎么做的？

参考来源

OpenAI — "Building a Safe, Effective Sandbox to Enable Codex on Windows" (2026.06) https://openai.com/index/building-codex-windows-sandbox^[1]
Luis Cardoso — "A Field Guide to Sandboxes for AI" (2025) https://luiscardoso.dev/blog/sandboxes-for-ai^[2]
Northflank — "How to Sandbox AI Agents in 2026" (2026) https://northflank.com/blog/how-to-sandbox-ai-agents^[3]
Bunnyshell — "Coding Agent Sandbox: Secure Environments for AI-Generated Code" (2026) https://www.bunnyshell.com/guides/coding-agent-sandbox^[4]
gVisor — "Security Basics, Part 1" (2019) https://gvisor.dev/blog/2019/11/18/gvisor-security-basics-part-1^[5]
Firecracker — "FAQ" (AWS) https://github.com/firecracker-microvm/firecracker/blob/main/FAQ.md^[6]

引用链接

[1]https://openai.com/index/building-codex-windows-sandbox

[2]https://luiscardoso.dev/blog/sandboxes-for-ai

[3]https://northflank.com/blog/how-to-sandbox-ai-agents

[4]https://www.bunnyshell.com/guides/coding-agent-sandbox

[5]https://gvisor.dev/blog/2019/11/18/gvisor-security-basics-part-1

[6]https://github.com/firecracker-microvm/firecracker/blob/main/FAQ.md