Cloudflare Computer生命周期全解DO化身、容器存活与capnweb会话的时间线【免费下载链接】computerGive your agent a computer 项目地址: https://gitcode.com/GitHub_Trending/computer1/computerCloudflare Computer开源项目 computer是为 AI Agent 打造的虚拟电脑它把虚拟文件系统放进 Durable ObjectDO给智能体一个真实的 Linux 容器、持久化 SQLite 存储层和一条 capnweb RPC 通道。新手上手时最大的疑问是DO 重启、容器死亡、capnweb 会话中断时到底会发生什么本文按时间维度梳理 DO、容器、capnweb 会话三层生命周期时间线讲清每个时刻哪些状态能存活、系统如何自动恢复。1️⃣ 三种生命周期三种时间尺度一个 Workspace 把一个 Durable Object与一个容器实例一一配对1:1 映射。两者之间只有一条长期存活的 capnweb WebSocket 会话DO 侧持有 SQLite事实源容器侧持有进程生命周期的内存镜像FUSE 挂载点通过同步协议保持一致。层级生命周期尺度状态存放重启后幸存什么Durable Object被驱逐事件分隔的多次化身SQLitectx.storage全部文件数据、同步水位线、容器运行时 UUID容器进程生命周期内存 VFS无除非已同步回 DOcapnweb 会话WebSocket 存活期纯内存无一句话记忆DO 存储是整个系统里唯一持久的东西其余一切都能从 SQLite 里的 rev 计数器水位线重建。架构总览见 docs/11_lifecycle.md。2️⃣ DO化身时间线冷启动后什么能活下来DO 的一生是一连串化身incarnation。每次 isolate 被驱逐后重新生成内存状态#handle、#shell等全部清空但以下三类状态穿越化身边界幸存SQLite 文件系统数据每个已提交的writeFile、mkdir、rm、symlink都是持久的同步水位线pushRevDO 侧成功推送到容器的最后一个修订号和 fetch cursorDO 已拉取的容器侧最后游标。它们与所描述的数据写在同一个 SQLite 事务里永远不会漂移实现在 watermarks.ts每个执行 ID 的最新容器运行时 UUID化身重建后Workspace 可凭它拒绝指向旧容器的 get/kill/dispose 调用。什么会唤醒睡着的 DO任何入站事件都能唤醒被驱逐的 DO外部fetch()调用、其他 DO 经 service binding 的调用、沙箱容器的回调如引导期的 egress 回调、alarm 触发或可休眠 WebSocket 上的入站消息。运行时不区分唤醒来源——容器发起的流量和外部流量效果相同。每次新化身都会先跑Workspace.ready()重走连接序列若容器还活着通过POST /connect/ws握手重建一条全新 capnweb 会话若容器也死了则下一轮同步从 DO 存储做rev-0 基线全量重建。3️⃣ 容器存活时间线computerd 比 DO 更长寿容器独立于 DO由 DO 通过container.start(...)启动存活期由 Cloudflare Containers 自身的生命周期策略回收。DO 重启、容器存活容器的内存 VFS、FUSE 挂载、computerd进程全部不受影响只有 DO 侧的句柄丢失。computerd是长驻进程完全可以活过多次 DO 重启——后端的Container.monitor()Promise 只在容器自身退出时才 resolve届时丢弃缓存句柄下次调用从零重建实现见 cloudflare-container.ts容器 SIGTERM / OOM容器侧内存 VFS 与 FUSE 状态全丢但 DO 的ctx.storage与 DO 实例幸存后端会失效句柄并在下一个活跃操作时自动重连两者同死宿主机 OOM、区域故障只剩ctx.storage下次连接做 rev-0 基线重建。关键不对称性容器的 VFS 是进程生命周期的内存态DO 的 VFS 是持久化 SQLite。容器重启后未同步的容器侧变更会丢失靠下一轮 push/pull 把状态带回来。4️⃣ capnweb 会话时间线出生、使用、死亡capnweb 会话比 DO 化身和容器生命周期脆弱得多——它只活到底层 WebSocket 关闭为止且自身不持有任何持久性。它只拥有四样纯内存状态导出表export ID → stub 映射、应答表等待回应的 RPC、活跃流fetchChanges、pushObjects、exec 事件流和套接字引用。会话三幕剧出生DO 侧Workspace.ready()→backend.connect()→newWebSocketRpcSession()cloudflare-container.ts使用RPC 双向流动流在单个 push/pull 轮次内打开、排空、关闭轮次之间会话空闲但套接字常开死亡WebSocket 关闭干净关闭或 RSTcapnweb 对所有挂起应答报错会话不可恢复。为什么同步撕裂不会丢数据rev 游标兜底这是设计最优雅之处——传输层虽然脆弱但上层协议定义了哪些恢复是安全的pushOncepushRev只在接收方确认成功后才写盘。撕裂的 push 让pushRev停在原值下次 push 原样重放该批次接收端applyChanges是幂等的pullOncefetch cursor 按已提交批次推进到最后一条流的(rev, path)恢复后只重取该检查点之后的条目重复部分被alreadyApplied检查丢弃exec 事件流每个事件带单调递增的seq断线后调用方可用getExec({ id, after: seq })从断点重新附着。规则总结可重放的同步操作在新会话上自动重试一次而 shell exec 这类有副作用的命令不会被盲目重放——后端直接失效句柄并报告失败把重连交给下一个显式操作。协议语义详见 docs/02_sync_protocol.mdRPC 接口定义在 interface.ts。5️⃣ 跨生命周期交互矩阵谁死了谁还能活事件DO容器capnweb 会话DO 冷启动出生按需启动新套接字上的新会话DO 重启、容器存活新化身不受影响新套接字上的新会话DO OOM被杀下次事件触发新化身不受影响死亡下次调用重建容器 SIGTERM / OOM失效句柄下次操作时重连重启内存 VFS 丢失死亡水位线对账后重建状态WebSocket 空闲断开失效并关闭句柄不受影响死亡可重放操作重连一次双死宿主故障下次事件触发新化身新容器从 DO 存储做 rev-0 基线6️⃣ 休眠路线图让空闲 DO免费睡眠docs/11_lifecycle.md 的休眠章节描述的是目标架构尚未落地切换到ctx.acceptWebSocket()休眠 API 后运行时可以在空闲期驱逐 isolate 而不关闭底层 TCP 连接流量到达即唤醒。收益是即时的——空闲 workspace 只付存储费不再为内存付费。1:1 映射让这件事大大简化ctx.getWebSockets()恰好返回一个套接字分发逻辑平凡。驱逐时需要幸存的状态通过ws.serializeAttachment()主动落盘2KB 上限导出/应答表直接丢弃、同步流无需保存游标在 SQLite、exec 流只需存{ [id]: seq }几十字节而已。⚠️ 一个容易踩的坑把拨号方向反过来让 DO 当 WS 客户端去连 computerd 的/ws会永久封死休眠——可休眠 WebSocket 只有服务端才有 API。这正是当前设计坚持DO 当 WS 服务端的原因。7️⃣ 实用清单检查你的 workspace 是否健康看同步进度调用诊断方法watermarks()查看currentRev/pushRev/fetchCursor三者不动说明线路上没有数据流动接口细节见 docs/08_capnweb_interface.md恢复中断的 exec断线后getExec({ id, after: seq })重新附着若日志已被驱逐会收到ELOG_TRUNCATED只能重启命令查 stub 泄漏设置CAPNWEB_TRACK_STUBS1computerd 会暴露GET /__computerd/stubs快照可用于验证持续负载下无无界增长记得usingWorker 侧从getWorkspace()、runtime.exec()拿到的 stub 要绑到using变量——capnweb 不垃圾回收远程 stub想跑起来试试容器示例见 examples/container/容器内跑 computerd经 capnweb 与 DO 对话不想用容器可以看 docs/12_worker_backend.md 的 Worker Shell 后端。写在最后Cloudflare Computer 的生命周期设计可以浓缩成一句话DO 的 SQLite 是唯一事实源其余一切皆为可重建的临时物。DO 化身、容器重启、capnweb 会话死亡——只要 rev 游标在位系统都会在下一轮 push/pull 中自动回到一致状态。新手基于它构建 Agent 时不必担心数据会不会丢只需要理解这三个时间尺度和各自的恢复锚点就能从容应对任何一次意外死亡。【免费下载链接】computerGive your agent a computer 项目地址: https://gitcode.com/GitHub_Trending/computer1/computer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cloudflare Computer生命周期全解：DO化身、容器存活与capnweb会话的时间线
Cloudflare Computer生命周期全解DO化身、容器存活与capnweb会话的时间线【免费下载链接】computerGive your agent a computer 项目地址: https://gitcode.com/GitHub_Trending/computer1/computerCloudflare Computer开源项目 computer是为 AI Agent 打造的虚拟电脑它把虚拟文件系统放进 Durable ObjectDO给智能体一个真实的 Linux 容器、持久化 SQLite 存储层和一条 capnweb RPC 通道。新手上手时最大的疑问是DO 重启、容器死亡、capnweb 会话中断时到底会发生什么本文按时间维度梳理 DO、容器、capnweb 会话三层生命周期时间线讲清每个时刻哪些状态能存活、系统如何自动恢复。1️⃣ 三种生命周期三种时间尺度一个 Workspace 把一个 Durable Object与一个容器实例一一配对1:1 映射。两者之间只有一条长期存活的 capnweb WebSocket 会话DO 侧持有 SQLite事实源容器侧持有进程生命周期的内存镜像FUSE 挂载点通过同步协议保持一致。层级生命周期尺度状态存放重启后幸存什么Durable Object被驱逐事件分隔的多次化身SQLitectx.storage全部文件数据、同步水位线、容器运行时 UUID容器进程生命周期内存 VFS无除非已同步回 DOcapnweb 会话WebSocket 存活期纯内存无一句话记忆DO 存储是整个系统里唯一持久的东西其余一切都能从 SQLite 里的 rev 计数器水位线重建。架构总览见 docs/11_lifecycle.md。2️⃣ DO化身时间线冷启动后什么能活下来DO 的一生是一连串化身incarnation。每次 isolate 被驱逐后重新生成内存状态#handle、#shell等全部清空但以下三类状态穿越化身边界幸存SQLite 文件系统数据每个已提交的writeFile、mkdir、rm、symlink都是持久的同步水位线pushRevDO 侧成功推送到容器的最后一个修订号和 fetch cursorDO 已拉取的容器侧最后游标。它们与所描述的数据写在同一个 SQLite 事务里永远不会漂移实现在 watermarks.ts每个执行 ID 的最新容器运行时 UUID化身重建后Workspace 可凭它拒绝指向旧容器的 get/kill/dispose 调用。什么会唤醒睡着的 DO任何入站事件都能唤醒被驱逐的 DO外部fetch()调用、其他 DO 经 service binding 的调用、沙箱容器的回调如引导期的 egress 回调、alarm 触发或可休眠 WebSocket 上的入站消息。运行时不区分唤醒来源——容器发起的流量和外部流量效果相同。每次新化身都会先跑Workspace.ready()重走连接序列若容器还活着通过POST /connect/ws握手重建一条全新 capnweb 会话若容器也死了则下一轮同步从 DO 存储做rev-0 基线全量重建。3️⃣ 容器存活时间线computerd 比 DO 更长寿容器独立于 DO由 DO 通过container.start(...)启动存活期由 Cloudflare Containers 自身的生命周期策略回收。DO 重启、容器存活容器的内存 VFS、FUSE 挂载、computerd进程全部不受影响只有 DO 侧的句柄丢失。computerd是长驻进程完全可以活过多次 DO 重启——后端的Container.monitor()Promise 只在容器自身退出时才 resolve届时丢弃缓存句柄下次调用从零重建实现见 cloudflare-container.ts容器 SIGTERM / OOM容器侧内存 VFS 与 FUSE 状态全丢但 DO 的ctx.storage与 DO 实例幸存后端会失效句柄并在下一个活跃操作时自动重连两者同死宿主机 OOM、区域故障只剩ctx.storage下次连接做 rev-0 基线重建。关键不对称性容器的 VFS 是进程生命周期的内存态DO 的 VFS 是持久化 SQLite。容器重启后未同步的容器侧变更会丢失靠下一轮 push/pull 把状态带回来。4️⃣ capnweb 会话时间线出生、使用、死亡capnweb 会话比 DO 化身和容器生命周期脆弱得多——它只活到底层 WebSocket 关闭为止且自身不持有任何持久性。它只拥有四样纯内存状态导出表export ID → stub 映射、应答表等待回应的 RPC、活跃流fetchChanges、pushObjects、exec 事件流和套接字引用。会话三幕剧出生DO 侧Workspace.ready()→backend.connect()→newWebSocketRpcSession()cloudflare-container.ts使用RPC 双向流动流在单个 push/pull 轮次内打开、排空、关闭轮次之间会话空闲但套接字常开死亡WebSocket 关闭干净关闭或 RSTcapnweb 对所有挂起应答报错会话不可恢复。为什么同步撕裂不会丢数据rev 游标兜底这是设计最优雅之处——传输层虽然脆弱但上层协议定义了哪些恢复是安全的pushOncepushRev只在接收方确认成功后才写盘。撕裂的 push 让pushRev停在原值下次 push 原样重放该批次接收端applyChanges是幂等的pullOncefetch cursor 按已提交批次推进到最后一条流的(rev, path)恢复后只重取该检查点之后的条目重复部分被alreadyApplied检查丢弃exec 事件流每个事件带单调递增的seq断线后调用方可用getExec({ id, after: seq })从断点重新附着。规则总结可重放的同步操作在新会话上自动重试一次而 shell exec 这类有副作用的命令不会被盲目重放——后端直接失效句柄并报告失败把重连交给下一个显式操作。协议语义详见 docs/02_sync_protocol.mdRPC 接口定义在 interface.ts。5️⃣ 跨生命周期交互矩阵谁死了谁还能活事件DO容器capnweb 会话DO 冷启动出生按需启动新套接字上的新会话DO 重启、容器存活新化身不受影响新套接字上的新会话DO OOM被杀下次事件触发新化身不受影响死亡下次调用重建容器 SIGTERM / OOM失效句柄下次操作时重连重启内存 VFS 丢失死亡水位线对账后重建状态WebSocket 空闲断开失效并关闭句柄不受影响死亡可重放操作重连一次双死宿主故障下次事件触发新化身新容器从 DO 存储做 rev-0 基线6️⃣ 休眠路线图让空闲 DO免费睡眠docs/11_lifecycle.md 的休眠章节描述的是目标架构尚未落地切换到ctx.acceptWebSocket()休眠 API 后运行时可以在空闲期驱逐 isolate 而不关闭底层 TCP 连接流量到达即唤醒。收益是即时的——空闲 workspace 只付存储费不再为内存付费。1:1 映射让这件事大大简化ctx.getWebSockets()恰好返回一个套接字分发逻辑平凡。驱逐时需要幸存的状态通过ws.serializeAttachment()主动落盘2KB 上限导出/应答表直接丢弃、同步流无需保存游标在 SQLite、exec 流只需存{ [id]: seq }几十字节而已。⚠️ 一个容易踩的坑把拨号方向反过来让 DO 当 WS 客户端去连 computerd 的/ws会永久封死休眠——可休眠 WebSocket 只有服务端才有 API。这正是当前设计坚持DO 当 WS 服务端的原因。7️⃣ 实用清单检查你的 workspace 是否健康看同步进度调用诊断方法watermarks()查看currentRev/pushRev/fetchCursor三者不动说明线路上没有数据流动接口细节见 docs/08_capnweb_interface.md恢复中断的 exec断线后getExec({ id, after: seq })重新附着若日志已被驱逐会收到ELOG_TRUNCATED只能重启命令查 stub 泄漏设置CAPNWEB_TRACK_STUBS1computerd 会暴露GET /__computerd/stubs快照可用于验证持续负载下无无界增长记得usingWorker 侧从getWorkspace()、runtime.exec()拿到的 stub 要绑到using变量——capnweb 不垃圾回收远程 stub想跑起来试试容器示例见 examples/container/容器内跑 computerd经 capnweb 与 DO 对话不想用容器可以看 docs/12_worker_backend.md 的 Worker Shell 后端。写在最后Cloudflare Computer 的生命周期设计可以浓缩成一句话DO 的 SQLite 是唯一事实源其余一切皆为可重建的临时物。DO 化身、容器重启、capnweb 会话死亡——只要 rev 游标在位系统都会在下一轮 push/pull 中自动回到一致状态。新手基于它构建 Agent 时不必担心数据会不会丢只需要理解这三个时间尺度和各自的恢复锚点就能从容应对任何一次意外死亡。【免费下载链接】computerGive your agent a computer 项目地址: https://gitcode.com/GitHub_Trending/computer1/computer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考