每天一个开源项目#61 3.9K Stars：Cloudflare 给 Agent 一台持久云电脑

GitHub Trending 第 1 名 ｜快照日期：2026-08-06｜3,913 Stars ｜184 Forks｜TypeScript｜MIT

项目地址：github.com/cloudflare/...

📋 项目概览

项目	信息
项目名	`cloudflare/computer`（Cloudflare Computer）
一句话定位	为云端 Agent 提供 SQLite 持久文件系统，并以统一接口接入容器、Worker Shell 和隔离 JavaScript 三类执行后端
Trending 排名	今日第 1 / 共 13 个项目
Stars / Forks	3,913 / 184（Trending 快照）
Open Issues	GitHub API 为 24，补充核对其中 4 个为开放 PR，约 20 个为开放 Issue
创建 / 最近推送	2026-06-05 / 2026-08-05
主要语言	TypeScript 94.7%、JavaScript 3.3%、Shell 2.0%
License	MIT
版本状态	npm `latest` 为 0.1.1；审计时 `main/packages/computer/package.json` 仍为 0.1.0-alpha.1；无 GitHub Release 页面记录，但已有 `v0.1.1` Tag
成熟度	Preview Only：官方明确只建议实验、探索和原型，不适合生产

数据口径说明： Stars、Forks、排名和语言占比来自 2026-08-06 Trending 任务快照；版本、贡献者、PR 与源码结构来自同日 API/源码补充核验。快照没有保存"今日新增 Stars"，因此本文不会把 Trending 排名倒推成虚构的日增量。

🔥 为什么值得关注

Agent 不只是需要一组 API，它往往还需要一块可以反复读写的"工作台"：保存计划、代码、下载文件和中间产物，运行 git、测试、构建工具，再把结果交给下一轮推理。传统做法通常把这些能力拼在临时容器、对象存储和数据库之间；容器被回收后状态容易丢失，直接挂磁盘又很难复制、迁移和按用户隔离。

Cloudflare Computer 的关键变化，是把持久状态 与执行环境 解耦：Durable Object 内的 SQLite 虚拟文件系统才是权威数据源，容器或隔离 Worker 只是可替换的执行面。Agent 可以用同一套 workspace.fs 管文件，再通过 workspace.runtime.exec() 决定本次任务需要完整 Linux、轻量 Shell，还是带结构化输入输出的 JavaScript 隔离环境。

这比"再封装一个 Agent 工具集"更有系统价值。它真正处理的是 Agent 基础设施最难的边界问题：状态如何跨重启保留、文件如何增量同步、不同执行后端如何共享工作目录、长任务怎样流式输出，以及隔离能力与执行权限如何划分。需要强调的是，它目前仍是 Cloudflare 平台上的预览组件，而不是通用本地虚拟机，也不是可以直接投入生产的多租户沙箱产品。

🏗️ 核心特性

1. SQLite 是权威文件系统，而不是旁路元数据

workspace.fs 提供接近 node:fs/promises 的异步接口，覆盖 readFile、writeFile、mkdir、readdir、rm、grep 等操作。数据位于 Durable Object 自己的 SQLite 中，因此 DO 重启后仍可恢复；Workspace 也可以完全不配置执行后端，只作为约 10 GB 上限的持久文件系统使用。

源码中的核心表不是简单的"路径---内容"键值表，而是 inode 风格设计：

vfs_nodes：文件、目录、符号链接的 inode 元数据；
vfs_dirents：父 inode 与名称到子 inode 的映射；
vfs_chunks：文件的分块顺序；
vfs_blobs / vfs_blob_bytes：以 SHA-256 寻址的块元数据与字节；
vfs_changes：删除操作留下的 tombstone；
_vfs_watermark / _vfs_fetch_cursor：增量同步游标。

这种设计带来两个直接收益：本地 rename 只需修改目录项，硬链接也能自然表达；相同文件块只保存和传输一次。它不是把 SQL 数据库伪装成磁盘那么简单，而是在为 Agent 工作目录设计一套可同步的内容寻址 VFS。

