Cloudflare发布智能体执行环境computer预览版

Cloudflare 这次发布值得看，是因为它瞄准的不是“再给模型加一个工具”，而是智能体从计划走到执行时最容易散落的三件事：工作文件放在哪里、命令在哪儿跑、不同任务该选哪种运行环境。官方在 2026 年 8 月 3 日 13:15:24 UTC 发布 @cloudflare/computer，把这些接口收进一个面向 Worker 与 Durable Object 的预览包。

可以确认的事实是：该项目将 Durable Object 中 SQLite 支撑的虚拟文件系统作为工作区状态；代码可经 workspace.runtime.exec() 进入后端；仓库当前列出容器、Worker shell、Worker JavaScript 3 种后端。npm Registry 在公告前已将 latest 指向 0.1.1，其记录的发布时间为 13:01:22 UTC。

状态限制同样清楚，而且必须放在功能之前读。公告、开源仓库根 README 和包文档都使用了 “PREVIEW ONLY” 的表述：API 不稳定、设计可能变化，只适合实验、探索和原型，暂不适合生产。因此，虚拟文件系统、多执行环境与智能体工具封装都已经是可审阅的预览能力，不能被写成 Cloudflare 对长期兼容、生产可用性或企业安全控制的正式承诺。

对开发者，直接价值是少写一层把 Agent 文件、命令执行和流式输出粘在一起的胶水代码；对平台团队，真正的工作还在后面：不同后端的网络权限、资源上限、数据保留、审计与故障恢复并没有因为统一 API 而自动统一。选择该预览包，应先把它放入隔离的原型环境，而不是把它当作可直接替换现有生产沙箱的组件。

这次发布实际交付了哪一层

Cloudflare 在博客中把 @cloudflare/computer 描述为 agent runtime，并强调它会在快速的 isolates 与完整 Linux containers 之间编排。开源仓库给出了更具体、也更需要谨慎阅读的实现视图：一个 Workspace 的权威状态位于 Durable Object 的 SQLite 中，执行面则是可插拔的。

这里的“计算机”并不等同于每个智能体都得到一台永久、完整的虚拟机。它首先是一个可持久化的工作目录，以及围绕该目录的读、写、编辑、列举和执行接口。包文档将 workspace.fs 设计得接近 node:fs/promises，而 workspace.runtime.exec() 则根据所选后端把输入解释为 shell 命令或 ECMAScript 模块。

这一区分很重要。传统的 Agent 应用常常把会话状态放在数据库，把临时文件放在对象存储或容器卷，再把命令投递到另一个执行服务。每一层都可以独立扩展，却也会分别产生身份传递、路径映射、文件回传、超时取消和结果归档的问题。Cloudflare 的预览把“工作区”设为这些操作的共同边界，试图让后端替换时不必更改所有文件操作调用。

层次	预览包中的角色	可以确认的能力	不能据此推定的事
工作区状态	Durable Object 中的 SQLite 虚拟文件系统	文件读写可跨 DO 重启保存，容器与 Worker 后端围绕同一 Workspace 工作	无限容量、跨区域复制策略或企业级备份 SLA
容器后端	Cloudflare Container 内的完整 Linux 用户态	可运行真实二进制、npm、node，并由 computerd 将文件系统与工作区同步	任意网络访问、任意镜像、任意时长任务均默认获准
Worker shell	Dynamic Worker 中的 just-bash	无需容器即可执行一部分 shell 命令，并通过 Workers RPC 访问工作区	与完整 Linux 命令、包管理器或内核环境等价
Worker JavaScript	新鲜的 Dynamic Worker 中执行模块	支持结构化输入输出、相对导入及 Workspace-backed node:fs/promises	任意 Node.js 原生依赖、无资源限制的代码执行

表中的后三行来自项目 README 和包文档的“当前后端”描述。它们是这次预览提供的实现选择，不是 Cloudflare 宣称所有后端具有相同性能、安全属性或正式支持等级。尤其是容器和 isolate 的隔离模型、出网策略以及任务取消语义，必须按各自的部署配置和平台文档核对。

一个工作区，三种不同的执行代价

容器是功能最完整的一条路径。仓库说明，computerd 在 sandbox container 内把 Workspace 状态作为 FUSE 挂载呈现；容器中的改动再经 capnweb RPC 通道同步回去。对需要系统二进制、包管理器、完整 Linux 用户态或真实网络的任务，这比在 Worker 中模拟命令更接近开发者习惯的环境。

代价也写在包文档中：容器侧文件系统保留在内存中，适合 Agent 规模工作区；通过 FUSE 的重 I/O，例如大型 node_modules 安装和大压缩包解包，会慢于原生磁盘。文档列出单工作区约 10 GB 的存储尺度，且与 Durable Object 存储共享。这是设计容量说明，不是用户可以把完整企业单体仓库长期塞入其中的保证。

Worker shell 的路径更轻。它借助 just-bash 在 Dynamic Worker 中运行命令，文件操作直接通过 Workers RPC 访问同一个 Workspace，因此没有第二套持久化存储，也少一次容器文件同步。换来的限制是它不是完整 Linux：需要操作系统包、编译工具、复杂原生依赖或特定网络行为的任务，仍要转给容器或改写为 Worker 可运行逻辑。

