OpenRig RuntimeAdapter接口源码剖析5个方法抽象出4种运行时【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址: https://gitcode.com/GitHub_Trending/op/openrigOpenRig是一个开源的 AI Agent 网络构建框架帮你把 Claude Code、Codex 和 Pi 三类 AI 编码工具编排成有角色分工、共享上下文、拥有独立工作区的持久化团队。而整个系统最优雅的抽象就是藏在守护进程daemon里的RuntimeAdapter 接口——仅凭 5 个方法签名就把 4 种截然不同的运行时Claude Code、Codex、Pi、Terminal统一纳管。本文将带你用通俗的方式读懂这份契约以及每个适配器是如何各显身手的。为什么需要一个运行时抽象层想象一下你要管理一个 AI 团队有些成员用 Claude Code有些用 Codex还有一个纯终端运维工位。它们的启动命令、会话恢复方式、技能安装路径、就绪判断标准全都不同。如果没有抽象层OpenRig 的启动编排器就得写满if (runtime claude-code) ... else if (runtime codex) ...。而 RuntimeAdapter 接口 的思路是把每个运行时必须回答的 5 个问题固化成契约具体怎么回答各适配器自己决定。契约全貌5 个方法 1 个身份字段打开 runtime-adapter.ts核心定义在文件末尾L131-L160。整个契约可以概括为上岗前的五个动作#方法通俗解释返回1listInstalled盘点这个工位上已经装了哪些技能/资源已安装资源清单2project投影把规划好的资源文件投放到运行时认识的目录里成功/跳过/失败三桶3deliverStartup投递启动文件如何送达合并进指导文档 / 装技能 / 直接发送文本投递数量与失败明细4launchHarness点火在 tmux 会话里真正拉起 harness支持断点续跑与会话分叉是否成功 新的会话令牌5checkReady体检运行时是否响应正常、真的就绪就绪与否 原因码外加一个只读字段runtime: string作为适配器的工牌号如claude-code、codex、pi、terminal供启动编排器分派任务。几个值得品味的设计细节resumeToken与forkSource互斥续跑旧会话还是从父会话分叉出新会话二选一。契约明确要求适配器不许猜两者同时出现必须报错拒绝claude-code-adapter.ts L235-L237。失败要诚实checkReady返回的code若命中 ATTENTION_REQUIRED_READINESS_CODES如trust_gate、login_required、codex_auth_refusal意味着需要人类出手而不是悄悄重试。分叉后只认新令牌fork 分支返回的resumeToken必须是分叉后的新会话 ID绝不复用父会话——这是身份诚实的底线。auto 提示的统一裁决resolveConcreteHint 把SKILL.md判为技能安装、.md判为指导合并、其余判为文本发送保证各适配器的投递语义字节级一致。四种适配器同一份考卷四种答卷四个实现类全部位于 packages/daemon/src/adapters/在守护进程启动时统一装配startup.ts L683-L684。1️⃣ ClaudeCodeAdapter —— 最完备的标准答案ClaudeCodeAdapter约 1000 行是最重的实现投影技能投到cwd/.claude/skills/指导文件以托管区块合并进CLAUDE.md点火拼出claude --resume token --name seat或--session-id全新会话命令通过 tmuxsendText打进面板并回车令牌捕获真实二进制写 fork 会话文件需要 1-3 秒所以它用 12 次 × 500ms 的轮询上限 6 秒来等新会话 ID落盘L291-L302体检探测面板首进程与滚动内容区分已续跑 / 卡在信任门禁 / 需要登录等状态。它甚至持有契约外的可选字段claudeManagedLaunch用于 Claude 托管模式的启动路径。2️⃣ CodexRuntimeAdapter —— 独立配置树的玩家CodexRuntimeAdapter约 1500 行全项目最厚的适配器对应 Codex 的独立特性独立的codex home配置树、钩子信任门禁、OAuth 令牌失效后的codex_auth_refusal拒绝码。它的存在说明这份契约足够宽——运行时差异再大也只需在 5 个方法内消化。3️⃣ PiRuntimeAdapter —— RPC 优先拒绝刮屏PiRuntimeAdapter 展示了契约的另一种解读方式它在 tmux 面板里拉起的是 OpenRig 自有的pi-runner后者托管pi --mode rpc的无头 JSONL 协议。文件头注释直接写明了原则L1-L10会话身份来自 Pi 的类型化 RPC 事件和 sidecar 状态文件绝不靠刮取面板文本猜状态。它的checkReady还会交叉验证sidecar 说就绪与面板前台进程是否回到了 shell防止陈旧标记骗过体检。4️⃣ TerminalAdapter —— 50 行的全空卷TerminalAdapter 只有 50 行全部方法都是空操作shell 天生可交互所以checkReady恒返回就绪project/deliverStartup什么都不做。唯一认真的地方是launchHarness——当有人给终端工位配置了forkSource时它会诚实报错terminal 没有原生 fork 原语。这份考全空卷恰恰证明了抽象的价值连没有运行时的工位也是契约的合法实现。这套抽象给工程实践带来了什么新增运行时 写一个类。想接入下一个 AI 工具实现 5 个方法、在 startup.ts 注册即可编排器一行不用改。行为一致性靠契约而非自觉互斥校验、失败原因码、fork 令牌规则都写在接口注释里L145-L152由测试逐条验收。失败路径与成功路径同等设计recovery: retry_fresh | attention_required让上层能区分可自动重试和必须叫人类避免静默重启吞掉信任门禁。关注点分离注释特别强调启动动作的执行不属于本契约而是checkReady()之后由启动编排器接管——接口只描述运行时是什么不描述流程怎么走。动手看看从接口到启动的完整链路想自己验证这套设计建议按这个顺序阅读源码契约定义packages/daemon/src/domain/runtime-adapter.ts重点看 NodeBinding L8-L23 与 HarnessLaunchResult L85-L90最简实现terminal-adapter.ts标准实现claude-code-adapter.ts 的launchHarnessL224-L334装配现场packages/daemon/src/startup.ts 中各适配器的依赖注入配合 demo/ 目录下的演示 rig含 demo/rig.yaml 与 6 个角色智能体定义以及 demo/README.md你可以直接跑一个多智能体团队直观看到 5 个方法在启动时刻的调用顺序。写在最后RuntimeAdapter 接口是 OpenRig 架构里少即是多的典型范例5 个方法回答不了所有运行时差异但它划定了差异必须被消化的边界——盘点、投影、投递、点火、体检缺一不可多一个方法都会被拒绝入约。理解了这份契约你再去看 OpenRig 的启动编排、恢复链路乃至跨主机能力会发现它们都是在这 5 个方法之上搭建的。这正是抽象接口设计的精髓不是穷举世界的全部而是找到世界的最小公约数。【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址: https://gitcode.com/GitHub_Trending/op/openrig创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考