# Agent 沙盒的对比和分析（修订版）

AI程序员
4 阅读23分钟

修订日期：2026-04-07
说明：这一版补齐了腾讯云、阿里云、字节/火山引擎等国内厂商，重新核对了上一版中的关键事实表述，并把参考来源改成了更细粒度的官方文档 / 官方仓库链接，而不是只给宽泛首页。

一、先说结论：上一版哪里需要修正

这次回查后，我认为上一版主要有三类问题：

1）覆盖面不完整

上一版把国际厂商和部分开源项目讲得比较多，但没有把腾讯云、阿里云、字节/火山引擎的公开方案系统纳入。这并不意味着这些厂商“没有产品”，而是上一版的资料覆盖不够完整。实际上，三家现在都已经有公开文档或官方方案页：

  • 腾讯云：Agent Runtime / Agent 沙箱
  • 阿里云：ACS Agent Sandbox、AgentRun BrowserTool / AIO Sandbox、AgentBay
  • 火山引擎：AI 云原生沙箱服务、VCI Agent Sandbox、AgentKit AIO/代码/浏览器沙箱

2）有些地方不算“硬错误”，但表述不够严谨

上一版里有一些内容更接近“分析判断”，但写法上容易让读者误以为它们是官方事实，例如：

  • “某厂商更像模型工具闭环，而不是独立卖通用沙盒云”——这类话本质上属于分析判断，不是厂商官方声明。
  • “某方案更成熟”——这也应当明确是作者判断，而不是官方结论。

这次修订里，我把这类内容尽量改成两层写法：

  1. 先写清楚官方文档明确写了什么；
  2. 再单独给出我的分析判断。

3）参考来源太粗，不足以支撑细节 claim

你指出“参考来源给得不太对”，这个反馈是对的。上一版参考来源的问题不在于“完全错”，而在于粒度太粗：很多地方只是给了产品主页、文档首页或者泛化链接，但没有做到“某个具体结论，对应某个具体页面”。

这次我改成了：

  • 尽量使用官方文档页面 / 官方仓库 README / 官方帮助中心；
  • 把“产品定位”“隔离边界”“状态保持”“浏览器能力”“兼容性”拆开引用；
  • 对于像 E2B 使用 Firecracker 这类信息，如果主要来自其官方博客或官方案例文章，就明确标注为“根据 E2B 官方博客/案例文章”，不再假装它来自产品主文档。

二、什么是 Agent 沙盒

1. 定义

Agent 沙盒，本质上不是一个“会跑 Python 的小工具”，而是一层给智能体提供隔离执行环境的运行底座。它通常要解决六件事：

  1. 让 LLM 生成的代码、Shell、文件操作能安全运行；
  2. 把执行边界隔离开，防止影响宿主机或其他租户；
  3. 管理网络、凭据、文件系统和生命周期；
  4. 在需要时提供浏览器、桌面、手机、VNC 等交互环境；
  5. 保留会话状态、进程状态或文件状态，以支持长任务；
  6. 提供日志、录制、回放、人工接管和审计能力。

2. 不能把“浏览器控制”直接等同于“沙盒”

一个常见误区是：

  • Playwright MCP、browser-use 这类东西，主要是“让 AI 更容易控制浏览器”；
  • OpenAI computer use、Anthropic computer use，主要是“模型看截图并输出动作，再由 harness 去执行”；
  • 真正的隔离边界，通常仍然来自：OS sandbox、container、microVM、Hyper-V、Kubernetes runtime，或托管浏览器会话本身。

也就是说，浏览器控制层 != 沙盒。浏览器控制只是执行面的一部分，沙盒是底层隔离与治理基础设施。

三、看 Agent 沙盒，最应该比较什么

1. 隔离边界（Isolation Boundary）

这是最核心的维度。

