Cloudflare Computer 将智能体计算机拆分至 Isolates 和 Containers

Cloudflare 于 2026 年 8 月 3 日以开源预览版形式发布 Cloudflare Computer，为智能体提供横跨三种执行后端的统一持久工作区。争议正存在于这一设计之中。开发者可以将简单任务路由至轻量级 Workers isolates，并将较重任务留给 Linux containers，但该项目明确尚未达到生产就绪状态。

这一区别很重要，因为智能体基础设施一直在向完整、隔离的机器演进。Cloudflare Computer 测试了另一种假设：智能体需要计算机的能力，但并非每项操作都需要相同的计算机运行时。其文件可以独立于每条命令所使用的执行环境而持久保存。

这一结果对那些将 sandbox、container 或 microVM 视为智能体会话基本单元的提供商构成压力。它也要求 Cloudflare 现有的 Sandbox SDK 说明开发者何时真正需要专用 container。这个预览版与其说是完成的产品，不如说是一场关于如何划分智能体计算的公开论证。

Cloudflare Computer 将文件与执行分离

核心变化在于架构：智能体的工作区不再归属于某个正在运行的 container。

根据该项目的开源仓库，Cloudflare Computer 将权威虚拟文件系统存储在 Durable Object 内部。Durable Object 是一种带有私有持久存储和单一协调点的有状态 Cloudflare 组件。

SQLite 保存文件系统状态。执行则通过名为 workspace.runtime 的共享接口在其他位置进行。即使不同后端执行命令，智能体仍可读取和修改同一批文件。

预览版提供三种后端。container 后端提供完整的 Linux 用户空间，包括真实二进制文件、包管理器和网络访问。Worker shell 后端通过 Dynamic Worker 中的 just-bash 运行类 shell 命令。第三种后端则在全新的 Dynamic Workers 内执行 JavaScript 模块。

开发者可以为一个工作区注册多个后端。每个后端都会获得稳定标识符，而 workspace.runtime.exec() 则成为统一入口。调用方可以直接选择后端，或者让智能体框架根据开发者提供的描述作出选择。

这种安排使文件系统成为会话稳定的中心，计算则变得可替换。轻量命令可以在 isolate 中运行，而包安装或原生构建可以转移到 Linux 中进行，无需创建独立的逻辑工作区。

Cloudflare 将该软件包称为具备可插拔执行能力、由 SQLite 支持的持久虚拟文件系统。其软件包文档称，每个工作区的上限约为 10 GB。存储受其 Durable Object 的限制约束。

该软件包也可以在没有任何执行后端的情况下工作。应用可以只使用持久文件系统，并在工作流需要时再添加执行能力。这使存储模型不只是 sandbox 的辅助功能。

公开 API 与熟悉的 Node.js 文件系统操作相似，包括读取、写入、列出、删除和搜索文件的函数。字符串默认使用 UTF-8，而二进制数据可通过字节数组或流传输。

container 访问还需要另一层机制。名为 computerd 的守护进程在 sandbox 内运行，并将持久工作区作为 FUSE 挂载点暴露出来。FUSE 允许用户空间进程通过常规文件系统接口呈现文件。

该守护进程通过 RPC 通道与权威 Durable Object 同步变更。这让 Linux 工具能够使用常规目录，同时将 container 外部的 SQLite 保持为唯一事实来源。

isolate 后端采用更短的路径。它们的文件系统操作会通过 Workers RPC 调用同一个 Durable Object，因此无需维护第二个存储副本，也避免了 container 工作后所需的同步步骤。

这正是该公告不只是又一项代码执行服务的原因。Cloudflare Computer 将熟悉的计算机拆解为持久文件、可选执行、同步和发布辅助功能。智能体仍会看到一个工作区，尽管底层基础设施可以随每条命令变化。

为什么智能体不再适合单一运行时

智能体工作负载将小型文件操作与偶发的系统级任务混合在一起，使固定单一执行环境成为低效的默认选择。

编码智能体很少执行单一、均质的任务。它可能检查配置文件、搜索代码仓库、编辑几行代码、运行测试、安装依赖、创建图像并发布制品。这些操作对运行时有不同要求。

读取文件不需要完整的 Linux container，解析文本或执行受控 JavaScript 模块也是如此。原生编译、包安装和操作系统工具通常则需要。

传统远程 sandboxes 将这些需求打包在一起。sandbox 在同一环境中提供文件系统、shell、进程和网络访问。这个模型易于理解，但它将持久性和执行绑定到同一生命周期。

