Cloudflare Computer：文件系统即真实产品，AI 沙箱新思路

2026年8月3日，在 Cloudflare 品牌化为"智能体周"（Agents Week）的活动中期，工程师 Matt Carey 和 Aron Carroll 发布了一个名称几乎刻意追求通用化的项目预览：@cloudflare/computer。它的 tagline 是"给你的智能体配一台电脑 👾"，听起来像是日益拥挤的 AI 智能体沙箱领域里又一个入局者。此后在 GitHub 上获得了大约 7,700 颗星，就 GitHub 趋势标准而言算得上体面，但算不上病毒式传播。

让它值得再看一眼的不是星数，而是架构。这个领域里的所有其他产品——E2B、Daytona、Modal 沙箱、Docker 自己的智能体工具——卖给你的都是一个容器或虚拟机：启动一个、在里面跑代码、用完销毁。容器是状态的单元，也是计算的单元，二者捆绑在一起。Cloudflare 的赌注是，这种捆绑才是真正的瓶颈，而不是 GPU 周期或模型质量。@cloudflare/computer 将二者拆开了：文件系统是持久且权威的，活在由 SQLite 支撑的 Durable Object 中；而针对该文件系统执行代码的东西——容器、JavaScript 隔离区、shell 隔离区——每次调用都是可丢弃、可替换的。这与"pip install 然后得到一个 VM"有着本质上的不同，在决定是否基于它构建之前，值得理解一下 Cloudflare 为什么认为这很重要。

它实际做什么

剥掉品牌外衣，@cloudflare/computer 是一个活在 Durable Object 内部的工作空间对象。这个工作空间持有一个东西作为 ground truth：一个虚拟文件系统，持久化到 SQLite。其他所有东西——容器、隔离区、RPC 通道——都是让代码读写那个文件系统的方式。

公共 API 表面刻意做得很小。执行入口只有一个：

workspace.runtime.exec(source, { backend })

source 要么是一条 shell 命令，要么是一个 ECMAScript 模块；backend 则从三个已注册的执行面中选择一个来处理它。一个单一的工作空间可以在稳定 ID 下注册多个后端，并在每次调用时选择其中之一——这就是真正新颖的地方：你不是在项目设置时选择一次沙箱提供商，而是在每一次工作时选择一种执行策略，而文件系统状态根本不在乎你上次选了什么策略。

预览版中包含的三个后端：

Container（容器）。SQLite 支撑的文件系统状态被投影到一个沙箱化的 Cloudflare 容器中，作为真实的 FUSE 挂载。沙箱端有一个名为 computerd 的守护进程，将状态挂载为文件系统，并通过 Cap'n Web RPC 通道将变更同步回来——这是 Cloudflare 自己无模式的、对象能力的 RPC 框架，由 Cap'n Proto 的原作者构建。这个后端给你一个完整的 Linux 用户空间：真实的二进制文件、真实的包管理器、真实的出站网络访问。它是最重量级的选项，也是最接近 E2B 或 Daytona 默认提供的方案。

Isolate shell（隔离区 shell）。在 Dynamic Worker 中运行 just-bash——这是 Vercel Labs 构建的 bash 实现，不是 Cloudflare 的。它直接通过 Workers RPC 与权威工作空间通信，所以没有第二个文件系统需要同步，循环中也没有守护进程。它是一个 shell 环境，但永远不会离开隔离区。

Isolate JavaScript（隔离区 JavaScript）。在一个全新的 Dynamic Worker 中运行 ECMAScript 模块，具有结构化的输入输出、持久的相对导入、一个 Workspace 支撑的 node:fs/promises 垫片，以及两个可信模块 ws:git 和 ws:artifacts，分别用于源代码控制和构建产物。

后端在首次使用时懒连接，而工作空间本身是智能体唯一需要持有引用的东西——它不需要预先知道某个任务是需要完整的 Linux 容器还是可以用沙箱化的 JS 模块来处理。那个路由决策可以由平台做出，也可以由模型自己在执行时做出。

它实际是怎么构建的

