人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载OpenRig v0.3.4 是聚焦恢复 韧性recovery resilience的版本新增rig start与rig reconcile-session两个顶级命令rig up从默认 fresh 翻转成默认恢复原会话并用一套命名化的五态词表resumed/fresh-primed/awaiting-decision/attention_required/failed统一了rig up/rig restore/rig ps的座位级状态表达同时以周期性快照调度器作为崩溃保险的地板。读完本文你将掌握 v0.3.4 全部新命令的用法、五态词表的语义边界、节点级局部恢复的正确姿势以及从旧版本升级后的行为变更与停止使用的旧模式。版本定位一次以恢复路径为中心的韧性补强v0.3.4 没有引入新的 schema-bumping 迁移已有的 v0.3.3 数据库只需在新 daemon 上执行一次rig daemon start即可完成升级见 v0.3.4 发布说明。这一版的核心目标是把此前分散、容易被误解的恢复行为收敛成命名化、诚实、可审计的语义恢复入口从需要 Agent 知道 out-of-band 地去问 resume变为默认行为座位级结果从 2-3 项的折叠模型扩展为 5 个精确命名项崩溃保护从依赖事件驱动 teardown 快照升级为周期性快照作为地板一批长期存在的恢复纸面问题paper cuts在同一版本被清退。从仓库源码看这一版在 CLI 层新增了 start 命令 与 reconcile-session 命令在 daemon 层新增了 周期性快照调度器、座位注意力调和器 与 恢复计划预览 等核心模块命令实现与 daemon 路由一一对应测试覆盖也同步补齐。rig start— 一键恢复编排入口slice 01rig start是新的顶级恢复入口。它的设计哲学是只做编排不发明语义把 daemon 启动、内核就绪等待、可恢复候选清单、选择器TTY 交互或 headless 标志以及逐 rig 的恢复 调和reconcile串成一条流水线底层全部复用既有原语。rig start Interactive: daemon kernel pick-and-restore rig start --last Headless: restore all rigs that were last running rig start --all Headless: restore all rigs with restore-usable snapshots rig start --rigs name [name...] Headless: restore only the named rigs rig start --json JSON output for agents从 start.ts 的 action 实现可以看到它分五个阶段执行阶段 1确保 daemon 运行— 若 daemon 未运行先跑SystemPreflight系统预检再以解析后的配置启动 daemon阶段 2内核就绪等待— 调用waitForKernelReady(baseUrl, KERNEL_WAIT_MS)60 秒上限内核不可用则拒绝继续恢复阶段 3候选清单— 通过/api/rigs/summary列出 rig跳过kernel与running状态的 rig再逐个用POST /api/rigs/:id/up携带plan: true做只读预览来判定可恢复阶段 4选择—--all/--last直接全选--rigs names...按名字过滤并校验缺失项无标志时走 TTY 交互[Y/pick]快速默认 空格键多选选择器阶段 5逐 rig 恢复— 通过 id 化的POST /api/rigs/:id/up执行恢复并处理awaiting-decision座位的 TTY 询问或 headless 提示。源码中有两处关键注释值得注意候选预览与恢复应用都 id-grounded于/api/rigs/:id/up// Guard BLOCKING f359e3a3与// Rev1 BLOCKING b4c6ada4同名 rigsame-name rigs会作为独立候选项出现选择结果携带候选的rigId一路到底名称化的/api/up路由在恢复路径中永远不会被触及因此不存在ambiguous_name409 问题。headless 模式下若遇到awaiting-decision座位命令会输出显式提示rig up --existing rig-name --fresh logical-idTTY 交互模式下则对每个awaiting-decision座位提供[y/N]询问默认答案为 No对应defaultPromptYesNo的实现默认不 fresh-prime。rig up— 默认恢复原会话slice 02v0.3.4 最大的行为翻转rig up existing-rig现在默认恢复原会话--fresh seats...成为逐座位的显式 fresh-prime 选择operation B故意全新初始化。rig up existing-rig Resume original sessions (default) rig up --existing name --fresh dev-impl Deliberately fresh-prime dev-impl only rig up existing-rig --plan Read-only restore preview (no mutation)在 up.ts 中--fresh seats...被定义为以逻辑 id 命名的座位用全新会话代替恢复原会话operation B状态报告为 fresh-primed同时定义了可注入的promptYesNo依赖测试注入、TTY 默认走 readline用于awaiting-decision的询问流程。座位级结果对应关系原会话成功恢复的座位报告resumed通过--fresh显式选择的座位报告fresh-primeddaemon 无法恢复、操作者又未选择 fresh 的座位报告awaiting-decision——零会话启动headless 调用者会看到显式提示TTY 调用者会先收到逐座位[y/N]询问存活但卡住的座位auth 门、模型选择菜单、信任提示、卡住的恢复报告attention_required绝不静默重分类为failed只有传输层真正失败才报告failed。旧行为已消失如果你有依赖隐式 fresh 的工作流现在必须显式命名--fresh seats...。rig up --plan— 只读恢复预览slice 04rig up existing-rig --plan [--json]--plan返回恢复计划但不做任何变更每个节点的预期动作resume-original/fresh-primed/awaiting-decision、计划将消费的快照、以及变更前是否会先捕获当前状态。从 restore-plan-preview.ts 看intendedAction是三态枚举由intendedActionFor()基于活动占用者解析与是否请求 fresh 推导。计划路径带有诚实的异步超时当预览无法在时限内完成时响应会明说无法完成而不是假装给出一份干净计划。rig start的候选清单正是复用了这套预览能力来判定restore-usable因此rig start的 TTY 选择器能直接显示每个 rig 的[ready to resume]/[will ask before fresh]/[fresh start]/[mixed]就绪摘要。五态恢复状态词表slice 06rig up、rig restore、rig ps三个表面上的座位级状态字段统一为五个命名值StatusMeaningresumedOriginal session continuity proven by the native-resume probe.fresh-primedOperator opted into a deliberate fresh-prime (operation B); a brand new session started.awaiting-decisionDaemon could not resume and operator has not opted into fresh. ZERO session started.attention_requiredSeat is live or parked but needs operator action (auth, model selection, trust, stuck recovery).failedThe launch transport itself failed.awaiting-decision是新增项取代了此前零会话结果要么被误报为成功、要么被误报为失败的模糊状态attention_required覆盖更广的存活但卡住类存活或停驻parked的座位永远不会被报告为failed。在 daemon 侧restore-orchestrator.ts 的汇总逻辑同样贯彻这一语义attention_required是非终态alive but blocked它向上汇总为partially_restored而非failed。rig reconcile-session— 收养手工恢复的会话slice 03这是我在 tmux 里手工恢复了座位claude --resume id/codex resume id但 daemon 仍显示该座位 down的标准修复手段。reconcile 把活着的进程绑定回它自己的持久化节点并更新投影让rig ps/ topology /rig send/rig capture/ 队列路由重新生效。rig reconcile-session session Auto-resolve target node rig reconcile-session session --rig rigId --node logicalId Disambiguate rig reconcile-session session --no-launch Explicit (default mode) rig reconcile-session session --json JSON output for agents关键约束reconcile-session.ts绝不launch、relaunch、kill、重放启动、按恢复菜单、压缩或向 pane 输入任何内容--rig与--node必须同时提供用于消歧同 node id、不重新配 key无法证明的元数据以投影漂移projection drift清单形式如实报告会话连续性conversation continuity以状态字符串报告从不声称已被证明。命令通过POST /api/sessions/:session/reconcile调用 daemondaemon 侧的四重证据前置条件tmux 会话存在、进程谱系匹配、前台进程确为运行时、resume token 已使用、pane 可用不满足时是带缺失原因的 no-op而不是报错。rig seat clear-attention— 有审计的卡座恢复slice 10rig seat下的新子命令用于把卡在attention_required的座位证据门控、操作者作证、审计留痕地调和回readyrig seat clear-attention session rig seat clear-attention session --reason operator attestation rig seat clear-attention session --json不带--reason时清除需要 daemon 侧证据门证明座位确实回到干净状态对应 seat-attention-reconciler.ts 的SeatAttentionReconciler证据门控路径包括 tmux 存活、前台进程识别、resume token 使用、pane 可用等检查--reason text是操作者作证覆盖项审计行逐字记录该作证字符串输出形如Cleared session: from - ready (clearedBy)审计日志记录 session、from-state、门控或作证来源、操作者地址座位 node id 不变。该命令取代了此前 Agent 在座位卡住时惯用的手工改 SQLite / 假清除模式。rig launch— 节点粒度的托管式局部恢复slice 11rig launch支持在运行中的 rig 上按单座位或子集通过编排层重新启动rig launch rigId nodeRef Single seat (logical id or node id) rig launch rigId --seats a,b,c Subset (comma-separated logical ids) rig launch rigId --seats a,b --hold-reason text Reason for held non-targets rig launch rigId --seats a,b --json单目标走POST /api/rigs/:rigId/nodes/:nodeRef/launch子集走POST /api/rigs/:rigId/nodes/launch-subset部分结果绝不折叠launched、held携带held-reason、alreadyRunning已运行只报告不重拉、failedTargetsliveness unknown分别报告。这正式清退了 v0.3.x 时代的pod_aware_launch_unsupported死胡同和用 rig up 代替这一丢失逐座位控制权的变通方案。rig launch用于运行中 rig 的逐座位/逐子集重拉整 rig 恢复入口仍是rig up existing。周期性快照 — 崩溃保险的地板slice 09事件驱动快照与 teardown 快照之间若发生 daemon 崩溃会丢失任意量的生命周期状态。v0.3.4 用周期性快照调度器补上这块地板新增snapshots.periodic配置族KeyDefaultMeaningsnapshots.periodic.enabledtrueMaster switchsnapshots.periodic.interval_seconds300Snapshot interval per enabled rigsnapshots.periodic.retention_keep10Per-rigauto-periodicretention count实现上periodic-snapshot-scheduler.ts 的PeriodicSnapshotScheduler按intervalMs对每个启用的 rig 调用snapshotCapture.captureSnapshot(rigId, auto-periodic)随后用pruneSnapshotsByKind(rigId, auto-periodic, retentionKeep)按保留数剪枝。恢复选择器的关键语义见 snapshot-repository.tsauto-periodic与auto-pre-down对称竞争较新者胜出——SQL 排序为(kind IN (auto-pre-down,auto-periodic)) DESC, created_at DESC。因此 teardown 快照之后、下一次 teardown 之前的 daemon 崩溃不再损失任意量的生命周期状态。最后快照 / 地板信息在rig ps/ status 中可见操作者可一眼看到保护底线。可通过rig config set ...调优调度器在 daemon 启动时读取配置并尊重snapshots.periodic.enabled false主开关。其余恢复诚实性修复Codex Profile-V2 Preflightslice 07profile 相关启动与恢复表面上的 profile 加载检查现在会诚实地区分它看到的是哪种失败legacy-profile 检测收窄只匹配contains legacy、[profiles.name]、cannot be used while.*legacy、legacy profile selector这些 legacy 专属模式此前对failed to load configuration的泛匹配会把无效 TOML 的 stderr 也误判成 legacy 问题、给出错误的迁移提示无效 TOML 现在暴露真实解析原因最多显示 3 行 stderr例如expected newline并附带 TOML 有效性提示而不是指向[profiles.profile]的错误迁移提示。这是 preflight 判别器的分类修复auth-refusal 投影路径不变。cmux Launch Readinessslice 08cmux 启动路径不再静默产出部分工作区当 cmux 起来时只带出预期窗口/面板的子集座位会如实呈现 partial-workspace 状态并提供一键打开缺失open-missing的操作入口而不是被投影为 launched-clean。Slow Codex Resume 分类slice 13verifyResumeLaunch内部分类修正真正在恢复但速度慢的 Codex 会话此前会误走 unresolved-gate 分支被错分现在它正确走五态词表分类就绪探针确认后到达resumed。Pod-Aware Claude Resume-Selection 菜单slice 05 rev1承接 0.3.3 slice 21 FR-2ClaudeCodeAdapter.verifyResumeLaunch现在把 Claude 的恢复选择菜单当成 Codex 的 unresolved-gate 情形同等处理——在内部轮询循环和最终探针退出路径上立即返回recovery: attention_required并附上最近 12 行 pane 证据从不发送数字选择按键也绝不让循环超时退化成泛化失败。该停止使用的旧模式What to STOP Usingv0.3.4 清退了一批旧模式以下均为官方认定的替换路径STOP把rig up existing-rig当作 fresh-by-default —— 现在默认恢复原会话要故意 fresh 请用--fresh seats...operation BSTOP把卡住/停驻座位读成failed—— 存活或停驻座位是attention_required只有传输层自身失败才是failed诚实的零会话状态是awaiting-decision而非failedSTOP使用pod_aware_launch_unsupported变通方案或用rig up代替做逐座位重拉 —— 请用rig launch rigId nodeRef或rig launch rigId --seats a,bSTOP手工改 SQLite 或假清除卡住的attention_required座位 —— 请用rig seat clear-attention session证据门控或rig seat clear-attention session --reason attestation操作者作证、审计留痕STOP只依赖事件驱动或 teardown 快照做崩溃安全 —— 周期性快照调度器才是地板按需调snapshots.periodic.interval_seconds/snapshots.periodic.retention_keepSTOP把无效 TOML 归类为 legacy-profile 问题 —— Codex profile-v2 preflight 现在暴露真实 TOML 解析原因legacy 检测需要 legacy 专属模式STOP用重拉整 rig 的方式来恢复手工恢复的会话 —— 请用rig reconcile-session session --no-launch不重拉、不写输入、node id 不变STOP把部分 cmux 工作区投影为 launched-clean —— 启动就绪门会如实呈现部分状态并提供一键 open-missing 路径。操作者 / 升级说明升级已发布的 CLInpm install -g openrig/cli0.3.4 rig --version # expect 0.3.4 rig daemon stop rig daemon startv0.3.4 无新 schema 迁移snapshots.periodic.*自带默认值enabledtrue、interval_seconds300、retention_keep10操作者无需任何动作即可获得崩溃保险地板。从 npm 全新安装 v0.3.4 的操作者可立即使用全部新表面升级既有主机者走上述标准 daemon-restart 流程即可0.3.4 host-upgrade 流程被单独排期且不是全新安装获得访问权限的前提。针对性要点rig start是纯编排daemon kernel 逐 rig/api/rigs/:id/up选择器默认 TTY 交互headless 标志--last/--all/--rigs names...覆盖脚本化恢复任何隐式依赖 fresh-prime 默认行为的 Agent 或脚本现在必须显式写--fresh seats...把awaiting-decision当作 headless 场景下操作者必须决策的结果而非错误rig seat clear-attention优先走证据门控清除--reason text是审计化的操作者作证路径作证字符串原样落入审计行周期性快照可按需调优高变更 rig 把snapshots.periodic.interval_seconds调低、需要更长恢复窗口时把snapshots.periodic.retention_keep调高默认 5 分钟间隔 10 份保留是均衡的地板。已知限制与顺延Carry-forwardsrig view list/show --json标志不一致—— wrapper 层路由路径仍在daemon 的view show name路由被直接调用时能正确返回 JSON。变通方案暂时用人类可读输出wrapper 层修复是已记录的目标docs/DESIGN.mddocs-guard ledger—— 设计文档更新的 docs-guard 台账顺延对已发布的运行时表面无行为影响Slice-21 FR-1原生 Codex session-id hook构建期取证后 scope 顺延至 0.4.0自 0.3.3 顺延Slice-13 component 3auto-rollout dispatcherskill 层落地保留产品代码 dispatcher/调用有意不进入已发布运行时 bundle自 0.3.3 顺延Slice-05 子范围自 0.3.2agent / port / managed-app 冲突检测Item 4.3、安装进既有 rig 的路径验收Item 4.4、install 期 rig 名覆盖的--target-nameCLI 标志均顺延Slice-21 FR-4(d) accepted-queue-state schema自 0.3.2 推迟新的accepted队列状态仍是 schema 模型变更Onboarding journey battle-hardeningslices 04新用户旅程、08hooks-elite、10rig-self、11personal-rig顺延至后续版本——0.3.4 这一刀聚焦于恢复 韧性表面Workspace symlink 对齐daemon 侧 workspace-resolver 与操作者 symlink 工作区根目录的对齐仍是后续事项不阻塞 0.3.4Slice-13 permission-block-routing-architecture 保持 heldbig-green-light 需操作者评审把关仅rigx-experimental非 split-deferred保持 held0.3.4 host-upgrade flow heldnpm 全新安装即时可用升级既有主机走上述标准 daemon-restart 流程命名的主机升级流程单独排期。验证执行Verification Performed发布说明记录了完整的验证矩阵npm run lint与npm run build在所有工作区干净通过每个已发布 slice 的每次提交都过 TypeScript 逐文件检查每个 slice 的聚焦测试套件全绿包括Slice 01pod-aware id-grounded 预览 应用rev1 BLOCKING b4c6ada4同名消歧恢复路径永不触及/api/up--last/--all/--rigs names...headless 路径Slice 02座位级结果驱动resumed/fresh-primed/awaiting-decision逐座位 TTY[y/N]提示headless 显式提示路径Slice 03同 node id 收养手工恢复会话投影漂移报告绝不 launch、绝不写 paneSlice 04只读恢复预览诚实异步超时无变更逐节点intendedAction使用同一五态词表Slice 05 rev1ClaudeCodeAdapter.verifyResumeLaunch返回recovery: attention_required附最近 12 行证据零数字按键发送Slice 06rig up/rig restore/rig ps投影在每条代表性座位状态路径上携带命名结果Slice 07收窄的 legacy 检测正则无效 TOML stderr 暴露解析原因与 TOML 有效性提示rev1 BLOCKINGSlice 08部分工作区状态如实呈现 open-missing 入口无静默 launched-clean 投影Slice 09PeriodicSnapshotScheduler捕获 按保留数剪枝restore 选择器中auto-periodicvsauto-pre-downnewest-winssnapshots.periodic.*配置族接入 settings storeSlice 10证据门控清除--reason操作者作证覆盖审计行捕获 session / from-state / cleared-bySlice 11单座位/api/rigs/:rigId/nodes/:nodeRef/launch子集/api/rigs/:rigId/nodes/launch-subset部分结果launched / held / alreadyRunning / failedTargets绝不折叠Slice 13慢恢复 Codex 路径经五态词表分类就绪探针确认后到达resumed。此外每次合并都通过逐提交守护per-commit guard CLEAR与 velocity-qa 对抗性自用测试 双 rev1针对 0.3.4 的 VM 端到端套件全绿恢复路径rig startrig upresume-by-default rig reconcile-sessionrig seat clear-attention在真实 macOS VM 上经 vm-e2e harness 演练相对 v0.3.3 基线所有已发布 slice 零回归。提交亮点完整 v0.3.3 → v0.3.4 增量为 67 commits / 69 files / 7,193 insertions / -267 deletions按主题分组的承重提交包括恢复入口rig start一键恢复编排器slice 01rig startid-grounded 预览 应用同名 rig 不再命中ambiguous_name409slice 01 rev1 BLOCKINGrig reconcile-session收养活跃手工恢复会话slice 03默认恢复rig upresume-original-by-default--fresh seats...成为 operation B 的逐座位选择逐座位 TTY[y/N]headless 显式提示slice 02rig up --plan只读恢复预览 诚实异步超时slice 04诚实恢复词表五态词表跨rig up/rig restore/rig psslice 06pod-aware Claude 恢复选择菜单暴露attention_required而非超时slice 05 rev1 BLOCKING慢 Codex 恢复分类修复slice 13预检与就绪诚实性Codex profile-v2 preflight 收窄 legacy 检测正则、无效 TOML 暴露解析原因slice 07 rev1 BLOCKINGcmux 启动就绪——部分工作区如实呈现 一键 open-missingslice 08崩溃保险地板PeriodicSnapshotSchedulersnapshots.periodic配置族auto-periodic快照类型restore 选择器对auto-periodic/auto-pre-down对称 newest-winsrig ps呈现最后快照/地板slice 09卡座恢复rig seat clear-attention证据门控、操作者作证、审计留痕调和slice 10节点粒度托管局部恢复rig launch rigId nodeRef单座位rig launch rigId --seats a,b子集部分结果分列报告清退pod_aware_launch_unsupported死胡同slice 11。完整的 Agent 可读 changelog含快速验证命令与操作者注意事项见仓库 CHANGELOG.md。赞分享人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载相关推荐Kaniko与Kubernetes CSI快照恢复构建状态恢复Kaniko与Kubernetes CSI快照恢复构建状态恢复 痛点直击构建中断的致命影响 你是否经历过Kubernetes集群中容器镜像构建到90%时节点云原生DevOps容器OpenRig 快照-恢复-连续性机制全解析从 auto-snapshot 到 restore-check 就绪探针OpenRig 快照 恢复 连续性机制全解析从 auto snapshot 到 restore check 就绪探针 OpenRig 是一个把 Claude人工智能AI Agent多智能体Agent 编排代码智能体CLIOpenRig v0.5.8 版本深度解读选中 Rig 精确恢复、Mission 执行可见性与诚实运维护栏OpenRig v0.5.8 版本深度解读选中 Rig 精确恢复、Mission 执行可见性与诚实运维护栏 OpenRig v0.5.8 是继 0.5.7 之人工智能AI Agent多智能体Agent 编排代码智能体CLI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考