Agent 沙盒的工程经济学

五个月复盘：2026 年 4 月 → 9 月，聚焦性能、成本、可靠性与架构灵活性

这是对《把 Agent 关进盒子里》（2026 年 4 月中旬）的跟进。原文在 Cloudflare Sandboxes GA、Anthropic Managed Agents、OpenAI Agents SDK 沙盒支持集中发布的那一周，系统论述了 Agent 执行环境沙盒化的安全动因、成本结构和架构演进。本文不再重复安全叙事（已充分验证），而是聚焦工程侧的四个问题：解耦到底带来了多少性能改善？成本结构真的优化了吗？可靠性比旧架构更好还是更差？架构灵活性走到了什么程度？

标注约定：【官方】 厂商一手披露 / 【三方】 独立测试或第三方报道 / 【推断】 笔者判断。关键数字均附来源。

TL;DR

1. 性能：Harness-Sandbox 解耦后 Anthropic 实测 p50 TTFT 降约 60%、p95 降超 90%；但 Cloudflare 承诺的"快照恢复 2 秒"五个月后仍未兑现，官方文档写的是"容器休眠→状态全丢"。第三方冷启动实测与厂商宣称最大差距达 77 倍（Blaxel 宣称 25ms、实测 1924ms）；更关键的是冷启动快不等于全流程快——E2B 冷启动 717ms 排第一，真实 CI pipeline 却排第八
2. 成本：active-CPU 计费成为主流，但内存才是真正的账单主角（agent 等模型响应时 CPU 空闲但内存不释放）。计费模型差异能让同一个 workload 的成本在不同厂商间相差 10 倍。"休眠免费"已成标配，但反面是失控无上限——HN 有人因 Durable Object alarm 死循环 8 天烧 $34k、零用户、零平台告警
3. 可靠性：Session 独立持久化让"换容器续跑"成为可能，但分布式调试复杂度显著上升（Cloudflare 一个生产 bug 同时导致 turn 误判失败、tool call 重复执行、sub-agent 误判终态）。Cloudflare 2026 年 8 月一周内 13 起独立事故且无正式 postmortem；把 Session 状态托管在 Durable Objects 上，DO 的可靠性就是你 Agent 的可靠性——Wire 团队因 placement 不可迁移、DO 不能自托管等结构性限制迁出
4. 架构灵活性：从"沙盒是终极形态"走向"isolate 为主、容器为兜底"。Cloudflare 明确说"全世界所有云的 CPU 加起来也不够给每个 Agent 一个容器"，目标是容器只承担不到 10% 的工作。Kubernetes agent-sandbox v1.0.0 成为编排标准，可插拔 gVisor/Kata/Firecracker。同时模型厂商（Anthropic/OpenAI）把 Harness 变成托管服务、Sandbox 变成可热插拔的数据平面——自带或自托管，9 家 provider 可选

一、性能：解耦真的有用，但快照恢复还是个未兑现的承诺

1.1 解耦带来的 TTFT 改善

原文引用了 Anthropic 在旧→新架构迁移后的性能数据。这五个月里，这组数字被 Anthropic 在多个官方出处反复确认：

p50 TTFT 下降约 60%，p95 TTFT 下降超过 90%。

来源：Scaling Managed Agents: Decoupling the brain from the hands（2026-04-08）；Building with Claude Managed Agents（2026-06-10）

原因很直观：旧架构里每次启动推理都必须先完成容器启动、仓库克隆、依赖安装。解耦后 Harness 可以直接开始调用模型，只有真正需要执行代码时才去分配 Sandbox。不需要 Sandbox 的会话，响应几乎是即时的。

OpenAI 侧没有公布对等的 TTFT 数字，但客户 Hypha 的证言从可靠性角度间接佐证了性能改善：

"By separating the agent harness from the sandbox, we reduced failed agent responses by 86%."

来源：Introducing the Agents API（2026-09-10）

【推断】 这个 86% 的降幅不太可能纯粹是"修了 bug"——更可能的机制是：harness 崩溃不再连带 sandbox 一起挂（反之亦然），重试和恢复可以在各自层面独立进行。这本质上是微服务化的经典收益：故障域隔离提升了整体可用性。

1.2 快照恢复：Cloudflare 的承诺 vs 现实

原文引用了一个很有感染力的数字：

启动一个 sandbox，克隆 axios 仓库，然后 npm install，从头来需要 30 秒。但如果从快照恢复，只需要 2 秒。

以及一个 API 示例：

class AgentDevEnvironment extends Sandbox {
  sleepAfter = "5m";
  persistAcrossSessions = { type: "disk" };
}

这两样东西在写作时（2026-04-13）的状态是"rolling out in the coming weeks"。

五个月后，官方文档（Last updated 2026-09-01）的实际表述是：

"### Idle — After a period of inactivity (10 minutes by default, configurable via sleepAfter), the container stops to free resources. When the next request arrives, a fresh container starts. All previous state is lost and the environment resets to its initial state."

Best practices 最后一条："Design for ephemeral state — Containers restart after inactivity, losing all state."

persistAcrossSessions 在全部 Sandbox 文档页中不存在。

实际交付的是一个降级方案：createBackup({dir}) 把目录打成 squashfs 归档到 R2，restoreBackup(handle) 恢复。但官方明说：

