AI Agent 开发中的沙盒：格局、方案与选型

Agent 负责思考，沙盒负责执行。这篇把 2026 年的沙盒市场拆成四条路线——垂直托管平台、公有云方案、本地 Agent 隔离、开源自建，讲清容器 / gVisor / Kata / microVM 的真实差别，为什么“每小时单价”不可比，知名 Agent 产品各自怎么实现，以及一套可照抄的选型和安全清单。

先给结论

1. 沙盒不是 Agent 框架，而是 Agent 的“执行电脑”：Agent 负责思考和决策，沙盒负责把代码、Shell、文件、进程和网络关在一个可控环境里。
2. 2026 年的市场已经形成四路竞争：
   • 垂直托管平台：E2B、Daytona、Runloop、Blaxel、Fly.io Sprites、CodeSandbox SDK；
   • 公有云厂商与开发平台方案：Modal、Vercel Sandbox、Cloudflare Sandbox SDK、AWS AgentCore、GKE/Cloud Run Sandboxes、Azure Dynamic Sessions、CoreWeave；
   • 本地 Agent 隔离：Docker Sandboxes、Anthropic Sandbox Runtime，以及 Codex、Claude Code、DeepSeek Harness 自带的 OS 沙盒；
   • 开源自建：E2B、OpenSandbox、Tencent CubeSandbox、Kimi AgentENV、BoxLite、NVIDIA OpenShell、Kubernetes Agent Sandbox、Microsandbox、AIO Sandbox，再组合 Firecracker（AWS 发起并开源）、gVisor（Google 发起并开源）或 Kata Containers（OpenInfra Foundation 托管的社区项目）。
3. 对新团队，E2B 是最稳妥的通用起点；要长期保留“工作电脑”优先看 Sprites、Blaxel、Daytona、Runloop；在已有云生态内，优先用该生态的原生方案；要 GPU，优先 Modal、Northflank 或 Daytona。
4. 不要把普通 Docker 容器等同于安全沙盒。 容器共享宿主机内核；面对公网用户或 LLM 生成的不可信代码，应至少增加 gVisor（Google）/Kata Containers（OpenInfra Foundation 社区），风险更高时使用 Firecracker（AWS）等 microVM，或 Hyper-V（Microsoft）隔离的轻量 VM。
5. 必须区分 Agent Harness 与 Sandbox。 Codex、Claude Code、Pi、DeepSeek Harness 是负责循环、上下文和工具调用的 Harness；E2B、Sprites、CubeSandbox 等是执行隔离层。一个产品可以自带轻量本地沙盒，也可以把工具执行换到远端 microVM。
6. 真正的安全不止“防逃逸”：还要同时解决网络外传、秘密泄露和资源滥用。microVM 只主要解决第一类问题。

1. 基本概念与隔离方式

一个常见架构是：

用户请求
   ↓
Agent Runtime（模型调用、规划、工具选择、会话状态）
   ↓ Sandbox API
控制面（创建、暂停、快照、销毁、配额、审计）
   ↓
隔离执行环境（Shell / 文件 / 进程 / 浏览器 / 桌面）
   ├─ 文件系统与快照
   ├─ 网络出口策略
   ├─ Secret 代理/临时凭证
   └─ CPU、内存、磁盘、超时限制
   ↓
隔离底座（容器 / gVisor / Kata / microVM）

沙盒至少要回答六个问题：

• 隔离边界：进程、容器、用户态内核，还是独立 microVM 内核？
• 状态模型：一次性销毁，还是能暂停、恢复、快照、分叉？
• 网络模型：默认能访问全网，还是默认拒绝并按域名/CIDR 放行？
• Secret 模型：真实密钥是否会进入沙盒？能否通过代理在请求离开沙盒时才注入？
• 资源模型：CPU、内存、磁盘、进程数、最长运行时间是否有限制？
• 回传模型：Agent 最终交付的是 stdout、文件、补丁、Git 分支、网页预览，还是完整快照？

最容易混淆的是：Harness 决定“做什么”，Sandbox 限制“能做什么、在哪里做”；容器、gVisor、Kata、microVM 等是 Sandbox 可选择的隔离底座。

1.1 隔离方式的核心区别

这里的“强度”只是架构上的通常量级，不是安全认证。一个网络全开、Secret 裸放、长期不打补丁的“强隔离”平台，整体安全性完全可能差于配置严谨的轻量方案。

陌生术语可查文末附录 A。

2. 当前格局

2.1 垂直托管与通用平台

2.2 公有云厂商与开发平台方案