常见路线有四类：

  • OS 级沙箱：例如 Anthropic Claude Code 的 Seatbelt / bubblewrap。
  • 容器强化路线：例如 Docker、Cloudflare Containers、OpenSandbox、Kubernetes runtime。
  • microVM / 虚拟化路线：例如 AWS AgentCore Runtime、Azure Dynamic Sessions、Vercel Sandbox、阿里云 ACS Agent Sandbox、火山引擎 AI 云原生沙箱、腾讯云 Agent Runtime 文档中的 VM 级隔离描述。
  • 浏览器会话隔离：例如 Browserbase、Hyperbrowser、AWS AgentCore Browser 这类托管浏览器会话。

2. 执行面（Execution Surface）

不同方案差别非常大：

  • 有的只支持 Python（如 OpenAI Code Interpreter、Gemini Code Execution）；
  • 有的支持 多语言 + Shell + 文件系统；
  • 有的进一步支持 Browser / Desktop / Computer Use / Mobile；
  • 有的还能提供 VNC、录屏、人工接管、端口暴露。

执行面越完整，越接近“给 agent 一台隔离电脑”；执行面越窄，越像“模型的附属工具”。

3. 状态模型（State Model）

这是很多人最容易忽略的维度。

  • E2B：文档明确支持保留文件系统、内存、运行进程；快照也是文件系统 + 内存状态。
  • Runloop：Suspend/Resume 更偏磁盘快照；文档明确说 suspend 不会保留内存状态与运行中进程。
  • Daytona：更强调 sandbox 的生命周期、archive、process/fs/git/computerUse 组合能力。
  • Cloudflare Sandbox SDK：在 sandbox 仍 active 的前提下，文件、进程、shell session、环境变量都可持续存在。
  • AWS AgentCore Runtime：支持 stop/resume 后保留文件系统状态；isolated sessions 则强调多次调用间的上下文与用户隔离。

对真正的 agent 来说，状态模型比“冷启动 100ms 还是 500ms”更重要，因为它决定了 agent 能否“接着上次的任务继续干”。

4. 网络与凭据治理（Network / Credentials Governance）

真正生产可用的 Agent 沙盒，必须处理好出网与密钥问题。

  • Anthropic 文档明确强调：没有网络隔离，就可能发生外传；没有文件系统隔离，也可能被借道绕过网络限制。
  • OpenAI Codex Cloud 文档明确写到：agent phase 默认关闭互联网，只在 setup phase 可以联网装依赖；并支持 allowlist 和 HTTP 方法限制。
  • Docker Sandboxes 的官方文档强调：默认通过 host-side proxy 管理 HTTP/HTTPS 出网，原始 TCP/UDP/ICMP 被阻断；代理还可以做 credentials injection，而原始密钥值不会进入 VM。
  • Cloudflare 也提供请求代理方案，让凭据留在 Worker 侧。

5. 可观测性与人工接管（Observability / HITL）

如果任务涉及网页和长流程，录屏、回放、Live View、日志与人机接管的重要性，几乎和隔离本身同等重要。

  • Browserbase：Session Inspector、Live View、视频录制、rrweb 回放、网络/控制台/性能调试。
  • Hyperbrowser：liveUrl、rrweb + MP4 录制、stealth mode。
  • AWS AgentCore Browser：官方文档明确提到 live viewing、session replay、CloudTrail / 观测能力。
  • 阿里云 AgentBay Browser Use：文档提到可视化调试与会话录制。
  • 火山引擎 AIO Sandbox / AgentKit：官方文档和开发者文章强调可视化接管、浏览器 VNC、Terminal 等能力。

6. 生态兼容性（Compatibility）

很多团队不想被某一朵“沙盒云”锁死，所以兼容性正在变成重要卖点。

  • 腾讯云 Agent 沙箱：官方文档写明兼容社区开源沙箱协议，并给出 E2B 迁移场景。
  • 阿里云 ACS Agent Sandbox：兼容 Kubernetes 原生生态、E2B SDK、AgentScope。
  • 火山引擎 VCI Agent Sandbox：官方文档说明其基于社区 Agent Sandbox 做深度开发。
  • OpenSandbox：从一开始就走统一 sandbox API + 多 runtime 路线。

