1. 从openrig这个名字说起它到底想解决什么问题第一次看到openrig这个词我脑子里蹦出来的不是某个具体软件而是一种开放式工作台的意象。rig在英文里本意是装配、搭建、成套设备在工程语境里常指一套组合好的装置前面加个open意思就很明确了——这是一套开放式的、可自由拼装的工具组合。结合热搜词里高频出现的Claude Code、Codex、Node.js、tmux这几个关键词我基本能判断出openrig的定位它大概率是一个围绕AI编程助手Claude Code、Codex这类命令行智能体搭建的本地开发工作台方案把终端复用、运行时环境、模型接入这几件事串成一条可复用的流水线。为什么我敢这么判断因为热搜词里几乎全是安装踩坑类的长尾词node.js v24.21.0 is not yet released、codex无法加载组织设置、cc switch local proxy failed while handling codex endpoint、your organization has disabled claude subscription access……这些词拼在一起就是一幅非常典型的画面——一个开发者想在本地把Claude Code和Codex跑起来结果卡在Node版本、卡在代理转发、卡在组织权限、卡在模型不支持上。openrig要做的就是把这些零散的、容易出错的环节固化下来变成一套装好就能用的骨架。所以这篇内容我打算这么写不空谈概念而是把openrig背后这套工作台真正涉及的技术点一个个拆开——Node.js运行时怎么选版本、tmux为什么是刚需、Claude Code和Codex各自的接入逻辑有什么不同、本地模型比如LMStudio怎么接、代理转发失败到底卡在哪。适合谁看适合那些已经装过一遍但被各种报错劝退的人也适合还没动手、想先搞清楚整体架构再决定要不要投入时间的人。下面我按实际搭建顺序来讲每一步都告诉你为什么这么做而不是只丢命令。2. Node.js运行时整个工作台的地基也是最容易翻车的地方2.1 为什么版本选择比你想的更重要热搜里有一条特别扎眼error installing 24.21.0: node.js v24.21.0 is not yet released or is not available。这个报错我见过太多次了本质原因是有人照着某个教程里的版本号去装但那个版本要么还没正式发布要么在当前镜像源里根本不存在。Node.js的版本发布节奏是这样的偶数大版本号18、20、22是LTS长期支持版奇数版本19、21、23是过渡版生命周期很短。Claude Code和Codex这类工具对Node版本有硬性要求通常要求18以上很多新特性在20才稳定。我的建议很直接生产环境一律用LTS别追最新。目前稳妥的选择是Node.js 20 LTS或22 LTS。热搜里出现ubuntu安装node.js 20说明很多人是在Ubuntu上折腾那我们就以Ubuntu为主线讲。2.2 Ubuntu上装Node.js的三种方式与取舍第一种是系统包管理器直接装sudo apt install nodejs npm。这种方式最省事但问题在于Ubuntu仓库里的Node版本往往偏旧可能只有16或18跑新工具容易出兼容问题。我不推荐。第二种是用NodeSource的官方源这也是我个人最常用的方式curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt-get install -y nodejs装完用node -v和npm -v验证。这种方式的优点是版本可控、升级方便缺点是依赖网络到NodeSource的连通性。第三种是用nvmNode Version Manager做多版本管理。如果你同时要维护好几个项目有的要18有的要20nvm几乎是唯一优雅的解法curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install 20 nvm use 20 nvm alias default 20提示nvm装完后一定要执行source ~/.bashrc或者重开终端否则nvm命令找不到。这个坑我踩过当时以为是安装失败其实是环境变量没加载。2.3 npm全局目录权限一个被严重低估的坑很多人装完Node后一执行npm install -g就报EACCES权限错误。原因是npm默认的全局目录在系统路径下普通用户没写权限。网上流传的解法是sudo npm install -g但我不建议——用sudo装全局包会导致后续权限混乱甚至把root拥有的文件混进你的项目目录。正确做法是给npm配置一个用户级的全局目录mkdir -p ~/.npm-global npm config set prefix ~/.npm-global echo export PATH~/.npm-global/bin:$PATH ~/.bashrc source ~/.bashrc这样以后所有npm install -g都装到你自己家目录下不需要sudo也不会污染系统。这一步做完后面装Claude Code、Codex的CLI工具才不会卡在权限上。2.4 网络与镜像源别让下载拖垮你的耐心Node.js生态的包大多托管在境外国内直接拉取经常慢到怀疑人生。配置镜像源是常规操作npm config set registry https://registry.npmmirror.com如果你用的是nvmnvm本身下载Node二进制也需要走镜像可以在~/.bashrc里加export NVM_NODEJS_ORG_MIRRORhttps://npmmirror.com/mirrors/node这一步不是必须的但能显著减少卡在下载的时间。我实测下来配了镜像之后装一个CLI工具从几分钟缩短到十几秒。3. tmux为什么AI编程助手离不开终端复用3.1 单窗口跑长任务的痛点Claude Code和Codex这类工具的一个共同特点是它们经常需要长时间运行比如等待模型返回、执行多轮对话、跑一个耗时的代码生成任务。如果你直接在普通终端里跑一旦网络抖动、SSH断连、或者你不小心关了窗口整个会话就没了之前积累的上下文全部丢失。这就是tmux存在的意义。tmux是一个终端复用器它让你在一个物理终端里开多个虚拟窗口和面板而且这些会话可以脱离当前终端独立存在。你关掉SSH会话还在后台跑你重新连上来tmux attach一下一切照旧。3.2 tmux的核心概念session、window、pane刚接触tmux的人容易被这三个词绕晕我用一个类比解释session像一个办公室window像办公室里的办公桌pane像办公桌上切分的区域。你可以有多个办公室每个办公室多张桌子每张桌子切成几块。常用操作我列一下这些是每天都会用到的tmux new -s work # 新建一个叫work的会话 tmux ls # 列出所有会话 tmux attach -t work # 重新接入work会话 tmux kill-session -t work # 杀掉work会话进入tmux后默认前缀键是Ctrlb然后Ctrlb再按c新建windowCtrlb再按%垂直切分paneCtrlb再按水平切分paneCtrlb再按d脱离会话detachCtrlb再按方向键在pane之间切换3.3 把tmux和AI助手结合起来的实际布局我的习惯是这样一个session里开三个window。第一个window跑Claude Code第二个window跑Codex第三个window留给普通的shell操作git、查看日志、跑测试。这样我在跟AI对话的同时随时能切过去执行它建议的命令不用来回开新终端。更进一步我会把pane切分用起来左边大pane放AI对话右边小pane放一个tail -f盯着日志文件。AI改完代码我立刻能在右边看到日志变化反馈闭环非常快。注意tmux里的复制粘贴默认比较反直觉需要按住Shift再用鼠标选择或者配置set -g mouse on开启鼠标模式。这个配置建议写进~/.tmux.conf能省很多事。3.4 tmux会话的持久化与恢复tmux本身不解决机器重启后会话恢复的问题那需要tmux-resurrect这类插件。但对大多数本地开发场景来说只要机器不重启tmux会话就能一直活着。我一般会在.bashrc里加一句判断登录时如果没在tmux里就自动attachif command -v tmux /dev/null [ -n $PS1 ] [[ ! $TERM ~ screen ]] [[ ! $TERM ~ tmux ]] [ -z $TMUX ]; then tmux attach -t work || tmux new -s work fi这样每次SSH进来都自动回到我的工作台体验非常顺。4. Claude Code与Codex两条不同的接入路线4.1 两者的定位差异Claude Code和Codex虽然都是命令行AI编程助手但设计哲学不太一样。Claude Code更强调agent能力它能直接读写文件、执行终端命令、多轮自主完成任务Codex则更偏向代码补全和生成交互上更接近传统的对话式编程。热搜里claude code如何直接执行终端命令这个词说明很多人对它的执行能力感兴趣而codex无法加载组织设置则暴露了Codex在权限体系上的复杂性。理解这个差异很重要因为它决定了你接入时关注的重点不同Claude Code重点在运行时环境和权限Codex重点在账号组织和模型配置。4.2 Claude Code的安装与常见报错安装Claude Code通常通过npmnpm install -g anthropic-ai/claude-code装完后在项目目录里执行claude就能启动。但热搜里有个词很关键your organization has disabled claude subscription access for claude code。这个报错的意思是你的账号所属组织在管理后台关闭了Claude Code的访问权限。这不是技术问题是账号策略问题需要联系组织管理员开通或者换一个个人账号。另一个高频问题是cc switch local proxy failed while handling codex endpoint /responses。这个报错涉及代理转发通常出现在你用某个中转工具比如cc switch把请求转发到不同模型端点时。核心原因是转发工具在处理/responses这个端点时失败了可能是目标端点不支持这个路径也可能是请求格式不匹配。排查思路是先用curl直接打目标端点确认它到底支持哪些路径再回头看转发配置。4.3 Codex的安装与模型支持问题Codex的安装同样走npm或官方安装包热搜里codex安装 windows桌面版codex安装包codex官网下载说明它的分发渠道比较多。安装本身不难难的是配置。有个报错特别典型{detail:the gpt-5.6-sol model is not supported when using codex with a...}。这说的是你配置的模型名不被当前Codex版本支持。模型名这种东西更新很快教程里写的名字可能已经过时。解决办法是查官方文档里当前支持的模型列表别照抄老教程。还有codex is ignoring 1 unrecognized configuration setting. check for typos or d...这是配置文件里有拼写错误或者不认识的字段。Codex的配置文件对字段名很敏感一个字母错了就整个字段被忽略。我的经验是改配置后一定要看启动日志它会明确告诉你哪个字段被忽略了。4.4 接入第三方模型DeepSeek、Qwen、GLM的实践热搜里codex接入deepseek使用cc switch 接入 deepseek v4, qwen, glm等模型说明很多人不想只用官方模型而是想接国内可用的模型。这条路是可行的核心思路是这些工具大多支持自定义API endpoint你只要把endpoint指向兼容OpenAI格式的服务即可。以接入DeepSeek为例大致流程是拿到DeepSeek的API key和base URL在工具的配置里把base URL改成DeepSeek的地址把模型名改成DeepSeek支持的模型标识用一个小请求测试连通性这里最容易出问题的是请求格式兼容性。有些工具发的是Anthropic格式的请求而目标服务只认OpenAI格式中间就需要一个转换层。cc switch这类工具就是干这个的。但转换层本身也可能有bug比如前面提到的/responses端点处理失败就是转换层没覆盖到某个路径。提示接第三方模型时先用最朴素的curl测试目标端点确认它接受什么格式、返回什么结构再去配工具。跳过这一步直接配出错了你根本不知道是工具的问题还是服务的问题。5. 本地模型接入LMStudio与工作台的结合5.1 为什么要在本地跑模型热搜里claude code 调用lmstudio的本地模型是个很有意思的需求。本地模型的好处很实在不依赖网络、不消耗API额度、数据不出本机。对于日常的代码补全、简单重构、文档生成这类任务一个7B到14B的本地模型已经能应付。LMStudio的价值在于它把模型下载、加载、暴露API这几件事做成了一个图形界面对不熟悉命令行的用户很友好。5.2 LMStudio的API暴露与对接LMStudio启动后在设置里开启Local Server默认监听http://localhost:1234。它暴露的是OpenAI兼容的接口路径是/v1/chat/completions。这意味着任何支持自定义OpenAI endpoint的工具都能接它。对接时的关键配置项配置项值说明Base URLhttp://localhost:1234/v1注意结尾的/v1API Key任意非空字符串LMStudio不校验但工具通常要求非空ModelLMStudio里加载的模型标识在LMStudio界面能看到5.3 本地模型的性能边界与预期管理我必须泼一盆冷水本地模型和云端大模型的能力差距是客观存在的。一个14B的模型在复杂逻辑推理、长上下文理解上跟云端旗舰模型没法比。所以我的用法是分工简单的、重复性的、不涉及敏感逻辑的任务交给本地模型复杂的架构设计、疑难bug排查还是用云端模型。另外本地模型对显存要求高。7B模型量化后大概需要6-8GB显存14B需要12GB以上。如果你的机器显存不够模型会跑到内存里速度会慢到无法忍受。这一点在动手前一定要评估清楚。5.4 本地与云端混合使用的配置思路一个实用的做法是在工具里配置多个profile需要时切换。比如默认走本地LMStudio遇到搞不定的问题切到云端。有些工具支持通过环境变量切换endpoint这样你可以在tmux的不同window里跑不同配置互不干扰。6. 代理转发与端点兼容那些让人抓狂的报错怎么破6.1 代理转发失败的典型链路回到那个报错cc switch local proxy failed while handling codex endpoint /responses。要理解它得先知道请求是怎么走的。你的Codex客户端发请求到本地代理cc switch本地代理再把请求转发到真正的模型服务。失败发生在处理/responses端点这一步说明代理收到了一个针对/responses的请求但它不知道怎么处理。可能的原因有三类一是代理配置里没有为/responses配置转发规则二是目标服务不支持/responses这个路径有些服务只支持/chat/completions三是请求体格式和目标服务不匹配。6.2 逐步排查的完整方法我的排查顺序是这样的确认代理是否在监听curl http://localhost:端口/health或者看代理进程日志直接打目标端点绕过代理用curl直接请求目标服务的/responses看它返回什么对比请求格式把代理转发的请求体和目标服务文档里的示例对比看代理日志大多数代理工具会打印转发详情包括请求路径、状态码、错误信息这个顺序的核心逻辑是从外到内逐层排除先确认最外层通不通再往里查。很多人一上来就改配置结果越改越乱。6.3 端点路径映射的常见坑不同模型服务的API路径设计不一样。OpenAI风格是/v1/chat/completionsAnthropic风格是/v1/messages有些服务还有/v1/responses。当你的工具发的是A路径目标服务只认B路径时就需要在代理层做路径重写。配置路径重写时要注意不仅要改路径请求体的字段名也可能要改。比如OpenAI用messagesAnthropic用messages但结构不同有些服务用input。这些细节不处理请求就会被拒。6.4 一个可复用的调试配置模板我一般会准备一个最小化的调试配置只保留必要的转发规则把日志级别开到debug。这样出问题时日志里能看到完整的请求和响应。等跑通了再逐步加功能。这个最小可用配置先行的原则能帮你快速定位问题到底出在哪个环节而不是在一堆配置里大海捞针。7. 把这些串起来openrig工作台的完整搭建顺序7.1 从零到可用的步骤清单把前面所有内容串成一条线完整的搭建顺序是这样的装Node.js 20 LTS用nvm或NodeSource配好npm全局目录和镜像源装tmux配好.tmux.conf建立工作会话装Claude Code和Codex的CLI配置模型接入云端或本地LMStudio如果需要第三方模型配好代理转发在tmux里分window跑起来验证每个环节7.2 每一步的验证方法每一步做完都要验证不要攒到最后一起测。Node装完验证node -vtmux装完验证能新建和attach会话CLI装完验证--version能输出版本模型接入验证能发一个最简单的请求拿到回复。这种小步验证的习惯能让你在出问题时立刻知道是哪一步引入的。7.3 我踩过的几个真实坑第一个坑是npm全局权限前面讲过了用用户级prefix解决。第二个坑是tmux里环境变量不加载导致CLI找不到API key解决办法是在.tmux.conf里加set-option -g update-environment或者在启动脚本里显式source。第三个坑是代理转发时端口冲突本地已经有服务占了同一个端口代理起不来但报错很隐晦用lsof -i:端口能快速确认。7.4 日常使用中的效率习惯工作台搭好之后效率提升的关键在习惯。我的习惯是所有AI对话都在tmux里跑绝不直接在裸终端里开配置文件统一放在一个目录下用git管理换机器时直接clone每个项目的AI会话单独开一个tmux session避免上下文串味。这些小习惯积累起来能省下大量重复配置的时间。8. 关于openrig这类工作台的一点个人看法折腾这套东西的过程中我最大的体会是工具本身不难难的是环境。Claude Code、Codex这些工具的设计都很精巧但它们的运行依赖一整套底层设施——Node运行时、终端复用、网络转发、模型服务。任何一个环节出问题表现出来都是工具用不了但根因可能在完全不同的地方。所以我的建议是别急着追新工具先把地基打牢。Node版本管理、tmux使用、代理调试这三项技能一旦掌握后面不管出什么新工具你都能快速接上。openrig这个名字里的open我觉得很有意义——它暗示的是一种开放、可组合的思路而不是一个封闭的、什么都替你搞定的黑盒。真正好用的工作台一定是你自己一点点拼出来、完全理解每个部件作用的那一套。最后分享一个我最近养成的习惯每次解决一个报错就把排查过程和最终解法记到一个markdown文件里。几个月下来这个文件成了我自己的报错字典再遇到类似问题搜一下就有答案比重新排查快得多。这个习惯对任何折腾技术环境的人都值得试试。