• 人工智能
• AI Agent
• 多智能体
• Agent 编排
• 代码智能体
• CLI

导读

OpenRig v0.5.2 是 v0.5.1 引入的"测试系统"第一次真正投入实战的版本：本窗口内的可靠性修复全部由驱动真实产品、模拟真人操作命令的场景（scenario）发现并验证。本版本的绝对头条是crash-cart 舰队恢复指挥器（fleet-restore conductor）——在守护进程（daemon）死亡时只需输入裸命令rig即可进入一个诚实可信的控制台，按一次 Enter 就能以"内核优先"的顺序恢复整个舰队、收养任何幸存的 tmux 面板且绝不覆盖它们，并以一次按键走完每个席位（seat）的精确修复路径。本文将以该发布说明为骨架，结合仓库源码逐项展开讲解各功能背后的实现机理、行为语义与兼容性边界，并如实列出官方背书记载的已知限制。

版本定位：让测试系统为自己正名

v0.5.2 的发布摘要只有一句话："Test system exercises for real; crash-cart conductor; reliability fixes"。它意味着两层事实：

1. v0.5.1 的测试系统首次产生闭环价值。v0.5.1 为产品引入了一套文本化场景（scenario）格式与执行器（runner），场景通过真人使用的同一条命令驱动真实产品端到端运行，从而在没有人工逐项检查的情况下证明产品自身行为。v0.5.2 的所有可靠性修复正是"通过这套测试系统被发现并验证"的——测试系统在第一个完整周期就证明了自身价值。
2. 单线谱系（one lineage, no divergence）：v0.5.2 完整包含 v0.5.1 的全部内容，不存在分支漂移。

在迁移层面，本版本没有新增迁移。v0.5.1 已经发布了迁移 068-071（其中 068 与 071 是一对匹配的 CREATE / DROP-IF-EXISTS，对于任何 v0.5.0→v0.5.1 升级者而言净效果为无操作），v0.5.2 停留在迁移 071。CLI 方面，相对 v0.5.1没有任何命令或 flag 被移除或重命名，API 表面完整保留。

头条：crash-cart 舰队恢复指挥器

这是 v0.5.2 的核心交付。一句话概括其体验：在守护进程已死的环境下输入裸命令rig，得到的是一个诚实的控制台，而不是一条晦涩报错或一次静默失败。

交互流程与行为承诺

发布说明给出的行为承诺可拆解为五条：

• 诚实控制台（truthful cockpit）：不再出现"cryptic error"或"silent failure"；系统明确告诉你守护进程处于何种状态。
• 一次 Enter 恢复舰队：按一次回车，恢复以kernel-first（内核优先）顺序进行——先恢复作为监督者的 kernel rig，再恢复其余 rig（v1 为顺序执行）。
• 收养幸存 tmux 面板（adopt, never clobber）：守护进程死亡但 tmux 面板存活时，指挥器会收养（adopt）这些幸存会话，绝不覆盖（clobber）它们。
• 逐席位的精确修复路径：每个需要操作员介入的席位（seat）都被给出"座位 + 精确需求"（seat + exact need）的检修行（triage row），可用一次按键逐一走完。
• 取消是诚实的（cancel is honest）：取消采用stop-before-next-rig语义——正在飞行中的 rig 会运行到它自己的结果为止，尚未开始的 rig 一律记为not_attempted（未被尝试），绝不静默丢弃。
• 破坏性恢复仅在被收养无法成功时才提供：只有收养分支确实无法达成时，才向操作员提供破坏性（快照恢复）路径。

发布说明同时记录了工程门槛：该功能经历了十个构建轮次（build rounds）、四道独立门禁（independent gates）、以及非作者执行的 QA 门测试（non-author QA door test）。

源码骨架：RestoreConductor 与四个原子构件

从源码看，该功能由 daemon 侧指挥器核心 与 CLI 侧的只读裁决命令 共同构成。

指挥器核心（Atom B）：RestoreConductor类通过依赖注入的restoreRig组合已发布的逐 rig 恢复逻辑（findLatestRestoreUsable→RestoreOrchestrator.restore），它本身不重新编写任何恢复逻辑。关键设计点：

• 最佳努力（best-effort）：单个 rig 的失败绝不会让整个舰队停下来（catch分支将结果记为failed后继续）。
• 停止语义：在每个 rig 的边界轮询isCancelled；被取消而未开始的 rig 携带reason: "cancelled before this rig started (stop-before-next-rig)"与remediation: "re-run the fleet restore to attempt this rig"。
• 进度流：每个 rig 完成即通过onRigDone回调发射结果，路由层可以据此更新一个可轮询的汇总（rollup），而无需阻塞到全部完成。

逐 rig 的闭合结果并集（closed union）：PerRigOutcome只有四个取值——fully_restored、partially_restored、failed、not_attempted。其中not_attempted是一等公民（first-class），永远不会被折叠进failed——这是"诚实"语义的代码级落点：一个指挥器没来得及处理的 rig（无可用快照，或已取消），会被如实标记并附上原因与补救方法，而不是用一个模糊的失败糊弄过去。

