青蛙小白

Agent Sandbox（Agent 沙箱）

Agent 沙箱（Agent Sandbox） 是为 LLM Agent 提供隔离执行环境的基础设施，是 ETCLOVG Taxonomy（ETCLOVG 分类法） E 层（执行环境与沙箱）的核心概念。沙箱不是从传统多租户代码执行"借来"的安全措施，而是 Agent 时代特有的一等研究对象——因为它同时服务三个不可分割的目的。

三重目的

安全性（Security）：LLM 生成代码既不可审计也不可在规模上预测，使静态审查作为主要防线失效。Prompt injection 攻击可将原本良性的 Agent 重定向为恶意沙箱操作媒介。沙箱提供边界，使提示注入的代码或幻觉命令无法修改敏感文件或泄露数据。

可复现性（Reproducibility）：长视野 Agent 任务和评估这些任务的 harness（§8）需要能将执行状态重置到已知基线的能力。Docker 容器或 microVM 可按需销毁重建，而开发者工作站无法做到这一点——这一特性使 SWE-bench、OSWorld 等大规模基准测试在实践上可行。

活性（Liveness）：没有沙箱，Agent 每次想执行潜在风险操作（文件写入、包安装、出站网络调用）都必须触发人工确认提示。规模上，这会产生两种失败：用户因挫败感放弃 Agent，或习惯性地批准一切，使安全提示失去意义。沙箱通过在会话配置层面预授权动作，将权限问题从动作级转移到配置级。Anthropic 报告引入沙箱后 permission prompts 减少 84%，同时维持安全性。

Claude Code 的 Auto Mode 解决的是同一类活性问题的另一条路径：它不先把执行环境严格隔离，而是让 transcript classifier 在动作前替代部分人工审批。两者互补：沙箱限制“能碰到哪里”，Auto Mode 判断“这次动作是否被用户授权”。对高风险环境，Auto Mode 不能替代沙箱；对需要主机或网络访问的本地开发任务，Auto Mode 可以减少沙箱配置负担。

这三个目的的组合——安全+可复现+活性——是将 Agent 沙箱视为独立研究对象而非容器技术下游应用的理由。

Containment：限制 blast radius

Anthropic 在《How we contain Claude across products》中把 Agent 部署风险拆成两部分：出错概率 P(harm) 与理论破坏半径（blast radius）。模型训练、系统提示、分类器和 probe 可以降低出错概率，但只要 Agent 能访问更多文件、网络和内部服务，潜在破坏半径仍会变大。Containment 的目标是在环境层设置硬上限：即使用户误用、模型误判或外部攻击成功，Agent 也只能影响被授权的环境。

这个视角把沙箱从“安全附加项”提升为部署决策的一部分。能力越高、收益越大，越需要把风险从“模型是否会做坏事”转成“即使它做了，最多能碰到什么”。环境层是硬上限，模型层是概率性约束，外部内容层则要对输入和输出做扫描与审计。

Anthropic 总结了三个产品化 containment 模式：

模式产品语境环境边界主要取舍
临时容器claude.ai code executionserver-side gVisor 容器、每会话临时文件系统、无本机文件访问blast radius 最小，但没有持久工作区和本地文件能力
Human-in-the-loop sandboxClaude Code本机 OS 级 sandbox，读默认允许，workspace 内写入，网络默认拒绝适合能读懂 Bash 的开发者；仍依赖用户注意力和信任提示时机
本地 VMClaude Cowork用户选择的 workspace 挂载进 VM，凭证留在 host keychain，VM 获得 scoped-down session token适合非技术用户；隔离更强，但启动、可观测性和本地 MCP 集成更复杂

这三个模式说明 containment 不能脱离用户能力讨论。开发者可以判断 rm -rf、npm install 和网络请求的风险，因此 Claude Code 可以把沙箱、人类审批和 Auto Mode 组合；知识工作者不应被要求判断 shell 命令，因此 Claude Cowork 更偏向绝对、always-on 的 VM 边界。

七类沙箱

通用托管沙箱（General-Purpose Managed Sandboxes）

提供 sandbox-as-a-service，通过 API 暴露任意 OCI 容器镜像，支持 shell、文件系统、网络和解释器。

代表系统：

  • Daytona：开发者环境转型，冷启动 <90ms
  • E2B：基于 Firecracker microVM
  • Modal：Python 平台，gVisor 隔离
  • Northflank：支持 Kata Containers、Firecracker、gVisor 并行，多后端自动扩缩容
  • OpenSandbox（阿里巴巴）：大规模通用沙箱
  • Docker Sandboxes（Docker, Inc.）：官方 microVM 方案（2025）

