产品发布 · 小互解读

Cloudflare 发布 @cloudflare/computer 给每个 AI Agent 配一台「虚拟电脑」

大部分活在毫秒级的轻量环境里跑完，只有硬骨头才调容器。仓库自测：删文件比真磁盘还快，拷大文件慢 41 倍。
一分钟速览
  • Cloudflare 把 Agent 干活的那个 shell 搬出了 Linux，grep、sed、awk 这些命令被人用 JavaScript 重写了一遍。
  • 轻活留在毫秒级的隔离区，只有硬骨头才切给容器。同一份文件两边都能改，但两边拿到它的路子完全不同。
  • 仓库里躺着一份跑分：有的操作比真磁盘还快，有的慢 41 倍。
⚑
本文主线来自 Cloudflare 官方博客，「容器不够用」这个判断和架构主张都是他们自己的口径。文中的性能数字、能力边界和限制条款取自他们的开源仓库 cloudflare/computer（读取时间 2026-08-04），同样是自测自评，暂无第三方复测。
痛点

核心痛点与背景

Cloudflare 发布 @cloudflare/computer：给每个 AI Agent 配一台「虚拟电脑」，而不是单独开一个传统容器。

现在的 Agent 要干活，得先有一台「电脑」写代码、跑测试、处理文件、管 git 仓库，这些事都需要一个能落地执行的环境。今天的标准做法是给它开一个独立的 Linux 容器，相当于配一台专属的小服务器。
算力不够用每开一个容器就要独占一份内存和一份磁盘，启动是秒级。等到 Agent 的数量要往「几亿、几十亿同时在线」去数，这个乘法就做不下去了。

放眼所有的云、所有的超大规模厂商，全世界的算力加起来，也不够让每家公司给自己每个用户的每个 Agent 都配一个容器化的计算环境。

Cloudflare

这就是为什么现在业界对 CPU 算力，而不只是 GPU，有一种绝望的、恐慌式的需求。

这个因果链成立。另一半也得说清：这套论证恰好指向 Cloudflare 手里唯一的差异化资产。他们十年前押注 Workers，六年前押注 Durable Objects，本来就没有超大规模厂商那种 CPU 机队。「容器不够用」既是一个真实观察，也是一个对他们最有利的论点。两件事可以同时成立，怎么看是你的事。

Agent 循环在轻量环境里，向外调用 MCP、浏览器和容器沙箱
今天的常规分工：跑循环的那层代码在轻量环境里，往外调 MCP、浏览器和容器沙箱。git clone、写文件、跑 node 都是丢给右下角那个容器做的。来源：Cloudflare
方案

Cloudflare 的解决方案：给 Agent 一个「专属电脑」

思路是：不直接给 Agent 一个笨重的容器，而是给它一台抽象出来的「电脑」，一份存在云端的文件系统，外加几种能操作这些文件的执行环境。这台「电脑」由三件事撑起来。

一、两种「打工人」搭配干活

隔离区（isolate）· 轻Cloudflare Workers 的运行单位，启动是毫秒级，占内存极小，闲下来能自动休眠，还能自己存自己的状态。适合读写文件、处理数据、管 git 仓库这类轻活。
容器（Container）· 重功能全，一整套 Linux 环境，npm、node、各种包管理器和真二进制程序都在。启动慢、占资源，适合非它不可的重活。
这两者的差别有多大

容器像给每位客人单独盖一间厨房，水电灶台全套，盖起来慢，还占地方。隔离区像在同一个大厨房里给每人划一块互不干扰的台面：划一块只要毫秒，人走了台面立刻还回来。代价是台面上没有烤箱，要烤东西还得去真厨房排队。

顺着这条线，Cloudflare 画了一张架构演进图。左边是年初的做法，Agent、配置密钥、工具全在一个容器里；中间是今天，跑循环的那层搬进了隔离区，配置和工具还留在容器；右边是他们想去的地方，配置和工具也搬进隔离区，容器里只剩下那些非它不可的重活。

BEFORE / TODAY / NEXT 三栏架构演进图
三栏演进图：BEFORE 全在容器里，TODAY 循环那层搬进隔离区，NEXT 连配置密钥和工具也搬进去、容器只剩重活。右边这栏是 Cloudflare 对下一步的规划，不是现状。来源：Cloudflare