"In production, restore mounts a copy-on-write overlay. The mount is lost when the sandbox sleeps or the container restarts. Restore again from the stored handle."

来源：Sandbox backup and restore

也就是说，restore 得到的 overlay 在下次 sleep 后又丢了——你需要在每次唤醒时重新 restore。而且这个 interim 方案本身有两个未修的 bug：≥10MiB 归档在开启 interceptHttps 时 createBackup 总是失败（multipart 上传用的 in-process fetch 不信任注入的 CA）；≥10MB 归档的 restore 不可恢复（并行下载脚本 exit 1 会杀掉持久 backup session shell）。

Cloudflare 员工在 GitHub issue 里的原话：

"While we continue working on a proper snapshotting solution at the VM level that enables true idle states, we currently have an interim solution wherein you can mount an R2 bucket..."

【推断】 那个"agent 合上笔记本、再打开继续干"的叙事——5 个月后还没兑现。这意味着 Cloudflare 的"idle 零成本"在 Durable Objects 层面是真的（isolate hibernation 确实有效），但在 Sandbox/容器层面，目前的"零成本 idle"是通过直接扔掉状态实现的，而不是通过快照。选型时这个差异很关键。

1.3 冷启动：厂商宣称 vs 第三方实测，以及为什么这个指标本身就有误导性

【三方】 LogRocket 的独立实测（2026-08-04）方法很讲究——create → 跑命令 → 确认命令真正在沙盒内执行 → pause → 计时 resume 到首条命令。"Ready" 指命令已执行，不是 API 返回：

关键警告（LogRocket 原文）：

"Our measured cold starts ran above vendor claims because vendors often measure warm, in-region paths while real agents pay for setup, distance, and the round trip."

原文表格里 Blaxel 写的是"25ms resume"，第三方实测 1924ms——差约 77 倍。这不是说 Blaxel 在撒谎（它可能测的是 in-process resume 的内部延迟），而是说这类数字的比较必须控制测量方法。

更重要的是：冷启动快不等于全流程快。

【三方】 StarSling 的开源基准（数据 2026-08-06，方法论开源）统一 4 vCPU / 8 GB / 40 GB，用 3 个真实仓库（Better Auth、Mastra、OpenClaw）各 12 个副本跑仓库自带 CI（clone→install→lint→typecheck→build）+ 10 个 Phoronix 合成套件。真实 pipeline p50：

1. Namespace 145.6s ← 新玩家夺冠
2. Daytona (VM) 163.7s
3. Blaxel 164.0s
4. Novita 205.5s
5. Modal (VM) 206.6s
6. microsandbox 237.9s
7. Vercel 258.0s
8. E2B 300.1s ← 冷启动第一，全流程第八
9. run.cloud 301.0s
10. Runloop 407.2s
11. Modal (gVisor) 424.4s

E2B 冷启动 717ms 排第一，全流程 300.1s 排第八（2.06× 于榜首 Namespace）。 这说明 Agent 实际工作负载中，安装依赖、编译、跑测试的时间远大于冷启动本身。选型时应该看的是 TFFI（Time to First Instruction） 或整个任务的端到端完成时间，而不是单一的 create 延迟。

这也是 Kubernetes agent-sandbox 路线图里正在定义的指标——他们专门立了一个"TFFI 基准定义与优化"条目。

1.4 Sandbox SDK 1.0：Cloudflare 的性能向架构调整

【官方】 Cloudflare 在 2026-08-07 发布了 Sandbox SDK 1.0 preview（稳定线仍是 0.12.x），核心是大幅瘦身：

• exec() 改为收 argv，且在进程 start 时就 resolve（不再等 finish），统一短命令和长驻服务为一个 process handle
• 完全移除 SDK 层 sessions："no session execution on the SDK. Each exec() is independent... Isolate end users with separate sandboxes, not sessions inside one sandbox"
• RPC 作为唯一 transport（移除 HTTP/WebSocket transport）
• PTY 升级为一等资源（createTerminal/getTerminal/listTerminals）
• Code interpreter 变成 opt-in extension（不再默认包含）
• Desktop 功能在 0.10.2 被彻底移除

【推断】 这次瘦身的性能含义是：每个 exec() 调用更轻（不维护 session 状态），RPC 路径更短（不做 transport 协商），但代价是开发者需要自己管理跨调用的状态连续性。这是"session 语义应该在哪一层实现"的一次明确表态——Cloudflare 认为应该在 Durable Object 层（Think/Agent），而不是在 Sandbox SDK 层。

二、成本：内存是真正的账单主角，计费模型差异 > 单价差异

2.1 当前定价全景

所有数字来自官方 pricing 页，核对日 2026-09-15/16。

来源：E2B · Daytona · Modal · Vercel · Cloudflare · Fly.io · Runloop · Blaxel · AWS AgentCore · Northflank

2.2 四种计费形态

【三方】 Fly.io 的定价分析（2026-09-09，⚠️ 利益相关方，但逐项标注了各家 pricing 页引用）把市场分成了四种形态：

1. Wall-clock on reserved（E2B、Daytona）：hours × vCPUs × rate。0% CPU 和 100% CPU 一个价。E2B 的解法是 pause
2. Active CPU split（Vercel、Cloudflare）：CPU 线只在进程上 CPU 时走。但 Cloudflare 卖固定 shape，内存和磁盘只要容器在跑就一直计费
3. Usage metering（Fly Sprites）：从 cpu.stat 读累计 CPU，按实际消耗计费
4. Plan + allowance（Cloudflare $5/月含 375 vCPU-分、Vercel Pro $20 credit、Modal Starter $30/月 credit）

