Cloudflare 给每个 AI Agent 配一台“虚拟电脑”，到底能干什么？
Cloudflare 发布的 @cloudflare/computer，为 AI Agent 提供持久化文件系统、命令执行、Git、R2 挂载和 AI SDK 工具。它目前还是 Preview，不是开箱即用的生产云电脑。
Cloudflare 最近发布了 @cloudflare/computer。很多人把它概括成一句话：给每个 AI Agent 配一台“虚拟电脑”。
这个说法很形象，但容易让人误以为它提供了一台带桌面、完整磁盘和长期运行进程的云主机。按官方 npm README 的描述，它更像是给 Agent 配了一套持久化工作空间：有文件系统，可以执行命令，可以接 Git，也可以根据需要挂上不同的运行后端。
而且目前版本是 Preview Only。官方明确提醒，API 还不稳定，适合实验、探索和原型，不适合直接用于生产环境。
它到底提供了什么
@cloudflare/computer 的核心对象是一个 Workspace 。这个工作空间可以绑定到 Cloudflare Durable Object，文件写入 Durable Object 自己的 SQLite 存储，因此即使 Durable Object 重启，文件仍然可以保留。
一个 Agent 可以拥有自己的工作空间，用来保存：
- 当前任务的文件。
- 对话过程中生成的笔记。
- 代码仓库和修改结果。
- 工具执行产生的中间文件。
- 需要在多次调用之间继续使用的上下文资料。
最小用法不是先开一台服务器，而是先得到一个持久化文件系统：
import { withWorkspace, getWorkspace } from "@cloudflare/computer";
import { DurableObject } from "cloudflare:workers";
export class Agent extends withWorkspace(
class extends DurableObject<Env> {},
(self) => ({ storage: self.ctx.storage }),
) {}
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");
这段代码的重点是 ws.fs。它提供了类似 node:fs/promises 的异步文件操作，例如读写文件、创建目录、列出目录、删除文件和搜索内容。
Agent 可以在里面执行什么
只有文件系统还不够，Agent 通常还需要运行命令、安装依赖、执行测试或处理数据。 Cloudflare Computer 把执行能力设计成可插拔后端。
官方 npm README 列出了三种后端：
Container
在完整 Linux 用户空间里运行 shell 命令，可以使用真实的二进制程序、npm、node 和网络。它需要 Cloudflare Container 运行 computerd。
这个后端最接近大家想象中的“虚拟电脑”，但冷启动更慢，资源和运行成本也需要单独考虑。
Worker Shell
在 Dynamic Worker 中通过 just-bash 运行 shell 命令，不需要容器，启动更快。它适合文本处理、简单脚本和不依赖完整 Linux 用户空间的任务。
Worker JavaScript
在新的 Dynamic Worker 中运行 ECMAScript 模块，提供结构化输入输出，以及由 Workspace 支持的文件访问能力。它适合把代码任务限制在 JavaScript 运行环境里。
三个后端可以同时注册到同一个 Workspace，再按照任务类型选择使用哪个后端。这比给每个 Agent 固定一套运行环境更灵活。
为什么要把文件和执行环境分开
一个 AI Agent 的任务可能先要读取文件，再修改文件，然后运行测试，最后把结果发布出去。
如果文件放在某个短生命周期的执行容器里，容器结束后，任务上下文也可能消失。 Cloudflare Computer 把 Workspace 文件系统和执行后端连接起来：文件负责持久化，后端负责执行。
这带来几个好处：
- Worker Shell 可以快速处理轻量任务。
- Container 可以处理需要完整 Linux 工具链的任务。
- 同一批文件可以被不同后端使用。
- Agent 重启后还能继续访问自己的工作目录。
代价是系统更复杂了。容器端还有一套内存中的文件系统，Cloudflare Computer 需要通过 FUSE 和 WebSocket 等机制同步两边的数据。官方 README 特别提醒，大量 I/O 、安装很大的 node_modules 或解压大型压缩包时，速度可能不如原生磁盘。
它给 Agent 准备了哪些工具
官方还提供了 @cloudflare/computer/tools，可以把 Workspace 能力包装成 AI SDK 工具，交给 generateText、streamText 或其他 Agent 框架使用。
默认工具包括：
read：读取文件。write：写入文件。edit：修改文件。ls：查看目录。exec：执行命令，配置后启用。publish：把文件发布出去，配置后启用。
这样，模型不需要知道底层每个 API 的细节。开发者把工具集交给 Agent，再通过说明告诉模型什么时候使用 Worker Shell，什么时候使用 Container 。
Git 也被放进了工作空间
Cloudflare Computer 提供了可选的 Git 客户端，底层使用 isomorphic-git，直接操作本地 SQLite 文件系统，不必依赖 shell 或执行后端。
它可以让 Agent 在自己的工作区里完成：
- 克隆代码仓库。
- 修改文件。
- 暂存变更。
- 创建提交。
- 继续读取之前的工作结果。
这对代码 Agent 很重要。 Agent 不再只返回一段回答，而是可以留下一个能继续修改、检查和发布的工作目录。
当然，Git 操作能留下版本记录，不代表 Agent 的修改一定正确。测试、代码审查、权限控制和合并策略仍然需要人来负责。
R2 挂载和文件发布
官方 README 还提供了两类文件外送方式。
第一类是 R2 只读挂载。可以把 R2 桶的一部分内容挂到 Workspace 的某个目录下，Agent 能读取这些文件，但不能直接修改挂载内容。
第二类是 Assets 和 Artifacts 。它们可以把工作空间中的文件上传到 R2，或者放进 Cloudflare Artifacts，供外部流程继续使用。
这让 Agent 的工作过程可以变成一条链：读取资料，生成文件，运行检查，再把结果作为可访问的产物交给下一个步骤。
它和传统云电脑有什么区别
传统云电脑通常强调一台长期存在的远程机器，用户可以远程登录，安装软件，运行桌面或常驻进程。
Cloudflare Computer 更偏向 Agent 工作空间：
- 它围绕 Durable Object 和 Workspace 组织数据。
- 文件系统是核心，执行后端可以替换。
- 不同后端有不同能力和限制。
- 它面向程序化调用，不是给人远程操作桌面的产品。
- 容器后端需要额外部署
computerd，不是所有场景都自动拥有完整 Linux 。
所以，“虚拟电脑”适合作为传播说法，技术上更准确的叫法是**：给 AI Agent 提供持久化文件、可选执行环境和工具接口的工作空间。**
对开发者有什么用
代码 Agent
Agent 可以拥有自己的代码目录，读取仓库、修改文件、运行测试，再把修改结果提交到 Git 。每个用户或任务可以对应一个独立的 Durable Object 工作空间。
研究 Agent
研究 Agent 可以保存检索资料、摘要、表格和中间结果。下一次调用时，不需要重新从零开始建立所有上下文。
数据处理 Agent
Agent 可以把上传文件保存到工作区，运行脚本进行清洗，生成报告，再把结果发布成文件或资源链接。
多步骤业务流程
一个 Agent 负责收集资料，另一个 Agent 负责处理，第三个 Agent 负责检查。它们可以共享受控的文件工作区，但执行能力按任务分别配置。
目前的限制
还是 Preview
官方明确标注 Preview Only 。 API 会变化，示例和配置也可能调整。不要把当前版本直接当成稳定的生产基础设施。
存储不是无限的
README 给出的工作空间上限大约是 10GB，而且与 Durable Object 存储共享。它适合 Agent 级别的工作目录，不适合保存完整大型 monorepo 、海量数据集或长时间积累的构建缓存。
容器文件系统在内存中
容器端文件系统由内存承载，并通过 FUSE 访问。大量 I/O 、依赖安装和大型文件处理可能更慢，也会带来内存压力。
不同后端不能混为一谈
Worker Shell 没有完整 Linux 用户空间，Worker JavaScript 也不是任意 Node.js 程序都能直接运行。需要完整二进制和网络能力时，才考虑 Container 后端。
仍然需要 Cloudflare 配置
Worker 需要 nodejs_compat 兼容标志。 Worker Shell 和 Worker JavaScript 还需要 experimental 标志和 Worker Loader binding 。 Durable Object 、 SQLite migration 、 Container 或 R2 等能力也各有配置要求。
安全边界要提前设置
给 Agent 一个能读写文件和执行命令的工作空间，能力很强，也意味着权限边界必须先设计好。
至少要考虑：
- Agent 能读取哪些目录。
- 哪些文件只能读，不能写。
- Container 能不能访问网络。
- 是否允许执行
npm install、 Git 操作和外部脚本。 - API Key 、用户上传文件和生成结果如何隔离。
- 是否需要对命令、文件和发布动作做审计。
“每个 Agent 一台虚拟电脑”真正有价值的前提，是每台虚拟电脑都有清晰的账户、文件、网络和执行边界。否则只是把一个权限过大的自动化程序放进了云端。
一句话总结
@cloudflare/computer 不是传统意义上的云桌面，而是 Cloudflare 为 AI Agent 准备的持久化工作空间。
它把文件系统、命令执行、 Git 、 R2 文件和 AI SDK 工具放到一起，让 Agent 能够保存上下文、处理文件、运行任务并留下结果。
目前它还是 Preview，适合做实验和原型。对开发者来说，它展示了一个方向：未来的 AI Agent 可能不再只是调用几个函数，而是拥有自己的文件、工具、运行环境和可持续的工作状态。