企业官网建设流程全解析

OpenRig rig restore 恢复指南：如何按名重启多智能体团队，5 步让每个节点结果透明可查

【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址: https://gitcode.com/GitHub_Trending/op/openrig

刚重启过电脑，昨天跑了一整晚的 Claude Code + Codex 智能体团队就断了？这正是OpenRig的rig restore命令要解决的问题。OpenRig 是一个把 Claude Code 和 Codex 组建成一个团队的多智能体（multi-agent）运行框架，你先用 YAML 定义团队，再一条命令启动整个 rig（智能体编排组）。而rig restore就是它的按名恢复能力：从快照把整个团队重新拉起来，并且逐节点汇报恢复结果——哪个节点成功、哪个失败、怎么补救，一目了然。

1 分钟理解：OpenRig 里 restore 恢复的是什么？

在 OpenRig 中，一个rig就是一个由多个"座位"（seat/node）组成的团队：每个座位跑一个 AI 编码智能体（Claude Code 或 Codex），由 tmux 会话托管。你可以参考仓库自带的演示定义，它用 YAML 描述了 lead、impl、qa、design、r1、r2 等成员及其协作关系：demo/rig.yaml。

恢复依赖两个核心概念：

• 快照（snapshot）：团队在某一时刻的状态存档，恢复的"原料"。
• 恢复尝试（restore attempt）：每次执行rig restore都会产生一个 attemptId，你可以随时查询它的进度和结果。

恢复不是"一刀切"：守护进程（daemon）会逐个节点执行恢复，最终给出restored/fresh/failed等状态，并对未成功的节点附带可操作的补救建议（recovery guidance）。这就是"每个节点结果透明可查"的由来，相关逻辑见 restore.ts。

恢复前自检：用 restore-check 确认"能不能恢复"

盲目恢复是新手最常见的坑。OpenRig 提供了rig restore-check命令，跨所有运行中的 rig 做一次恢复就绪体检，输出红绿灯式的检查项：

rig restore-check # 体检所有 rig（默认精简输出） rig restore-check --rig my-rig # 只查某一个 rig rig restore-check --full --json # 完整明细（含每个座位）

它的输出会给出四类信息，全部可读、可解释：

退出码也约定得很清楚：0= 可恢复，1= 有红色阻塞项，2= 未知/探测失败——方便脚本化。命令实现见 restore-check.ts。

💡 小技巧：如果体检提示守护进程没在运行，先执行rig daemon start再重试，输出里会直接告诉你怎么修。

五步完成按名恢复：从快照到逐节点汇报

下面是完整的rig restore恢复流程，每步一条命令。

第 1 步：列出快照，挑选恢复点

rig snapshot list my-rig

输出是一张表：ID、Kind（快照类型）、Status、创建时间。快照的创建本身很简单，例如在团队状态良好时手动打一个：rig snapshot my-rig，实现见 snapshot.ts。

第 2 步：按名执行恢复

rig restore <snapshotId> --rig my-rig

这里--rig指定的就是你在 YAML 里给团队起的名字——所谓"按名恢复"，指的就是按 rig 名称 + 快照 ID精确定位要恢复的团队。命令成功后会打印恢复尝试编号：

Restore attempt id: 12 Status: started Daemon is restoring per-node in the background; follow progress with 'rig ps --nodes' or 'rig restore-check'.

第 3 步：用rig ps --nodes跟踪逐节点进度

恢复在守护进程后台逐节点进行，rig ps --nodes的每个节点行都带有restoreOutcome（恢复结果）字段，随时刷新都能看到当前状态：ps.ts。

第 4 步：查询某次恢复尝试的"回执"

rig restore status <attemptId> --rig my-rig

它会告诉你当时选的是哪个快照、为什么选它（rationale）、初始判定（original verdict）与当前意图集判定（current intended-set verdict），以及"预期 N 个节点 / 排除历史节点 N 个 / 未解决 N 个"的明细。这是核对恢复结果最权威的一手数据。

第 5 步：处理未成功节点

对fresh或failed的节点，恢复命令会直接打印Recovery guidance（补救建议）：包括该节点的会话名、tmux 接入命令、工作目录、可复制执行的补救命令和注意事项。照着做即可把个别节点补到位，而不必重跑整个团队。

也可以在图形界面上验证：打开rig ui后在左侧 Explorer 选中你的 rig，拓扑图里每个节点都标有运行时（CLAUDE / CODEX）与状态点，点击节点的 CMUX 按钮还能直接跳进对应终端。

读懂逐节点结果：透明在哪？

一次恢复结束后，rig restore会按节点逐行打印结果，格式非常克制：

lead: restored impl: restored qa: failed — session not found

而真正"透明"的部分在恢复回执与节点明细里，每个节点最多告诉你这些事实（定义见 restore.ts）：

• status：恢复状态（restored / fresh / failed …）
• error：失败原因（仅 failed 时出现）
• canonicalSessionName：规范会话名，方便你手工定位
• tmuxAttachCommand：一键接入该节点终端的命令
• resumeCommand/recoveryGuidance：续接命令与补救建议

整体团队则汇总为rigResult：restored/partially_restored/failed/not_attempted。只要出现部分失败或整体失败，命令退出码就是 1——脚本和 CI 都能可靠地感知。

新手避坑：常见报错与处理方式

恢复被事前校验拦住时，OpenRig 会明确告诉你"尚未开始恢复"，并逐条列出阻塞项（blocker）与修复建议（remediation）：

另外注意一个诚实的细节：Ctrl-C 中断的只是 CLI 客户端，守护进程侧的恢复仍会继续。OpenRig 会直接提示你用rig ps --nodes或rig restore-check继续跟踪，而不是假装一切停止了（restore.ts）。

⚠️ 还有一个新手容易踩的坑：如果环境变量里泄漏了指向测试夹具的OPENRIG_HOME，restore-check不会误报"宿主机宕机"，而是会诚实地报告"这是泄漏的测试夹具，真实内核未被探测"，并给出清除环境变量的修复步骤（restore-check.ts）。

常见问题 FAQ

Q：恢复能完全还原智能体的对话上下文吗？A：要看快照里保存了什么。restore-check的 CONTINUITY 一栏会如实标注哪些续接能力（如 provider 会话续接、上下文窗口保留）已被验证、哪些未验证——它不做虚假承诺。

Q：部分节点失败要整个重跑吗？A：不用。每个失败节点都有独立的 recovery guidance 与接入命令，单独补齐即可；其余已restored的节点保持原样。

Q：恢复前必须做什么？A：跑一次rig restore-check。有红色阻塞项就先修（输出里附了修复命令包），全绿或仅有黄色提示时再执行rig restore。

Q：去哪里看更多示例？A：仓库的 demo/README.md 提供了可直接运行的演示 rig 与脚本；README.md 覆盖安装与首次启动（需要 Node.js 20/22/24 和 tmux）。

小结

OpenRig 的rig restore把"重启后恢复智能体团队"这件烦心事变成了一条可预期、可验证的流水线：

1. rig snapshot list—— 选对恢复点
2. rig restore <snapshotId> --rig <rigName>—— 按名发起恢复
3. rig ps --nodes—— 实时跟踪逐节点进度
4. rig restore status <attemptId>—— 核对权威回执
5. Recovery guidance —— 单独补救失败节点

配合恢复前的rig restore-check体检，整个团队在重启后的状态恢复就做到了每一步透明、每个节点可查——这正是 OpenRig 作为多智能体编排框架在可靠性上的底气所在。

【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址: https://gitcode.com/GitHub_Trending/op/openrig