内核优先排序（R2）：listRigsInKernelFirstOrder从宿主上的全部非归档 rig 中挑出名称为"kernel"的 rig 置于序列首位，其余按listRigs顺序跟随；若不存在 kernel rig，则全部 rig 按原序恢复、且没有任何 rig 被标记为 kernel（诚实，绝不虚构）。

幸存面板收养分支（Amendment 2）：这一分支解决了一个表面矛盾——对于"仅守护进程崩溃、面板幸存"的场景，restore()按设计会以 409rig_not_stopped失败关闭（fail-closed），而验收要求可恢复的席位必须回到自己的面板中。解法是收养：对每个存活会话调用已发布的ClaimService.reconcileSession（即rig reconcile-session的先例）进行无启动收养（仅触碰会话状态：bindings/sessions/events，绝不触碰队列状态），然后对剩余席位调用已发布的launchNodeSubset做逐席位恢复验证。收养发现空结果（探测说活着但实际已死）时，会诚实地返回not_attempted并建议重新运行走快照恢复路径。

舰队汇总（Atom C）：aggregateFleetRollup是纯聚合——四个闭合并集键全部初始化计数，attention_required是各 rig 检修行的并集视图（a view, not a parallel record）；deriveFleetVerdict则是从计数派生的判定函数（all_fully_restored/all_failed/none_attempted/mixed），任何舰队级结论都从不落库存储，避免存储的结论与逐 rig 事实漂移。

检修行生成（R5）：attentionRowsFromNodes只对attention_required、awaiting-decision、failed三种节点生成检修行，运行中/已恢复节点被排除；对awaiting-decision节点会原样保留已发布编排器携带的精确错误与修复命令（例如具体的--fresh <logicalId>命令），绝不虚构需求。

CLI 侧：只读裁决 + 结构化 JSON

按发布说明的边界（R10/Boundaries），v1 不新增任何公开 CLI 动词——没有restore-fleet或cancel-fleet，TUI 通过 daemon 客户端直接驱动 daemon 侧的批量路由。CLI 侧的rig crash-cart --json只发射只读裁决：

• 输出一条 JSON= 三态检测器裁决（up/down/unverified）+（若 DOWN）发现信息（discovery）；即使失败关闭（fail-closed）也输出结构化 JSON，绝不只靠退出码表达。
• 退出码只是提示（state === "up" ? 0 : 1），JSON 才是契约。
• 该命令对@openrig/daemon/crash-cart窄子路径做懒加载导入（调用时才加载，rig 启动与其他动词绝不加载 daemon 模块），组合已测试的 emit/detector/read 核心。窄表面定义见 crash-cart-surface.ts，仅导出 discovery、detect、probes、emit 四组，杜绝意外公开 API。
• 探测器probeHealthz对 daemon/healthz做带超时（默认 700ms）的探测：2xx →answered，非 2xx（他方占用）→not-openrig（见 crash-cart-probes.ts）。

测试验证

仓库中对应的测试覆盖了指挥器全链路：crash-cart-conductor.test.ts（指挥器核心）、crash-cart-probes.test.ts（探测器）、crash-cart-emit.test.ts（发射）、crash-cart-load.test.ts（发现加载）、crash-cart-route.test.ts（路由）、crash-cart-readmodel.test.ts（读模型）、crash-cart-guard.test.ts（护栏）、crash-cart-copy-read.test.ts（只读复制）、crash-cart-detect.test.ts（检测）等，共同构成"十轮构建 + 四道独立门禁 + 非作者 QA"的工程证据链。

可靠性修复（经测试系统验证）

守护进程事件循环在负载下不再挂起

发布说明明确："A class of daemon event-loop freeze under load is fixed and measured"——若你的守护进程在舰队级活动下变得无响应，正是这一类问题。对应的监控与修复证据包括仓库中的event-loop-monitor、event-loop-health-server、daemon-lifecycle-event-loop.test.ts、event-loop-health-server.test.ts等测试（位于 daemon/src 与 daemon/test）。

无人值守的 Claude 席位交接

当一个 Claude 席位需要交接（compaction、会话边界、显式交接请求）时，离席席位现在自动写入 recap（纪要）并提交自己的数据包（packet），接任席位带着 recap 接手，而不是冷启动。该能力端到端经过门测试（door-proven end-to-end）。代码侧可参考 claim-service.ts（交接的会话声明逻辑）、迁移021_seat_handover_observability、060_occupant_tenures、063_occupant_generation_stamps（交接可观测性与任期数据）以及claude-resume.ts、codex-resume.ts（恢复数据包读写）等实现。

rig policy诚实处理对抗性输入

畸形或恶意的策略（policy）输入现在产生诚实的结构化错误，而不是静默失败或意外行为。该修复经历了三轮评审（three review rounds）。对应实现与验证见策略解析/校验相关模块及policy.test.ts、permission-policy-r2-adversarial.test.ts（对抗性输入测试）等。