Worker JavaScript 则把任务收敛为一个 ECMAScript 模块。它适合结构化输入与输出、轻量脚本以及直接调用 Workspace 文件 API 的场景。包文档也明确了前提：这两种 Worker 后端需要 Worker Loader binding 和 experimental compatibility flag；JavaScript 后端还需要正确传入 waitUntil。这些配置条件意味着“统一 exec”减少了应用层分支，并没有取消底层 Workers 配置与兼容性管理。

从智能体编排角度看，三种后端对应的不是简单的快慢档位，而是三组约束：

• 需要真实 Linux、二进制工具链和可能的联网命令时，容器更合适，但要接受启动、同步和 I/O 成本；
• 需要对文本、文件和有限 shell 操作快速响应时，Worker shell 可以避免容器；
• 需要可控模块、结构化结果与 Worker 原生接口时，Worker JavaScript 的边界更清晰。

官方目前没有在本次公告中给出把一项任务自动分配到哪条路径的完整策略、基准数据或失败回退规则。博客使用了“动态编排”的产品语言，但部署方仍应显式设定后端选择规则，并观察 Agent 是否会把高风险命令错误送到权限更宽的执行面。

版本记录能证明什么，不能证明什么

npm Registry 提供了当天最清晰的分发时间线：0.1.0 在 12:19:20 UTC 出现，0.1.1 在 13:01:22 UTC 出现，后者被标为 latest。仓库中也存在 v0.1.1 Git 标签，因此“公告发布时已有 0.1.1 包可供解析”有两个可回溯入口。

但 latest 不等于稳定，也不等于 GA。预览包的版本号只能证明某个分发快照被登记到 Registry，无法证明所有 API 已冻结、示例在所有地区可部署，或升级不会破坏此前的原型。项目仓库甚至提醒：docs/ 下的 specification 是前瞻性设计，应作为 intent 阅读，而不是把它逐项当作当前代码的描述。

这也是解读 “virtual filesystem” 时最容易越界的地方。官方确实写明文件状态可由 Durable Object SQLite 支持，容器侧可借 FUSE 呈现该状态；但这不自动回答数据在哪个地区落盘、灾难恢复如何做、写冲突何时可见、容器被杀死时未同步写入如何处置。它们不是措辞上的小缺口，而是智能体执行进入企业工作流前必须被验证的操作语义。

原文状态词的翻译边界

官方原文或文档状态	本文中文表述	不能改写成
PREVIEW ONLY	仅预览、用于反馈	已正式上线、GA
APIs are unstable	API 不稳定，可能变化	接口已固定、可长期兼容
Suitable for experiments, exploration and prototypes	适合实验、探索和原型	已适合生产关键路径
NOT suitable for production use at this time	当前不适合生产使用	未来必然按某日期生产可用
three backends ship today	当前仓库列出三类后端	三类后端已有同等 SLA 或安全认证

这些状态词均来自仓库或包文档。公告没有给出生产可用的截止时间，因而不能用“即将转正”补写时间表。

平台能力与预览承诺必须分开

Cloudflare 的 Containers 官方文档说明，Containers 可由 Worker 代码按需启动，并用于需要并行 CPU、大内存或磁盘、完整文件系统和既有容器镜像的负载；文档还标注该平台可在 Workers Paid plan 使用。这解释了为什么 @cloudflare/computer 把容器作为一个后端：它能覆盖纯 Worker 不适合的工具运行场景。

不过，底层 Containers 的通用能力不能直接外推到 computer 预览包。Containers 文档说的是平台服务的使用方式，computer 的 README 说的是一个 API 尚会变化的开源预览。两者之间仍有需要用户自己配置和测试的环节，例如 computerd 容器镜像、Durable Object binding、Worker Loader、兼容性标记、工作区 ID 映射及后端默认选择。

安全边界也要按此拆开。容器可以运行“real network”的描述，是项目文档解释容器后端能力的一部分；它不是“所有 Agent 默认拥有安全的外网白名单”或“所有数据自动隔离”的声明。反过来，Worker 后端减少了容器操作面，也不能仅凭运行位置就断言其满足某个企业合规等级。要进入真实业务，团队至少需要把命令允许列表、密钥注入、出网控制、租户隔离、文件导出、日志保留和人工审批放进自己的威胁模型。

现在适合怎样试，后续又该盯什么

在当前状态下，较稳妥的试用方式是选一个无敏感数据、可随时删除的 Agent 工作流：例如把 Markdown 转换、代码脚手架生成或只读资料整理接入 Workspace。先固定一条后端，再记录冷启动、文件读写、失败重试、任务取消和输出回传；等这些基础行为清晰后，才比较容器与 Worker 后端是否值得混用。

不宜在预览阶段直接迁移的场景包括：依赖稳定 API 的公共产品、需保证数据驻留与审计的客户工作流、无法接受容器或 Worker 配置变化的自动化，以及把任意用户命令直接交给 Agent 执行的系统。后者即使不用该包，也需要独立的权限与沙箱设计；computer 并没有在公告中替团队承诺这层治理。

接下来可观察的信号分成两类。产品信号包括 GA 计划、地区与价格、版本迁移政策、每种后端的资源和并发上限。工程信号包括 SQLite 到容器文件系统的同步一致性、FUSE 在大 I/O 下的实测、Dynamic Worker 后端的命令兼容范围，以及命令、网络、文件导出在多租户中的可审计性。只有这两组信息逐步公开，@cloudflare/computer 才能从一个有吸引力的 Agent 原型底座，变成可以纳入生产架构评估的执行层选项。