Agent 沙盒的对比和分析

AI程序员
3 阅读18分钟

版本说明：本文基于截至 2026-04-07 可公开访问的官方文档与官方仓库整理，目标是从产品形态、隔离模型、状态持久化、浏览器能力、可观测性与开源生态几个维度，对“Agent 沙盒”做一份偏选型导向的全景梳理。

1. 什么是 Agent 沙盒

Agent 沙盒，本质上是给 AI Agent 提供的一层隔离执行环境。它不只是“能跑一段 Python 的代码解释器”，而是一个能承载以下能力的受控运行边界：

  • 执行 LLM 生成的代码、Shell 命令和文件操作
  • 管理依赖、进程、网络与生命周期
  • 在需要时提供浏览器、虚拟桌面或 computer use 能力
  • 对不同用户、会话、任务进行隔离，避免跨会话泄漏
  • 在必要时允许人工接管、回放、审计和复现

今天市场上被称作“Agent 沙盒”的产品，实际上可以分成四类：

  1. 模型原生代码解释器：例如 OpenAI Code Interpreter、Gemini Code Execution、Azure OpenAI Code Interpreter。
  2. 通用远程 Devbox / Sandbox / VM：例如 E2B、Daytona、Runloop、Modal、Vercel Sandbox、Docker Sandboxes、CodeSandbox SDK、Together Code Sandbox。
  3. 浏览器/Computer Use 专用沙盒：例如 Browserbase、Hyperbrowser、Browser Use Cloud、AWS AgentCore Browser。
  4. 开源/自建运行层：例如 OpenSandbox、Kubernetes Agent Sandbox、OpenHands Runtime、AIO Sandbox。

2. 先分清几个容易混淆的概念

2.1 代码解释器 != 完整 Agent 沙盒

代码解释器通常只提供受限的代码执行能力，最适合数据分析、数学推理、图表生成和轻量脚本任务。它的优势是模型集成度高，但通常不等于“一台完整的隔离电脑”。

2.2 浏览器控制层 != 沙盒

像 Playwright MCP、browser-use 这类方案，更准确地说是浏览器控制接口或 agent 控制层。它们负责让模型理解页面、执行点击、输入、导航，但真正的隔离边界通常来自底层浏览器会话、容器、虚拟机或 microVM。

2.3 Computer Use != 浏览器云

OpenAI Computer Use、Anthropic Computer Use 更像是“模型 + harness + UI 动作循环”；Browserbase、Hyperbrowser 则更像“托管浏览器基础设施”。两者经常组合使用，但不是一回事。

3. 评估 Agent 沙盒时最重要的 7 个维度

3.1 隔离边界

常见路线包括：

  • OS 级沙箱：如 Seatbelt、bubblewrap
  • 容器 / 强化容器：Docker、gVisor、Kata、Cloudflare Containers
  • microVM / VM / Hyper-V：Firecracker、Hyper-V、虚拟机 Devbox

如果要运行不受信任代码、多租户任务或外部用户提交的脚本，底层隔离边界通常比“能不能跑代码”更重要。

3.2 执行面（Execution Surface）

要区分产品到底提供的是：

  • 仅 Python
  • 多语言代码 + Shell
  • 完整文件系统
  • 长驻进程 / Web 服务
  • 浏览器 / 桌面 / VNC / Computer Use

3.3 状态模型

这是选型时最容易被忽略、但对 agent 体验影响极大的维度。不同方案的“持久化”完全不是一回事：

  • 有的只保留当前会话
  • 有的能保存文件系统
  • 有的还能保存内存 + 运行进程
  • 有的只支持磁盘快照，恢复后进程需要重启

3.4 网络与凭据治理

一个真正可用于生产的沙盒，不只是隔离文件系统，还必须管控：

  • 哪些域名或 CIDR 可以访问
  • 凭据是否暴露给沙盒内部
  • 是否支持出网代理、白名单和审计
  • 浏览器流量是否可控