两条洞见直接影响选型：

"Memory dominates almost everywhere, because an agent waiting on a model call still holds its RAM."

"the plan fee usually beats the compute: E2B Pro $150/mo, Modal Team $250... At a few hundred sessions a month, the plan is the bill."

2.3 计费模型差异让排名完全反转

同一篇里的 2 vCPU / 4 GB sandbox 对比（100 sandbox-hours）：

【三方】 LogRocket 的成本建模（2026-08-04）更直观：

• 场景 A（30,000 次/月 bursty，存活 5 分钟但只用 30 秒 CPU）：
  Modal ~$36 / Vercel ~$276 / E2B·Daytona·Blaxel ~$414
  → active-CPU 派赢一个数量级
• 场景 B（50 个持久 sandbox，每天活跃 2h、空闲 22h）：
  Modal ~$426 / E2B·Daytona·Blaxel ~$533 / Vercel ~$3,800
  → 因为 Vercel 的常驻内存按 24h 计

同一个选 E2B 还是 Modal 的决定，在两个场景下给出完全相反的答案。 这说明"谁最便宜"是一个没有通用答案的伪问题——正确的问题是"我的 workload profile 是什么"。

2.4 "休眠免费"已成标配，但它有另一面

⚠️ 两个例外要特别注意：

• Vercel 的内存按全 wall-clock 计——即使 CPU 空闲，只要 sandbox 存在就在收内存费
• AWS AgentCore 的内存按峰值计到 session 终止——哪怕后续实际使用量下降

但"休眠免费"有一个危险的反面——失控成本无上限。

HN 上有一个真实案例：Durable Object 的 alarm 死循环，8 天烧掉 $34,000，零用户，平台零告警。提交者是一个把全部个人积蓄投进创业的独立开发者。

评论里最有价值的两条诊断：

"The thing that would have caught this: anomaly detection scoped to the service + the account, not just the total bill... Per-service p95-vs-median alerts at hourly granularity would have flagged this inside 6 hours."

"CPU-time monitoring is a relic from before Workers grew DO/KV/D1 with their own metered ops, and per-binding spend caps would have caught this."

【推断】 在 agent 场景（alarm + fiber + 自触发循环）里这个风险被显著放大。原文的经济学论述说"10,000 个活跃 1% 的 Agent 只需约 100 个活跃实例"——这是对的。但它的另一面是：一个自触发的 alarm 可以在 8 天内让你欠下 $34k 而平台侧没有任何 per-binding 的 spend cap 来拦住它。

Think 0.18.0 的 CHANGELOG 里恰好有个相关修复——把 alarm memory-limit circuit breaker 从 Agent.alarm() 移到 Lifecycle 事件循环，并用 ctx.abort(reason, { retryAlarm: false }) 抑制重试。说明 Cloudflare 自己也踩过这个坑。

2.5 "没有发生价格战"——发生的是整合

原文预测"Sandbox-as-a-Service 会爆发价格战"。

没有发生。 E2B 和 Daytona 的单价小数点后完全一致（$0.000014/vCPU-秒），这是价格对标而不是价格战。真实降价只有两处，且都不是 CPU 单价：E2B 把存储改为免费；Vercel 把下载流量改为免费。

实际发生的是整合和大厂收编：

第三方点评：

"这移除了让 Daytona 对担心锁定的团队有吸引力的自托管逃生舱……E2B 成为这组里唯一自托管仍是活选项的商业平台。"

来源：comparesandboxes.com（2026-06-19）

同时，推理厂也在往下游收编：Baseten 收 Blaxel、Together AI 收 CodeSandbox（SDK 迁到 together-sandbox）。加上云大厂全面进场（GKE Agent Sandbox GA、AWS AgentCore Harness GA、Azure Foundry hosted agents 预览、DigitalOcean M.A.R.S.、Oracle OCI GenAI Sandbox），独立 sandbox 厂商从"agent 栈的必需品"变成了"可热插拔的 compute 后端"——议价能力在下降。

2.6 中国市场的定价：更细的休眠粒度

中国厂商在成本优化上做了一个海外还没做到的事——三态计费。

阿里云 FC 云沙箱的官方定价分三个档位：

三态语义（官方原文）：

• 活跃：收 CPU + 内存 + 磁盘，磁盘享 15 GiB 免费额度
• 浅休眠：不收 CPU，仍收内存和磁盘
• 深休眠：不收 CPU 和内存，仅按深休眠磁盘占用收费，且不享 15 GiB 免费

这比海外厂商的二元模型（running / paused）多了一层。云栖大会演讲（第三方转述）里更有一句值得注意的话：

"首创了按实例'忙/闲'状态独立计费的模式——Agent 等待模型或工具响应时算力免费，仅收极低内存费用，平均降低 60% TCO"

PPIO 派欧云（定价页）把超时做成了两段式，比多数厂商细：

• Timeout：最长生命周期，从创建时倒计时，与活动无关
• Idle timeout：仅当在配置时长内没有任何客户端连接时触发

二者触发时均可选 pause 而非 kill，并可选自动恢复。另外，暂停的 Sandbox 不占用并发配额——这对高并发场景的成本控制很有用。