2. 三种执行后端，共用一个 `runtime.exec()`

后端	`source` 的含义	文件访问路径	适合任务	主要代价
Container	Shell 命令	`computerd` 通过 FUSE 挂载容器侧 VFS，并与 DO 双向同步	原生二进制、包管理器、网络、完整 Linux 工具链	冷启动更慢；存在同步成本；权限面最大
Worker Shell	`just-bash` 命令	每次文件操作通过 Workers RPC 直达权威 Workspace	`grep`、文本处理、轻量 Git 与短命令	不是真实 Linux，命令兼容范围有限；不能按 ID 重连
Worker JavaScript	ECMAScript 模块	Dynamic Worker 获得 Workspace 支持的 `node:fs/promises`	结构化输入输出、受控 JS 自动化、可信模块调用	依赖实验性 Worker Loader；不是任意 Node 环境

统一入口看似只是 API 收敛，实际价值在于调度策略：Agent 可以把便宜、快速的文本操作放进 Worker Shell，把需要 pandoc、编译器或系统包的任务路由到容器，把需要结构化返回值的逻辑交给 JavaScript 后端。同一个 Workspace 还能注册多个稳定 ID，并按调用选择：

ts 复制代码

const grep = await ws.runtime.exec("grep -r TODO /workspace", {
  backend: "shell",
});

const build = await ws.runtime.exec("npm test", {
  backend: "sandbox",
});

后端会在首次 exec、push、pull 或 ready(id) 时惰性连接，避免没有任务时提前支付启动成本。

3. 512 KiB 内容寻址分块，只同步真正缺失的字节

容器后端存在两份文件树：DO 侧 SQLite 是持久真相，容器侧是 computerd 的进程生命周期数据库并通过 FUSE 暴露为真实目录。两边各自维护单调递增 revision，典型命令链路如下：

DO 将容器尚未见过的变更按路径合并，连续五次改写同一路径只发送最终状态；
文件按固定 512 KiB 分块，变更项只携带 (hash, size)，不内嵌字节；
接收端先用 hasObjects 告知已有哈希，发送端只补传缺失块；
容器执行命令，FUSE 写入被记录为新的容器 revision；
命令结束后，DO 以最多 256 个变更项一批拉取，补齐缺失块并提交 SQLite；
(rev, path) 游标在每个已提交批次后推进，崩溃重试最多重做一个批次。

协议借鉴了 Git 的 have/want 思路，但同步的是"当前文件树"，不是提交历史。它选择 final-state + tombstone，而不是重放 rename 等操作日志，从而让冷启动、重试和幂等收敛遵循同一套规则。

4. 为 Agent 准备的工具、Git 和产物出口

@cloudflare/computer/tools 可直接生成 AI SDK 工具，默认包含 read、write、edit、ls，配置后再加入 exec 和 publish。读取工具支持最大字节数和行数限制，流式执行结果还能转换成 SSE，避免长命令结束前 Agent 和前端完全失去反馈。

Git 不是必须依赖 Shell：项目通过 isomorphic-git 直接操作 SQLite VFS，并把 pako 替换为 Workers 的 node:zlib；只有导入 @cloudflare/computer/git 时才加载这部分依赖。文件可以通过 R2 预签名链接分享，也能以 session 前缀隔离后发布到 Cloudflare Artifacts。

5. 明确处理长连接生命周期和失败恢复

README 特别提醒：Workers RPC 不会自动回收远端 stub。长会话需要对 getWorkspace() 和 runtime.exec() 返回值使用 using，否则远端对象会一直积累到会话结束。源码中还有 stub soak 测试，能直接观察"不释放"时每轮累积的 Workspace 与 Exec Handle stub。

命令完成但回拉失败时，结果会标记同步为 pending。应用可配置 SyncRetryScheduler，借助 Durable Object alarm 做有界指数退避；项目没有擅自接管应用的 alarm。这个边界虽然增加了接入工作，却比隐藏失败更可靠。

🔬 技术架构深度解析

总体架构

text 复制代码

                       Cloudflare Worker / Agent
                                │
                     getWorkspace(DO Stub)
                                │ Workers RPC
                                ▼
