人工智能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 的Seat Continuity and Handover席位连续性与交接技能展开讲解多智能体系统中谁坐在席位上与席位本身是什么的分离设计席位身份保持稳定入驻者occupant身份流动更替每一次更替都留下可查询的 provenance 记录。读者将掌握resume/fork/rebuild/fresh四类入驻者创建原语与 seat-binding 交接操作的关系、continuityOutcomeseatBindingOutcome双结果诚实模型、5 种失败模式的处置动作以及rig handover/rig seat handover/rig seat status等真实 CLI 命令的完整用法并能结合附带的学徒-继任者交接 SOPapprentice-successor-seat-cutover执行一次经授权的席位交接。什么是席位连续性与交接OpenRig 是一个将 Claude Code 与 Codex 等 Agent 编排为同一系统的多智能体框架harness。在它的拓扑模型中席位seat是拓扑中稳定的逻辑地址而入驻者occupant是实际坐在该席位上的 Agent 会话。Seat Continuity and Handover 是一对原语家族的组合其核心设计决策可概括为三句话stable seat identity, fluid occupant identity, explicit provenance稳定的席位身份、流动的入驻者身份、显式的来源记录。这一决策的直接推论是不要把相继的入驻者编码进活跃席位名称中。也就是说禁止出现lead2/lead3这类带继任后缀的席位名——稳定地址保持稳定历代任期tenure的区别由账本ledger的代次generation与精确历史令牌exact history token来记录而不是靠重命名活跃面板pane。该技能位于packages/daemon/assets/plugins/openrig-core/skills/seat-continuity-and-handover/SKILL.md属于 openrig-core 插件中 factory-approved工厂已批准阶段的技能与retiring-and-inheriting-a-seat、session-source-fork、agent-starters、cross-host-rig-commands等技能互为兄弟sibling_skills。两组原语入驻者创建 与 席位绑定技能文档将相关操作严格划分为两个家族二者职责不同、结果相互独立入驻者创建原语Occupant-creation primitives——resume、fork、rebuild、fresh。它们产出候选新入驻者回答的问题是新入驻者从哪里来席位绑定操作Seat-binding operations—— handover 将候选入驻者绑定进既有拓扑中的席位回答的问题是稳定的席位身份发生了什么需要注意文档给出的边界设计词汇本身不构成命令应以当前 CLI 中实际可执行的操作executable operations为准。例如fork可以产出一个候选入驻者而 handover 把它绑定进既有席位——连续性结果为forked绑定结果则独立判定。何时使用 / 何时不使用应当使用Use this when通过 rebuild、fork、fresh 或 seat-handover 替换席位的入驻者选择旧入驻者的处置方式retire退役/ advise留任顾问/ shadow影子并行判断席位的世系lineage是否稳定或已漂移drifted读取或写入席位的 provenance 记录设计或审计跨入驻者变更的拓扑稳定性。不应使用Dont use this when席位是全新创建的、没有入驻者需要替换——直接用rig launch/rig expand意图是改变拓扑形状增删席位而非替换入驻者——应使用拓扑变更topology-mutation原语。双结果诚实模型continuityOutcome seatBindingOutcome这是本技能最核心的模型。每一次席位绑定操作都会产生两个相互独立的independent结果continuityOutcome: rebuilt | resumed | forked | fresh | failed seatBindingOutcome: handed_over | partial | failed | unchanged两个结果可以诚实地不一致disagree honestly。技能文档给出的两个示例continuityOutcome: failedseatBindingOutcome: unchanged—— 新入驻者没有物化成功席位正确地保留了旧入驻者。continuityOutcome: rebuiltseatBindingOutcome: failed—— 候选入驻者创建成功但绑定在途中失败provenance 记录了这一缺口gap。绝不要把这两个结果合并成一个。只有当二者被独立记录时系统才能描述实际发生的事。这一原则在 CLI 层的实现中同样可见在 packages/cli/src/commands/seat.ts 中SeatStatusResponse接口分别携带continuity_outcome、handover_result、previous_occupant、handover_at等独立字段rig seat status命令在人类可读输出中也会逐行打印Continuity outcome与Handover result互不折叠。Provenance 记录持久、可查询的事实源每一次 handover 都必须写入 provenance 记录字段包括seat id席位 IDold occupant id旧入驻者 IDnew occupant id新入驻者 IDcreation moderesume/fork/rebuild/freshsource artifacts used使用的来源工件旧入驻者是否作为 advisor/shadow 保持存活发起该动作的 operator 或 looptimestamp时间戳resulthanded_over/partial/failed这份记录是系统回答当前入驻者是怎么到这里来的的事实源truth-source。没有它控制平面只能显示当前入驻者是谁却无法证明这次更替的合法性legitimacy。因此文档特别强调硬边界如果 provenance 记录没有持久写入就不得报告seatBindingOutcome: handed_over。两套相互独立的状态模型入驻者创建状态按候选入驻者计Requested—— rebuild/fork/fresh/resume 的输入Realized—— 运行时/工件路径产出了具备 managed-seat 形态的入驻者Failed—— 候选未物化continuityOutcome: failed。席位绑定状态按席位计Stable—— 当前入驻者已挂接无进行中的绑定Binding—— handover 正在进行中Bound—— handover 成功provenance 记录已写入Unchanged—— 绑定在完成前失败席位保留旧入驻者。关键推论即使多个候选入驻者被创建又丢弃席位依然保持在Stable状态。这正体现了创建与绑定两种状态模型的独立性。5 种失败模式及处置动作技能文档定义了五类必须显式处理的失败模式候选创建失败——rebuild无法从工件合成、fork无法解析session_source、fresh无法启动。动作绑定操作不开始席位不变provenance 记录候选创建失败的步骤。旧入驻者无法干净分离—— 运行时挂起hung、tmux 锁定等。动作绑定中途停止席位进入带显式 halted 子状态的Binding状态告警 operator。绝不在分离未干净完成时通过重挂旧入驻者来自动回滚auto-rollback。绑定成功但 provenance 写入失败—— 磁盘/数据库错误。动作在 provenance 持久化之前不视为 durable按Binding停止处理而非Bound。旧入驻者处置无法兑现—— operator 要求advise保持存活作为顾问但运行时无法保持旧入驻者存活。动作降级为retire并显式通知若 operator 传入了 strict-disposition 标志则直接失败。并发 handover 竞争—— 两个操作瞄准同一席位。动作按 seat-id 锁串行化第二次尝试明确拒绝并给出清晰错误。硬边界do-not list技能文档以 verbatim 形式列出了四条不可逾越的边界不要把rebuild与seat handover合并为一个原语。设计上刻意分离以便系统能描述实际发生的事。不要引入继任后缀席位名lead2/lead3。稳定席位身份是架构目标活跃地址保持稳定退役任期由账本代次与精确历史令牌区分无需重命名活跃面板。provenance 记录未持久写入时不得报告seatBindingOutcome: handed_over。不要自动回滚半完成的 handover通过重挂旧入驻者除非分离已先干净完成。命令面rig handover 与 rig seat 家族rig handover seat与rig seat handover seat从 CLI 源码packages/cli/src/commands/seat.ts可以看到rig handover顶层动词OPR.0.4.3.04与rig seat handover共用同一个runSeatHandover动作与同一条 daemon 路由/api/seat/handover/:seat前者是为了可发现性discoverability提升到顶层。两个表面都接受以下--source取值fresh默认—— 启动一个全新的 Agentdiscovered:id—— 采用 operator 预先准备好的候选discovery recordfork:id—— 对来源会话做原生 fork继任者从第一字节起继承旧对话rebuild—— 启动全新 Agent并用席位的持久工件链durable artifact chain做 priming。完整选项如下rig handover seat \ --source fresh|discovered:id|fork:id|rebuild \ --reason reason \ --operator address \ --dry-run \ --json--reason是必填项缺失时会返回missing_reason错误并给出指引例如--reason context-wall。--dry-run只请求规划planning only不改变拓扑不带它时这些表面可以执行变更。技能文档特别提醒不要因为较短的 seat 命令rig seat handover的描述偏向规划导向Plan a safe two-phase seat handover就推断它是只读的——两者行为一致均可执行。--json供 Agent 消费结构化输出。在SeatHandoverPlan的 dry-run 响应中规划被组织为prepare与commit两个阶段phases每个阶段含步骤列表与bindingUnchangedUntilComplete标志在SeatHandoverMutationResult的实际执行响应中会返回previousOccupant、currentOccupant、previousSessionIdsSuperseded、newSessionId、discovery含 tmuxSession/tmuxPane、handoverAt、eventSeq以及sourceOutcomefork 记录forkedFromrebuild 记录primedArtifacts、gaps与emptyChainReason和sideEffectsdepartingSessionKilled、startupContextDelivered、provenanceRecordWritten。一个重要的诚实性设计handover 从不会静默完成。若来源无法继续例如 fork 找不到可发现的 native id会在任何变更之前诚实拒绝。帮助列表或 dry-run 的成功输出不是成功过渡的证明——必须独立读取返回的 source、continuity、binding 与 provenance 结果。rig seat status seat这是只读的可观测性表面read-only observability surface示例rig seat status spec-writeropenrig-pm rig seat status spec.writeropenrig-pm --json输出包含 seat ref、rig、logical ID、当前入驻者、session/startup 状态、occupant lifecycle、continuity_outcome、handover_result、previous_occupant、handover_at、restore_outcome等字段参见 packages/cli/src/commands/seat.ts 中的SeatStatusResponse。相关辅助表面rig seat switch-client seat --client tty --json—— 视图中立的重定向把已挂接的 tmux 客户端视图指回席位的 canonical session/window只改变看见什么绝不改变 routing、queue、transcript 或绑定。rig seat stop/rig seat clean/rig seat launch --fresh/rig seat set-model/rig seat set-resume-token—— 席位生命周期相关动词。其中set-resume-token只从 STDIN 读取令牌--token-stdin绝不接受 argv 位置参数以免令牌泄漏到 shell 历史与ps中且回显永远被 redact。来源支持source support由运行中的 daemon 声明并依赖真实的身份、历史与工件前置条件。跨主机场景需参考cross-host-rig-commands技能确认目标端是否支持相应生命周期操作。为什么这对 RSI递归席位刷新循环是承重设计任何递归的 seat-refresh loopRSIrecursive seat-refresh iteration都必须能在保持拓扑稳定的前提下替换入驻者。没有这些原语RSI 循环要么累积带后缀的席位名世系泄漏进身份要么在每个周期破坏拓扑引用。同时provenance 必须既持久又可查询RSI 循环才能判断一个席位是否足够新鲜fresh以接收新工作还是需要重新 handover。Managed binding 与保留历史retained history一个退役顾问retired advisor的历史可以在没有托管节点或活跃面板的情况下继续可用。查询当前绑定与世系账本要分开进行一个回答谁持有席位另一个识别保留的历史与精确 resume token。不要因为 registry 中没有记录就推断前任不可达也不要因为保留了一个令牌就推断 resume 成功。需要咨询时应检查实际运行时与历史具体可参照retiring-and-inheriting-a-seat技能。附带的交接 SOPApprentice-Successor Seat Cutover技能目录下附带三份参考文献位于packages/daemon/assets/plugins/openrig-core/skills/seat-continuity-and-handover/references/apprentice-successor-seat-cutover.md —— 可移植的机械操作 SOP该 SOP 仅供具名负责人named owner已显式授权 cutover之后使用覆盖从临时继任席位到稳定席位desk seat的机械过渡同时把在位者incumbent保留为可唤醒记忆wakeable memory。它不决定继任者是否就绪——那是 desk、owner 或其他具名权威的判断operator 只负责机制与证明。必需输入在变更前记录于一个持久的 operator baton操作接力棒上包括权威 cutover 指令与决策者、目标 rig 与 host、稳定的目标 logical ID/node ID/canonical session 名、继任者与在位者的精确 provider resume token、所需 runtime/model/cwd/OPENRIG_HOME/OPENRIG_URL/托管PATH、旧入驻者处置是否保持可唤醒、继任者须接受的 duty-custody 工件或账本条目、必须存活过切换的 queue 行或暂存消息、回执目标。绝不要从标签推断 provider token——要从活跃会话记录推导并与活跃 provider 历史文件交叉验证。7 条不变量要点稳定席位身份保持稳定、继任世系进 provenance 而非后缀名精确的已接受 provider 历史必须整体迁移不允许 compact/summary/fork/意外旧历史恢复desk 权威从在位者空闲确认起冻结直至新入驻者通过切换后自检在位者按裁决处置保持以精确令牌可唤醒保留 canonical 物理面板不要求保留该面板里的在位者进程面板里可见的暂存提示不等于持久需与 outbox 等持久源核对席位绑定、provider 历史、进程环境、queue 身份、Herder 客户端挂接是五个独立表面逐一验证超时操作是不确定indeterminate的重试前须按效果回读。8 个阶段Phase 1 围栏与预检rig whoami --json、rig seat status target-seat --json、rig ps --nodes --rig rig --json核对会话行、resume token、provider 历史文件、暂存输入、Herder 客户端、快照 IDPhase 2 静默临时继任者claimed/adopted会话用rig unclaimlaunched会话用rig seat stop禁止rig down、kill provider、清 provider 历史Phase 3 物化精确候选以精确 token 启动隔离可发现候选从第一字节起注入OPENRIG_SESSION_NAME、OPENRIG_NODE_ID、OPENRIG_RUNTIME、OPENRIG_HOME、OPENRIG_URL、PATH——PATH 必须放进 provider 进程环境本身因为仅设 tmux session 环境会被登录 shell 替换Phase 4 提交绑定rig seat handover target-seat \ --source discovered:discovery-id \ --reason durable-reason \ --operator operator-seat \ --json回读要求handover_resultcomplete、目标节点不变、continuity outcome 指向实际模式通常resumed、provenance 指向前任、存在新的目标会话行Phase 5 保留物理席位并调和对账在原始 canonical 面板中只停掉在位者进程保持 tmux session/window/pane 不变把在位者精确 token 作为 cold-advisor 句柄放进 lineage ledger用精确继任 token 在原面板恢复rig seat status核对恰好一个托管入驻者、旧 token 仍可唤醒、空 staging 会话已移除Phase 6 切换后自检新入驻者须自行推导而非假设rig whoami --json、rig queue whoami、活跃 provider UUID、有效模型、duty-custody 工件、queue 行计数、command -v node/command -v rig、一次窄 hook/tool 动作Phase 7 解冻并移交 custodyPhase 8 验证 Herder 视图客户端跟随物理 tmux 会话与面板必要时rig seat switch-client显式重定向。完成证明要求一份回执包含 operator baton 与权威来源、快照 ID、新旧 node ID 与 provider UUID、discovery/handover/最终 session ID、最终进程 argv 与关键环境、rig seat status结果、目标与继任者库存状态、queue 行对账、暂存输入处置与效果证明、reserve 面板/名/token 与围栏、Herder 客户端挂接、新入驻者自检与首批经效果验证的权威行为、偏差与失败尝试以及回执路径与 SHA-256。2026-08-28 实测中证明的陷阱要点dry-run 可能接受托管继任者而实际 handover 拒绝successor_already_managed须先静默临时席位通用 launch/restore 选择可能选中更旧的席位历史须启动精确的已接受 resume tokenhandover 可能绑定候选却不停止在位者须显式应用裁决处置reconciliation 可能建立正确的会话身份却不携带 resume token外观正常的进程仍可能有坏的工具PATH须从 provider 自身工具 shell 内验证重命名会话会让 Herder 客户端跟随退役面板默认保留 canonical 面板面板输入可能可见却不在 JSONL 中先对账持久 outboxreserve 消息可能以稳定席位名渲染boot-time 环境在解绑后仍存活reserve 须自我标识并保持围栏成功输出不是效果证明须回读 queue 关闭、绑定、客户端移动与转移指令。orchestrator-role.md —— 编排者角色契约编排者orchestrator拥有判断边界judgment boundary既不替继任者干活也不替 operator 按键。核心原则话语就是门禁the word is the gate——在具名负责人用话语表达接受、且效果回执记录该接受之前继任者只能观察、提问、产出有界证据不得以稳定席位身份行动。G0–G3 是可选的回执词汇当继承采用该模型时缺失记录与被刻意跳过的门禁必须保持可区分。文中还列出五条不变量底线在安装上下文之前证明全新身份与钉住的模型要求继任者自行推导 layer-5 delta 并被检查在每个边界枚举 standing-duty custody保留前任逐字可达句柄与预成问题机制统一路由到 cutover SOP 以免角色本地副本漂移以及路由 cutover 前须确认的清单owner 话语、门禁回执或声明的简化模型、完整 deposit、显式 duty custody、reserve 处置、精确继任 token、单活跃 walker 所有权最终只有在 operator 报告效果后按来源验证 READYcanonical 席位身份、当前模型、当前代次、canonical tmux 面板、queue 普查、duty 接受、可用宽度才解冻权威。apprentice-evidence-toolkit.md —— 可选证据工具包这是可选的证据工具包不是默认体验按代价匹配严格度只在高代价或难以逆转的继承场景中使用。包含四种装置Predict-sync在展示在位者答案前让继任者先预测/解释记录首次陈述的答案再与来源及在位者推理对比以侦测被安装的模型而非看过答案后的转述Dual-blind checks真正昂贵的过渡才使用独立封存继任者回应与在位者 rubric 再比较数独立方法而非投票Rotated probes覆盖全新身份、模型漂移、权威诚实、standing-duty custody、reach-back 与领域判断等不同失败方向的小型冷场景轮换样例以防识别替代理解并应有一条奖励继任者说出自己所不知道的的诚实探针Receipts每条被选检查记录主张、证据、作者、时间与处置并说明失败会是什么样不做该事也能产出的绿色结果不算证据须持久存储由编排者判断是否足以支撑 owner 话语门禁。与兄弟技能的协作关系session-source-forkpackages/daemon/specs/agents/shared/skills/core/session-source-fork/SKILL.md——fork入驻者创建原语agent-starterspackages/daemon/specs/agents/shared/skills/core/agent-starters/SKILL.md—— 把入驻者创建 绑定组合成具名可复用的起始点cross-host-rig-commandspackages/daemon/specs/agents/shared/skills/core/cross-host-rig-commands/SKILL.md—— 远程寻址与传输须验证目标端的生命周期支持retiring-and-inheriting-a-seatpackages/daemon/assets/plugins/openrig-core/skills/retiring-and-inheriting-a-seat/SKILL.md—— 席位退役与继承的配套技能。此外packages/daemon/test/continuity-role-guidance.test.ts对上述三份参考文献与技能主体做了契约级测试测试解析seat-continuity-and-handover/references/apprentice-successor-seat-cutover.md、orchestrator-role.md与apprentice-evidence-toolkit.md的路径与角色指引确保技能文件与其引用工件在插件打包与运行中保持一致是验证本文所述机制契约的入口。结语把诚实建模为架构Seat Continuity and Handover 的精髓在于系统不假装知道它不知道的事。通过把入驻者从哪来continuity与席位绑定发生了什么seat binding拆成两个独立结果通过强制持久化 provenance、显式列举 5 种失败模式与 4 条硬边界OpenRig 让每一次席位更替都可被描述、可被审计、可被安全地纳入递归刷新循环。无论你是要执行一次具名负责人授权的席位交接、审计某个席位的世系稳定性还是设计跨入驻者的拓扑变更流程遵循本文的双结果模型、状态机与 SOP 机械步骤就能避免继任后缀泄漏进身份与拓扑引用漂移这两类最典型的失控。赞分享人工智能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 席位继承定向与前任回询读懂 inherited seat 的世界模型与 rig ask --wake 有界咨询机制OpenRig 席位继承定向与前任回询读懂 inherited seat 的世界模型与 rig ask wake 有界咨询机制 导读 本文以 openr人工智能AI Agent多智能体Agent 编排代码智能体CLIopenrig Lore 路由机制如何用稳定地址按席位编排位置知识openrig Lore 路由机制如何用稳定地址按席位编排位置知识 Lore 是 openrig 中「位置知识」的承载约定某个持久席位seat在真实工作人工智能AI Agent多智能体Agent 编排代码智能体CLIGutenberg ColorPicker 组件完全指南基于 react-colorful 的视觉取色与 RGB(A)/HSL(A)/Hex(8) 精确编辑Gutenberg ColorPicker 组件完全指南基于 react colorful 的视觉取色与 RGB A /HSL A /Hex 8 精确编辑 导人工智能AI Agent多智能体Agent 编排代码智能体CLI上一篇GitHub Readme Streak Stats动画性能优化减少CPU占用的技巧下一篇Navicat激活总失败用navicat-keygen-tools离线激活3步拿到序列号和激活码创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考