Cloud Agent 架构演进

E2B Sandbox (当前) → Cloudflare Think Durable Objects (新方案) 的技术对比与体验差异分析

Bloome IM Platform · 2026-04-18

0为什么要迁移？

当前 E2B Sandbox 方案在产品体验上有三个核心痛点，直接影响用户留存和平台可扩展性：

痛点 1

"Agent 怎么这么慢？"

用户发送第一条消息后，需要等待 10-25 秒 才能收到回复。其中 5-15 秒是在创建虚拟机、启动进程、建立 WebSocket 连接 — 这些对用户来说都是 无意义的等待。

闲置 5 分钟后再发消息，又要等 2-8 秒 "恢复"。IM 场景下，用户期望的是即时响应。

痛点 2

"代码太复杂了"

SandboxManager 有 ~2000 行状态机代码，管理 6 个生命周期阶段、Redis 双锁、多实例竞争、Grace Period、22 小时续期……

每次改一个功能都需要考虑 所有状态转换路径。Bug 排查需要同时看 Server 日志、Redis 状态、E2B API 响应、Sandbox 内部日志 — 链路太长。

痛点 3

"成本不好控"

E2B 按 CPU 秒 + 内存秒 计费。即使 Agent 只是在等用户回复，只要 Sandbox 还在 running 状态就在烧钱。autoPause 有 5 分钟延迟窗口。

大量 Agent 同时在线时，空闲等待的成本 远大于 实际推理的成本。作为平台方，这个模型 规模化后不经济。

Cloudflare Think 如何解决这三个问题

→ 冷启动 <50ms

Durable Object 是 V8 isolate，不是虚拟机。按需唤醒 <1ms。用户感受到的延迟 = 纯 LLM 推理时间。

→ 300 行代码

不需要状态机、Redis、多实例协调。DO 天然全局唯一 + 自动休眠。基础设施逻辑交给 Cloudflare。

→ 按请求计费

空闲 = $0（仅 DO 存储费 $0.20/GB·月）。没有 "5 分钟等待窗口"。1000 个闲置 Agent 的成本 ≈ 0。

1架构总览

Current · E2B Sandbox

MicroVM + WebSocket + Redis

  • Runtime: E2B MicroVM (Firecracker)，独立 Linux 容器
  • 通信: Agent ↔ Server 通过 WebSocket 双向长连接
  • 协调: Redis Presence Lease + Ownership Lease（多 Server 实例竞争）
  • Session: JSONL 文件持久化在 Sandbox 文件系统内
  • 备份: Workspace 定期 tar → R2
  • LLM: runner.cjs 内部直接调用 API（API Key 作为环境变量注入）
  • 状态机: idle → creating → running → paused → resuming → dead
  • 计费: CPU/秒 + Memory/秒 按量扣费
New · Cloudflare Think

Durable Objects + HTTP + SQLite

  • Runtime: Cloudflare Workers Durable Object（V8 isolate）
  • 通信: Server → Worker 通过 HTTP POST（无需长连接）
  • 协调: 不需要 — 每个 DO 全局唯一，天然单实例
  • Session: Think SDK 内置 SQLite，树结构，可 fork
  • 备份: DO 内置持久化，自动复制到多区域
  • LLM: 通过 Server LLM Proxy 中转（API Key 不暴露给 Worker）
  • 状态机: 无显式状态 — DO 按需唤醒，空闲自动休眠
  • 计费: Cloudflare Workers 标准计费（请求数 + CPU 时间 + DO 存储）

2Think 执行阶梯 — 简单任务 vs 复杂任务

Think 的核心设计思想是 可组合的执行阶梯 — 每一层都是可选的，按需叠加。简单对话不需要沙箱，复杂任务才启用重计算。而 E2B 方案不管任务简单还是复杂，都要启动一个完整的虚拟机。

Think 执行阶梯（每层独立可选）
Tier 4
Full Sandbox 完整 OS — git, npm test, cargo build, Docker
重 @cloudflare/sandbox
Tier 3
Browser Automation 网页交互 — 点击、导航、数据提取
中 Browser Run
Tier 2
NPM Support 从 npm 注册表加载第三方包
轻 worker-bundler
Tier 1
Dynamic Workers LLM 生成 JS 代码 → 沙箱 isolate 执行
轻 @cloudflare/codemode
Tier 0
Workspace + Chat 虚拟文件系统 + LLM 对话 + 持久记忆 + 工具调用
基础 @cloudflare/think

