Cloudflare 扔出了一个叫 @cloudflare/computer 的仓库，还贴着“早期预览”的标签，但看两眼你就会发现，这根本不是一个普通的产品更新。它瞄准的是接下来两年最要命的工程难题——当每个 AI 代理都需要一个安全、可快速启动的执行环境时，你到底该让它们跑在哪里。容器？虚拟机？还是更激进地，直接塞进轻量隔离沙箱？Cloudflare 给出的答案是：都行，但思路得彻底反着来。
没有容器的世界里，Agent 怎么活
一个 Agent 一个虚拟文件系统，但不是你想象的那种
大多数人一听到“虚拟文件系统”就会想起 Docker 那样的分层镜像，或者虚拟机里挂载的虚拟磁盘。但 @cloudflare/computer 干的事情不一样。它给每个智能体分配的是一个完全在内存中构建的 虚拟文件系统，没有持久层，没有复杂的卷管理，智能体看到的目录树、读写权限、临时文件全部由这个运行时在瞬间捏合出来。智能体写入文件、读取文件、甚至执行脚本，都发生在这个即用即抛的虚拟层上，执行结束直接销毁。这相当于把“无服务器”那套逻辑嫁接到了 Agent 的执行上下文上——状态被严格限制在一次生命周期内，除非你显式地将结果推送到外部存储。
执行平面三选一，但选择权交给了部署者
这个项目最不 Cloudflare 的地方，是它把执行平面拆成了三种截然不同的形态：在 isolate 里跑、在 容器沙箱 里跑，或者直接在用户本地的 浏览器 里跑。过去 Cloudflare Workers 给外界的印象是“V8 isolate 搞定一切”，但这次他们明显意识到 agent 的工作负载远比一段简单的请求处理复杂得多。需要完整 Linux 系统调用能力？走容器路径。追求毫秒级冷启动和极高密度部署？isolate 是默认选择。想让用户的浏览器直接变成 agent 的执行节点？浏览器沙箱模式已经留好了接口。三种路径共享同一套虚拟文件系统抽象，上层的 agent 逻辑几乎不用修改。
冷启动这个老问题，这回被拆解成了两层
容器对于 Agent 太重了，不是缺点，是错位
过去一年，大量基于 LLM 的自主代理框架默认把每一步工具调用都丢进一个 Docker 容器里执行。安全、隔离性好，但代价也很直接——冷启动动辄几百毫秒甚至上秒，内存占用让单机只能跑几十个并发 agent。当你的目标是同时处理上万个 agent 请求时，这种模式就开始流血。Cloudflare 并没有直接否定容器，而是把决策权上移：短生命周期的工具调用根本不需要容器级别的隔离，一个 isolate 加上虚拟文件系统已经足够隔离文件写入和进程边界；只有那些必须依赖内核特性或者运行不受信二进制的工作，才掉回容器沙箱。这层分级让冷启动从“一刀切的痛”变成了“可规划的取舍”。
混合执行不是折中，是面向成本做路由
真正精妙的地方在于，@cloudflare/computer 把执行环境的选择做成了一种运行时策略，而非编译期配置。调度层可以根据安全策略、启动时间预算、计算资源水位，把同一个 agent 的不同步骤路由到不同的执行平面上。比如代码解释器步骤走 isolate，需要调用子进程的部分切到容器，与用户 UI 交互的部分直接退回浏览器本地执行。这种混合执行的模型一旦跑通，对大规模部署而言就是直接的成本杠杆——你不再因为最坏情况的安全需求，把所有请求都闷进最重的隔离方案里。
开源这步棋，比技术架构更值得琢磨
预览版背后不是秀肌肉，是拉人上船
Cloudflare 给这个项目安的 title 是“开源智能体运行时”，不是“Cloudflare Agent 产品”。注意这个措辞变化。过去它的 Workers、Durable Objects、Queues 都是平台锁定型产品，你用得了原语，离不开全家桶。但这次它主动把 agent 运行时的核心抽象——虚拟文件系统、执行平面调度、沙箱接口——拆出来，放在 GitHub 上，用 MIT 许可证开放。这显然不是一次心血来潮的开源布道，而是在 agent 基础设施标准还没定型的时候，用开源抢占定义权。谁能想到，前端打包器领域发生过的事，现在正在 agent 运行时领域重演。
你可以在本地跑，也可以在边缘跑，这恰恰是护城河
仓库的 README 里明确写了“可以在 isolate、容器或浏览器中执行”，并且给了本地开发和部署的示例。对于平台厂商来说，让用户能跑在非自家基础设施上，通常是自断后路。但 Cloudflare 赌的是另一件事：agent 的工作负载最终会向边缘移动。当延迟优势、数据本地化要求和爆发式并发成为决策因子时，那些已经习惯了这套运行时接口的开发者，会自然而然地把工作负载迁回 Cloudflare 的网络上。开源的每一步都是在降低迁移摩擦，而真正的收费点埋在后面，在调度、在边缘节点密度、在那些你无法自建的东西上。
别急着唱赞歌，预览版留下的坑肉眼可见
生产级基准缺失，现在只能谈路线
必须说清楚，当前版本是 早期预览，没有给出任何生产级压力测试数据。虚拟文件系统在多 agent 并发写入时的隔离强度如何？isolate 模式下对于恶意代码的逃逸防御到了什么级别？容器沙箱的启动到底是 fork 一个已有的微虚拟机还是每次都从头构建？这些问题都没有答案。对于一家以运营大规模生产流量著称的公司，Cloudflare 肯定知道光有 API 形态远远不够，但“路线图”和“现在就能用”之间隔着一整条护城河，而这护城河里淹死过无数看起来很美的开源项目。
开发者体验决定了它是下一个 Puppeteer，还是下一个 Zone.js
抽象层的厚度一旦拿捏不好，这个项目就有可能变成开发者骂娘的源泉。虚拟文件系统要足够透明，让大部分现成的 Node.js 和 Python 工具能直接读写；三种执行平面要能以最低认知成本切换，而不是让开发者在配置文件中写一堆条件分支。目前预览版的示例代码看起来干净，但真实场景里 agent 往往会带着一堆乱七八糟的依赖——那些依赖于原生模块的包会不会在 isolate 模式下直接崩掉？浏览器沙箱里的文件系统映射到底能覆盖到哪些 Web API？这些坑一旦开始填，项目的复杂度会非线性增长。Cloudflare 选了一个很窄的切入点，但这个切入点通向一片沼泽地。
无论如何，@cloudflare/computer 已经在 agent 基础设施这个方向的版图上插了一面旗。它不一定立刻改变你今天部署智能体的方式，但它划出了一条清晰的思考线：agent 运行时不等于容器，更不等于虚拟机，它需要的是一种能够跟随负载形态瞬间切换执行密度的环境。而这条线上，能打的玩家还远没有到齐。