公开采用口径：每家最多列三个厂商或客户公开披露的代表案例；“—”只表示尚无足够明确的独立生产披露。“使用 AgentCore”也不等于必然使用其 Code Interpreter。

3. 价格为什么不能只看“每小时”

不同厂商至少有四种计费口径：

1. 按沙盒存活的配置资源计费：E2B、Daytona、Runloop、CodeSandbox、Northflank、Railway。Agent 等模型或网络时，通常仍为内存和 CPU 付费。
2. CPU 仅按活跃量，内存按墙钟/峰值：Vercel、Cloudflare、AWS AgentCore。I/O 密集 Agent 往往更便宜。
3. 按实际/活跃资源计费并自动 idle-to-zero：Sprites、Blaxel；适合长生命周期但低占空比的 Agent。
4. 按 max(资源请求, 实际使用) 计费：Modal。请求值设太高会直接浪费。

不同口径的“每小时”单价不能直接排序。做预算时应使用：

总成本 = 基础计划
       + 创建/构建费用
       + 活跃 CPU
       + 墙钟内存
       + 热/冷磁盘与快照
       + 镜像存储
       + 网络出站与固定 IP/网关
       + 并发扩容费
       + 日志、Durable Object、对象存储等附属资源

4. 开源自建方案

4.1 可自建方案对照

开源可自建既可能指完整多租户平台，也可能只是可嵌入的单机运行时。下表把部署形态、入口和复杂度分开，便于横向比较；“部署复杂度”是根据前置依赖、组件数量和生产运维要求做的相对评估，不是项目官方分级。

无论采用哪条路线，从“能启动第一个 sandbox”到“可承载不可信生产流量”之间，还要补齐：API 鉴权与 TLS、默认拒绝的 egress、Secret broker、资源和并发配额、镜像供应链、审计日志、数据/快照备份、版本升级与回滚，以及真实的逃逸和外传测试。一键安装成功不等于生产就绪。

5. 知名 Agent 产品怎样实现

本节把第 1 章的分层框架应用到具体产品，集中说明 Harness、执行隔离、状态和公开采用。

5.1 核心产品对照

这些产品可归纳为三种实现路线：

1. 本机 Harness + OS 沙盒：Codex CLI、Claude Code、DeepSeek Harness。启动快、体验自然，但仍共享宿主内核，适合“保护开发者电脑”，不适合把陌生用户代码直接做强多租户托管。
2. 托管 Harness + 每任务云环境：Codex Cloud、Claude Code Web、Manus、Notion Workers。控制面掌握会话，执行面是一任务一容器或 microVM，并通过代理控制 Git、网络和 Secret。
3. Harness 与 Sandbox 解耦：Pi + Sprites、Open SWE + Daytona、Devin Outposts、Managed Agents。工具协议是接缝，可在不重写 Agent loop 的情况下替换执行位置，是企业自有计算/BYOC 最常见的方向。

6. 场景化选型

第一次做 Demo

• 优先：E2B Hobby。API 简单、资料和集成多，也能自建。
• 如果更在意快速创建、长期工作区、Windows/GPU：Daytona，但要接受生产平台已经闭源。
• 如果是自己电脑上的 coding agent：优先 Docker Sandboxes；轻量方案可用 Codex/Claude/DeepSeek 自带 OS 沙盒，但理解它们不是 microVM。
• 只有自己运行可信脚本时，可以本地 Docker 起步；不要把它直接用于公网不可信代码。

数据分析 / Code Interpreter

• 通用：E2B。
• AWS 企业：AgentCore Code Interpreter。
• GPU、Jupyter、批量 Python：Modal。
• Cloud Run 内已有 Agent：Cloud Run Sandboxes。
• Azure 生态：Dynamic Sessions；注意最小一小时计费粒度。

Coding Agent / Devin 类产品

• 一次性任务、高并发：E2B、Daytona、Vercel。
• 长期保留环境、等 PR 评论再继续：Sprites、Runloop、Blaxel、Daytona。
• 自带 benchmark/eval：Runloop。
• 同时还要托管 API、数据库和 GPU：Northflank。

RL、评测和大规模 fan-out

• 托管：E2B、Runloop、Modal；需要 GPU 时 Modal/Northflank/Daytona。
• 自建通用平台：OpenSandbox、CubeSandbox 或 Kubernetes Agent Sandbox + gVisor/Kata/Firecracker。
• 训练专用自建：Kimi AgentENV；CoreWeave 用户可直接看 CoreWeave Sandboxes。
• 关键能力不是单个沙盒启动快，而是模板缓存、快照 fork、并发额度、批量创建速率、失败回收和可观测性。

Browser / Computer Use