四、行业方案全景：大厂、国内厂商、独立供应商、开源社区

4.1 国际大厂 / 模型厂商

OpenAI

OpenAI 现在至少有三条相关线：

  1. Code Interpreter：模型可调用的 Python 沙盒工具；
  2. Codex Cloud Environments：给 coding agent 使用的云环境，agent phase 默认不开互联网；
  3. Computer Use：模型看截图并输出动作，由你的 harness 在浏览器或 VM 里执行。

事实层面：

  • Code Interpreter 是“在 sandboxed environment 中运行 Python”。
  • Computer Use 不是完整沙盒本身，而是让模型返回 click/type/scroll 等动作，由你的代码去执行。
  • Codex Cloud 文档写明：setup 阶段可联网装依赖，agent phase 默认关闭互联网，并通过 HTTP/HTTPS proxy 出网。

分析层面：

OpenAI 的强项仍然是“模型 + 工具 + 云环境 + 审批/安全”的闭环，而不是把“通用 agent 沙盒”单独抽出来做成基础设施产品。

Anthropic

Anthropic 的公开路线更偏“本地 / IDE agent 的安全控制模型”。

事实层面：

  • Claude Code 的 sandboxed bash 工具同时做文件系统隔离 + 网络隔离；
  • macOS 上用 Seatbelt，Linux / WSL2 上用 bubblewrap；
  • 其官方开源 sandbox-runtime 研究预览版也明确是基于原生 OS 沙箱和代理式网络过滤；
  • Anthropic 的工程文章说明，这套沙箱化能力是为了减少权限提示并提升自主性。

分析层面：

Anthropic 在“如何让 agent 在开发者机器附近更安全地执行”这件事上表述非常清晰，但它的公开定位更像安全框架和开发体验，而不是像 E2B / Daytona 那样主打远程 devbox 基础设施。

Google

Google 这块需要特别纠正上一版的写法。上一版只强调了 Gemini Code Execution 和 Vertex Extensions / Code Interpreter Extension，但现在还应该明确纳入 Vertex AI Agent Engine Code Execution。

事实层面：

  • Gemini Code Execution：官方文档明确说只能执行 Python；
  • Gemini / Vertex code execution 环境有预装库，但不能安装自定义库；
  • Vertex Extensions API 确实提供 code interpreter extension，但官方文档写明仅在 us-central1 区域提供；
  • Vertex AI Agent Engine Code Execution 是一个更直接的 agent sandbox 能力：官方文档写明它运行在安全、隔离、受管理的沙盒环境中，sandbox 创建可在 1 秒以内完成，执行状态（内存）可保留最多 14 天，且无法访问网络。

修正结论：

上一版关于 Google 的部分不算“完全错误”，但明显不完整。如果今天讨论 Agent 沙盒，Google 不能只写成“模型内置代码执行 + 扩展”，还应明确把 Vertex AI Agent Engine Code Execution 当作更接近“agent sandbox”的正式方案纳入比较。

AWS

AWS 在 2025–2026 的路线已经很清晰：Bedrock AgentCore 正在把 Runtime、Browser、Code Interpreter、Memory、Gateway、Observability 做成一整套 agent 平台。

事实层面：

  • AgentCore Runtime：每个用户 session 运行在 dedicated microVM 中；
  • Runtime 支持 stop/resume 后保留文件系统；
  • isolated sessions 用于在多次调用之间保持上下文，同时保证用户隔离；
  • AgentCore Browser 提供 session isolation、live viewing、session replay；
  • AgentCore Code Interpreter 是官方内建工具。

分析层面：

AWS 的重点不是“某个单点代码沙盒”，而是企业级 agent runtime。

Microsoft / Azure

