我把官方博客和 GitHub 仓库翻了一遍，最打动我的不是它多了几个功能，而是它跟市面上所有沙箱产品想的都不一样：把"文件"和"跑代码的机器"拆开。这话先放着，看到后面那张图你就明白了。

一、先一句话说清，它是个什么东西

Cloudflare Computer，npm 包名叫 @cloudflare/computer。2026 年 8 月 3 号，Cloudflare 一年一度的 Agents Week 上发布的，作者是 Matt Carey 和 Aron Carroll 两个系统工程师。MIT 协议开源，一条命令装：

一句话说它的定位：给 Agent 一个能长期用的虚拟工作环境。Agent 在这里读写文件、跑命令、操作 Git，换个会话接着用，而且碰不到你的本地电脑。

先提醒一句：README 白纸黑字写着 PREVIEW ONLY（预览版），API 会变，设计会改，只适合做实验和原型，别用在线上核心业务。这事后面专门说，先看设计。

它有个特别直白的口号：你的 Agent 需要的是一台电脑，而不是一个容器。这俩到底差在哪，是整篇文章的主线，我画张图你先感受下。

一句话总结这张图：容器把"存东西"和"算东西"焊在同一台机器上，电脑把这俩分开。Cloudflare Computer 选的，就是后者。

二、它跟 Cloudflare Sandbox、Container 是什么关系

这仨名字太像，绕晕过不少人。理清楚很简单：Cloudflare 在 2026 年 4 月已经把 Sandboxes 和 Containers 转成正式服务了，Computer 是站在它俩肩膀上，又加了一层。

打个比方。Sandbox 和 Container 给的是底下的隔离执行环境，要么是完整的小虚拟机，要么是轻量的 isolate，相当于电脑里的 CPU 和内存。Computer 在这之上把零件攒成一台整机：一个能长期保存文件的硬盘，加一套可以随时换的执行后端，整台交给 Agent。

所以别把 Computer 理解成又一个沙箱 SDK。它的目标是让容器只在不到 10% 的活儿里才必须用，剩下的 isolate 就够。这跟"给你一台容器自己折腾"是两种思路。

三、核心主张：把状态和算力拆开

现在说到这篇文章真正的命门。你去看市面上的沙箱产品，不管是 E2B、Daytona 还是 Modal，卖法都一样：给你一台容器或虚拟机，你在里面跑代码，用完就扔。容器既是"存东西的地方"，又是"算东西的地方"，这俩被焊死了。

Cloudflare 的判断是：这个捆绑才是真瓶颈，不是模型多强，也不是 GPU 多快。因为 Agent 越来越多、越跑越久，要是每个 Agent 都得配一整台常驻容器，账根本算不过来。

算一笔账就懂了。一台容器启动要几百毫秒到秒级，常驻要吃几百 MB 内存；Agent 大部分时间其实在等模型、等人，闲着也烧钱。并发一上来，几千个 Agent 就是几千台几乎空转的机器。更麻烦的是，活儿干了一半容器崩了，状态跟着陪葬。

于是 Computer 把两件事彻底分开：文件的正本放进 Durable Object 里的 SQLite 虚拟文件系统，重启也不丢；执行后端做成可插拔的，随用随接，用完就扔。

四、架构总览：三层，一个 Workspace

先看整体结构，一共三层：Worker 做入口，管登录验证、限流这些事；Durable Object 当中间的管理层，手里攥着 Workspace 和那份 SQLite 文件系统；执行后端在最下面，真正跑代码。

Durable Object 这块要顺一句：它有稳定 ID、能存状态、就挨着算力放，特别适合当"这台电脑的主板"。Cloudflare 把"大脑和手分开"这个思路用了起来：Agent 的大脑跑在 DO 里，跟用户保持长连接、调模型；真要干活了，才把下面那台容器叫醒，干完接着让它睡。

整台机器的核心叫 Workspace。一个 Workspace 住在一个 Durable Object 里，装着那个 SQLite 虚拟文件系统，对外只开一个执行口：workspace.runtime.exec(source, { backend })。后端第一次用到才连，也可以干脆不挂后端，只当个纯文件系统用。

