企业官网建设流程全解析

Cloudflare Computer：如何给你的 AI Agent 一块持久工作区与真实执行环境

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

Cloudflare Computer 是 Cloudflare 开源的 Agent 云计算机：SQLite 虚拟文件系统装在 Durable Object 里，文件操作跨重启存活，再按需挂上容器或 Worker 执行后端，就能跑真实的 Linux 命令。

先做个小实验：让 Agent 读一份日志、改一段配置，然后关掉终端再重开。多数实现里，上一轮写下的中间产物、聊天记录、生成代码全部归零——模型再聪明，"记忆"也只活在一次会话里。问题不在模型，而在它缺两块"硬件"：一块能存住中间状态的硬盘，一双能碰真实二进制（git、npm、pandoc）的手。纯文本替换干不了需要执行的活，本地 fs 跟着进程生灭，自建容器要么丢状态、要么要自己写同步。Cloudflare Computer 就是冲着这两块硬件来的，而且把两者装进了同一个对象里。

它把硬盘搬进了 Durable Object

Durable Object 是 Cloudflare 的持久化服务端运行时，可以理解为一个永不掉线、状态自动落盘的服务端实例。Workspace 就住在这种实例里：文件系统状态以 SQLite 为唯一数据源，writeFile、mkdir、grep全部对它做持久化，DO 重启后原样还在。你在 DO 里构造时指定存储与要挂的后端：

new Workspace({ storage: ctx.storage, backends: [ new CloudflareContainerBackend({ workspace: { binding: "Agent", id: ctx.id.toString() }, }), ], });

之后 Workspace 露出两张脸：workspace.fs是接近 Nodefs/promises的异步文件 API（绝对路径、流式读写、全局 grep）；workspace.runtime是唯一执行入口，按 backend 参数把同一条exec()路由到不同运行时。也可以不挂任何后端，这时它退化成一块纯持久硬盘，只读不跑命令。

一条命令的一生：push、执行、pull 的闭环

容器后端的同步机制是这套系统里最有含金量的部分。容器内跑着一个 packages/computerd/ 里的守护进程computerd，它借 FUSE——Linux 允许用户态程序挂载虚拟文件系统的机制——把 DO 侧状态投影成真实的/workspace挂载点。

一次exec被包在同步括号里。push 阶段，DO 把容器还没见过的修订（revision）流过去，同一路径的多次改动合并成一条，文件按 512 KiB 分块并以 sha256 做内容寻址，双方像 git 协商一样只传缺失的块。命令在挂载点里执行，FUSE 捕获的每次写入都打上容器侧修订号。命令结束后 DO 按游标拉回变更，批大小 256 条，中途崩溃最多重放一批，apply 幂等，所以重试是安全的。整条通道走 capnweb 二进制 RPC，DO 与容器按匹配版本成对部署。

Worker Shell 后端则压根没有第二个存储：just-bash 跑在 Dynamic Worker（按需冷启动的隔离执行环境，业内常称 Isolate）里，通过 Workers RPC 直接读权威 SQLite，零同步开销。

await workspace.runtime.exec("grep -R TODO .", { backend: "worker-shell" }); await workspace.runtime.exec("npm test", { backend: "container" });

exec还返回一个事件 ReadableStream，转成 SSE 帧推给浏览器，就是天然的终端直播。

动手：在终端里和带硬盘的 Agent 说上话

仓库自带一组可直接跑的 Worker 示例，我们一般建议从 examples/think 起步：一个聊天 Agent，同时挂着快速 Worker Shell 与完整容器两个后端，工具直接来自@cloudflare/computer/tools的createAITools()——read、write、edit、ls、find、grep、delete 自动就位，exec 与 publish（把产物发布成可分享链接）按需开启，自带分页、字节上限和原子化的 diff 返回。

本地起它需要 Docker（wrangler 要构建容器镜像）：

git clone https://gitcode.com/GitHub_Trending/computer1/computer cd computer && npm install cd examples/think && npm run dev # 终端 1：wrangler dev # 终端 2 再进一次 shell： cd examples/think && npm run chat # AI SDK 终端聊天 UI

发消息后，Agent 会自己决定调 read、write 还是 exec 在云端工作区里干活。每个--name对应一个独立实例：自己的工作区、自己的聊天历史。

给命令选跑道：三种后端怎么对号入座

同一个workspace.runtime.exec()，三种解释方式，冷启动速度与天花板各不相同：

think 示例的 system prompt 就编码了这条决策路径：先 read/ls 而不是exec cat，先试 shell 后端，干不了再落容器。网络出口是另一根缰绳：默认none完全断网，all直连公网，custom走 http-gateway 白名单——examples/egress 把同一个 URL 打到三条后端，让你直观看到三种策略的差异。

边界在哪：元数据快、大文件慢，还有几条红线 ⚠️

官方基准跑在 standard-2 实例（1 vCPU / 6 GiB / 12 GB 磁盘）上，对照系是 tmpfs 与容器内 ext4 根盘，对象是一次含 854 个包、36,675 个文件的完整npm install。结论分得很干净：

• 元数据密集的场景，内存 inode 表让它快过真实 ext4：stat1000 个文件 0.91x、rm0.66x、建 10×10×10 目录树 0.74x、find0.72x、git init + commit0.72x
• 大文件顺序 I/O 是短板，64 MiB 写盘约为 ext4 的 17 倍耗时、纯读约 30 倍——每个 512 KiB 块在释放时都要哈希进内容寻址存储，这是 DO 侧"只同步脏块"必须付的账
• 完整npm install耗时 124.7s，约为 ext4（63.9s）的 2 倍、tmpfs（34.3s）的 3.6 倍

所以它想装的是 Agent 的工作台，而不是整个 monorepo。几条红线要记牢：总容量约 10 GB（与 DO 共享存储）；容器侧文件树常驻内存，巨型目录树撑不住；项目处于 PREVIEW 阶段，API 不稳定，适合实验与原型，不建议直接上生产。另外它没有合并语义——两个写者碰同一文件时最后写入者获胜，多 Agent 共享工作区要么划分目录、要么靠显式workspace.pull()交接。

往哪走：仓库地图与示例清单

monorepo 很小，四个包各司其职。packages/computer/ 是 DO 侧门面：Workspace、fs/runtime 表面、AI 工具，另有/backends/*、/git、/tools等子路径入口，且用了容器后端就不会把 just-bash 那棵树拉进 bundle。packages/dofs 是 SQLite 虚拟文件系统本体与同步协议构件，packages/computerd 是容器内 FUSE 守护进程，packages/rpc 是 DO 与容器共享的 capnweb 线协议类型。

docs/ 下 19 篇设计文档是最好的第二入口，同步协议那篇连"为什么不设计一个 rename opcode"都写清楚了。想横向对比运行时，跑examples/think-compare-runtimes，让同一任务在容器与 Worker 上并排赛跑；想让 Agent 写 Markdown 再在容器里用pandoc出 PDF，看examples/tutorial；MCP 协议接入看examples/mcp。

如果你现在要给 Agent 配一块存得住中间产物、跑得动真实命令的云硬盘，下一步就是 clone 下来把examples/think跑起来，再按自己的负载把backends数组换成你需要的形状。

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