3.5 可观测性与 Human-in-the-Loop

越接近真实 agent 落地，越需要：

  • 实时 Live View
  • 视频录制 / 回放
  • rrweb / DOM replay
  • 日志、网络面板、性能面板
  • 手动接管浏览器或桌面

3.6 自定义环境能力

面向软件工程 agent 的沙盒，往往需要：

  • 自定义镜像 / 模板 / 蓝图
  • 预装依赖
  • 快照恢复
  • Git / 代码挂载 / 端口暴露 / 隧道

3.7 集成方式

最后要看它是更适合：

  • 直接被模型工具调用
  • 作为 agent runtime 底座
  • 被 LangChain / AutoGen / MCP / 自定义 agent 框架接入
  • 在 Kubernetes / 企业私有环境中自托管

4. 行业方案梳理

4.1 大厂 / 模型厂商原生方案

OpenAI

OpenAI 目前相关能力分成三层：

  • Code Interpreter：模型原生 Python 沙盒
  • Codex Cloud Environments：把 repo、setup、网络控制、审批和 cloud task 环境串起来
  • Computer Use：模型输出 UI 动作，需要开发者提供浏览器或 VM harness 落地

这条路线的优势是：模型工具整合最顺、审批流完整、非常适合“模型自己决定何时执行工具”的产品体验。限制是：对外呈现上仍更像“模型原生执行能力”，而不是单独售卖的一朵通用 sandbox 云。

Anthropic

Anthropic 的公开路线更偏本地/IDE agent 的安全约束：

  • Claude Code Sandboxing：用 macOS Seatbelt、Linux/WSL2 bubblewrap 做 OS 级隔离，同时提供网络限制
  • Computer Use Reference Implementation：提供 Web UI、Docker 容器、agent loop 与工具示例
  • sandbox-runtime (srt)：开源研究预览，用原生 OS 沙箱和代理式网络过滤，支持 agent、MCP server、bash 与任意进程

Anthropic 的特点是：对“边界、审批、减少权限疲劳、让 agent 更自主但仍受控”解释得最系统。

Google

Google 的公开方案主要是两条：

  • Gemini Code Execution：Python-only，环境自带库，适合把代码执行作为模型推理工具
  • Vertex AI Code Interpreter Extension：通过 Extensions API 注册和调用 Google 提供的 Code Interpreter 扩展

适合场景是：你本来就在 Gemini / Vertex 生态里，需要低摩擦地补一个代码执行能力。限制是：执行面更窄，和完整 devbox/remote computer 还有明显距离。

AWS

AWS 在 2025-2026 的布局最像“企业级 agent runtime 平台”：

  • AgentCore Runtime：每个用户会话运行在 dedicated microVM 中，支持 MCP / A2A / AGUI 等协议
  • AgentCore Isolated Sessions：把多次调用间的上下文复用和用户间数据隔离做成一等能力
  • AgentCore Code Interpreter：面向安全代码执行
  • AgentCore Browser：托管浏览器会话，内建 live view、session recording、session replay、审计

如果你从云平台和企业安全角度看，AWS 这条路线已经不只是“代码沙盒”，而是完整的 agent 托管底座。

Microsoft / Azure

Microsoft 也在走双层路线：

  • Azure OpenAI Code Interpreter：模型原生 Python 沙盒能力
  • Azure Container Apps Dynamic Sessions：更底层的会话池 / 沙盒基础设施，强调预热、毫秒级分配、Hyper-V 隔离、适合运行不受信任代码

这意味着 Azure 既有“模型工具层”，也有“可做自定义 runtime 的沙盒底座”。对于企业内部 Agent 平台，自带会话池这一点很重要。

4.2 独立通用沙盒 / Devbox 厂商

E2B

E2B 是最典型的“给 agent 一台虚拟电脑”的路线之一：

  • 面向 AI-generated code 的安全云沙盒
  • 自定义模板里可以把启动命令和运行进程做进快照
  • pause / resume 支持恢复文件系统、内存和运行中的进程
  • 官方文档与博客明确围绕 Firecracker microVM 设计
  • 还有 Desktop 模板，提供 XFCE、noVNC、xdotool、scrot 等 GUI/桌面能力