五、Workspace 内部：文件系统才是主角

Computer 的底层包叫 @cloudflare/dofs，全称 Durable Object FileSystem。说白了，它就是一个存在 SQLite 里的虚拟文件系统，所有文件的正本都在这里，Durable Object 重启也不丢。

有几个工程细节你得知道，不然会踩坑：

第一，装 Workspace 的那个 Durable Object 必须注册成 SQLite 类型（new_sqlite_classes）。普通 DO 的存储只是简单的键值对，撑不起文件系统，注册错了直接跑不起来。

第二，文件 API 刻意做得像 Node 的 fs/promises，readFile、writeFile、mkdir、readdir 全家桶，还带一个 grep。全异步，路径全用绝对路径。这样第三方 JS 库能直接拿来用，迁移成本低。

第三，它支持 R2 只读挂载，可以把云上的数据预填充进工作区目录，适合给 Agent 一份只读的参考料。

但它有天花板：单个 Workspace 上限约 10 GB，因为跟 DO 自己的存储是共用的。而且容器那份文件默认放在内存里，特别大的目录别往里塞。Cloudflare 的原话是，这是给 Agent 日常干活用的，不是让你把整个大仓库搬进去的。

六、三个执行后端，各干各的活

这是 Computer 最妙的地方：同一个 Workspace，可以挂三种后端，按需切换。模型甚至能自己决定这回用哪个。我一个一个说。

Isolate Shell：一个不离开隔离区的 shell

它跑的是 just-bash，一个把 bash 命令翻译成 JS 来执行的开源实现，作者是 Vercel Labs，不是 Cloudflare 自己。它在一个 Dynamic Worker 里跑，关键点是：它通过 Workers RPC 直接读写 Workspace 里的文件，不用复制一份，也不用来回同步。改文件、查文件、Git 操作这类轻活，用它就够，连容器都不用起。

Isolate JavaScript：一个干净跑 JS 的环境

它在一个全新的 Dynamic Worker 里执行一段 JS 模块。传参数进去、拿结果出来，可以用预先装好的库，文件操作走 Workspace 里的 node:fs/promises。另外配了两个内置模块 ws:git 和 ws:artifacts，一个管源码，一个管构建产物。JS 应用、数据处理、生成文档这类活儿，它在隔离区里就能干完。

Container：真要 Linux 时才用的重档

需要 npm、原生二进制、完整用户态、真实网络时，才升级到这一档。它把 SQLite 里的状态通过 FUSE 挂进一个 Cloudflare 容器，挂载点是 /workspace。

容器里有个叫 computerd 的守护进程，负责把文件系统的改动通过 capnweb RPC 通道同步回 Durable Object。这一档最接近 E2B、Daytona 那种你熟悉的容器，也最重。

七、走一遍：一次 container 执行到底发生了什么

光说概念不过瘾，跟着一条命令把容器这条路走一遍。假设 Agent 决定"这回得上真 Linux"，事情按这六步发生：

注意第⑤⑥步：命令跑完，容器可以睡、可以扔，但改动已经通过 computerd 落回了 SQLite。这就是开头说的"合上电脑明天接着写"的底气。DO 还顺手当"守门员"：记着用户授权过哪些仓库、哪些操作，再决定放行哪些出网请求、注入哪些凭据。

八、代价：FUSE 那点性能账

持久化不是白给的。文件从 FUSE 进、再同步回 SQLite，中间这层有成本。Cloudflare 自己跑了套测试，我直接把数字摆给你。测试机是一台 standard-2 规格的容器（1 个 vCPU、6 GiB 内存、12 GB 磁盘）。

最能说明问题的是装 854 个 npm 包：走 computerd 的 FUSE 要 124.7 秒，原生磁盘 63.9 秒，内存盘 34.3 秒，差不多慢一倍。但小操作反过来：查文件、删文件、git 提交这些，computerd 比原生磁盘还快，只是追不上内存盘。

