1. 从 openrig 这个名字说起它到底想解决什么问题第一次看到 openrig 这个标题我下意识把它拆成了 open 和 rig 两个部分。open 不用多说开源、开放rig 这个词在工程圈里通常指“成套装置”或者“装配好的工作台”比如测试台架、实验装置。把这两个词拼在一起openrig 给我的第一直觉就是一套开放的、可自由装配的工具台架。结合热搜词里高频出现的 Claude Code、Codex、YAML、npm 这些关键词我基本能判断出openrig 大概率是围绕 AI 编程助手Claude Code、Codex 这类命令行智能体做配置管理、环境装配、多工具切换的一套开源方案。为什么我会这么判断因为热搜词里有一大堆非常具体的痛点信号cc switch local proxy failed while handling codex endpoint /responses、your organization has disabled claude subscription access for claude code、claude code 调用 lmstudio 的本地模型、codex 接入 deepseek、vscode 配置 claude code、npm 国内源、npm 环境变量 path 配置。这些词单独看是零散的问题但放在一起就勾勒出一个非常清晰的场景一个开发者想在自己的机器上同时用好几个 AI 编程工具结果被安装、配置、代理、模型接入、环境变量这些琐事反复折磨。openrig 要做的就是把这些零散的配置动作收敛成一套可复用、可版本化、可分享的“装配方案”。所以这篇博文我不打算把它写成一份干巴巴的说明书而是按照一个真实从业者的思路把 openrig 这类项目背后的设计逻辑、核心机制、实操步骤、踩坑经验完整地拆一遍。不管你是刚听说 Claude Code 想上手的新人还是已经在用 Codex、被各种 YAML 配置搞得头大的老手都能从里面找到能直接抄作业的东西。核心关键词 openrig、Claude Code、Codex、YAML、npm 会自然地贯穿全文我不会为了堆词而堆词。先说清楚适用人群如果你只是偶尔用网页版 AI 聊天这篇可能对你偏重但只要你动过“把 AI 编程助手装进终端、接进编辑器、连上本地模型”的念头或者你已经被 npm 报错、YAML 缩进、代理转发失败折腾过那这篇就是写给你的。openrig 的价值不在于它本身多复杂而在于它把一堆“看起来简单、做起来全是坑”的配置工作变成了一份可以照着走的路线图。2. openrig 的整体设计思路与方案选型2.1 为什么是“装配台架”而不是“一键脚本”很多人第一反应会问为什么不直接写个一键安装脚本非要搞成 openrig 这种带配置文件的“台架”我实际折腾过一键脚本也维护过配置文件方案结论很明确一键脚本适合一次性、单环境的场景而 AI 编程工具的配置是典型的多环境、多工具、多模型场景脚本根本扛不住。举个最直接的例子。热搜词里同时出现了claude code 调用 lmstudio 的本地模型和codex 接入 deepseek。这意味着同一个开发者可能白天用云端模型跑 Claude Code晚上切到本地 LM Studio 跑离线任务中间还要让 Codex 走 DeepSeek 的接口。这三种组合的 endpoint、鉴权方式、模型名、上下文长度都不一样。如果写成一键脚本你得写三套分支改一个参数就要动脚本逻辑越改越乱。openrig 的思路是把“工具”“模型”“环境”三个维度解耦用声明式的配置文件大概率是 YAML来描述组合关系。YAML 的好处在这里体现得淋漓尽致它是纯数据不带逻辑改配置不会引入代码 bug它可读性强团队里谁都能看懂它天然适合做版本管理配置改错了 git diff 一眼就能看出来。热搜里yolov10 yaml 文件怎么创建、rstudio 的 yaml 在哪里这些词也侧面说明YAML 作为配置载体已经是跨领域的通用选择openrig 选它并不意外。提示声明式配置的核心价值是“描述你要什么”而不是“描述你怎么做”。一旦你习惯了这种思维配置的复用性和可维护性会有质的提升。2.2 工具、模型、环境三层解耦的具体含义我把 openrig 这类方案的心智模型总结成三层理解了这三层后面所有配置你都能自己推导出来。第一层是工具层也就是 Claude Code、Codex 这些命令行智能体本身。它们各自有安装方式热搜里claude code 安装、codex 安装教程、npm 安装反复出现、启动命令、配置文件位置。工具层的关键是“版本”和“入口”你要清楚每个工具装在哪、怎么被调用。第二层是模型层也就是工具背后真正干活的模型。它可能是云端的 Claude、也可能是本地 LM Studio 暴露的 OpenAI 兼容接口还可能是 DeepSeek 这类第三方服务。模型层的关键是 endpoint、API Key、模型标识符、以及请求格式比如/responses还是/chat/completions。热搜里那个cc switch local proxy failed while handling codex endpoint /responses就是典型的模型层和工具层对接出错。第三层是环境层包括 Node.js 版本、npm 全局路径、环境变量 PATH、代理设置、shell 类型PowerShell 还是 bash。热搜里npm 环境变量 path 配置、npm : 无法加载文件 d:\program files\nodejs\npm.ps1因为在此系统上禁止运行脚本全是环境层的坑。环境层最容易被忽视但它恰恰是 90% 安装失败的根源。openrig 的设计精髓就在于它不试图把这三层揉成一个黑盒而是让每一层都独立可配、可替换。你换模型不用动工具配置换工具不用重装环境这才是“台架”相对于“脚本”的本质优势。2.3 选型背后的取舍为什么绕不开 npm热搜词里 npm 出现的频率极高npm 国内源、npm install -g pnpm 报错、npm warn eresolve overriding peer dependency、npm 卸载全局包、发布 npm 包等等。这说明 openrig 生态里的工具绝大多数是通过 npm 分发的。Claude Code 和 Codex 这类工具官方主推的安装方式就是 npm 全局安装。为什么是 npm 而不是别的因为这类 AI 编程助手本质上是 Node.js 写的 CLI 工具npm 是 Node 生态最成熟的包管理器一条npm install -g就能把命令注册到全局 PATH。但 npm 也带来了它固有的麻烦全局路径权限、镜像源速度、PowerShell 执行策略、peer dependency 冲突。这些不是 openrig 的锅而是整个 Node CLI 生态的通病。我的建议是在 openrig 的环境层里把 npm 的配置也纳入管理固定 registry 为国内源、明确全局安装目录、在 Windows 上提前处理好 PowerShell 执行策略。这样后面装任何工具都不会再被环境问题打断。具体怎么做我在第 3 章会给出可直接复制的命令。3. 核心细节解析与实操要点3.1 YAML 配置文件的结构设计openrig 的配置文件是整个方案的大脑我根据这类项目的常见实践推断它的 YAML 结构大致会分成几个顶层块tools、models、env、profiles。下面这份是我基于常见实践整理出来的参考结构你可以直接拿去改。# openrig 配置参考结构 tools: claude-code: install: npm install -g anthropic-ai/claude-code command: claude config_path: ~/.claude/settings.json codex: install: npm install -g openai/codex command: codex config_path: ~/.codex/config.yaml models: local-lmstudio: endpoint: http://127.0.0.1:1234/v1 api_key: lm-studio model: local-model format: openai deepseek: endpoint: https://api.deepseek.com/v1 api_key: ${DEEPSEEK_API_KEY} model: deepseek-chat format: openai env: npm_registry: https://registry.npmmirror.com node_version: 20.x profiles: daily: tool: claude-code model: local-lmstudio cloud: tool: codex model: deepseek这份结构里最值得说的是profiles块。它把“用哪个工具 连哪个模型”打包成一个命名组合切换时只需要指定 profile 名不用手动改一堆参数。这就是解耦带来的直接收益。热搜里cc switch这个词暗示存在某种切换机制profile 就是最自然的实现方式。注意YAML 对缩进极其敏感必须用空格不能用 Tab。我见过太多人因为编辑器自动把 Tab 转成空格、或者混用两者导致解析报错却找不到原因。建议在编辑器里开启“显示空白字符”一眼就能看出缩进问题。3.2 模型接入的关键参数与格式差异模型接入是 openrig 里最容易出错的部分热搜里那个local proxy failed while handling codex endpoint /responses就是活生生的例子。问题的根源在于不同工具对模型接口的请求格式要求不一样。Claude Code 原生走的是 Anthropic 的接口格式而 Codex 走的是 OpenAI 的/responses或/chat/completions格式。当你把一个 OpenAI 兼容的本地模型比如 LM Studio接到 Codex 上时格式基本能对上但如果你想让 Claude Code 去调本地模型中间往往需要一个转换层把 Anthropic 格式翻译成 OpenAI 格式。这个转换层就是热搜里说的 “local proxy”。我在实操中总结出一个判断口诀先看工具原生说什么格式再看模型提供什么格式两者不一致就必须加转换层。转换层可以是 openrig 内置的也可以是独立的代理进程。参数上要特别注意这几个参数作用常见坑endpoint模型服务地址本地服务常写成 localhost容器里要用宿主 IPapi_key鉴权凭证本地模型常随便填但有些工具会校验非空model模型标识符必须和服务端注册的名字完全一致format请求格式openai / anthropic 混用会直接 404max_tokens最大输出设太大可能被服务端拒绝max_tokens这个参数特别容易被忽略。本地模型如果显存有限你请求一个很大的输出长度服务端可能直接报错或者截断。我的经验是本地模型先设 2048 试水跑通了再往上加。3.3 环境变量与 PATH 的配置要点环境层是 openrig 里最“脏”的部分因为它和操作系统强相关。热搜里npm 环境变量 path 配置、node 安装后 npm 不能用、npm : 无法加载文件 c:\program files\nodejs\npm.ps1全是这一层的典型问题。在 Windows 上npm 全局安装的工具默认放在%APPDATA%\npm这个目录必须加到 PATH 里否则你装完工具在终端里敲命令会提示“不是内部或外部命令”。很多人装完 Node.js 就以为万事大吉结果 npm 全局包的命令一个都用不了就是漏了这一步。PowerShell 的执行策略是另一个大坑。Windows 默认禁止运行.ps1脚本而 npm 在 PowerShell 里恰恰是通过npm.ps1来执行的于是就出现了热搜里那个因为在此系统上禁止运行脚本的报错。解决办法是以管理员身份运行 PowerShell执行Set-ExecutionPolicy RemoteSigned然后确认。这一步做完npm 命令才能正常跑。在 macOS 和 Linux 上问题通常出在 Node 版本管理器nvm、fnm和系统自带 Node 的冲突。我的做法是统一用 nvm 管理 Node 版本全局包跟着 nvm 的版本走避免权限问题。openrig 的 env 块里固定 node_version就是为了让团队所有人的环境一致减少“在我机器上能跑”的扯皮。4. 实操过程与核心环节实现4.1 从零搭建 openrig 环境的完整流程这一节我把整个搭建过程按顺序走一遍你可以直接照着敲。我假设你是一台干净的机器Windows 和 macOS/Linux 的差异我会分别标注。第一步安装 Node.js。推荐用版本管理器而不是官网安装包因为版本管理器能让你随时切换 Node 版本也不会污染系统目录。macOS/Linux 用 nvmWindows 可以用 nvm-windows。装完后执行node -v和npm -v确认版本Node 建议 20.x 起步太老的版本跑新工具会报语法错误。第二步配置 npm 国内源。这一步能极大提升安装速度热搜里npm 国内源、npm 镜像源地址就是大家在找这个。执行npm config set registry https://registry.npmmirror.com npm config get registry第二条命令用来确认设置生效。如果你在公司内网可能需要额外的代理配置这个按公司规范来。第三步处理 Windows 的 PowerShell 执行策略仅 Windows。以管理员身份打开 PowerShellSet-ExecutionPolicy RemoteSigned -Scope CurrentUser用-Scope CurrentUser避免影响系统全局更安全。执行完可以用Get-ExecutionPolicy确认。第四步确认 npm 全局目录在 PATH 里。执行npm config get prefix看全局目录在哪然后检查这个目录是否在 PATH 中。Windows 上通常是%APPDATA%\npmmacOS/Linux 上通常是 nvm 对应的 bin 目录。第五步安装 openrig 本身和它管理的工具。如果 openrig 是通过 npm 分发的命令大概是npm install -g openrig openrig initopenrig init会生成一份默认的 YAML 配置你在这个基础上改就行。第六步编辑配置文件填入你的模型 endpoint 和 API Key。API Key 建议用环境变量引用如${DEEPSEEK_API_KEY}不要明文写在 YAML 里避免不小心提交到 git。第七步用openrig doctor或类似的诊断命令检查环境。这类项目一般都会提供自检功能把 Node 版本、npm 源、PATH、配置文件语法、模型连通性都过一遍。如果自检全绿基本就能用了。4.2 接入本地模型与云端模型的实操差异接入本地 LM Studio 模型和接入云端 DeepSeek操作上有几个关键差异我分开说。本地模型这边第一步是在 LM Studio 里启动本地服务默认端口 1234接口路径是/v1。启动后先用 curl 测一下curl http://127.0.0.1:1234/v1/models如果返回模型列表说明服务正常。然后在 openrig 配置里把 endpoint 指向这个地址api_key 随便填一个非空字符串本地服务通常不校验model 填 LM Studio 里加载的模型名。这里有个细节LM Studio 的模型名可能很长带路径和量化后缀必须一字不差地填进配置否则会报模型不存在。云端模型这边以 DeepSeek 为例你需要先去官网申请 API Key然后设置环境变量export DEEPSEEK_API_KEY你的keyWindows PowerShell 里用$env:DEEPSEEK_API_KEY你的key。配置里 endpoint 填https://api.deepseek.com/v1model 填deepseek-chat。云端模型的响应速度受网络影响如果超时频繁可以在配置里调大 timeout 参数。两者的共同点是都走 OpenAI 兼容格式所以 openrig 里可以用同一套 format 配置。差异主要在鉴权和网络本地模型无鉴权、低延迟、但能力受限于本地硬件云端模型需要 key、有网络延迟、但模型能力更强。我的建议是日常轻量任务用本地复杂任务切云端profile 机制正好支持这种切换。4.3 多工具切换的配置与验证openrig 最实用的功能之一就是多工具切换。假设你配置了daily和cloud两个 profile切换命令可能是openrig use daily openrig use cloud切换后openrig 会更新对应工具的配置文件把 endpoint、model、api_key 写进去。这里有个关键点切换不是简单改个环境变量而是要真正改写 Claude Code 或 Codex 的配置文件因为这两个工具启动时读的是自己的配置不认 openrig 的环境变量。验证切换是否生效最直接的办法是启动工具后问一个只有特定模型才知道的问题或者看工具的启动日志里打印的 endpoint。我习惯在切换后跑一条简单请求确认返回正常再开始正式工作。热搜里cc switch相关的报错很多就是切换后配置没写对、或者代理进程没重启导致的。提示切换 profile 后如果工具行为异常先检查工具的配置文件是否真的被更新了。有些工具会缓存配置需要重启进程才生效。5. 常见问题与排查技巧实录5.1 安装阶段的典型报错与解决安装阶段的问题占了热搜词的一大半我挑几个最高频的逐个拆解。npm : 无法加载文件 ... npm.ps1因为在此系统上禁止运行脚本。这是 Windows PowerShell 执行策略问题前面说过用Set-ExecutionPolicy RemoteSigned -Scope CurrentUser解决。如果公司策略不允许改可以改用 CMD 或者 Git Bash 来执行 npm 命令绕开 PowerShell。npm install -g pnpm 报错和npm warn eresolve overriding peer dependency。前者通常是权限问题或网络问题先确认 registry 是国内源再确认全局目录有写权限。后者是 peer dependency 冲突警告多数情况下不影响使用但如果安装真的失败了可以加--legacy-peer-deps参数绕过。error: cannot find module npmcli/config。这是 npm 自身损坏的典型症状通常是升级 npm 过程中断导致的。解决办法是重装 Node用版本管理器最方便或者用npm install -g npmlatest强制重装 npm。node 安装后 npm 不能用。八成是 PATH 没配好或者装了多个 Node 版本导致冲突。用which nodemacOS/Linux或where nodeWindows看实际调用的是哪个再决定怎么修。5.2 运行阶段的连接与格式问题运行阶段最典型的就是热搜里那个local proxy failed while handling codex endpoint /responses。这个报错拆开看Codex 在往/responses这个 endpoint 发请求但代理层处理失败了。可能的原因有三个代理没启动、代理配置的转发目标不对、或者请求格式和代理预期的不匹配。排查顺序我建议这样先确认代理进程在跑ps或任务管理器看再用 curl 直接打代理端口看返回最后看代理日志里具体的错误信息。如果是格式不匹配就要检查代理是不是支持/responses这个路径有些老版本代理只支持/chat/completions。your organization has disabled claude subscription access for claude code这个提示说明账号层面的订阅权限被限制了这不是本地配置能解决的需要联系账号管理员或者换用其他鉴权方式。遇到这类问题不要死磕本地配置先确认账号权限。模型返回空结果或者乱码通常是 model 名字填错或者 max_tokens 设得太小。我遇到过一次模型名里多了个空格排查了半小时才发现。所以配置里的字符串一定要仔细核对。5.3 常见问题速查表报错/现象可能原因解决方向npm.ps1 禁止运行PowerShell 执行策略Set-ExecutionPolicy RemoteSigned命令找不到全局目录不在 PATH把 npm prefix 加入 PATHpeer dependency 警告依赖版本冲突加 --legacy-peer-depscannot find modulenpm 自身损坏重装 Node 或 npmproxy failed /responses代理未启动或格式不符检查代理进程和路径支持模型返回空model 名错误核对服务端模型标识符连接超时网络或 endpoint 错误curl 直测 endpoint订阅权限被禁账号层面限制联系管理员或换鉴权这张表我建议存下来遇到问题先对号入座能省下大量搜索时间。5.4 我踩过的几个坑和独家经验第一个坑是 YAML 里的环境变量引用。我一开始以为${VAR}在所有工具里都能自动展开结果发现有些工具不认必须用工具自己的语法。后来我统一改成在启动脚本里先 export再让配置文件读环境兼容性最好。第二个坑是本地模型的端口冲突。LM Studio 默认 1234但有些其他服务也占这个端口导致连不上。我的做法是给本地模型服务固定一个不常用的端口比如 18080写死在配置里避免冲突。第三个坑是切换 profile 后忘记重启工具。Claude Code 和 Codex 都是长驻进程配置文件改了但进程没重启读的还是旧配置。后来我在 openrig 的切换逻辑里加了一步自动重启省心很多。第四个坑是 API Key 泄露。我早期图省事把 key 明文写在 YAML 里结果提交到了公开仓库。虽然及时发现删了但教训深刻。现在所有 key 一律走环境变量YAML 里只留引用。第五个坑是 Node 版本不一致。团队里有人用 18有人用 22同一个工具在 18 上跑不起来。后来我们在 openrig 的 env 块里锁死 Node 版本并在文档里写明问题才消失。6. 把 openrig 用出长期价值的几个思路openrig 这类方案真正的价值不在于装好那一刻而在于长期使用中的可维护性。我分享几个让它越用越顺的思路。第一把配置文件纳入 git 管理但用.gitignore排除含密钥的文件。我的做法是配置分两层一层是团队共享的模板不含密钥一层是本地的覆盖文件含密钥被忽略。这样新人 clone 下来改几个 key 就能用。第二给每个 profile 写一句注释说明用途。比如daily是本地快速问答cloud是复杂重构任务。过几个月回头看没有注释的配置你根本想不起来当初为什么这么设。第三定期跑一次openrig doctor做体检。Node 版本升级、npm 源变更、模型服务地址调整这些变化都会让配置失效定期体检能提前发现问题。第四把常见报错和解决过程记在自己的笔记里。热搜词里那些问题本质上都是别人踩过的坑你踩过一次记下来下次就是几分钟的事。我自己的笔记里已经攒了几十条比任何官方文档都管用。第五关注工具的更新节奏。Claude Code 和 Codex 这类工具迭代很快配置格式可能变。openrig 的抽象层能缓冲一部分变化但底层工具的 breaking change 还是要留意。我的习惯是每次升级前先看 changelog确认配置格式没变再升。最后分享一个小技巧如果你同时用多个 AI 编程工具给它们分配不同的终端标签页或者窗口配合 openrig 的 profile 切换能避免“这个窗口用的是哪个模型”的混乱。我现在的布局是左边 Claude Code 跑本地模型做快速补全右边 Codex 连云端做复杂任务互不干扰效率比单工具高不少。这套东西说到底就是一句话把配置当代码管把环境当资产维护。openrig 提供的只是一个骨架真正让它好用的是你对每一层细节的理解和持续打磨。
openrig 实战：用 YAML 装配 Claude Code 与 Codex 多模型环境
1. 从 openrig 这个名字说起它到底想解决什么问题第一次看到 openrig 这个标题我下意识把它拆成了 open 和 rig 两个部分。open 不用多说开源、开放rig 这个词在工程圈里通常指“成套装置”或者“装配好的工作台”比如测试台架、实验装置。把这两个词拼在一起openrig 给我的第一直觉就是一套开放的、可自由装配的工具台架。结合热搜词里高频出现的 Claude Code、Codex、YAML、npm 这些关键词我基本能判断出openrig 大概率是围绕 AI 编程助手Claude Code、Codex 这类命令行智能体做配置管理、环境装配、多工具切换的一套开源方案。为什么我会这么判断因为热搜词里有一大堆非常具体的痛点信号cc switch local proxy failed while handling codex endpoint /responses、your organization has disabled claude subscription access for claude code、claude code 调用 lmstudio 的本地模型、codex 接入 deepseek、vscode 配置 claude code、npm 国内源、npm 环境变量 path 配置。这些词单独看是零散的问题但放在一起就勾勒出一个非常清晰的场景一个开发者想在自己的机器上同时用好几个 AI 编程工具结果被安装、配置、代理、模型接入、环境变量这些琐事反复折磨。openrig 要做的就是把这些零散的配置动作收敛成一套可复用、可版本化、可分享的“装配方案”。所以这篇博文我不打算把它写成一份干巴巴的说明书而是按照一个真实从业者的思路把 openrig 这类项目背后的设计逻辑、核心机制、实操步骤、踩坑经验完整地拆一遍。不管你是刚听说 Claude Code 想上手的新人还是已经在用 Codex、被各种 YAML 配置搞得头大的老手都能从里面找到能直接抄作业的东西。核心关键词 openrig、Claude Code、Codex、YAML、npm 会自然地贯穿全文我不会为了堆词而堆词。先说清楚适用人群如果你只是偶尔用网页版 AI 聊天这篇可能对你偏重但只要你动过“把 AI 编程助手装进终端、接进编辑器、连上本地模型”的念头或者你已经被 npm 报错、YAML 缩进、代理转发失败折腾过那这篇就是写给你的。openrig 的价值不在于它本身多复杂而在于它把一堆“看起来简单、做起来全是坑”的配置工作变成了一份可以照着走的路线图。2. openrig 的整体设计思路与方案选型2.1 为什么是“装配台架”而不是“一键脚本”很多人第一反应会问为什么不直接写个一键安装脚本非要搞成 openrig 这种带配置文件的“台架”我实际折腾过一键脚本也维护过配置文件方案结论很明确一键脚本适合一次性、单环境的场景而 AI 编程工具的配置是典型的多环境、多工具、多模型场景脚本根本扛不住。举个最直接的例子。热搜词里同时出现了claude code 调用 lmstudio 的本地模型和codex 接入 deepseek。这意味着同一个开发者可能白天用云端模型跑 Claude Code晚上切到本地 LM Studio 跑离线任务中间还要让 Codex 走 DeepSeek 的接口。这三种组合的 endpoint、鉴权方式、模型名、上下文长度都不一样。如果写成一键脚本你得写三套分支改一个参数就要动脚本逻辑越改越乱。openrig 的思路是把“工具”“模型”“环境”三个维度解耦用声明式的配置文件大概率是 YAML来描述组合关系。YAML 的好处在这里体现得淋漓尽致它是纯数据不带逻辑改配置不会引入代码 bug它可读性强团队里谁都能看懂它天然适合做版本管理配置改错了 git diff 一眼就能看出来。热搜里yolov10 yaml 文件怎么创建、rstudio 的 yaml 在哪里这些词也侧面说明YAML 作为配置载体已经是跨领域的通用选择openrig 选它并不意外。提示声明式配置的核心价值是“描述你要什么”而不是“描述你怎么做”。一旦你习惯了这种思维配置的复用性和可维护性会有质的提升。2.2 工具、模型、环境三层解耦的具体含义我把 openrig 这类方案的心智模型总结成三层理解了这三层后面所有配置你都能自己推导出来。第一层是工具层也就是 Claude Code、Codex 这些命令行智能体本身。它们各自有安装方式热搜里claude code 安装、codex 安装教程、npm 安装反复出现、启动命令、配置文件位置。工具层的关键是“版本”和“入口”你要清楚每个工具装在哪、怎么被调用。第二层是模型层也就是工具背后真正干活的模型。它可能是云端的 Claude、也可能是本地 LM Studio 暴露的 OpenAI 兼容接口还可能是 DeepSeek 这类第三方服务。模型层的关键是 endpoint、API Key、模型标识符、以及请求格式比如/responses还是/chat/completions。热搜里那个cc switch local proxy failed while handling codex endpoint /responses就是典型的模型层和工具层对接出错。第三层是环境层包括 Node.js 版本、npm 全局路径、环境变量 PATH、代理设置、shell 类型PowerShell 还是 bash。热搜里npm 环境变量 path 配置、npm : 无法加载文件 d:\program files\nodejs\npm.ps1因为在此系统上禁止运行脚本全是环境层的坑。环境层最容易被忽视但它恰恰是 90% 安装失败的根源。openrig 的设计精髓就在于它不试图把这三层揉成一个黑盒而是让每一层都独立可配、可替换。你换模型不用动工具配置换工具不用重装环境这才是“台架”相对于“脚本”的本质优势。2.3 选型背后的取舍为什么绕不开 npm热搜词里 npm 出现的频率极高npm 国内源、npm install -g pnpm 报错、npm warn eresolve overriding peer dependency、npm 卸载全局包、发布 npm 包等等。这说明 openrig 生态里的工具绝大多数是通过 npm 分发的。Claude Code 和 Codex 这类工具官方主推的安装方式就是 npm 全局安装。为什么是 npm 而不是别的因为这类 AI 编程助手本质上是 Node.js 写的 CLI 工具npm 是 Node 生态最成熟的包管理器一条npm install -g就能把命令注册到全局 PATH。但 npm 也带来了它固有的麻烦全局路径权限、镜像源速度、PowerShell 执行策略、peer dependency 冲突。这些不是 openrig 的锅而是整个 Node CLI 生态的通病。我的建议是在 openrig 的环境层里把 npm 的配置也纳入管理固定 registry 为国内源、明确全局安装目录、在 Windows 上提前处理好 PowerShell 执行策略。这样后面装任何工具都不会再被环境问题打断。具体怎么做我在第 3 章会给出可直接复制的命令。3. 核心细节解析与实操要点3.1 YAML 配置文件的结构设计openrig 的配置文件是整个方案的大脑我根据这类项目的常见实践推断它的 YAML 结构大致会分成几个顶层块tools、models、env、profiles。下面这份是我基于常见实践整理出来的参考结构你可以直接拿去改。# openrig 配置参考结构 tools: claude-code: install: npm install -g anthropic-ai/claude-code command: claude config_path: ~/.claude/settings.json codex: install: npm install -g openai/codex command: codex config_path: ~/.codex/config.yaml models: local-lmstudio: endpoint: http://127.0.0.1:1234/v1 api_key: lm-studio model: local-model format: openai deepseek: endpoint: https://api.deepseek.com/v1 api_key: ${DEEPSEEK_API_KEY} model: deepseek-chat format: openai env: npm_registry: https://registry.npmmirror.com node_version: 20.x profiles: daily: tool: claude-code model: local-lmstudio cloud: tool: codex model: deepseek这份结构里最值得说的是profiles块。它把“用哪个工具 连哪个模型”打包成一个命名组合切换时只需要指定 profile 名不用手动改一堆参数。这就是解耦带来的直接收益。热搜里cc switch这个词暗示存在某种切换机制profile 就是最自然的实现方式。注意YAML 对缩进极其敏感必须用空格不能用 Tab。我见过太多人因为编辑器自动把 Tab 转成空格、或者混用两者导致解析报错却找不到原因。建议在编辑器里开启“显示空白字符”一眼就能看出缩进问题。3.2 模型接入的关键参数与格式差异模型接入是 openrig 里最容易出错的部分热搜里那个local proxy failed while handling codex endpoint /responses就是活生生的例子。问题的根源在于不同工具对模型接口的请求格式要求不一样。Claude Code 原生走的是 Anthropic 的接口格式而 Codex 走的是 OpenAI 的/responses或/chat/completions格式。当你把一个 OpenAI 兼容的本地模型比如 LM Studio接到 Codex 上时格式基本能对上但如果你想让 Claude Code 去调本地模型中间往往需要一个转换层把 Anthropic 格式翻译成 OpenAI 格式。这个转换层就是热搜里说的 “local proxy”。我在实操中总结出一个判断口诀先看工具原生说什么格式再看模型提供什么格式两者不一致就必须加转换层。转换层可以是 openrig 内置的也可以是独立的代理进程。参数上要特别注意这几个参数作用常见坑endpoint模型服务地址本地服务常写成 localhost容器里要用宿主 IPapi_key鉴权凭证本地模型常随便填但有些工具会校验非空model模型标识符必须和服务端注册的名字完全一致format请求格式openai / anthropic 混用会直接 404max_tokens最大输出设太大可能被服务端拒绝max_tokens这个参数特别容易被忽略。本地模型如果显存有限你请求一个很大的输出长度服务端可能直接报错或者截断。我的经验是本地模型先设 2048 试水跑通了再往上加。3.3 环境变量与 PATH 的配置要点环境层是 openrig 里最“脏”的部分因为它和操作系统强相关。热搜里npm 环境变量 path 配置、node 安装后 npm 不能用、npm : 无法加载文件 c:\program files\nodejs\npm.ps1全是这一层的典型问题。在 Windows 上npm 全局安装的工具默认放在%APPDATA%\npm这个目录必须加到 PATH 里否则你装完工具在终端里敲命令会提示“不是内部或外部命令”。很多人装完 Node.js 就以为万事大吉结果 npm 全局包的命令一个都用不了就是漏了这一步。PowerShell 的执行策略是另一个大坑。Windows 默认禁止运行.ps1脚本而 npm 在 PowerShell 里恰恰是通过npm.ps1来执行的于是就出现了热搜里那个因为在此系统上禁止运行脚本的报错。解决办法是以管理员身份运行 PowerShell执行Set-ExecutionPolicy RemoteSigned然后确认。这一步做完npm 命令才能正常跑。在 macOS 和 Linux 上问题通常出在 Node 版本管理器nvm、fnm和系统自带 Node 的冲突。我的做法是统一用 nvm 管理 Node 版本全局包跟着 nvm 的版本走避免权限问题。openrig 的 env 块里固定 node_version就是为了让团队所有人的环境一致减少“在我机器上能跑”的扯皮。4. 实操过程与核心环节实现4.1 从零搭建 openrig 环境的完整流程这一节我把整个搭建过程按顺序走一遍你可以直接照着敲。我假设你是一台干净的机器Windows 和 macOS/Linux 的差异我会分别标注。第一步安装 Node.js。推荐用版本管理器而不是官网安装包因为版本管理器能让你随时切换 Node 版本也不会污染系统目录。macOS/Linux 用 nvmWindows 可以用 nvm-windows。装完后执行node -v和npm -v确认版本Node 建议 20.x 起步太老的版本跑新工具会报语法错误。第二步配置 npm 国内源。这一步能极大提升安装速度热搜里npm 国内源、npm 镜像源地址就是大家在找这个。执行npm config set registry https://registry.npmmirror.com npm config get registry第二条命令用来确认设置生效。如果你在公司内网可能需要额外的代理配置这个按公司规范来。第三步处理 Windows 的 PowerShell 执行策略仅 Windows。以管理员身份打开 PowerShellSet-ExecutionPolicy RemoteSigned -Scope CurrentUser用-Scope CurrentUser避免影响系统全局更安全。执行完可以用Get-ExecutionPolicy确认。第四步确认 npm 全局目录在 PATH 里。执行npm config get prefix看全局目录在哪然后检查这个目录是否在 PATH 中。Windows 上通常是%APPDATA%\npmmacOS/Linux 上通常是 nvm 对应的 bin 目录。第五步安装 openrig 本身和它管理的工具。如果 openrig 是通过 npm 分发的命令大概是npm install -g openrig openrig initopenrig init会生成一份默认的 YAML 配置你在这个基础上改就行。第六步编辑配置文件填入你的模型 endpoint 和 API Key。API Key 建议用环境变量引用如${DEEPSEEK_API_KEY}不要明文写在 YAML 里避免不小心提交到 git。第七步用openrig doctor或类似的诊断命令检查环境。这类项目一般都会提供自检功能把 Node 版本、npm 源、PATH、配置文件语法、模型连通性都过一遍。如果自检全绿基本就能用了。4.2 接入本地模型与云端模型的实操差异接入本地 LM Studio 模型和接入云端 DeepSeek操作上有几个关键差异我分开说。本地模型这边第一步是在 LM Studio 里启动本地服务默认端口 1234接口路径是/v1。启动后先用 curl 测一下curl http://127.0.0.1:1234/v1/models如果返回模型列表说明服务正常。然后在 openrig 配置里把 endpoint 指向这个地址api_key 随便填一个非空字符串本地服务通常不校验model 填 LM Studio 里加载的模型名。这里有个细节LM Studio 的模型名可能很长带路径和量化后缀必须一字不差地填进配置否则会报模型不存在。云端模型这边以 DeepSeek 为例你需要先去官网申请 API Key然后设置环境变量export DEEPSEEK_API_KEY你的keyWindows PowerShell 里用$env:DEEPSEEK_API_KEY你的key。配置里 endpoint 填https://api.deepseek.com/v1model 填deepseek-chat。云端模型的响应速度受网络影响如果超时频繁可以在配置里调大 timeout 参数。两者的共同点是都走 OpenAI 兼容格式所以 openrig 里可以用同一套 format 配置。差异主要在鉴权和网络本地模型无鉴权、低延迟、但能力受限于本地硬件云端模型需要 key、有网络延迟、但模型能力更强。我的建议是日常轻量任务用本地复杂任务切云端profile 机制正好支持这种切换。4.3 多工具切换的配置与验证openrig 最实用的功能之一就是多工具切换。假设你配置了daily和cloud两个 profile切换命令可能是openrig use daily openrig use cloud切换后openrig 会更新对应工具的配置文件把 endpoint、model、api_key 写进去。这里有个关键点切换不是简单改个环境变量而是要真正改写 Claude Code 或 Codex 的配置文件因为这两个工具启动时读的是自己的配置不认 openrig 的环境变量。验证切换是否生效最直接的办法是启动工具后问一个只有特定模型才知道的问题或者看工具的启动日志里打印的 endpoint。我习惯在切换后跑一条简单请求确认返回正常再开始正式工作。热搜里cc switch相关的报错很多就是切换后配置没写对、或者代理进程没重启导致的。提示切换 profile 后如果工具行为异常先检查工具的配置文件是否真的被更新了。有些工具会缓存配置需要重启进程才生效。5. 常见问题与排查技巧实录5.1 安装阶段的典型报错与解决安装阶段的问题占了热搜词的一大半我挑几个最高频的逐个拆解。npm : 无法加载文件 ... npm.ps1因为在此系统上禁止运行脚本。这是 Windows PowerShell 执行策略问题前面说过用Set-ExecutionPolicy RemoteSigned -Scope CurrentUser解决。如果公司策略不允许改可以改用 CMD 或者 Git Bash 来执行 npm 命令绕开 PowerShell。npm install -g pnpm 报错和npm warn eresolve overriding peer dependency。前者通常是权限问题或网络问题先确认 registry 是国内源再确认全局目录有写权限。后者是 peer dependency 冲突警告多数情况下不影响使用但如果安装真的失败了可以加--legacy-peer-deps参数绕过。error: cannot find module npmcli/config。这是 npm 自身损坏的典型症状通常是升级 npm 过程中断导致的。解决办法是重装 Node用版本管理器最方便或者用npm install -g npmlatest强制重装 npm。node 安装后 npm 不能用。八成是 PATH 没配好或者装了多个 Node 版本导致冲突。用which nodemacOS/Linux或where nodeWindows看实际调用的是哪个再决定怎么修。5.2 运行阶段的连接与格式问题运行阶段最典型的就是热搜里那个local proxy failed while handling codex endpoint /responses。这个报错拆开看Codex 在往/responses这个 endpoint 发请求但代理层处理失败了。可能的原因有三个代理没启动、代理配置的转发目标不对、或者请求格式和代理预期的不匹配。排查顺序我建议这样先确认代理进程在跑ps或任务管理器看再用 curl 直接打代理端口看返回最后看代理日志里具体的错误信息。如果是格式不匹配就要检查代理是不是支持/responses这个路径有些老版本代理只支持/chat/completions。your organization has disabled claude subscription access for claude code这个提示说明账号层面的订阅权限被限制了这不是本地配置能解决的需要联系账号管理员或者换用其他鉴权方式。遇到这类问题不要死磕本地配置先确认账号权限。模型返回空结果或者乱码通常是 model 名字填错或者 max_tokens 设得太小。我遇到过一次模型名里多了个空格排查了半小时才发现。所以配置里的字符串一定要仔细核对。5.3 常见问题速查表报错/现象可能原因解决方向npm.ps1 禁止运行PowerShell 执行策略Set-ExecutionPolicy RemoteSigned命令找不到全局目录不在 PATH把 npm prefix 加入 PATHpeer dependency 警告依赖版本冲突加 --legacy-peer-depscannot find modulenpm 自身损坏重装 Node 或 npmproxy failed /responses代理未启动或格式不符检查代理进程和路径支持模型返回空model 名错误核对服务端模型标识符连接超时网络或 endpoint 错误curl 直测 endpoint订阅权限被禁账号层面限制联系管理员或换鉴权这张表我建议存下来遇到问题先对号入座能省下大量搜索时间。5.4 我踩过的几个坑和独家经验第一个坑是 YAML 里的环境变量引用。我一开始以为${VAR}在所有工具里都能自动展开结果发现有些工具不认必须用工具自己的语法。后来我统一改成在启动脚本里先 export再让配置文件读环境兼容性最好。第二个坑是本地模型的端口冲突。LM Studio 默认 1234但有些其他服务也占这个端口导致连不上。我的做法是给本地模型服务固定一个不常用的端口比如 18080写死在配置里避免冲突。第三个坑是切换 profile 后忘记重启工具。Claude Code 和 Codex 都是长驻进程配置文件改了但进程没重启读的还是旧配置。后来我在 openrig 的切换逻辑里加了一步自动重启省心很多。第四个坑是 API Key 泄露。我早期图省事把 key 明文写在 YAML 里结果提交到了公开仓库。虽然及时发现删了但教训深刻。现在所有 key 一律走环境变量YAML 里只留引用。第五个坑是 Node 版本不一致。团队里有人用 18有人用 22同一个工具在 18 上跑不起来。后来我们在 openrig 的 env 块里锁死 Node 版本并在文档里写明问题才消失。6. 把 openrig 用出长期价值的几个思路openrig 这类方案真正的价值不在于装好那一刻而在于长期使用中的可维护性。我分享几个让它越用越顺的思路。第一把配置文件纳入 git 管理但用.gitignore排除含密钥的文件。我的做法是配置分两层一层是团队共享的模板不含密钥一层是本地的覆盖文件含密钥被忽略。这样新人 clone 下来改几个 key 就能用。第二给每个 profile 写一句注释说明用途。比如daily是本地快速问答cloud是复杂重构任务。过几个月回头看没有注释的配置你根本想不起来当初为什么这么设。第三定期跑一次openrig doctor做体检。Node 版本升级、npm 源变更、模型服务地址调整这些变化都会让配置失效定期体检能提前发现问题。第四把常见报错和解决过程记在自己的笔记里。热搜词里那些问题本质上都是别人踩过的坑你踩过一次记下来下次就是几分钟的事。我自己的笔记里已经攒了几十条比任何官方文档都管用。第五关注工具的更新节奏。Claude Code 和 Codex 这类工具迭代很快配置格式可能变。openrig 的抽象层能缓冲一部分变化但底层工具的 breaking change 还是要留意。我的习惯是每次升级前先看 changelog确认配置格式没变再升。最后分享一个小技巧如果你同时用多个 AI 编程工具给它们分配不同的终端标签页或者窗口配合 openrig 的 profile 切换能避免“这个窗口用的是哪个模型”的混乱。我现在的布局是左边 Claude Code 跑本地模型做快速补全右边 Codex 连云端做复杂任务互不干扰效率比单工具高不少。这套东西说到底就是一句话把配置当代码管把环境当资产维护。openrig 提供的只是一个骨架真正让它好用的是你对每一层细节的理解和持续打磨。
