1. 从“openrig”这个名字说起它到底想解决什么问题第一次看到“openrig”这个词我脑子里蹦出来的不是某个具体软件而是一种“开放式工作台”的意象。rig 在英文里本意是“装配、搭建”在工程语境里常指一套成套的设备或支架比如测试台架、钻井平台。前面加个 open意思就很明确了——这是一套开放的、可自由拼装的工具台。结合热搜词里高频出现的 Claude Code、Codex、Node.js、tmux 这几个关键词我基本能判断出 openrig 的定位它大概率是一个把 AI 编程助手Claude Code、Codex 这类 CLI 工具和终端复用器tmux、运行时环境Node.js整合到一起的本地开发工作台方案。为什么我敢这么判断因为热搜词里有一大堆非常具体的报错和配置问题比如 “cc switch local proxy failed while handling codex endpoint /responses”、“error installing 24.21.0: node.js v24.21.0 is not yet released”、“codex is ignoring 1 unrecognized configuration setting”、“your organization has disabled claude subscription access for claude code”。这些不是普通用户会搜的词而是真正在本地折腾 AI 编程工具链的人才会遇到的坑。openrig 要做的就是把这些零散的工具、配置、代理转发、会话管理打包成一个可复用的“台架”让你不用每次换机器都从头配一遍。我自己的理解是openrig 的核心价值不在于发明新东西而在于“编排”。它把 Node.js 作为运行时底座把 Claude Code 和 Codex 作为两个可切换的 AI 后端把 tmux 作为会话保持层再通过一个本地代理层热搜词里的 cc switch、local proxy 就是线索来统一管理请求转发和模型路由。这样一来你可以在同一个终端窗口里用同一套快捷键随时在 Claude Code 和 Codex 之间切换甚至把请求转发到 DeepSeek、Qwen、GLM 这些第三方模型上。这对于需要频繁对比不同模型输出、或者想在本地模型和云端模型之间做成本控制的开发者来说是非常实用的。这篇文章适合谁看如果你正在用或者打算用 Claude Code、Codex 这类 CLI 编程助手并且被环境配置、代理转发、会话丢失、模型切换这些问题折磨过那这篇内容就是写给你的。如果你只是听说过这些工具但还没上手也没关系我会从最基础的 Node.js 环境讲起把每一步的意图和坑都说明白。下面我就按照一个真实搭建 openrig 工作台的思路把整个链路拆开来讲。2. 底座先行Node.js 环境为什么是整条链路的命门2.1 Node.js 版本选择的真实逻辑热搜词里有一条特别扎眼“error installing 24.21.0: node.js v24.21.0 is not yet released or is not available”。这个报错说明有人在安装 Node.js 时指定了一个还不存在的版本号。这背后反映的问题是很多人配环境时习惯性去搜“最新版 Node.js”然后照着某个教程里的版本号抄结果那个版本要么还没正式发布要么已经被标记为不稳定版。我的经验是做 AI 编程工具链的底座Node.js 版本选择要遵循“LTS 优先、偶数版本优先、不低于 18”三个原则。LTS 是长期支持版稳定性和兼容性都有保障偶数版本如 18、20、22是官方主推的稳定线奇数版本如 19、21、23是过渡版生命周期短容易遇到依赖不兼容不低于 18 是因为 Claude Code 和 Codex 的 CLI 工具普遍依赖较新的 ES 模块和 fetch APINode 16 及以下会直接报错。具体操作上我不建议直接去官网下载安装包双击安装而是用版本管理工具。在 macOS 和 Linux 上nvm是最成熟的选择在 Windows 上nvm-windows或者fnm都可以。用版本管理工具的好处是你可以随时切换 Node 版本不会因为某个工具要求 Node 20 而另一个要求 Node 22 就抓瞎。# macOS / Linux 安装 nvm curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash # 安装并切换到 Node 20 LTS nvm install 20 nvm use 20 nvm alias default 20 # 验证 node -v npm -vWindows 用户如果用 nvm-windows安装后需要以管理员身份运行命令并且注意安装路径不要有空格和中文否则会出现“node.js v24.21.0 is not yet released”这类看似版本问题、实则是路径解析失败的报错。2.2 npm 源与全局安装的权限坑Node.js 装好之后下一步是配置 npm 源。国内网络环境下默认源拉取包的速度可能很慢甚至超时。我一般会换成国内镜像源但要注意不是所有包都能在镜像源上找到最新版本尤其是 Claude Code 和 Codex 这种更新频繁的 CLI 工具。所以我的做法是日常用镜像源遇到版本不对时临时切回官方源。# 查看当前源 npm config get registry # 切换为国内镜像 npm config set registry https://registry.npmmirror.com # 临时用官方源安装某个包 npm install -g anthropic-ai/claude-code --registryhttps://registry.npmjs.org另一个高频坑是全局安装的权限问题。在 macOS 和 Linux 上如果不用 nvm 而是用系统自带的 Nodenpm install -g会往/usr/local/lib里写文件普通用户没有权限就会报 EACCES 错误。很多人这时候会用sudo npm install -g这虽然能装上但会导致后续所有全局包都属于 root普通用户运行时又会出现权限问题形成恶性循环。正确做法是用 nvm 管理 Node这样全局包会装到用户目录下完全避开权限问题。提示如果你已经用 sudo 装过全局包建议先卸载 Node改用 nvm 重装然后把之前用 sudo 装的包重新用普通用户装一遍。这个清理过程虽然麻烦但能避免后面无数奇怪的权限报错。2.3 验证 Node 环境是否真的可用装完 Node 和 npm 之后不要急着装 Claude Code 和 Codex先做三个验证node -v能输出版本号、npm -v能输出版本号、npm install -g一个小的测试包比如npm install -g cowsay能成功并且cowsay hello能运行。这三个都过了说明 Node 环境是健康的。如果cowsay装上了但运行报“command not found”那说明 npm 的全局 bin 目录没有加到 PATH 里需要手动加一下。# 查看 npm 全局 bin 目录 npm config get prefix # 把这个路径下的 bin 目录加到 PATH以 nvm 为例通常已经在 PATH 里了 export PATH$PATH:$(npm config get prefix)/bin这个验证步骤看起来多余但我见过太多人跳过它结果后面 Claude Code 装上了却运行不了回头排查半天才发现是 PATH 问题。先把底座验通后面的事就顺了。3. Claude Code 与 Codex 的安装两条路线同一套心法3.1 Claude Code 的安装与首次配置Claude Code 的安装本身不复杂官方推荐用 npm 全局安装。但热搜词里出现了“claude code安装”、“claude code windows”、“ubuntu配置claude code”、“vscode配置claude code”这么多变体说明不同平台、不同使用方式下的配置差异很大。# 全局安装 Claude Code npm install -g anthropic-ai/claude-code # 验证安装 claude --version安装完成后第一次运行claude会引导你登录。这里有个关键点Claude Code 需要访问 Anthropic 的 API登录方式通常是浏览器授权或者 API Key。如果你在终端环境里没有浏览器可以用 API Key 方式。API Key 的配置一般在~/.claude/config.json或者通过环境变量ANTHROPIC_API_KEY设置。热搜词里有一条“your organization has disabled claude subscription access for claude code”这个报错的意思是组织管理员关闭了 Claude Code 的订阅访问权限。如果你用的是公司账号需要联系管理员开通如果是个人账号检查一下订阅状态是否正常。这个报错跟本地环境无关纯粹是账号权限问题不要浪费时间在重装工具上。另一个高频问题是“note: claude code might not be available in your country”。这个提示出现时通常是因为网络环境导致 API 请求无法到达。我的建议是检查你的网络出口是否稳定以及是否有防火墙拦截了相关域名。如果是公司网络可能需要找 IT 开通白名单。3.2 Codex 的安装与配置陷阱Codex 的安装同样走 npm 路线但它的配置项比 Claude Code 更细碎。热搜词里“codex is ignoring 1 unrecognized configuration setting. check for typos or d”这个报错就是配置文件里写了 Codex 不认识的字段。Codex 的配置文件通常是~/.codex/config.toml或~/.codex/config.json具体格式取决于版本。# 安装 Codex CLI npm install -g openai/codex # 查看版本 codex --versionCodex 的配置里最容易出错的是模型名称和 endpoint 地址。如果你要接入第三方模型比如 DeepSeek、Qwen、GLM需要把 endpoint 指向对应的 API 地址并且模型名称要跟服务商文档里的一致。热搜词里“codex接入deepseek”就是一个典型场景。配置示例大概长这样# ~/.codex/config.toml model deepseek-chat api_base https://api.deepseek.com/v1 api_key your-api-key-here注意不同版本的 Codex 配置字段名可能不同有的用api_base有的用base_url有的用endpoint。如果你写了api_base但工具报“unrecognized configuration setting”那就说明这个版本用的是别的字段名。这时候不要瞎猜直接去看对应版本的官方文档或者用codex --help看支持的配置项。3.3 两个工具共存时的 PATH 与别名管理Claude Code 和 Codex 都装好后它们各自的可执行文件都在 npm 全局 bin 目录下。正常情况下不会冲突因为命令名不同claude和codex。但如果你之前装过旧版本或者用其他方式装过同名工具就可能出现which claude指向了错误的路径。我的做法是装完后立刻用which claude和which codex确认路径然后用claude --version和codex --version确认版本。如果路径不对检查 PATH 里是否有多个 Node 版本的 bin 目录把旧的清理掉。另外如果你经常需要在两个工具之间切换可以在 shell 配置文件里加别名比如alias ccclaude、alias cxcodex减少输入成本。但要注意别名不要跟已有命令冲突比如cc在某些系统上是 C 编译器的命令那就换个名字。4. tmux 会话保持让 AI 编程助手不再“断线重连”4.1 为什么 AI 编程助手需要 tmuxClaude Code 和 Codex 都是长时间运行的交互式 CLI 工具。你在里面跟 AI 对话、让它读代码、改文件这个过程可能持续几十分钟甚至几个小时。如果你是在 SSH 远程连接里跑这些工具网络一抖SSH 断了工具进程也就跟着断了之前的对话上下文全丢。即使你是在本地终端里跑不小心关了窗口进程也会被终止。tmux 解决的就是这个问题。它把终端会话和终端窗口解耦会话在后台持续运行你随时可以 attach 回去。对于 AI 编程助手这种“上下文很贵”的工具来说tmux 几乎是必备的。热搜词里 tmux 跟 Claude Code、Codex 一起出现说明已经有很多人意识到这个问题了。# 安装 tmuxUbuntu/Debian sudo apt install tmux # 安装 tmuxmacOS brew install tmux # 新建一个名为 ai-work 的会话 tmux new -s ai-work # 在会话里运行 Claude Code claude # 按 CtrlB 然后按 D 脱离会话工具继续在后台跑 # 重新连接会话 tmux attach -t ai-work4.2 tmux 配置里对 AI 工具最友好的几个选项默认的 tmux 配置对长时间滚动的 AI 对话输出不太友好历史缓冲区太小滚上去看不到之前的输出。我一般会改几个配置# ~/.tmux.conf # 增大历史缓冲区到 50000 行 set -g history-limit 50000 # 开启鼠标支持方便滚动和选择 set -g mouse on # 用更直观的前缀键可选默认是 CtrlB # set -g prefix C-a # bind C-a send-prefix # 窗口编号从 1 开始 set -g base-index 1 setw -g pane-base-index 1history-limit这个配置特别重要。Claude Code 和 Codex 的输出动辄几百行默认的 2000 行缓冲区很快就不够用了。改成 50000 之后你可以随时往上翻查看之前的代码建议和对话内容。mouse on则让你可以用鼠标滚轮滚动不用记复杂的快捷键。4.3 用 tmux 窗口管理多个 AI 会话tmux 的窗口window和面板pane机制可以让你在一个会话里同时跑多个 AI 工具。比如窗口 1 跑 Claude Code窗口 2 跑 Codex窗口 3 跑一个普通的 shell 用来执行命令。这样你可以在不同窗口之间快速切换对比两个 AI 工具对同一个问题的回答。# 在 tmux 会话里新建窗口 CtrlB c # 重命名当前窗口 CtrlB , # 在窗口之间切换 CtrlB 1 # 切换到窗口 1 CtrlB 2 # 切换到窗口 2 CtrlB n # 切换到下一个窗口 CtrlB p # 切换到上一个窗口 # 水平分割面板 CtrlB % # 垂直分割面板 CtrlB 我自己的习惯是左边面板跑 Claude Code右边面板跑一个 shell 用来执行 Claude Code 建议的命令。这样 AI 给出命令后我直接复制到右边执行不用切换窗口。这个工作流用熟了之后效率提升非常明显。注意tmux 会话里的环境变量可能跟你登录 shell 的环境变量不一致。如果你在 tmux 里运行 Claude Code 时报“command not found”先检查echo $PATH是否包含了 npm 全局 bin 目录。可以在~/.tmux.conf里加set -g update-environment PATH或者直接在 tmux 里手动 export。5. 本地代理与模型路由cc switch 和 local proxy 的实战逻辑5.1 为什么需要本地代理层热搜词里“cc switch local proxy failed while handling codex endpoint /responses”这个报错暴露了一个核心需求很多人希望用一个统一的本地代理来管理 Claude Code 和 Codex 的请求实现模型切换、请求转发、日志记录等功能。这个代理层通常跑在本地某个端口上Claude Code 和 Codex 的 endpoint 都指向这个本地地址由代理层决定把请求转发到哪个上游服务。这样做的好处有三个第一可以在不修改工具配置的情况下切换后端模型第二可以统一管理 API Key不用在每个工具里都配一遍第三可以记录请求日志方便排查问题和统计用量。5.2 cc switch 的工作机制与常见故障cc switch 从名字看是一个“Claude Code 切换器”它的核心功能应该是让 Claude Code 在不同的模型后端之间切换。结合热搜词“使用cc switch 接入 deepseek v4, qwen, glm等模型”可以推断它支持把 Claude Code 的请求转发到 DeepSeek、Qwen、GLM 等第三方模型。它的工作原理大概是在本地启动一个 HTTP 服务监听某个端口比如 3456然后把 Claude Code 的 API endpoint 配置成http://localhost:3456/v1/messages。当 Claude Code 发请求时cc switch 接收到请求根据配置把请求转换成目标模型能理解的格式转发到目标 API再把响应转换回 Claude Code 期望的格式。“local proxy failed while handling codex endpoint /responses”这个报错说明代理在处理 Codex 的/responses端点时失败了。可能的原因有几个代理版本不支持 Codex 的/responses路径请求体格式跟代理期望的不一致上游 API 返回了代理无法解析的响应。排查时先看代理的日志确认请求是否到达了代理以及代理转发出去后上游返回了什么。# 启动 cc switch假设命令是 cc-switch cc-switch --port 3456 --config ~/.cc-switch/config.json # 查看代理日志 tail -f ~/.cc-switch/logs/proxy.log # 测试代理是否可达 curl http://localhost:3456/health5.3 配置 Codex 走本地代理的完整步骤如果你想让 Codex 也走本地代理需要修改 Codex 的配置把 endpoint 指向代理地址。但 Codex 的配置格式跟 Claude Code 不同不能直接照搬。# ~/.codex/config.toml model gpt-4 api_base http://localhost:3456/v1 api_key dummy-key注意这里的api_key可以填任意值因为真正的 API Key 是在代理层配置的。代理层会根据请求的目标模型自动替换成对应的真实 Key。这样你就不用在 Codex 里存真实的 API Key安全性更好。配置完成后运行codex并发一条消息观察代理日志里是否有请求进来。如果日志里没有请求说明 Codex 没有走代理检查api_base是否写对了以及 Codex 是否重启了。如果日志里有请求但报错看错误信息是代理转发失败还是上游返回错误。提示本地代理的端口不要跟其他常用服务冲突。3456、7890、8080 这些端口经常被占用建议用 3456 或 4567 这类不太常见的端口。启动代理前先用lsof -i :3456检查端口是否被占用。6. 编辑器集成VS Code 里跑 Claude Code 的正确姿势6.1 VS Code 集成 Claude Code 的两种方式热搜词里“vscode配置claude code”、“vscode接入claude code”、“claude code for vs code”出现频率很高说明很多人希望在 VS Code 里直接用 Claude Code而不是在外部终端里跑来跑去。目前有两种主流方式一种是用 VS Code 的集成终端跑 Claude Code CLI另一种是装 Claude Code 的 VS Code 扩展在编辑器界面里直接交互。第一种方式最简单不需要装额外扩展。在 VS Code 里按Ctrl打开集成终端直接运行claude就行。但这种方式的问题是集成终端的环境变量可能跟外部终端不同如果 Claude Code 报“command not found”需要在 VS Code 的设置里配置terminal.integrated.env或者terminal.integrated.shellArgs。// VS Code settings.json { terminal.integrated.env.linux: { PATH: ${env:PATH}:/home/yourname/.nvm/versions/node/v20.11.0/bin }, terminal.integrated.env.osx: { PATH: ${env:PATH}:/Users/yourname/.nvm/versions/node/v20.11.0/bin } }第二种方式是装扩展。在 VS Code 扩展市场搜索“Claude Code”找到官方或社区维护的扩展安装后按提示配置 API Key。扩展的好处是可以在编辑器侧边栏里直接对话不用切换窗口。但扩展的更新频率可能跟不上 CLI 工具有时候 CLI 已经支持新功能了扩展还没跟上。6.2 在 VS Code 里用 Claude Code 执行终端命令热搜词里“claude code如何直接执行终端命令”是一个很实际的问题。Claude Code 本身有执行 shell 命令的能力但默认可能需要你确认。在 VS Code 集成终端里Claude Code 执行命令时输出会直接显示在同一个终端里你可以看到命令的执行结果。如果你希望 Claude Code 自动执行某些命令而不需要每次确认可以在配置里设置权限。但我要提醒一句自动执行命令有风险尤其是涉及文件删除、系统修改的命令。我的建议是日常开发中保持手动确认只在明确知道命令安全的情况下才开启自动执行。# 在 Claude Code 里执行终端命令的典型交互 帮我看看当前目录下有哪些文件 # Claude Code 会建议执行 ls -la # 你确认后它执行并返回结果6.3 VS Code 终端与 tmux 的配合如果你在 VS Code 集成终端里跑 Claude Code同时又想用 tmux 保持会话可以在集成终端里直接tmux attach到之前的会话。这样你既能在 VS Code 里编辑代码又能随时切到 Claude Code 的会话里查看进度。但要注意VS Code 集成终端对 tmux 的鼠标支持可能不如外部终端好。如果鼠标滚动有问题可以在 tmux 配置里关掉鼠标支持改用快捷键滚动。或者直接用 VS Code 终端自己的滚动条但那样只能滚动 VS Code 终端缓冲区的内容tmux 会话内部的历史还是需要用 tmux 的翻页模式CtrlB [来查看。7. 踩坑实录那些热搜词背后的真实故障与修复7.1 “codex无法加载组织设置”的排查链路这个报错通常出现在企业环境下Codex 尝试从组织配置中读取设置但失败了。排查链路是这样的先确认 Codex 是否配置了组织相关的字段比如organization或org_id然后确认当前登录的账号是否有权限访问该组织最后确认网络是否能到达组织配置的服务端点。如果是在个人环境下遇到这个报错很可能是配置文件里残留了之前企业环境的字段。打开~/.codex/config.toml把organization、org_id之类的字段删掉然后重启 Codex。如果删掉后还报错检查是否有环境变量CODEX_ORG_ID之类的设置用env | grep -i codex看一下。7.2 “codex破甲”与配置重置“codex破甲”这个说法在社区里通常指的是绕过某些限制或者重置配置。我不建议用非官方的方式去修改工具行为因为这样可能导致账号异常或工具不可用。如果你遇到了配置混乱的问题最稳妥的做法是备份现有配置然后删掉配置目录让工具重新生成默认配置。# 备份 Codex 配置 mv ~/.codex ~/.codex.bak # 重新运行 Codex它会生成新的默认配置 codex # 如果新配置能用再把旧配置里需要的字段手动迁移过来同样的方法也适用于 Claude Code。配置目录通常是~/.claude备份后重命名让工具重新初始化。这个“重置大法”能解决大部分因为配置字段冲突、版本升级导致的奇怪问题。7.3 Node.js 版本与工具兼容性的对照表工具最低 Node 版本推荐 Node 版本已知不兼容版本Claude Code18.x20.x LTS16.x 及以下Codex CLI18.x20.x LTS16.x 及以下cc switch18.x20.x LTS21.x 奇数版tmux不依赖 Node--这张表是我在实际使用中总结出来的。Node 20 LTS 是目前最稳的选择兼容性最好。Node 22 虽然也是 LTS但部分工具的依赖还没完全适配偶尔会遇到原生模块编译失败的问题。Node 18 能用但一些新版本的 CLI 工具开始要求 Node 20所以长远来看还是升到 20 比较省心。7.4 代理转发失败的通用排查步骤当你遇到“local proxy failed”这类报错时按以下步骤排查确认代理进程是否在运行ps aux | grep cc-switch或lsof -i :3456确认代理端口是否可达curl http://localhost:3456/health查看代理日志确认请求是否到达代理tail -f ~/.cc-switch/logs/proxy.log确认上游 API 是否可达用curl直接请求上游 API看是否返回正常确认请求格式是否匹配对比代理期望的格式和工具实际发送的格式确认 API Key 是否有效用上游 API 的测试端点验证 Key这个排查顺序是从本地到远程、从简单到复杂能帮你快速定位问题出在哪一环。大部分情况下问题都出在第 1 步或第 6 步——要么代理没启动要么 Key 过期了。8. 把 openrig 当成一套可复用的工作台来维护8.1 用脚本固化环境配置折腾完这一整套之后最怕的就是换机器或者重装系统后又要从头来一遍。我的做法是把所有配置步骤写成一个 shell 脚本放在 dotfiles 仓库里新机器上跑一遍脚本就能恢复环境。#!/bin/bash # setup-openrig.sh # 安装 nvm curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash export NVM_DIR$HOME/.nvm [ -s $NVM_DIR/nvm.sh ] \. $NVM_DIR/nvm.sh # 安装 Node 20 nvm install 20 nvm alias default 20 # 安装全局工具 npm install -g anthropic-ai/claude-code npm install -g openai/codex # 安装 tmux 并复制配置 sudo apt install -y tmux cp tmux.conf ~/.tmux.conf # 复制 Claude Code 和 Codex 配置模板 cp claude-config.json ~/.claude/config.json cp codex-config.toml ~/.codex/config.toml echo openrig 环境配置完成这个脚本不需要很复杂关键是把版本号、安装命令、配置文件路径都固化下来。下次换机器时改一下脚本里的用户名和路径跑一遍就能用。8.2 配置文件的版本管理Claude Code 和 Codex 的配置文件里可能包含 API Key所以不能直接提交到公开仓库。我的做法是配置文件里用占位符代替真实 Key然后用一个单独的secrets.sh文件存真实 Key这个文件加到.gitignore里。# secrets.sh不提交到仓库 export ANTHROPIC_API_KEYsk-ant-xxxx export OPENAI_API_KEYsk-xxxx export DEEPSEEK_API_KEYsk-xxxx然后在 shell 配置文件里source ~/.openrig/secrets.sh这样环境变量就自动加载了。Claude Code 和 Codex 都支持从环境变量读取 API Key所以配置文件里不需要写死 Key。8.3 定期更新与版本锁定AI 编程工具的更新频率很高有时候新版本会引入不兼容的变更。我的策略是日常使用锁定一个稳定版本每隔一两周主动更新一次更新前先看 release notes 有没有 breaking changes。如果更新后出问题用 npm 回退到上一个版本。# 查看当前版本 claude --version codex --version # 更新到最新版 npm update -g anthropic-ai/claude-code npm update -g openai/codex # 回退到指定版本 npm install -g anthropic-ai/claude-code1.0.0我自己的经验是不要在赶项目的时候更新工具。更新放在空闲时间做更新后跑一遍基本功能测试确认没问题再继续用。这样能把工具更新带来的风险降到最低。8.4 多模型切换的成本控制思路最后聊一下成本控制。Claude Code 和 Codex 的官方 API 都是按 token 计费的用多了成本不低。通过本地代理接入 DeepSeek、Qwen、GLM 这些第三方模型可以在一些不那么复杂的任务上降低成本。我的做法是复杂推理和代码生成用 Claude Code 或 Codex 的官方模型简单的代码解释、格式转换、注释生成用第三方模型。在 cc switch 的配置里可以设置路由规则比如根据请求的 token 数量或者关键词来决定走哪个上游。这样既能保证关键任务的质量又能在边缘任务上省钱。具体配置方式取决于 cc switch 的版本建议看它的文档里关于 routing rules 的部分。这套 openrig 工作台我用了几个月最大的感受是环境配置这件事一次投入时间把它做扎实后面每天都能省下折腾的时间。Node.js 版本、tmux 会话、代理转发、编辑器集成每一环都有坑但每一环的坑都有成熟的解法。把解法固化成脚本和配置你就有了一个真正属于自己的、可复用的 AI 编程工作台。
1. 从“openrig”这个名字说起它到底想解决什么问题第一次看到“openrig”这个词我脑子里蹦出来的不是某个具体软件而是一种“开放式工作台”的意象。rig 在英文里本意是“装配、搭建”在工程语境里常指一套成套的设备或支架比如测试台架、钻井平台。前面加个 open意思就很明确了——这是一套开放的、可自由拼装的工具台。结合热搜词里高频出现的 Claude Code、Codex、Node.js、tmux 这几个关键词我基本能判断出 openrig 的定位它大概率是一个把 AI 编程助手Claude Code、Codex 这类 CLI 工具和终端复用器tmux、运行时环境Node.js整合到一起的本地开发工作台方案。为什么我敢这么判断因为热搜词里有一大堆非常具体的报错和配置问题比如 “cc switch local proxy failed while handling codex endpoint /responses”、“error installing 24.21.0: node.js v24.21.0 is not yet released”、“codex is ignoring 1 unrecognized configuration setting”、“your organization has disabled claude subscription access for claude code”。这些不是普通用户会搜的词而是真正在本地折腾 AI 编程工具链的人才会遇到的坑。openrig 要做的就是把这些零散的工具、配置、代理转发、会话管理打包成一个可复用的“台架”让你不用每次换机器都从头配一遍。我自己的理解是openrig 的核心价值不在于发明新东西而在于“编排”。它把 Node.js 作为运行时底座把 Claude Code 和 Codex 作为两个可切换的 AI 后端把 tmux 作为会话保持层再通过一个本地代理层热搜词里的 cc switch、local proxy 就是线索来统一管理请求转发和模型路由。这样一来你可以在同一个终端窗口里用同一套快捷键随时在 Claude Code 和 Codex 之间切换甚至把请求转发到 DeepSeek、Qwen、GLM 这些第三方模型上。这对于需要频繁对比不同模型输出、或者想在本地模型和云端模型之间做成本控制的开发者来说是非常实用的。这篇文章适合谁看如果你正在用或者打算用 Claude Code、Codex 这类 CLI 编程助手并且被环境配置、代理转发、会话丢失、模型切换这些问题折磨过那这篇内容就是写给你的。如果你只是听说过这些工具但还没上手也没关系我会从最基础的 Node.js 环境讲起把每一步的意图和坑都说明白。下面我就按照一个真实搭建 openrig 工作台的思路把整个链路拆开来讲。2. 底座先行Node.js 环境为什么是整条链路的命门2.1 Node.js 版本选择的真实逻辑热搜词里有一条特别扎眼“error installing 24.21.0: node.js v24.21.0 is not yet released or is not available”。这个报错说明有人在安装 Node.js 时指定了一个还不存在的版本号。这背后反映的问题是很多人配环境时习惯性去搜“最新版 Node.js”然后照着某个教程里的版本号抄结果那个版本要么还没正式发布要么已经被标记为不稳定版。我的经验是做 AI 编程工具链的底座Node.js 版本选择要遵循“LTS 优先、偶数版本优先、不低于 18”三个原则。LTS 是长期支持版稳定性和兼容性都有保障偶数版本如 18、20、22是官方主推的稳定线奇数版本如 19、21、23是过渡版生命周期短容易遇到依赖不兼容不低于 18 是因为 Claude Code 和 Codex 的 CLI 工具普遍依赖较新的 ES 模块和 fetch APINode 16 及以下会直接报错。具体操作上我不建议直接去官网下载安装包双击安装而是用版本管理工具。在 macOS 和 Linux 上nvm是最成熟的选择在 Windows 上nvm-windows或者fnm都可以。用版本管理工具的好处是你可以随时切换 Node 版本不会因为某个工具要求 Node 20 而另一个要求 Node 22 就抓瞎。# macOS / Linux 安装 nvm curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash # 安装并切换到 Node 20 LTS nvm install 20 nvm use 20 nvm alias default 20 # 验证 node -v npm -vWindows 用户如果用 nvm-windows安装后需要以管理员身份运行命令并且注意安装路径不要有空格和中文否则会出现“node.js v24.21.0 is not yet released”这类看似版本问题、实则是路径解析失败的报错。2.2 npm 源与全局安装的权限坑Node.js 装好之后下一步是配置 npm 源。国内网络环境下默认源拉取包的速度可能很慢甚至超时。我一般会换成国内镜像源但要注意不是所有包都能在镜像源上找到最新版本尤其是 Claude Code 和 Codex 这种更新频繁的 CLI 工具。所以我的做法是日常用镜像源遇到版本不对时临时切回官方源。# 查看当前源 npm config get registry # 切换为国内镜像 npm config set registry https://registry.npmmirror.com # 临时用官方源安装某个包 npm install -g anthropic-ai/claude-code --registryhttps://registry.npmjs.org另一个高频坑是全局安装的权限问题。在 macOS 和 Linux 上如果不用 nvm 而是用系统自带的 Nodenpm install -g会往/usr/local/lib里写文件普通用户没有权限就会报 EACCES 错误。很多人这时候会用sudo npm install -g这虽然能装上但会导致后续所有全局包都属于 root普通用户运行时又会出现权限问题形成恶性循环。正确做法是用 nvm 管理 Node这样全局包会装到用户目录下完全避开权限问题。提示如果你已经用 sudo 装过全局包建议先卸载 Node改用 nvm 重装然后把之前用 sudo 装的包重新用普通用户装一遍。这个清理过程虽然麻烦但能避免后面无数奇怪的权限报错。2.3 验证 Node 环境是否真的可用装完 Node 和 npm 之后不要急着装 Claude Code 和 Codex先做三个验证node -v能输出版本号、npm -v能输出版本号、npm install -g一个小的测试包比如npm install -g cowsay能成功并且cowsay hello能运行。这三个都过了说明 Node 环境是健康的。如果cowsay装上了但运行报“command not found”那说明 npm 的全局 bin 目录没有加到 PATH 里需要手动加一下。# 查看 npm 全局 bin 目录 npm config get prefix # 把这个路径下的 bin 目录加到 PATH以 nvm 为例通常已经在 PATH 里了 export PATH$PATH:$(npm config get prefix)/bin这个验证步骤看起来多余但我见过太多人跳过它结果后面 Claude Code 装上了却运行不了回头排查半天才发现是 PATH 问题。先把底座验通后面的事就顺了。3. Claude Code 与 Codex 的安装两条路线同一套心法3.1 Claude Code 的安装与首次配置Claude Code 的安装本身不复杂官方推荐用 npm 全局安装。但热搜词里出现了“claude code安装”、“claude code windows”、“ubuntu配置claude code”、“vscode配置claude code”这么多变体说明不同平台、不同使用方式下的配置差异很大。# 全局安装 Claude Code npm install -g anthropic-ai/claude-code # 验证安装 claude --version安装完成后第一次运行claude会引导你登录。这里有个关键点Claude Code 需要访问 Anthropic 的 API登录方式通常是浏览器授权或者 API Key。如果你在终端环境里没有浏览器可以用 API Key 方式。API Key 的配置一般在~/.claude/config.json或者通过环境变量ANTHROPIC_API_KEY设置。热搜词里有一条“your organization has disabled claude subscription access for claude code”这个报错的意思是组织管理员关闭了 Claude Code 的订阅访问权限。如果你用的是公司账号需要联系管理员开通如果是个人账号检查一下订阅状态是否正常。这个报错跟本地环境无关纯粹是账号权限问题不要浪费时间在重装工具上。另一个高频问题是“note: claude code might not be available in your country”。这个提示出现时通常是因为网络环境导致 API 请求无法到达。我的建议是检查你的网络出口是否稳定以及是否有防火墙拦截了相关域名。如果是公司网络可能需要找 IT 开通白名单。3.2 Codex 的安装与配置陷阱Codex 的安装同样走 npm 路线但它的配置项比 Claude Code 更细碎。热搜词里“codex is ignoring 1 unrecognized configuration setting. check for typos or d”这个报错就是配置文件里写了 Codex 不认识的字段。Codex 的配置文件通常是~/.codex/config.toml或~/.codex/config.json具体格式取决于版本。# 安装 Codex CLI npm install -g openai/codex # 查看版本 codex --versionCodex 的配置里最容易出错的是模型名称和 endpoint 地址。如果你要接入第三方模型比如 DeepSeek、Qwen、GLM需要把 endpoint 指向对应的 API 地址并且模型名称要跟服务商文档里的一致。热搜词里“codex接入deepseek”就是一个典型场景。配置示例大概长这样# ~/.codex/config.toml model deepseek-chat api_base https://api.deepseek.com/v1 api_key your-api-key-here注意不同版本的 Codex 配置字段名可能不同有的用api_base有的用base_url有的用endpoint。如果你写了api_base但工具报“unrecognized configuration setting”那就说明这个版本用的是别的字段名。这时候不要瞎猜直接去看对应版本的官方文档或者用codex --help看支持的配置项。3.3 两个工具共存时的 PATH 与别名管理Claude Code 和 Codex 都装好后它们各自的可执行文件都在 npm 全局 bin 目录下。正常情况下不会冲突因为命令名不同claude和codex。但如果你之前装过旧版本或者用其他方式装过同名工具就可能出现which claude指向了错误的路径。我的做法是装完后立刻用which claude和which codex确认路径然后用claude --version和codex --version确认版本。如果路径不对检查 PATH 里是否有多个 Node 版本的 bin 目录把旧的清理掉。另外如果你经常需要在两个工具之间切换可以在 shell 配置文件里加别名比如alias ccclaude、alias cxcodex减少输入成本。但要注意别名不要跟已有命令冲突比如cc在某些系统上是 C 编译器的命令那就换个名字。4. tmux 会话保持让 AI 编程助手不再“断线重连”4.1 为什么 AI 编程助手需要 tmuxClaude Code 和 Codex 都是长时间运行的交互式 CLI 工具。你在里面跟 AI 对话、让它读代码、改文件这个过程可能持续几十分钟甚至几个小时。如果你是在 SSH 远程连接里跑这些工具网络一抖SSH 断了工具进程也就跟着断了之前的对话上下文全丢。即使你是在本地终端里跑不小心关了窗口进程也会被终止。tmux 解决的就是这个问题。它把终端会话和终端窗口解耦会话在后台持续运行你随时可以 attach 回去。对于 AI 编程助手这种“上下文很贵”的工具来说tmux 几乎是必备的。热搜词里 tmux 跟 Claude Code、Codex 一起出现说明已经有很多人意识到这个问题了。# 安装 tmuxUbuntu/Debian sudo apt install tmux # 安装 tmuxmacOS brew install tmux # 新建一个名为 ai-work 的会话 tmux new -s ai-work # 在会话里运行 Claude Code claude # 按 CtrlB 然后按 D 脱离会话工具继续在后台跑 # 重新连接会话 tmux attach -t ai-work4.2 tmux 配置里对 AI 工具最友好的几个选项默认的 tmux 配置对长时间滚动的 AI 对话输出不太友好历史缓冲区太小滚上去看不到之前的输出。我一般会改几个配置# ~/.tmux.conf # 增大历史缓冲区到 50000 行 set -g history-limit 50000 # 开启鼠标支持方便滚动和选择 set -g mouse on # 用更直观的前缀键可选默认是 CtrlB # set -g prefix C-a # bind C-a send-prefix # 窗口编号从 1 开始 set -g base-index 1 setw -g pane-base-index 1history-limit这个配置特别重要。Claude Code 和 Codex 的输出动辄几百行默认的 2000 行缓冲区很快就不够用了。改成 50000 之后你可以随时往上翻查看之前的代码建议和对话内容。mouse on则让你可以用鼠标滚轮滚动不用记复杂的快捷键。4.3 用 tmux 窗口管理多个 AI 会话tmux 的窗口window和面板pane机制可以让你在一个会话里同时跑多个 AI 工具。比如窗口 1 跑 Claude Code窗口 2 跑 Codex窗口 3 跑一个普通的 shell 用来执行命令。这样你可以在不同窗口之间快速切换对比两个 AI 工具对同一个问题的回答。# 在 tmux 会话里新建窗口 CtrlB c # 重命名当前窗口 CtrlB , # 在窗口之间切换 CtrlB 1 # 切换到窗口 1 CtrlB 2 # 切换到窗口 2 CtrlB n # 切换到下一个窗口 CtrlB p # 切换到上一个窗口 # 水平分割面板 CtrlB % # 垂直分割面板 CtrlB 我自己的习惯是左边面板跑 Claude Code右边面板跑一个 shell 用来执行 Claude Code 建议的命令。这样 AI 给出命令后我直接复制到右边执行不用切换窗口。这个工作流用熟了之后效率提升非常明显。注意tmux 会话里的环境变量可能跟你登录 shell 的环境变量不一致。如果你在 tmux 里运行 Claude Code 时报“command not found”先检查echo $PATH是否包含了 npm 全局 bin 目录。可以在~/.tmux.conf里加set -g update-environment PATH或者直接在 tmux 里手动 export。5. 本地代理与模型路由cc switch 和 local proxy 的实战逻辑5.1 为什么需要本地代理层热搜词里“cc switch local proxy failed while handling codex endpoint /responses”这个报错暴露了一个核心需求很多人希望用一个统一的本地代理来管理 Claude Code 和 Codex 的请求实现模型切换、请求转发、日志记录等功能。这个代理层通常跑在本地某个端口上Claude Code 和 Codex 的 endpoint 都指向这个本地地址由代理层决定把请求转发到哪个上游服务。这样做的好处有三个第一可以在不修改工具配置的情况下切换后端模型第二可以统一管理 API Key不用在每个工具里都配一遍第三可以记录请求日志方便排查问题和统计用量。5.2 cc switch 的工作机制与常见故障cc switch 从名字看是一个“Claude Code 切换器”它的核心功能应该是让 Claude Code 在不同的模型后端之间切换。结合热搜词“使用cc switch 接入 deepseek v4, qwen, glm等模型”可以推断它支持把 Claude Code 的请求转发到 DeepSeek、Qwen、GLM 等第三方模型。它的工作原理大概是在本地启动一个 HTTP 服务监听某个端口比如 3456然后把 Claude Code 的 API endpoint 配置成http://localhost:3456/v1/messages。当 Claude Code 发请求时cc switch 接收到请求根据配置把请求转换成目标模型能理解的格式转发到目标 API再把响应转换回 Claude Code 期望的格式。“local proxy failed while handling codex endpoint /responses”这个报错说明代理在处理 Codex 的/responses端点时失败了。可能的原因有几个代理版本不支持 Codex 的/responses路径请求体格式跟代理期望的不一致上游 API 返回了代理无法解析的响应。排查时先看代理的日志确认请求是否到达了代理以及代理转发出去后上游返回了什么。# 启动 cc switch假设命令是 cc-switch cc-switch --port 3456 --config ~/.cc-switch/config.json # 查看代理日志 tail -f ~/.cc-switch/logs/proxy.log # 测试代理是否可达 curl http://localhost:3456/health5.3 配置 Codex 走本地代理的完整步骤如果你想让 Codex 也走本地代理需要修改 Codex 的配置把 endpoint 指向代理地址。但 Codex 的配置格式跟 Claude Code 不同不能直接照搬。# ~/.codex/config.toml model gpt-4 api_base http://localhost:3456/v1 api_key dummy-key注意这里的api_key可以填任意值因为真正的 API Key 是在代理层配置的。代理层会根据请求的目标模型自动替换成对应的真实 Key。这样你就不用在 Codex 里存真实的 API Key安全性更好。配置完成后运行codex并发一条消息观察代理日志里是否有请求进来。如果日志里没有请求说明 Codex 没有走代理检查api_base是否写对了以及 Codex 是否重启了。如果日志里有请求但报错看错误信息是代理转发失败还是上游返回错误。提示本地代理的端口不要跟其他常用服务冲突。3456、7890、8080 这些端口经常被占用建议用 3456 或 4567 这类不太常见的端口。启动代理前先用lsof -i :3456检查端口是否被占用。6. 编辑器集成VS Code 里跑 Claude Code 的正确姿势6.1 VS Code 集成 Claude Code 的两种方式热搜词里“vscode配置claude code”、“vscode接入claude code”、“claude code for vs code”出现频率很高说明很多人希望在 VS Code 里直接用 Claude Code而不是在外部终端里跑来跑去。目前有两种主流方式一种是用 VS Code 的集成终端跑 Claude Code CLI另一种是装 Claude Code 的 VS Code 扩展在编辑器界面里直接交互。第一种方式最简单不需要装额外扩展。在 VS Code 里按Ctrl打开集成终端直接运行claude就行。但这种方式的问题是集成终端的环境变量可能跟外部终端不同如果 Claude Code 报“command not found”需要在 VS Code 的设置里配置terminal.integrated.env或者terminal.integrated.shellArgs。// VS Code settings.json { terminal.integrated.env.linux: { PATH: ${env:PATH}:/home/yourname/.nvm/versions/node/v20.11.0/bin }, terminal.integrated.env.osx: { PATH: ${env:PATH}:/Users/yourname/.nvm/versions/node/v20.11.0/bin } }第二种方式是装扩展。在 VS Code 扩展市场搜索“Claude Code”找到官方或社区维护的扩展安装后按提示配置 API Key。扩展的好处是可以在编辑器侧边栏里直接对话不用切换窗口。但扩展的更新频率可能跟不上 CLI 工具有时候 CLI 已经支持新功能了扩展还没跟上。6.2 在 VS Code 里用 Claude Code 执行终端命令热搜词里“claude code如何直接执行终端命令”是一个很实际的问题。Claude Code 本身有执行 shell 命令的能力但默认可能需要你确认。在 VS Code 集成终端里Claude Code 执行命令时输出会直接显示在同一个终端里你可以看到命令的执行结果。如果你希望 Claude Code 自动执行某些命令而不需要每次确认可以在配置里设置权限。但我要提醒一句自动执行命令有风险尤其是涉及文件删除、系统修改的命令。我的建议是日常开发中保持手动确认只在明确知道命令安全的情况下才开启自动执行。# 在 Claude Code 里执行终端命令的典型交互 帮我看看当前目录下有哪些文件 # Claude Code 会建议执行 ls -la # 你确认后它执行并返回结果6.3 VS Code 终端与 tmux 的配合如果你在 VS Code 集成终端里跑 Claude Code同时又想用 tmux 保持会话可以在集成终端里直接tmux attach到之前的会话。这样你既能在 VS Code 里编辑代码又能随时切到 Claude Code 的会话里查看进度。但要注意VS Code 集成终端对 tmux 的鼠标支持可能不如外部终端好。如果鼠标滚动有问题可以在 tmux 配置里关掉鼠标支持改用快捷键滚动。或者直接用 VS Code 终端自己的滚动条但那样只能滚动 VS Code 终端缓冲区的内容tmux 会话内部的历史还是需要用 tmux 的翻页模式CtrlB [来查看。7. 踩坑实录那些热搜词背后的真实故障与修复7.1 “codex无法加载组织设置”的排查链路这个报错通常出现在企业环境下Codex 尝试从组织配置中读取设置但失败了。排查链路是这样的先确认 Codex 是否配置了组织相关的字段比如organization或org_id然后确认当前登录的账号是否有权限访问该组织最后确认网络是否能到达组织配置的服务端点。如果是在个人环境下遇到这个报错很可能是配置文件里残留了之前企业环境的字段。打开~/.codex/config.toml把organization、org_id之类的字段删掉然后重启 Codex。如果删掉后还报错检查是否有环境变量CODEX_ORG_ID之类的设置用env | grep -i codex看一下。7.2 “codex破甲”与配置重置“codex破甲”这个说法在社区里通常指的是绕过某些限制或者重置配置。我不建议用非官方的方式去修改工具行为因为这样可能导致账号异常或工具不可用。如果你遇到了配置混乱的问题最稳妥的做法是备份现有配置然后删掉配置目录让工具重新生成默认配置。# 备份 Codex 配置 mv ~/.codex ~/.codex.bak # 重新运行 Codex它会生成新的默认配置 codex # 如果新配置能用再把旧配置里需要的字段手动迁移过来同样的方法也适用于 Claude Code。配置目录通常是~/.claude备份后重命名让工具重新初始化。这个“重置大法”能解决大部分因为配置字段冲突、版本升级导致的奇怪问题。7.3 Node.js 版本与工具兼容性的对照表工具最低 Node 版本推荐 Node 版本已知不兼容版本Claude Code18.x20.x LTS16.x 及以下Codex CLI18.x20.x LTS16.x 及以下cc switch18.x20.x LTS21.x 奇数版tmux不依赖 Node--这张表是我在实际使用中总结出来的。Node 20 LTS 是目前最稳的选择兼容性最好。Node 22 虽然也是 LTS但部分工具的依赖还没完全适配偶尔会遇到原生模块编译失败的问题。Node 18 能用但一些新版本的 CLI 工具开始要求 Node 20所以长远来看还是升到 20 比较省心。7.4 代理转发失败的通用排查步骤当你遇到“local proxy failed”这类报错时按以下步骤排查确认代理进程是否在运行ps aux | grep cc-switch或lsof -i :3456确认代理端口是否可达curl http://localhost:3456/health查看代理日志确认请求是否到达代理tail -f ~/.cc-switch/logs/proxy.log确认上游 API 是否可达用curl直接请求上游 API看是否返回正常确认请求格式是否匹配对比代理期望的格式和工具实际发送的格式确认 API Key 是否有效用上游 API 的测试端点验证 Key这个排查顺序是从本地到远程、从简单到复杂能帮你快速定位问题出在哪一环。大部分情况下问题都出在第 1 步或第 6 步——要么代理没启动要么 Key 过期了。8. 把 openrig 当成一套可复用的工作台来维护8.1 用脚本固化环境配置折腾完这一整套之后最怕的就是换机器或者重装系统后又要从头来一遍。我的做法是把所有配置步骤写成一个 shell 脚本放在 dotfiles 仓库里新机器上跑一遍脚本就能恢复环境。#!/bin/bash # setup-openrig.sh # 安装 nvm curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash export NVM_DIR$HOME/.nvm [ -s $NVM_DIR/nvm.sh ] \. $NVM_DIR/nvm.sh # 安装 Node 20 nvm install 20 nvm alias default 20 # 安装全局工具 npm install -g anthropic-ai/claude-code npm install -g openai/codex # 安装 tmux 并复制配置 sudo apt install -y tmux cp tmux.conf ~/.tmux.conf # 复制 Claude Code 和 Codex 配置模板 cp claude-config.json ~/.claude/config.json cp codex-config.toml ~/.codex/config.toml echo openrig 环境配置完成这个脚本不需要很复杂关键是把版本号、安装命令、配置文件路径都固化下来。下次换机器时改一下脚本里的用户名和路径跑一遍就能用。8.2 配置文件的版本管理Claude Code 和 Codex 的配置文件里可能包含 API Key所以不能直接提交到公开仓库。我的做法是配置文件里用占位符代替真实 Key然后用一个单独的secrets.sh文件存真实 Key这个文件加到.gitignore里。# secrets.sh不提交到仓库 export ANTHROPIC_API_KEYsk-ant-xxxx export OPENAI_API_KEYsk-xxxx export DEEPSEEK_API_KEYsk-xxxx然后在 shell 配置文件里source ~/.openrig/secrets.sh这样环境变量就自动加载了。Claude Code 和 Codex 都支持从环境变量读取 API Key所以配置文件里不需要写死 Key。8.3 定期更新与版本锁定AI 编程工具的更新频率很高有时候新版本会引入不兼容的变更。我的策略是日常使用锁定一个稳定版本每隔一两周主动更新一次更新前先看 release notes 有没有 breaking changes。如果更新后出问题用 npm 回退到上一个版本。# 查看当前版本 claude --version codex --version # 更新到最新版 npm update -g anthropic-ai/claude-code npm update -g openai/codex # 回退到指定版本 npm install -g anthropic-ai/claude-code1.0.0我自己的经验是不要在赶项目的时候更新工具。更新放在空闲时间做更新后跑一遍基本功能测试确认没问题再继续用。这样能把工具更新带来的风险降到最低。8.4 多模型切换的成本控制思路最后聊一下成本控制。Claude Code 和 Codex 的官方 API 都是按 token 计费的用多了成本不低。通过本地代理接入 DeepSeek、Qwen、GLM 这些第三方模型可以在一些不那么复杂的任务上降低成本。我的做法是复杂推理和代码生成用 Claude Code 或 Codex 的官方模型简单的代码解释、格式转换、注释生成用第三方模型。在 cc switch 的配置里可以设置路由规则比如根据请求的 token 数量或者关键词来决定走哪个上游。这样既能保证关键任务的质量又能在边缘任务上省钱。具体配置方式取决于 cc switch 的版本建议看它的文档里关于 routing rules 的部分。这套 openrig 工作台我用了几个月最大的感受是环境配置这件事一次投入时间把它做扎实后面每天都能省下折腾的时间。Node.js 版本、tmux 会话、代理转发、编辑器集成每一环都有坑但每一环的坑都有成熟的解法。把解法固化成脚本和配置你就有了一个真正属于自己的、可复用的 AI 编程工作台。
