当你的 Agent 不再只是"调用 API"，而是能真正跑命令、写文件、编译代码——这就是 Cloudflare Computer 在做的事。
读完本文你将了解：操作步骤 | 技术原理 | 架构设计 | 适用场景
🎯 这个项目解决什么问题？
AI Agent 开发中最痛的瓶颈之一：Agent 缺乏持久化的执行环境。
现有的方案要么用临时 sandbox（每次重新创建，状态全丢），要么用 API 调用（只能调外部服务，无法在环境里操作）。Agent 像一个没有桌子的工程师——脑子里有想法，但连把扳手都摸不到。
Cloudflare Computer 给出的答案是：把文件系统 + 执行环境打包进 Durable Object，天然持久化。Agent 写进去的文件，下次对话还在；执行的脚本结果，跨 session 可查。这不是"给 Agent 加一个 API 调用能力"，而是给 Agent 一台真正的电脑。
🔧 快速上手
Cloudflare Computer 目前处于 PREVIEW 阶段。要跑通第一个示例，你需要：
- Cloudflare 账号 + Workers 配额（免费套餐即可）
- Wrangler CLI：
npm i -g wrangler - 一个空的 Workers 项目作为实验环境
Step 1：安装 Computer 包
npminstall@cloudflare/computerStep 2：创建带 Workspace 的 Worker
import{Workspace}from"@cloudflare/computer";exportdefault{asyncfetch(request,env){constworkspace=newWorkspace({storage:env.MY_DO,// Durable Object storage handle});// 写文件到持久化 VFSawaitworkspace.fs.writeFile("/workspace/hello.txt","Hello, persistent Agent!");// 读取刚写入的文件constcontent=awaitworkspace.fs.readFile("/workspace/hello.txt","utf8");returnnewResponse(`Read back:${content}`);},};Step 3：配置 wrangler.toml
name = "computer-demo" main = "src/index.ts" [[durable_objects.bindings]] name = "MY_DO" class_name = "MyDO"Step 4：用 runtime.exec 执行命令
// 使用 container 后端执行 shell 命令consthandle=awaitworkspace.runtime.exec("npm init -y",{backend:"container-shell",cwd:"/workspace",});constresult=awaithandle.result();console.log(result.stdout);这一步的关键在于backend参数——它决定了你用的是哪个执行表面：
container-shell：完整 Linux 用户空间，跑真实命令worker-shell：轻量 shell（just-bash），在 Dynamic Worker 中运行worker-javascript：纯 JavaScript 模块，无 shell
为什么分三种后端？因为性能差几个数量级。
npm test需要完整容器，但ls -la用 Worker 就够了——选错后端，钱就花出去了。
⚙️ 技术原理
Cloudflare Computer 的核心设计可以拆成三层：VFS 层、同步协议层、执行层。
第一层：SQLite VFS（虚拟文件系统）
所有文件数据存在Durable Object 的 SQLite 存储中。这是整个架构的权威数据源。
每个文件被切分成 512KB 的 chunk，每个 chunk 按内容哈希后存入 blob store。同内容只存一份——三个项目都用同一个lodash.min.js，磁盘上只有一个副本。这就是 content-addressed 存储的威力。
写文件时，只有变更的 chunk 被同步回 DO。这比"整个文件重传"省了几倍的带宽和存储。
第二层：同步协议
Container 和 DO 之间通过capnweb RPC保持同步。同步流程：
push → spawn → events/result → pull- push：把 DO 侧的变更推到容器
- spawn：启动命令执行
- events/result：收集执行结果
- pull：把容器的文件变更拉回 DO
worker-shell后端跳过 push/pull（它直接读共享存储），所以零同步开销。
第三层：三大执行后端
性能关键数字（来自官方基准测试）：
| 操作类型 | Container (FUSE) | tmpfs 对比 | ext4 磁盘对比 |
|---|---|---|---|
| stat 1000 个文件 | 1972ms | 1.49x | 0.91x |
| rm 1000 个文件 | 828ms | 2.56x | 0.66x |
| mkdir tree (10³) | 1598ms | 1.01x | 0.74x |
| find tree | 1814ms | 1.00x | 0.72x |
| npm init + tiny install | 599ms | 0.95x | 0.95x |
| 完整 npm install (854 包) | 124.7s | 3.6x | 1.9x |
| 解读：元数据密集型操作（stat/rm/find/git）FUSE 比真实磁盘还快——这是 DO 内存 inode store 的红利。但大文件顺序 I/O（64MB 读/写/复制）慢 20-40 倍，这是 content-addressed 写路径（每 chunk 都要哈希 + blob store）的代价。 | |||
对实际开发的影响：npm install整体差 1.9x，但开发时 90% 的操作是"找文件、读配置、跑测试"——这些都落在 FUSE 优势区间。只有"打包 50MB 的 vendor 目录"才会暴露瓶颈。 |
执行流程序列
🏗️ 架构分析
Cloudflare Computer 是一个小精悍的 monorepo，四个核心包各司其职：
- dofs：VFS 核心。SQLite schema、inode 管理、同步协议、Node.js @platformatic/vfs provider
- rpc：capnweb wire 类型和 server/client 辅助函数
- computerd：在 container 内运行的 daemon，FUSE mount + HTTP/WebSocket RPC server
- computer：顶层 API，Durable Object 的入口
为什么不用现成的 Sandbox SDK？
Cloudflare 已有cloudflare/sandbox-sdk，为什么还要做 Computer？答案在设计文档里写得很清楚：
Sandbox SDK 的问题是：每次创建都是全新的容器，状态不持久。Computer 把文件系统搬到 DO 层，天然跨 session 持久化。这是架构层面的根本差异，不是优化问题。
✅ 优缺点 & 适用场景
优势
- 天然持久化：DO 生命周期内的文件系统状态永久保存，跨 session 可用
- Content-addressed 存储：同内容去重，节省存储和带宽
- 元数据操作快于磁盘：FUSE 的 inode cache 在 stat/rm/find 场景下碾压 ext4
- 多后端路由：不同任务选不同执行表面，性能成本可控
- Cloudflare 生态整合：与 Workers AI、Think、Artifacts 深度集成
劣势
- PREVIEW 状态：API 不稳定，不适合生产
- 大文件 I/O 瓶颈：64MB 读写慢 20-40 倍，打包/构建场景不友好
- 仅 Cloudflare 平台：依赖 Workers + Containers，跨平台迁移成本高
- 不接受外部 PR：贡献路径受限
适用场景
- ✅ AI Agent 开发沙箱（持久化状态、跨 session 上下文）
- ✅ 自动化 Pipeline（跑测试、build、CI 任务）
- ✅ 文档/代码分析 Agent（读文件、生成报告、持久化结果）
- ❌ 需要完整 GPU 的 ML 训练任务
- ❌ 大文件视频/图像处理
- ❌ 跨云厂商的 Agent 平台
总结
Cloudflare Computer 不是又一个 sandbox——它是把文件系统和执行环境搬进 Durable Object的一次架构实验。它的价值不在"跑得更快"，而在"跑完还能留着"。
对于 AI Agent 领域，这个方向的意义可能比技术细节本身更大：当 Agent 拥有了持久的"工作区"，它就不再是"一问一答"的对话工具，而是真正能在环境里工作的协作者。这就是从"API 调用者"到"有桌子的工程师"的跨越。
当然，PREVIEW 状态说明它还远不够成熟。但方向对了——让 Agent 拥有真正的计算环境，是这个赛道终局形态的必经之路。