┌──────────────────── Durable Object ────────────────────┐
│ Workspace                                               │
│ ├─ fs / git / tools                                     │
│ ├─ runtime.exec(source, { backend })                    │
│ └─ SQLite VFS（持久、权威状态）                         │
│    ├─ nodes + dirents：命名空间                         │
│    ├─ chunks → SHA-256 blobs：文件内容                  │
│    └─ revisions + cursors + tombstones：增量同步        │
└───────────────┬──────────────────┬──────────────────────┘
                │                  │
        capnweb WebSocket      Workers RPC / Loader
        push → exec → pull          │
                │                  ├───────────────┐
                ▼                  ▼               ▼
      ┌─────────────────┐  ┌──────────────┐  ┌────────────────┐
      │ Container       │  │ Worker Shell │  │ Worker JS      │
      │ computerd       │  │ just-bash    │  │ ES Module      │
      │ memory DB       │  │ 直接读权威 FS│  │ 结构化输入输出 │
      │ FUSE /workspace │  └──────────────┘  └────────────────┘
      │ Linux / network │
      └─────────────────┘

这里最值得注意的是：三类后端的"共享文件系统"并不采用同一种实现。容器需要真实 FUSE 目录，所以维护第二份状态并执行 push/pull；两个 Worker 后端直接通过 RPC 访问权威 Workspace，不需要额外存储和同步往返。这避免了为 API 统一而强行统一底层机制。

容器同步的数据面

text 复制代码

DO mutation
   │ bump rev
   ▼
coalesceChanges(after pushRev) ── 每路径保留最终状态
   │
   ├─ ChangeEntry：path / type / mode / mtime / chunk hashes
   └─ hasObjects(hashes) → pushObjects(missing)
                              │
                              ▼
                     computerd SQLite VFS
                              │ FUSE
                              ▼
                       Linux command writes
                              │
fetchChanges(after {rev,path})
   │ 每批最多 256 项
   ├─ 查询本地已有 blobs
   ├─ fetchObjects(missing)
   ├─ transactionSync 写入
   └─ 提交后推进 cursor

固定分块非常适合追加、尾部改写和重复依赖，但对文件头插入不友好：前面插入一个字节会让后续所有固定边界偏移，导致大量块哈希变化。文档讨论了 FastCDC / buzhash 等内容定义分块，但当前源码仍是固定 512 KiB，不能把规划当成已实现特性。

一致性与并发边界

单个 Durable Object 内的写入由平台 input gate 和 Workspace 队列串行化；同步批次可以原子或幂等重试。但两个容器同时改同一路径时，项目采用同步粒度的最后写入者获胜：没有 CRDT、文件锁或三方合并，也不会提示其中一方内容被覆盖。

因此它适合"一 Workspace、一个活动写者"，或多个 Agent 各写独立子目录；不适合多个 Agent 并发更新共享 PLAN.md、计数器或日志。Agent 交接前后还需要显式同步点。对象级完整性可以保证，业务内容级冲突检测则尚未提供。

权限边界：执行后端不是授权系统

backend 参数只是路由选择，不是安全凭证。后端在构造时决定最大权限，例如 JavaScript 后端可配置只读或读写；对外网关仍必须验证签名能力允许选择哪些后端。尤其 Container 后端拥有真实二进制和网络，不能因为它由统一 API 调用就误认为天然安全。

换句话说，Cloudflare Computer 提供了隔离与执行构件，但多租户产品仍需自己补齐身份认证、能力授权、网络出口策略、密钥注入、资源配额和审计。Agent 工具层的描述或模型选择也不能替代确定性的权限控制。

性能：元数据操作有亮点，大文件吞吐是硬伤

官方基准运行于 Cloudflare Containers standard-2（1 vCPU、6 GiB 内存、12 GB 磁盘），REPS=3、WARMUP=1。以下数字是维护者提供的结果，并非本文独立云端复测：