隔离区里没有 Linux，它凭什么能干活

这是整套方案最容易被跳过、也最值钱的一层。隔离区里能跑 shell，靠的是一个叫 just-bash 的东西。

just-bash 是 Vercel Labs 开源的项目，做的事情是把 bash 语法和大约 80 个 unix 命令，用纯 JavaScript 重新实现了一遍。grep（在一堆文件里搜关键词）、sed（按规则批量改文本）、awk、jq、sort、find、tar、diff、sqlite3，每一个都是一个 JavaScript 函数，不是一个二进制程序。管道、重定向、&&、变量、通配符、if、for、while、自定义函数，也都实现了。

文本处理 · 全部是 JS 函数
grepsedawkcutsortuniqheadtailtrwcdiffxargsrgsha256sum
文件与目录
lscatcpmvrmmkdirstatfindtreelndutargzip
数据格式
jqyqsqlite3xanbase64
Cloudflare 默认关掉的
python3js-execcurl

这就是它能塞进隔离区的根本原因：没有进程，没有 fork，没有内核，只有一堆 JavaScript 函数在互相传字符串。

代价是一条很硬的边界。翻 Cloudflare 这个包的源码，默认的 shell 环境明确关掉了 just-bash 的三项能力：Python、JavaScript 执行、网络。前两项关掉还不是选择，它们依赖 node:worker_threads，而 Cloudflare 的运行时不支持这个模块，装不上。网络关掉的意思是，curl 在隔离区里根本不存在。

那 git clone 是怎么成功的？隔离区的 shell 自己没有网络，所以 git 是个假命令。它转手交给宿主那侧的 Durable Object，由宿主去真正发网络请求，拉下来的文件直接落进共享的文件系统。隔离区从头到尾没碰过网。

隔离区 · 自己没有网络 just-bash git clone （假命令） ① 转交 宿主 Durable Object 用 isomorphic-git 发请求 代码托管站 只认 https 地址 ② 文件写回 共享文件系统 /workspace ③ 隔离区直接看到文件
隔离区里敲 git clone，命令本身跑不动网络请求，它把活转交给宿主；宿主拉完代码写进共享文件系统，隔离区再直接读。本站按仓库源码 git-command.ts 绘制。

Agent 自己挑用哪个环境

Agent 每敲一条命令，判断的就是这条边界：

隔离区能干
  • 约 80 个文本和文件命令，包括 grep sed awk jq sqlite3
  • git clone / status / diff / log，转交宿主执行
  • 读写编辑文件、遍历目录
  • 完整 bash 语法：管道、循环、函数、变量
隔离区干不了
  • 装包，npm install 跑不了
  • 跑 node，跑 python
  • 任何真二进制程序，pandoc、ffmpeg 都不行
  • 自己发网络请求，curl 不存在

前沿模型很擅长做这个判断，只在真需要时才回落到容器。给模型看的工具说明里就写着容器那侧「有完整的 Linux 用户态：npm、node、包管理器、测试框架，以及 $PATH 上的真二进制程序」，让它照着挑。

看一段真跑出来的记录。用户让 Agent 去更新 cloudflare/computer 这个仓库的依赖，界面上每条命令旁边都挂着标签，写明它跑在哪：

Agent 对话记录截图，命令旁标着 ISOLATE 或 CONTAINER
真实的对话记录。git clone 标 ISOLATE·GIT、ls 标 ISOLATE，read 0 毫秒、webfetch 216 毫秒、apply_patch 0 毫秒。整串活里只有 npm install 标着 CONTAINER，装了 665 个包，花掉 56 秒。来源：Cloudflare

一整串活，只有装包那一步真的需要 Linux，而它一个人就花掉了 56 秒，其余全是毫秒级。

这里有个数字要看清

Cloudflare 给自己定的目标是：容器只承担不到 10% 的活，编码、音视频处理、文档生成都能由隔离区搞定。这是目标，不是现状。对照上面那张能力边界表就知道距离有多远，今天的隔离区没有 Python、没有 node、没有网络、装不了包，音视频处理连一条可行路径都还看不出来。这个 10% 没有任何实测支撑。