有趣的工程决策在于真相来源（source of truth）在哪里。在传统的沙箱产品中，容器自己的文件系统就是状态——当容器消亡时，除非你明确地将它快照或同步到某处，否则状态就消失了，或者必须从基础镜像加上命令日志来重建。@cloudflare/computer 将这个关系反转了。Durable Object 的 SQLite 存储是权威的；每个执行后端都是该存储的一个视图，而不是存储本身。

对于容器后端，这意味着一条真正不寻常的数据路径：运行在沙箱内部的 computerd，将 SQLite 支撑的状态挂载为真实的 FUSE 文件系统，并通过 Cap'n Web RPC 将写操作同步回来。容器可以表现得像拥有了一个正常的 Linux 文件系统——因为从内部看它确实有——而 Durable Object 从不丢失对真实状态的追踪。杀掉容器，启动一个新的，重新挂载，你就回到了离开时的状态，无需重放命令日志。

对于隔离区后端，没有 FUSE 层也没有守护进程，因为没有第二个文件系统需要协调——隔离区运行时，用 Cloudflare 的术语叫"Dynamic Worker"，直接通过 Workers RPC 与 Workspace 通信，JS 模块后端所做的 node:fs/promises 调用是对持久状态的真读真写。这才是将状态与计算分离的真正论据：对于很大一部分智能体工作——它们实际上只是"读一些文件，运行一些确定性逻辑，把一些文件写回去"——Cloudflare 的公告特别指出这"非常适合文件操作和数据处理"——你根本不需要付出启动容器、挂载文件系统或保持持久虚拟机运行的成本。只有当一个任务真的需要原生二进制文件、包管理器或完整用户空间时，你才需要使用容器后端，根据项目自己的描述，这是明确的例外情况，而不是默认选项。

注册模型值得具体过一遍，因为这才是让"让模型选择"从理论变为可行的关键。工作空间不会预装后端；调用代码在稳定的字符串 ID 下注册它们——类似于 workspace.registerBackend('container', containerConfig) 以及 workspace.registerBackend('js-isolate', isolateConfig)——之后任何调用点，包括交给 LLM 的工具定义，都可以传递 { backend: 'container' } 或 { backend: 'js-isolate' } 作为参数，而不是在部署时做出的硬编码架构决策。这意味着，构建在 @cloudflare/computer 之上的智能体框架可以将"在完整 Linux 环境中运行"和"作为快速沙箱脚本运行"作为两个工具调用选项暴露给模型自己，让模型在每个步骤中选择，两个选项都读写同一个持久状态。容器优先的竞争者中没有一家有等价第二层可以作为便宜的默认选项——在 E2B、Daytona 或 Modal 中，"快速便宜"和"完整 Linux"在同一层，只是上面叠加了不同的启动时间优化。

有一个小但值得注意的细节埋藏在 isolate shell 后端选择 just-bash 的决定中：这是 Vercel Labs 的项目，不是 Cloudflare 的。Cloudflare 没有为快速路径编写自己的 bash-in-JS 实现——它采用了竞争对手的开源工具并接入其中。这既可以看作智能体工具周围健康开源生态系统的信号，也可以看作即使 Cloudflare 也认为重新实现一个 POSIX shell 不值得工程时间的信号，取决于你想对这件事多愤世嫉俗。

这里实际改变了什么

这个领域每个认真的竞争者都以容器（或 microVM）作为原子单元来架构。E2B 的卖点是快速启动的 Firecracker microVM，可以在低几百毫秒内启动；Daytona 的模式是类似的快速、短暂的"开发环境即沙箱"模型；Modal 的则是带有 Python 优先 SDK 的无服务器 GPU/CPU 容器。三者都将沙箱自己的磁盘作为状态，三者都在启动速度上投入了大量资金，因为启动时间是每次状态和计算被焊接在一起时你都要支付的代价。

为什么开发者应该真正关注它

成本。这里的成本逻辑直接来自架构。isolate 执行复用 Cloudflare 现有的 Workers/Dynamic Workers 基础设施——与运行普通边缘函数同一个资源池——而不是为每个会话单独配置一台 VM。对于以文件操作而非原生计算为主的工作负载，相比容器-per-task 模型，这是一种明显更便宜的默认方案（假设 Cloudflare 在正式发布时如此定价——预览阶段 isolate 后端的定价尚未最终确定）。