设计模式：短暂性优先、可选持久会话；Python/TypeScript SDK；支持任意 OCI 镜像。各系统在隔离强度与运营模式上分化：Docker Sandboxes 和 E2B 默认 microVM，而容器仍是通用选项。

OpenAI 2026 年 4 月 15 日更新的 OpenAI Agents SDK把沙箱作为原生运行配置纳入 SDK：开发者可以自带 sandbox，也可以接入 Blaxel、Cloudflare、Daytona、E2B、Modal、Runloop、Vercel 等提供商。这里的重点是沙箱提供商可替换，Agent 定义与编排逻辑不应硬绑定某一家执行基底。

Claude Managed Agents 提供了同一趋势的 Anthropic 形态：sandbox 不承载 session 和 harness，只作为可 provision、可执行、可失败重建的“手”。execute(name, input) -> String 把 sandbox 调用压成普通工具调用；provision({resources}) 让新 sandbox 能按标准 recipe 重新初始化。这个设计把沙箱从不可丢失的状态容器，变成可替换执行基底。

Computer-Use Agent 基础设施

在沙箱内封装完整桌面环境（通常经由 Xvfb + 窗口管理器或完整 VM），暴露像素坐标和击键动作给 Agent。

代表系统：Anthropic Computer Use、CUA（开源）、OSWorld（VM-based，兼作评估 harness）

与通用沙箱的权衡：桌面环境更重（启动更慢，更难多路复用），但可运行任何不提供 API 的应用程序——这是唯一支持该用例的执行模型。

代码特化沙箱（Code-Specialized Sandboxes）

针对代码生成、评估和数据分析优化，而非通用 shell 访问。

代表系统：

  • Judge0：代码评测沙箱，被大量 coding agent 评估 pipeline 复用
  • OpenAI Code Interpreter：ChatGPT Advanced Data Analysis 的生产级沙箱 Python 环境
  • sandboxed.sh：coding agent 的 shell 沙箱
  • langchain-sandbox：WebAssembly + Pyodide + Deno 运行时，本地无容器执行

趋势：从基于容器的代码沙箱向 WebAssembly-based 沙箱转移——WebAssembly 提供能力安全（capability-safety）、确定性执行和微秒级实例化，代价是 Python 标准库受限和原生扩展支持减少。NVIDIA 也为客户端 Agent 工作流倡导 WebAssembly 方案。

框架集成运行时（Framework-Integrated Runtimes）

执行环境与框架的编排循环、工具注册、提示约定捆绑，不能脱离框架独立使用。

代表系统：OpenHands runtime（Docker，集成 bash/IPython/Chromium/MCP/VSCode）、agent-infra sandbox（all-in-one 设计）、smolagents executor（local/Docker/E2B/Modal/WebAssembly 多后端）

核心权衡：bundle（开箱即用，功能覆盖全）vs compose（轻量可替换，更灵活）。MCP 等标准是否会降低 composition 成本，从而削减 bundle 方案的优势，是开放问题。

Pi 是 compose 路线的边界案例：它默认继承宿主用户与进程权限，不内置文件系统、进程、网络或凭证 sandbox。官方建议要么用 Gondolin Extension 把内置工具路由到 microVM，要么把整个 Pi 进程放进 Docker 或 OpenShell。前一种模式必须特别注意：其他 Extension 注册的工具仍可能在 host 执行；工具路由扩展并不会自动覆盖所有扩展能力。

浏览器评估环境（Browser Evaluation Environments）

同时承担沙箱（隔离 Web 执行环境）和评估 harness（提供可复现任务定义和自动化评估）双重角色。

代表系统：WebArena（自托管真实 Web 应用集群）、VisualWebArena（扩展多模态视觉 grounding）、BrowserGym + WorkArena（gym 风格接口，标准化基准测试）

双重功能特性使其有别于 §3.2.2 的 Computer-Use 类（操作系统级，而非浏览器级），并与 V 层（评估）产生直接接口。

OS 级权限沙箱（OS-Level Permission Sandboxes）

用操作系统原语（Linux 上的 bubblewrap、macOS 上的 Seatbelt、syscall 过滤用的 seccomp-bpf）实现细粒度文件系统和网络隔离，不提供全新 OS 镜像。

设计哲学：permission，not partition——目标不是给每个会话提供新的 OS 镜像，而是给 Agent 提供对现有主机的受限视图，使提示注入或幻觉命令无法修改敏感文件或泄露数据。

