Cloudflare Computer：不给智能体一个容器，给它一台机器

这是本周第三个关于智能体运行时归谁的答案。微软把它做成受支持的产品，DeepSeek 把它拆成可替换的插件，而 Cloudflare 换掉的是单位本身：它认为容器不该是运行智能体的那个单位。

论证是关于账单的形状，不是跑分

Cloudflare 的说法是：靠容器跑智能体扩展不到「数亿乃至数十亿个并发智能体」，因为全球没有那么多算力。这句话是修辞，不是可核对的结论——真正能被检验的是它派生出的设计目标：让不到 10% 的工作需要容器，编码、音视频处理与文档创建都由 isolate 完成。那是一个目标，不是一次测量。

架构：isolate 跑框架，容器当工具调用

• 智能体框架跑在一个 isolate（一个 Durable Object） 里；isolate 可以横向扩展、启停极快、在不运行时休眠，并持久保存智能体状态。
• 需要更重的原语时，按需连上一个容器沙箱，当作一次工具调用——只在必要时才付那份钱。
• 三种后端：容器项目（把 SQLite 状态以真正挂载的 FUSE 文件系统暴露给沙箱容器）、isolate shell（在 Dynamic Worker 里跑 just-bash 环境）、isolate JavaScript（在全新 Dynamic Worker 里跑 ECMAScript 模块）。

真正的核心是那套共享文件系统

架构里最实的一件东西是基于 SQLite 的共享文件系统，isolate 和容器都能访问。任务因此可以在两者之间无缝转移，两边处理的是同一批文件；它可以对接 Git 仓库、存储桶或任意文件，而所有操作都受管控、经审计、处于可观测状态。

这一条正好接住本站《长时程智能体的记忆与上下文管理》里那个问题——什么被带到下一步。在这里答案不是提示词里的一段摘要，而是一份两种执行环境都看得见的真实文件系统。

制品把口径收窄了一点

npm 上 @cloudflare/computer 的自我描述比新闻稿具体得多：「一套基于 SQLite 的虚拟文件系统，与容器侧守护进程（computerd）同步」。也就是说，包本身首先是文件系统与同步层，而不是一整套智能体运行时。这不是矛盾，是宣传口径与制品口径的粒度差——值得记下来，因为决定你要不要用它的是后者。

而它的仓库数字，正好是今天头条那条结论的反面

同一天发布的 DeepSeek Harness 两天半拿到 11.4 万 star。cloudflare/computer 只有它的十四分之一——但把两边的活跃度指标并排放（均为 2026-08-16 经 GitHub API 与 npm registry 一手核对）：

• star / fork：8,265 / 450，对 114,625 / 11,151。
• 未关闭的 issue：14，对 0（后者几乎只能解释为 issue 功能被关掉了）。
• 最后一次 push：2026-08-14，对停在创建当天。仓库建于 2026-06-05，最近 100 次提交分布在 08-07 到 08-14 的七天里，10 位贡献者。
• 已发布版本：npm 上 0.0.0 到 0.2.0 共 5 个，对没有任何 release。

star 数差 14 倍，而每一个「有人在用、有人在改」的指标都指向相反方向。 这不是说哪个项目更好，而是说这两组数字量的根本不是同一件事——今天那份开放模型生态报告用整个 Hub 的数据说的正是这句话。

边界

本条为二手报道（InfoQ 中文译自 InfoQ 英文，后者报道 Cloudflare），架构描述以该报道为准；仓库与 npm 数字为一手核对。Cloudflare 自己写明仍处于早期预览阶段，只适合实验、探索与原型开发。「不到 10% 需要容器」是设计目标，没有公开的负载分布数据支撑；而把智能体运行时放进一家云厂商的 isolate 模型里，锁定程度显然高于跑一个自己的容器——这正是《系统设计的权衡》里那句话的又一次实例。