“给每个 Agent 一台电脑”很容易让人点头。Agent 有 shell，有文件系统，有网络，再给它一个单独的环境，事情似乎就齐了。
我看完 Cloudflare Computer 的 README，觉得它有意思的地方在另一处。Agent 跑一次命令不难，难的是它跑到第三步、第五步，甚至换了执行环境以后，前面留下的文件、日志和产物还找不找得到。
举个 README 里能对应上的场景。一个任务先写好 Markdown，后来要调用 pandoc 生成 PDF。前半段可能在 Worker 里完成，后半段需要进有完整 Linux 用户空间的容器。文件若跟着前一个执行环境放，后面就要拷贝、同步、挂载。任务再失败一次，系统还得回头确认那份文件最后在哪儿。
Cloudflare Computer 把这件事单独拎了出来。它先给任务留一个 Workspace（工作区），再让容器、Worker Shell 和 Worker JavaScript 按各自的能力接入。执行环境可以换，工作目录还在原处。
这篇文章只根据项目的 GitHub README 和公开示例来讲。该项目明确写着 PREVIEW ONLY，目前适合实验和原型，不能直接当作生产方案使用。接口和设计都有变化的可能，下面谈的是它已经公开的做法，不是对安全性或性能的背书。
容器停了，任务留下什么
容器很适合给 Agent 干活。它能装依赖、跑编译器、执行测试，也能把不同任务隔开。碰到浏览器自动化、原生二进制、复杂语言工具链，容器通常绕不过去。
可容器对长期任务有个很实际的问题。它擅长承接一次运行，文件和中间产物却常常跟着实例走。实例销毁、迁移或更换时，系统得想办法把现场搬出去。一个任务只跑十分钟时，这些处理看着不重。任务一旦跨越多轮工具调用，还要在不同环境之间切换，问题就会不断冒出来。
我更愿意把一段 Agent 任务拆成三件事。
- 执行环境决定命令在哪里运行，能用哪些进程、网络和系统工具
- Workspace 保存这个任务处理过的文件和产物
- 调度程序根据当前步骤选择合适的后端
这三个东西分开以后，任务从轻量 Worker 转到容器时，换的是执行能力，原来的目录不用搬家。
Cloudflare 把文件系统放进 Durable Object
README 对 Cloudflare Computer 的描述很直接。它是一个运行在 Durable Object（持久对象）中的虚拟文件系统，权威状态放在 SQLite 里。
Workspace 先提供文件系统。执行后端挂在 workspace.runtime 上。项目也允许只创建 Workspace 而不注册任何后端，调用方只把它当文件系统用。
统一的执行入口如下。
|
|
调用时传入 backend。它决定 source 是 shell 命令，还是 ECMAScript 模块。这个 API 本身并不神奇，真正值得看的是职责分开了。文件在哪儿，由 Workspace 负责。命令怎么跑，交给所选后端。
README 还提到，一个 Workspace 可以用稳定 ID 注册多个后端，后端会在首次使用时连接。任务不用在创建时就押注某一种运行环境，后面的步骤可以按需要选。
三种后端，各做各的事
Cloudflare Computer 当前列出三种后端。它们服务的工作并不相同。
Container 留给真实 Linux
Container 后端会把 SQLite 中的状态投射到沙箱容器内的 FUSE 文件系统。容器侧的 computerd 守护进程负责挂载，并通过 capnweb RPC 与 Durable Object 通信。
完整 Linux 用户空间、真实二进制和网络访问，都属于这一类需求。README 中的 tutorial 做了一个具体演示。Agent 在 Workspace 里写 Markdown，容器直接对这份文件运行 pandoc，产出 PDF。文件不需要先从一个临时目录复制到容器里。
这条路有代价。容器提供了执行环境，却不负责回答 Agent 能不能访问某个域名、读取哪些文件、何时可以把结果发出去。网络出口、资源配额、密钥处理、审计和人工确认，仍得由使用它的系统自己补上。
Worker Shell 处理轻量脚本
Worker Shell 在 Dynamic Worker 中运行 just-bash。它通过 Workers RPC 直接访问 Workspace，不另存一份文件，也不多走一次同步。
整理目录、读写文本、小型构建步骤，这些任务未必需要完整容器。能在受限 shell 里完成，就没有必要为它启动更重的环境。反过来，任务真需要系统二进制和复杂依赖，硬塞进轻量 shell 只会多出兼容问题。
这里没有万能后端。任务要什么能力，系统就给到什么能力，通常更省事。
Worker JavaScript 把步骤写成模块
Worker JavaScript 会在新的 Dynamic Worker 中运行 ECMAScript 模块。README 提到结构化输入和结果、持久的相对导入、已配置的库，以及由 Workspace 支持的 node:fs/promises。
对用 JavaScript 或 TypeScript 调工具的 Agent 来说，这种形式很实用。一个步骤可以读 Workspace 里的文件，算出结构化结果，把新产物再写回去。比起把一长串 shell 字符串交给模型，它通常也更容易约束输入和输出。
分析、编辑、转换和构建，本来就不要求同一种运行能力。把它们都塞进一个大容器，或都压进一个很轻的 Worker，最后都会碰到不舒服的地方。
文件状态比一次执行更难处理
Agent 写长任务时，真正麻烦的上下文有不少落在文件系统里。源码、临时脚本、下载内容、测试报告、失败日志、生成的制品，还有一轮轮修改留下的版本，都在里面。
这些文件没有稳定归属，恢复任务时就容易犯难。日志里写着某个容器失败了，开发者仍要追问，当时输入是什么，改过哪些文件，产物有没有出来，下一次该从哪个目录继续。
Cloudflare Computer 的做法很朴素。Workspace 保存权威文件状态，容器和 Worker 只负责进去干活。这样能带来一些实际好处。
轻量 Worker 写下的内容可以交给容器继续处理，容器生成的文件也留在同一个目录。后续加一类后端时，状态保存方式不用一起推倒。出了错以后，排查至少有一个明确地点可以回去看输入、变更和产物。
持久 Workspace 也不能变成一个无限堆积的目录。谁能访问，多久过期，任务结束后删什么，敏感文件能不能留，产物能不能外发，都要写进生命周期规则。文件留得住只是开始，后面的管理同样重要。
先看能力，再挑运行环境
大多数团队不必复刻 Durable Object、FUSE 和 Dynamic Worker 这套实现。真正能拿走的是先问任务需要什么。
读写文本、生成结构化数据的步骤，可以放进受限的 JavaScript 模块或轻量环境。需要 shell 语义却用不到完整系统工具时，轻量 shell 可能够用。编译器、浏览器、原生依赖和特定网络访问出现后，再进容器或更强隔离环境。
发送邮件、写业务系统、删文件、外发数据，属于另一类问题。这些动作即使在容器里运行，也仍然要经过权限和审批规则。运行环境解决命令怎么执行，权限策略决定这条命令能不能放行，别把两件事混在一起。
任务身份和 Workspace 上下文最好贯穿所有后端。这样排查一个失败任务时，开发者看到的是同一个任务留下的现场，不是一堆彼此无关的短命实例。
Preview 阶段先别急着上生产
Cloudflare 在 README 中把边界写得很清楚。Cloudflare Computer 目前是预览版，API 不稳定，设计也可能改。docs/ 下的规范偏向未来方向，项目方还特别提醒，不能把它们当成当前代码行为的完整描述。
这类项目很适合拿来验证自己的问题。比如，一个 Agent 是否真要在几种运行环境之间切换，现有文件状态是否被某个容器绑得太死，轻量任务有没有被不必要地送进重型环境。
生产环境则得先把任务和数据的边界说清楚。谁可以创建 Workspace，哪个任务可以访问哪份文件，网络怎样出，密钥怎样注入，失败后留什么，多久清理。项目给出了一种文件系统和运行时的组合方式，这些决定仍然在使用者手里。
Cloudflare Computer 把 Agent 的“电脑”拆成了两部分。容器、shell 和 JavaScript Worker 提供不同的执行能力。Workspace 把文件和产物留在任务身边。
任务越长、后端越多，这个拆分越有用。下次设计 Agent 运行环境时，可以先问一句，命令换个地方跑以后，前面做过的事还能不能接上。
参考来源
- cloudflare/computer GitHub README 与示例
- Cloudflare Computer 的
@cloudflare/computer包说明 - Cloudflare Computer 文档目录
- BestBlogs 对 Cloudflare Computer 的收录
以上来源用于说明 Cloudflare Computer 的公开项目定位、README 中列出的架构和示例，以及选题发现背景。它们不构成对稳定性、安全性或性能表现的独立审计。项目 README 已明确标注该软件仅为预览版，生产使用前需要自行验证兼容性、隔离和权限控制。