二、共享的文件系统

文件本身存在 Durable Object 自带的那份 SQLite 里，那是唯一的真本。无论 Agent 在隔离区还是在容器里操作，看到的都是这一份，不用搬运，也不用各自重新初始化一遍。

但两边够到它的路子，是两回事。

隔离区那边shell 的每次文件读写，通过 Workers binding 直接打到这份 SQLite 上。没有第二份拷贝，没有同步往返，它操作的就是那一份。
容器那边做不到这样，因为容器里的 pandoc 得把文件当成一个普通文件打开才能工作。所以 Cloudflare 往容器里塞了一个自己写的守护进程 computerd，把文件挂载成一个 FUSE 文件系统，容器里的程序读写这个挂载点，改动再通过一条 RPC 通道同步回来。

FUSE 挂载：一种让普通程序把「其实不是磁盘的东西」当磁盘目录来用的机制。容器里的程序以为自己在读一个普通文件，实际每次读写都被转发到远端的 Durable Object。

Durable Object 里的 SQLite 唯一的真本 容器要走的路 FUSE 挂载 切成 512 KiB 块 每块算哈希 RPC 同步 容器 npm · pandoc 每读写一次文件，都要把上面这一串走完 隔离区要走的路 一条 Workers binding 直连 没有第二份拷贝，也没有同步往返 隔离区 just-bash
同一份文件的两条访问路径。上面那条是容器的，每次读写都要过 FUSE、切块、算哈希、再同步回来；下面那条是隔离区的，一条连线直接够到真本。本站按仓库 README 与官方架构图绘制。

为什么要切块算哈希？因为这样 Durable Object 才能只同步改动过的那几块，相同内容还能自动去重。代价直接落在吞吐量上。

这套结构画出来是这样：

Durable Object 里的虚拟文件系统与可插拔执行运行时
全景：虚拟文件系统和执行运行时都长在同一个 Durable Object 上，文件可以从云存储、代码仓库、压缩包这些外部来源灌进来。来源：Cloudflare
Workspace 与两种执行运行时的连接方式对比图
这张把不对称画得最清楚：容器那侧自己有一份文件系统副本，靠 push / pull 和真本同步；隔离区那侧只有一层薄薄的转接层，走 binding 直接读写真本。图右侧标着「a small computed binary」，按仓库应为 computerd 守护进程，判为原图笔误。来源：Cloudflare

官方教程里那个例子最能说明这套分工怎么省事：你 POST 一道菜名，Agent 去菜谱站找到做法，在宿主这边写一个 card.md，然后在容器里跑 pandoc card.md -o card.pdf 转成 PDF，最后传到 R2 给你一个一天有效的链接。写 markdown 是纯文件操作，在宿主直接完成，不用开容器；pandoc 是真二进制程序，必须进容器。容器通过挂载看到的是同一个 /workspace，所以它读到的就是刚写好的那个文件，生成的 PDF 也回得来。

这套设计的账单：小文件更快，大文件更慢

Cloudflare 拿 FUSE 挂载点和容器自己的 ext4 磁盘跑了一组对照，环境是 standard-2 容器实例：1 个 vCPU、6 GiB 内存、12 GB 磁盘。

结果在两类活上分岔了。文件多但每个都小的活，它比真磁盘还快；大文件顺序读写，它慢得很难看。

删 1000 个小文件
0.66×
遍历目录树
0.72×
git 初始化 + 提交
0.72×
stat 1000 个文件
0.91×
完整 npm install
1.95×
写 64 MiB 大文件
16.9×
拷贝 64 MiB 大文件
41.5×

条形长度按耗时倍数排布，绿色是比容器真磁盘快，橙色是比它慢。倍数小于 1 就是更快。

场景FUSE 挂载容器 ext4 磁盘倍数
删 1000 个文件827.7 ms1281.8 ms0.66×
遍历目录树 find1813.6 ms4404.2 ms0.72×
git 初始化 + 提交 100 个文件459.2 ms635.4 ms0.72×
建 10×10×10 目录树1597.5 ms3034.7 ms0.74×
git 浅克隆（约 1 MB）549.1 ms576.2 ms0.84×
stat 1000 个文件1971.9 ms2659.3 ms0.91×
npm 初始化 + 小规模安装598.5 ms630.7 ms0.95×
创建 1000 个文件560.6 ms303.2 ms1.85×
完整 npm install（854 个包、36675 个文件）124.7 s63.9 s1.95×
写 64 MiB230.6 ms16.8 ms16.9×
纯读 64 MiB263.1 ms8.5 ms30.3×
纯拷贝 64 MiB852.9 ms22.0 ms41.5×

