OpenRig 学徒交接（Apprentice Cutover）火堆：把第二个上下文阈值变成归具名技工所有的交接指挥棒

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

本文聚焦 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 seat@rig 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）可以准备并证明交接，但必须永远不自动重绑座位；具名负责人的话才是闸门。六步如下：

1. 确认 prepare 梯级（rung）已在早前的评估轮中触发，且继任者仍是精确被接受的历史与模型——不是近似、不是摘要、不是换个模型。
2. 对账每一笔 deposit，并枚举 standing-duty 保管责任（custody）。deposit 集合中指名、但保管表中缺失的职责，会直接叫停交接（stops the cutover）。这是防止"一次性工作看似完成、周期性职责悄悄消失"的关键闸点。
3. 记录闸门收据 G0–G3——gate、evidence 与 worder 三元组；若政策声明了更简化的模型，则按声明记录。
4. 创建或识别一个可追责的机械师指挥棒，记录"one-active-walker"所有权，以及 staged / submitted / consumed 三态交付边界。
5. 机械师遵循可移植 SOP（详见下文第五节），动作序列为：fence（围栏）→ derive（派生）→ quiesce（静默）→ realize（实现精确 token）→ commit provenance（提交溯源）→ self-check READY（自检就绪）→ 收到效果回执（effect receipt）后才 unfreeze（解冻）。
6. 保留前任逐字可回拨句柄（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定义的第一阈值动作是：在不移动座位权柄的前提下，准备一个继任者。它的六步是：

1. 创建一个全新、暂存、未绑定的继任者，并持久化其精确的 provider 历史。
2. 在安装任何东西之前先跑模型发散闸门（model-divergence gate）——降级模型或复用历史会叫停整栈，因为其后每一张收据都会描述错误的 occupant。
3. 安装world，让继任者用自己的话陈述产品结果。
4. 安装mission，包含完整任务及其指明的第一手来源。
5. 从座位链安装position，并签发显式的无权限授予（authority-free grant）。
6. 派生继任者的 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 中，这一系列技能被总结为两组原语族：

1. Occupant 创建原语——resume、fork、rebuild、fresh，回答"新 occupant 从哪来"；
2. 座位绑定操作——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: failed+seatBindingOutcome: unchanged表示新 occupant 没有成形、座位正确地保留旧 occupant；continuityOutcome: rebuilt+seatBindingOutcome: 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 历史文件互相印证。

七大不变量

1. 稳定座位身份保持稳定；继任者血缘进 provenance，不进带后缀的活座位名。
2. 精确被接受的历史迁移；不允许 compact、summary、fork 或意外陈旧历史恢复。
3. 从在任者的空闲确认开始，直到新 occupant 通过 cutover 后自检，desk 权柄保持冻结。
4. 当裁决处置为"顾问储备（advisory reserve）"时，在任者以精确 token 保持可唤醒；保留规范物理窗格不要求在该窗格保留在任者进程。
5. 暂存提示（staged prompt）不会因为"在窗格里可见"就耐久；停窗格前必须与 outbox 或另一耐久来源对账。
6. 座位绑定、provider 历史、进程环境、队列身份、Herder 客户端挂接是五个独立表面，逐个核验。
7. 超时操作状态不确定；重试前先按效果读回。

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 unclaim；
• launched：使用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_NAME=<target-session> OPENRIG_NODE_ID=<target-node-id> OPENRIG_RUNTIME=<runtime> OPENRIG_HOME=<home> OPENRIG_URL=<url> PATH=<managed-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）

对发现记录运行受支持的 handover：

rig seat handover <target-seat> \ --source discovered:<discovery-id> \ --reason <durable-reason> \ --operator <operator-seat> \ --json

读回结果，要求：handover_result=complete；目标 node 不变；continuity 结果指明实际模式（通常为resumed）；provenance 指向前 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派生而非假定：

1. rig whoami --json：稳定逻辑 ID、node ID、规范会话、runtime、edges；
2. rig queue whoami：规范目的地与开放行清点；
3. 最新活历史文件中的活跃 provider UUID；
4. 来自活 provider 记录的有效模型（不只依赖 spec 钉住值）；
5. 职责保管工件已读且已接受；
6. 交接窗口期队列行全部对账；
7. 在 Agent 自己的工具 shell 中执行command -v node与command -v rig；
8. 一次窄 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 UUID；discovery、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 token；
• handover 可能绑定候选却不停掉在任者——显式应用裁决处置；
• 对账可能造出正确的会话身份却不携带 resume token——持久化并读回；
• 看起来规范的进程仍可能工具PATH损坏——从 provider 自己的工具 shell 内核验；
• 改会话名会让 Herder 客户端跟随退役窗格——默认保留物理规范窗格，仅修复已改名运行时显式重定向；
• 窗格输入可见但 JSONL 里没有——停窗格前先对账耐久 outbox；
• 储备消息可能因启动环境在解绑后残留而渲染出稳定座位名——储备必须自我标识并显式围栏；
• 成功输出不是效果证明——读回队列关闭、绑定、客户端移动与已转移指令。

这九条也印证了 cutover 火堆第 6 步"以效果回执为解冻前提"的哲学：handover_result=complete之类的成功字符串只是过程信号，效果必须通过独立表面读回。

九、从火堆到产品：产品化候选清单

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 的连续性体系里，完整链路是：

1. 第一阈值→ apprentice-prepare.md 准备未绑定继任者（含模型发散闸门）；
2. 第二阈值→ apprentice-cutover.md 把交接物化为归具名机械师所有的指挥棒；
3. 机械师执行apprentice-successor-seat-cutover.md 八阶段 SOP；
4. 每任任期写入座位血缘账本（append-only、每任一行，含启动期捕获的 harness session id 与一行墓志铭），见 retiring-and-inheriting-a-seat/SKILL.md；
5. 继任者以 orienting-to-an-inherited-seat/SKILL.md 的世界模型入场，把数据包当作"checked-not-believed"的证词，拒绝陈旧 ghost 提示。

这条链路的策略意图在源码中表达得很清楚：continuity-stack-packets.ts里 prepare 栈说"把学徒当作对话开启，继任者在负责人之话记录前保持无权限"，cutover 栈说"仅知晓不算保管"。cutover 火堆不是自动化换人的开关，而是把一次高风险的身份迁移变成可证明、可审计、由人裁量的仪式——这正是 OpenRig"稳定座位、流动 occupant、显式溯源"架构在上下文墙面前的落地形态。

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