Azure 现在也是双层结构：

  • 上层是 Azure OpenAI 侧的工具能力；
  • 下层是 Azure Container Apps Dynamic Sessions 这样的通用强隔离会话底座。

事实层面：

  • Dynamic sessions 提供 prewarmed session pools 和毫秒级分配；
  • 文档明确写它适合运行 LLM generated scripts 和不受信任代码；
  • Code Interpreter Sessions 文档明确写：每个 code interpreter session 由 Hyper-V boundary 完全隔离，并且就是为运行不受信任代码设计的。

分析层面：

Azure 的特点是：不只是给你一个“模型工具”，而是给你一个可以承载多类会话型 agent 工具的 serverless session 底座。

4.2 独立基础设施厂商：真正把“给 agent 一台电脑”做出来的公司

E2B

E2B 是当前最典型的 agent 沙盒基础设施之一。

事实层面：

  • 文档明确支持 pause/resume，恢复文件系统、内存和运行中进程；
  • snapshots 也是文件系统 + 内存状态；
  • 模板支持把 start command 做进 snapshot，使得 sandbox 创建后进程已在运行；
  • Desktop 模板提供 Ubuntu 桌面、XFCE、VNC 等 GUI 能力；
  • “底层使用 Firecracker microVM” 这件事，主要来自 E2B 官方博客 / 官方案例文章，而不是主产品文档。

修正说明：

上一版直接把 “E2B uses Firecracker” 写成了像产品文档的硬事实来源，这次我把它改成：根据 E2B 官方博客/案例文章，E2B 底层使用 Firecracker microVMs。

Daytona

Daytona 现在的定位非常明确：full composable computers for AI agents。

事实层面：

  • 官方文档直接把 sandbox 描述成 “full composable computers”；
  • 每个 sandbox 都有 dedicated kernel、filesystem、network stack；
  • SDK 直接暴露 process、fs、git、computerUse；
  • computerUse 相关文档说明会提供 desktop automation 相关接口。

分析层面：

Daytona 很像把“远程开发箱”和“agent 电脑”做成了可编排基础设施。

Runloop

Runloop 是更明确面向 software engineering agent 的 VM-based devbox。

事实层面：

  • 官方文档明确说用 virtual machine technology 做隔离；
  • Devbox 是 full-featured execution environment；
  • suspend/resume 只保留 disk state，不会保留内存状态和运行进程；
  • 这意味着 resume 后，daemon / 进程一般需要重启。

修正说明：

上一版如果让人觉得 Runloop 的 suspend/resume 和 E2B 一样能恢复运行进程，那就是误导。两者的状态模型并不相同。

Modal

Modal Sandboxes 是把“安全运行不受信任代码”纳入 AI 云计算平台的一条路线。

事实层面：

  • Modal 官方在 2025 年宣布 Sandboxes GA；
  • 文档支持 filesystem snapshots；
  • 产品页明确宣传可扩到 50,000+ concurrent sessions；
  • 默认 lifetime 5 分钟，最长可调到 24 小时。

分析层面：

Modal 的优势不在“桌面化”，而在“与其 AI 云计算体系深度一体化”。

Vercel Sandbox

事实层面：

  • 官方文档写明它用于运行 arbitrary code in isolated, ephemeral Linux VMs；
  • 概念文档写明使用 Firecracker microVMs；
  • 默认 timeout 为 5 分钟；
  • 支持 snapshots / persistent sandboxes。

分析层面：

Vercel 的风格是典型“平台化 compute primitive”，而不是传统开发环境产品。

Docker Sandboxes

Docker 这条线很有代表性，因为它把“给 agent 完整 Docker 能力，但不碰宿主机”做成了产品。

事实层面：

  • 每个 sandbox 都有自己的 Docker daemon、filesystem、network；
  • 官方安全模型明确写到：primary trust boundary is the microVM；
  • agent 在 VM 内有完整控制权，包括 sudo；
  • 默认 HTTP/HTTPS deny-by-default，raw TCP/UDP/ICMP 阻断；
  • credentials 通过 host-side proxy 注入，raw credential values never enter the VM。