Cloudflare 早期的 Sandbox SDK 大体遵循这一模型。该公司在 2026 年 4 月 13 日让 Sandboxes 正式可用；九个月前，它首次将其介绍为命令和文件系统环境。

到正式可用时，每个 Sandbox 已成为一个开发环境，具备终端、后台进程、文件监控、实时预览 URL、出站流量控制和快照。Cloudflare 表示，标准账户可运行 15,000 个并发 lite 实例、6,000 个 basic 实例，以及超过 1,000 个更大实例。

该公司还将 Sandboxes 改为按活跃 CPU 计费，因此空闲等待不会消耗付费 CPU 时间。这一变化解决了长时间运行智能体会话的一项成本问题，但并未消除启动 container 与在轻量 isolate 中运行代码之间的架构差异。

Cloudflare Computer 将这种差异转变为路由决策。后端采用惰性连接，也就是说，只有工作首次到达时才会初始化。工作流可以从文件和 isolate 开始，仅在命令确实需要时才调用 Linux。

这一策略呼应了 Cloudflare 更广泛的立场，即智能体工作负载需要多种计算规模。其Agents Week 回顾认为，部分智能体需要完整操作系统，而大多数任务需要可在毫秒级启动的更轻量环境。

Cloudflare Computer 为这一主张提供了具体的编程模型。它不要求开发者在互不关联的服务之间手动移动文件。工作区提供连续性，而执行边界可以改变。

对于框架作者而言，这种连续性很重要。智能体可以获得名为 read、write、edit、ls 和 exec 的标准工具。该软件包为 AI SDK 应用提供适配器，同时由开发者描述每个后端能够处理的任务。

模型随后可以将快速文本操作发送至 isolate，将较重命令发送至 container。这使后端选择成为智能体工具策略的一部分。如果这些描述不够清楚，或模型选择不当，也会产生新的故障模式。

这一设计尤其适合频繁暂停的智能体。模型推理、人工审批、网络请求和外部 API 调用都会造成空闲间隔。在每个间隔期间都让完整环境保持活跃或许方便，但这并非保留智能体工作成果的唯一方法。

持久文件系统让执行层可以消失而不会抹除会话状态。下一步操作可以通过另一个后端重新打开相同文件。从智能体视角看，这很像一台计算机，即使没有任何单一机器拥有完整会话。

这一抽象对以 container 为先的提供商构成压力，但并未消除其最有力的论点。完整的隔离环境提供可预测的工具、熟悉的调试方式和一致的安全边界。将会话拆分到多个运行时会增加协调和同步问题。

它也对 Cloudflare 的产品边界构成压力。开发者必须理解自己需要 Sandbox SDK、Cloudflare Computer、Dynamic Workers，还是它们的组合。预览软件包可以探索重叠领域，但生产平台最终需要给出简单答案。

可能的答案取决于工作负载。Cloudflare Computer 更适合执行大量小型操作、偶尔需要 Linux 的智能体。当几乎每一步都依赖原生工具、大量本地依赖或高吞吐磁盘访问时，container 仍然更清晰。

这才是真正的利害问题。该预览版提出：开发者应配置的基本单元究竟是一台机器，还是一个能够借用不同机器的工作区。

Cloudflare Computer 如何将一个工作区路由至三种后端

Cloudflare Computer 通过显式选择运行时获得灵活性，但每个后端都具有不同的能力和同步特征。

Worker shell 后端是处理熟悉命令的最轻量路径。它使用 just-bash，这是一个 Bash 风格环境的 TypeScript 实现，设计目标是在不启动操作系统进程的情况下运行。

该后端可针对持久工作区处理以文本为中心的 shell 操作，无需 Docker 或 Cloudflare Container。文件操作会返回 Durable Object，从而将权威状态保存在同一位置。

Worker JavaScript 后端处理 ECMAScript 模块，而非 shell 命令。每次执行都在全新的 Dynamic Worker 内进行，并可接受结构化输入或返回结构化结果。它支持由工作区支持的文件访问和已配置的库。

Cloudflare 还为 Git 和 Cloudflare Artifacts 提供受信任模块。Git 操作可通过 isomorphic-git 客户端直接针对虚拟文件系统运行，不需要 container 或常规 Git 二进制文件。

container 后端覆盖 isolates 无法处理的任务。它提供 Linux、原生二进制文件、Node.js、npm、网络及其他操作系统能力。工作区通过 computerd FUSE 挂载点出现在其中。

这一后端带来了最棘手的数据问题。Cloudflare 必须将由 SQLite 支持的状态映射到 container 中，允许常规工具修改它，并在之后同步这些变更。该软件包会为每个已注册后端维护独立的同步游标。

