什么是Cloudflare Computer？Agent专用持久化虚拟文件系统3大执行后端全解析-编程实验室

什么是Cloudflare Computer？Agent专用持久化虚拟文件系统3大执行后端全解析

【免费下载链接】computerGive your agent a computer 👾项目地址: https://gitcode.com/GitHub_Trending/computer1/computer

Cloudflare Computer是一个专为 AI Agent 设计的持久化虚拟文件系统：它把文件状态存放在 Durable Object 的 SQLite 数据库中，跨重启不丢失，并通过可插拔的 3 大执行后端（Container、Worker Shell、Worker JavaScript）为 Agent 提供一台真正意义上的"随身电脑" 👾。无论 Agent 需要跑 shell 命令、编译代码还是执行 JS 模块，都只需一个入口workspace.runtime.exec，由你选定的后端决定如何执行。本文将完整解析这套架构与 3 大后端的核心区别，帮你快速选型。

一、为什么 Agent 需要一台"电脑"？

大模型本身没有持久状态：聊完即忘、文件即丢。让 Agent 干活（写代码、跑测试、生成文档）时，它通常需要一个稳定、持久、可执行的工作区。

传统方案是起一台虚拟机或容器，但它笨重、成本高、且与云端 Serverless 架构割裂。Cloudflare Computer 的思路是：

📦文件即 SQLite：整个文件树存放在 Durable Object 的 SQLite 里，天然持久化，约 10GB 上限，随 Agent 会话创建；
🔌执行可插拔：文件系统只是底座，真正"跑东西"的能力由 3 种后端提供，按需选择；
⚡单一执行入口：workspace.runtime.exec(source, { backend })一行代码切换执行环境。

官方定位非常清晰——为需要小型便携文件系统和配套工具的 Agent 而生（详见 docs/README.md）。

二、核心架构：SQLite 是唯一的"真相源"

Cloudflare Computer 的架构图揭示了它最核心的设计：Durable Object 侧的 SQLite 存储是文件系统的唯一权威来源，容器侧只是一个通过 FUSE 挂载出来的"活镜像"。

图中上半部分是沙箱容器，下半部分是 Durable Object，二者通过一条Sync Protocol（同步协议）保持双向一致：

DO → 容器（push）：每次exec()前，DO 把容器还没看到的变更（增量版本号）推送过去；
容器 → DO（pull）：命令跑完后，DO 拉回容器内 FUSE 写入的所有变更，落盘到 SQLite。

这套增量双向同步是最终状态式的：每条变更带单调递增的版本号，接收方幂等应用，即使中途崩溃也能从断点续传。同步协议完整设计可见 docs/02_sync_protocol.md。

对开发者的实际收益是：你在 DO 侧用fs.writeFile写的文件，容器里的 shell 立刻看得到；容器里git clone下来的仓库，DO 侧随即也能读取。两边共享同一个文件树。

三、3大执行后端全解析

同一个 Workspace 可以同时注册多个后端（用稳定 ID 区分），exec时通过backend参数路由。三大后端定位各不相同：

后端一：Container —— 完整 Linux 环境的"重型武器"

Container 后端把 SQLite 状态通过 computerd 守护进程以FUSE 挂载成一个真实文件系统，投进 Cloudflare 沙箱容器：

✅ 完整 Linux 用户态：真实二进制、真实内核、真实网络，npm install、gcc、pandoc随便跑；
✅ 容器内/workspace与 DO 侧文件树实时镜像；
⚠️ 成本：每个会话一个容器，重 I/O（大体积node_modules安装）相比原生磁盘有可感知的性能损耗。

computerd是一个自包含的 Node SEA 单二进制文件，内嵌 Node 运行时与 FUSE 驱动，宿主机镜像无需任何额外依赖。它负责 FUSE 挂载、脏写追踪、命令执行与 RPC 端点，详见 docs/07_injected_service.md。

后端二：Worker Shell —— 即开即用的"轻量极速"选项

Worker Shell 后端在 Dynamic Worker 中运行 just-bash 解释器，完全没有容器：

⚡ 冷启动极快、按 Worker 计费，成本远低于容器；
✅ 支持丰富的文本类命令：cat、grep、awk、sed、jq、sort等；
✅ 通过 Workers RPC 直接访问 DO 侧同一个 SQLite 存储——没有第二份副本，零同步开销；
⚠️ 局限：不是完整 Linux 用户态，不能编译、不能装包。

