Cloudflare Computer容器沙箱架构拆解FUSE computerd capnweb全景图【免费下载链接】computerGive your agent a computer 项目地址: https://gitcode.com/GitHub_Trending/computer1/computerCloudflare Computer 是一个给 AI Agent 一台真实计算机的开源项目它在 Durable Object 里用 SQLite 持久化一份虚拟文件系统再通过容器沙箱把这份文件投射成真实的 FUSE 挂载让 Agent 能像操作本地电脑一样跑 shell 与任意二进制。本文拆解这套容器沙箱架构的三大核心——FUSE 挂载机制、容器内守护进程 computerd 与双向同步的 capnweb 协议帮你看懂整张架构全景图。 图中两条黄色批注点出了关键事实容器侧是内存虚拟文件系统 FUSE 挂载而 DO 侧的SQLite 才是文件系统的唯一事实来源source of truth——容器重启也不影响数据安全。三大核心角色一分钟看懂分工角色所在位置核心职责Durable Object (DO)云端隔离运行时以 SQLite 持久化虚拟文件系统是文件状态的唯一事实来源对外提供fs读写 APIcomputerd容器内守护进程把内存 VFS 挂载为 FUSE 文件系统默认/workspace执行 shell 命令并回传输出流capnweb 通道DO ↔ 容器之间一条长连接 WebSocket承载双向增量文件同步 exec 事件流设计上一个 DO 与一个容器实例1:1 绑定WebSocket 对端唯一无歧义同步水位watermark只面向单一对方也为未来的 DO 休眠hibernation留好了门。FUSE 挂载容器如何看见同一份文件FUSEFilesystem in Userspace让 computerd 以用户态程序向 Linux 内核伪装出一个文件系统容器里的任何进程——node、shell、编译器——访问/workspace时实际读写的是 computerd 管理的内存 VFS自带 Node 的单体二进制computerd 是 Node SEA 单文件可执行程序内嵌 Node 运行时、fuse-native预编译件与libfuse镜像里无需安装 Nodeapt装个fuse3即可。路径绝对一致VFS 中的/workspace/repo/a.txt在容器进程眼中就是同一个绝对路径fsAPI、exec命令与同步协议三方对齐。没有 FUSE 也能跑FUSE_MOUNTauto会自动探测——有/dev/fuse就挂真实内核 FUSE没有常见于 CI 和普通容器则透明降级为用户态 shim把 VFS 文件实体化写到磁盘并双向轮询同步本地开发体验完全不受影响。三步启动序列启动二进制 → 轮询GET /health直至 200 → 建立 capnweb 会话。会话方向可以是 DO 直连/ws也可以是容器经POST /connect反向拨号让流量穿过 DO 可控的路由详见 docs/07_injected_service.md。computerd容器里的隐形文件管理员computerd 是一个管文件、跑命令、开接口的三合一守护进程HTTP/WS 服务面/health健康探针、/apiHTTP-batch RPC、/wsWebSocket RPC主同步载体、/__computerd/stats观测表行数、孤儿 blob 字节数、进程内存排障第一入口。写模型字节归属权在 DOFS 虚拟文件系统层computerd 内部没有逐文件暂存缓冲——create/open直接挂接写缓冲write/truncate原地修改release时单文件一个事务落盘到vfs_chunks打开窗口内的读取总能看见最新字节。源码位置packages/computerd/官方 Dockerfile 配方见 examples/container/Dockerfile。capnweb 同步协议双向增量同步如何工作两侧各维护一个单调递增的 revision 计数器DO→容器的 push 与容器→DO 的 pull 各走各的时钟谁也不需要重发整棵树Coalesce 合并两次 exec 之间同一路径被改写 5 次线上只传 1 条最终状态赢。字节不内联变更条目只带 chunk 哈希发送方先探测hasObjects只补传接收方缺失的对象——天然去重、天然省带宽。最终状态制线上只有活条目 墓碑没有 rename 之类的操作指令apply 幂等、无需按操作顺序重放崩溃中途 pull 最多重放 256 条一批。冲突处理last-writer-wins收敛树形而不纠结过程。协议细节见 docs/02_sync_protocol.md线类型定义在 packages/rpc/。一次 exec 调用的完整数据链路以workspace.runtime.exec(npm test)为例整条链路分六步Push— DO 把容器尚未见过的所有 revision 合并后推给容器Hydrate— 命令可能触碰的懒加载挂载桩lazy mount从数据源取来随批下发Exec— 命令执行FUSE 写入被容器内 VFS 实时捕获并打上新 revisionFetch— 命令返回后DO 按(rev, path)游标拉取变更流Diff— DO 对照本地vfs_blobs只 fetch 缺失的 blob chunkApply— 按 256 条一批写入 SQLite每批一个已提交事务游标按批推进。结果fs写入对exec立即可见反之亦然且全程崩溃可恢复。生命周期与休眠策略见 docs/11_lifecycle.md。性能实测FUSE 挂载快在哪、慢在哪 官方基准standard-2 容器对比 ext4 磁盘与 tmpfs结论很清晰场景computerd vs ext4 磁盘结论stat 1000 个文件0.91x✅ 快于磁盘rm 1000 个文件0.66x✅ 快于磁盘mkdir / find 万级目录树0.72x ~ 0.74x✅ 快于磁盘git init commit 100 文件0.72x✅ 快于磁盘读取 64 MiB 大文件约 20x ~ 40x❌ 明显更慢完整 npm install854 包、3.6 万文件124.7s vs 63.9s❌ 约为磁盘 2 倍一句话总结元数据密集型操作git status、模块解析、增量构建内存 inode 存储全面胜出大文件顺序 I/O 是已知代价——根源是每个 512 KiB chunk 都要做内容寻址哈希写入 blob 库。完整数字见 docs/19_performance.md。上手与源码导航 想动手跑一遍先克隆仓库git clone https://gitcode.com/GitHub_Trending/computer1/computer想了解的模块路径设计规格总览19 篇专题文档docs/SQLite 虚拟文件系统 同步构件packages/dofs/capnweb 线类型与客户端/服务端packages/rpc/computerd 守护进程FUSE RPCpackages/computerd/顶层 Workspace 包fs / runtimepackages/computer/最小可运行容器示例examples/container/总结Cloudflare Computer 用DO 侧 SQLite 事实来源 容器侧 FUSE 内存镜像 capnweb 双向增量同步三板斧把一台安全、持久、随时可重启的Agent 计算机装进了一个容器镜像。看懂这张全景图后你在读任何 sandbox 类项目时都会发现难点从来不是隔离本身而是让两侧对同一份文件保持低延迟、可恢复的一致。【免费下载链接】computerGive your agent a computer 项目地址: https://gitcode.com/GitHub_Trending/computer1/computer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cloudflare Computer容器沙箱架构拆解：FUSE + computerd + capnweb全景图
Cloudflare Computer容器沙箱架构拆解FUSE computerd capnweb全景图【免费下载链接】computerGive your agent a computer 项目地址: https://gitcode.com/GitHub_Trending/computer1/computerCloudflare Computer 是一个给 AI Agent 一台真实计算机的开源项目它在 Durable Object 里用 SQLite 持久化一份虚拟文件系统再通过容器沙箱把这份文件投射成真实的 FUSE 挂载让 Agent 能像操作本地电脑一样跑 shell 与任意二进制。本文拆解这套容器沙箱架构的三大核心——FUSE 挂载机制、容器内守护进程 computerd 与双向同步的 capnweb 协议帮你看懂整张架构全景图。 图中两条黄色批注点出了关键事实容器侧是内存虚拟文件系统 FUSE 挂载而 DO 侧的SQLite 才是文件系统的唯一事实来源source of truth——容器重启也不影响数据安全。三大核心角色一分钟看懂分工角色所在位置核心职责Durable Object (DO)云端隔离运行时以 SQLite 持久化虚拟文件系统是文件状态的唯一事实来源对外提供fs读写 APIcomputerd容器内守护进程把内存 VFS 挂载为 FUSE 文件系统默认/workspace执行 shell 命令并回传输出流capnweb 通道DO ↔ 容器之间一条长连接 WebSocket承载双向增量文件同步 exec 事件流设计上一个 DO 与一个容器实例1:1 绑定WebSocket 对端唯一无歧义同步水位watermark只面向单一对方也为未来的 DO 休眠hibernation留好了门。FUSE 挂载容器如何看见同一份文件FUSEFilesystem in Userspace让 computerd 以用户态程序向 Linux 内核伪装出一个文件系统容器里的任何进程——node、shell、编译器——访问/workspace时实际读写的是 computerd 管理的内存 VFS自带 Node 的单体二进制computerd 是 Node SEA 单文件可执行程序内嵌 Node 运行时、fuse-native预编译件与libfuse镜像里无需安装 Nodeapt装个fuse3即可。路径绝对一致VFS 中的/workspace/repo/a.txt在容器进程眼中就是同一个绝对路径fsAPI、exec命令与同步协议三方对齐。没有 FUSE 也能跑FUSE_MOUNTauto会自动探测——有/dev/fuse就挂真实内核 FUSE没有常见于 CI 和普通容器则透明降级为用户态 shim把 VFS 文件实体化写到磁盘并双向轮询同步本地开发体验完全不受影响。三步启动序列启动二进制 → 轮询GET /health直至 200 → 建立 capnweb 会话。会话方向可以是 DO 直连/ws也可以是容器经POST /connect反向拨号让流量穿过 DO 可控的路由详见 docs/07_injected_service.md。computerd容器里的隐形文件管理员computerd 是一个管文件、跑命令、开接口的三合一守护进程HTTP/WS 服务面/health健康探针、/apiHTTP-batch RPC、/wsWebSocket RPC主同步载体、/__computerd/stats观测表行数、孤儿 blob 字节数、进程内存排障第一入口。写模型字节归属权在 DOFS 虚拟文件系统层computerd 内部没有逐文件暂存缓冲——create/open直接挂接写缓冲write/truncate原地修改release时单文件一个事务落盘到vfs_chunks打开窗口内的读取总能看见最新字节。源码位置packages/computerd/官方 Dockerfile 配方见 examples/container/Dockerfile。capnweb 同步协议双向增量同步如何工作两侧各维护一个单调递增的 revision 计数器DO→容器的 push 与容器→DO 的 pull 各走各的时钟谁也不需要重发整棵树Coalesce 合并两次 exec 之间同一路径被改写 5 次线上只传 1 条最终状态赢。字节不内联变更条目只带 chunk 哈希发送方先探测hasObjects只补传接收方缺失的对象——天然去重、天然省带宽。最终状态制线上只有活条目 墓碑没有 rename 之类的操作指令apply 幂等、无需按操作顺序重放崩溃中途 pull 最多重放 256 条一批。冲突处理last-writer-wins收敛树形而不纠结过程。协议细节见 docs/02_sync_protocol.md线类型定义在 packages/rpc/。一次 exec 调用的完整数据链路以workspace.runtime.exec(npm test)为例整条链路分六步Push— DO 把容器尚未见过的所有 revision 合并后推给容器Hydrate— 命令可能触碰的懒加载挂载桩lazy mount从数据源取来随批下发Exec— 命令执行FUSE 写入被容器内 VFS 实时捕获并打上新 revisionFetch— 命令返回后DO 按(rev, path)游标拉取变更流Diff— DO 对照本地vfs_blobs只 fetch 缺失的 blob chunkApply— 按 256 条一批写入 SQLite每批一个已提交事务游标按批推进。结果fs写入对exec立即可见反之亦然且全程崩溃可恢复。生命周期与休眠策略见 docs/11_lifecycle.md。性能实测FUSE 挂载快在哪、慢在哪 官方基准standard-2 容器对比 ext4 磁盘与 tmpfs结论很清晰场景computerd vs ext4 磁盘结论stat 1000 个文件0.91x✅ 快于磁盘rm 1000 个文件0.66x✅ 快于磁盘mkdir / find 万级目录树0.72x ~ 0.74x✅ 快于磁盘git init commit 100 文件0.72x✅ 快于磁盘读取 64 MiB 大文件约 20x ~ 40x❌ 明显更慢完整 npm install854 包、3.6 万文件124.7s vs 63.9s❌ 约为磁盘 2 倍一句话总结元数据密集型操作git status、模块解析、增量构建内存 inode 存储全面胜出大文件顺序 I/O 是已知代价——根源是每个 512 KiB chunk 都要做内容寻址哈希写入 blob 库。完整数字见 docs/19_performance.md。上手与源码导航 想动手跑一遍先克隆仓库git clone https://gitcode.com/GitHub_Trending/computer1/computer想了解的模块路径设计规格总览19 篇专题文档docs/SQLite 虚拟文件系统 同步构件packages/dofs/capnweb 线类型与客户端/服务端packages/rpc/computerd 守护进程FUSE RPCpackages/computerd/顶层 Workspace 包fs / runtimepackages/computer/最小可运行容器示例examples/container/总结Cloudflare Computer 用DO 侧 SQLite 事实来源 容器侧 FUSE 内存镜像 capnweb 双向增量同步三板斧把一台安全、持久、随时可重启的Agent 计算机装进了一个容器镜像。看懂这张全景图后你在读任何 sandbox 类项目时都会发现难点从来不是隔离本身而是让两侧对同一份文件保持低延迟、可恢复的一致。【免费下载链接】computerGive your agent a computer 项目地址: https://gitcode.com/GitHub_Trending/computer1/computer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考