企业官网建设流程全解析

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

本篇技术指南围绕 OpenRig 的Seat Continuity and Handover（席位连续性与交接）技能展开，讲解多智能体系统中"谁坐在席位上"与"席位本身是什么"的分离设计：席位身份保持稳定，入驻者（occupant）身份流动更替，每一次更替都留下可查询的 provenance 记录。读者将掌握resume/fork/rebuild/fresh四类入驻者创建原语与 seat-binding 交接操作的关系、continuityOutcome+seatBindingOutcome双结果诚实模型、5 种失败模式的处置动作，以及rig handover/rig seat handover/rig seat status等真实 CLI 命令的完整用法，并能结合附带的学徒-继任者交接 SOP（apprentice-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）。

两组原语：入驻者创建 与 席位绑定

技能文档将相关操作严格划分为两个家族，二者职责不同、结果相互独立：

1. 入驻者创建原语（Occupant-creation primitives）——resume、fork、rebuild、fresh。它们产出"候选新入驻者"，回答的问题是："新入驻者从哪里来？"
2. 席位绑定操作（Seat-binding operations）—— handover 将候选入驻者绑定进既有拓扑中的席位，回答的问题是："稳定的席位身份发生了什么？"

需要注意文档给出的边界：设计词汇本身不构成命令，应以当前 CLI 中实际可执行的操作（executable operations）为准。例如fork可以产出一个候选入驻者，而 handover 把它绑定进既有席位——连续性结果为forked，绑定结果则独立判定。

何时使用 / 何时不使用

应当使用（Use this when）：

• 通过 rebuild、fork、fresh 或 seat-handover 替换席位的入驻者；
• 选择旧入驻者的处置方式：retire（退役）/ advise（留任顾问）/ shadow（影子并行）；
• 判断席位的世系（lineage）是否稳定或已漂移（drifted）；
• 读取或写入席位的 provenance 记录；
• 设计或审计跨入驻者变更的拓扑稳定性。

不应使用（Don't 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: failed+seatBindingOutcome: unchanged—— 新入驻者没有物化成功；席位正确地保留了旧入驻者。
• continuityOutcome: rebuilt+seatBindingOutcome: 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（席位 ID）
• old occupant id（旧入驻者 ID）
• new occupant id（新入驻者 ID）
• creation mode（resume/fork/rebuild/fresh）
• source artifacts used（使用的来源工件）
• 旧入驻者是否作为 advisor/shadow 保持存活
• 发起该动作的 operator 或 loop
• timestamp（时间戳）
• result（handed_over/partial/failed）

这份记录是系统回答"当前入驻者是怎么到这里来的"的事实源（truth-source）。没有它，控制平面只能显示当前入驻者是谁，却无法证明这次更替的合法性（legitimacy）。因此文档特别强调硬边界：如果 provenance 记录没有持久写入，就不得报告seatBindingOutcome: handed_over。

两套相互独立的状态模型

入驻者创建状态（按候选入驻者计）

1. Requested—— rebuild/fork/fresh/resume 的输入；
2. Realized—— 运行时/工件路径产出了具备 managed-seat 形态的入驻者；
3. Failed—— 候选未物化，continuityOutcome: failed。

席位绑定状态（按席位计）

1. Stable—— 当前入驻者已挂接，无进行中的绑定；
2. Binding—— handover 正在进行中；
3. Bound—— handover 成功，provenance 记录已写入；
4. Unchanged—— 绑定在完成前失败，席位保留旧入驻者。

关键推论：即使多个候选入驻者被创建又丢弃，席位依然保持在Stable状态。这正体现了"创建"与"绑定"两种状态模型的独立性。

5 种失败模式及处置动作

技能文档定义了五类必须显式处理的失败模式：

