OpenRig 快照与恢复Claude 与 Codex 恢复语义差异全解为什么刚启动不能直接快照【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址: https://gitcode.com/GitHub_Trending/op/openrigOpenRig是一个开源的多智能体编排框架让你用 YAML 定义团队把 Claude Code 与 Codex 放进同一个 Rig 统一管理。它的核心能力之一是用rig down --snapshot给整个团队拍快照、再用rig up name恢复现场。但有一个新手容易踩的坑刚rig up启动完不能立刻快照。原因是 Claude 和 Codex 两家的原生恢复resume语义不同——Codex 新会话立刻可恢复而 Claude 新会话必须完成一轮热身之后快照才是可信的。快照与恢复OpenRig 的存档读档机制OpenRig 把智能体团队的生命周期抽象成一条闭环rig up—— 按 YAML 拓扑启动整支队伍tmux 会话、harness、启动文件、就绪检查一步到位rig down --snapshot—— 停机并自动捕获完整状态快照rig up rig-name—— 按名字恢复对每个节点报告resumed / fresh / failed等逐节点结果这套机制的关键是恢复诚实性restore honestyOpenRig 不会假装恢复成功。如果某个席位其实没有恢复原生会话它会诚实地报awaiting-decision或failed而不是静默地给你一个空壳。官方架构文档 lifecycle-snapshot-restore.md 中定义了完整的恢复结果状态机resumed、rebuilt、fresh-primed、awaiting-decision、failed等 9 种节点级结果其中resume指重新接上原生会话、rebuild/fresh则是重新拉起。核心差异Claude 与 Codex 的原生恢复语义这是本文的重点。OpenRig 的官方 demoNorth Star Demo在 demo/README.md 中明确总结了在 macOS 上观察到的当前可靠规则运行时刚启动后能否立刻快照恢复说明Codex✅ 可以新会话立即可恢复Claude Code❌ 不可以rig up之后新会话不是快照安全的需要完成一轮热身对话具体差异在于Codex会话从创建那一刻起就写好了可被resume的会话标识rig up完成 →rig down --snapshot→rig up name三步之内每个 Codex 席位都能接回原对话。Claude Code新会话在没有任何一轮完成的对话之前其存储的会话 ID 还不可用于原生 resume。此时若立刻快照再恢复Claude 席位会恢复失败或退化为全新会话——你在快照前刚发生的对话实际上并没有被可靠地存进可恢复路径里。好消息是Claude 的门槛非常低只要完成一轮热身对话warmup turn当前存储的会话 ID 就变成可恢复的了。这也是为什么 OpenRig 的 demo 启动脚本run.sh在拉起拓扑后会先探测恢复基线、不满足时自动给每个 agent 喂一轮热身、然后再复测# demo/run.sh 的关键逻辑简化示意 npx tsx demo/scripts/verify-native-resume.ts --rig $RIG_ID # 探测 # 若未通过 npx tsx demo/scripts/seed-resume-baseline.ts --rig $RIG_ID --max-rounds 1 # 每 agent 一轮热身动手实践三步建立恢复基线以官方 demo 为例详见 demo/README.md 的 Resume Baseline 一节标准做法是探测 → 播种 → 复测第 1 步体检。确认 rig 各节点存活。npx tsx demo/scripts/check-demo-health.ts --rig demo-rig第 2 步探测原生恢复能力。对每个 agent 席位发起一次能否 resume的实测npx tsx demo/scripts/verify-native-resume.ts --rig demo-rig第 3 步若 Claude 席位未通过播种基线。给每个 agent 发一轮最小热身对话--max-rounds 1即只发一轮然后再次运行第 2 步的探测直到全部resumed。完成这套基线之后你再做rig down --snapshotrig restore snapshotId --rig rigId恢复报告里才会是诚实的全部 resumed。相关的探测脚本源码在 demo/scripts/verify-native-resume.ts 和 demo/scripts/resume-probe-lib.tsdemo 拓扑定义见 demo/rig.yaml文化/协作规范见 demo/culture.md。为什么 OpenRig 不直接帮 Claude 绕过去你可能会问OpenRig 是编排层为什么不自动给每个 Claude 席位补一轮热身这背后是两条设计原则恢复诚实性优先。OpenRig 的恢复流程会校验是否真的 resume 了resume 适配器会判定启动后的面板状态若启动报告是fresh且缺少快照的 resume 类型与令牌证明结果会被回滚为awaiting-decision而不是谎报resumed规则细节见 lifecycle-snapshot-restore.md 的 Restore-honesty rules 一节。运行时行为归运行时所有。会话能不能 resume 取决于 Claude Code / Codex 各自的存储与标识语义OpenRig 只是探测并如实报告把该不该热身的决策留在编排脚本demo 的run.sh层面由使用者显式执行。新手避坑清单 刚rig up完先别急着rig down --snapshot——先跑一次 resume 探测或干脆给 Claude 席位各发一轮对话。不要混用恢复方式重复测试时优先显式rig restore snapshotId --rig rigIdrig up name只在同名历史 rig 只有一个时才是安全的快捷方式否则会遇到歧义报错见 demo/README.md 的 Restore Notes。恢复后做人工验证附上 tmux 会话问一句 What were you working on?确认上下文真的接上了。想跑完整证据链直接用官方证明脚本./demo/run-proof.sh它会自动产出启动/快照/恢复各阶段的 transcript 与 JSON 证据清单见 demo/README.md 的 Full Proof Package。总结OpenRig 的快照与恢复是诚实的存档系统Codex 新会话天生可恢复Claude 新会话需要一轮热身才能进入可恢复状态。理解了这两者的原生恢复语义差异你就不会在rig up后立刻快照、恢复时发现 Claude 席位失忆。记住这个口诀——先探测再热身后快照你的多智能体团队才能真正存档读档。想动手试试克隆仓库后按 demo/README.md 的 Quick Start 执行./demo/run.sh脚本会自动帮你走完基线探测 热身播种的完整流程仓库地址https://gitcode.com/GitHub_Trending/op/openrig。【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址: https://gitcode.com/GitHub_Trending/op/openrig创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考