企业官网建设流程全解析

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/openrig

OpenRig是一个开源的多智能体编排框架，让你用 YAML 定义团队，把 Claude Code 与 Codex 放进同一个 Rig 统一管理。它的核心能力之一是用rig down --snapshot给整个团队拍快照、再用rig up <name>恢复现场。但有一个新手容易踩的坑：刚rig up启动完，不能立刻快照。原因是 Claude 和 Codex 两家的原生"恢复（resume）语义"不同——Codex 新会话立刻可恢复，而 Claude 新会话必须完成一轮"热身"之后，快照才是可信的。

快照与恢复：OpenRig 的"存档读档"机制

OpenRig 把智能体团队的生命周期抽象成一条闭环：

1. rig up—— 按 YAML 拓扑启动整支队伍（tmux 会话、harness、启动文件、就绪检查一步到位）
2. rig down --snapshot—— 停机并自动捕获完整状态快照
3. rig up <rig-name>—— 按名字恢复，对每个节点报告resumed / fresh / failed等逐节点结果

这套机制的关键是"恢复诚实性"（restore honesty）：OpenRig 不会假装恢复成功。如果某个席位其实没有恢复原生会话，它会诚实地报awaiting-decision或failed，而不是静默地给你一个空壳。

官方架构文档 lifecycle-snapshot-restore.md 中定义了完整的恢复结果状态机（resumed、rebuilt、fresh-primed、awaiting-decision、failed等 9 种节点级结果），其中"resume"指重新接上原生会话、"rebuild/fresh"则是重新拉起。

核心差异：Claude 与 Codex 的原生恢复语义

这是本文的重点。OpenRig 的官方 demo（North Star Demo）在 demo/README.md 中明确总结了在 macOS 上观察到的"当前可靠规则"：

具体差异在于：

• 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 --snapshot+rig restore <snapshotId> --rig <rigId>，恢复报告里才会是诚实的"全部 resumed"。相关的探测脚本源码在 demo/scripts/verify-native-resume.ts 和 demo/scripts/resume-probe-lib.ts，demo 拓扑定义见 demo/rig.yaml，文化/协作规范见 demo/culture.md。

为什么 OpenRig 不直接"帮 Claude 绕过去"？

你可能会问：OpenRig 是编排层，为什么不自动给每个 Claude 席位补一轮热身？这背后是两条设计原则：

1. 恢复诚实性优先。OpenRig 的恢复流程会校验"是否真的 resume 了"：resume 适配器会判定启动后的面板状态，若启动报告是fresh且缺少快照的 resume 类型与令牌证明，结果会被回滚为awaiting-decision，而不是谎报resumed（规则细节见 lifecycle-snapshot-restore.md 的 "Restore-honesty rules" 一节）。
2. 运行时行为归运行时所有。会话能不能 resume 取决于 Claude Code / Codex 各自的存储与标识语义，OpenRig 只是探测并如实报告，把"该不该热身"的决策留在编排脚本（demo 的run.sh）层面，由使用者显式执行。

新手避坑清单 📋

• 刚rig up完，先别急着rig down --snapshot——先跑一次 resume 探测，或干脆给 Claude 席位各发一轮对话。
• 不要混用恢复方式：重复测试时优先显式rig restore <snapshotId> --rig <rigId>；rig 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