分析层面：

这是一套很强的“宿主机保护”方案，但它也明确提醒：workspace 默认是 direct mount，agent 对工作区文件的修改会实时反映到宿主机目录。

Cloudflare Sandbox SDK

事实层面：

  • Cloudflare Sandbox SDK 基于 Containers；
  • 从 Workers 中即可执行命令、管理文件、启动后台进程、暴露服务；
  • 架构由 Workers + Durable Objects + Containers 组成；
  • session 文档说明：在容器 active 时，working directory、环境变量、shell state 可持续存在。

分析层面：

Cloudflare 不是“给你一台传统 VM”，而是把安全隔离执行直接内嵌到 edge application runtime。

4.3 浏览器 / Computer Use 专用沙盒

Browserbase

事实层面：

  • 提供 cloud browser session；
  • Live View 支持实时观看和控制；
  • Session Inspector 提供网络、控制台、性能和会话状态观察；
  • 每个 session 自动视频录制，并支持 rrweb DOM replay；
  • 文档明确指出 Live View 支持 human-in-the-loop，用于认证、captcha、异常处理等场景。

分析层面：

它不是通用 Linux 沙盒，而是“让 agent 可靠使用 Web”的托管浏览器基础设施。

Hyperbrowser

事实层面：

  • 是 cloud browser platform；
  • 每个 session 有 liveUrl；
  • 支持 rrweb 和 MP4 录制；
  • 支持 stealth mode。

Browser Use Cloud / browser-use

需要把开源层和托管层区分开看：

  • browser-use open source：更像 AI browser automation library；
  • Browser Use Cloud：提供 stealth browsers、captcha solving、residential proxies、managed infrastructure。

它更偏“浏览器执行层”，不是通用 agent devbox。

4.4 国内厂商：这次补齐的重点

腾讯云：Agent Runtime / Agent 沙箱

这是上一版最大的缺漏之一。

事实层面：

  • 腾讯云产品页明确把 Agent Runtime 定义为面向 Agent 原生执行范式的新一代基础设施平台；
  • 产品页写明支持 VM 级隔离、身份鉴权、审计与可观测；
  • 公开写出 100 毫秒级启动、状态保持、Code / Browser / Mobile / Computer Use 等原生执行环境；
  • 文档页写明 Agent 沙箱 支持毫秒级启动与数万实例并发，提供 Code、Browser、Computer 等多种沙箱类型；
  • 文档还写明支持 SDK、CLI、MCP、RESTful API，并兼容社区开源沙箱协议；
  • 快速入门页专门给了 E2B 兼容迁移 场景。

分析层面：

腾讯云这条线已经不是“一个小工具”，而是把沙箱、工具、网关、记忆、观测都纳入 Agent Runtime 平台的路线。上一版没写腾讯，确实是明显漏项。

阿里云：ACS Agent Sandbox

阿里云现在至少有两条相关线：

  1. ACS Agent Sandbox：更底座、更基础设施；
  2. AgentRun / AgentBay：更偏“工具化运行环境 / 多模态环境”。

ACS Agent Sandbox

事实层面：

  • 阿里云帮助文档直接把它定义为“新一代面向 AI 智能体的沙箱算力”；
  • 使用 MicroVM 级别隔离；
  • 支持内存级休眠唤醒、Checkpoint 克隆；
  • 最高每分钟 15K Sandbox；
  • 兼容 Kubernetes 原生生态、E2B SDK、AgentScope；
  • 提供计算 / 网络 / 存储端到端隔离；
  • 支持 Warm Pool 和百毫秒级创建；
  • 支持 Code Interpreter、Browser Use 等场景。

AgentRun：BrowserTool / AIO Sandbox