场景	computerd	ext4	computerd / ext4	结论
`stat` 1,000 文件	1,971.9 ms	2,659.3 ms	0.91×	比 ext4 快约 9%
删除 1,000 文件	827.7 ms	1,281.8 ms	0.66×	元数据路径有优势
`find` 目录树	1,813.6 ms	4,404.2 ms	0.72×	内存 inode 查询占优
浅克隆约 1 MB 仓库	549.1 ms	576.2 ms	0.84×	小型 Agent 仓库可接受
写入 64 MiB	230.6 ms	16.8 ms	16.93×	大文件明显更慢
读取 64 MiB	437.5 ms	25.6 ms	39.72×	不适合作为大数据盘
安装 854 个 npm 包、36,675 文件	124.7 s	63.9 s	约 1.95×	完整依赖安装成本较高

慢点来自每个 512 KiB 块都要计算哈希、写入内容寻址存储并维护同步元数据。项目更像"Agent 的耐久小工作目录"，而不是高吞吐通用磁盘；README 也明确建议避开完整大型 monorepo、模型权重、视频和重型归档解压。

源码成熟度与实测

审计的 main 提交为 76d9e75c。浅克隆统计到 541 个跟踪文件 ，其中 377 个 .ts 文件；按文件名识别出 148 个测试文件 。仓库包含 dofs、rpc、computerd、computer 四个主要包和 8 个可运行示例，不是只放 README 的概念项目。

本文在干净克隆上执行：

bash 复制代码

npm ci
npm run build --workspace @cloudflare/computer
npm test --workspace @cloudflare/computer

构建与测试均以退出码 0 完成。主 Vitest 套件 897 项，加上 proxy 5 项、worker backend 4 项、script runner 23 项、stub soak 4 项，共 933 项测试通过 。需要注意两点：本地 Node SQLite 仍输出 experimental warning；npm ci 的依赖审计报告 2 个 moderate、6 个 high 风险项，这只是工作区依赖扫描结果，并不等同于已确认的产品可利用漏洞，但生产试点前应进一步区分开发依赖与运行时依赖并完成审计。

📖 README 核心内容摘要

README 的核心设计可以概括为四句话：

文件先于执行环境。 Workspace 即使没有 backend 也能独立工作，持久目录不是容器附属品。
一个入口，多种执行语义。 runtime.exec() 的 source 在容器和 Worker Shell 中是命令，在 Worker JavaScript 中是 ES Module；调用方必须清楚后端切换也会切换语言语义。
为 Agent 提供现成能力。 AI SDK 工具、Git、R2 只读挂载、Assets 与 Artifacts 让文件从生成到发布形成闭环。
生命周期必须显式管理。 长会话需要释放 stub，容器同步失败需要应用侧 alarm 承接重试。

README 还给出了清晰的规模限制：每个 Workspace 与 DO 共享约 10 GB，容器侧文件系统位于内存，不应承载超大目录；重 I/O 会被 FUSE、哈希和同步放大。文档目录虽然详细，却被官方标记为 forward-looking，阅读时必须区分当前代码和目标设计。

当前已实现与规划项尤其容易混淆：

能力	审计结论
SQLite VFS、三执行后端、统一 runtime、Git、AI SDK tools	当前源码存在并有测试覆盖
R2 只读 mount provider	当前源码存在
文档中泛化的 GitHub/Artifacts/custom mount	设计文档标注"not yet implemented"，不能按完整挂载体系宣传
内容定义分块 FastCDC	仅规划；当前固定 512 KiB
`vfs_changes` tombstone 自动清理	文档明确尚未接线，删除密集工作负载可能让表持续增长
多写者冲突检测/合并	未实现，当前为 last-write-wins

🚀 快速上手指南

1. 安装

bash 复制代码

npm install @cloudflare/computer

截至本次核验，npm latest 指向 0.1.1。预览期 API 仍可能破坏性变化，严肃试验应在 package.json 中锁定精确版本，而不是长期漂移跟随 latest。

2. 先创建一个不带执行后端的持久文件系统

ts 复制代码

import { DurableObject } from "cloudflare:workers";
import { getWorkspace, withWorkspace } from "@cloudflare/computer";