E2B 的差异化在于：状态模型很强，不只是“保存磁盘”，而是强调恢复整个运行时状态。

Daytona

Daytona 更像“可编排的远程开发箱”：

  • 创建沙盒时可配置语言、快照、卷、区域、资源
  • SDK 暴露 process、fs、git、computerUse 等接口
  • 支持自动停止、自动归档、从 object storage 恢复
  • computer use 能力包含 mouse、keyboard、screenshot、display、recording，并启动 Xvfb / xfce4 / x11vnc / novnc

它非常适合做 coding agent、desktop agent 或远程开发型 agent runtime。

Modal

Modal Sandboxes 更像“云计算平台上的安全进程沙盒”：

  • 官方明确把 Sandboxes 定位为运行不受信任代码的原语
  • 适合有状态、多阶段交互
  • 支持文件系统快照
  • 支持 block_network 和基于 CIDR 的出网控制
  • 支持 idle timeout
  • 官方宣传可扩到 50,000+ 并发会话

如果你的团队本来就在 Modal 上做 AI 计算，Sandboxes 的整合度和规模化能力会很有吸引力。

Runloop

Runloop Devboxes 的定位很明确：

  • 用虚拟机技术保护 API keys、代码、敏感数据和内网系统
  • 既可短任务临时启动，也支持 snapshot / suspend / resume
  • Blueprints 和 Snapshots 都能构建定制环境
  • suspend 主要保磁盘，不保留运行中的进程内存
  • 支持 Code Mounts、Tunnels、Computer-ready Devbox

它非常适合软件工程 agent，特别是“需要改代码、起服务、开隧道、接代码库”的场景。

Vercel Sandbox

Vercel Sandbox 是 Vercel 新一代 compute primitive：

  • 目标就是安全运行不受信任或用户生成的代码
  • 面向 AI agents、code generation、developer experimentation
  • SDK 文档明确说会创建 ephemeral Linux microVMs
  • 公开仓库写明底层是 Firecracker MicroVM
  • 支持文件系统 snapshots，默认自动停止时间为 5 分钟

它更像“面向 AI 代码生成工作负载的轻量 microVM substrate”。

Docker Sandboxes

Docker Sandboxes 的思路非常直接：

  • 用 isolated microVM sandboxes 运行 AI coding agents
  • 每个 sandbox 都有自己的 Docker daemon、文件系统和网络
  • agent 在 VM 内有很高自由度，官方文档明确写到包含 sudo 权限
  • 通过 filtering proxy 控制 HTTP/HTTPS 出网；原始 TCP/UDP 默认阻断
  • 默认网络隔离，需要显式端口转发

如果你需要“给 agent 完整 Docker 能力，但不信任它碰宿主机”，这是很有代表性的路线。

Cloudflare Sandbox SDK

Cloudflare 的风格非常 edge-native：

  • Sandbox SDK 基于 Containers
  • 从 Workers 直接执行命令、管理文件、跑后台进程、暴露服务
  • 架构上由 Workers + Durable Objects + Containers 组成，强调 secure、stateful、isolated execution
  • Active 状态下保留 files、running processes、shell sessions 和 env vars
  • 可以把 sandbox 里的服务通过 preview URL 暴露出去

这类方案特别适合把“隔离执行”直接嵌进边缘应用或平台 API 中。

CodeSandbox SDK

CodeSandbox SDK 是很多人低估的选手：

  • 官方直接把它定义为“快速、安全地创建和运行沙盒”的 SDK
  • 底层是自己的 microVM infrastructure
  • 支持 VM checkpoint/snapshot restore、快速 clone
  • VM Sandboxes（旧称 Devbox）也是基于 microVM 的开发环境
  • 可配置 hibernation / inactivity 行为

