1. 从 openrig 说起一个被低估的终端工作流编排思路第一次看到 openrig 这个名字我下意识把它和“脚手架”“配置管理”这类工具归到了一起。但真正把它和 Claude Code、Codex、tmux、Node.js 这几个关键词放在同一张桌子上之后我才意识到它想解决的是一个更具体、也更痛的问题当你在终端里同时跑多个 AI 编码代理时怎么让它们各自待在自己的格子里互不打架还能被你随时叫出来干活。这个问题的背景其实很现实。Claude Code 和 Codex 这类命令行 AI 编码工具本质上都是“长驻会话型”的程序。它们不像ls、grep那样执行完就退出而是会保持一个持续的上下文等待你不断输入指令。你一旦同时开两个终端就会变成一锅粥输出互相穿插、光标位置错乱、CtrlC 不知道该杀谁。openrig 的核心价值就是把这几个长驻会话用 tmux 的会话与窗口机制隔离开再用一层轻量的 Node.js 脚本做统一调度。它适合谁如果你只是偶尔用一次 Claude Code 问个问题那确实用不上。但如果你已经进入“多代理并行”的工作状态——比如一个窗口让 Claude Code 重构模块另一个窗口让 Codex 补测试第三个窗口跑本地模型做代码审查——那 openrig 这类编排思路就非常值得研究。它不是什么大厂出品也没有华丽的界面但它解决的是真实工作流里的摩擦点。下面我会把它拆开从设计动机一直讲到你能直接抄的配置。2. 核心设计拆解为什么是 tmux 加 Node.js 这套组合2.1 长驻会话的隔离需求从何而来要理解 openrig 的设计先得理解 Claude Code 和 Codex 这类工具的运行形态。它们启动后会占用一个前台进程持续读取标准输入、输出到标准输出。你在同一个终端里再启动第二个两者会争抢同一个 TTY结果就是输出错位、输入被吞。更麻烦的是这类工具往往会注册一些全局状态比如配置目录、缓存文件、会话历史如果多个实例同时读写偶尔会出现配置被覆盖的情况。我实测过一个典型场景在一个终端里先跑 Claude Code再CtrlZ挂起然后启动 Codex。表面上看两个都活着但当你fg把 Claude Code 调回前台时Codex 的输出会突然插进来整个屏幕的刷新逻辑就乱了。这不是工具本身的 bug而是终端复用方式不对。正确的做法是给每个长驻会话分配独立的伪终端而 tmux 恰好就是干这个的。2.2 tmux 作为隔离层的三个理由选择 tmux 而不是开多个终端标签页是有讲究的。第一tmux 的会话可以脱离当前 SSH 连接独立存在。你在笔记本上通过 SSH 连到开发机跑 Claude Code网络一断普通终端里的进程就没了但 tmux 会话还在重连之后tmux attach就能回到原来的上下文。第二tmux 支持窗口和面板的嵌套划分你可以把一个会话切成多个窗口每个窗口跑一个代理切换成本极低。第三tmux 有完整的命令行接口tmux new-session -d、tmux send-keys、tmux capture-pane这些命令可以被脚本调用这就为自动化编排留了口子。openrig 的思路正是踩在这第三点上。它不重新造一个终端复用器而是把 tmux 当成底层运行时用 Node.js 写一层控制逻辑。这样做的好处是tmux 本身足够稳定、足够老几乎不会出问题而 Node.js 负责处理配置解析、会话命名、启动参数拼装这些更灵活的事情。2.3 Node.js 在其中的角色定位为什么是 Node.js 而不是 Bash 或 Python我的理解是三点。其一Claude Code 和 Codex 本身就是 Node.js 生态里的工具用 npm 全局安装版本管理、依赖解析都走同一套体系用 Node.js 写编排脚本能直接复用这些环境信息。其二Node.js 处理 JSON 配置、拼装命令行参数、做异步流程控制都很顺手写出来的脚本比 Bash 可读性好很多。其三Node.js 的跨平台能力虽然不完美但在 Linux 和 macOS 上表现一致而这两个系统正是终端工作流的主战场。需要说明的是openrig 本身并不是一个官方项目它更像是一种被社区反复实践出来的编排模式。你在热词里看到的cc switch local proxy failed、codex endpoint /responses这些报错很多都源于多个代理实例共享了同一份配置或同一个本地代理端口。openrig 式的隔离恰恰能从根上减少这类冲突。3. 环境准备Node.js 与 tmux 的安装细节3.1 Node.js 版本选择与安装方式Claude Code 和 Codex 对 Node.js 版本有明确要求通常需要 18 以上推荐 20 LTS 或更高。热词里出现的error installing 24.21.0: node.js v24.21.0 is not yet released这类报错往往是因为用了 nvm 去安装一个还不存在的版本号或者镜像源里没有同步到最新版。我的建议是直接用 LTS 版本不要追最新的奇数版本。在 Ubuntu 上最稳的方式是用 NodeSource 的仓库而不是apt install nodejs因为系统源里的版本通常偏旧。操作如下curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt-get install -y nodejs node -v npm -v如果你用 macOS直接brew install node20就行。Windows 用户建议用 WSL2因为 tmux 在原生 Windows 上体验很差而 openrig 这套思路高度依赖 tmux。注意不要同时用 nvm 和系统包管理器装 Node.js两者会打架导致which node指向混乱。选一个坚持用。3.2 tmux 安装与基础配置tmux 的安装很简单Ubuntu 上sudo apt install tmuxmacOS 上brew install tmux。装完之后建议先改一下默认前缀键因为CtrlB在很多终端里和翻页冲突。我习惯改成CtrlA在~/.tmux.conf里写set -g prefix C-a unbind C-b bind C-a send-prefix set -g mouse on set -g history-limit 10000set -g mouse on这行很关键它让你可以用鼠标直接点选窗口和面板对不熟悉 tmux 快捷键的人非常友好。history-limit调大是为了让 Claude Code 的长输出能被回滚查看默认的 2000 行经常不够用。3.3 验证环境是否就绪装完之后跑一遍检查node -v npm -v tmux -V三个命令都有正常输出说明基础环境没问题。接下来安装 Claude Code 和 Codex通常是npm install -g anthropic-ai/claude-code和对应的 Codex 包。安装完成后先单独在普通终端里跑一次确认能正常登录、能正常对话再进入 openrig 式的多会话编排。这一步不能省因为如果单实例都跑不起来多实例只会更乱。4. 实操过程用 tmux 编排多个 AI 编码代理4.1 会话命名规范与启动脚本openrig 式编排的第一步是给每个代理一个固定的会话名。我一般用claude-main、codex-test、local-review这种带用途的命名而不是session1、session2。原因很简单当你同时开着五六个会话时tmux ls的输出必须能让你一眼看出谁是谁。启动脚本可以写成一个 Node.js 文件比如rig.js核心逻辑是调用child_process执行 tmux 命令const { execSync } require(child_process); const sessions [ { name: claude-main, cmd: claude }, { name: codex-test, cmd: codex }, { name: local-review, cmd: claude --model local } ]; sessions.forEach(s { try { execSync(tmux has-session -t ${s.name} 2/dev/null); console.log(${s.name} already exists); } catch { execSync(tmux new-session -d -s ${s.name} -x 220 -y 50); execSync(tmux send-keys -t ${s.name} ${s.cmd} Enter); console.log(${s.name} started); } });这段脚本做了三件事检查会话是否已存在、创建指定尺寸的分离会话、把启动命令发送进去。-x 220 -y 50是显式指定终端尺寸避免某些环境下 tmux 默认尺寸过小导致 Claude Code 的界面被截断。4.2 参数计算终端尺寸与并发数量的平衡这里有个容易被忽略的细节每个 tmux 会话都会占用一定的内存和文件描述符。我实测下来一个 Claude Code 会话大概占 150 到 300 MB 内存Codex 类似。如果你在 8 GB 内存的开发机上开十个会话系统会开始频繁换页响应变慢。我的经验值是8 GB 内存最多开 4 个16 GB 开 6 到 8 个32 GB 以上可以开到 12 个左右。终端尺寸方面Claude Code 的 TUI 界面在宽度小于 100 列时会开始折行影响阅读。所以-x建议不低于 120-y不低于 40。如果你用tmux attach之后发现界面错位多半是尺寸没设对可以在会话内用CtrlA然后:resize-window -A让它自适应。4.3 会话切换与输出抓取日常使用中最常用的两个操作是切换和抓取。切换用tmux attach -t claude-main退出用CtrlA然后d。抓取输出用tmux capture-pane -t claude-main -p这个命令能把指定会话当前屏幕的内容打印出来非常适合做日志记录或者让另一个脚本去解析结果。我经常用这个机制做一件事让 Claude Code 在claude-main里跑一个重构任务然后用一个定时脚本每 30 秒capture-pane一次把输出追加到日志文件。这样即使我离开电脑回来也能看到完整的执行过程。这个技巧在处理长任务时特别有用因为 Claude Code 的输出滚动很快人工盯着看容易漏掉关键信息。提示capture-pane默认只抓当前可见区域加-S -可以抓取从历史开头到现在的全部内容但输出量可能很大建议配合tail使用。5. 常见问题与排查技巧实录5.1 代理端口冲突与配置隔离热词里cc switch local proxy failed while handling codex endpoint /responses这个报错我遇到过好几次。根本原因是 Claude Code 和 Codex 可能都会尝试启动一个本地代理服务默认端口撞了。解决办法是给每个实例指定不同的端口或者干脆让它们各自读不同的配置目录。以 Claude Code 为例可以通过环境变量指定配置路径export CLAUDE_CONFIG_DIR~/.claude-main在 tmux 启动脚本里把这条 export 放在启动命令之前每个会话用不同的目录。这样会话历史、缓存、代理端口配置就完全隔离了不会再出现互相覆盖的情况。5.2 登录状态与组织设置问题your organization has disabled claude subscription access和codex无法加载组织设置这两类报错通常和账号权限有关不是 openrig 本身能解决的。但多会话编排会放大这个问题如果你在多个会话里用同一个账号反复登录偶尔会触发风控导致某个会话突然掉线。我的做法是主会话用主账号测试会话用另一个账号或者本地模型。热词里提到的claude code 调用 lmstudio 的本地模型就是一个很好的隔离方案把需要频繁试验的任务放到本地模型会话里不消耗云端额度也不会影响主账号的登录状态。5.3 常见问题速查表现象可能原因排查方向会话启动后立即退出命令路径不对或未登录先在普通终端单独运行一次输出错位、界面花屏终端尺寸设置过小调整-x-y参数代理端口冲突多实例共用默认端口为每个实例指定独立端口登录状态频繁失效多会话共用同一账号分离账号或改用本地模型内存占用过高并发会话数超出硬件减少会话数或升级内存capture-pane内容不全未加-S -参数补上历史抓取参数5.4 几个踩过的坑第一个坑是 tmux 会话里的环境变量不会自动继承。你在.bashrc里设置的PATH在tmux new-session -d创建的分离会话里可能不生效导致claude: command not found。解决办法是在启动脚本里显式 source 一下或者用绝对路径。第二个坑是send-keys发送命令时如果命令里含有特殊字符会被 tmux 解释成快捷键。比如命令里有;就可能出问题。稳妥的做法是把命令写成一个 shell 脚本然后send-keys只发送脚本路径。第三个坑是会话积累。用久了tmux ls会列出一堆废弃会话占着内存不放。我习惯在启动脚本里加一个清理逻辑把超过 24 小时没活动的会话自动 kill 掉。这个逻辑用tmux list-sessions -F #{session_name} #{session_activity}配合时间戳比较就能实现。6. 进阶玩法把 openrig 思路扩展到更多场景6.1 与 VS Code 的协同很多人习惯在 VS Code 里写代码同时想用 Claude Code 做辅助。热词里vscode配置claude code、claude code for vs code都是这个需求。我的做法是VS Code 的集成终端里只跑一个轻量的 tmux attach真正的代理会话在后台的 tmux 里跑。这样即使 VS Code 重启代理会话也不受影响。具体就是在 VS Code 的settings.json里把默认终端配置成tmux attach -t claude-main打开终端就直接进主会话。6.2 本地模型接入的编排claude code 调用 lmstudio 的本地模型这个场景特别适合用 openrig 的思路来管。因为本地模型的加载和卸载很吃资源你不可能同时加载好几个。合理的做法是开一个专门的local-review会话里面配置好指向本地模型的 endpoint需要审查代码时切过去用完就让它闲着。这样云端会话和本地会话各司其职互不干扰。6.3 自动化任务链再进一步你可以用 Node.js 脚本把多个会话串成任务链。比如先在claude-main里发送“分析这个模块的依赖”用capture-pane抓取结果解析出关键信息再发送到codex-test里让它“根据以下依赖生成测试骨架”。这种链式编排听起来复杂但核心就是send-keys和capture-pane两个命令的反复调用。我试过一个简单的三阶段链从分析到生成再到校验全程无人值守跑完大概需要几分钟省下来的手动切换时间相当可观。注意自动化链里一定要加超时和错误检测否则某个环节卡住整个链就会一直挂着。我一般用capture-pane抓取最后几行匹配特定关键词来判断阶段是否完成。6.4 资源监控与动态调度当你开的会话多了手动管理会变得吃力。我后来加了一个简单的监控脚本每隔一分钟检查每个会话的 CPU 和内存占用超过阈值就在日志里标红。更进一步可以根据负载动态决定要不要启动新的会话。这套东西不需要多复杂一个 Node.js 脚本加一个setInterval就能跑起来但带来的掌控感提升很明显。7. 我个人的使用体会这套 openrig 式的编排思路我用了大概几个月最大的感受是它把“工具管理”这件事从你的脑子里挪到了脚本里。以前我开三个代理得记住哪个窗口在跑什么、哪个登录的是哪个账号、哪个端口被占了脑子一半的带宽都花在管理上。现在这些信息都固化在会话名和启动脚本里我只需要tmux attach切过去就行。另一个体会是隔离带来的稳定性提升比预期大。以前多实例混跑偶尔会遇到配置被覆盖、登录掉线、端口冲突排查起来很烦。现在每个会话有独立的配置目录和端口这类问题基本消失了。热词里那些cc switch local proxy failed、codex无法加载组织设置的报错很多都能通过这种隔离从源头避免。最后分享一个小技巧给每个 tmux 会话配一个专属的日志文件用pipe-pane把输出实时写进去。命令是tmux pipe-pane -t claude-main -o cat ~/logs/claude-main.log。这样即使会话被 kill 了日志还在回头查问题有据可依。这个习惯帮我定位过好几次偶发的输出异常强烈建议你也加上。