export class Agent extends withWorkspace(
  class extends DurableObject<Env> {},
  (self) => ({ storage: self.ctx.storage }),
) {}

export default {
  async fetch(_request: Request, env: Env): Promise<Response> {
    const id = env.Agent.idFromName("user-123");
    using ws = await getWorkspace(env.Agent.get(id));

    await ws.fs.writeFile("/notes.md", "- [ ] ship it\n");
    const notes = await ws.fs.readFile("/notes.md", "utf8");
    return new Response(notes);
  },
} satisfies ExportedHandler<Env>;

wrangler.jsonc 至少需要 Node 兼容标志、Durable Object binding 和 SQLite migration：

jsonc 复制代码

{
  "compatibility_flags": ["nodejs_compat"],
  "durable_objects": {
    "bindings": [{ "name": "Agent", "class_name": "Agent" }]
  },
  "migrations": [
    { "tag": "v1", "new_sqlite_classes": ["Agent"] }
  ]
}

3. 增加不依赖容器的 Worker Shell

ts 复制代码

import { WorkerShellBackend } from "@cloudflare/computer/backends/worker-shell";

export class Agent extends withWorkspace(
  class extends DurableObject<Env> {},
  (self) => ({
    storage: self.ctx.storage,
    backends: [
      new WorkerShellBackend({
        loader: self.env.LOADER,
        workspace: {
          binding: "Agent",
          id: self.ctx.id.toString(),
        },
        ctx: self.ctx,
      }),
    ],
  }),
) {}

同时补充 Worker Loader 和实验标志：

jsonc 复制代码

{
  "compatibility_flags": ["nodejs_compat", "experimental"],
  "worker_loaders": [{ "binding": "LOADER" }]
}

此后，同一份文件可直接被命令读取：

ts 复制代码

await ws.fs.writeFile("/hello.txt", "world");
using run = await ws.runtime.exec("cat /hello.txt");
const { stdout, exitCode } = await run.result();

4. 试点时的四条底线

先用 Worker Shell 做文本和 Git 任务，只有需要原生二进制时才启用 Container；
每个 Workspace 保持一个活动写者，或按 Agent 划分互不重叠的目录；
对 node_modules、.next、target、dist 等派生目录设置完整 ignore，避免同步数万小文件；自定义 ignore 会替换默认值，而不是追加；
对外暴露 runtime.exec() 前，必须在应用层限制可选 backend、网络、密钥和资源，不要把 backend 名称当授权。

📊 增长速度与社区热度

增长速度评估

项目从 2026-06-05 创建到 2026-08-06 快照约 61.6 天 ，累计 3,913 Stars，生命周期平均约 63.6 Stars/天。这是一个用于观察早期传播强度的粗基线，不是"今日增星"：新项目受发布事件和品牌流量影响很大，生命周期均值不能代表稳定增长率。

Fork / Star 比约 4.7%。对一个仅两个月、且官方不接收未经邀请 PR 的预览项目而言，184 Forks 仍显示出较强的实验意愿；但贡献入口被主动限制为 Issue 与 Discussion，不能用 PR 数低直接推断社区不活跃。

社区结构

指标	数据	解读
Stars	3,913	两个月内达到 3.9K，早期关注度高
Forks	184	Fork / Star 约 4.7%
开放 Issue	约 20	API 返回 24 个开放事项，扣除 4 个开放 PR
开放 PR	4	官方仅接受获邀协作者 PR，外部协作模式较封闭
可见贡献者	6	API 返回的贡献者中，`aron-cf` 为 568 次贡献，核心维护高度集中
Tags	17	从 `v0.0.0-alpha.0` 到 `v0.1.1`，迭代密集
GitHub Releases	0	有 Tag 和 npm 包，但未使用 GitHub Releases 页面发布说明
测试实测	933 项通过	核心包不是概念 Demo，但平台端到端生产可靠性仍需独立验证

前六名贡献者记录合计 590 次贡献，其中第一贡献者占约 96.3%。这意味着项目推进速度快、架构一致性强，但 bus factor 偏低；再结合 API 尚不稳定，外部团队采用时应锁版本并准备迁移成本。