跨主机消息携带来源机器标识

跨主机发送的消息现在包含其来源机器（machine of origin），使多主机协调在接收端可正确解读。该行为通过门测试端到端强制（enforced end-to-end via door tests）。从 v0.5.1 起该字段即为消息的一等属性（machine-of-origin on messages），v0.5.2 以门测试把"接收端可读"固化下来。相关实现可参考 daemon 侧消息路由、跨主机 HTTP 传输与cross-host-http.test.ts、cross-host-executor.test.ts等测试。

Codex 模型配置漂移检测器

新增一类此前会被悄然忽视的Codex model-config drift（模型配置漂移）检测器，落地时即捕获了真实案例（Caught real cases on landing）。结合 codex-runtime-adapter.ts 与 codex-resume.ts 等适配器实现可看到模型配置在 Codex 运行时中的读取路径；漂移检测保证席位实际运行的模型配置与预期（来自 agent spec）一致，避免"配置被悄悄改写却无人知晓"的静默故障。

测试完整性（Test-integrity）工作

本版本在测试基础设施上做了三条硬约束：

• 脏树拒绝运行：测试运行器拒绝在未提交（dirty tree）的工作区上运行——一次绿色运行意味着绿色源码，而不是"碰巧未提交的状态"。
• 封闭测试根（hermetic test roots）：测试根目录彼此隔离，避免交叉污染。
• 隔离易碎夹具（flaky fixtures isolated）：把不稳定的测试夹具单独隔离处理。

这三条与 v0.5.1 建立的"场景驱动真实产品"体系一起，构成发布流程的质量底线。

代码中的治理（Governance in code）

• 计划锁显式化：计划锁（plan locks）是在你主动请求时才选定的，而不是从环境状态（ambient state）隐式继承——杜绝"明明没锁却被当作已锁"的歧义。
• Wake 改为 opt-in：唤醒行为默认为关闭，只有明确选择才启用。

这属于产品内治理语义的收紧：把"默认继承"改为"显式选择"，使可审计性与可预测性更强。

容器 tar 文件挂起：从源头消灭

一类容器 tar 文件挂起问题**"dead by construction"——不是绕过去（worked around），而是封死了让它成为可能的那条接缝（seam）**。也就是说，修复不是打补丁，而是在结构上让该挂起类不再可能发生。相关工程背景可参考 docker/testbed（容器测试床脚手架，v0.5.1 引入、本轮继续演进）。

已知限制（5.3 backlog）

发布说明诚实记账（ledgered honestly）了下一周期要修的问题，并明确命名了尚未修复的内容：

• Reply-hint self-qualify：部分跨主机消息上的 reply-hint 以机器 ID（machine-ID）自我寻址，而非注册主机名；直接使用该 reply-hint 可能报 "no registered host X"。规避方法：从rig host list取注册主机名替换。修复排期 5.3。
• rig queue handoff --summary自相矛盾：命令发出警告，但该字段在其自身输出上却不可设置（unsettable）。修复排期 5.3。
• rig send --verify不检测 staged-unsent：对 Claude 席位的多行发送，未检测"已暂存但未发出"；多行发送可能静默暂存。修复排期 5.3。
• 全屏推销下的 Claude 转录变薄：上游全屏推销会写入"tui":"fullscreen"；一次被接受的提示就可能让整个舰队翻转（re-flip）。修复 + 固定（pin）+ 预防排期 5.3。
• 测试运行器可在未构建树上静默跳过：发布仪式已采用最终门禁规则（构建 CLI + 断言零跳过）；产品侧修复排期 5.3。
• seat-handover模型保真度的真实 Codex 端到端在 main 上同样失败（环境与产品的差异尚未根因隔离）。隔离修复排期 5.3。

另有少量内部债务项记账待维护（internal debt items ledgered for maintenance）。

行为与兼容性

• 迁移（Migrations）：本版本无新增迁移；v0.5.1 已交付 068-071（068 CREATE + 071 DROP-IF-EXISTS 成对，对 v0.5.0→v0.5.1 升级者净无操作）；v0.5.2 停留在 071。
• API 表面完整保留：相对 v0.5.1 无任何 CLI 命令或 flag 移除/重命名。
• 单线谱系：v0.5.2 完整包含 v0.5.1，无分歧。

延伸阅读

• CHANGELOG.md 中的[0.5.2]条目（含 Summary For Installing Agents：包版本自 0.5.1 提升、Node engines 不变、无新增捆绑技能）。
• 上一版本发布说明：测试系统 + 可靠性修复，是理解 v0.5.2 测试驱动方法论的上下文。
• 发布说明目录 与 发布模板：了解本仓库发布文档的格式约定。
• 核心源码：crash-cart-conductor.ts、crash-cart.ts 命令、crash-cart-surface.ts。

• 人工智能
• AI Agent
• 多智能体
• Agent 编排
• 代码智能体
• CLI