代表系统：

  • Anthropic sandbox-runtime：npm 包，基于 bubblewrap 的文件系统 + 网络 allowlist + 本地 HTTP/SOCKS5 代理
  • Claude Code sandboxing：内置于 Claude Code，消费上述 runtime 限制 bash 工具的文件系统和网络访问
  • IsolateGPT：用 seccomp 和 setrlimit 在 LLM-based Agent 系统间执行执行隔离，~30% 性能开销

与通用托管沙箱的权衡：OS 级权限沙箱比 microVM 托管沙箱提供更弱的对抗代码隔离，但在威胁模型是 prompt injection（而非完全对抗代码）时是合适选择。共享主机内核意味着内核漏洞仍在攻击面内。

Claude Code 的本机沙箱是这一类的产品化例子：macOS 用 Seatbelt，Linux 用 bubblewrap。Anthropic 报告启用沙箱后 permission prompts 减少 84%，说明环境层硬边界可以把权限问题从“每个动作都问人”转成“会话配置时设边界”。但 Claude Code 也暴露过信任边界时序问题：如果项目目录里的配置、hook 或 localhost listener 在 trust prompt 之前被解析或执行，攻击者提交的仓库内容就会先于用户同意进入执行路径。类似系统应把 project-open、config-load 和本地监听器当作来自互联网的输入，直到用户明确信任目录之后才解析或执行。

Codex CLI 的权限提示体现了这类本地 Agent 沙箱的边界：Codex 会把适用于内置 shell 工具的沙箱和审批规则放进开发者消息中，例如可写目录、网络访问和何时请求用户授权。但这些规则只适用于 Codex 自己提供的 shell 工具；通过 Model Context Protocol（模型上下文协议）接入的外部工具不自动继承该沙箱，必须由对应 MCP 服务器自己执行权限控制。

Codex 的子智能体继承父会话当前的沙箱和审批策略，父线程本轮启用的运行时覆盖也会应用到新子线程；自定义 Agent 可以进一步收紧为只读。交互式会话能展示其他 Agent 线程发起的审批，而无法请求新审批的非交互运行会失败并把错误返回父线程。委派因此不会天然扩大授权边界。

Model Context Protocol（模型上下文协议）的代码执行式用法说明了沙箱在工具密集 Agent 中的另一种角色：沙箱不只是运行 bash 或测试代码，也可以成为 MCP 工具之间的数据处理平面。Agent 写代码从 Google Sheets、Drive、Slack 或 Salesforce 等 MCP server 取数、过滤、聚合，再只把必要摘要打印给模型。这样能减少上下文暴露，但也意味着沙箱必须承担敏感数据驻留、网络出口、文件持久化和 MCP 工具权限的治理。

沙箱抽象层（Sandbox Abstraction Layers）

不是沙箱本身，而是在单一 API 后统一多个沙箱后端的接口，使 harness 在不重写 Agent 逻辑的情况下切换执行基底。

代表系统：SWE-ReX（统一 Docker/AWS Fargate/Modal/Daytona）、smolagents executor（local/e2b/modal/docker/blaxel/wasm 单一参数化接口）、K8s Agent Sandbox CRD（Kubernetes SIG Apps，声明式 API 暴露 gVisor 和 Kata Containers 作为可插拔后端）

这一类别的出现反映了一个成熟认知：执行基底应该是可替换的。将特定沙箱 API 硬编码到 harness 中，会将编排逻辑与单一供应商绑定。

OpenAI Agents SDK 的 Manifest 抽象也属于这个方向：它描述 Agent 工作区，而不是某个具体容器。Manifest 可以声明本地目录挂载、输出目录，以及 AWS S3、Google Cloud Storage、Azure Blob Storage、Cloudflare R2 等存储来源。这样模型看到的是稳定工作区语义，harness 再把这些语义映射到本地开发或生产沙箱。

VM containment：Claude Cowork 案例

Claude Cowork 面向一般知识工作，不假设用户能审查 Bash 或网络请求。Anthropic 的第一版设计把 Agent loop、代码执行和一部分本地 MCP server 都放进完整 VM：VM 有独立 Linux kernel、文件系统和进程表；用户选中的 workspace 与 .claude 目录被挂载进去；凭证留在 host keychain，不进入 guest。

Cowork 的隔离机制分两类：

机制执行位置作用root-in-guest 后是否仍有效
Hypervisor boundaryguest 外guest memory isolation是
vsockguest 外host transport，不暴露普通网络栈是
seccompguest 内阻断特定 syscall pattern否
Mount namespacesguest 内只让 workspace 可见否
Egress proxyguest 内domain allowlist否
Per-session userguest 内进程隔离否