不同任务类型的开销对比

任务类型 Bloome 占比 E2B Sandbox Cloudflare Think
纯对话
聊天、问答、翻译、总结 		~70% 过度
启动完整 VM 只为调 LLM API
空闲 5 分钟窗口持续计费 		Tier 0
DO 内直接调用 LLM
无 VM 开销，空闲 = $0
IM 操作
发消息、查历史、创建线程 		~20% 过度
VM 内运行 reson-cli
CLI → WS → Server → DB 		Tier 0 + Tools
DO 内 HTTP 直调 Server API
链路更短，延迟更低
轻量代码执行
数据处理、格式转换、计算 		~7% 匹配
VM 内 Node.js 执行
能力充足但启动成本高 		Tier 1-2
Dynamic Worker isolate
按需启动，毫秒级
重型开发任务
git clone、npm install、运行测试 		~3% 匹配
完整 Linux 环境
Shell + 包管理器 + 文件系统 		Tier 4
Cloudflare Sandbox DO
提供 Shell + FS，但较新
关键洞察

~90% 的 Agent 交互根本不需要虚拟机。E2B 方案对所有任务一视同仁地启动完整 VM，而 Think 的分层设计让简单任务（纯对话 + IM 操作）在 Tier 0 就能完成 — 零 VM 开销、毫秒级响应、按请求计费。只有真正需要完整 OS 的重型任务才会升级到 Tier 4。

3触发链路对比

E2B Sandbox 链路（6 个组件参与）
User → Message → Server → MESSAGE_CREATED Event
                     ↓
               handleMessageForAgents()
                     ↓
         ┌─── dispatchAgentTrigger() ───┐
         │                              │
    Local WS?  ─yes→ pushToAgent()     │  Redis Presence?
    (Agent在     直接推送               │  ─yes→ Redis Relay
     本实例?)                           │        转发到目标实例
         │                              │
         no                             no
         ↓                              ↓
    ensureRunningAndPush()          Pending Queue
         ↓                              等待认领
    Phase=idle?  → E2B Create (5-15s)
    Phase=paused? → E2B Resume (2-8s)
    Phase=running → 等待 WS 重连
         ↓
    Runner.cjs 启动 → WS 连接 → 刷新 Pending Queue
         ↓
    createAgentSession() → LLM Call → Stream via WS → Server → IM
Cloudflare Think 链路（3 个组件参与）
User → Message → Server → MESSAGE_CREATED Event
                     ↓
               handleMessageForAgents()
                     ↓
         dispatchAgentTrigger() — Think fast path
                     ↓
         ThinkAgentClient.trigger()
         HTTP POST → Cloudflare Worker
                     ↓
         DO auto-wake (<1ms if hibernated)
                     ↓
         ResonAgent.chat() → LLM Proxy → Server → Gateway → Bedrock
                     ↓
         onChatResponse() → HTTP POST → Server REST API → IM

4关键指标对比

