给你的 AI Agent 一台电脑:Cloudflare Computer 深度解读项目地址:https://github.com/cloudflare/computer一、它解决了什么问题?如果你搭建过 AI Agent(智能体),大概率会遇到这样的困境:Agent 要写代码、跑测试、生成文件,就得给它一个能落地的环境——一个文件系统、一个可以执行命令的沙箱。市面上常见的做法是直接甩给它一个容器(Container):启动一个 Docker 实例,挂个卷,让 Agent 在里面为所欲为。但这套方案有几个绕不开的痛点:成本高、启动慢:每个会话都要拉起一个完整的容器,冷启动动辄几秒甚至更久,资源开销也不小。状态难持久化:容器一旦销毁,里面的文件往往也就没了,想让 Agent 记住上次的工作成果并不容易。“杀鸡用牛刀”:很多任务其实只是读写几个文件、跑一段简单脚本,根本用不上一个完整的 Linux 环境,但因为没有更轻量的选择,只能捆绑一个重型容器。Cloudflare 的思路很直接:Agent 真正需要的不是一个容器,而是一台电脑——一套持久化的文件系统,外加一个可以按需切换的执行单元。容器只是这台电脑众多可能的CPU之一,而不是必需品。二、Cloudflare Computer 是什么?Cloudflare Computer 是一个存在于 Durable Object 内部的虚拟文件系统。Durable Object 用 SQLite 保存权威状态,并通过 workspace.runtime 暴露一个可插拔的执行接口。简单翻译一下就是:文件系统是主角,它是持久化的、以 SQLite 为底座的,不依赖某个具体的运行环境而存在。执行方式是插件,你可以按任务需要挑选不同的后端来跑代码,而不用每次都拖出一整个容器。目前官方提供了三种执行后端:Container(容器后端)把 SQLite 状态投影进沙箱容器,形成一个真正的 FUSE 挂载。容器内的守护进程 computerd 挂载这份状态作为文件系统,并通过 capnweb RPC 通道把变更同步回去,拥有完整的 Linux 用户态、真实的二进制程序和网络访问能力。适合需要跑 pandoc、编译工具链这类重活的场景。Isolate Shell(隔离 Shell 后端)在 Dynamic Worker 中运行 just-bash,通过 Workers RPC 直接访问权威的 Workspace,不需要额外的存储或同步环节。没有容器,启动更快,适合轻量的 shell 操作。Isolate JavaScript(隔离 JS 后端)在全新的 Dynamic Worker 中运行一个 ECMAScript 模块,支持结构化的输入输出、持久化的相对路径导入、预配置的库、基于 Workspace 的 node:fs/promises,以及受信任的 ws:git 和 ws:artifacts 模块。适合纯逻辑计算类任务。一个 Workspace 可以同时注册多个后端,workspace.runtime.exec(source, { backend })是统一的执行入口——用哪个后端跑,由调用者按任务需求决定,后端还会在首次使用时才懒连接,进一步节省资源。值得一提的是,Workspace 甚至可以不挂任何执行后端单独使用,这时它就是一个纯粹的文件系统,给不需要跑代码、只需要读写文件的场景使用。需要注意的是,官方也明确标注了当前状态:这是一个预览版(Preview),API 还不稳定,设计可能随时调整,适合拿来做实验和原型验证,暂不建议用于生产环境。三、怎么用?1. 安装在你的 Worker / Agent 项目中安装核心包:npminstallcloudflare/computer2. 基本用法示例官方博客给出了一个典型场景:在一个基于cloudflare/think构建的 Bug 分诊(triage)Agent 里挂载 Workspace,让它读取 Bug 报告、克隆仓库、定位问题:asyncstartTriage(report:{title:string;body:string;repoUrl:string}){awaitthis.workspace.fs.mkdir(/workspace,{recursive:true});awaitthis.workspace.fs.writeFile(/workspace/BUG_REPORT.md,#${report.title}\n\n${report.body}\n,);awaitthis.workspace.git.clone({url:report.repoUrl,dir:/workspace/repo});// 后续可以调用 workspace.runtime.exec(...) 执行诊断脚本}可以看到,workspace.fs提供了和 Worker 绑定兼容的文件读写接口,而workspace.git、workspace.runtime这些能力都是即插即用的模块。3. 给 Agent 配上现成工具箱如果你不想自己手搓工具,官方还打包了一套开箱即用的 AI SDK 工具:read、write、edit、ls,以及可选的exec(跨后端执行)和publish(发布产物)。也就是说,你可以直接把这些工具丢给一个支持 Tool Use 的模型,让它自主决定何时读文件、何时写文件、何时执行代码。4. 官方 Examples 一览仓库里的examples/目录提供了多个可直接运行的示例,覆盖了不同的使用姿势:examples/container:在容器里跑 computerd,通过 capnweb 和 Durable Object 通信,暴露一个 write / read / exec 的 HTTP 接口。examples/worker-shell:同样的 HTTP 接口,但 Shell 跑在 Dynamic Worker 里的 just-bash 上,完全不需要容器。examples/worker-javascript:和上面类似,但 exec 执行的是一段 ECMAScript 模块。examples/think:一个基于cloudflare/think的对话式 Agent,把 Workspace 当作工作目录,可通过终端交互。examples/tutorial:手把手的入门示例——一个 Agent 在宿主机上写一份 Markdown 菜谱,再到容器里跑 pandoc 把它转成 PDF。examples/artifacts:让 Agent 在 Workspace 里生成一个 Worker 项目,并发布到 Cloudflare Artifacts,产出一个可直接 clone 的仓库。examples/assets:用 Workers AI 把一段 prompt 变成图片,写入 Workspace,再通过cloudflare/computer/assets生成一个可分享的链接。新手建议从examples/tutorial入手,跑通写文件 → 容器里执行 → 产出 PDF的完整链路,能比较直观地理解 Workspace Runtime 这套组合拳是怎么配合工作的。5. 性能怎么样?computerd 的 FUSE 挂载在元数据密集型操作上表现优于真实磁盘,但在大文件顺序 IO 上则会落后于真实磁盘,官方在docs/19_performance.md里给出了详细的fs-bench数据,以及与cloudflare/sandbox-sdk的 npm install 对比,方便你根据自己的场景做取舍。四、总结Cloudflare Computer 的核心思路,是把给 Agent 一个可执行环境这件事拆成了两层:下层是持久化、统一的虚拟文件系统(基于 Durable Object SQLite),不管上层用什么方式执行代码,文件状态始终是同一份、不会因为切换后端或重启而丢失;上层是可插拔的执行后端,轻量任务用 Dynamic Worker 里的隔离 Shell 或 JS 环境,又快又省;重型任务(需要真实 Linux 环境、真实网络、复杂工具链)再切换到容器,按需付费、按需启动。这种文件系统与执行环境解耦的设计,本质上是在回应一个越来越明显的行业趋势:Coding Agent 需要的不是又一个隔离沙箱,而是一台可以持续使用、按需伸缩的虚拟电脑。无论是自主写代码、跑测试,还是生成文档、发布产物,Agent 都能像人一样在这台电脑上过日子,而不是每次任务都从零开始。当然,项目目前仍处于预览阶段,API 还会变动,还不适合直接上生产。但对于想探索Agent 持久化环境这个方向的开发者来说,cloudflare/computer提供了一套非常值得参考的架构思路,也是 Cloudflare 在 Agent 基础设施上的又一次重要落子。参考资料:cloudflare/computer GitHub 仓库 | Cloudflare Blog 官方介绍