三、可靠性：Session 独立存活让"换容器续跑"成为可能，但分布式调试更难了

3.1 Session / Harness / Sandbox 的解耦让失败恢复变得可能

原文的架构描述里最有工程价值的一段是：

"Sandbox 死了？没关系，Harness 把错误返回给 Claude，Claude 自己决定要不要重试。Harness 自己崩溃了？也没关系，因为 Session 日志是独立存储的，新的 Harness 实例可以通过 wake(sessionId) 恢复，从最后一条事件继续执行。"

五个月后，这套能力已经产品化了。两家的 Session 持久化设计可以并排对比：

Anthropic Managed Agents（官方文档）：

• Session 是一等资源，有独立的 API 端点（POST /v1/sessions）
• 事件流是 SSE + 服务端持久化
• Session ≠ Context Window：上下文窗口只是当前喂给模型的内容，Session 记录的是从开始到现在的全部历史事件。Harness 可以通过 getEvents() 按位置切片读取、回退到某个时刻查看前因、在失败重试时重读完整上下文
• 自动 context compaction 压缩长会话
• dreaming（2026-05-06 research preview）：异步 batch 任务，跨 session 审视 memory store，合并重复、替换过期条目、提炼模式——等于 Session 的"离线整理"

OpenAI Agents API（官方文档）：

• Session 同样是一等资源
• 支持自动 context compaction
• Agents SDK 层面内置 snapshotting 和 rehydration：如果 sandbox 容器挂了或过期了，SDK 可以把 Agent 的状态恢复到新容器里，从上一个 checkpoint 继续执行
• 三层状态模型正式化：RunState（harness 侧：model items、tool state、approvals、active agent position）/ serialized session state（可重连的 provider session）/ snapshot（保存的 workspace 内容，用于播种新 session）

Cloudflare 的 Session API（Think / Agents SDK）：

• 基于 Durable Object SQLite，把对话存成一棵带 parent_id 的树
• 支持 forking（从任意节点分叉对话）、非破坏性压缩（compaction 不删原始消息，可回溯）
• 基于 SQLite FTS5 的全文搜索（Think 0.18.0 改为首次搜索时才构建索引）
• Durable Objects 的 hibernation + Fiber 的 checkpoint 机制

【推断】 长时运行的 Agent 终于达到了传统服务端应用级别的可靠性——前提是你在正确的层面做持久化（Session 层而非 Sandbox 层）。但代价是调试复杂度上升了——见下一节。

3.2 分布式调试的代价是真实的

原文写过一段：

"在旧架构里，Agent 的所有东西都在同一个进程或容器里。出了问题，你只需要看一组日志。但在解耦架构里，Harness、Sandbox、Session 是三个独立组件，问题可能出在任何一层。"

五个月后，这个预测完全成真。以 Cloudflare Think 为例，PR #1623 修的是一个客户在生产里遇到的连锁 bug——反复 wrangler deploy 导致的状态不一致：

• 已完成的 turn 被标记为 failed
• 已执行的 tool call 重复执行
• 被中断的 tool call 凭空消失
• malformed tool input 永久 400
• auto-compaction 在 tool-heavy 历史上静默 no-op
• sub-agent 中断被误判为终态失败

这不是"一个 bug"——这是解耦后状态一致性的系统性挑战。当 Harness 和 Sandbox 各自可以独立崩溃和恢复时，"上次到底执行到哪了"这个问题的答案散落在多个组件的日志和状态里。

好消息是可观测性工具在跟上：

• Cloudflare（2026-08-04）：Dashboard 里的 Agents 视图提供 agent tracing（invoke_agent / chat / execute_tool / tool_approval spans）、session replay（回放录制数据，不是重新执行）、trace waterfall（agent 操作和 Workers 基础设施 span 嵌套）、token/成本归因。支持 Think / Flue / AI SDK（wrapAISDK()）/ 自定义 harness（OTel GenAI semconv）
• Browser Run（2026-09-01）：Session Recording 进入 Beta——rrweb 结构化 JSON（非视频），Dashboard 回放，也可 API 取，保留 30 天
• OpenAI Agents API：harness 侧的 versioned access 保证每次模型发布配套版本化的 harness 能力

但调试体验的根本性改善——让工程师能像"进容器 shell"一样直观地跨组件追踪问题——仍然是一个开放挑战。

3.3 Cloudflare 的可靠性记录：2026 年 8 月的事故群

选型时不能只看 happy path。

【官方 status page】 2026 年 8 月，Durable Objects 相关事故密集发生：

【三方】 更广泛地看，8/7–8/14 一周内 Cloudflare status page 记录了 13 起独立事故，涉及 R2、DO、Workers KV、Workers AI、email security、四大洲网络性能。12 起 minor、1 起 major。

截至 8/15，Cloudflare 未发布任何正式 postmortem。 有客户在社区论坛报告 R2 桶里约 67GB 数据在事故数天后仍未恢复。

一条第三方分析（btw.media）指出了一个可观测性盲区：

"Durable Objects alone moved to degraded performance... Hong Kong, RealtimeKit and Realtime SFU stayed operational, showing why a green location indicator cannot establish the health of a stateful application path."