维度 E2B Sandbox Cloudflare Think
冷启动（首次触发） 5 – 15s 慢
创建 MicroVM + 启动 Node + WS 握手		 <50ms 极快
DO 首次创建 = V8 isolate 启动
温启动（从休眠唤醒） 2 – 8s 中等
E2B Resume API + WS 重连		 <1ms 极快
DO 自动唤醒，无显式 resume
热启动（已在运行中） <10ms 快
WS 直接推送		 ~50ms 快
HTTP POST + DO 路由
空闲成本 $0 (auto-pause 后) 零
但 5 分钟活跃窗口有 CPU 计费		 $0 零
休眠 = 仅 DO 存储费（$0.20/GB·月）
活跃成本 $0.000014/s CPU + $0.0000045/s Mem 按秒
× 1.5 markup = ~$0.05/小时 (1vCPU+0.5G)		 CPU: $0.02/百万ms, Req: $0.15/百万 低
典型 Agent 单次触发 ~$0.0001
最大空闲超时 5 分钟 (E2B autoPause) 固定 无限 — 有请求就唤醒 无限
多实例协调 Redis Presence + Ownership Lease 复杂
需要竞争、Grace Period、故障恢复		 不需要 无
DO 全局唯一，CF 负责路由
Session 持久化 JSONL 文件 + R2 备份 脆弱
Sandbox 销毁 = 丢失未备份数据		 SQLite (DO 内置) 持久
自动复制，支持 tree 结构 + fork
Sandbox 执行能力 完整 Linux 环境 强
Shell, git, npm, 文件系统，任意进程		 Cloudflare Sandbox DO 新
Shell + FS via Sandbox SDK，但受 Worker 限制
API Key 安全 注入为环境变量 暴露
API Key 存在于 Sandbox 内存中		 Server LLM Proxy 中转 安全
Worker 只持有 agentToken，不接触真实 Key
代码行数 ~2000 行 庞大
cloud-sandbox/manager.ts + index.ts 调度逻辑		 ~300 行 精简
agent.ts + server.ts + think-client.ts

5用户体验场景对比

💬 场景 1: 用户第一次给 Agent 发消息

Agent 此前从未被触发过，需要完全冷启动

E2B Sandbox
5-15s创建 MicroVM
1-3s启动 Runner
1-2sWS 握手
2-5sLLM 推理
<100msWS 推送回复
总延迟: 9 – 25 秒（用户看到 "Agent 正在启动..." 占大部分时间）
Cloudflare Think
<50ms创建 DO
<10ms配置加载
2-5sLLM 推理
<100msHTTP 回复
总延迟: 2 – 5 秒（几乎全部是 LLM 推理时间，基础设施开销 <100ms）
⏰ 场景 2: Agent 闲置 1 小时后再次触发

Agent 上次回复已过 1 小时，Sandbox 已 auto-pause

E2B Sandbox
2-8sE2B Resume
1-2sWS 重连
<50ms刷新 Pending
2-5sLLM 推理
<100msWS 推送
总延迟: 5 – 15 秒（用户等待期间界面显示 "Agent 恢复中"）
Cloudflare Think
<1msDO 唤醒
2-5sLLM 推理
<100msHTTP 回复
总延迟: 2 – 5 秒（用户感受不到 "唤醒" 过程）
⚡ 场景 3: 用户连续快速发消息

Agent 正在处理第一条消息时，用户又发了第二条

E2B Sandbox — 有状态，需排队
即时WS 推送
排队Runner 串行处理
2-5s第二次 LLM
第二条消息回复: 等待第一条完成后排队处理。Session state 保证顺序一致。
Cloudflare Think — DO 单线程串行
即时HTTP POST
排队DO 串行 (gate)
2-5s第二次 LLM
行为相同 — DO 天然单线程，自动保证请求串行处理。
🔧 场景 4: Agent 需要执行代码/Shell 命令

用户要求 Agent "帮我写个脚本并运行测试"

E2B Sandbox — 完整 Linux 环境
原生完整 Linux Shell (bash/zsh)
原生npm/pip/cargo
原生文件系统 (POSIX)
完整沙箱 — Agent 可安装任何包、运行任何进程、访问完整文件系统。全能力
Cloudflare Think — Sandbox DO 代理
Sandbox SDKexec() / readFile() / writeFile()
备份createBackup() / restoreBackup()
通过 Cloudflare Sandbox DO 提供执行能力 — 支持 Shell、文件操作、备份/恢复。SDK 抽象

6架构复杂度对比

~2000
E2B 状态机代码行数
~300
Think Agent 代码行数
6
E2B 生命周期阶段
0
Think 显式生命周期阶段
E2B 需要管理的
  • 6 个生命周期阶段: idle → creating → running → paused → resuming → dead
  • Redis 双 Lease: Presence Lease (WS连接) + Ownership Lease (生命周期)
  • 多实例竞争: 滚动部署时旧/新实例交接
  • Grace Period: WS 断开后 15 秒宽限期
  • 故障恢复: Sandbox gone、ownership lost、recovery_needed
  • 22 小时续期: 防止 E2B 计费周期过期
  • Pending Queue: 内存队列 + 故障时 Redis 转发
  • Workspace 备份: 定时 tar → R2，恢复时下载
  • 成本结算: settleCost() 精确到秒
