Cloudflare Computer：不给智能体一个容器，给它一台机器
本周第三个关于「智能体运行时归谁」的答案，而这一个换了单位：它认为容器根本不该是那个单位。框架跑在 isolate 里，容器按需连上来当作一次工具调用，两边共享同一套基于 SQLite 的文件系统。目标写得很直白——让不到一成的工作才需要容器。仍是早期预览版。
Marked as a signal by the editors; worth tracking.
On this page11 sections
This signal comes from a Chinese-language source and is written in Chinese.
Record
The signal
#这是本周第三个关于智能体运行时归谁的答案。微软把它做成受支持的产品，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 模型里，锁定程度显然高于跑一个自己的容器——这正是《系统设计的权衡》里那句话的又一次实例。
Why now
Why it matters
#同一周里第三种关于智能体运行时的答案，而它把问题往下推了一层：不是「运行时该由谁提供」，而是「运行智能体的单位该是什么」。如果按需连上的容器只服务不到一成的工作，那么成本模型、冷启动、状态持久化和可观测性都要重画一次。它同时是今天头条那条结论最干净的对照组——star 数差 14 倍，活跃度指标全部反向。
Background
Technical context
#智能体框架运行在一个 isolate（Durable Object）中，具备快速启停、休眠与状态持久化；需要更重的计算原语时按需连接容器沙箱，作为一次工具调用。三种后端分别是把 SQLite 状态以 FUSE 挂载暴露给容器的容器项目、在 Dynamic Worker 中运行 just-bash 的 isolate shell、以及在全新 Dynamic Worker 中运行 ECMAScript 模块的 isolate JavaScript。核心是一套 isolate 与容器共享的 SQLite 文件系统，可对接 Git 仓库、存储桶或任意文件，全部操作受管控并可审计。npm 包 @cloudflare/computer 目前为 0.2.0，MIT 协议。
Audience
Who should care
#Next
Learning path
#- 先读共享文件系统那一节，把「什么被带到下一步」的答案从提示词换成文件，再回看自己项目里这一步是怎么做的
- 把「不到 10% 需要容器」当成待验证的假设：统计自己智能体任务里真正需要完整操作系统的比例
- 对照那组仓库数字，给你正在评估的任何高热度项目做同一遍核对——star、未关闭 issue、最后一次 push、已发布版本数
- 读《系统设计的权衡》，把「换来什么、付出什么」写成三段式记录再决定
Network
Where it sits in the network
#How this signal connects to neighbouring technologies, skills and background knowledge. Follow any link to keep exploring.
Further thought
Follow-up questions
#- 你的智能体任务里，真正需要完整容器的比例是多少？没有这个数，10% 这个目标对你没有意义。
- 共享文件系统在 isolate 与容器之间同步，冲突与延迟怎么表现？早期预览版有没有公开这方面的数据？
- 把运行时放进一家云厂商的 isolate 模型，迁出去要重写哪几层？这笔账现在算比以后算便宜。
- 如果 star 数与活跃度指标给出相反的结论，你的选型流程会采信哪一个？
Publication record
Featured in
#The briefings that carried this signal, newest first; the last row is the weekly review of its week. The tag is the section it ran in.
技术简报 - 2026-08-17
Worth trackingWeekly review · Aug 10 – Aug 16
Worth tracking
Sources