快的那一半有个明确的原因：文件索引放在内存里，所以凡是「翻目录、查状态、删小文件」这类操作，它省掉了真磁盘的寻址开销。慢的那一半原因也明确，就是上面那条切块算哈希的长路，每写一次都要重新算，落在 dd 式的裸吞吐上就很难看。

Cloudflare 自己的解释

快的这八个场景，覆盖了 git status、模块解析、增量构建这些日常开发里真正花时间的地方；而大文件顺序读写在真实开发负载里很少碰到。证据就在表里：「npm 初始化 + 小规模安装」和真磁盘基本打平（0.95 倍），尽管同一个挂载点「纯读 64 MiB」慢了 30 倍。

三、可控与安全

Agent 做的每一步操作都有闸门、有审计、有观测。拆开看是这么几条：

拿不到你的密钥隔离区里跑的代码，读到的环境变量只是调用方显式传进去的那一份快照，Durable Object 自己的环境从不合并进去。宿主的 binding、凭据、存储对象都不进用户代码。
默认不给出网隔离区默认关掉对外请求，要放行得显式配。
读写权限提前钉死挂载进来的外部目录默认只读，写进去会被拒；宿主在每一次改动时都校验这个后端到底有没有写权限。
路径逃不出去越界路径和路径里的每一段符号链接，操作前都会被检查掉。
各种上限都能设CPU 时间、墙上时钟截止、源码大小、输入输出字节数，都有独立的上限参数。

这套说法有两道口子，都值得先知道再上手。

第一，那道路径检查不是安全边界。它不是原子性的「解析到根目录之下」，所以不能拿单个隔离区能力去对抗另一个更高权限方并发替换路径。真要防这种对抗性并发，得等未来的事务型底座，或者干脆给两边用独立的工作区身份。

第二，「留痕」在三种后端里并不一致。隔离区 JavaScript 那种会在工作区数据库里留一份执行流水账，事件和结果一直保留到你显式清理；而隔离区 shell 这一版明确不保留跨请求事件、也没法按 ID 重新接上。要监督式的进程行为，官方建议用容器那条。

另外，执行失败或被取消，已经落盘的文件改动不会回滚。

上手

怎么用（开发视角）

安装和接法

包本身是 MIT 协议、免费开源，npm install @cloudflare/computer 就能装。当前版本 0.1.1，7 月 29 日第一次上传到 npm。

装完之后，工作区可以挂在任何一个 Durable Object 上；如果你用 Cloudflare 自家的 Agent 框架 @cloudflare/think，接起来更短。它自带一套 AI SDK 兼容的工具集，给 Agent 现成提供 read、write、edit、ls、exec 这几个基础工具，其中 exec 带一个 backend 参数，就是前面说的那条选择线。

开箱的运行时有三种

Cloudflare 的博客说两种，仓库 README 和 npm 包的入口都是三种：

01
容器 shell
完整 Linux 环境，真二进制程序、真网络，文件走 FUSE 挂载。慢，但什么都能干。
02
隔离区 shell
just-bash 跑在临时 Worker 里，直连文件系统。快，但没有 Python、没有网络、装不了包。
03
隔离区 JavaScript
让模型直接写一段 JavaScript 模块丢进临时 Worker 跑，node:fs/promises 接到同一份文件上。

第三种是 Code Mode 那套思路的落地：不让模型一条条敲 shell 命令，让它直接写代码。

要花多少钱

包免费，但真跑起来免费套餐直接被挡在门外：

你要的东西免费套餐Workers Paid（每月 5 美元）
容器后端没有，官方价格表这一栏直接写 N/A含 375 vCPU-分钟（合 6 个多小时单核时间）+ 25 GiB-小时内存
隔离区每次调用的 CPU 时间10 毫秒，跑 shell 基本没戏默认 30 秒，最高可调到 5 分钟
单个工作区最大容量1 GB10 GB