Think 全部不需要
  • 无状态机: DO 按需唤醒，空闲自动休眠
  • 无 Redis: DO 全局唯一，CF 路由保证
  • 无多实例竞争: 一个 agentId = 一个 DO
  • 无 Grace Period: 无长连接 = 无断线问题
  • 无故障恢复: CF 自动处理 DO 故障转移
  • 无续期逻辑: DO 无运行时间限制
  • 无 Pending Queue: HTTP 请求天然排队
  • 无手动备份: SQLite 内置持久化
  • 简化计费: CF 标准计费（请求 + CPU 时间）

7组件替换映射

E2B 组件 Think 替代 说明
E2B Sandbox (Firecracker MicroVM) Cloudflare Durable Object 从完整 VM → 轻量 V8 isolate
Runner.cjs (sandbox 内进程) ResonAgent.chat() Think SDK 内置推理循环
JSONL Session 文件 Think Session (SQLite) 结构化、可 fork、树形历史
Redis Presence/Ownership 不需要 DO 天然全局唯一
WebSocket 双向通信 HTTP POST (触发) + HTTP POST (回复) 无状态、更简单
SandboxManager (~1500 行) ThinkAgentClient (~100 行) 从复杂状态机 → 3 个 HTTP 调用
R2 Workspace 备份 DO SQLite 自动持久化 无需手动管理备份/恢复
API Key 注入环境变量 Server LLM Proxy 中转 API Key 不离开 Server
E2B Shell (完整 Linux) Cloudflare Sandbox SDK exec() + readFile() + writeFile()

8迁移当前状态

✓
Worker 已部署到 Cloudflare
✓
Server ThinkClient 已实现
✓
触发链路打通 (Server → Worker)
WIP
LLM Proxy 回调 (Worker → Server)
当前阻塞: Zod v4 + AI SDK v6 工具 Schema 兼容性

Zod v4 生成的 JSON Schema 缺少 input_schema.type 字段，导致 AWS Bedrock 拒绝请求 (400 Bad Request)。LLM 推理本身已打通（LLM Proxy → Gateway → Bedrock 链路正常），只是工具定义的 Schema 序列化有问题。临时方案：禁用所有工具后验证纯文本对话是否可用。

文件 状态 说明
apps/think-agent/ 新增 Worker 完整实现（agent.ts, server.ts, reson-tools.ts, sandbox-tools.ts）
apps/server/.../think-client.ts 新增 Server 端 HTTP 客户端（含 ProxyAgent 代理支持）
apps/server/.../index.ts 修改 ACP 调度增加 Think fast path（含临时 DEBUG 日志）
agent.ts getTools() 临时禁用 返回空 {} 以绕过 Zod v4 schema 问题

9总结与判断

Think 方案的核心优势

  • 冷启动从 15 秒降到 50ms — 用户体验从 "等待启动" 变为 "即时响应"
  • 消除 2000 行状态机代码 — 用 Cloudflare 托管基础设施替代手写生命周期管理
  • 不再需要 Redis 协调 — DO 全局唯一天然解决多实例竞争
  • Session 从脆弱的 JSONL 文件升级为 SQLite — 支持 tree 结构和 fork
  • API Key 安全性提升 — 从注入环境变量到 Server Proxy 中转
  • 空闲成本从 "5 分钟 CPU 窗口" 降为 "按请求计费"
需要关注的取舍
  • 沙箱执行能力: Cloudflare Sandbox SDK 是新产品，功能不如完整 Linux VM 成熟
  • 回复方式从流式变为一次性: E2B 通过 WS 流式推送 token，Think 当前通过 HTTP POST 完整回复（可优化为 SSE）
  • 调试能力: E2B 有完整的 SSH/Terminal 接入，Think DO 只有 wrangler tail 日志
  • Vendor Lock: 从 E2B (可替换) → Cloudflare DO (深度绑定)
  • Zod v4 兼容性: Think Agent 依赖 Zod v4 + AI SDK v6，当前存在序列化问题