【推断】 对于把 Agent 的 Session 状态放在 Durable Objects 上的团队来说，DO 的可靠性就是他们 Agent 的可靠性。13 起事故在一周内发生，且没有 postmortem，这是选型决策中需要被权衡的风险——不是说 Cloudflare 不好（任何分布式系统都有事故），而是说你需要知道当事故发生时，恢复路径是什么、你能看到什么。

3.4 Wire 的案例：从 DO 迁出的结构性原因

【三方】 Wire 的工程博客（2026-07-07）在 Durable Objects 上跑了一段时间后决定迁出。作者特意强调"This is not a 'we left Cloudflare' post... We left because of four structural limits, not reliability." 四条理由全都和性能/架构灵活性有关：

1. 向量索引在 object 外面：embedding 放在 Vectorize（独立服务），最热路径上多一跳 + 第二份可能漂移的状态。DO SQLite 不能加载扩展，索引永远进不来
2. 需要 compute 靠着 data：检索是多阶段 pipeline（hybrid 候选生成、fusion、query expansion、wide rerank），DO 上只能跑很薄一片
3. Placement 只在创建时定，compute 永远共享："an object never moves afterward, so a container created from London serves an agent fleet in Virginia forever. And you cannot buy dedicated capacity for one tenant."
4. DO 不能自托管："Regulated teams keep asking to run containers on infrastructure they control."

迁移结果（Bun on Fly Machines，SQLite + sqlite-vec 内嵌索引）：

• warm tool call 从 ~0.4s（有 >2s 尖峰）降到稳定 ~0.3s
• idle 容器唤醒从 3.7s → 1.4s

作者诚实地澄清："it was never 'Durable Object cold start', isolates wake in milliseconds. The 3.7 seconds was our own stack reassembling itself."

最有教学价值的一段是关于"买回 durability"的代价：

"Cloudflare replicates every DO storage write before acking it. Our first cut was only 'durable at next checkpoint,' and soak tests that kill machines under load showed exactly what that means: a handful of acked writes, gone. The real fix is continuous WAL shipping. A write does not ack until its WAL frame is in object storage; group commit keeps that to about 100 ms."

HN 上一条评论的总结：

"Durability is not the problem, but because the state lives somewhere you structurally can't relocate. That constraint never shows up in a benchmark, it shows up in an enterprise procurement call."

【推断】 DO 的自托管缺失是一个真实的 lock-in 痛点。2026 年下半年出现了一批 DO 替代方案（Celld: Self-hosted Durable Objects 在 HN 上拿到 286 分；还有 Node.js 版、Postgres 版、Rails 版的 DO 移植），说明社区的解绑需求是真实的。

四、架构灵活性：从"沙盒是终极形态"到"isolate 为主、容器为兜底"

4.1 Cloudflare 对原文最反直觉的修正

2026-08-03，Cloudflare 发布 @cloudflare/computer，开篇论断：

"No matter where the harness runs, giving every agent a container presents a challenge — across all the clouds, all the hyperscalers, there's nowhere near enough compute in the world for every company to give each of their users' agents their own containerized compute environment. This will not scale to hundreds of millions, then billions, of concurrent agents. This is why there is desperate, panicked industry demand for CPU compute, not just GPU compute."

明确目标：

"Our goal with @cloudflare/computer is to provide an agent with a runtime where a container is required for less than 10% of its work, and coding tasks, audio/video manipulation, and document creation can all be handled by isolates."

产品形态：一个跨 isolate 和 container 的共享虚拟文件系统（SQLite 支撑，isolate 后端通过 worker bindings 直接访问，container 后端通过 FUSE mount 双向同步），加一个统一的 exec(string, options) 接口。两个开箱后端：

• isolate 后端：用 just-bash 把 shell 代码翻译成 JavaScript，跑在 Dynamic Worker 里（ms 级启动、几 MB 内存、无网络）
• container 后端：Cloudflare Containers，完整 Linux 环境

关键设计决策：由模型自己按 tool description 选后端。官方说："In our testing, the frontier models are very good at making the correct decision and falling back to using containers only when needed."

【推断】 这意味着原文 Execution Ladder 的重心方向反了：

而且同一战略的第二次落子是 Kitesurf（2026-08-06）——一个完全跑在 Workers 上、不是 Chromium 的自研浏览器（Rust → Wasm），HN 221 分。性能对比（14-URL corpus，5 次运行中位数，Chromium 用 warm pool）：

在按 CPU 和内存计费的世界里，省 3–7× 的 CPU 和内存、换 1.7× 的 wall time，对成本结构是正收益。 Kitesurf 和 @cloudflare/computer 是同一逻辑：把尽可能多的工作从容器搬到 isolate。

4.2 模型厂商把 Harness 变成托管服务，Sandbox 变成可热插拔的数据平面

这是五个月里最大的架构灵活性变化。

"谁托管 Harness + 谁提供 Sandbox"变成了两个独立的选择。

Anthropic（Managed Agents）：

• Harness：Anthropic 托管，对外不可见，"harness evolves alongside the model"
• Sandbox 两种选择：cloud（Anthropic 托管的 Ubuntu 24.04 容器，≤8GB / 10GB）或 self_hosted（你的基础设施）
• 自托管实现是一个工作队列：你跑一个 environment worker，轮询 GET /v1/environments/{id}/work 领取任务，在本地执行，结果回传
• Provider 生态（自托管的平台指南里点名的）：AWS Lambda MicroVMs、Blaxel、Cloudflare、Daytona、E2B、Fly.io、GKE Agent Sandbox、Modal、Namespace、Superserve、Vercel

