OpenRig Pi适配器与RPC Runner终端窗格里跑第三种运行时的原理【免费下载链接】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 是一款基于 tmux 的本地多智能体协作平台它的Pi 适配器与RPC Runner解决了第三方运行时接入的经典难题Pi 和 Oh My PiOMP这类智能体没有像 Claude Code、Codex 那样可以直接被旁听的交互界面OpenRig 用窗格内 Runner架构让它们以RPC 结构化事件的方式跑在普通终端窗格里同时保留真人可直接打字的体验。为什么 Pi 需要一条第三路接入在 OpenRig 里每个智能体Seat都占一个 tmux 窗格。Claude Code 和 Codex 是原生会话——直接跑在窗格里守护进程daemon靠各自的钩子和进程观察就能拿到活动状态。但 Pi 的一等集成面是pi --mode rpc一个无头 JSONL 协议不是交互式 TUI。硬把 Pi 的交互界面塞进窗格再刮屏解析脆弱且不可信。Pi 适配器的设计哲学因此写在源码开头就定调了见 pi-runtime-adapter.ts#L1-L10Runner 住在窗格里一切信号走结构化 RPC绝不刮 Pi 的界面BR-1 规则。OpenRig TUI 中的团队拓扑每个座位对应一个独立的 tmux 窗格一个窗格里跑的三层结构 RPC Runner 是整套方案的核心数据流非常清晰摘自 pi-runner.ts#L1-L19 的注释数据流方向去向窗格 stdinrig send或人工打字进RPCprompt/steer/follow_upPi RPC 事件类型化 JSONL出① 人类可读的窗格镜像同上出② 活动 会话身份 POST 回 daemon同上出③runner-state.json状态旁挂文件对应源码分三个文件职责边界极干净适配器pi-runtime-adapter.ts —— 负责在座位窗格里敲入启动命令、轮询就绪状态纯协议契约pi-runner-protocol.ts —— 零副作用的常量、argv 构造器和 sidecar 形状保证 Runner 进程不拖进任何 daemon 依赖窗格内 Runnerpi-runner.ts —— 编译后以node dist/adapters/pi-runner.js形式独立运行daemon 判断 Runner 是否就绪时只信任Runner 自己写出的标记[pi-runner] READY、[pi-runner] EXITED、[pi-runner] ERROR定义在 pi-runner-protocol.ts#L45-L49外加前台进程是否已退回 shell 的守卫检查——上一轮残留在滚动缓冲里的 READY 标记不会造成假就绪。状态旁挂文件runner-state.json 的三个巧思 每个 Pi 座位在stateRoot/sessionName/下有三块隔离状态见 pi-runner-protocol.ts#L23-L26agent/—— Pi 的配置目录PI_CODING_AGENT_DIRauth、models、skillssessions/—— 会话历史目录PI_CODING_AGENT_SESSION_DIRrunner-state.json—— Runner 自报的会话身份旁挂文件这个 sidecar 文件有三个精妙设计launchId 启动作用域每次启动都铸造一个 launchId旧的 READY/EXITED 记录若 launchId 不匹配一律忽略——陈旧工件既不能假绿新启动也不能假红它lastEntryId 持久追赶游标崩溃重启后Runner 用get_entries重放上个实例没来得及投影的会话条目重置 sidecar 时这个游标会被刻意保留防止恢复时丢事件exited 字段pi 进程死亡会诚实地写下退出码座位绝不会出现静默卡死的窗格在 OpenRig 里选择要启动的 rig其座位随后各自落入终端窗格像普通终端一样打字输入边界与窗格镜像Runner 接管窗格 stdin 的方式pi-runner.ts#L38-L148很有工程味原始模式行编辑器保留 VT100 行编辑体验同时正确处理 bracketed-paste 粘贴块1MB 输入上限超限直接拒收并提示Ctrl-C 清空两条快捷前缀/followup text在回合结束后排队/abort发送 RPC 取消流式中打断回合进行中输入走steer语义——在当前回合的工具调用结束后、下次模型调用前送达这是 Pi 的文档化行为Pi 的类型化事件被映射为窗格里可读的一行行镜像见 mapPiEvent工具调用显示为⚙ 工具名 …/⚙ 工具名 done上下文压缩显示为[pi] compacting context…助手文本逐增量流式追加。点击座位的 CMUX 按钮可直接打开该智能体所在的终端窗格默认拒绝的环境白名单与显式信任 ️安全设计集中在 pi-runner-protocol.ts#L105-L210deny-by-default 环境变量只有PATH、HOME、TERM等基线变量加声明模型所属 provider 的那一个密钥如 OpenRouter 对应OPENROUTER_API_KEY能穿进 Pi 子进程任意*_KEY一律不转发扩展白名单是一次需要评审的变更每座位隔离PI_CODING_AGENT_DIR/PI_CODING_AGENT_SESSION_DIR指向座位私有目录会话之间互不可见信任旗标永远显式启动命令必须带--approve或--no-approve交互式的ask在 RPC 模式下被静默跳过——受管路径上永远不弹交互式询问这是刻意的诚实设计多个座位的窗格同时活动镜像文本、工具调用摘要与状态同步推进恢复会话精确续接绝不假装Pi 座位的恢复逻辑在 pi-resume.ts 里核心是一条诚实续接契约恢复 用持久化的会话文件重新拉起 Runner走--session 精确文件路径FR-6永远不用--resume——那会打开交互式选择器在受管路径上被禁止会话文件不存在时返回retry_fresh由恢复编排器映射为停下询问绝不做静默的全新开始BR-6校验只轮询本次启动作用域的 sidecar且要求 Runner 上报的sessionFile与请求文件完全一致才算恢复成功超时或退出都会带上窗格尾部证据新手上手在 demo rig 里看到 Pi 座位 不用从零搭环境仓库自带的演示 rig 就能跑完整流程团队定义demo/rig.yaml演示说明demo/README.md各角色智能体规格demo/agents/lead/agent.yaml 等启动后进入 TUI用拓扑视图找到目标座位再通过rig terminal open rig --provider cmux或 herdr把座位的终端窗格并排打开——你会直观看到 Pi 适配器把 RPC 事件翻译成窗格里的可读对话而 daemon 侧拿到的全是类型化结构化信号。这套窗格里跑 Runner、真相走 RPC的模式也正是 OpenRig 能同时容纳 Claude Code、Codex、Pi 三种异构运行时的关键。【免费下载链接】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），仅供参考 OpenRig Pi适配器与RPC Runner：终端窗格里跑第三种运行时的原理
OpenRig Pi适配器与RPC Runner终端窗格里跑第三种运行时的原理【免费下载链接】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 是一款基于 tmux 的本地多智能体协作平台它的Pi 适配器与RPC Runner解决了第三方运行时接入的经典难题Pi 和 Oh My PiOMP这类智能体没有像 Claude Code、Codex 那样可以直接被旁听的交互界面OpenRig 用窗格内 Runner架构让它们以RPC 结构化事件的方式跑在普通终端窗格里同时保留真人可直接打字的体验。为什么 Pi 需要一条第三路接入在 OpenRig 里每个智能体Seat都占一个 tmux 窗格。Claude Code 和 Codex 是原生会话——直接跑在窗格里守护进程daemon靠各自的钩子和进程观察就能拿到活动状态。但 Pi 的一等集成面是pi --mode rpc一个无头 JSONL 协议不是交互式 TUI。硬把 Pi 的交互界面塞进窗格再刮屏解析脆弱且不可信。Pi 适配器的设计哲学因此写在源码开头就定调了见 pi-runtime-adapter.ts#L1-L10Runner 住在窗格里一切信号走结构化 RPC绝不刮 Pi 的界面BR-1 规则。OpenRig TUI 中的团队拓扑每个座位对应一个独立的 tmux 窗格一个窗格里跑的三层结构 RPC Runner 是整套方案的核心数据流非常清晰摘自 pi-runner.ts#L1-L19 的注释数据流方向去向窗格 stdinrig send或人工打字进RPCprompt/steer/follow_upPi RPC 事件类型化 JSONL出① 人类可读的窗格镜像同上出② 活动 会话身份 POST 回 daemon同上出③runner-state.json状态旁挂文件对应源码分三个文件职责边界极干净适配器pi-runtime-adapter.ts —— 负责在座位窗格里敲入启动命令、轮询就绪状态纯协议契约pi-runner-protocol.ts —— 零副作用的常量、argv 构造器和 sidecar 形状保证 Runner 进程不拖进任何 daemon 依赖窗格内 Runnerpi-runner.ts —— 编译后以node dist/adapters/pi-runner.js形式独立运行daemon 判断 Runner 是否就绪时只信任Runner 自己写出的标记[pi-runner] READY、[pi-runner] EXITED、[pi-runner] ERROR定义在 pi-runner-protocol.ts#L45-L49外加前台进程是否已退回 shell 的守卫检查——上一轮残留在滚动缓冲里的 READY 标记不会造成假就绪。状态旁挂文件runner-state.json 的三个巧思 每个 Pi 座位在stateRoot/sessionName/下有三块隔离状态见 pi-runner-protocol.ts#L23-L26agent/—— Pi 的配置目录PI_CODING_AGENT_DIRauth、models、skillssessions/—— 会话历史目录PI_CODING_AGENT_SESSION_DIRrunner-state.json—— Runner 自报的会话身份旁挂文件这个 sidecar 文件有三个精妙设计launchId 启动作用域每次启动都铸造一个 launchId旧的 READY/EXITED 记录若 launchId 不匹配一律忽略——陈旧工件既不能假绿新启动也不能假红它lastEntryId 持久追赶游标崩溃重启后Runner 用get_entries重放上个实例没来得及投影的会话条目重置 sidecar 时这个游标会被刻意保留防止恢复时丢事件exited 字段pi 进程死亡会诚实地写下退出码座位绝不会出现静默卡死的窗格在 OpenRig 里选择要启动的 rig其座位随后各自落入终端窗格像普通终端一样打字输入边界与窗格镜像Runner 接管窗格 stdin 的方式pi-runner.ts#L38-L148很有工程味原始模式行编辑器保留 VT100 行编辑体验同时正确处理 bracketed-paste 粘贴块1MB 输入上限超限直接拒收并提示Ctrl-C 清空两条快捷前缀/followup text在回合结束后排队/abort发送 RPC 取消流式中打断回合进行中输入走steer语义——在当前回合的工具调用结束后、下次模型调用前送达这是 Pi 的文档化行为Pi 的类型化事件被映射为窗格里可读的一行行镜像见 mapPiEvent工具调用显示为⚙ 工具名 …/⚙ 工具名 done上下文压缩显示为[pi] compacting context…助手文本逐增量流式追加。点击座位的 CMUX 按钮可直接打开该智能体所在的终端窗格默认拒绝的环境白名单与显式信任 ️安全设计集中在 pi-runner-protocol.ts#L105-L210deny-by-default 环境变量只有PATH、HOME、TERM等基线变量加声明模型所属 provider 的那一个密钥如 OpenRouter 对应OPENROUTER_API_KEY能穿进 Pi 子进程任意*_KEY一律不转发扩展白名单是一次需要评审的变更每座位隔离PI_CODING_AGENT_DIR/PI_CODING_AGENT_SESSION_DIR指向座位私有目录会话之间互不可见信任旗标永远显式启动命令必须带--approve或--no-approve交互式的ask在 RPC 模式下被静默跳过——受管路径上永远不弹交互式询问这是刻意的诚实设计多个座位的窗格同时活动镜像文本、工具调用摘要与状态同步推进恢复会话精确续接绝不假装Pi 座位的恢复逻辑在 pi-resume.ts 里核心是一条诚实续接契约恢复 用持久化的会话文件重新拉起 Runner走--session 精确文件路径FR-6永远不用--resume——那会打开交互式选择器在受管路径上被禁止会话文件不存在时返回retry_fresh由恢复编排器映射为停下询问绝不做静默的全新开始BR-6校验只轮询本次启动作用域的 sidecar且要求 Runner 上报的sessionFile与请求文件完全一致才算恢复成功超时或退出都会带上窗格尾部证据新手上手在 demo rig 里看到 Pi 座位 不用从零搭环境仓库自带的演示 rig 就能跑完整流程团队定义demo/rig.yaml演示说明demo/README.md各角色智能体规格demo/agents/lead/agent.yaml 等启动后进入 TUI用拓扑视图找到目标座位再通过rig terminal open rig --provider cmux或 herdr把座位的终端窗格并排打开——你会直观看到 Pi 适配器把 RPC 事件翻译成窗格里的可读对话而 daemon 侧拿到的全是类型化结构化信号。这套窗格里跑 Runner、真相走 RPC的模式也正是 OpenRig 能同时容纳 Claude Code、Codex、Pi 三种异构运行时的关键。【免费下载链接】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），仅供参考