延迟。Dynamic Worker 的冷启动更接近普通边缘函数的延迟曲线，而非容器启动——即使是很快速的容器。对于一个发出多个小型顺序工具调用的智能体循环——编辑一个文件、运行检查、再编辑——把容器启动延迟从大多数这类调用中省掉，收益会快速叠加，即使偶尔有容器后端调用的仍然要付完整成本。

锁定。这是公告中没有深入讨论的部分。整个模型依赖 Durable Objects——Cloudflare 自研的强一致性、单实例-per-key 计算原语——以及 Cap'n Web 的 RPC 语义来承载。没有哪个版本的架构可以跑在另一朵云上。如果你围绕 @cloudflare/computer 的 workspace 模型构建智能体平台，你就是在 Cloudflare 上构建它，就是这样。这比选择 E2B 或 Daytona 的锁定程度要深得多——后两者都可以自托管或替换，因为它们"只是"在你自己的基础设施选择之上的容器编排。

安全。将状态与计算分离改变的是威胁模型，而非简单地缩小它。已被攻陷的容器后端仍然可以通过 FUSE 挂载和 Cap'n Web 通道读写完整的权威文件系统——隔离边界保护的是主机，而非 workspace 的数据。多个后端共享一个 workspace 还意味着，选择哪个后端处理某个调用的路由逻辑如果存在 bug，就会把不受信的 isolate 代码交给与可信容器路径相同的文件系统访问权。这不是 Cloudflare 特有的缺陷——任何多后端执行模型都有这种结构——但值得围绕 workspace 而非任何单个后端来设计你的权限边界。

可维护性与开发者体验。单一入口 API（workspace.runtime.exec）与同时摆弄"沙箱"和"存储"两套独立 SDK 相比，在思考模型上确实更加简洁——这就是当你把 E2B 或 Daytona 接入外部数据库或对象存储自己来在会话间获得持久化时最终要做的事。这里持久化是默认的，不是你后期再加上的东西。

最清晰的适用场景是那些大部分时间在仓库里工作的编码智能体：读取文件、做编辑、运行 linter 或类型检查器、偶尔调用一下构建工具。这种工作负载正是 isolate 后端针对优化的，而持久化文件系统意味着一个长时间运行的智能体会话可以被暂停和恢复——或者在任务中途在 isolate 和容器执行之间交接——而不会丢失状态，这在纯容器沙箱中做起来很别扭。

第二个适用场景是任何需要同时运行许多短生命周期、低权限智能体动作的产品——比如一个后台任务会分发到数十个小文件转换任务——在这里每个任务都启动一个容器，即使很快，也与所做的工作相比是不成比例的开销。

较弱的适用场景是任何本质上是运行不受信的、计算密集的或依赖原生依赖代码的场景：数据科学笔记本、ML 训练任务、任何需要 GPU 的东西。这是 Modal 的核心用例，@cloudflare/computer 的容器后端技术上可以做这些，但不是架构优势显现的地方——你在付完整的容器成本，却没有任何走 isolate 路径的节省。

设想一个编码智能体产品要处理一批数百个 pull request 审查任务。它们大多数是"克隆差分的上下文、运行 linter、检查明显危险模式、写一条评论"——纯文件操作，无需编译，无原生依赖。只有少数需要实际运行项目的测试套件，这意味着需要真正的二进制文件和真正的包管理器。在纯容器平台上，所有这几百个任务都要付完整的容器启动成本，因为那是唯一可用的单位。在 @cloudflare/computer 上，这批任务的主体运行在 JS-isolate 后端上，面对的是同一个持久化 workspace 状态，只有需要实际执行 npm test 的那部分才会升级到容器后端——而且是在任务中途针对同一个文件系统升级，而不是需要单独的交接步骤把文件从一个系统移到另一个系统。这就是架构实际针对优化的场景，也是它在容器优先平台上很难复制的场景——除非你在它上面自己构建一个状态同步层。

文档和发布文章没有深入讨论的部分

