Cloudflare 给 Agent 发"电脑"了：@cloudflare/computer

你的 Agent 需要的是一台电脑，而不是一个容器

2026 年 8 月 3 日，Cloudflare 正式发布了 @cloudflare/computer 的早期预览版[reference:0]。这个开源包为 Agent 提供了一个运行时，让每个 Agent 都拥有"自己的电脑"——一个由 SQLite 支撑的持久虚拟文件系统，加上可按任务调度的 Isolate 与容器两种执行后端[reference:1]。

官方博客的标题直接点明了立场：「Your agent needs a computer, not a container」[reference:2]。最强大的 Agent 有一个共同点：它们被赋予了自己的电脑来工作——文件系统、Shell、工具、包、运行代码的能力[reference:3]。电脑给模型提供了一种熟悉的方式来对世界采取行动[reference:4]。

过去六个月的变化：从"每个 Agent 一个容器"到"脑手分离"

今年年初，启动一个容器并在其中运行 Agent 是常态[reference:5]。但最近半年，主流 Agent 框架已迅速转向通过工具提供沙箱化代码执行[reference:6]。这把手（执行工作的沙箱）和脑（Agent 循环）分开了[reference:7]。

无论框架在哪里运行，给每个 Agent 一个容器都面临一个挑战——全世界的云服务商、所有超大规模数据中心加起来，也没有足够的算力让每家公司给每个用户的 Agent 都配一个容器化计算环境[reference:8]。这无法扩展到数亿、数十亿的并发 Agent。这正是业界对 CPU 算力（不仅仅是 GPU）存在恐慌性需求的原因[reference:9]。

Cloudflare 在这个问题上已经耕耘了很久，创造了一个更高效的计算原语：Isolate[reference:10]。十年前引入 Cloudflare Workers 时做出了这个反共识的押注[reference:11]，六年前引入 Durable Objects 时又做了一次[reference:12]。Isolate 可以无限水平扩展，启动和销毁极快，Agent 空闲时可以休眠，存储 Agent 自己的状态，甚至启动自己的 Isolate 来运行不受信任的代码[reference:13]。

去年，Cloudflare 让 Isolate 具备了按需拉起容器沙箱的能力[reference:14]。从第一天起，Cloudflare 的架构就被设计为在 Isolate（Durable Object）中运行 Agent 框架，并按需调用附带的容器作为工具[reference:15]。这让你只在需要时才使用更重的计算原语，优化性能和成本[reference:16]。Durable Objects 无限水平扩展，附带的容器让它垂直扩展以执行任何任务[reference:17]。

但面对构建 Agent 所需的多种底层计算原语（Isolate 和容器），以及客户和开发者在用户空间自行组合它们的需求，Cloudflare 认为可以提供更简单的抽象[reference:18]。这就是 @cloudflare/computer 诞生的原因。

核心设计：一个文件系统，两种算力

@cloudflare/computer 的核心是 Workspace——一个由 SQLite 支撑的虚拟文件系统，实例化在 Durable Object 上[reference:19]。Durable Object 重启后文件仍然保留[reference:20]。Workspace 可以从云存储、Git 仓库或任意文件预填内容[reference:21]。

关键的设计不是"又多了一个沙箱"，而是把状态与算力解耦：文件只有一个权威副本（Durable Object 里的 SQLite），但提供了可插拔的执行后端[reference:22]。官方内置了三种后端[reference:23]：

• 容器后端（Container）：将 SQLite 状态投射到沙箱容器中作为真正的 FUSE 挂载[reference:24]。容器内的守护进程 computerd 将状态挂载为文件系统，并通过 capnweb RPC 将改动同步回来[reference:25]。提供完整的 Linux 用户态、真正的二进制文件和真实的网络[reference:26]。
• Isolate Shell 后端：使用 just-bash 将 Shell 代码翻译成 JavaScript，在 Dynamic Worker 中运行[reference:27]。文件系统通过 Workers RPC 直接访问权威 Workspace，没有第二份存储或同步往返开销[reference:28]。
• Isolate JavaScript 后端：在全新的 Dynamic Worker 中运行 ECMAScript 模块，支持结构化输入/输出、持久化相对导入、配置好的库、Workspace 支持的 node:fs/promises 以及 ws:git 和 ws:artifacts 模块[reference:29]。

一个 Workspace 可以注册多个后端，通过稳定 ID 标识[reference:30]。workspace.runtime.exec(source, { backend }) 是唯一的执行入口[reference:31]。后端在首次使用时惰性连接[reference:32]。Workspace 也可以不构造任何后端，仅提供文件系统本身[reference:33]。