它更偏“开发环境平台能力下放给 AI Agent”。

Together Code Sandbox / Code Interpreter

Together 把两个层次拆得很清楚：

  • Code Sandbox：可配置的 VM 开发环境，支持任意代码、依赖安装、服务运行
  • Code Interpreter：会话式代码执行能力，适合分析/实验类任务

如果你已经在 Together 上做模型推理，继续用它的 Sandbox / Interpreter 可以减少系统复杂度。

PPIO（国内路线）

PPIO 的 Agent 沙箱是中文市场里值得单独关注的一条线：

  • 系统级隔离
  • 启动时间低于 200ms
  • 支持 Python / JavaScript / C++ 等多语言
  • 支持暂停 / 恢复，恢复文件系统和进程状态
  • 支持后台执行
  • 提供 E2B 兼容 API，并给出 browser-use / E2B Desktop 的接入说明

对于国内部署、希望兼容 E2B 生态的团队，这条路径很现实。

4.3 浏览器 / Computer Use 专用沙盒

Browserbase

Browserbase 不是通用 Linux 沙盒，而是托管浏览器基础设施：

  • 平台化管理 headless browser fleet
  • 支持 custom extensions、file downloads、long-running sessions
  • 每个会话自动视频录制，可在 Session Inspector 中回放
  • Live View 支持实时观看与远程控制
  • 支持 network / console / performance 级别的调试信息
  • 提供代理、自动指纹管理和 CAPTCHA 处理

如果任务以网页登录、表单填写、抓取和人工接管为主，Browserbase 往往比通用 devbox 更合适。

Hyperbrowser

Hyperbrowser 也是明显的浏览器专用路线：

  • 每个 session 自带 liveUrl 用于实时观察/接管
  • 支持 rrweb web recordings 和 MP4 video recordings
  • 提供 stealth mode，面向反检测和 bot protection 场景

它不一定要成为“一台完整电脑”，而是优先把浏览器会话做成生产级运行面。

Browser Use Cloud

browser-use 的云产品提供的是：

  • stealth browsers
  • CAPTCHA solving
  • residential proxies
  • managed infrastructure
  • remote browsers / agents on-demand

更适合作为“浏览器 agent 执行层”，而不是通用多语言沙盒。

4.4 开源 / 自建平台

OpenSandbox

阿里开源的 OpenSandbox 是目前最像“平台级开源沙盒”的项目之一：

  • 多语言 SDK
  • 统一 sandbox APIs / protocol
  • Docker / Kubernetes runtimes
  • Command / Filesystem / Code Interpreter 等内建能力
  • Chrome / Playwright / VNC / VS Code 等示例
  • 支持 gVisor、Kata、Firecracker 等更强隔离后端
  • Kubernetes controller 提供资源池与批量交付能力

对想自建 agent runtime 平台的团队，这个项目非常值得重点研究。

Kubernetes Agent Sandbox

Kubernetes SIG Apps 的 agent-sandbox 代表了另一条很有前景的路线：

  • 提供 Sandbox CRD 与控制器
  • 面向 isolated、stateful、singleton workloads
  • 每个 Sandbox 有稳定 hostname 与网络身份
  • 支持持久化存储、生命周期管理、暂停/恢复
  • SandboxWarmPool 提供预热资源池
  • 抽象隔离后端，支持 gVisor / Kata 等 runtime
  • 例子里已经包含 AIO Sandbox、Jupyter、VNC、VSCode 这类环境

它的重要意义在于：开始把 agent runtime 作为 Kubernetes 原生对象来设计，而不是临时拼装 Pod/Deployment。

OpenHands Runtime

OpenHands 的 runtime 架构偏“agent 框架自带执行容器”：

  • 启动 Docker 容器作为 runtime
  • 后端通过 action execution server 与容器通信
  • 在容器内安全执行 shell、文件、Python 等 action
  • 文档额外强调在公网 / 安全敏感环境中应采用 hardened Docker 配置

