人工智能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 仓库中 packages/daemon/assets/continuity/apprentice-cutover.md 所定义的学徒交接apprentice handover第二阶段——cutover 火堆cutover fire stack。当座位seat的上下文用量越过第二个阈值时这套栈并不自动换人而是把一次交接物化为归具名机械师named mechanic所有的指挥棒owned baton由负责人owner的一句话作为闸门由机械师按可移植 SOP 完成围栏、派生、静默、实现、提交溯源、自检 READY、解冻的机械动作并产出可审计的交接回执。读完本文你将掌握两道连续性阈值的政策落地方式、cutover 栈的六步操作清单、G0–G3 闸门收据词汇、机械师指挥棒的持有纪律以及从 prepare 到 cutover 全链路对应的源码与测试依据可直接在本仓库中核对每一处实现。一、背景为什么交接需要火堆而不是一条自动命令OpenRig 是一个把 Claude Code 与 Codex 编排进同一系统的多 Agent harness参见仓库根目录 README.md。长期运行的座位会持续积累上下文逼近上下文窗口边缘时与其让压缩compaction把 Agent 退化成冷启动的低分辨率自己不如主动、可审计地交接——这就是学徒交接政策apprentice-handover的出发点。在源码 packages/daemon/src/domain/continuity-policy-materializer.ts 中可以看到连续性政策被物化为两道阈值prepare 阈值第一阈值触发 prepare 火堆——创建一个全新、暂存、未绑定的继任者但不移动座位权柄cutover 阈值第二阈值触发 cutover 火堆——把交接变成一把归具名机械师所有的指挥棒。通知notice可以准备并证明交接但绝不自动重绑座位具名负责人的话the word of the named owner始终是闸门。从源码看该物化器对apprentice-handover政策还有一个硬性要求必须声明 mechanic。materializeContinuityPolicy中明确抛出错误——mechanic is required for apprentice-handover; declare a canonical seatrig at spec-default, profile, or member lifecycle level, then follow continuity/apprentice-cutover.md。也就是说cutover 火堆不是无人值守的后台作业而是一个具名执行者被写进政策的编排动作。对应测试 packages/daemon/test/continuity-stack-packets.test.ts 断言prepare 与 cutover 两份栈文件必须存在且 cutover 文件必须匹配/owned baton.*never auto-rebind/——owned baton 且永不自动重绑是被测试锁定的契约。两份栈文件同放在 packages/daemon/assets/continuity/ 下apprentice-prepare.md——第一阈值对应的 prepare 火堆apprentice-cutover.md——本文主角第二阈值对应的 cutover 火堆。二、cutover 火堆的六步操作清单核心骨架apprentice-cutover.md全文是一份紧凑的六步清单。其目的陈述是把第二个上下文阈值变成一把归具名机械师所有的指挥棒。通知notice可以准备并证明交接但必须永远不自动重绑座位具名负责人的话才是闸门。六步如下确认 prepare 梯级rung已在早前的评估轮中触发且继任者仍是精确被接受的历史与模型——不是近似、不是摘要、不是换个模型。对账每一笔 deposit并枚举 standing-duty 保管责任custody。deposit 集合中指名、但保管表中缺失的职责会直接叫停交接stops the cutover。这是防止一次性工作看似完成、周期性职责悄悄消失的关键闸点。记录闸门收据 G0–G3——gate、evidence 与 worder 三元组若政策声明了更简化的模型则按声明记录。创建或识别一个可追责的机械师指挥棒记录one-active-walker所有权以及 staged / submitted / consumed 三态交付边界。机械师遵循可移植 SOP详见下文第五节动作序列为fence围栏→ derive派生→ quiesce静默→ realize实现精确 token→ commit provenance提交溯源→ self-check READY自检就绪→ 收到效果回执effect receipt后才 unfreeze解冻。保留前任逐字可回拨句柄verbatim reach-back handle与预成型问题pre-formed questions并在最终回执中报告当前座位身份、当前代数generation、规范 tmux 窗格、职责接受情况以及恢复后可用的宽度usable post-restore width。从源码 packages/daemon/src/domain/continuity-stack-packets.ts 可以印证这套栈的货物结构prepare 栈要求把学徒当作对话来开启继任者在负责人之话被记录前保持无权限cutover 栈则要求拥有式指挥棒——执行随附的continuity/apprentice-cutover.md栈及其可移植 cutover SOP仅知晓不算保管awareness-only is not custody并且在交接前枚举 deposits 与 standing duties不要自动重绑机械师只按负责人的话行动。测试 continuity-stack-packets.test.ts 进一步验证了机械师指挥棒的模板必须包含staged/submitted/consumed、one-active-walker、authority-effective-at-effect-receipt、cutover SOP等字段且不包含任何rebindCall属性——从数据结构上杜绝自动重绑。三、第一阈值prepare 火堆前置上下文要理解 cutover 火堆必须先理解它准备的是什么。apprentice-prepare.md定义的第一阈值动作是在不移动座位权柄的前提下准备一个继任者。它的六步是创建一个全新、暂存、未绑定的继任者并持久化其精确的 provider 历史。在安装任何东西之前先跑模型发散闸门model-divergence gate——降级模型或复用历史会叫停整栈因为其后每一张收据都会描述错误的 occupant。安装world让继任者用自己的话陈述产品结果。安装mission包含完整任务及其指明的第一手来源。从座位链安装position并签发显式的无权限授予authority-free grant。派生继任者的 layer-5 delta独立核验然后让在任者与学徒见面开启一场基于真实工作的对话。prepare 栈的两个负载包值得注意继任者数据包携带orienting-to-an-inherited-seat技能其完整世界模型见 packages/daemon/assets/plugins/openrig-core/skills/orienting-to-an-inherited-seat/SKILL.md在任者通知则携带retiring-and-inheriting-a-seat见 packages/daemon/assets/plugins/openrig-core/skills/retiring-and-inheriting-a-seat/SKILL.md。交付状态记录为 staged、submitted、consumed 三态。prepare 栈的任何一步都不会把继任者绑定进活座位——绑定是 cutover 阶段才发生的事。四、核心纪律指挥棒永不自动重绑cutover 火堆与普通自动化最大的区别在于权限边界。在 packages/daemon/assets/plugins/openrig-core/skills/seat-continuity-and-handover/SKILL.md 中这一系列技能被总结为两组原语族Occupant 创建原语——resume、fork、rebuild、fresh回答新 occupant 从哪来座位绑定操作——handover 把候选 occupant 绑定进拓扑回答稳定座位身份发生了什么。其核心架构决策是稳定座位身份、流动 occupant 身份、显式溯源stable seat identity, fluid occupant identity, explicit provenance。不要把连续的 occupant 编码进活座位名禁止lead2/lead3这类带后缀的座位名稳定地址保持不变血缘lineage单独记录。这也直接解释了为什么 cutover 火堆要求机械师实现精确 token——任何 compact、summary、fork 或意外的陈旧历史恢复都是被禁止的。更底层的诚实模型是双结果独立性每次座位绑定操作都产生两个独立结果——continuityOutcome: rebuilt | resumed | forked | fresh | failed seatBindingOutcome: handed_over | partial | failed | unchanged这两个结果可以诚实地不一致continuityOutcome: failedseatBindingOutcome: unchanged表示新 occupant 没有成形、座位正确地保留旧 occupantcontinuityOutcome: rebuiltseatBindingOutcome: failed表示候选创建成功但绑定中途失败、溯源记录下这个缺口。cutover 火堆的每一步回执都必须能分别描述这两件事不许合并。五、可移植 SOP学徒-继任者座位交接8 阶段cutover 火堆第 5 步要求机械师遵循 packages/daemon/assets/plugins/openrig-core/skills/seat-continuity-and-handover/references/apprentice-successor-seat-cutover.md——这份 SOP 标注为2026-08-28 实战验证2026-08-30 以物理座位修正后整理。它不决定继任者是否准备好那是 desk、owner 或其他具名权威的判断机械师只负责机械动作与证明。全文分 8 个阶段必需输入先记在一根耐久指挥棒上在发生任何变更前把以下内容记录到指挥棒权威的交接指令与决策者目标 rig 与 host稳定的目标逻辑 ID、node ID、规范会话名继任者逻辑 ID、node ID、规范会话名与精确 provider resume token在任者精确 resume token所需 runtime、model、cwd、OPENRIG_HOME、OPENRIG_URL与受管 runtime 的PATH旧 occupant 处置方式含是否保持可唤醒继任者必须接受的职责保管工件或账本条目必须在换座中存活的队列行或暂存消息回执目的地。关键禁令不要从标签推断 provider token——必须从活会话记录派生并与活跃的 provider 历史文件互相印证。七大不变量稳定座位身份保持稳定继任者血缘进 provenance不进带后缀的活座位名。精确被接受的历史迁移不允许 compact、summary、fork 或意外陈旧历史恢复。从在任者的空闲确认开始直到新 occupant 通过 cutover 后自检desk 权柄保持冻结。当裁决处置为顾问储备advisory reserve时在任者以精确 token 保持可唤醒保留规范物理窗格不要求在该窗格保留在任者进程。暂存提示staged prompt不会因为在窗格里可见就耐久停窗格前必须与 outbox 或另一耐久来源对账。座位绑定、provider 历史、进程环境、队列身份、Herder 客户端挂接是五个独立表面逐个核验。超时操作状态不确定重试前先按效果读回。Phase 1围栏与预检Fence And Preflight认领耐久指挥棒请新旧 occupant 完成当前原子动作并回到空闲提示要求显式确认冻结 desk 动作、折叠、裁定、路由与面向 owner 的写入读取完整指挥棒与具名职责保管工件派生活状态rig whoami --json rig seat status target-seat --json rig ps --nodes --rig rig --json在 host 数据库中读取最新目标与继任者会话行确认精确 resume token确认两份 provider 历史文件存在且继任者文件处于活跃写入状态检查继任者窗格与耐久 outbox 中已暂存未发出的输入并逐一记录处置记录当前挂在在任者会话上的所有 Herder/tmux 客户端拍一份有边界的 rig 快照并记录其 ID。只要身份、token、模型、权柄、保管或暂存输入证据不一致立即停止。Phase 2静默临时继任者Quiesce只使用受支持的生命周期表面。正确的 detach 动词取决于会话来源claimed或adopted按 CLI 指引使用rig unclaimlaunched使用rig seat stop successor-seat此时rig unclaim会正确地拒绝。仅当确有残留受管记录需要清理时才执行rig seat clean成功停止后返回nothing_to_clean是可接受的。禁止使用rig down、kill provider、清空 provider 历史或启动一个泛化的全新 occupant。Phase 3实现精确候选Realize从精确被接受的 provider token 启动一个隔离、可发现的候选从第一个字节起就给它目标座位的规范环境OPENRIG_SESSION_NAMEtarget-session OPENRIG_NODE_IDtarget-node-id OPENRIG_RUNTIMEruntime OPENRIG_HOMEhome OPENRIG_URLurl PATHmanaged-runtime-bin:required-system-paths以精确 model、token、规范名启动 provider并且PATH必须放进 provider 进程环境本身——仅设置 tmux 会话环境不够因为中间的 login shell 可能替换它。提交前直接核验进程 argv 与环境精确 resume token、精确 model、规范--name、规范目标 node 与会话环境、从受管 runtime 路径可解析node与rig。Phase 4提交绑定Commit The Binding对发现记录运行受支持的 handoverrig seat handover target-seat \ --source discovered:discovery-id \ --reason durable-reason \ --operator operator-seat \ --json读回结果要求handover_resultcomplete目标 node 不变continuity 结果指明实际模式通常为resumedprovenance 指向前 occupant存在新的目标会话行。在提交耐久之前不要重命名窗格。Phase 5保留物理座位、对账、保留记忆规范 tmux 会话/窗口/窗格是稳定座位的组成部分当人类或 Agent 挂着客户端时不要让客户端去追一个改名后的会话。要点在原规范窗格中只停掉在任者 provider 进程tmux 会话/窗口/窗格保持原样把在任者精确 token 留在血缘账本中作为冷顾问句柄继任者被接受 token 耐久后再停掉暂存进程然后用精确 token 在原始规范窗格内以规范名、模型、cwd、环境与受管PATH恢复通过受支持座位表面对账规范目标会话并用受审计的 token 输入表面持久化精确 resume token核验规范座位恰好一个受管 occupant、旧 token 保持可唤醒、空暂存会话已被移除。注意改名在任者与暂存会话是修复性回退针对已经改了物理会话的异常运行绝不是默认交接路径。被恢复的储备可能在 argv 或环境中残留启动期规范名这不使它成为绑定座位——储备回复必须在其正文中自我围栏把拓扑绑定当作权威。Phase 6交接后自检Post-Cutover Self-Check保持权柄冻结要求新 occupant派生而非假定rig whoami --json稳定逻辑 ID、node ID、规范会话、runtime、edgesrig queue whoami规范目的地与开放行清点最新活历史文件中的活跃 provider UUID来自活 provider 记录的有效模型不只依赖 spec 钉住值职责保管工件已读且已接受交接窗口期队列行全部对账在 Agent 自己的工具 shell 中执行command -v node与command -v rig一次窄 hook/工具动作证明无启动环境故障。任一表面失败保留精确 provider UUID只修复不一致的那个表面必要时用同一历史重新启动解冻权柄前重复完整自检。Phase 7解冻与移交保管自检干净后显式解冻 desk 权柄把每一条 staged 或交接窗口期指令精确转移一次要求新 occupant 以读回核验效果通知路由负责人与在任储备交接完成让在任储备保持空闲、不压缩、无权柄。Phase 8核验 Herder 视图客户端跟随物理 tmux 会话与窗格而非逻辑绑定。默认物理座位交接应让每个已记录客户端仍挂在同一规范窗格读回挂接若修复回退已改名会话则显式重定向受影响客户端rig seat switch-client target-seat --client tty --json否则一次正确的交接也可能在网格或焦点页签上看起来错了。完成回执Completion Proof回执必须包含操作指挥棒与权柄来源快照 ID稳定与临时 node ID新旧 provider UUIDdiscovery、handover 与最终会话 ID最终进程 argv 与关键环境rig seat status结果目标与继任者库存状态队列行对账暂存输入处置与效果证明储备窗格/名/token 与围栏Herder 客户端挂接新 occupant 的自检与首次经效果核验的 desk 动作偏差、失败尝试与剩余产品缺口回执路径与 SHA-256。只有回执已存在且新 occupant 至少完成了一次经效果核验的权柄承载动作才关闭指挥棒。六、编排者角色与 G0–G3 闸门语义cutover 火堆第 3 步的闸门收据 G0–G3语义来自 packages/daemon/assets/plugins/openrig-core/skills/seat-continuity-and-handover/references/orchestrator-role.md话就是闸门the word is the gate。在具名负责人说出接受之话、且效果回执记录它之前继任者可以观察、提问、产出有界证据但不得作为稳定座位行动。G0–G3 是一套有用的回执词汇gate、evidence、worder 三元组当风险不值得凑齐四级时声明更简化的模型同样有效但缺失的记录与被刻意跳过的闸门必须可区分。测试 continuity-stack-packets.test.ts 印证了这一实现回执按[G0,G1,G2,G3].map(gate ({ gate, evidence: ..., worder: ... }))生成闸门、证据、措辞者三要素齐全。编排者底线还包括先证明全新身份与钉住模型再装上下文否则后续每张回执都在描述错误的 occupant要求继任者自己派生 layer-5 delta 并接受核验读 deposit 不等于安装它在每个边界枚举 standing-duty 保管保留前任逐字回拨句柄与预成型问题机械动作一律路由到唯一可移植 SOP避免角色本地副本漂移。编排者还在路由 cutover 前确认负责人之话、闸门回执或声明的简化模型、完整 deposits、显式职责保管、储备处置、精确继任者 token、one-active-walker 所有权并创建归属的机械师指挥棒——仅知晓不算保管。七、可选证据工具箱按风险匹配严谨度当交接代价高或难以逆转时packages/daemon/assets/plugins/openrig-core/skills/seat-continuity-and-handover/references/apprentice-evidence-toolkit.md 提供四件可选器具默认体验不是它普通学徒制仍是基于真实工作的对话Predict-sync在展示在任者答案前让继任者先用自己的话预测决策或解释组件记录首述答案再与源和在任者推理对比——用来识别背下来的模型而非学来的复述双盲检查Dual-blind checks对真正昂贵的换座把继任者回答与在任者评分标准独立封存后再比较数独立方法不数投票不用于常规或易逆转的继任仪式本身可能窄化判断旋转探针Rotated probes用覆盖不同失败方向的小型冷场景全新身份、模型发散、权柄诚实、standing-duty 保管、回拨、领域判断并轮换示例防止认出冒充理解至少一根诚实探针应奖励说出自己不知道的东西收据Receipts每项检查记录主张、证据、作者、时间与处置并写明失败本应长什么样不做事也能产出的绿结果不是证据。八、2026-08-28 实战中证实的陷阱SOP 末尾附有九条实战教训直接转化为操作纪律干跑dry-run可能接受一个受管继任者而活交接拒绝successor_already_managed——先静默临时座位泛化的 launch/restore 选择可能选到更旧的座位历史——必须启动精确被接受的 resume tokenhandover 可能绑定候选却不停掉在任者——显式应用裁决处置对账可能造出正确的会话身份却不携带 resume token——持久化并读回看起来规范的进程仍可能工具PATH损坏——从 provider 自己的工具 shell 内核验改会话名会让 Herder 客户端跟随退役窗格——默认保留物理规范窗格仅修复已改名运行时显式重定向窗格输入可见但 JSONL 里没有——停窗格前先对账耐久 outbox储备消息可能因启动环境在解绑后残留而渲染出稳定座位名——储备必须自我标识并显式围栏成功输出不是效果证明——读回队列关闭、绑定、客户端移动与已转移指令。这九条也印证了 cutover 火堆第 6 步以效果回执为解冻前提的哲学handover_resultcomplete之类的成功字符串只是过程信号效果必须通过独立表面读回。九、从火堆到产品产品化候选清单SOP 同时指出手工序列暴露了值得转正为一线产品的机会直接从已受管的继任者座位执行 handover精确 resume token 候选启动器旧 occupant 的一等advise/记忆处置原子绑定加 token 持久化提交前受管环境校验staged 输入保管报告为逻辑座位核验或修复全部 Herder 客户端挂接独立于规范座位归因的储备归因一份同时独立报告 continuity 与 seat-binding 结果的回执。这些候选与技能层 seat-continuity-and-handover/SKILL.md 中打包的rig handover seat/rig seat handover seat接受fresh、discovered:id、fork:id、rebuild来源--dry-run仅请求规划的命令面相衔接——注意帮助列表或 dry-run不是一次成功交接的证明每个返回的 source、continuity、binding、provenance 结果都必须独立解读。十、把整条链路串起来两栈一 SOP 一账本把 cutover 火堆放回 OpenRig 的连续性体系里完整链路是第一阈值→ apprentice-prepare.md 准备未绑定继任者含模型发散闸门第二阈值→ apprentice-cutover.md 把交接物化为归具名机械师所有的指挥棒机械师执行apprentice-successor-seat-cutover.md 八阶段 SOP每任任期写入座位血缘账本append-only、每任一行含启动期捕获的 harness session id 与一行墓志铭见 retiring-and-inheriting-a-seat/SKILL.md继任者以 orienting-to-an-inherited-seat/SKILL.md 的世界模型入场把数据包当作checked-not-believed的证词拒绝陈旧 ghost 提示。这条链路的策略意图在源码中表达得很清楚continuity-stack-packets.ts里 prepare 栈说把学徒当作对话开启继任者在负责人之话记录前保持无权限cutover 栈说仅知晓不算保管。cutover 火堆不是自动化换人的开关而是把一次高风险的身份迁移变成可证明、可审计、由人裁量的仪式——这正是 OpenRig稳定座位、流动 occupant、显式溯源架构在上下文墙面前的落地形态。赞分享人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载相关推荐CANN ops-transformer 中 aclnnMatmulAllReduceAddRmsNorm 融合算子接口详解与实战调用指南CANN ops transformer 中 aclnnMatmulAllReduceAddRmsNorm 融合算子接口详解与实战调用指南 本指南以 CANN人工智能AI Agent多智能体Agent 编排代码智能体CLIOpenRig 学徒交接中的 Orchestrator 角色判断边界、权威门控与交接前 READY 验证OpenRig 学徒交接中的 Orchestrator 角色判断边界、权威门控与交接前 READY 验证 在 OpenRig 的多 Agent 系统中座位人工智能AI Agent多智能体Agent 编排代码智能体CLI终极HubPress社交集成指南一键连接所有社交网络账号的完整教程终极HubPress社交集成指南一键连接所有社交网络账号的完整教程 HubPress是一个让你在GitHub上构建个人博客的强大web应用通过简单的配置就能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考