排名	仓库	排名	仓库
1	`cloudflare/computer`	8	`obra/superpowers`
2	`huangruiteng/loopx`	9	`roboflow/supervision`
3	`TencentCloud/TencentDB-Agent-Memory`	10	`vercel/next.js`
4	`donnemartin/system-design-primer`	11	`tailwindlabs/tailwindcss`
5	`firecrawl/pdf-inspector`	12	`uber/ADR`
6	`esengine/DeepSeek-Reasonix`	13	`lyogavin/airllm`
7	`addyosmani/agent-skills`	---	---

榜单里还有成熟框架、Agent Skills 集合、记忆平台和 PDF 工具。本文选择 Cloudflare Computer，不只是因为它排名第一，而是因为它把"Agent 有工具"推进到了"Agent 有可持久、可执行、可迁移的工作空间"，同时包含 VFS、内容寻址同步、FUSE、RPC 和多运行时路由等更具系统深度的问题。

🎯 适用场景

场景	适配度	原因与建议
云端代码 Agent 的个人工作目录	高	计划、代码、中间产物可跨 DO 重启保留；保持单写者
文档、报告、图片等产物生成	高	Worker Shell 做轻处理，容器运行 `pandoc` 等工具，再经 Assets/Artifacts 输出
短生命周期自动化任务	高	可按成本与能力选择三种后端，不必所有任务都启动容器
带 Git 的小型仓库修改	中高	Git 可直接操作 VFS；大型 monorepo 与完整依赖安装需要评估性能
多 Agent 分工协作	中	每个 Agent 使用独立子目录或显式交接可行；共享文件并发写存在覆盖风险
多租户在线代码执行平台	中低	还需自行构建身份、能力授权、网络与资源隔离；官方也未声明生产就绪
大数据集、模型权重、视频处理	低	大文件顺序 I/O 明显慢，容器侧文件树还占内存
高频共享状态或数据库替代品	低	没有事务化的跨 Agent 文件协作、冲突检测或 CRDT

⚠️ 采用前必须看清的边界

预览版不是一句免责声明。 API、Wire shape 和包版本都可能变化，DO 与 computerd 没有协议版本协商，需要匹配版本锁步部署。
容器镜像不是持久真相。 当前 computerd 使用进程生命周期数据库；容器重启后依赖 DO 重新基线同步。
删除日志可能持续增长。 vfs_changes 的自动清理仍是规划项，删除密集型长期 Workspace 要监控 SQLite 体积。
忽略目录在 DO 侧完全不可见。 ignored 文件仍存在于容器并可被命令使用，但 workspace.fs 的 readdir、stat 和 readFile 看不到它们。
目录 rename 的同步成本是 O(子树)。 本地 inode move 很便宜，但 wire 没有 rename opcode，需要为新旧路径生成状态与 tombstone。
公共贡献并非自由 PR 模式。 官方要求外部先提交 Issue 或 Discussion，未经邀请的 PR 可能被关闭。

💡 总结

Cloudflare Computer 最值得关注的，不是"Agent 可以执行 Shell"，而是它把文件的持久性从临时沙箱中抽离出来：SQLite VFS 保存权威状态，内容寻址分块负责增量同步，容器、Worker Shell 和 JavaScript 隔离环境变成按任务选择的计算层。这套分层让 Agent 工作空间更容易跨重启保留、按用户隔离并连接产物发布链路。

它也没有魔法消除系统代价：容器同步牺牲了大文件吞吐，多写者仍是 last-write-wins，权限治理需要应用自己完成，部分设计文档仍领先于实现。现阶段最合适的定位是值得做技术验证的 Agent Workspace 基础组件，而不是开箱即用的生产沙箱。若你的 Agent 主要处理小型代码仓库、文档和可恢复中间产物，它值得进入 PoC；若核心负载是大文件、多人并发写或强隔离执行，则应等待架构继续成熟。

每天一个开源项目#61 3.9K Stars：Cloudflare 给 Agent 一台持久云电脑