人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载导读session_source是 OpenRig 中成员级member-level的会话连续性声明字段它决定一个新启动的托管 Seatmanaged seat如何从先前的一次原生运行时会话Claude Code 会话或 Codex 线程中派生初始上下文。v1 支持唯一的模式fork——基于先前的native_id启动一个全新的 Seat而不是声称原 Seat 被延续。本文以 session-source-fork/SKILL.md 为骨架结合仓库源码rigspec-schema.ts、rigspec-codec.ts、types.ts、claude-code-adapter.ts等展开帮助你掌握session_source的 YAML 写法、schema 校验规则、运行时命令形态、状态机与失败模式以及如何正确区分fork/rebuild/resume/fresh四种连续性语义。session_source 是什么一个“成员级”的启动时输入session_source不是一个新的顶层命令也不是一个长期存活的状态字段。它是一个launch-time input启动时输入声明于成员配置或rig expand载荷中在启动时被解析并实现随后便成为历史。members: - id: reviewer-2 runtime: claude-code # 或 codexterminal 上不合法 agent_ref: specs/agents/reviewer.yaml profile: reviewer cwd: . session_source: mode: fork ref: kind: native_id # v1 fork 模式仅支持 native_id value: 0b0165d7-cb4d-4650-90de-15c0a1ede9e6Schema 是运行时无关的rigspec-schema.ts负责统一的语法校验而实现是运行时特定的Claude 与 Codex 各自拥有原生 fork 命令。该字段与starter_ref、restore_policy、compaction_strategy等一同被收录在成员合法键集合MEMBER_KEYS中见 rigspec-schema.ts。何时使用 / 何时禁用使用场景编写一个应从先前会话 fork 的 rig spec 成员编写携带session_source的rig expand载荷动态添加成员时同样可以携带会话来源归属为某个新 Seat 决策究竟该用fork/rebuild/resume/fresh组合“fork handoverseat-handover-over-fork”详见seat-continuity-and-handoverskill。禁用场景Restore 而不是创建restore 延续的是一个已存在的受管 Seatfork 创建的是一个新 Seat。二者语义截然不同连续性属于artifact-backed mental-model rebuild由 packet 推导的理解而非原生运行时连续性此时应使用mode: rebuildrebuild 表面见seat-continuity-and-handover——切勿把 fork 折叠进 artifact 驱动的重入路径这一区分是承重的load-bearing运行时是terminalterminal 运行时在 schema 层直接拒绝session_source。Canonical YAML 形状与校验规则上面的 YAML 即 v1 的规范形状配套规则如下modev1 唯一合法值为forkref.kindv1 仅支持native_id。schema 会在启动前拒绝artifact_path、name、last、artifact_set并给出明确的“deferred / weaker / wrong-mode”错误消息value当ref.kind: native_id时为必填的非空字符串v1 中唯一被 schema 接受的 kindrig expand接受相同形状因此动态添加的成员也能携带会话来源归属。源码层面的证据validateForkSessionSourcerigspec-schema.ts逐条实现了上述拒绝矩阵kind artifact_path→artifact_path deferred to follow-up slice; v1 fork mode supports native_id onlykind name || kind last→ 提示${kind} is weaker than native_idkind artifact_set→ 提示该 kind 属于mode: rebuild其余未知 kind →required; v1 fork mode supports native_id onlyvalue非空字符串校验失败 →ref.value: required non-empty string when ref.kind is native_id。此外validateSessionSourcerigspec-schema.ts对 terminal 运行时直接拒绝terminal runtime has no native fork primitive and no agent context to rebuild; remove session_source for terminal members。值得留意的是源码中的 session_source 实际上支持三种模式fork/rebuild/agent_imageSKILL.md 聚焦的 fork 是 v1 的窄 MVPrebuild 的ref.kind必须是artifact_set且value为按信任优先级排序的路径数组见validateRebuildSessionSourcerigspec-schema.ts。还需要注意一个跨字段约束starter_refAgent Starter 引用与session_source.mode: fork的组合在 v0/v1 前期被 schema 显式拒绝starter_ref session_source.modefork composition is rejected in v0见 rigspec-schema.ts其意图是等待 v1 的 “Real native-fork-from-registered-thread-id starter proof” 触发器而starter_ref session_source.mode: rebuild是被允许的二者在启动管线中可独立叠加。Codec 往返session_source 如何被忠实保存session_source必须能经得起 序列化 → 解析 → 规范化 的往返而不失真。在 rigspec-codec.ts 中可以看到代码用类型层面强制枚举 sessionSource union 的可选 ref 字段_sessionSourceEnumerationComplete哨兵防止新增 ref 字段未同步序列化序列化时将内存中的m.sessionSource还原为 YAML 的session_source键rigspec-codec.ts。在类型层面SessionSourceSpec是三选一的联合类型types.tsexport type SessionSourceSpec | SessionSourceForkSpec // mode: fork, ref.kind: native_id | SessionSourceRebuildSpec // mode: rebuild, ref.kind: artifact_set | SessionSourceAgentImageSpec; // mode: agent_image, ref.kind: image_name其中 fork 规格携带forkSource: { kind: native_id, value: resumeToken }会在启动时传给运行时适配器的forkSource选项types.ts。状态模型声明 → 解析 → 实现 → 失败session_source是启动时输入而非长期状态字段其生命周期分为四步Declared声明——出现在成员配置或rig expand载荷中Resolved解析——启动时 OpenRig 将ref对运行时进行解析Realized实现——运行时 fork 成功新 Seat 获得一个全新的原生连续性 tokenClaude session id 或 Codex thread id。OpenRig 持久化这个新 token父 token 永远不会被写入新 SeatFailed失败——解析或 fork 失败Seat 不会以 fork 方式启动错误信息会明确指出失败发生在哪一步解析。一旦实现realizedsession_source便成为历史。之后对该 Seat 的恢复是对新 Seat 的 restore而不是“从父会话重新 fork”。持久化诚实性是这条状态机的一个关键约束Seat 的resume_token必须是新的 post-fork token父 token 绝不写入。这一点同时体现在适配器层claude-code-adapter.ts中resumeToken与forkSource互斥resumeToken and forkSource are mutually exclusive — pick one见 claude-code-adapter.ts并在 daemon 的三个层面强制这种互斥。五种失败模式及处理动作#失败模式说明与动作1Source session id not found运行时无法解析native_id。动作发出指明运行时与缺失 id 的错误绝不静默地以 fresh 启动。未来态注记当后续切片支持artifact_path时它可能成为 Claude 的候选回退v1 中 schema 在启动前拒绝artifact_path因此当前不存在回退路径2Source artifact path missingv1 范围外待ref.kind: artifact_path被 schema 接受后才适用v1 schema 启动前即拒绝该 kind3Unsupported runtime/kind combinationv1 中大部分被 schema 预先拦截schema 提前拒绝所有非native_id的 kind适配器层存在防御性拒绝但 v1 中不可达4Fork launch failed after source resolution运行时命令claude --resume parent --fork-session或codex fork id返回非零或挂起。动作保留运行时 stderr不记录新 Seat 已启动不把父 token 写入 Seat5Persistence inconsistencyfork 成功但 Seat-token 持久化无法记录新连续性 token。这是内部故障在新 token 被持久化写入之前Seat 不视为已启动诚实的 UX 规则verbatim该原语绝不能对外报告 “restored the original agent”“resumed the original seat”或 “snapshot”。正确的表述是“forked from source session”/“started from prior conversation source”。同时要核对实际呈现给用户的最终结果与持久化的身份——措辞本身并不能证明预期的连续性真的被创建了。这一规则在代码中体现为显式的连续性结果字面量continuityOutcome取值见 types.ts 与SeatRecord字段types.ts。硬边界do-not 清单不得引入一个“分歧的 fork 原语”fork 必须流经既有的 spec / expansion 路径。2026-08-07 更新rig fork source-session已作为薄便捷动词发布它组合了既有的 agent-image fork 路径——这符合该边界并非分歧原语。规则现表述为spec / expansion / agent-image 路径之外不得新增 fork 机制。任何 UX 表面不得报告 “restored” / “resumed the original seat” / “snapshot”不得把session_source耦合进 AgentSpec它是成员级启动时输入不得改变restore语义session_source创建 Seatrestore延续一个已存在的受管 Seat。适配器命令形态已发布 v1运行时命令形态Claudemode: forkref.kind: native_idclaude --resume parent-id --fork-sessionCodexmode: forkref.kind: native_idcodex... fork parent-idTerminalschema 层拒绝源码证据claude-code-adapter.ts的 fork 分支构建claude --resume parent --fork-session --name seat并校验forkSource.kind native_id、forkSource.value非空claude-code-adapter.ts。resumeTokenrestore 路径与forkSourcefork 路径的互斥在 daemon 的三个层面被强制适配器参数校验、schema 校验与持久化层。连续性结果字面量Continuity Outcome结果出现时机forkedfork 成功新 Seat 持有新 native token父 token 从未写入新 Seatfresh全新启动未声明session_sourceresumed对已存在受管 Seat 的 restorefailed解析或 fork 失败对于 “seat handover over fork” 的组合场景绑定结果binding outcome是独立的见seat-continuity-and-handoverskill。验证运行中的实现Verify the running implementation源码检出与正在运行的 daemon 可能包含不同实现。在授权 fork 之前应检查目标 daemon 的构建身份及其对请求来源的支持。源码或隔离测试只能证明该版本cut的行为不能证明线上运行时正在使用它。建议记录实际父历史parent history新 Seat 身份new seat identity新连续性 tokennew continuity token独立的绑定结果binding outcome。保留错误与不完整结果而不要将 “fresh launch” 或 “restored original seat” 报告为一次成功的 fork。这些检查不授予启动、替换或退役线上 Seat 的权限。已发布v1与延期Deferred清单已发布openrigc7b6df12026-04-30Schema 接受/拒绝矩阵完整 Honest Refusal MatrixCodec 往返serialize → parse → normalize 忠实保留session_source经rig expand成员输入的扩展路径Claude Codexnative_id的适配器命令形态持久化诚实性Seat 的resume_token是新的 post-fork token父 token 绝不写入诚实的 UX 字面量契约continuityOutcome: forked。延期Claudeartifact_path模式schema 当前以 deferred 消息拒绝Provenance 列parent_native_id/created_via供可查询的 RSI 消费者使用跨主机 fork来源在主机 A、新 Seat 在主机 B——依赖cross-host-rig-commands。延伸阅读seat-continuity-and-handoverskill——同级的 occupant 创建原语resume / fork / rebuild / fresh与 Seat 绑定handover 与 fork 组合agent-startersskill——把 session_source fork 组合进可命名的可复用起点cross-host-rig-commandsskill——多主机 fork延期源码入口rigspec-schema.ts校验矩阵、rigspec-codec.ts序列化往返、types.ts类型契约、claude-code-adapter.tsClaude fork 命令实现、codex-runtime-adapter.tsCodex fork 实现。赞分享人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载相关推荐Agno Agent 会话分支Fork Session实战用 fork_session 实现非破坏性会话派生与血缘追踪Agno Agent 会话分支Fork Session实战用 fork_session 实现非破坏性会话派生与血缘追踪 会话级的分支能力让 Agent 可人工智能大模型AI AgentAgent 框架多智能体工具调用RAGAgent 工作流Agent 记忆OpenRig Conveyor Lead 角色深度解析conveyor starter rig 的 Intake 与 Close Seat 实战指南OpenRig Conveyor Lead 角色深度解析conveyor starter rig 的 Intake 与 Close Seat 实战指南 本篇技人工智能AI Agent多智能体Agent 编排代码智能体CLIopenclaw resume 实战指南将终端 UI 重新挂载到既有 Gateway 会话openclaw resume 实战指南将终端 UI 重新挂载到既有 Gateway 会话 导读 openclaw resume 是 OpenClaw CLIAI 应用AI Agent交互助手后端即时通讯网关上一篇Astro 文档构建系统指南下一篇Suricata 开源项目教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考