浏览器沙盒是相邻但不同的子市场：它除了代码隔离，还要管理 Chrome、Cookie/Profile、Playwright/CDP、VNC/截图与反机器人问题。可看 E2B Desktop、Daytona Computer Use、Runloop Browser/Computer、AWS AgentCore Browser、AIO Sandbox。若 Agent 只操作网页，Browserbase 一类专用浏览器平台通常比通用 Linux 沙盒更合适。

严格合规、VPC 或 On-prem

• 快速托管/BYOC：E2B Enterprise、Northflank BYOC、Daytona Customer-Managed Compute。
• 真正自控：OpenSandbox、CubeSandbox、OpenShell 或 Kubernetes Agent Sandbox，底层配 gVisor/Kata/Firecracker；单机嵌入可看 BoxLite。
• AWS/GCP/Azure 原生团队优先考虑 AgentCore、GKE Agent Sandbox、Azure Dynamic Sessions，能少维护一套 IAM、审计和网络体系。

7. 安全上最容易踩的坑

沙盒至少要同时覆盖三条防线：

1. 防逃逸：Agent 不能读宿主机、杀宿主进程或影响别的租户。靠 microVM/gVisor/Kata、内核补丁和多层隔离。
2. 防外传/越权：即使代码没逃逸，也不能把可访问的数据发到任意域名。靠默认拒绝网络、域名/CIDR allowlist、私网、Secret broker、短期凭证。
3. 防资源滥用：防 fork bomb、挖矿、无限下载、磁盘写爆和账单攻击。靠 cgroup/VM quota、进程数限制、磁盘配额、超时、并发上限和预算告警。

上线前最低清单：

• 默认 无互联网；按任务动态放行域名，禁止任意 TCP/UDP 出站。
• 不把生产 API Key 作为环境变量直接交给 Agent；使用代理注入、临时 token 或最小权限账号。
• 每个用户/任务独立沙盒，禁止多个不可信租户共享可写文件系统。
• 设置 CPU、RAM、磁盘、PID、文件大小、执行时间、并发和创建速率上限。
• 快照、模板和上传文件都视为不可信输入；恢复后仍要执行同样策略。
• 对命令、网络、文件变更、Secret 使用、生命周期事件保留审计日志。
• 端口预览默认鉴权，分享链接要短时有效，不要默认公开。
• 定期做逃逸测试、恶意包安装、DNS/HTTP 外传、fork bomb、磁盘写满、暂停/恢复后策略保留等测试。

8. 如何做自己的 PoC 评测

不要只比较厂商宣称的冷启动。用自己的 workload，对每家重复至少 30 次并记录 P50/P95：

1. 创建空沙盒到第一条命令完成；
2. 从自定义模板创建并安装依赖；
3. clone 中型仓库、运行测试、启动 dev server；
4. 暂停/恢复、快照/fork、失败重试；
5. 100/1000 并发下的创建成功率与限流；
6. Agent 等待模型 90% 时间时的实际账单；
7. 默认网络、Secret 注入和端口暴露是否安全；
8. API 断线、进程仍运行、控制面重试时是否幂等；
9. 数据驻留、日志、删除与快照保留是否符合合规要求；
10. 用同一月度负载把计划费、存储、出网、并发和附属服务全部算入。

9. 最终建议

如果没有既有约束，可以按下面的顺序缩小范围：

1. 先定信任级别：可信内部代码可用容器；不可信用户/LLM 代码用 gVisor/Kata/microVM；强多租户优先 microVM。
2. 再定状态模型：秒级任务选 ephemeral；编码/研究 Agent 选 pause/resume + snapshot/fork；长期服务选 idle-to-zero + 持久磁盘。
3. 再定部署模型：小团队先 SaaS；已有云平台团队选云原生；法规、数据驻留或成本规模足够大时再 BYOC/自建。
4. 最后比较价格：用真实 active CPU 比例和快照/网络成本，不要拿不同计费口径的“每小时”单价直接排序。

数据说明

• 价格均来自各厂商公开页面，可能按区域、合同、资源类型和时间变化；未找到独立公开单价的方案明确标成预览或联系销售，而不是猜价。
• “启动速度”是厂商口径，测试条件不统一，本文没有据此做绝对排名。
• Star 快照更新于 2026-09-01。Star 只表示关注度，不等于安全性、活跃度或生产成熟度。Daytona 仍有 7 万多 Star，但 2026 年 6 月后的生产代码已经闭源；DeepSeek Harness 20 万+ Star 也不表示其本地进程沙盒等于强隔离云平台。
• “开源”严格区分：完整数据面/控制面可自建，与只公开 SDK、CLI、示例完全不是一回事。

附录 A：核心术语