本地开发还得装 Docker，因为 wrangler 要在本地构建那个容器镜像。它带了 8 个可跑的示例，其中一个是从空目录开始的分步教程，就是前面那个把菜谱转成 PDF 的例子。

现在还不能上生产

这东西现在只能拿来做实验、探索和原型，不适合用在生产环境：API 不稳定，设计随时会改。连那份设计规范也是前瞻性的，写的是意图，不是代码现状。三条硬限制：

限制意味着什么
最大约 10 GB和 Durable Object 共用存储额度。付费套餐每个 SQLite 型 Durable Object 上限 10 GB，免费套餐只有 1 GB。
容器那侧的文件系统放在内存里超大目录树不合适。原话是：目标是 Agent 规模的工作区，不是一整个 monorepo。
容器走 FUSE重 IO 负载，比如大型 node_modules 安装、解大压缩包，会有可测量的性能损失。
🧰 上手卡 · @cloudflare/computer
入口github.com/cloudflare/computer
价格包本身 MIT 免费开源；容器后端需 Workers Paid，每月 5 美元起
门槛要会写 Workers / Durable Objects；本地开发需装 Docker；免费套餐跑不了容器，隔离区也只有 10 毫秒 CPU 时间
价值

价值与总结

对开发者的价值：底层的脏活不用自己干了以前想让 Agent 既能快速动文件、又能在需要时跑真程序，你得自己搭沙箱、自己写两边的文件同步、自己决定哪条命令派到哪里。这个包把这套底层收进去了，你只管挂上工作区、给 Agent 那几个工具。
对行业和算力的价值：把「一个 Agent 一个容器」这个默认假设推翻了一半前面那段真实记录里，容器只用掉 56 秒，其余全是毫秒级。容器按活跃运行的每 10 毫秒计费，5 美元套餐含 375 vCPU-分钟，同样的额度，够跑大约 400 次这种任务（示意算法：375 分钟 ÷ 56 秒）。按老办法会话全程占着一个容器，这个除法完全不是一个量级。
对 Cloudflare 自己：十年前的赌注开始兑现他们手里没有超大规模厂商那种 CPU 机队，isolate 是唯一能打的牌。这个包把 Workers 和 Durable Objects 从「跑网站的」重新定位成「跑 Agent 的」。

落到具体场景，Cloudflare 说他们内部已经有 Agent 只用隔离区就跑完了整套活：用现代工具链构建、测试、部署 JavaScript 应用，给每个客户生成定制文档，还有用浏览器完成复杂任务。这几件事以前都得开容器。

一句话总结：让 Agent 在绝大多数时候用超轻量的省钱模式干活，只有遇到硬骨头才切到重型模式，从而让大规模跑 Agent 这件事变得又快又省。

今天它还是 0.1.1 的预览版，不能上生产。但它把「Agent 到底需要多少算力」这笔账摊开算了一遍，连难看的那部分数字也一起摊开了。

站内 · 已经有人这么干了
camelAI 把 Agent 从虚拟机里改造成跑在 Cloudflare 边缘节点上
一家公司真把编码 Agent 从虚拟机搬进 Durable Object 之后，成本和延迟各自变成了什么样，可以和这篇官方口径对照着看。
来源
你的 Agent 需要的是一台电脑，不是一个容器The Cloudflare Blog·原文·2026-08-03
延伸
cloudflare/computer 仓库·性能跑分文档·just-bash·Containers 价格·Dynamic Workers 文档
本站说明
页面里的五张彩图来自 Cloudflare 原文，两张线条图（git 转交路径、两条访问路径对比）为本站按仓库源码与官方架构图绘制。跑分数字、能力边界（默认关掉 Python / JavaScript / 网络）、三种运行时、安全机制与两处自划口子、10 GB 与内存限制，均出自 cloudflare/computer 仓库（读取时间 2026-08-04），Cloudflare 的博客未提及；价格与 CPU 时间上限出自 Cloudflare 官方文档。博客称「开箱两种运行时」与仓库的三种不一致，本站按仓库口径写，两边都已标明。「400 次任务」为本站按官方价格表所做的示意算法，原文没有这个数字。