该项目明确是一个预览版：README 声明 API 不稳定，并称其不适合生产环境，仓库也不接受自发提交的 pull request——这告诉你这是 Cloudflare 在公开迭代，而非邀请社区共同构建。在正式发布之前，请把这里描述的每个 API surface 都视为可能变化的。

容器后端的 FUSE 挂载加 RPC 同步设计虽然优雅，但也是最有可能出现边缘 case 的部分——这些问题在真实规模运行之前不会暴露——文件锁语义、大文件同步延迟、多个后端针对同一 workspace 并发写入时的行为，这些正是会被早期采用者发现而非在预览阶段提前记录在文档中的东西。目前还没有公开的基准测试将 isolate 冷启动延迟或容器 FUSE 同步开销与 E2B 或 Daytona 的启动时间进行对比，所以"它更快"目前只是 Cloudflare 的说法，并非独立测量的结果。

锁定问题值得重复强调，因为在发布文章中很容易被一带而过：这不是一个跨"某个容器提供商"的可移植抽象。它是 Cloudflare 的原生原语，早期采用它意味着赌 Cloudflare 的 Durable Objects 和 Dynamic Workers 平台是你希望智能体基础设施长期驻留的地方。

这个架构对 rest of the sandbox market 还没有认真提出的问题给出了一个真正不同的答案：是否每个智能体动作都需要一个容器？Cloudflare 的答案是否定的——大多数不需要，需要的那些应该是你主动选择的例外，而非你为之付费的默认。这是一个可以站得住脚的说法，而且如果 isolate 路径的经济性在正式发布定价时能够成立，对于它所针对的工作负载形态来说，可能是一个真实的成本和延迟优势。

但值得注意的是，对"这将全面取代 E2B、Daytona 或 Modal"的论调应保持怀疑态度。这些产品的优化方向有着不同的重心：不受信任的、计算密集型的、存在原生依赖的执行——这最多只是 @cloudflare/computer 容器后端能勉强覆盖的范畴，更准确地说根本不在其目标范围内——这里根本没有 GPU 的故事。Cloudflare 真正构建的是一个强有力的论证：状态（state）理应成为一个独立于执行体（whatever's executing against it）的持久化平台级原语，而且当你同时掌控了计算 fabric（Workers）和强一致性存储原语（Durable Objects）时，这究竟是什么样子的一个可行预览。这种组合对于专注于容器编排的竞争对手来说，如果没有自己的边缘计算平台，就很难复制——这也正是 E2B、Daytona 和 Modal 自身都没有构建类似方案的原因。

谁应该现在尝试、观望或跳过

如果你的项目已经构建在 Cloudflare Workers 之上，且智能体工作负载以文件读取/编辑/grep 为主而非重型原生计算，并且你能接受在副项目或内部工具中运行预览级基础设施和不稳定的 API，那么现在就可以尝试。

如果你需要生产级稳定性、正式版定价方案或在投入工程时间之前需要独立基准测试，请等待——预览标签和"不接受未经请求的 PR"政策是 Cloudflare 在明确告知你它还没有为此做好准备。

如果你的工作负载需要 GPU、需要运行在 Cloudflare 平台之外，或者避免在智能体执行层上形成单一供应商锁定是硬性要求，请跳过——在这种情况下，E2B 或 Daytona（两者都支持自托管）才是更安全的长期选择，无论隔离优先的成本故事最终多么引人。

你是否认同将持久状态与可丢弃计算分离这一方向——这是否是沙箱市场其余玩家最终会效仿的方向，还是这只是 Cloudflare 的专属技巧，只有在他们已经同时掌控边缘计算层和底层存储原语的情况下才能奏效？

cloudflare/computer on GitHub

cloudflare/computer README（原始内容）

Cloudflare Computer Agent Runtime — 2026 年 8 月（explainx.ai）

Agent Runtime 2026: Cloudflare 押注容器之外（Nerd Level Tech）

cloudflare/capnweb on GitHub

vercel-labs/just-bash on GitHub

Cloudflare Durable Objects 文档

如需进一步操作，你可以考虑屏蔽此人或举报滥用行为