OpenAI（Agents API，2026-09-10）：

• Harness：OpenAI 托管的开源 Codex harness（代码在 github.com/openai/codex），开发者可以 inspect 和 learn from
• Sandbox 三种选择：openai_hosted（复用 Codex/ChatGPT 基础设施）、self_hosted（你跑 codex exec-server，纯出站 WebSocket）、9 家 partner
• 自托管实现更轻量：executor 用 environment ID + 受限 API key 注册，经 WebSocket 接命令回结果，全部出站连接，断线自动重连
• Partner 列表：Blaxel、Cloudflare、Daytona、DigitalOcean、E2B、Modal、Oracle、Runloop、Vercel

这个架构最强大的地方在于：它让你可以在不改 harness 代码的情况下换 sandbox provider。 测试时用 Docker，staging 用 E2B，生产用 Cloudflare 或自建——只改配置。

而且反过来也成立——Cursor Cloud Agents（2026-09-02）是另一个有趣的组合：Cursor 托管 harness（agent loop + 推理 + 规划），Cloudflare 只跑工具执行。同样，Codex via OpenAI Agents API（2026-09-10）也是 OpenAI 跑 harness、Cloudflare 跑 sandbox。

四家 coding agent（Devin、Cursor、Claude、Codex）都有 Cloudflare 作为 sandbox 后端的官方路径。 Cloudflare 的护城河在底层基础设施，而不是在 harness。

4.3 Kubernetes agent-sandbox：编排层的标准化

【官方】 kubernetes-sigs/agent-sandbox 发布 v1.0.0（2026-08-28），成为 Kubernetes SIG Apps 下的正式项目。

自我定位：

"Agent Sandbox is a sandbox orchestrator. It delegates low-level container isolation to secure 'Sandbox Runtimes' (like gVisor or Kata Containers) by managing Pods configured to use these runtimes (via RuntimeClass)."

核心 CRD 和扩展 CRD：

性能目标（路线图）：

• 已完成：控制器支撑 300 sandboxes/秒 claim 吞吐
• 目标：claim 延迟 200ms → 100ms → 50ms；1000+ claims/秒
• 正在定义 TFFI（Time to First Instruction） 基准

架构灵活性（路线图里与此相关的条目）：

GKE Agent Sandbox（2026-05 GA）的数据进一步验证了这个方向的可行性：

• gVisor 内核隔离（和保护 Gemini 的同一技术）
• 300 sandboxes/秒/集群，90% 分配 <200ms
• Pod Snapshots 挂起空闲 agent、秒级恢复
• Warm pool + standby capacity buffers（挂起 VM 做冷池，低成本补充热池）
• 2026-07-30 官方后续：从 microVM 迁到 Agent Sandbox，同一 VM 内可跑 88 个 OpenClaw agent（密度 +44%），成本降 75%

来源：Reduce your agents' costs with GKE Agent Sandbox（2026-07-30）

【推断】 Kubernetes agent-sandbox 的战略位置是"中立编排层"：它不绑定任何一家云厂商（虽然 Google 是主要贡献者），不绑定任何一个隔离技术（gVisor / Kata / Firecracker 可选），也不绑定任何一个模型厂商的 harness（LangChain / CrewAI / kAgent 的框架集成在 In Progress）。对于不想被锁定在某一家 sandbox 厂商或某一家云大厂上的团队，这是目前最有吸引力的选择。

4.4 开源沙盒运行时：谁在成为底座

不是一个项目独占底座，而是形成了清晰的三层分工：

三个体量最大的开源沙盒项目（全部 2026 年新出现或新开源）：

gVisor 在 RL 训练场景的生产数据（官方博客，腾讯容器基础设施团队投稿，2026-04-23）：

"Today, we run millions of gVisor sandboxes daily for Agentic-RL training in production."

他们跨 10 个主流代码执行数据集做了 74,379 次 runc vs runsc 并排对比，兼容性问题占约 1.7%，经定向修复后"essentially closed the execution correctness gap with runc"。选 gVisor 而非 microVM 的理由：

"Compared to microVM solutions—which must run on bare-metal hosts—gVisor can run inside regular VMs, making it significantly cheaper."

【推断】 对性能和成本敏感的 RL 训练场景，gVisor 的"够用的隔离 + 显著更低的成本"组合比 microVM 更有吸引力。而 microVM（Firecracker / RustVMM）更适合需要完整 OS 语义的场景（如 coding agent 需要 npm install / git clone）。这两种技术不是互斥的，而是服务于不同的 workload tier——和原文的 Execution Ladder 思路一脉相承。

4.5 Code Mode：一个被低估的架构灵活性维度

原文讨论 Code Mode 时聚焦的是 token 节省（99.9%）。五个月后，Code Mode 更重要的一面是它对架构灵活性的影响。

先修正那个数字。规模斜率如下（综合多个独立来源）：

最严谨的独立数据来自 code-mode-mcp 基准（160 次评分运行，确定性 10-tool MCP server，Opus 4.8）。结论原话：

"The benchmark found no universal call-count threshold."

