给你的 AI Agent 一台“电脑“:Cloudflare Computer 深度解读！-酒店常州论坛

给你的 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 项目中安装核心包:

npminstall@cloudflare/computer

2. 基本用法示例

官方博客给出了一个典型场景:在一个基于@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 官方介绍

企业官网建设流程全解析