选型口诀：Agent 只需要"读、搜、转、总结"类文本操作时，Worker Shell 是性价比之王。完整说明见 docs/12_worker_backend.md。

后端三：Worker JavaScript —— 模块化的 JS 隔离运行时

第三个后端直接在动态 Worker 中运行ECMAScript 模块，把"执行"从 shell 命令升维成了结构化编程：

📜 源码是真实的 ES 模块：支持静态 import、顶层 await、default export函数接收结构化输入并返回结构化结果；
📁 内置 Workspace 版node:fs/promises——写代码时直接操作持久化文件系统；
🧩 支持"持久化相对导入"：import task from "./task.js"会解析到 Workspace 文件系统里的文件，代码本身也是持久化的；
🔐 可信模块ws:git、ws:artifacts可直接做 Git 操作和发布制品。

它与 Worker Shell 共用 Worker 的隔离与低成本优势，但换来的是类型化 I/O 和确定性返回值，非常适合把 Agent 的"技能"沉淀成可复用模块。设计细节见 docs/17_isolate_javascript.md。

一张表看懂 3 大后端怎么选

维度	Container	Worker Shell	Worker JavaScript
执行内容	Shell 命令	Shell 命令（just-bash）	ES 模块
环境完整度	完整 Linux 用户态	文本类命令子集	Worker JS 运行时
启动/成本	容器级，最重	毫秒级，最轻	毫秒级，最轻
网络能力	支持	支持（策略可控）	支持（策略可控）
同步开销	有（push/pull）	无（共享存储）	无（共享存储）
典型场景	编译、装包、跑测试	读/搜/转文本	结构化任务、可复用技能

后端路由与生命周期差异详见 docs/05_runtime_interface.md。

四、快速上手：5 分钟给 Agent 配一台"电脑"

npm install @cloudflare/computer

在 Durable Object 中挂上 Workspace 和后端，文件操作与命令执行就通了（完整示例见 examples/container 与 examples/worker-shell）：

const workspace = new Workspace({ storage: this.ctx.storage, backends: [new CloudflareContainerBackend({ /* ... */ })], }); // 写文件（DO 侧，持久化） await workspace.fs.writeFile("/workspace/notes/todo.md", "- [ ] ship it\n"); // 跑命令（容器侧，看到的正是同一棵树） const run = await workspace.runtime.exec("ls -la /workspace"); const { stdout } = await run.result();

几个贴心细节：

🌊exec返回ReadableStream事件流，可以逐帧转成 SSE 推给前端，实时看 Agent 的输出；
🧰 需要给@cloudflare/agents接工具？@cloudflare/computer/tools直接提供read、write、edit、ls、grep、exec、publish等现成 AI SDK 工具，详见 docs/09_tool_interface.md；
🌐 想体验容器里"写 markdown → pandoc 转 PDF"的完整链路，看 examples/tutorial；想对比容器与 Worker 运行时跑同一任务，看 examples/think-compare-runtimes。

五、性能表现如何？

官方用fs-bench做了系统基准测试（standard-2 容器，1 vCPU / 6 GiB），结论很有参考价值：

🏆元数据密集型操作占优：统计 1000 文件、删除 1000 文件、目录树遍历、git init等场景，FUSE 挂载比真实 ext4 磁盘还快（ratio < 1.0）；
🐢大块顺序 I/O 偏慢：64 MiB 文件读写比磁盘慢 20~40 倍；完整安装 sandbox-sdk（3.6 万文件）耗时约 125s vs 磁盘 64s。

完整数据与复现方法见 docs/19_performance.md。实践建议：它适合 Agent 规模的中等体量工作区，不适合往里面塞巨型 monorepo 或跑高带宽 I/O。

六、注意事项与适用边界

Preview 阶段：包仍为 Preview，API 不稳定，适合实验与原型，暂不建议生产使用；
容量约束：与 DO 共享约 10GB 存储；容器侧文件树在内存中，超大目录树不适合；
路径规范：所有路径必须是 POSIX 风格的绝对路径（/workspace/...），相对路径会被拒绝；
当前为文件系统 + 后端预览：从 R2/Artifacts/GitHub 自动挂载数据的 Mount 子系统已在 schema 中预留，尚属规划中特性。