1. 候选创建失败——rebuild无法从工件合成、fork无法解析session_source、fresh无法启动。动作：绑定操作不开始；席位不变；provenance 记录候选创建失败的步骤。
2. 旧入驻者无法干净分离—— 运行时挂起（hung）、tmux 锁定等。动作：绑定中途停止；席位进入带显式 "halted" 子状态的Binding状态；告警 operator。绝不在分离未干净完成时通过重挂旧入驻者来自动回滚（auto-rollback）。
3. 绑定成功但 provenance 写入失败—— 磁盘/数据库错误。动作：在 provenance 持久化之前不视为 durable；按Binding停止处理，而非Bound。
4. 旧入驻者处置无法兑现—— operator 要求advise（保持存活作为顾问）但运行时无法保持旧入驻者存活。动作：降级为retire并显式通知；若 operator 传入了 strict-disposition 标志则直接失败。
5. 并发 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（默认）—— 启动一个全新的 Agent；
• discovered:<id>—— 采用 operator 预先准备好的候选（discovery record）；
• fork:<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，以及sourceOutcome（fork 记录forkedFrom；rebuild 记录primedArtifacts、gaps与emptyChainReason）和sideEffects（departingSessionKilled、startupContextDelivered、provenanceRecordWritten）。

一个重要的诚实性设计：handover 从不会静默完成。若来源无法继续（例如 fork 找不到可发现的 native id），会在任何变更之前诚实拒绝。帮助列表或 dry-run 的成功输出不是成功过渡的证明——必须独立读取返回的 source、continuity、binding 与 provenance 结果。

rig seat status <seat>

这是只读的可观测性表面（read-only observability surface），示例：

rig seat status spec-writer@openrig-pm rig seat status spec.writer@openrig-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 loop（RSI，recursive seat-refresh iteration）都必须能在保持拓扑稳定的前提下替换入驻者。没有这些原语，RSI 循环要么累积带后缀的席位名（世系泄漏进身份），要么在每个周期破坏拓扑引用。同时，provenance 必须既持久又可查询，RSI 循环才能判断一个席位是否足够"新鲜"（fresh）以接收新工作，还是需要重新 handover。

Managed binding 与保留历史（retained history）

一个退役顾问（retired advisor）的历史可以在没有托管节点或活跃面板的情况下继续可用。查询当前绑定与世系账本要分开进行：一个回答"谁持有席位"，另一个识别保留的历史与精确 resume token。不要因为 registry 中没有记录就推断前任不可达；也不要因为保留了一个令牌就推断 resume 成功。需要咨询时，应检查实际运行时与历史，具体可参照retiring-and-inheriting-a-seat技能。

附带的交接 SOP：Apprentice-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 客户端、快照 ID）；Phase 2 静默临时继任者（claimed/adopted会话用rig unclaim，launched会话用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_result=complete、目标节点不变、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 解冻并移交 custody；Phase 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 token）；handover 可能绑定候选却不停止在位者（须显式应用裁决处置）；reconciliation 可能建立正确的会话身份却不携带 resume token；外观正常的进程仍可能有坏的工具PATH（须从 provider 自身工具 shell 内验证）；重命名会话会让 Herder 客户端跟随退役面板（默认保留 canonical 面板）；面板输入可能可见却不在 JSONL 中（先对账持久 outbox）；reserve 消息可能以稳定席位名渲染（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 报告效果后按来源验证 READY（canonical 席位身份、当前模型、当前代次、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-fork（packages/daemon/specs/agents/shared/skills/core/session-source-fork/SKILL.md）——fork入驻者创建原语；
• agent-starters（packages/daemon/specs/agents/shared/skills/core/agent-starters/SKILL.md）—— 把入驻者创建 + 绑定组合成具名可复用的起始点；
• cross-host-rig-commands（packages/daemon/specs/agents/shared/skills/core/cross-host-rig-commands/SKILL.md）—— 远程寻址与传输，须验证目标端的生命周期支持；
• retiring-and-inheriting-a-seat（packages/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