BrowserTool

  • 官方文档把它定义为运行在云端隔离容器中的无头浏览器实例；
  • 原生兼容 Playwright / Puppeteer；
  • 提供 CDP endpoint 和 VNC 调试。

AIO Sandbox

  • 官方文档明确写它是集成 BrowserTool + Code Interpreter 的统一云端隔离环境；
  • 支持同一会话中浏览器交互 + 代码执行；
  • 兼容 Playwright / Puppeteer；
  • 默认单实例生命周期最长 6 小时。

AgentBay

  • AgentBay 官方文档把自己定义成 “AI 时代的 Agent 云基础设施”；
  • CodeSpace 是代码执行环境；
  • Browser Use 是浏览器自动化模块；
  • 文档强调云端沙箱与网络隔离、SDK/MCP/ASP 接入、会话录制与可视化调试。

分析层面：

阿里云其实已经形成了“底座型沙箱（ACS） + 工具型沙箱（AgentRun） + 多模态 Agent 环境（AgentBay）”的分层布局。上一版没把阿里这几条线拆开，是不够完整的。

字节 / 火山引擎：AI 云原生沙箱服务、VCI Agent Sandbox、AgentKit

这也是上一版的重要缺口。

AI 云原生沙箱服务

事实层面：

  • 火山引擎方案页明确把它定义为面向 AI 推理、训练场景的新一代基础设施；
  • 写明提供安全、隔离、高效的云端沙箱环境；
  • 方案页给出 <150ms 启动、万级并发创建、有状态长时间运行、microVM 隔离等特性；
  • 场景中明确包括 RL、Vibe Coding、Deep Research、Computer Use。

AI 云原生 Agent 套件

  • 方案页明确列出 Computer Use、Code Sandbox、Mobile Use 等能力；
  • Computer Use 支持对 Windows / Linux 远程虚拟机进行鼠标、键盘、截屏操控；
  • Code Sandbox 支持多语言编译运行。

VCI Agent Sandbox

这一块非常关键，因为它是火山引擎在“Kubernetes 原生 Agent 沙箱”方向上的正式表述。

事实层面：

  • 官方文档说明：VCI 基于社区 Agent Sandbox 做深度开发；
  • 使用 Kata Container 实现强进程隔离、存储隔离、网络隔离；
  • 支持稳定标识、持久化存储、生命周期管理；
  • 支持系统盘快照、镜像缓存、快速恢复；
  • 场景明确包含 AgentServing、OpenClaw、AgentRL。

AgentKit / AIO Sandbox

  • 官方文档有“代码沙箱工具示例”和“浏览器沙箱工具示例”；
  • 文档写明 AIO Sandbox 中的代码沙箱支持基于 session_id 的会话复用；
  • 不同 session_id 使用独立沙箱环境；
  • 火山引擎开发者社区的官方技术文章则更清晰地把 AIO Sandbox 描述成一个把 Browser、Code、Shell、VNC、代理、MCP、鉴权整合到一个环境里的 All-in-One Sandbox。

分析层面：

火山引擎这边的布局其实非常完整：

  • 有底座型的 AI 云原生沙箱服务；
  • 有 Kubernetes 方向的 VCI Agent Sandbox；
  • 有产品化的 Agent 套件 和 AgentKit；
  • 还有面向实际 agent 任务的 AIO Sandbox。

所以上一版没有把字节 / 火山引擎写进去，确实是不应该的。

4.5 开源社区 / 自建平台

OpenSandbox（阿里开源）

事实层面：

  • 官方仓库将其定义为通用 AI 应用沙盒平台；
  • 提供 multi-language SDKs、unified sandbox APIs；
  • 支持 Docker / Kubernetes runtimes；
  • 面向 Coding Agent、GUI Agent、Agent Evaluation、AI Code Execution、RL Training。

Kubernetes Agent Sandbox

事实层面：

  • 官方站点明确把它定位为适合 AI agent runtimes 的 isolated, stateful, singleton workloads；
  • 提供 Sandbox CRD、生命周期管理、持久化存储、pause/resume、warm pool；
  • 支持 gVisor 和 Kata Containers 等不同隔离后端。

