07 场景与成本
本章导读｜预计 18 分钟
到这一章为止，你已经会拆机制（第 4 章）、会挑隔离后端（第 5 章）、也知道该防什么（第 6 章）；产品有哪些留到下一章（第 8 章）再讲。但真正开工前你最先要回答的是另一个问题：我这个场景，到底需要什么样的沙箱？
这一章把「场景」变成可操作的选型输入。两条主张先放在这里：
- 场景不按行业分，按四个属性分——沙箱里跑什么 / 跑多久 / 要不要留状态 / 谁在指挥。这四个定下来，选型基本被逼死。
- 每个场景只有一个主导成本项——账单会被什么撑爆，答案通常直接指向该用哪类沙箱。（这一条是我的归纳，不是任何来源的说法；理由在 7.3 末尾。）
⚠️ 本章出现的 star / 冷启动数字都带快照日期，会腐；但「场景 → 需求 → 成本」这套判断方法不会过时——请把重点放在方法，而不是记住名单。
7.0 先描述场景：四个属性
Section titled “7.0 先描述场景：四个属性”在挑项目之前，先用四句话把你的场景说清楚。这四句是「需求」，与第 8 章的「供给」是一对：需求定下来，能选的供给自然收窄。
| 属性 | 取值（举几个） | 它逼死哪个设计选择 |
|---|---|---|
| 沙箱里跑什么 | 代码片段 / 整个仓库 / 浏览器 / 模型训练任务 | 镜像多大、要不要 GPU、要不要 GUI |
| 跑多久 | 秒级 / 分钟级 / 小时级 / 常驻 | 能否用一次性环境，还是必须持久 + 暂停恢复 |
| 要不要留状态 | 一次性 / 工作区持久 / 快照分叉 | 决定选「用完就丢」还是「带快照的 microVM」 |
| 谁在指挥 | 你的 agent / 用户的 agent / 第三方工具 / 平台自己 | 决定凭据模型与网络策略（见 7.1 分叉 A） |
一句话记住用法：看一个沙箱项目 README 里「for AI agents」这种泛泛描述没有信息量，要看它为哪个属性做了优化。 一个主打「毫秒级冷启动」的项目和一个主打「可分支的 VM」的项目，优化目标根本不同。
7.1 两个架构分叉（比选项目更重要）
Section titled “7.1 两个架构分叉（比选项目更重要）”项目名单会变，但下面这两个分叉不会。分叉选错，后面挑哪个项目都救不回来。
分叉 A：agent 在沙箱里，还是在沙箱外？
Section titled “分叉 A：agent 在沙箱里，还是在沙箱外？”这是最容易被忽略、却决定了一整套设计的分叉。
| agent 在沙箱内 | agent 在沙箱外 | |
|---|---|---|
| 沙箱的角色 | 一整台机器，装着 harness + 模型凭据 | 只是一个工具执行器 |
| 出网要求 | 必须放行模型 API 的域名 | 沙箱本身可以完全断网 |
| 观测点 | 沙箱内（日志、PTY、屏幕） | 主服务侧（沙箱只回传结果） |
| 凭据模型 | 凭据要放进沙箱或经代理注入 | 凭据留在控制面 |
| 典型 | Upstash Box、clawk、vibekit、OpenClaw in Sandbox | E2B 的多数用法、agent-sandbox 的「Sandboxed Tools」模式 |
公开事实：Upstash 的对比文章把这条讲得最直白——一类产品是「安全边界」，另一类是把「整个 agent 塞进盒子，只给你一个 prompt」。（来源：Upstash 对比文章，经调研 agent-sandbox-use-cases.md 转述。）
为什么这条比选项目重要？因为两类东西混着比会得出错误结论：把「agent 在沙箱内」的产品按「沙箱外」的标准挑，你会嫌它出网策略太松、镜像太重；反过来又会嫌另一类没有屏幕观测。先站队，再比较。
分叉 B：状态模型
Section titled “分叉 B：状态模型”第二件事是沙箱要不要记住这次执行。三个档：
- 一次性（ephemeral）：跑完即弃。实现最简单、成本最低，也最容易复用（回到预热池）。
- 工作区持久（workspace）：文件、依赖、git 跨会话留存。多步任务的前提。
- 快照分叉（snapshot / fork）：从同一个状态复制出 N 份并行尝试，或沿时间回退到某一步。
第三档里有三个常被混为一谈的东西，它们其实不是同一件事：
| 机制 | 它做什么 | 复制的方向 | 代表性项目 |
|---|---|---|---|
| 快照分叉（fork） | 从同一状态复制出多个副本，各自并行推进 | 并行铺开 | E2B（公开文档写明 fork 上限 100 份） |
| 可分支的 VM（branchable VM） | VM 状态本身可分支出多条线，各带独立生命周期 | 并行铺开 | smolvm |
| 回溯（backtracking） | 回到过去的某一步重跑，用于分析或调试 | 沿时间回退 | arrakis |
怎么避免混：先看「复制的是宽度还是时间」。fork 和 branchable VM 都是宽度——同一刻复制 N 份；区别在复制发生在哪一层，E2B 是云服务 API 层面，smolvm 是 VM 本体层面。backtracking 是时间——不是复制副本，是退回去重来，所以它服务的场景（安全分析、调试）和前两者不同。
公开事实：E2B 官网自列的五类场景之外，还写明 fork 上限 100 份、egress 按 CIDR / hostname 控制、凭据在 egress 代理处注入。（来源：E2B 官网 markdown e2b.dev/index.md，经调研 agent-sandbox-use-cases.md 引用。）
快照分叉是 microVM 系对容器系最大的功能优势——容器侧要靠 CRIU 才能做到，且没这么整齐。这块的机制细节（快照 ≠ 预热池）见第 4 章，本章只用到「有还是没有」这个判断。
7.2 九个场景
Section titled “7.2 九个场景”下面九个场景，每个都按同一副骨架写：谁 + 硬需求 + 状态 + 命门（主导成本）+ 推荐 + 坑。骨架固定下来，你就能只看「命门」那一行——它能直接回答「我的账单会被什么撑爆」。
读法：不要通读九个。先找出和你最像的那一个，只读它，再回 7.3 的表。
场景 1：代码解释器 / 数据分析
Section titled “场景 1：代码解释器 / 数据分析”- 谁：ChatGPT 高级数据分析一类产品、BI 工具、报表生成、论文复现。
- 硬需求：秒级冷启动、科学计算栈预装、富输出回传（图 / 表 / DataFrame）。
- 状态：多为会话内一次性。
- 命门：冷启动。这是唯一一个把启动延迟当第一指标的场景——用户坐在那里等结果，几百毫秒和几秒的差别就是体验的生死线。
- 推荐：E2B Code Interpreter、microsandbox、llm-sandbox；只判题、不要 agent 抽象就用 judge0 / piston。
- 坑：富输出的序列化（图片怎么回传、大 DataFrame 怎么截断）通常比隔离本身更费工。
场景 2：Coding agent（仓库编辑类）
Section titled “场景 2：Coding agent（仓库编辑类）”- 谁：Claude Code / Codex 一类、Aider、Ramp 的后台编码 agent、各家的「Devin 替代」。
- 硬需求：持久工作区、git 操作、装依赖、跑测试、分钟到小时级运行、能暂停恢复。
- 状态：工作区持久 + 快照。
- 命门：依赖安装与状态留存。每步都重装环境的 coding agent 会慢一个数量级，也没法迭代——它省下的不是钱，是「这个 agent 还能不能干活」。
- 推荐：vibekit、container-use、clawk、kubernetes-sigs/agent-sandbox（有现成的 Claude Code / Aider 示例）。
- 坑：git 凭据必须走代理注入，别把 token 写进沙箱；另外 PR 回写路径、测试环境的网络白名单都要提前设计。
场景 3：浏览器 / 桌面 computer-use
Section titled “场景 3：浏览器 / 桌面 computer-use”- 谁：browser-use 类、GUI 操作 agent、Playwright 抓取与截图。
- 硬需求：有头浏览器、CDP 或 VNC、固定分辨率、可选的 GPU（给 VLM 推理用）。
- 状态：多为会话级，但需要「上一次的页面还在」。
- 命门：内存密度。一个 Chromium 就 1GB 起，并发的成本是纯线性的——第一个浏览器不贵，第一千个浏览器才贵。
- 推荐：agent-infra AIO Sandbox（Browser + Shell + VSCode + Jupyter 一容器）、trycua/cua（跨 OS 桌面）、agent-sandbox 的 Playwright / Chrome 示例。
- 坑：反爬指纹、浏览器崩溃后的会话恢复、截图流的带宽。
场景 4：评测与 RL 训练（需求最特殊）
Section titled “场景 4：评测与 RL 训练（需求最特殊）”- 谁：SWE-bench / terminal-bench 一类评测、NVIDIA NeMo Gym、WebGym、各家做 agent 训练的数据管线。
- 硬需求：千级并行、完全可复现、固定或无外网、快速重置、批量调度与配额。
- 状态：一次性，但镜像必须完全确定。
- 命门：调度与镜像分发，不是隔离。评测场景的瓶颈往往不在单个环境的强度，而在「能不能同时起一千个、镜像拉得动吗」。
- 推荐：kubernetes-sigs/agent-sandbox（WarmPool / Kueue / Ray / NeMo Gym 都有官方示例）、OpenSandbox 的批量创建。
- 坑：环境漂移会让评测数字不可比；镜像拉取时间经常超过任务本身。
- 证据（公开事实）：Hugging Face 用 E2B 复现 DeepSeek-R1 的 RL 管线，是这类场景被公开引用最多的案例。（来源：经调研
agent-sandbox-use-cases.md引用。）
场景 5：常驻多租户 / agents-as-a-service
Section titled “场景 5：常驻多租户 / agents-as-a-service”- 谁：托管型个人 agent（OpenClaw 类）、「AI 员工」、per-user 工作区。
- 硬需求：按用户分配、预热池、suspend/resume 省闲置成本、状态在 PVC 上存活。
- 状态：长期工作区。
- 命门：闲置成本。常驻但不干活的时间必须能被压到接近零——这一项的账单和你用户数成正比，和你流量无关。
- 推荐：agent-sandbox（有「Hermes Agents as a Service」完整模式：per-user claims + warm pool + suspend/resume + PVC 存活）、E2B 的 pause/resume。
- 坑：状态迁移（节点下线时用户的文件怎么办）、配额与滥用。
场景 6：工具执行 / MCP server 隔离
Section titled “场景 6：工具执行 / MCP server 隔离”- 谁：第三方 MCP server、插件市场、把 tool call 当不可信输入的平台。
- 硬需求：最小权限、每调用级策略、凭据不出沙箱、低延迟。
- 状态：一次性，但沙箱要复用（每次起太慢）。
- 命门：策略粒度。要能说清「这个工具只能读这个目录、只能连这个域名」——粒度不够就是给了它整个机器。
- 推荐：anthropic
srt、nono（per-tool-call brokered sandboxing）、agent-sandbox 的 MCP Sandbox 示例。 - 坑：复用沙箱 + 每次调用换策略，这两件事在实现上会打架（沙箱状态是热的，策略是冷的）。
场景 7：用户可编程平台 / AI app builder
Section titled “场景 7：用户可编程平台 / AI app builder”- 谁：低代码平台、内嵌代码执行的 SaaS、生成应用并预览的产品。
- 硬需求：多租户强隔离、按租户配额、预览 URL、冷启动要快、防滥用（挖矿）。
- 状态：项目级持久 + 会话级临时。
- 命门：计费与防滥用。这一类的沙箱量按「生成的应用数」走，量级可以是 CDN 级；但只要有一个人拿它挖矿，账单就能盖过整月营收。
- 推荐：E2B、OpenSandbox、Vercel Sandbox（按 active CPU 计费，等模型时不计费）。
- 证据（公开事实）：Modal 公开的 Lovable 案例——48 小时内 100 万+ 沙箱，约 25 万次应用创建，沙箱纯粹当「生成应用的预览环境」用。这是把沙箱当 CDN 级基础设施在跑的样本。（来源：Modal 公开数据，经调研
agent-sandbox-use-cases.md引用。）
场景 8：安全分析（沙箱的原始场景）
Section titled “场景 8：安全分析（沙箱的原始场景）”- 谁：红队、恶意样本分析、渗透测试 agent。
- 硬需求：强隔离、网络可完全切断或仿真、快照回滚、行为采集。
- 状态：快照回滚为主。
- 命门：可观测性（进程、文件、网络行为都要留痕）。注意——这一项不落在 7.3 的七个成本维度里，它是本章单独点名的一个：这里你要的不是省钱，是「看得见刚才发生了什么」。
- 推荐：arrakis、自建 Firecracker。
- 坑：这个场景几乎不需要「agent 抽象」，反而需要完整的系统调用与网络行为记录，和 agent 沙箱的关注点正交。别硬套前六个场景的框架。
- 覆盖度提示：这一档开源方案样本少，结论偏弱（见章末「还不确定的地方」）。
场景 9：CI/CD 里的 agent
Section titled “场景 9：CI/CD 里的 agent”- 谁：GitHub Agentic Workflows 一类、自动修 PR 的流水线。
- 硬需求：与 CI 集成、无状态、权限最小、审计留痕。
- 状态：一次性。
- 命门：启动与清理——CI 里每次运行都要起一个、用完即弃，冷启动和回收速度直接乘在流水线时长上。
- 推荐：Docker Sandboxes（2026-07 起被 GitHub Agentic Workflows 支持）、agent-sandbox 的 CI/CD 模式。
- 坑：CI 本身已经有隔离，沙箱是第二层，别把两层的凭据搞混。
- 覆盖度提示：同上，开源方案覆盖度最弱的一档，样本少。
关于「公开事实」的核对：kubernetes-sigs/agent-sandbox 的 Use Cases 官方分 6 类（Code Execution、Coding Agents、Computer Use、CI/CD、Agents in Sandbox、Self-Hosted Sandboxes），More Examples 下有 40+ 具体示例（RL、NeMo Gym、Ray、Kueue、KEDA、Hermes agents-as-a-service、MCP、Playwright、VSCode、JupyterLab 等）——上面场景 2、3、4、5、6、9 的推荐都能在里面找到落点。（来源：该仓库 Use Cases 文档，经调研
agent-sandbox-use-cases.md引用。）
7.3 场景 → 主导成本
Section titled “7.3 场景 → 主导成本”先把七个成本维度解释清楚（每个一行白话），再看矩阵。
| 成本维度 | 一句话解释 |
|---|---|
| 冷启动 | 从「收到请求」到「代码能跑」的等待时间 |
| 依赖安装 | 每次执行重新装环境的时间与带宽 |
| 内存密度 | 单机能塞多少个环境，直接决定单环境成本 |
| 调度与镜像分发 | 批量起环境时，调度器和镜像分发的吞吐 |
| 闲置成本 | 环境存在但不干活时占用的资源 |
| 策略粒度 | 能不能按调用说清「能碰什么」，说不到就得出事 |
| 计费与防滥用 | 计量是否准、能不能挡住挖矿这类滥用 |
矩阵里 ● 表示主导成本（账单会被它撑爆的那一项），○ 表示次要成本：
| 场景 | 冷启动 | 依赖安装 | 内存密度 | 调度&镜像 | 闲置 | 策略粒度 | 计费&滥用 |
|---|---|---|---|---|---|---|---|
| 1 代码解释器 | ● | ○ | |||||
| 2 Coding agent | ○ | ● | ○ | ○ | |||
| 3 浏览器 / 桌面 | ○ | ● | |||||
| 4 评测 / RL | ● | ○ | |||||
| 5 常驻多租户 | ○ | ● | |||||
| 6 工具执行 / MCP | ● | ○ | |||||
| 7 用户可编程平台 | ○ | ○ | ○ | ● | |||
| 9 CI 里的 agent | ● | ○ | ○ |
（场景 8 安全分析的主导项是可观测性，不在这七维内，见 7.2 场景 8。）
为什么「每个场景只有一个主导成本项」——这是归纳，不是来源的说法。 证据是各厂商各自强调的瓶颈不一样：E2B 强调 fork / pause（对应并行与状态），agent-sandbox 强调 WarmPool / 调度（对应批量与镜像），Modal 强调并发数（对应密度）。同一个「沙箱」，不同场景的宣传重点落在不同维度上——把这些重点并排放，就得到上面这张表。这是我的归纳，不是任何来源的明确主张；它的用法是「先问账单会被什么撑爆」，而不是当成定律。
● 怎么用：选型时先找到你自己那一行，看 ● 落在哪一列，再回到 7.4 找对应优化方向的项目。若你的场景同时有两个 ●，说明你其实在混合两个场景——拆开来，分别选。
7.4 场景 → 开源首选
Section titled “7.4 场景 → 开源首选”数据快照：2026-10-21，star 取自 GitHub REST API 实查；2026-10-22 复验了本周关键项。star 会变，超过一两月请用第 8 章的自查命令重查。
| 场景 | 开源首选 | 备选 | 主导成本 → 优化方向 |
|---|---|---|---|
| 1 代码解释器 | vndee/llm-sandbox（1.1k）、microsandbox（8.8k） | dify-sandbox（1.3k）、judge0（4.5k） | 冷启动 → 预热池、快照恢复 |
| 2 Coding agent | vibekit（1.9k）、container-use（4.1k） | clawk（1.0k）、agent-sandbox 示例 | 依赖安装 → 持久工作区、模板镜像 |
| 3 浏览器 / 桌面 | agent-infra AIO Sandbox（6.2k） | trycua/cua（30.5k） | 内存密度 → 共享浏览器进程、按需启停 |
| 4 评测 / RL | kubernetes-sigs/agent-sandbox（4.3k） | OpenSandbox 批量（16.0k） | 调度与镜像 → WarmPool、镜像懒加载 |
| 5 常驻 / 多租户 | agent-sandbox + WarmPool | E2B pause/resume（14.5k） | 闲置 → suspend/resume、scale-to-zero |
| 6 工具执行 / MCP | anthropic srt（5.6k）、nono（4.6k） |
agent-sandbox MCP 示例 | 策略粒度 → 复用沙箱 + 每调用策略 |
| 7 用户可编程 | OpenSandbox（16.0k）、E2B（14.5k） | Dormice（1.6k，E2B 兼容） | 计费 & 滥用 → 配额、active CPU 计费 |
| 8 安全分析 | arrakis | 自建 Firecracker（37.5k） | 可观测性 → 行为采集、快照回滚 |
| 9 CI 里的 agent | Docker Sandboxes | agent-sandbox CI/CD 模式 | 启动 & 清理 → 一次性环境 + 快速回收 |
star 数只说明热度，不代表适合你：第 8 章列的坑（如已归档的 Daytona）同样适用于这里的候选。挑完记得用第 8 章的 30 秒自查命令确认它还活着。
7.5 与其它章的分工
Section titled “7.5 与其它章的分工”三个视角，各回答一个问题。互链即可，不要重复内容——你不需要把三章都读透才能开工，先读和你问题对应的那一章。
| 章 | 它回答什么 | 什么时候翻它 |
|---|---|---|
| 第 5 章：隔离后端选型 | 隔离机制怎么选（技术问题） | 「我需要多强的隔离？microVM 还是 gVisor？」 |
| 本章：场景与成本 | 场景需要什么（需求问题） | 「我这个场景硬需求是什么、账单会被什么撑爆？」 |
| 第 8 章：产品与项目版图 | 谁能提供（供给问题） | 「满足这些需求的产品有哪些、怎么尽调？」 |
推荐的读法顺序：先用本章 7.0 的四句话把需求写下来，再用本章 7.4 收敛到几类项目，最后用第 8 章对候选做尽调。如果中途发现「需求里最硬的是隔离强度」，那就回第 5 章按机制细选。
| 误区 | 问题 | 正确做法 |
|---|---|---|
| 「按行业挑沙箱」（金融 / 医疗 / 电商各一类） | 行业给不出可操作的需求，最后还是在比功能表 | 按 7.0 的四个属性描述场景 |
| 「把 agent 在沙箱内 / 沙箱外混着比」 | 两者凭据与网络模型不同，比出来的结论是错的 | 先站 7.1 分叉 A，再比较 |
| 「fork 和 branchable VM 是一回事」 | 它们复制在同一刻，一个在云 API 层、一个在 VM 层 | 按 7.1 分叉 B 的「复制方向 / 复制层」判断 |
| 「快照 = 预热池」 | 一个存状态，一个省冷启动，目的不同 | 快照为了分叉 / 回滚；预热池为了压冷启动 |
| 「先把最强隔离上了再说」 | 拖慢交付、抬高成本；很多场景的命门根本不在隔离 | 先定主导成本项，再按需升级后端（第 5 章） |
动手练习 7
Section titled “动手练习 7”- 用 7.0 的四句话，写出你自己项目的场景描述。写不出来的那一句，就是还没想清的需求。
- 从 7.3 的矩阵里找到你那一行，说出你的主导成本项是什么。如果
●落在两列，试着把场景拆成两个。 - 用 7.4 挑 2–3 个候选，再用第 8 章的 8 问对它们做一次尽调，填一张对比表。
- 挑战题：解释为什么「安全分析」的命门不在 7.3 的七个维度里。