这组数字我是这么读的：它不擅长装包、解压这类大文件读写，但擅长增删改、grep、Git 这类小操作，而 Agent 的日常恰恰更偏后者。Cloudflare 的算盘也在这儿：能省的重活尽量留给 isolate，非必要不起容器。别忘了这是 Cloudflare 自己测的，没有第三方复测，看的时候打个折。

另一头是启动成本的差距：isolate 几毫秒就能起、只吃几 MB 内存；容器要几百毫秒、吃几百 MB。再叠上快照：重新装一份环境约 30 秒，从快照恢复只要约 2 秒。两组数字放一起看，就明白"文件"和"机器"为什么要拆开：机器要能随叫随到、随用随睡，文件才能做到闲着不花钱、干活秒恢复。

九、让模型自己挑后端

Computer 给 Agent 的工具集照着 Vercel AI SDK 的接口做：read、write、edit、ls，外加可选的 exec 和 publish。其中 exec 最特别，它多一个 backend 参数。Cloudflare 在工具说明里引导模型自己判断：这回走快又省的 isolate，还是上全功能的容器。

官方说法是，跑下来前沿模型这个决策做得相当准，只在该升级的时候升级，大部分活儿前两个后端就消化了。它的愿景目标也挂在这：让一个容器只承担不到 10% 的工作，编码、音视频处理、文档生成这些，尽量都在 isolate 里解决。

十、放到同行里看，它处在什么位置

不跟同行比一下，容易高估也容易低估它。把几家卖的东西摆在一起，差别一眼就看出来。

E2B、Daytona、Modal 这几家，卖的都是一次性容器或虚拟机：拉起、跑代码、扔掉，文件要么手动存快照，要么跟着容器一起消失。Vercel Sandbox、AWS AgentCore 也是同一个思路，给你个隔离环境跑不可信代码。

Cloudflare 反着来：默认把文件存在 isolate 旁边，重活才临时拉一台容器。但这话得说全，Computer 不是通吃。E2B、Daytona、Modal 的主场是不可信、重算力、原生依赖、甚至要 GPU 的活儿，而 Computer 现在没有 GPU，还离不开 Cloudflare 平台。

所以我的判断是：Computer 真正的价值，是给"是不是每个动作都得配个容器"这个问题，交了一个不一样的答案。它其实在坚持一件事：文件应该自己活得下去，不绑在跑它的机器上。这个判断要是站得住，值得整个行业学；要是 isolate 的省钱账在正式定价后不成立，那它就是个漂亮的实验。现在下结论还早。

十一、先别上头，泼几盆冷水

吹了这么多，该冷静了。给你四条红线，决定你要不要现在碰它。

其一，还是预览版。README 写得很死：API 不稳、设计会改，只适合实验和原型，不适合生产。想用到线上核心业务的，等正式版。

其二，不接受主动 PR，只走 issue 和 discussion；仓库里那份 docs 更是被标注成"前瞻意图，不是对现状的描述"。也就是说很多设计还停在纸面上。

其三，测试是官方自测的。那组数字是 Cloudflare 在自己机器上跑的，没有第三方复核，看的时候打个折。

其四，绑在 Cloudflare 上。它整个建在 Durable Object 上面，天然离不开这家平台，想保持多云、想搬家，代价自己掂量。

十二、收个尾

写到这，帮你把 Cloudflare Computer 压成三句话：

它把 Agent 需要的"电脑"拆成两部分：一份存在 Durable Object 里、换会话也不丢的 SQLite 文件系统，加三个随叫随到的执行后端（两个 isolate 加一个真 Linux 容器）。中间只留一个 exec 入口，两边各干各的，文件始终对得上。

它的野心不是再造一个沙箱 SDK，而是想把"文件"从容器手里解放出来，让它自己就能长期存在。这件事要是成了，改变的不只是它自己。

但答应我，先记住它还是预览版。想感受"给 Agent 配电脑"到底香不香，最实在的做法是把仓库下下来，跟着官方教程跑一遍，让 Agent 在自己的工作区里真干点活，比读十篇解读都清楚。仓库地址放这儿：

至于它和 E2B、Daytona 们谁能笑到最后，我的态度是：让子弹再飞一会儿。架构方向我投它一票，商业成熟度我暂时捏把汗。