1. openrig 到底是个什么东西第一次看到 openrig 这个名字很多人会以为是某个硬件外设或者开源机械臂项目。实际上它是一套围绕 AI 编程助手做本地化编排与代理转发的工具集核心解决的问题是当你同时使用 Claude Code、Codex CLI 这类命令行 AI 编程工具时如何统一管理它们的请求出口、模型路由和配置切换。热搜词里出现的 claude code、codex、yaml、node.js基本勾勒出了 openrig 的技术栈轮廓——它跑在 Node.js 运行时上用 YAML 做配置文件服务于 Claude Code 和 Codex 这两大主流 AI 编程终端。我接触 openrig 的契机比较实际。手头同时有 Claude Code 和 Codex 两个工具在用前者在代码理解和长上下文任务上表现稳定后者在某些推理场景下响应更快。但两个工具各自维护一套配置切换模型供应商时要改环境变量、改配置文件、重启终端来回折腾非常烦。更麻烦的是团队里几个人用的模型端点不一样有人直连官方有人走第三方兼容接口配置散落在各自机器上出了问题排查成本极高。openrig 就是在这个背景下进入视野的——它把多个 AI 编程工具的请求统一收口到一个本地代理层用一份 YAML 配置驱动所有路由规则。它适合谁如果你只是偶尔用一下 Claude Code 写个小脚本那 openrig 对你来说偏重了。但如果你符合下面任意一条它就值得认真研究日常重度依赖 Claude Code 或 Codex CLI 做开发需要在多个模型供应商之间灵活切换团队协作时希望统一配置基线或者你想在本地对 AI 编程工具的请求做日志记录和流量分析。openrig 本质上是一个AI 编程工具的配置中枢把分散的、易变的、容易出错的配置项集中管理起来。从技术定位上说openrig 不是模型本身也不是 Claude Code 或 Codex 的替代品它是一层中间件。你可以把它理解成公司前台所有访客请求先到前台登记前台根据访客身份和事由模型名称、任务类型决定把他引导到哪个会议室后端模型端点。这个类比后面讲路由逻辑时还会用到先记住这个画面。2. 核心架构与设计思路拆解2.1 为什么选择本地代理而不是直接改配置很多人第一反应是我直接改 Claude Code 的环境变量不就行了为什么要多一层代理这个问题问到点子上了。直接改配置在单工具、单模型、单人的场景下确实够用但一旦出现下面几种情况直接改配置就会变成灾难。第一种情况是多工具共存。Claude Code 读的是它自己的一套配置Codex 读的是另一套两者的配置格式、环境变量命名、模型标识符都不完全一样。你想让它们都走同一个模型端点就得分别改两处而且改完之后两边的行为可能还不一致。openrig 的做法是把这层差异屏蔽掉两个工具都指向本地代理代理再统一转发到真实端点。第二种情况是频繁切换。今天用 A 模型写业务代码明天用 B 模型做代码审查如果每次都改配置文件再重启工具效率极低。openrig 支持在 YAML 里预定义多套路由规则切换时只需要改一个字段或者调一个接口不用动工具本身的配置。第三种情况是团队统一。团队里每个人的机器环境不同有人用 Windows有人用 Ubuntu有人用 macOS。如果靠口头约定你把环境变量改成这个迟早会有人配错。openrig 的 YAML 配置文件可以纳入版本管理新人入职拉下来就能用配置基线统一。提示本地代理的核心价值不是多一层而是把变化点集中到一处。凡是会频繁变动的东西都应该收口到配置文件里而不是散落在各个工具的环境变量中。2.2 Node.js 运行时与 YAML 配置的搭配逻辑openrig 选择 Node.js 作为运行时这个选择有它的道理。Claude Code 和 Codex CLI 本身都是 Node.js 生态里的工具用 npm 全局安装运行在 Node 环境里。openrig 用 Node.js 写意味着它和这两个工具共享同一套运行时不需要额外装 Python 或 Go 环境降低了部署门槛。热搜词里node.js安装node.js官网下载node.js LTS下载出现频率很高说明很多人在第一步就卡住了后面我会专门讲 Node.js 的安装和版本选择。YAML 作为配置格式是 openrig 的另一个关键设计。相比 JSONYAML 支持注释这对配置文件来说太重要了。你可以在一行路由规则旁边写上这行是给代码审查用的别删JSON 做不到这一点。相比 TOMLYAML 的嵌套结构表达力更强适合描述供应商 - 模型 - 路由规则这种多层关系。热搜词里yaml文件yolov10 yaml文件怎么创建rstudio的yaml在哪里混在一起说明 YAML 这个格式在很多领域都在用但 openrig 用的是它最基础的键值对和嵌套能力不涉及复杂特性。一个典型的 openrig 配置结构大致是这样的层次顶层定义代理监听端口和日志级别第二层定义供应商列表每个供应商有 base_url、api_key 引用、超时设置第三层定义路由规则哪个模型名映射到哪个供应商的哪个模型。这种三层结构对应了谁来处理请求 - 请求发给谁 - 怎么发的完整链路。2.3 与 Claude Code、Codex 的对接方式openrig 和 Claude Code 的对接核心是让 Claude Code 把请求发到本地代理而不是官方端点。Claude Code 支持通过环境变量指定 API 基础地址openrig 启动后监听一个本地端口把 Claude Code 的 base URL 指向这个端口即可。Codex 的对接逻辑类似但 Codex 的配置项名称和 Claude Code 不同需要分别设置。这里有个容易踩的坑Claude Code 和 Codex 对 API 路径的拼接方式不一样。Claude Code 可能请求/v1/messagesCodex 可能请求/responsesopenrig 需要在代理层做路径重写把不同工具的请求路径统一映射到后端供应商支持的路径上。热搜词里cc switch local proxy failed while handling codex endpoint /responses这个报错大概率就是路径重写规则没配对导致的——Codex 发到/responses的请求代理没有正确转发到后端。对接的另一个关键点是认证信息的传递。Claude Code 和 Codex 各自会带上自己的 API keyopenrig 需要决定是透传这个 key还是用配置里指定的 key 替换掉。透传适合工具本身已经配好了 key代理只做转发的场景替换适合key 统一在 openrig 配置里管理工具端不需要配 key的场景。两种方式各有优劣后面实操部分会详细对比。3. 环境准备与安装实操3.1 Node.js 版本选择与安装避坑openrig 跑在 Node.js 上所以第一步是把 Node.js 装好。热搜词里error installing 24.21.0: node.js v24.21.0 is not yet released or is not ava这个报错很典型说明有人试图安装一个还不存在的版本。Node.js 的版本号是有规律的偶数版本是 LTS长期支持版奇数版本是 Current尝鲜版。生产环境一律选 LTS目前主流是 20.x 和 22.x 两个 LTS 线。安装方式分两种。Windows 用户直接去 Node.js 官网下载 LTS 的安装包双击一路下一步即可安装程序会自动把 node 和 npm 加到 PATH 里。Ubuntu 用户建议用 NodeSource 的源安装不要用 apt 自带的版本因为 apt 源里的 Node.js 往往版本很旧。macOS 用户可以用 Homebrewbrew install node22这样指定版本装。装完之后验证三件事node -v看版本号npm -v看 npm 版本which node看路径对不对。如果node -v报command not found说明 PATH 没配好Windows 下检查环境变量Linux/macOS 下检查 shell 配置文件里有没有 export PATH。注意不要用 nvm 或 fnm 之外的版本管理器混装 Node.js。我见过有人系统里同时有 apt 装的 Node、nvm 装的 Node、官网安装包装的 Node三个版本打架node -v显示的版本和实际运行的不是一个排查了半天。选定一种安装方式卸载掉其他的。3.2 openrig 的获取与初始化openrig 的获取方式取决于它的发布形态。如果是 npm 包直接npm install -g openrig全局安装如果是源码仓库就 clone 下来npm install装依赖。安装完成后通常需要运行一个初始化命令生成默认配置文件比如openrig init它会在当前目录或用户主目录下生成一个openrig.yaml。初始化之后第一件事是检查配置文件的位置。openrig 一般会按优先级查找配置当前目录的openrig.yaml 用户主目录的.openrig/config.yaml 全局配置。搞清楚它实际读的是哪个文件否则你改了配置不生效会以为是工具坏了。可以在启动时加--verbose或--debug参数让它打印出实际加载的配置文件路径。配置文件生成后先不要急着填真实信息用默认配置启动一次看代理能不能正常监听端口。启动命令通常是openrig start或openrig serve启动后终端会打印监听地址比如http://127.0.0.1:8787。用curl http://127.0.0.1:8787/health测试一下健康检查接口返回 200 就说明代理层本身是通的。3.3 Claude Code 与 Codex 的安装确认在配置 openrig 之前先确保 Claude Code 和 Codex 本身能正常工作。Claude Code 的安装方式参考官方文档通常是 npm 全局安装后运行claude命令进入交互界面。Codex 的安装类似装完后运行codex看能不能正常启动。热搜词里claude code安装codex安装教程codex安装 windows桌面版都是高频问题说明这两个工具的安装本身就有一定门槛。安装 Claude Code 时常见的坑是权限问题。Linux/macOS 下全局安装 npm 包如果报 EACCES 错误不要用 sudo 硬装正确做法是配置 npm 的全局目录到用户目录下或者用 nvm 管理 Node.js 从而避免权限问题。Windows 下如果报不是内部或外部命令检查 npm 全局 bin 目录有没有加到 PATH。Codex 的坑主要在登录环节。热搜词里codex登录codex无法加载组织设置your organization has disabled claude subscription access这些都指向认证配置问题。Codex 首次运行会引导你登录登录方式可能是浏览器授权或者 API key 输入。如果组织策略限制了访问需要联系管理员确认权限这不是 openrig 能解决的问题得先把工具本身的认证跑通。两个工具都确认能独立工作之后再接入 openrig。顺序很重要先保证每个组件单独可用再组合这样出问题时能快速定位是哪一层的毛病。4. YAML 配置详解与路由规则设计4.1 配置文件结构逐层拆解openrig 的 YAML 配置文件是整个工具的灵魂配错了什么都跑不起来。我按实际使用中会遇到的层次从外到内拆一遍。最外层是全局设置通常包含port代理监听端口、host监听地址默认 127.0.0.1、log_level日志级别调试时设 debug稳定后设 info。端口选择有个小技巧避开常用端口比如 3000、8080、8000 这些容易被其他开发服务占用的选 8787、9787 这类不太会冲突的。第二层是providers也就是供应商列表。每个供应商是一个命名条目包含base_url供应商的 API 基础地址、api_key认证密钥可以写明文也可以引用环境变量、timeout请求超时秒数、max_retries失败重试次数。供应商命名建议用有意义的短名比如official、backup、local不要用provider1、provider2这种过两天自己都忘了哪个是哪个。第三层是routes路由规则。每条规则包含match匹配条件通常是模型名称或路径前缀和target转发目标指向某个供应商和具体模型。路由规则的顺序有讲究openrig 一般按从上到下的顺序匹配第一条命中的规则生效所以特殊规则要放在通用规则前面。port: 8787 host: 127.0.0.1 log_level: info providers: official: base_url: https://api.example-official.com api_key: ${OFFICIAL_API_KEY} timeout: 120 max_retries: 2 backup: base_url: https://api.example-backup.com api_key: ${BACKUP_API_KEY} timeout: 60 max_retries: 3 routes: - match: model: claude-* target: provider: official model: claude-sonnet - match: model: gpt-* target: provider: backup model: gpt-compatible上面这段配置的意思是所有模型名以claude-开头的请求走 official 供应商以gpt-开头的走 backup 供应商。${OFFICIAL_API_KEY}这种写法是从环境变量读取密钥避免把密钥明文写在配置文件里——如果这个文件要提交到 Git 仓库明文密钥是绝对不能出现的。4.2 模型映射与路径重写的关键细节模型映射是 openrig 最实用的功能之一。Claude Code 请求的模型名可能是claude-sonnet-4-20250514这种带日期的完整标识但你的后端供应商可能只认claude-sonnet这个简名。openrig 的target.model字段就是做这个转换的不管前端请求什么模型名只要匹配到规则就替换成 target 里指定的模型名发给后端。路径重写是另一个容易出问题的地方。前面提到的cc switch local proxy failed while handling codex endpoint /responses报错根源就在路径上。Claude Code 和 Codex 的 API 路径规范不同openrig 需要把两者的请求路径都正确转发到后端。如果后端供应商是标准兼容接口路径通常是/v1/chat/completions或/v1/messages如果后端有自己的路径规范就需要在配置里做映射。路径重写的配置一般长这样routes: - match: path: /responses rewrite: path: /v1/chat/completions target: provider: backup这条规则的意思是收到路径为/responses的请求Codex 发的重写成/v1/chat/completions再转发给 backup 供应商。如果后端供应商本身支持/responses路径就不需要重写直接转发即可。判断要不要重写的方法很简单看后端供应商的 API 文档它支持哪些路径就把前端的路径映射到它支持的路径上。提示路径重写规则配好后一定要用 curl 手动测一遍。构造一个和 Codex 发的一模一样的请求看代理日志里打印的转发路径对不对再看后端返回的是不是正常响应。不要等到在 Codex 里跑才发现问题那样排查链路太长。4.3 多供应商切换与故障转移配置openrig 支持配置多个供应商这为故障转移提供了基础。当主供应商不可用时可以自动切换到备用供应商。故障转移的配置方式通常是在路由规则里指定一个供应商列表按顺序尝试routes: - match: model: claude-* target: providers: - name: official weight: 1 - name: backup weight: 1 strategy: failoverstrategy: failover表示主供应商失败时切到备用strategy: round_robin表示轮询分发。故障转移的触发条件一般是 HTTP 5xx 错误或超时4xx 错误比如认证失败通常不触发转移因为换一个供应商也是同样的认证问题。这里有个实操心得故障转移的重试次数不要设太多。我一开始把max_retries设成 5结果主供应商挂了之后每个请求都要等 5 次超时才切到备用用户体验极差。后来改成主供应商重试 1 次失败立即切备用整体响应时间反而更稳定。重试次数和超时时间要配合着调超时设 120 秒、重试 5 次最坏情况一个请求要等 10 分钟这显然不合理。5. 实操过程与核心环节实现5.1 从零启动 openrig 的完整流程我把整个启动流程按顺序走一遍你照着做基本不会出问题。第一步确认 Node.js 版本。运行node -v确保是 20.x 或 22.x 的 LTS 版本。如果是 18.x 或更低建议升级因为 openrig 可能用到了较新的 Node API。第二步安装 openrig。如果是 npm 包npm install -g openrig如果是源码clone 后npm install npm run build。安装完成后运行openrig --version确认安装成功。第三步生成配置文件。运行openrig init它会在当前目录生成openrig.yaml。如果已经有配置文件它会提示是否覆盖选否。第四步编辑配置文件。填入供应商信息和路由规则。密钥部分建议用环境变量引用先在 shell 里 export 好。比如export OFFICIAL_API_KEYyour-key-here然后配置文件里写${OFFICIAL_API_KEY}。第五步启动代理。运行openrig start观察终端输出。正常的话会看到类似Proxy listening on http://127.0.0.1:8787的日志。如果报端口占用改配置里的 port 换个端口。第六步健康检查。另开一个终端curl http://127.0.0.1:8787/health返回 200 或{status:ok}就说明代理层正常。第七步配置 Claude Code 指向代理。Claude Code 通过环境变量指定 base URL设置export ANTHROPIC_BASE_URLhttp://127.0.0.1:8787然后启动 Claude Code 测试。第八步配置 Codex 指向代理。Codex 的配置方式不同可能需要改它的配置文件或设置不同的环境变量具体看 Codex 的文档。设置完成后启动 Codex 测试。第九步验证请求链路。在 Claude Code 里发一个简单请求比如让它解释一段代码同时观察 openrig 的日志看请求有没有正确转发、后端有没有正常响应。5.2 请求链路验证与日志分析openrig 的日志是排查问题的第一手资料。把log_level设成debug日志里会打印每个请求的详细信息来源工具、请求路径、匹配到的路由规则、转发目标、响应状态码、耗时。一个正常的请求日志大概长这样[debug] incoming request: POST /v1/messages from claude-code [debug] matched route: modelclaude-sonnet-4-20250514 - providerofficial [debug] forwarding to https://api.example-official.com/v1/messages [debug] response status: 200, duration: 2340ms如果请求失败日志里会显示失败原因。常见的失败模式有几种no route matched表示没有匹配到任何路由规则检查 match 条件写对没有provider connection refused表示后端供应商连不上检查 base_url 和网络401 unauthorized表示认证失败检查 api_key 配置timeout after 120s表示后端响应太慢考虑调大 timeout 或换供应商。我习惯在调试阶段把日志同时输出到终端和文件终端看实时情况文件留着事后分析。openrig 一般支持--log-file参数指定日志文件路径或者配置里写log_file: ./openrig.log。5.3 多工具共存的配置隔离Claude Code 和 Codex 同时接入 openrig 时需要做配置隔离避免互相干扰。隔离的核心是让两个工具的请求能被 openrig 区分开从而走不同的路由规则。区分方式有两种。第一种是按路径区分Claude Code 请求/v1/messagesCodex 请求/responsesopenrig 根据路径匹配不同的路由。第二种是按请求头区分两个工具可能会带不同的 User-Agent 或自定义头openrig 根据头信息匹配路由。路径区分更可靠因为路径是工具固定的行为不容易变。配置隔离的 YAML 大概是这样routes: - match: path: /v1/messages target: provider: official model: claude-sonnet - match: path: /responses rewrite: path: /v1/chat/completions target: provider: backup model: gpt-compatible这样 Claude Code 的请求走 official 供应商的 claude-sonnet 模型Codex 的请求重写路径后走 backup 供应商的 gpt-compatible 模型。两个工具各走各的路互不影响。注意如果两个工具用了同一个端口openrig 只能监听一个端口所以它们必须共用这个端口靠路径或请求头区分。如果想让它们用不同端口需要启动两个 openrig 实例各自监听不同端口配置不同的路由规则。多实例方案更清晰但资源占用翻倍单实例方案更省资源但配置稍复杂按需选择。6. 常见问题与排查技巧实录6.1 启动阶段的高频报错启动阶段最常见的问题是端口占用。报错信息通常是EADDRINUSE: address already in use。解决办法是先找到占用端口的进程Linux/macOS 下用lsof -i :8787Windows 下用netstat -ano | findstr 8787找到 PID 后 kill 掉或者改 openrig 的监听端口。第二个高频问题是配置文件解析失败。YAML 对缩进极其敏感多一个空格少一个空格都会导致解析错误。报错信息通常是YAMLException: bad indentation或mapping values are not allowed here。排查方法是把配置文件贴到在线 YAML 校验工具里检查或者用node -e console.log(require(js-yaml).load(require(fs).readFileSync(openrig.yaml,utf8)))手动解析看报什么错。第三个问题是环境变量没生效。配置文件里写了${OFFICIAL_API_KEY}但启动时报api_key is empty。原因是环境变量没有 export 到当前 shell或者 export 之后没有重新启动 openrig。检查方法是echo $OFFICIAL_API_KEY看有没有值没有的话重新 export 再启动。6.2 请求转发失败的排查路径请求转发失败的表现是工具端报错openrig 日志里有异常。排查按从外到内的顺序走。先看工具端报什么错。如果是连接被拒绝说明 openrig 没启动或者端口不对。如果是 404说明路径没匹配上。如果是 401说明认证有问题。如果是 500说明 openrig 内部出错或者后端出错。再看 openrig 日志。日志里会显示请求有没有进来、匹配到哪条规则、转发到哪个地址、后端返回什么状态码。如果日志里根本没有请求记录说明请求没到 openrig检查工具的 base URL 配置。如果日志里有请求但显示no route matched检查路由规则的 match 条件。如果显示转发失败检查后端供应商的 base_url 和网络连通性。最后看后端供应商。用 curl 直接请求后端绕过 openrig看后端本身是否正常。如果 curl 直接请求也失败问题在后端或网络如果 curl 成功但经过 openrig 失败问题在 openrig 的转发逻辑。6.3 常见问题速查表报错信息可能原因排查方法解决方案EADDRINUSE端口被占用lsof -i :端口号换端口或kill占用进程YAMLException缩进错误在线YAML校验统一用2空格缩进api_key is empty环境变量未生效echo $变量名重新export并重启no route matched路由规则不匹配看debug日志检查match条件401 unauthorized认证失败检查api_key更新密钥配置timeout后端响应慢测后端响应时间调大timeout或换供应商404 not found路径不匹配对比前后端路径加路径重写规则connection refused后端连不上curl后端地址检查base_url和网络6.4 独家避坑经验第一个坑配置文件里的密钥不要用明文。我见过有人把 API key 直接写在 YAML 里然后不小心把配置文件提交到了公开仓库密钥泄露。正确做法是用环境变量引用或者用 openrig 支持的密钥管理功能。如果已经泄露了立即去供应商后台吊销旧密钥生成新密钥。第二个坑路由规则的顺序。openrig 按顺序匹配第一条命中的生效。如果你把通用规则放在前面特殊规则放在后面特殊规则永远不会生效。比如model: *这种通配规则必须放在最后否则它会拦截所有请求。第三个坑超时时间设太短。有些模型推理复杂任务需要几十秒甚至几分钟如果 timeout 设成 30 秒请求会在模型还没返回时就被切断。我一般把 timeout 设成 120 秒起步复杂任务场景设 300 秒。但也不能无限大否则后端挂了请求会一直挂着。第四个坑日志级别一直开着 debug。debug 日志信息量大长时间运行会占满磁盘。调试阶段开 debug稳定后改回 info。如果确实需要长期记录详细日志配置日志轮转限制单个日志文件大小和保留数量。第五个坑多实例端口冲突。如果你为了隔离 Claude Code 和 Codex 启动了两个 openrig 实例记得给它们分配不同端口并且两个实例的配置文件要分开。我见过有人两个实例读同一个配置文件结果两个实例监听同一个端口第二个启动直接失败。7. 进阶玩法与扩展思路7.1 本地模型接入的配置方式热搜词里claude code 调用lmstudio的本地模型是个很实际的需求。openrig 同样可以代理到本地模型服务。LM Studio 或类似工具会在本地启动一个兼容 API 的服务监听某个端口比如 1234。openrig 配置一个指向本地端口的供应商即可providers: local: base_url: http://127.0.0.1:1234/v1 api_key: not-needed timeout: 300本地模型的优势是数据不出本机适合处理敏感代码。劣势是模型能力通常不如云端大模型复杂任务效果会打折扣。我的做法是把本地模型作为兜底简单任务走本地复杂任务走云端在路由规则里按模型名或任务类型区分。7.2 请求日志与用量统计openrig 的日志除了排查问题还能用来做用量统计。日志里记录了每个请求的模型、耗时、状态码把这些数据提取出来可以分析出哪个模型用得最多、平均响应时间多少、失败率多高。如果 openrig 支持结构化日志JSON 格式用脚本解析起来更方便。我自己的做法是每周导出一次日志用简单的脚本统计各模型的调用次数和平均耗时看看有没有异常。比如某个供应商的失败率突然升高说明它可能不稳定该考虑切换了。这种数据驱动的运维方式比凭感觉判断靠谱得多。7.3 配置版本管理与团队协作openrig 的 YAML 配置文件非常适合纳入 Git 管理。团队协作时把配置文件放在仓库里每个人拉下来改改环境变量就能用。但要注意两点密钥不能进仓库用环境变量或密钥管理工具个人特殊配置不要提交用.gitignore排除本地覆盖文件。openrig 一般支持配置继承或覆盖机制比如主配置openrig.yaml提交到仓库个人配置openrig.local.yaml不提交启动时自动合并。这样团队共享基础配置个人又能有自己的定制兼顾统一性和灵活性。7.4 性能调优的几个方向openrig 作为代理层本身会引入一点延迟。如果发现经过代理后响应明显变慢可以从几个方向调优。一是减少日志级别debug 日志的写入开销不小。二是调整连接池配置如果 openrig 支持 keep-alive开启后能减少连接建立的开销。三是检查代理和后端之间的网络如果代理在本地但后端在远端网络延迟是主要因素这个没法通过配置优化只能换更近的后端。还有一个容易被忽略的点openrig 的 Node.js 进程如果长时间运行内存可能增长。定期重启进程比如用 systemd 或 pm2 管理配置定时重启能避免内存泄漏导致的问题。如果 openrig 本身有内存泄漏 bug关注它的版本更新及时升级。我在实际使用中最大的体会是openrig 这类工具的价值不在于它多复杂而在于它把配置这件事从散落状态变成了集中状态。以前改一个模型端点要在三四个地方同步修改现在只改一个 YAML 文件。这个改变看起来小但日积月累节省的时间和减少的错误是实实在在的。如果你也在同时用多个 AI 编程工具被配置切换折磨过openrig 值得花一个下午认真配一遍。配好之后你会发现自己再也不想回到手动改环境变量的日子了。
openrig：统一管理Claude Code与Codex的本地代理配置指南
1. openrig 到底是个什么东西第一次看到 openrig 这个名字很多人会以为是某个硬件外设或者开源机械臂项目。实际上它是一套围绕 AI 编程助手做本地化编排与代理转发的工具集核心解决的问题是当你同时使用 Claude Code、Codex CLI 这类命令行 AI 编程工具时如何统一管理它们的请求出口、模型路由和配置切换。热搜词里出现的 claude code、codex、yaml、node.js基本勾勒出了 openrig 的技术栈轮廓——它跑在 Node.js 运行时上用 YAML 做配置文件服务于 Claude Code 和 Codex 这两大主流 AI 编程终端。我接触 openrig 的契机比较实际。手头同时有 Claude Code 和 Codex 两个工具在用前者在代码理解和长上下文任务上表现稳定后者在某些推理场景下响应更快。但两个工具各自维护一套配置切换模型供应商时要改环境变量、改配置文件、重启终端来回折腾非常烦。更麻烦的是团队里几个人用的模型端点不一样有人直连官方有人走第三方兼容接口配置散落在各自机器上出了问题排查成本极高。openrig 就是在这个背景下进入视野的——它把多个 AI 编程工具的请求统一收口到一个本地代理层用一份 YAML 配置驱动所有路由规则。它适合谁如果你只是偶尔用一下 Claude Code 写个小脚本那 openrig 对你来说偏重了。但如果你符合下面任意一条它就值得认真研究日常重度依赖 Claude Code 或 Codex CLI 做开发需要在多个模型供应商之间灵活切换团队协作时希望统一配置基线或者你想在本地对 AI 编程工具的请求做日志记录和流量分析。openrig 本质上是一个AI 编程工具的配置中枢把分散的、易变的、容易出错的配置项集中管理起来。从技术定位上说openrig 不是模型本身也不是 Claude Code 或 Codex 的替代品它是一层中间件。你可以把它理解成公司前台所有访客请求先到前台登记前台根据访客身份和事由模型名称、任务类型决定把他引导到哪个会议室后端模型端点。这个类比后面讲路由逻辑时还会用到先记住这个画面。2. 核心架构与设计思路拆解2.1 为什么选择本地代理而不是直接改配置很多人第一反应是我直接改 Claude Code 的环境变量不就行了为什么要多一层代理这个问题问到点子上了。直接改配置在单工具、单模型、单人的场景下确实够用但一旦出现下面几种情况直接改配置就会变成灾难。第一种情况是多工具共存。Claude Code 读的是它自己的一套配置Codex 读的是另一套两者的配置格式、环境变量命名、模型标识符都不完全一样。你想让它们都走同一个模型端点就得分别改两处而且改完之后两边的行为可能还不一致。openrig 的做法是把这层差异屏蔽掉两个工具都指向本地代理代理再统一转发到真实端点。第二种情况是频繁切换。今天用 A 模型写业务代码明天用 B 模型做代码审查如果每次都改配置文件再重启工具效率极低。openrig 支持在 YAML 里预定义多套路由规则切换时只需要改一个字段或者调一个接口不用动工具本身的配置。第三种情况是团队统一。团队里每个人的机器环境不同有人用 Windows有人用 Ubuntu有人用 macOS。如果靠口头约定你把环境变量改成这个迟早会有人配错。openrig 的 YAML 配置文件可以纳入版本管理新人入职拉下来就能用配置基线统一。提示本地代理的核心价值不是多一层而是把变化点集中到一处。凡是会频繁变动的东西都应该收口到配置文件里而不是散落在各个工具的环境变量中。2.2 Node.js 运行时与 YAML 配置的搭配逻辑openrig 选择 Node.js 作为运行时这个选择有它的道理。Claude Code 和 Codex CLI 本身都是 Node.js 生态里的工具用 npm 全局安装运行在 Node 环境里。openrig 用 Node.js 写意味着它和这两个工具共享同一套运行时不需要额外装 Python 或 Go 环境降低了部署门槛。热搜词里node.js安装node.js官网下载node.js LTS下载出现频率很高说明很多人在第一步就卡住了后面我会专门讲 Node.js 的安装和版本选择。YAML 作为配置格式是 openrig 的另一个关键设计。相比 JSONYAML 支持注释这对配置文件来说太重要了。你可以在一行路由规则旁边写上这行是给代码审查用的别删JSON 做不到这一点。相比 TOMLYAML 的嵌套结构表达力更强适合描述供应商 - 模型 - 路由规则这种多层关系。热搜词里yaml文件yolov10 yaml文件怎么创建rstudio的yaml在哪里混在一起说明 YAML 这个格式在很多领域都在用但 openrig 用的是它最基础的键值对和嵌套能力不涉及复杂特性。一个典型的 openrig 配置结构大致是这样的层次顶层定义代理监听端口和日志级别第二层定义供应商列表每个供应商有 base_url、api_key 引用、超时设置第三层定义路由规则哪个模型名映射到哪个供应商的哪个模型。这种三层结构对应了谁来处理请求 - 请求发给谁 - 怎么发的完整链路。2.3 与 Claude Code、Codex 的对接方式openrig 和 Claude Code 的对接核心是让 Claude Code 把请求发到本地代理而不是官方端点。Claude Code 支持通过环境变量指定 API 基础地址openrig 启动后监听一个本地端口把 Claude Code 的 base URL 指向这个端口即可。Codex 的对接逻辑类似但 Codex 的配置项名称和 Claude Code 不同需要分别设置。这里有个容易踩的坑Claude Code 和 Codex 对 API 路径的拼接方式不一样。Claude Code 可能请求/v1/messagesCodex 可能请求/responsesopenrig 需要在代理层做路径重写把不同工具的请求路径统一映射到后端供应商支持的路径上。热搜词里cc switch local proxy failed while handling codex endpoint /responses这个报错大概率就是路径重写规则没配对导致的——Codex 发到/responses的请求代理没有正确转发到后端。对接的另一个关键点是认证信息的传递。Claude Code 和 Codex 各自会带上自己的 API keyopenrig 需要决定是透传这个 key还是用配置里指定的 key 替换掉。透传适合工具本身已经配好了 key代理只做转发的场景替换适合key 统一在 openrig 配置里管理工具端不需要配 key的场景。两种方式各有优劣后面实操部分会详细对比。3. 环境准备与安装实操3.1 Node.js 版本选择与安装避坑openrig 跑在 Node.js 上所以第一步是把 Node.js 装好。热搜词里error installing 24.21.0: node.js v24.21.0 is not yet released or is not ava这个报错很典型说明有人试图安装一个还不存在的版本。Node.js 的版本号是有规律的偶数版本是 LTS长期支持版奇数版本是 Current尝鲜版。生产环境一律选 LTS目前主流是 20.x 和 22.x 两个 LTS 线。安装方式分两种。Windows 用户直接去 Node.js 官网下载 LTS 的安装包双击一路下一步即可安装程序会自动把 node 和 npm 加到 PATH 里。Ubuntu 用户建议用 NodeSource 的源安装不要用 apt 自带的版本因为 apt 源里的 Node.js 往往版本很旧。macOS 用户可以用 Homebrewbrew install node22这样指定版本装。装完之后验证三件事node -v看版本号npm -v看 npm 版本which node看路径对不对。如果node -v报command not found说明 PATH 没配好Windows 下检查环境变量Linux/macOS 下检查 shell 配置文件里有没有 export PATH。注意不要用 nvm 或 fnm 之外的版本管理器混装 Node.js。我见过有人系统里同时有 apt 装的 Node、nvm 装的 Node、官网安装包装的 Node三个版本打架node -v显示的版本和实际运行的不是一个排查了半天。选定一种安装方式卸载掉其他的。3.2 openrig 的获取与初始化openrig 的获取方式取决于它的发布形态。如果是 npm 包直接npm install -g openrig全局安装如果是源码仓库就 clone 下来npm install装依赖。安装完成后通常需要运行一个初始化命令生成默认配置文件比如openrig init它会在当前目录或用户主目录下生成一个openrig.yaml。初始化之后第一件事是检查配置文件的位置。openrig 一般会按优先级查找配置当前目录的openrig.yaml 用户主目录的.openrig/config.yaml 全局配置。搞清楚它实际读的是哪个文件否则你改了配置不生效会以为是工具坏了。可以在启动时加--verbose或--debug参数让它打印出实际加载的配置文件路径。配置文件生成后先不要急着填真实信息用默认配置启动一次看代理能不能正常监听端口。启动命令通常是openrig start或openrig serve启动后终端会打印监听地址比如http://127.0.0.1:8787。用curl http://127.0.0.1:8787/health测试一下健康检查接口返回 200 就说明代理层本身是通的。3.3 Claude Code 与 Codex 的安装确认在配置 openrig 之前先确保 Claude Code 和 Codex 本身能正常工作。Claude Code 的安装方式参考官方文档通常是 npm 全局安装后运行claude命令进入交互界面。Codex 的安装类似装完后运行codex看能不能正常启动。热搜词里claude code安装codex安装教程codex安装 windows桌面版都是高频问题说明这两个工具的安装本身就有一定门槛。安装 Claude Code 时常见的坑是权限问题。Linux/macOS 下全局安装 npm 包如果报 EACCES 错误不要用 sudo 硬装正确做法是配置 npm 的全局目录到用户目录下或者用 nvm 管理 Node.js 从而避免权限问题。Windows 下如果报不是内部或外部命令检查 npm 全局 bin 目录有没有加到 PATH。Codex 的坑主要在登录环节。热搜词里codex登录codex无法加载组织设置your organization has disabled claude subscription access这些都指向认证配置问题。Codex 首次运行会引导你登录登录方式可能是浏览器授权或者 API key 输入。如果组织策略限制了访问需要联系管理员确认权限这不是 openrig 能解决的问题得先把工具本身的认证跑通。两个工具都确认能独立工作之后再接入 openrig。顺序很重要先保证每个组件单独可用再组合这样出问题时能快速定位是哪一层的毛病。4. YAML 配置详解与路由规则设计4.1 配置文件结构逐层拆解openrig 的 YAML 配置文件是整个工具的灵魂配错了什么都跑不起来。我按实际使用中会遇到的层次从外到内拆一遍。最外层是全局设置通常包含port代理监听端口、host监听地址默认 127.0.0.1、log_level日志级别调试时设 debug稳定后设 info。端口选择有个小技巧避开常用端口比如 3000、8080、8000 这些容易被其他开发服务占用的选 8787、9787 这类不太会冲突的。第二层是providers也就是供应商列表。每个供应商是一个命名条目包含base_url供应商的 API 基础地址、api_key认证密钥可以写明文也可以引用环境变量、timeout请求超时秒数、max_retries失败重试次数。供应商命名建议用有意义的短名比如official、backup、local不要用provider1、provider2这种过两天自己都忘了哪个是哪个。第三层是routes路由规则。每条规则包含match匹配条件通常是模型名称或路径前缀和target转发目标指向某个供应商和具体模型。路由规则的顺序有讲究openrig 一般按从上到下的顺序匹配第一条命中的规则生效所以特殊规则要放在通用规则前面。port: 8787 host: 127.0.0.1 log_level: info providers: official: base_url: https://api.example-official.com api_key: ${OFFICIAL_API_KEY} timeout: 120 max_retries: 2 backup: base_url: https://api.example-backup.com api_key: ${BACKUP_API_KEY} timeout: 60 max_retries: 3 routes: - match: model: claude-* target: provider: official model: claude-sonnet - match: model: gpt-* target: provider: backup model: gpt-compatible上面这段配置的意思是所有模型名以claude-开头的请求走 official 供应商以gpt-开头的走 backup 供应商。${OFFICIAL_API_KEY}这种写法是从环境变量读取密钥避免把密钥明文写在配置文件里——如果这个文件要提交到 Git 仓库明文密钥是绝对不能出现的。4.2 模型映射与路径重写的关键细节模型映射是 openrig 最实用的功能之一。Claude Code 请求的模型名可能是claude-sonnet-4-20250514这种带日期的完整标识但你的后端供应商可能只认claude-sonnet这个简名。openrig 的target.model字段就是做这个转换的不管前端请求什么模型名只要匹配到规则就替换成 target 里指定的模型名发给后端。路径重写是另一个容易出问题的地方。前面提到的cc switch local proxy failed while handling codex endpoint /responses报错根源就在路径上。Claude Code 和 Codex 的 API 路径规范不同openrig 需要把两者的请求路径都正确转发到后端。如果后端供应商是标准兼容接口路径通常是/v1/chat/completions或/v1/messages如果后端有自己的路径规范就需要在配置里做映射。路径重写的配置一般长这样routes: - match: path: /responses rewrite: path: /v1/chat/completions target: provider: backup这条规则的意思是收到路径为/responses的请求Codex 发的重写成/v1/chat/completions再转发给 backup 供应商。如果后端供应商本身支持/responses路径就不需要重写直接转发即可。判断要不要重写的方法很简单看后端供应商的 API 文档它支持哪些路径就把前端的路径映射到它支持的路径上。提示路径重写规则配好后一定要用 curl 手动测一遍。构造一个和 Codex 发的一模一样的请求看代理日志里打印的转发路径对不对再看后端返回的是不是正常响应。不要等到在 Codex 里跑才发现问题那样排查链路太长。4.3 多供应商切换与故障转移配置openrig 支持配置多个供应商这为故障转移提供了基础。当主供应商不可用时可以自动切换到备用供应商。故障转移的配置方式通常是在路由规则里指定一个供应商列表按顺序尝试routes: - match: model: claude-* target: providers: - name: official weight: 1 - name: backup weight: 1 strategy: failoverstrategy: failover表示主供应商失败时切到备用strategy: round_robin表示轮询分发。故障转移的触发条件一般是 HTTP 5xx 错误或超时4xx 错误比如认证失败通常不触发转移因为换一个供应商也是同样的认证问题。这里有个实操心得故障转移的重试次数不要设太多。我一开始把max_retries设成 5结果主供应商挂了之后每个请求都要等 5 次超时才切到备用用户体验极差。后来改成主供应商重试 1 次失败立即切备用整体响应时间反而更稳定。重试次数和超时时间要配合着调超时设 120 秒、重试 5 次最坏情况一个请求要等 10 分钟这显然不合理。5. 实操过程与核心环节实现5.1 从零启动 openrig 的完整流程我把整个启动流程按顺序走一遍你照着做基本不会出问题。第一步确认 Node.js 版本。运行node -v确保是 20.x 或 22.x 的 LTS 版本。如果是 18.x 或更低建议升级因为 openrig 可能用到了较新的 Node API。第二步安装 openrig。如果是 npm 包npm install -g openrig如果是源码clone 后npm install npm run build。安装完成后运行openrig --version确认安装成功。第三步生成配置文件。运行openrig init它会在当前目录生成openrig.yaml。如果已经有配置文件它会提示是否覆盖选否。第四步编辑配置文件。填入供应商信息和路由规则。密钥部分建议用环境变量引用先在 shell 里 export 好。比如export OFFICIAL_API_KEYyour-key-here然后配置文件里写${OFFICIAL_API_KEY}。第五步启动代理。运行openrig start观察终端输出。正常的话会看到类似Proxy listening on http://127.0.0.1:8787的日志。如果报端口占用改配置里的 port 换个端口。第六步健康检查。另开一个终端curl http://127.0.0.1:8787/health返回 200 或{status:ok}就说明代理层正常。第七步配置 Claude Code 指向代理。Claude Code 通过环境变量指定 base URL设置export ANTHROPIC_BASE_URLhttp://127.0.0.1:8787然后启动 Claude Code 测试。第八步配置 Codex 指向代理。Codex 的配置方式不同可能需要改它的配置文件或设置不同的环境变量具体看 Codex 的文档。设置完成后启动 Codex 测试。第九步验证请求链路。在 Claude Code 里发一个简单请求比如让它解释一段代码同时观察 openrig 的日志看请求有没有正确转发、后端有没有正常响应。5.2 请求链路验证与日志分析openrig 的日志是排查问题的第一手资料。把log_level设成debug日志里会打印每个请求的详细信息来源工具、请求路径、匹配到的路由规则、转发目标、响应状态码、耗时。一个正常的请求日志大概长这样[debug] incoming request: POST /v1/messages from claude-code [debug] matched route: modelclaude-sonnet-4-20250514 - providerofficial [debug] forwarding to https://api.example-official.com/v1/messages [debug] response status: 200, duration: 2340ms如果请求失败日志里会显示失败原因。常见的失败模式有几种no route matched表示没有匹配到任何路由规则检查 match 条件写对没有provider connection refused表示后端供应商连不上检查 base_url 和网络401 unauthorized表示认证失败检查 api_key 配置timeout after 120s表示后端响应太慢考虑调大 timeout 或换供应商。我习惯在调试阶段把日志同时输出到终端和文件终端看实时情况文件留着事后分析。openrig 一般支持--log-file参数指定日志文件路径或者配置里写log_file: ./openrig.log。5.3 多工具共存的配置隔离Claude Code 和 Codex 同时接入 openrig 时需要做配置隔离避免互相干扰。隔离的核心是让两个工具的请求能被 openrig 区分开从而走不同的路由规则。区分方式有两种。第一种是按路径区分Claude Code 请求/v1/messagesCodex 请求/responsesopenrig 根据路径匹配不同的路由。第二种是按请求头区分两个工具可能会带不同的 User-Agent 或自定义头openrig 根据头信息匹配路由。路径区分更可靠因为路径是工具固定的行为不容易变。配置隔离的 YAML 大概是这样routes: - match: path: /v1/messages target: provider: official model: claude-sonnet - match: path: /responses rewrite: path: /v1/chat/completions target: provider: backup model: gpt-compatible这样 Claude Code 的请求走 official 供应商的 claude-sonnet 模型Codex 的请求重写路径后走 backup 供应商的 gpt-compatible 模型。两个工具各走各的路互不影响。注意如果两个工具用了同一个端口openrig 只能监听一个端口所以它们必须共用这个端口靠路径或请求头区分。如果想让它们用不同端口需要启动两个 openrig 实例各自监听不同端口配置不同的路由规则。多实例方案更清晰但资源占用翻倍单实例方案更省资源但配置稍复杂按需选择。6. 常见问题与排查技巧实录6.1 启动阶段的高频报错启动阶段最常见的问题是端口占用。报错信息通常是EADDRINUSE: address already in use。解决办法是先找到占用端口的进程Linux/macOS 下用lsof -i :8787Windows 下用netstat -ano | findstr 8787找到 PID 后 kill 掉或者改 openrig 的监听端口。第二个高频问题是配置文件解析失败。YAML 对缩进极其敏感多一个空格少一个空格都会导致解析错误。报错信息通常是YAMLException: bad indentation或mapping values are not allowed here。排查方法是把配置文件贴到在线 YAML 校验工具里检查或者用node -e console.log(require(js-yaml).load(require(fs).readFileSync(openrig.yaml,utf8)))手动解析看报什么错。第三个问题是环境变量没生效。配置文件里写了${OFFICIAL_API_KEY}但启动时报api_key is empty。原因是环境变量没有 export 到当前 shell或者 export 之后没有重新启动 openrig。检查方法是echo $OFFICIAL_API_KEY看有没有值没有的话重新 export 再启动。6.2 请求转发失败的排查路径请求转发失败的表现是工具端报错openrig 日志里有异常。排查按从外到内的顺序走。先看工具端报什么错。如果是连接被拒绝说明 openrig 没启动或者端口不对。如果是 404说明路径没匹配上。如果是 401说明认证有问题。如果是 500说明 openrig 内部出错或者后端出错。再看 openrig 日志。日志里会显示请求有没有进来、匹配到哪条规则、转发到哪个地址、后端返回什么状态码。如果日志里根本没有请求记录说明请求没到 openrig检查工具的 base URL 配置。如果日志里有请求但显示no route matched检查路由规则的 match 条件。如果显示转发失败检查后端供应商的 base_url 和网络连通性。最后看后端供应商。用 curl 直接请求后端绕过 openrig看后端本身是否正常。如果 curl 直接请求也失败问题在后端或网络如果 curl 成功但经过 openrig 失败问题在 openrig 的转发逻辑。6.3 常见问题速查表报错信息可能原因排查方法解决方案EADDRINUSE端口被占用lsof -i :端口号换端口或kill占用进程YAMLException缩进错误在线YAML校验统一用2空格缩进api_key is empty环境变量未生效echo $变量名重新export并重启no route matched路由规则不匹配看debug日志检查match条件401 unauthorized认证失败检查api_key更新密钥配置timeout后端响应慢测后端响应时间调大timeout或换供应商404 not found路径不匹配对比前后端路径加路径重写规则connection refused后端连不上curl后端地址检查base_url和网络6.4 独家避坑经验第一个坑配置文件里的密钥不要用明文。我见过有人把 API key 直接写在 YAML 里然后不小心把配置文件提交到了公开仓库密钥泄露。正确做法是用环境变量引用或者用 openrig 支持的密钥管理功能。如果已经泄露了立即去供应商后台吊销旧密钥生成新密钥。第二个坑路由规则的顺序。openrig 按顺序匹配第一条命中的生效。如果你把通用规则放在前面特殊规则放在后面特殊规则永远不会生效。比如model: *这种通配规则必须放在最后否则它会拦截所有请求。第三个坑超时时间设太短。有些模型推理复杂任务需要几十秒甚至几分钟如果 timeout 设成 30 秒请求会在模型还没返回时就被切断。我一般把 timeout 设成 120 秒起步复杂任务场景设 300 秒。但也不能无限大否则后端挂了请求会一直挂着。第四个坑日志级别一直开着 debug。debug 日志信息量大长时间运行会占满磁盘。调试阶段开 debug稳定后改回 info。如果确实需要长期记录详细日志配置日志轮转限制单个日志文件大小和保留数量。第五个坑多实例端口冲突。如果你为了隔离 Claude Code 和 Codex 启动了两个 openrig 实例记得给它们分配不同端口并且两个实例的配置文件要分开。我见过有人两个实例读同一个配置文件结果两个实例监听同一个端口第二个启动直接失败。7. 进阶玩法与扩展思路7.1 本地模型接入的配置方式热搜词里claude code 调用lmstudio的本地模型是个很实际的需求。openrig 同样可以代理到本地模型服务。LM Studio 或类似工具会在本地启动一个兼容 API 的服务监听某个端口比如 1234。openrig 配置一个指向本地端口的供应商即可providers: local: base_url: http://127.0.0.1:1234/v1 api_key: not-needed timeout: 300本地模型的优势是数据不出本机适合处理敏感代码。劣势是模型能力通常不如云端大模型复杂任务效果会打折扣。我的做法是把本地模型作为兜底简单任务走本地复杂任务走云端在路由规则里按模型名或任务类型区分。7.2 请求日志与用量统计openrig 的日志除了排查问题还能用来做用量统计。日志里记录了每个请求的模型、耗时、状态码把这些数据提取出来可以分析出哪个模型用得最多、平均响应时间多少、失败率多高。如果 openrig 支持结构化日志JSON 格式用脚本解析起来更方便。我自己的做法是每周导出一次日志用简单的脚本统计各模型的调用次数和平均耗时看看有没有异常。比如某个供应商的失败率突然升高说明它可能不稳定该考虑切换了。这种数据驱动的运维方式比凭感觉判断靠谱得多。7.3 配置版本管理与团队协作openrig 的 YAML 配置文件非常适合纳入 Git 管理。团队协作时把配置文件放在仓库里每个人拉下来改改环境变量就能用。但要注意两点密钥不能进仓库用环境变量或密钥管理工具个人特殊配置不要提交用.gitignore排除本地覆盖文件。openrig 一般支持配置继承或覆盖机制比如主配置openrig.yaml提交到仓库个人配置openrig.local.yaml不提交启动时自动合并。这样团队共享基础配置个人又能有自己的定制兼顾统一性和灵活性。7.4 性能调优的几个方向openrig 作为代理层本身会引入一点延迟。如果发现经过代理后响应明显变慢可以从几个方向调优。一是减少日志级别debug 日志的写入开销不小。二是调整连接池配置如果 openrig 支持 keep-alive开启后能减少连接建立的开销。三是检查代理和后端之间的网络如果代理在本地但后端在远端网络延迟是主要因素这个没法通过配置优化只能换更近的后端。还有一个容易被忽略的点openrig 的 Node.js 进程如果长时间运行内存可能增长。定期重启进程比如用 systemd 或 pm2 管理配置定时重启能避免内存泄漏导致的问题。如果 openrig 本身有内存泄漏 bug关注它的版本更新及时升级。我在实际使用中最大的体会是openrig 这类工具的价值不在于它多复杂而在于它把配置这件事从散落状态变成了集中状态。以前改一个模型端点要在三四个地方同步修改现在只改一个 YAML 文件。这个改变看起来小但日积月累节省的时间和减少的错误是实实在在的。如果你也在同时用多个 AI 编程工具被配置切换折磨过openrig 值得花一个下午认真配一遍。配好之后你会发现自己再也不想回到手动改环境变量的日子了。