这更适合作为框架内部的安全执行层，而不是通用 sandbox 平台。

AIO Sandbox

AIO Sandbox 试图把一大组能力装进一个环境里：

  • Browser
  • Shell
  • File
  • MCP
  • VSCode Server
  • Jupyter

这种一体化方案很适合 PoC、评测和组合式 agent 实验。

Anthropic sandbox-runtime（开源预览）

虽然它来自 Anthropic，但以开源生态视角看也很重要：

  • 使用 sandbox-exec / bubblewrap 等原生 OS 沙箱原语
  • 通过代理做网络过滤
  • 面向 agent、local MCP server、bash 和任意进程

它很有参考价值，尤其适合研究“本地 agent 的最小安全边界如何做”。

Open Interpreter：一个有用的反例

Open Interpreter 的价值很大，但它恰恰提醒我们：

  • “能执行代码”
  • 和
  • “能安全隔离不受信任 agent”

不是一回事。官方 README 明确强调它运行在本地环境里，拥有完整互联网访问和任意包能力。这对个人生产力很好，但不能当作多租户或高风险 agent 的安全边界。

4.5 编排层 / 抽象层 / 浏览器控制层

Playwright MCP

Playwright MCP 提供的是通过 MCP 暴露给 LLM 的浏览器自动化接口。它依赖 structured accessibility snapshots，而不是视觉模型；这非常适合当浏览器控制层，但它本身不是底层隔离边界。

browser-use（开源框架）

browser-use 的核心价值是：让 agent 更容易操作网页。它是浏览器 agent 框架，不是独立的安全边界；生产上常常要和 Browser Use Cloud、Browserbase、E2B、PPIO 这类执行层配合。

LangChain Deep Agents Sandboxes

LangChain Deep Agents 已经把 sandboxes 抽象成 backend，并支持 Modal、Daytona、Runloop。更重要的是，文档明确提醒：沙盒本身并不能阻止 prompt injection；如果不限制网络，仍可能发生数据外传。

ComputeSDK

ComputeSDK 的方向是“多家沙盒统一 API”：把 E2B、Daytona、Modal、Vercel 等 provider 统一到一个接口层。对于需要可移植性的团队，这类抽象会越来越重要。

AutoGen DockerCommandLineCodeExecutor

AutoGen 的 DockerCommandLineCodeExecutor 路线很传统，但很稳：就是把命令放进 Docker 容器里运行。它不一定最炫，但在很多企业内部工具里足够实用。

5. 关键对比结论

5.1 如果你只需要“模型会用代码”

优先考虑：

  • OpenAI Code Interpreter
  • Gemini Code Execution
  • Azure OpenAI Code Interpreter
  • Vertex AI Code Interpreter Extension

它们的优点是模型集成最顺、调用链最短；缺点是环境定制能力和“完整电脑”能力有限。

5.2 如果你需要“完整 Coding Agent / Devbox”

优先考虑：

  • E2B
  • Daytona
  • Runloop
  • Modal
  • Vercel Sandbox
  • Docker Sandboxes
  • CodeSandbox SDK
  • Together Code Sandbox

这类平台能更好承载：

  • clone repo
  • 装依赖
  • 起服务
  • 持久化状态
  • 暴露端口
  • 接浏览器/桌面

5.3 如果你的核心任务是网页交互

优先考虑：

  • Browserbase
  • Hyperbrowser
  • Browser Use Cloud
  • AWS AgentCore Browser

这些产品更看重浏览器稳定性、Live View、录制回放、代理、反检测、验证码和人工接管，而不是通用 Linux 计算能力。

5.4 如果你必须自建 / 私有化 / 上 Kubernetes

优先考虑：

  • OpenSandbox
  • Kubernetes Agent Sandbox
  • OpenHands Runtime
  • AIO Sandbox

这类方案更适合：

  • 有合规要求
  • 需要自定义隔离后端
  • 想与企业内网 / K8s / 现有平台深度整合

5.5 如果你最在乎状态持久化