如果命令成功但命令后的拉取失败，执行结果可能会报告待同步状态。应用可以通过有界指数退避配置重试。不过，库并不负责 Durable Object 的 alarm 调度。

这一细节揭示了仍由开发者承担的责任有多少。用户看到的是一个工作区，但应用必须处理后端注册、重试调度、执行生命周期和未解决的同步问题。

该设计还要求严格释放资源。RPC 层不会自动回收远程存根。长时间运行的会话若反复获取工作区或执行句柄，除非应用释放每个句柄，否则这些句柄可能会不断累积。

Cloudflare 记录了用于检测此类泄漏的调试支持。尽管如此，这仍是预览阶段的基础设施，而非无形的平台服务。尝试使用它的开发者需要理解其底层机制。

文件发布引入了另一层边界。该软件包可以将工作区文件上传至 R2，并返回预签名链接。它还可以将会话连接到 Cloudflare Artifacts——一项兼容 Git、用于存储代码和构建产物的服务。

其中一份教程展示了预期的职责划分。智能体会在工作区中编写 Markdown 食谱卡片，然后在容器内使用 pandoc 创建 PDF。存储保持持久化，而 Linux 工具负责格式转换。

另一个示例将图像生成任务发送给 Workers AI，把结果写入工作区，并返回可分享的资产。一个对比界面会并排通过容器和 Worker 运行时执行同一任务。

这些示例指向了一种更广泛的智能体模式：工作区成为共享工作台，不同运行时则像专用工具。智能体无需将每个后端都视为一台独立的计算机。

该机制也可支持知识密集型开发。工程团队可以将任务文件、生成的报告和测试输出保存在工作区中，再将持久化成果复制到一个可搜索的知识库。运行时仍是临时的，但有价值的工作成果可在智能体会话之外访问。

不过，这一抽象存在边界。容器侧文件系统保存在内存中，Cloudflare 建议使用面向智能体规模的工作区，而非完整的 monorepo。约 10 GB 的上限对于文档和小型项目而言相当可观，但并不意味着该服务可以全面替代开发磁盘。

Worker 后端还需要实验性的 Cloudflare 功能和 Worker Loader 绑定。该软件包本身则要求启用 nodejs_compat 兼容性标志。这些要求进一步印证了其预览状态。

这篇 Cloudflare Computer 解读分析中最重要的一点，并不是隔离环境取代了容器。它们没有。该机制让应用程序能够决定：何时值得为容器的启动、能力和同步成本买单。

这种选择可以发生在应用层，也可以通过智能体框架完成。模型能够看到后端描述并选择目标。因此，开发者需要的是策略控制，而不只是自然语言提示。

生产系统很可能会限制每个后端可访问的命令、文件、网络和凭据。它还需要可靠记录，说明某条命令为何被发送到特定运行时。当前仓库提供了可观测性钩子，但尚未解决完整的治理问题。

当工作能够自然拆分时，Cloudflare Computer 最具说服力：在隔离环境中搜索和编辑，在 Linux 中编译，再通过制品服务发布。当每项操作都需要容器，或任务需要反复移动大文件时，其优势就不那么明确了。

预览警告和基准测试让这一主张更复杂

该仓库给出了异常直接的限制说明，包括明确的生产环境警告，以及显示大型顺序文件操作存在显著性能代价的基准测试。

Cloudflare 表示，该软件包适用于实验、探索和原型开发。它表示 API 并不稳定，设计可能发生变化，而且该软件包不适合生产环境使用。

这一警告应当构成所有关于 Cloudflare Computer 当前能力判断的前提。仓库包含可运行的软件包、示例和数百次提交，但其部分设计文档具有前瞻性。Cloudflare 告诉读者，应将这些规范视为设计意图，而非当前代码的描述。

性能是最明确的权衡。该公司在一台标准容器上对 computerd 进行了基准测试，容器配备一个虚拟 CPU、6 GiB 内存和 12 GB 磁盘。它将 FUSE 工作区与内存文件系统及容器的 ext4 磁盘进行了比较。

结果显示，虚拟文件系统在若干元数据密集型操作中更具优势。删除 1,000 个文件所需时间约为 ext4 的三分之二。创建嵌套目录树所需时间约为四分之三，查找该目录树也大致为四分之三。

涉及 100 个文件的 Git 初始化与提交，在 computerd 上耗时 459.2 毫秒，而 ext4 上为 635.4 毫秒。浅克隆一个约 1 MB 的仓库耗时 549.1 毫秒，而磁盘上为 576.2 毫秒。