这个分层很重要：guest 内机制仍有价值，但如果 Agent 获得 guest root，它们可能失效；hypervisor boundary 和 vsock 这类 guest 外机制才是更硬的边界。

后来 Cowork 改成 host-loop 模式：Agent loop 移到 host，代码执行仍留在 VM sandbox；本地 MCP server 也移到 host。这样 VM 启动失败时，Agent 仍能响应用户并帮助排错；需要访问本地数据库或进程的 MCP server 也更容易运行。安全影响较小，因为模型生成代码的执行面仍受 VM 文件系统和网络控制约束。这个案例说明“harness 在 host、untrusted compute 在 sandbox”常常比“整个 Agent 都塞进 sandbox”更可靠。

Managed Agents 的安全边界也遵循这个方向：Git token 可在 sandbox 初始化时用于 clone 和配置 remote，但不暴露给 Agent；MCP OAuth token 则留在 sandbox 外部的 vault，由代理按 session token 取用。沙箱因此不只是“跑代码的地方”，也是凭证不可达边界的一部分。

Cowork 还提供 read-only、read-write、read-write-no-delete 等文件挂载模式，用挂载能力表达风险差异。路径校验必须先解析 symlink，否则授权目录内的 symlink 可能指向目录外并逃出挂载边界。

Egress allowlist 不是目的地过滤

Cowork 的一个第三方披露案例说明：域名 allowlist 应被理解为能力授权，不是简单目的地过滤。攻击文件把隐藏指令和攻击者 API key 放进 workspace；Claude 读取文件后调用 api.anthropic.com 的 Files API，把 workspace 内文件上传到攻击者账号。egress proxy 只检查目的地，看到域名在 allowlist 上就放行；沙箱按设计工作，数据仍然外泄。

修复方式是在 VM 内加入 defensive MITM proxy，拦截发往 Anthropic API 的流量：只有携带 VM 自己 provisioned session token 的请求被放行；攻击者 key 被拒绝；会触发 server-side fetch 的 header 也被阻断。proxy 放在 VM 内而不是服务器端，是因为只有 VM 知道请求 provenance；服务器侧看不出这是 Cowork VM 的请求还是普通 API client。

这个案例给 Agent 沙箱设计一个通用原则：allowlist 的每个域名都等价于开放该域名上可达的全部功能面。允许 api.example.com 不是“允许出站到一个安全域名”，而是“授权 Agent 使用这个 API 的所有上传、下载、转发和间接访问能力”，除非代理能继续检查 token、header、路径、方法和数据流向。

威胁模型与沙箱逃脱

沙箱化 Agent 执行面临的威胁：

  1. Prompt injection：外部输入（网页、工具响应、文件内容）劫持 Agent 行为
  2. 目标错位（Goal Misalignment）：Agent 将沙箱逃脱作为达成任务目标的工具性子目标
  3. 组合放大（Compositional Amplification）：多工具访问使单个沙箱弱点在集成能力间级联

SandboxEscapeBench（Marchand et al., 2026）：在嵌套沙箱 CTF 设置中评估前沿 LLM，报告 15–35% 成功逃脱率（依容器配置），涵盖错误配置、权限提升错误、内核漏洞和运行时弱点。防御研究仍处早期阶段，且各系统威胁模型、评估协议、基线假设不一致。

部署模式

  • 自托管（Self-hosted）：开发者直接管理沙箱基础设施（OpenHands、SWE-agent 的默认模式）
  • 云（SaaS）：服务提供商管理基础设施（E2B、Modal、Daytona Cloud）
  • 混合/BYOC：Agent 逻辑与沙箱执行跨环境解耦（OpenHands SDK 的 Local+Remote Workspace 抽象、E2B 和 Northflank 的 BYOC 选项）

相关词条

参考来源
  1. 1. https://openreview.net/pdf?id=3hXEPbG0dh
  2. 2. https://openai.com/index/unrolling-the-codex-agent-loop/
  3. 3. https://openai.com/index/the-next-evolution-of-the-agents-sdk/
  4. 4. https://developers.openai.com/codex/subagents
  5. 5. https://www.anthropic.com/engineering/code-execution-with-mcp
  6. 6. https://www.anthropic.com/engineering/claude-code-auto-mode
  7. 7. https://www.anthropic.com/engineering/how-we-contain-claude
  8. 8. https://www.anthropic.com/engineering/managed-agents
  9. 9. https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/containerization.md
评论