这点差异非常大：

  • E2B：最强调完整状态恢复，包含文件系统、内存与运行进程
  • Runloop：更偏磁盘快照，恢复后进程通常需要自己重启
  • Daytona：归档更偏文件系统级状态
  • Cloudflare Sandbox SDK：Active 状态下能保留文件、进程、shell session 与 env vars
  • Vercel / CodeSandbox：更偏快照化和快速恢复环境

5.6 如果你最在乎“强隔离”

通常优先看：

  • AWS AgentCore Runtime / Code Interpreter Sessions（dedicated microVM）
  • Azure Dynamic Sessions（Hyper-V）
  • E2B（Firecracker）
  • Vercel Sandbox（microVM / Firecracker）
  • Docker Sandboxes（microVM）
  • Runloop（VM）

而 Cloudflare、OpenSandbox、Agent Sandbox 则更偏容器/强化容器/Kubernetes 可插拔隔离路线。

5.7 如果你最在乎观测与人工接管

优先看：

  • Browserbase
  • Hyperbrowser
  • AWS AgentCore Browser
  • Daytona（computer use + recording + VNC）

因为这些产品把 live view、recording、replay、remote control 当成一等能力，而不是附加功能。

6. 我对市场格局的判断

6.1 大厂在补“模型闭环”

OpenAI、Anthropic、Google、Microsoft 更擅长把模型、工具调用、审批、安全文档和少量执行能力串起来。它们最强的地方不是“卖一朵通用沙盒云”，而是把执行能力放进自家 agent 工具链里。

6.2 独立厂商在做“给 agent 一台电脑”

E2B、Daytona、Runloop、Modal、Vercel、Docker、CodeSandbox、Together 这类厂商，更像是在争夺 agent runtime substrate。它们的核心价值是：把 agent 需要的完整执行环境产品化。

6.3 浏览器赛道已经独立成类

Browserbase、Hyperbrowser、Browser Use Cloud、AgentCore Browser 说明：对于很多 agent 场景，浏览器不是附属能力，而是单独的基础设施层。

6.4 开源社区正在把“agent runtime”标准化

OpenSandbox、Kubernetes Agent Sandbox、OpenHands、AIO Sandbox，再加上 LangChain / ComputeSDK / AutoGen 这类抽象层，意味着行业开始从“有没有沙盒”走向“如何跨沙盒编排和迁移 agent”。

7. 选型建议（直接可用）

场景 A：做数据分析、报表、图表生成

选模型原生代码解释器即可：OpenAI、Gemini、Azure OpenAI、Vertex AI。

场景 B：做软件工程 Agent（改代码、跑测试、起服务）

优先 E2B、Daytona、Runloop、Modal、Vercel、Docker、CodeSandbox、Together。

场景 C：做 Web Agent / Computer Use Agent

优先 Browserbase、Hyperbrowser、Browser Use Cloud、AgentCore Browser；如果还要完整桌面或混合工作流，再看 Daytona、E2B Desktop、PPIO。

场景 D：做企业私有化 / 合规 / K8s 平台

优先 OpenSandbox、Kubernetes Agent Sandbox、OpenHands Runtime。

场景 E：需要国内部署，又想兼容现有 E2B 生态

优先看 PPIO。

8. 一句话结论

Agent 沙盒正在从“模型附带一个代码解释器”，演进成“给智能体一台有边界、有状态、可观察、可恢复的电脑”。

未来真正决定产品上限的，不是能不能跑代码，而是这五件事：

  1. 隔离边界够不够强
  2. 状态模型够不够完整
  3. 执行面是否覆盖代码 + 文件 + 浏览器 + 桌面
  4. 网络与凭据治理是否可控
  5. 是否能被你的 agent 框架、K8s 平台和业务流程稳定接入

参考来源

OpenAI / Anthropic / Google / AWS / Azure

独立沙盒 / Devbox 厂商

浏览器专用基础设施

开源、自建与抽象层

avatar
文章
阅读
粉丝