对模型一侧，官方提供兼容 AI SDK 的工具包，内置 read、write、edit、ls 和 exec 五个工具[reference:34]。exec 工具比较特殊，它跨运行时工作，接受 backend 参数。工具描述本身就在引导 Agent 按任务选择合适的运行时：要么是快速、便宜的 Worker 后端，要么是全功能的容器。在官方测试中，前沿模型非常擅长做出正确决策，只在需要时才回退到容器[reference:35]。

如何使用

安装方式非常简单：

npm install @cloudflare/computer

官方示例展示了一个 bug 分诊 Agent[reference:36]：先把报告写入 /workspace/BUG_REPORT.md，再把仓库 clone 到 /workspace/repo，然后让模型在这个预置好的环境里复现、修复、验证[reference:37]。

Workspace 类提供了直接操作文件系统的 API 接口，以及 node:fs 兼容包装，方便接入第三方 JavaScript 库[reference:38]。

GitHub 仓库中提供了多个可运行的示例[reference:39]：

• container：在容器内运行 computerd，挂载 Workspace，通过 capnweb 与 Durable Object 通信[reference:40]
• worker-shell：在 Dynamic Worker 中运行 just-bash，无容器[reference:41]
• worker-javascript：在 Dynamic Worker 中执行 ECMAScript 模块[reference:42]
• think：与 @cloudflare/think 集成的聊天 Agent[reference:43]

还有一个分步教程，从零开始构建一个 PDF 菜谱卡片 Agent——用户提交一道菜名，Agent 在 openstove.org 上找到匹配的菜谱，写入 Markdown 菜谱卡片，用 pandoc 转换为 PDF，最后返回下载链接[reference:44]。整个过程写操作在主机（Durable Object）上完成，容器通过 FUSE 挂载看到同一文件系统，pandoc 像操作普通文件一样读取和写入[reference:45]。

已确认和还不能确认的

已确认的边界：发布事实、安装方式、MIT 许可证、三种后端架构都能在官方页面和仓库里直接核验[reference:46]；npm 包真实存在、可安装；官方文档明确标注这是预览版、API 不稳定、不适合生产使用[reference:47]；文件操作在 Durable Object 重启后的持久性写在仓库文档里[reference:48]。

还不能确认的同样重要："容器只应占 Agent 工作量的 10% 以下"是官方目标[reference:49]，不是第三方实测数据；"前沿模型很擅长为任务选择正确后端、只在需要时才回退到容器"来自官方自己的测试[reference:50]，没有公开数据集支撑；Isolate 后端在真实代码任务上的成功率、容器后端的冷启动时间和计费曲线，目前都没有独立数据；GA 时间与正式定价均未公布。

对一个真实工作流的影响

如果你在做编程类 Agent 产品，常见形态是每个用户会话挂一个容器：能力完整，但成本与冷启动压不下去。官方博客也直言，世界上没有足够的算力让每家公司给每个用户的 Agent 都配一台容器[reference:51]。@cloudflare/computer 的替代路径是默认在 Isolate 里干活，只有真正需要 Linux 的任务才进容器。如果官方的调度目标兑现，容器成本占比有望出现数量级下降。

代价是平台锁定。Workspace 依赖 Durable Objects，内置后端分别依赖 Dynamic Workers 与 Cloudflare Containers，整套方案离开 Cloudflare 平台不可用。已经在 AWS 或自建 Kubernetes 上跑 Agent 沙箱的团队，它更像一个值得对照的架构参照，而不是今天的迁移目标。

还有一个值得注意的信号：Cloudflare 内部已经在用这种方式构建自己的 Agent——用 Isolate 构建、测试和部署 JavaScript 应用、为每个客户生成定制文档、操作浏览器完成复杂任务[reference:52]。厂商自己吃螃蟹不等于方案成熟，但至少说明这不是一个只为发布会存在的演示项目。对国内读者的另一个现实意义是：Cloudflare 的可用区与网络条件在国内有客观限制，评估时应把网络延迟计入成本对比。

今天该怎么做

1. 在一个测试用 Workers 项目里 npm install @cloudflare/computer，按仓库教程跑一遍最小 Agent，确认文件持久化和三种后端的实际行为。
2. 从自己的业务里挑 10-20 个真实任务（而不是官方示例），对比 Isolate 后端与现有容器方案的完成率、延迟和成本。
3. 如果你所在团队对数据驻留和审计有要求，把门控与审计能力单独做一次评估，再决定它能进入哪一级环境。
4. 生产环境今天什么都不动：预览版 API 明确不稳定[reference:53]，任何架构切换决策等 API 稳定、计费明朗之后再做。