做 AI Agent 时，模型完成推理后仍要读写文件、装依赖和运行脚本。产品化后，常见方案是给每个会话分配一个容器或微虚拟机，但这会让大量空闲执行环境持续占用算力。
Cloudflare 开源的 computer 项目提出了另一种拆分：文件系统长期保留，执行环境按需创建、用完销毁。容器从每个 Agent 的标配，变成必要时才调用的临时后端。
他们为什么反对“每个 Agent 一台机器”
Cloudflare 的出发点是：全球算力不足以让每家公司、每个用户、每个 Agent 都长期拥有独立机器。Agent 工作时大量操作只是读写文件，真正需要持续保留的是文件，不是执行环境。
传统方案像是为临时工盖一间带家具的房子，人走了房子还继续计费。computer 的拆分是把文件柜留下，执行环境按需叫来，用完释放。
Workspace：持久化的文件柜
Workspace 是运行在 Durable Object 中的虚拟文件系统，状态存储在 DO 自带的 SQLite。它的 API 接近 node:fs/promises：
await ws.fs.writeFile("/notes/todo.md", "- [ ] ship it\n");
const todo = await ws.fs.readFile("/notes/todo.md");
DO 重启后文件仍然存在。也可以将 R2 作为只读挂载，向挂载点写入会返回 EROFS。Workspace 可以完全不连接执行后端，单独提供持久化草稿空间。
一个 exec，三个后端
统一入口是 workspace.runtime.exec()，具体执行 shell 还是 JavaScript，取决于后端：
- Container：完整 Linux 环境，常驻
computerd，通过 FUSE 将 SQLite 中的状态挂载为文件系统，可以运行二进制并访问网络； - Isolate shell：使用 just-bash，将 shell 命令翻译成 JavaScript，交给 Dynamic Worker 执行；
- Isolate JavaScript：直接运行 ES 模块，提供结构化输入输出和可持久化的相对导入。
三个后端读写的是同一份文件。官方建议由模型选择，只有确实需要完整 Linux 时才回退到容器。
性能短板也被公开
FUSE 挂载存在性能代价。官方 benchmark 在 Containers standard-2 实例上比较了 tmpfs、ext4 和 FUSE：元数据操作可能更快，例如删除 1000 个文件和遍历目录树；大文件顺序读写则明显变慢。
64 MiB 读取中，FUSE 约 437.5ms，磁盘约 25.6ms。安装 cloudflare/sandbox-sdk 的 854 个包、36675 个文件时，tmpfs 34.3 秒、ext4 63.9 秒、FUSE 124.7 秒。写入路径按 512 KiB 分块并哈希到内容寻址 blob store，以换取增量同步和去重。
这意味着是否能接受约 2 倍的安装耗时，取决于 Agent 的工作负载：频繁装依赖的场景会更敏感，主要读写小文件的日常开发可能更适合。
上手门槛
这是给 Cloudflare Workers 和 Durable Objects 使用的 npm 包，不是安装后直接运行的 CLI。需要注意：
- Worker 开启
nodejs_compat； - 两个 isolate 后端需要 experimental 标志和 Worker Loader 绑定；
- 容器后端需要配置镜像，并让
computerd成为 PID 1； - DO 类需要写进
new_sqlite_classes。
只要文件系统、不需要执行后端时，配置最简单，不必使用 Docker。需要执行 shell 但仍不想使用容器时，可使用 worker-shell 后端。仓库 examples/tutorial 展示了 Agent 读取网络资料、在 DO 写 Markdown，再用容器处理的完整链路。
结论
这个项目当前更适合用来理解架构思路：把 Agent 的“记忆”和“手”分开，记忆常驻且便宜，执行环境按需创建且昂贵。即使不用 Cloudflare，也可以用这个拆分重新计算自己的 Agent 成本。
官方所说让容器只占 Agent 工作量约 10% 是目标，不是已经验证的普遍结果。生产使用前应按文档和自己的负载测试，尤其关注依赖安装、大文件读写和网络访问。