大型顺序操作则呈现相反结果。写入一个 64 MiB 文件，在 computerd 上耗时 230.6 毫秒，而 ext4 上仅需 16.8 毫秒。复制相同数据量耗时 1,037.2 毫秒，而 ext4 上为 39.8 毫秒。

纯读取 64 MiB 数据的速度约比磁盘基准慢 30 倍。纯复制则慢逾 41 倍。这些差距会影响归档文件、依赖树、媒体、模型文件和数据处理工作负载。

Cloudflare 的文件系统基准测试解释了性能下降背后的机制。写入路径会将 512 KiB 数据块哈希后存入内容寻址的 blob 存储。这样可支持去重和仅同步变更的数据块，但会为原始吞吐量操作增加额外工作。

完整安装 Cloudflare 的 Sandbox SDK 让这一成本更加具体。测试涵盖 854 个软件包和 36,675 个文件。在 FUSE 工作区中，安装耗时 124.7 秒；在 ext4 上为 63.9 秒；在内存中为 34.3 秒。

Cloudflare 将 ext4 描述为更贴近现实的一般用途基准。相较于这一基准，FUSE 安装耗时约为两倍。构建依赖繁重的 JavaScript 项目的开发者会注意到这一差异。

这些基准并未否定该设计。许多智能体任务涉及元数据、小幅编辑、搜索和增量变更，而非持续的顺序 I/O。相反，这些结果界定了后端路由的重要性所在。

合理的工作流可能会将源文件保留在持久化工作区中，同时避免反复解压大型归档文件。它可能会将依赖项缓存在其他位置，或选择价值足以抵消同步开销的任务。Cloudflare 尚未确定最佳生产模式。

安全性带来了第二个不确定性。该仓库描述了执行边界和存储行为，但并未声称三个后端都提供相同的隔离级别。JavaScript 隔离环境、以 TypeScript 实现的 shell，以及 Linux 容器，本质上是不同的执行环境。

Worker shell 获得速度优势，部分原因在于它并非完整操作系统。这限制了兼容性，但也可能缩小命令可执行操作的范围。容器提供更广泛的能力，因此需要围绕网络访问、软件包和凭据实施更强控制。

在这些环境之间切换可能产生策略缺口。一条在某个后端被拒绝的命令，可能会在另一个后端运行。智能体可能因为描述中承诺了更强能力而选择 Linux，即使任务并不需要它。

该软件包包含用于工作区连接、同步、执行和文件系统操作的观察者钩子。这些钩子可以为 Cloudflare 追踪或其他记录器提供数据。它们是有用的基础，但生产用户仍需要授权规则和可审计的后端选择策略。

持久化也带来自身的安全问题。文件会在 Durable Object 重启后保留，这正是智能体处理长任务所需的能力。持久化工作区也可能让敏感提示词、源代码、生成的凭据或下载的数据保留时间超出预期。

应用程序需要与自身风险相匹配的删除策略和租户隔离。只读 R2 挂载有助于保护参考数据，但并不能回答有关数据保留或出站访问的所有问题。

GitHub 的反馈提供的是采用信号，而非生产证据。截至 8 月 6 日，该仓库显示约 3,100 个星标和 141 个 fork。鉴于其在 GitHub Trending 上的位置，这些数字表明公告发布后开发者产生了浓厚兴趣。

但它们并不能证明可靠性、安全性或持续使用情况。围绕引人注目的架构，星标可以迅速累积。真正的验证将来自能够运行数周、从部分失败中恢复，并在运行时变化中持续一致保存文件的工作负载。

Cloudflare 的透明度在这方面有所帮助。公开不利的 I/O 数据，让开发者有了更好的实验依据。明确的警告也避免了人们将热门排名误认为正式可用发布。

谨慎的结论很直接：Cloudflare Computer 提供了一种可信的机制，用于将智能体状态与执行分离，但这一预览版本尚未证明额外的协调成本在生产环境中优于专用沙箱。

GitHub 热度激增后，开发者应关注什么

下一阶段取决于三个信号：API 稳定化、真实工作负载证据，以及可执行的后端选择策略。

第一个信号是面向生产环境的版本化发布。Cloudflare Computer 当前采用不稳定的 API 和实验性的后端要求。若转向稳定接口，将表明 Cloudflare 已解决 Computer、Sandbox SDK、Dynamic Workers 和 Durable Objects 之间的职责边界问题。