guided hybrid vs direct-only 聚合：wall time −40.6%、prompt processing −46.2%、成本 −73.7%——但收益完全来自 3 个任务类型：大数据集后归约、长确定性依赖链、fan-out 聚合。简单的独立查找 → direct 更好。

但真正让 Code Mode 成为架构话题的，是 Cloudflare 2026-06-16 的架构升级（changelog）：

"Code Mode now uses createCodemodeRuntime(), connectors, and a durable execution log... When the code reaches an approval-gated action, the runtime pauses execution and returns a pending approval. After approval, completed calls replay from the durable log, the approved action runs, and the same code continues."

现在的架构：

• 模型只拿到一个 codemode({code}) 工具
• Executor 故意无状态（DynamicWorkerExecutor on Workers / IframeSandboxExecutor in browser）
• Connectors 桥接 MCP server / OpenAPI spec / AI SDK toolset，持有凭证
• Runtime 是 Durable Object facet + 独立 SQLite（存执行记录、connector 调用日志、pending approvals、snippets，跨 hibernation 存活）
• 沙盒完全无网络："The sandbox has no network access. Model code cannot fetch; every effect goes through a connector."
• 有 rollback() 补偿机制

这次演进的本质：Code Mode 从"省 token 的技巧"变成了"把副作用管起来的执行层"。 当所有外部效果都必须通过 connector，你就有了一个统一的审批、审计和回滚点。这比 token 故事更重要——它让 Code Mode 变成了一个架构模式，而不只是一个优化技巧。

学术验证也在跟上：arXiv 2608.06370《The Bitter Lesson of Tool Calling》（2026-08-06）在 BFCL v4 上跨 14 个模型对比：programmatic tool calling 在 11/14 匹配或超过原生 JSON tool calling；GPT-5.6 家族 +10.6%；context rot 条件下保持稳定而 baseline 平均降 2.3%。

厂商侧已全面产品化：OpenAI GPT-5.6 在 Responses API 里写 JavaScript 跑托管 V8（无网络）；Anthropic PTC 写 Python 跑 code execution sandbox；Pydantic AI CodeMode 用 Monty（Rust 解释器、微秒级启动）自托管。

4.6 MCP 变薄让执行层更灵活

原文预测 MCP 会扩展成"工具 + 执行环境"协议。实际走了反方向——MCP 2026-07-28 规范主动变薄变无状态：

• 移除 initialize 握手和 Mcp-Session-Id（任何请求可以落到 round-robin 后面的任意实例）
• Tasks 移出核心协议
• 弃用 Roots、Sampling、Logging
• 路线图五个优先领域里没有沙盒项

但从架构灵活性的角度看，这其实是好事。 协议不管执行环境，意味着你可以在任何地方跑 MCP server——本地、容器、isolate、microVM——只要它能收到 JSON-RPC 请求并返回结果。执行环境的选择从协议层解耦出来了，变成了 host/gateway 的配置问题。

实际的灵活性通过三个层面实现：

1. K8s agent-sandbox：Agent Sandbox MCP Server 在路线图里（📅 Planned），会通过 router 或 SDK 提供 MCP endpoint
2. MCP 网关：Docker MCP Gateway（每个本地 MCP server 跑在独立容器；secrets 走 Docker Desktop secrets 管理而不进环境变量）、Microsoft mcp-gateway（K8s-native）、agentgateway（AAIF 项目）
3. OpenClaw 的 sandbox 内 MCP server 发现：workspace 声明的 .mcp.json 可被 capable sandbox backend 自动发现并在沙盒内启动，不需要在 host 上跑

开源框架侧，LangChain deepagents 的 SandboxBackendProtocol 是目前最成熟的可插拔 sandbox provider 抽象：

"Sandbox backends have a simple architecture: the only method a provider must implement is execute(), which runs a shell command and returns its output... Adding a new provider is straightforward. Implement execute() — the base class handles everything else."

内置 6 家 provider（Daytona / E2B / LangSmith / Modal / Runloop / Vercel / AgentCore）+ entry-point 插件机制。BaseSandbox 把 read / write / edit / ls / glob / grep 全部翻译成通过 execute() 跑的 shell 脚本，保证跨 provider 行为一致。

4.7 中国市场的两个独特维度

E2B API 形状成为事实标准。

至少 7 家中国厂商官方声明兼容 E2B SDK：阿里云 FC 云沙箱、阿里云 ACS Agent Sandbox、腾讯云 AGSX、百度智能云 CFC、火山引擎 veFaaS、PPIO、CubeSandbox。阿里云甚至主动用定价引导开发者切到 E2B 接入方式——新计费"仅适用于使用云沙箱的用户群体（E2B SDK 接入方式）"。

CubeSandbox（腾讯云开源）的兼容做到了"改一个环境变量就能从 E2B Cloud 切过来，零客户端代码改动"。

RL 训练是一等场景，驱动了不同于在线 Serving 的架构需求。

阿里云 FC 云沙箱 Pro 档的官方定位就是"C 端高并发 Agent、复杂计算和大规模在线 RL 仿真"。ACS Agent Sandbox 三大场景之首是 AgentRL，Checkpoint/Restore 明确用于"加速分支并行探索"。火山引擎有专门的"veRL 集成 veFaaS 云沙箱"文档页。第三方转述云栖演讲称 Qwen RL 训练用 AgentRun Sandbox 达"数十万核"（此条来自媒体转述，非官方文档）。