sandbox-runtime（Anthropic 开源）

  • 研究预览版；
  • 基于原生 OS sandboxing 和代理式网络过滤；
  • 可以用于 agent、本地 MCP server、bash 和任意进程的沙箱化。

OpenHands

  • 官方文档显示其默认推荐的 sandbox provider 是 Docker；
  • runtime architecture 文档说明 agent 在容器里执行 shell / file / code 等动作；
  • 在安全敏感场景中，官方文档建议使用 hardened Docker 配置。

Playwright MCP / browser-use

这两个项目很重要，但一定要归类正确：

  • Playwright MCP：官方定义是给 LLM 的 browser automation server；
  • browser-use open source：是 AI browser automation library，可本地或自托管运行；
  • 二者都很适合作为“agent 浏览器控制层”，但不能直接等同于隔离沙盒。

五、代表性方案横向对比（精简版）

方案主要定位隔离边界状态保持浏览器/桌面典型场景备注
OpenAI Code Interpreter模型原生代码工具平台托管沙盒会话级否数据分析、图表、Python 执行Python-only
OpenAI Codex Cloudcoding agent 云环境平台托管环境 + 网络策略环境级间接云端 coding agentagent phase 默认无公网
Anthropic Claude Code Sandbox本地/IDE agent 安全边界Seatbelt / bubblewrap命令级与配置级否本地代理执行强调 FS + 网络双隔离
Google Gemini Code Execution模型原生代码工具平台托管沙盒对话级否Python 推理只能执行 Python
Google Vertex Agent Engine Code Execution托管代码执行沙盒安全隔离受管 sandbox最长 14 天内存状态否agent code execution无网络，us-central1
AWS AgentCore Runtime企业级 agent runtimededicated microVMsession / FS 持久化配套 Browser企业 agent 托管Runtime/Browser/Code Interpreter 一体化
Azure Dynamic Sessionssession 池底座Hyper-Vsession 级可承载工具不受信任代码、LLM 代码预热池 + 毫秒分配
E2Bagent 虚拟电脑官方未在主文档直写底层；官方博客指向 FirecrackerFS + memory + process有 Desktop 模板coding / desktop agent状态模型很强
Daytonacomposable computers独立 kernel / fs / network stacklifecycle / archive有 computerUsecoding / desktop agent开发箱属性强
RunloopVM devboxVMdisk-only suspend/resume可配合工具软件工程 agent不保留运行进程
Modal SandboxesAI 云计算平台上的沙盒安全隔离容器/沙盒FS snapshots不是重点大规模 code execution50k+ concurrency 宣传明确
Vercel Sandboxcompute primitiveFirecracker microVMsnapshots / persistent beta否AI app/code runtime很平台化
Docker Sandboxes宿主机保护型 agent sandboxmicroVMVM 内状态持久否AI coding agentcredentials 不进 VM
Cloudflare Sandbox SDKedge sandboxContainers + DO + Workersactive session state否edge code execution很适合 Cloudflare 生态
Browserbase托管浏览器浏览器会话隔离session 级强Web agent录制/回放/HITL 强
Hyperbrowsercloud browser浏览器会话隔离session 级强Web agentliveUrl + rrweb + MP4
腾讯云 Agent 沙箱Agent Runtime 平台能力VM 级隔离支持状态保持Code/Browser/Computer/Mobile企业 Agent、RL、Research兼容 E2B 迁移
阿里云 ACS Agent Sandbox生产级 AI 智能体沙箱算力MicroVM内存休眠/唤醒 + checkpoint可支撑 Browser UseAgentServing / AgentRL兼容 K8s / E2B / AgentScope
阿里云 AgentRun AIO Sandbox一体化云端隔离环境云端隔离环境单实例生命周期最长 6hBrowser + Code一体化 agent 执行BrowserTool + Code Interpreter 集成
火山引擎 AI 云原生沙箱AI 推理/训练底座microVM有状态长运行可支撑 Computer UseRL / Research / Coding<150ms 启动
火山引擎 VCI Agent SandboxKubernetes Agent 沙箱Kata + Kubernetes快照 / 持久化 / lifecycle可扩展AgentServing / AgentRL基于社区 Agent Sandbox
OpenSandbox开源平台Docker/K8s 可插拔取决于 runtime可支持 GUI 场景自建平台平台属性强
Kubernetes Agent SandboxK8s 原生抽象gVisor/Kata 等后端持久化 + pause/resume + warm pool取决于模板自建 agent runtime标准化潜力很大