该版本还应明确恢复行为。当容器命令已完成但同步失败时，开发者需要可预测的结果。他们还需要关于并发访问、清理、存储限制和长时间 RPC 会话的保障。

如果 Cloudflare 发布带有迁移指南的稳定版本，架构层面的论点将更有说服力。如果 API 持续变动，或该软件包仍停留在实验阶段，团队将继续把该仓库视为设计研究。

第二个信号是完整智能体工作负载的证据。微基准已经显示 FUSE 的优势和短板。更难回答的问题是：在隔离环境与容器之间路由命令，是否能改善总任务时间、可靠性或资源利用率。

有价值的评估应比较相同的编程、研究和数据分析智能体。它们应衡量启动延迟、执行时长、同步失败、传输的存储数据量以及任务成功完成情况。单纯的文件系统基准无法捕捉这些综合影响。

仓库中的示例是一个起点，尤其是对同一任务进行运行时比较的界面。独立测试还应加入更大的仓库、重复的软件包安装、并行智能体，以及在中断后恢复的会话。

如果混合运行时工作流能够可靠完成任务，同时调用更少容器，Cloudflare 的机制便会获得支持。如果同步和路由抹去了这些节省，持久化沙箱仍是更简单的选择。

第三个信号是后端策略。如今，应用程序可以描述可用后端，并让智能体自行选择。生产采购方将希望获得确定性的控制机制，规定哪个后端可以访问哪些文件、网络、密钥和命令。

Cloudflare 已具备相关基础设施。其 Sandbox 平台包含可编程的出站控制，而 Durable Objects 提供私有的持久化状态。Cloudflare Computer 必须将这些部分整合为开发者能够理解和推理的策略模型。

成熟的实现应让权限升级过程可见。当智能体从 Worker shell 转移到 Linux 时，应用程序应知道原因、新增了哪些能力，以及哪些数据跨越了边界。

这个问题超越了 Cloudflare。LangChain、Daytona、Ona、Modal 及其他平台正通过微型虚拟机、容器、持久化能力和开发者工具的不同组合，探索智能体环境。它们竞争的焦点不只是执行速度，而是如何定义一台智能体计算机。

一些提供商认为，不受信任的智能体代码需要硬件级隔离和完整的机器边界。相比之下，Cloudflare Computer 更强调分解，让工作区在需要 Linux 之前使用更轻量的执行方式。这些立场可以共存，因为不同任务对隔离的需求各不相同。

企业级编程智能体可能仍会偏向配备可复现工具链和严格租户边界的专用环境。高吞吐量文档智能体或许更适合持久化文件和轻量级命令。处理大规模输入的数据智能体，则可能暴露 FUSE 设计在吞吐量方面的限制。

因此，开发者在采用这一理念前应先测试自身的任务组合。统计真正需要原生二进制文件的步骤数量，衡量有多少数据在工作区中流动，并有意触发同步失败以确认恢复能力。

他们还应将出色的智能体体验与足够的安全设计区分开来。“一个工作区”是一个有用的界面，但并不意味着每条执行路径都拥有相同的信任边界。运行时升级应当受到与权限升级同等程度的审查。

Cloudflare Computer 的重要性在于，它明确提出了这一设计选择。它要求开发者将文件视为持久状态，将执行视为可选服务，并将表面上的计算机视为针对每项任务组装而成的抽象。

即使这一预览版发生重大变化，这一框架仍将影响智能体基础设施。它为另一种方案提供了可能：不必仅仅因为智能体之后还需要文件，就让一个容器或微型虚拟机持续运行。

GitHub 上的热度激增证实了人们对这一理念的兴趣。但这并不能说明开发者究竟更偏好单台机器带来的运维简洁性，还是多个运行时共享一个工作区所承诺的效率。

未来几个月，应关注代码仓库而非星标数量。稳定的 API、端到端基准测试和严格的后端策略，将决定 Cloudflare Computer 会成为生产级基础设施，还是仍停留在引人注目的预览阶段。

评估 cloudflare computer preview 的团队应从受控工作负载开始，记录每一次运行时切换，并在信任持久状态之前测试恢复能力。哪些操作真正需要 Linux，哪些只需要文件加上一个小型执行界面？通过追踪记录和故障测试来回答这个问题，将揭示混合模型是否适合你的智能体。它也会暴露哪些场景下传统沙箱仍然更易于保障安全和运维。更大的启示已经很有价值：智能体的计算机不必是一台永久运行的机器。然而，将其拆分为多个服务，会把复杂性转移到路由、同步和策略之中。应将这些机制视为核心基础设施，而非实现细节。