RL 场景的技术需求与在线 Serving 明显不同：

这也是阿里云用 Eco/Std/Pro 三档（只有 Pro 有浅休眠）和 ACS 用 SandboxSet 批量 CR 来分别服务两种 workload 的原因。OpenSandbox 的 K8s Controller 同样为 RL 设计了专门的批处理交付模式。

来源：阿里云 ACS Agent Sandbox · gVisor at Tencent · 阿里云 ACK Agentic RL 方案

五、修正清单

把前四节压缩成一张表。

六、总结：选型决策框架

把前面的数据压缩成实操可用的选型视角：

按 workload 类型选

按架构决策选

必须验证的三个数字

在做最终决策前，用你自己的 workload 跑一遍：

1. TFFI（Time to First Instruction）——不是 API 返回的 create 延迟，而是"命令真正在沙盒内执行"的端到端时间
2. 空闲小时的真实成本——内存是否按 wall-clock 计？idle 状态只计什么？有没有 per-binding spend cap？
3. restore-after-sleep 是否保留状态——文档说"持久化"可能只是指"备份到对象存储然后每次唤醒重新 restore"，而不是"原地恢复"

近期跟进节点

• 2026-09-21 起 Cloudflare Birthday Week——历史上 Workers、Workers AI、R2 都在此发布，今年两次 Agents Week 都有重量级发布。persistAcrossSessions 是否兑现是最值得盯的一条
• 2026-09-23 阿里云云栖大会——上午场标题直接是《构建 Agent Infra — Agent Sandbox 重磅发布与技术架构揭秘》。ACS Agent Sandbox 目前是公测，推断可能是 GA

参考资料

性能与架构

• Scaling Managed Agents: Decoupling the brain from the hands — Anthropic，2026-04-08（p50 TTFT −60%、p95 −90%）
• Introducing the Agents API — OpenAI，2026-09-10（Hypha "failed responses −86%"）
• Cloudflare Computer — 2026-08-03（"容器只承担 <10%"）
• Kitesurf — 2026-08-06（CPU/内存 3–7× 更省）
• Sandbox SDK 1.0 preview — 2026-08-07
• Sandbox concepts / Backup and restore — 官方文档
• Sandbox SDK issue #102 — "proper snapshotting solution at the VM level"
• Agents on Cloudflare — 2026-08-04（tracing + session replay）
• Cloudflare Agents Platform — 2026-06-17（三层栈）
• Code Mode changelog — 2026-06-16（durable execution log）

成本与定价

• 官方定价页：E2B · Daytona · Modal · Vercel · Cloudflare · Fly.io · Runloop · Blaxel · AWS AgentCore · Northflank
• AI sandbox pricing — Fly.io，2026-09-09（⚠️ 利益相关方）
• Comparing AI agent sandbox platforms — LogRocket，2026-08-04（独立实测 + 成本建模）
• HPC sandbox benchmarks — StarSling（11 家 pipeline 对比）
• Modal Series C — $355M @ $4.65B，2026-05-21
• Daytona is going closed source — 2026-06-11
• Blaxel is joining Baseten — 2026-09-10
• 阿里云 FC 云沙箱定价 / 新计费模式
• PPIO 定价
• HN：Durable Object alarm 死循环 8 天 $34k

可靠性

• Think PR #1623 — 生产环境连锁 bug
• Cloudflare August 2026 incidents — 第三方统计
• Cloudflare HKG DO product health gap — 可观测性盲区分析
• Why we're moving Wire off Cloudflare Durable Objects — 2026-07-07
• Claude Managed Agents overview — Session 持久化
• Agents API overview — Session 三层状态模型
• New in Claude Managed Agents: dreaming, outcomes — dreaming

架构灵活性

• kubernetes-sigs/agent-sandbox v1.0.0 — 2026-08-28
• Agent Sandbox documentation
• Running agents on Kubernetes with Agent Sandbox — K8s 官方博客
• GKE Agent Sandbox GA — 2026-05-21
• Reduce agents' costs with GKE Agent Sandbox — 2026-07-30（88 个 agent/VM、成本 −75%）
• Cursor Cloud Agents on Cloudflare — 2026-09-02
• Codex via OpenAI Agents API on Cloudflare — 2026-09-10
• Claude Managed Agents self-hosted sandboxes — 2026-05-19
• MCP specification 2026-07-28 — 协议变薄
• MCP 2026 Roadmap
• LangChain deepagents sandboxes — SandboxBackendProtocol
• opensandbox-group/OpenSandbox · TencentCloud/CubeSandbox · NVIDIA/OpenShell
• Scaling Agentic RL sandboxes with gVisor at Tencent — 2026-04-23
• 阿里云 ACS Agent Sandbox
• 阿里云 ACK Agentic RL 方案

Code Mode

• The Bitter Lesson of Tool Calling — arXiv 2608.06370，2026-08-06（BFCL v4，14 模型）
• bifrost MCP code mode benchmark — 96/251/508 工具三档
• code-mode-mcp benchmark — 160 次运行，"no universal call-count threshold"
• Code Mode official docs — Cloudflare
• Anthropic Programmatic Tool Calling

安全（简要）

• OpenAI × Hugging Face incident — 2026-07-21
• How we contain Claude across products — 2026-05-25（"allowlist = capability grant"）
• The Week of Sandbox Escapes — Pillar Security