六、怎么选

1. 只需要“让模型会跑代码”

优先考虑：

  • OpenAI Code Interpreter
  • Gemini Code Execution
  • Vertex Agent Engine Code Execution
  • Azure Code Interpreter Sessions
  • AWS AgentCore Code Interpreter

适合：数据分析、数学、报表、图表、轻量脚本。

2. 需要“给 agent 一台隔离开发机 / 电脑”

优先考虑：

  • E2B
  • Daytona
  • Runloop
  • Modal
  • Vercel Sandbox
  • Docker Sandboxes
  • 腾讯云 Agent 沙箱
  • 阿里云 ACS Agent Sandbox
  • 火山引擎 AI 云原生沙箱 / VCI Agent Sandbox

适合：clone repo、安装依赖、起服务、持续会话、测试、长链路工程任务。

3. 核心任务是网页交互 / Computer Use

优先考虑：

  • Browserbase
  • Hyperbrowser
  • Browser Use Cloud
  • AWS AgentCore Browser
  • 阿里云 BrowserTool / AgentBay Browser Use
  • 腾讯云 Browser / Computer 沙箱
  • 火山引擎 Browser Session / Computer Use / AIO Sandbox

4. 必须自建 / 上 Kubernetes / 私有化

优先考虑：

  • OpenSandbox
  • Kubernetes Agent Sandbox
  • OpenHands
  • 火山引擎 VCI Agent Sandbox
  • 阿里云 ACS Agent Sandbox（偏 K8s 兼容）

5. 最看重安全与治理

应重点看：

  • 隔离是不是 microVM / Hyper-V / Kata 这种强边界；
  • 网络是不是默认 deny-by-default；
  • 密钥是不是不会直接进入沙箱；
  • 是否有日志、录制、回放、审批和人工接管。

真正生产可用的安全体系，不是“只有一个 sandbox 就够了”，而是：

执行隔离 + 网络/凭据治理 + 观测/审计 + 人工审批

七、我的修订结论

如果把今天的市场一句话说清楚：

Agent 沙盒正在从“代码解释器”升级为“给智能体一台有边界、有状态、可观察、可恢复的工作电脑”。

更细一点看：

  • OpenAI / Anthropic / Google 更强在模型原生工具与工具闭环；
  • AWS / Azure 更强在企业级 agent runtime；
  • E2B / Daytona / Runloop / Modal / Vercel / Docker / Cloudflare 更强在通用执行底座；
  • Browserbase / Hyperbrowser / Browser Use Cloud 更强在 Web 专用执行层；
  • 腾讯云 / 阿里云 / 火山引擎 现在都已经有了明确的公开产品路线，而且不应再被忽略；
  • OpenSandbox / Kubernetes Agent Sandbox / OpenHands / sandbox-runtime 代表了开源自建平台的重要方向。

八、参考来源（按厂商/项目分组，尽量使用官方文档）

OpenAI

Anthropic

Google

AWS

Microsoft / Azure

E2B / Daytona / Runloop / Modal / Vercel / Docker / Cloudflare

Browserbase / Hyperbrowser / Browser Use

腾讯云

阿里云

字节 / 火山引擎

开源 / 社区

avatar
文章
阅读
粉丝