OpenClaw 与 E2B 集成可行性分析
1. OpenClaw 支持 E2B 吗？
不支持。 OpenClaw 的沙箱方案是基于 Docker 自研的：
- 每个 session 可跑在独立 Docker 容器里（
sandbox.mode: "non-main"） - 支持工具白名单/黑名单
- 工作目录 bind mount 进容器
2. OpenClaw 能运行在 E2B 上吗？
技术上可以，但实际意义不大。
OpenClaw 核心依赖
- Node.js runtime（Gateway 常驻进程）
- 持久化文件系统（SOUL.md、MEMORY.md、workspace）
- 长连接（Telegram/Discord WebSocket）
- 外部工具访问（浏览器、飞书 API 等）
E2B 的限制
- Sandbox 有生命周期限制（Pro 最长 24 小时）
- 文件系统不持久，重建后丢失
- 每个 sandbox 独立，不适合跑长期服务
- GPU 不可用
架构不匹配
OpenClaw Gateway 是常驻服务，需要 7×24 运行；E2B 是临时执行环境，sandbox 会自动回收。把常驻服务塞进临时环境，生命周期模型不兼容。
3. E2B vs OpenClaw Docker 沙箱对比
| 维度 | OpenClaw Docker | E2B |
|---|---|---|
| 隔离方式 | 容器（进程级） | Firecracker microVM（硬件级） |
| 冷启动 | 秒级 | ~150ms |
| 安全边界 | Docker breakouts 可能 | VM 级隔离，更强 |
| 持久化 | 容器生命周期 | 支持暂停/恢复 |
| 成本 | 本地 Docker，免费 | 云服务付费（Hobby $0.06/h） |
| 并发上限 | 取决于宿主机资源 | Hobby 20 / Pro 100 / 可扩至 1,100 |
| 自托管 | N/A（本身就是本地） | 支持（Manus 用的就是自托管） |
4. 更合理的集成方式
把 E2B 当 OpenClaw 的执行后端，而非宿主：
OpenClaw Gateway (VPS 常驻)
↓ API 调用
E2B Sandbox (临时创建，执行完销毁)
- OpenClaw 跑在 VPS 上，负责消息收发、工具调度、记忆管理
- 需要隔离执行不信任代码时，通过 E2B API 创建 sandbox
- 执行完毕后销毁 sandbox
需要写中间层桥接，目前 OpenClaw 没有内置 E2B 集成。
5. E2B 调度系统简述
E2B 没有用 K8s，而是自研调度器：
- 语言：Go
- 底层：Firecracker（AWS 开源 microVM）
- 接口：gRPC API
- 调度特点：秒级冷启动、持久会话（可暂停/恢复）、并发控制、自动回收
- 自托管：Manus 用的就是 E2B Self-hosted，部署在自己服务器上
E2B vs K8s
| 维度 | E2B | K8s |
|---|---|---|
| 调度单位 | Firecracker microVM | Pod（容器） |
| 启动速度 | ~150ms | 秒级 |
| 隔离级别 | 硬件级 | 进程级（除非用 kata containers） |
| 定位 | AI 代码执行沙箱 | 通用容器编排 |
| 复杂度 | 轻量，专一 | 重，功能全 |
6. 结论
- OpenClaw 不支持 E2B，沙箱方案是 Docker
- OpenClaw 运行在 E2B 上技术上可行但架构不匹配（常驻服务 vs 临时沙箱）
- 最佳实践：OpenClaw 作为控制面跑在 VPS，E2B 作为执行面按需创建 sandbox
- OpenClaw 管的是 agent 全生命周期（渠道、工具、记忆、调度），E2B 只管代码执行的隔离环境