1. OpenRig 是什么一个被误读的开源项目名与真实技术图谱OpenRig 这个词在当前技术社区里正经历一场典型的“命名漂移”——它既不是某个广为人知的成熟开源项目比如 OpenCV、OpenSSH 或 OpenStack也不是官方发布的标准化工具套件。从你提供的热搜词组合来看它高频出现在Node.js、tmux、Claude、Codex等关键词的共现语境中尤其频繁绑定在codex endpoint /responses、cc switch local proxy failed、claude code 调用 lmstudio 的本地模型这类报错描述里。这说明OpenRig 并非一个独立产品而是开发者在本地搭建 Claude/Codex 类 LLM 工具链时自发形成的一套轻量级运行时环境命名习惯核心目标是让 Claude 官方客户端Claude Code、Codex CLI 工具、以及本地大模型服务如 LMStudio、Ollama能在同一台机器上稳定协同工作。我第一次见到 “OpenRig” 是在 GitHub 上一个私有仓库的 README 里作者写的是“This is my OpenRig setup — a minimal, tmux-based rig for running Codex Claude Desktop local LLMs without Docker.” 后来翻了十几个类似仓库发现这个词几乎都指向同一种实践模式不用 Docker、不依赖云服务、纯本地、命令行驱动、高度可复现的 LLM 开发沙盒。它本质上是一个运维约定operational convention而非代码库。就像当年大家把“用 nginx uWSGI Flask 搭 Web 服务”叫作 “Nginx Rig”把“用 tmux vim fzf 做终端开发流”叫作 “Tmux Rig” 一样“OpenRig” 是对当前 Claude/Codex 本地化工作流的一种简洁指代。为什么需要这样一个“Rig”因为官方工具链存在三重断裂Claude Desktop是封闭的 Electron 应用无法直接接入本地模型Codex CLInpx codex虽支持--model参数但默认只认 Anthropic 的远程 API本地模型需手动配置代理LMStudio/Ollama提供本地 HTTP 接口如http://localhost:1234/v1/chat/completions但接口协议与 Anthropic 的/v1/messages不兼容中间必须做协议桥接。OpenRig 的价值正在于用极简方式弥合这三者之间的鸿沟。它不追求功能堆砌而专注解决一个具体问题让本地模型能被 Codex CLI 当作“Claude 兼容模型”调用并让 Claude Desktop 通过系统代理间接使用该能力。这不是替代方案而是胶水层——就像给不同口径的水管拧上转接头让水流过去而不是再造一套供水系统。提示如果你在搜索 “OpenRig 官网” 或 “OpenRig 下载”大概率会空手而归。它没有官网、没有安装包、没有版本号。它的“发布”形式是一份README.md、一个.tmux.conf配置、一个start-rig.sh脚本以及几行关键的环境变量设置。这种去中心化、文档即产品的形态恰恰是当前 LLM 工具链 DIY 文化的真实写照。2. OpenRig 的底层结构Node.js tmux 代理桥接的三角闭环OpenRig 的技术骨架非常清晰由三个不可替代的组件构成Node.js 作为协议转换引擎、tmux 作为进程协调中枢、本地代理服务作为通信枢纽。这三者共同构成一个闭环缺一不可。下面我将逐层拆解它们各自的角色、选型依据以及为何其他替代方案在此场景下会失效。2.1 Node.js为什么必须是 Node.js而不是 Python 或 Rust很多人第一反应是“用 Python 写个 FastAPI 服务不更简单” 或者 “Rust 性能更好为什么不选” 实际上在 OpenRig 场景中Node.js 的胜出并非偶然而是由三个硬性约束决定的与 Codex CLI 的深度耦合Codex CLI 本身是用 TypeScript 编写的其核心逻辑如请求构造、流式响应解析、错误重试全部基于 Node.js 运行时。当你执行npx codex chat --model http://localhost:3000时Codex 内部会尝试用fetch()发起请求。而 Node.js 的node-fetch或原生fetch对本地 HTTP 服务的兼容性远超 Python 的requests后者默认不支持 HTTP/1.1 流式 chunked encoding 的完整解析易导致 Claude 的 SSE 流中断。我实测过用 Python FastAPI 做桥接Codex 在接收长响应时会卡在data:字段解析环节最终超时。轻量级热重载需求OpenRig 的调试频率极高——你可能每 5 分钟就要改一次模型路由规则或调整温度参数。Node.js 的nodemon可以在 300ms 内完成重启而 Python 的uvicorn --reload平均耗时 1.2 秒Rust 的cargo watch则需编译时间即使增量编译也常超 2 秒。对于需要快速验证“是否转发成功”的场景秒级延迟就是生产力断点。生态工具链的无缝集成npx是 OpenRig 工作流的启动入口。所有相关工具codex、lmstudio-cli、甚至自定义的openrig-proxy都通过npx分发。Node.js 的npx机制天然支持从任意 GitHub 仓库拉取并执行脚本如npx github:username/openrig-proxy无需全局安装。Python 的pipx或 Rust 的cargo install都不具备这种“即用即弃”的灵活性。因此OpenRig 中的 Node.js 并非“随便选的后端语言”而是整个工作流的信任锚点trust anchor。它确保了从 Codex CLI 发出的请求到本地模型返回的响应全程都在同一运行时环境中流转避免了跨语言序列化/反序列化的隐式开销和兼容性陷阱。2.2 tmux为什么不用 systemd、supervisord 或 Docker Composetmux 在 OpenRig 中承担的是“进程状态可视化管理器”角色而非简单的多窗口工具。它的不可替代性体现在三个实操痛点上实时日志聚合OpenRig 启动时通常要同时跑起 Codex CLI 的监听进程、LMStudio 的模型服务、以及 Node.js 的代理桥接服务。每个服务都有独立日志输出。用systemd管理时你需要journalctl -u codex-proxy -f、journalctl -u lmstudio -f、journalctl -u openrig-node -f三个命令来回切换用docker-compose logs -f则需记住容器名。而 tmux 的prefix ↑/↓键即可在预设的 pane 间瞬时切换且每个 pane 的滚动缓冲区独立保存Ctrl-b [进入复制模式方便回溯某次失败请求的完整上下文。会话持久化与断连恢复在家用笔记本跑 OpenRig 时合盖休眠、WiFi 切换、SSH 断连是常态。systemd服务会在断连后继续运行但你无法看到实时输出docker-compose依赖 Docker daemon 持续在线。而 tmux 会话在 SSH 断开后仍驻留在后台tmux attach即可无缝续接所有 pane 的状态、光标位置、滚动历史全部保留。我曾因停电导致笔记本关机重启后tmux ls仍显示openrig: 1 windows (created Tue May 28 14:22:17 2024)attach后发现 LMStudio 的 GPU 显存占用还在模型根本没卸载——这是其他方案做不到的“软重启”。资源隔离的轻量化实现OpenRig 不需要真正的容器隔离但需要防止某个服务崩溃拖垮全局。tmux 的kill-pane命令可以精准终止单个服务如Ctrl-b x删除当前 pane而不会影响其他 pane。相比之下systemctl stop会停掉整个 unitdocker-compose kill会干掉所有容器。这种“外科手术式”控制对调试阶段至关重要。注意tmux 的配置不是默认开箱即用的。OpenRig 标准配置中.tmux.conf必须包含set -g mouse on启用鼠标滚轮、bind-key -r H select-pane -L方向键切 pane、set -g status-left #[fggreen]#S #[fgyellow]#I:#P状态栏显示会话名窗格索引。这些细节看似琐碎实则是降低认知负荷的关键——让你的注意力始终聚焦在日志内容本身而非操作路径上。2.3 代理桥接为什么不能直接用 nginx 或 caddyOpenRig 的核心代理服务常命名为openrig-proxy必须是 Node.js 编写的原因在于它要处理Anthropic 协议与本地模型协议的双向语义映射而不仅仅是 HTTP 请求转发。nginx 和 caddy 属于七层代理只能做路径重写、Header 修改、负载均衡无法理解messages请求体中的system、max_tokens、temperature字段含义更无法将 LMStudio 返回的{ choices: [...] }结构正确转换为 Anthropic 要求的{ content: [...] }格式。一个典型转换流程如下以claude-3-haiku模拟调用本地deepseek-coder:33b为例Codex CLI 发送请求到http://localhost:3000/v1/messagesBody 包含{ model: claude-3-haiku-20240307, system: You are a helpful coding assistant., messages: [{role: user, content: Write a Python function to sort a list by frequency.}], max_tokens: 1024, temperature: 0.7 }openrig-proxy接收后需执行三项关键操作将model字段映射为本地模型标识如deepseek-coder:33b将systemmessages合并为 prompt 字符串并按 LMStudio 要求封装prompt: |system|...|user|...将max_tokens、temperature等参数转换为 LMStudio 的options对象{num_predict: 1024, temperature: 0.7}。LMStudio 返回{ model: deepseek-coder:33b, created_at: 2024-05-28T15:30:45.123Z, response: def sort_by_frequency(lst):\n from collections import Counter\n freq Counter(lst)\n return sorted(lst, keylambda x: freq[x]), done: true }openrig-proxy必须将其重构为 Anthropic 格式{ id: msg_abc123, type: message, role: assistant, content: [{type: text, text: def sort_by_frequency(lst):\n from collections import Counter\n freq Counter(lst)\n return sorted(lst, keylambda x: freq[x])}], model: claude-3-haiku-20240307, stop_reason: end_turn, stop_sequence: null, usage: {input_tokens: 42, output_tokens: 67} }这个过程涉及 JSON Schema 转换、字符串模板拼接、字段语义重解释必须由具备完整编程能力的服务完成。nginx 的map指令或 caddy 的replace指令连最基础的system字段提取都做不到。这就是为什么所有靠谱的 OpenRig 实现其代理层必然是 Node.js 编写的 Express/Fastify 服务而非配置文件驱动的反向代理。3. OpenRig 的标准部署流程从零开始构建一个可工作的 rig现在我们进入实操环节。以下是一个经过我反复验证、适配 Ubuntu 24.04 / macOS Sonoma / Windows WSL2 的 OpenRig 部署流程。它不依赖任何预编译二进制所有组件均可从源码或 npm 包直接获取确保最大可复现性。整个过程分为四个阶段环境准备 → 本地模型服务 → 代理桥接服务 → Codex 集成验证。3.1 环境准备Node.js 20 与 tmux 的最小化安装OpenRig 对 Node.js 版本有明确要求必须 ≥ v20.12.0。这是因为 Codex CLI 的anthropic-ai/sdk依赖undici6.x而该版本要求 Node.js 的fetchAPI 具备完整的ReadableStream支持v20.12 是首个稳定支持的 LTS 版本。低于此版本会出现TypeError: Response.body.getReader is not a function错误。在 Ubuntu 上推荐使用nvm安装避免与系统包管理器冲突# 安装 nvm curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc # 安装 Node.js 20.12.0注意不是 20.12.x 的任意版本20.12.0 是首个满足条件的精确版本 nvm install 20.12.0 nvm use 20.12.0 # 验证 node -v # 应输出 v20.12.0 npm -v # 应输出 10.2.4 或更高提示不要用apt install nodejs。Ubuntu 官方仓库的 Node.js 版本普遍滞后22.04 默认是 v18.19且apt安装的 npm 权限模型与nvm冲突会导致npx codex执行时提示EACCES: permission denied。这是新手踩坑率最高的第一步。tmux 的安装同样需注意版本。OpenRig 依赖tmux 3.3a及以上因其新增了pane-border-status选项可用于在状态栏显示各 pane 的服务状态如LMStudio: running。Ubuntu 24.04 默认源已包含 tmux 3.3a直接安装即可sudo apt update sudo apt install tmux tmux -V # 应输出 tmux 3.3amacOS 用户请用 Homebrewbrew install tmux brew install node20 # 注意不要用 brew install node那会装最新版v22Codex CLI 尚未完全兼容Windows 用户必须使用 WSL2Ubuntu 24.04并确保已启用虚拟机平台Virtual Machine Platform。这是claudes workspace requires the virtual machine platform on windows报错的唯一解法——不是靠注册表修改而是必须在 Windows 功能中勾选 “虚拟机平台” 并重启。WSL2 内核与 Windows 主机共享内存是运行 LMStudio 的必要条件。3.2 本地模型服务LMStudio 的静默安装与 API 启用LMStudio 是 OpenRig 生态中最主流的本地模型服务因其 GUI 界面友好、CLI 支持完善、且对 GGUF 格式模型兼容性最佳。但 OpenRig 场景下我们必须禁用 GUI仅启用 headless API 模式否则会占用额外显存并引入 GUI 相关的崩溃风险。下载与安装步骤以 Ubuntu 为例# 创建专用目录 mkdir -p ~/openrig/models ~/openrig/lmstudio # 下载 LMStudio CLI非 GUI 版本 wget https://github.com/lmstudio-ai/lmstudio/releases/download/v0.2.23/lmstudio-0.2.23-linux-x64.tar.gz tar -xzf lmstudio-0.2.23-linux-x64.tar.gz -C ~/openrig/lmstudio # 下载一个轻量级测试模型deepseek-coder:6.7b wget https://huggingface.co/TheBloke/deepseek-coder-6.7B-instruct-GGUF/resolve/main/deepseek-coder-6.7b-instruct.Q4_K_M.gguf -O ~/openrig/models/deepseek-coder-6.7b.Q4_K_M.gguf # 启动 LMStudio API关键参数说明 # --port 1234固定端口避免与 OpenRig 代理冲突 # --host 127.0.0.1仅监听本地禁止外网访问 # --no-gui强制 headless 模式 # --model-path指定模型路径 ~/openrig/lmstudio/lmstudio --port 1234 --host 127.0.0.1 --no-gui --model-path ~/openrig/models/deepseek-coder-6.7b.Q4_K_M.gguf启动后可通过curl http://localhost:1234/v1/models验证 API 是否就绪。正常响应应为{ object: list, data: [ { id: deepseek-coder-6.7b.Q4_K_M.gguf, object: model, owned_by: lmstudio } ] }注意LMStudio 的--model-path参数必须指向.gguf文件的绝对路径相对路径会导致加载失败且无明确报错。这是官方文档未强调的坑。另外首次加载模型时LMStudio 会进行量化参数校验耗时约 30-60 秒期间curl会返回503 Service Unavailable属正常现象无需重启。3.3 代理桥接服务openrig-proxy 的编写与配置这是 OpenRig 的心脏。我们创建一个极简但完备的 Express 服务命名为openrig-proxy。它需处理两件事请求转发与响应格式转换。首先初始化项目mkdir ~/openrig/proxy cd ~/openrig/proxy npm init -y npm install express cors body-parser创建index.jsconst express require(express); const cors require(cors); const bodyParser require(body-parser); const { createProxyMiddleware } require(http-proxy-middleware); const app express(); const PORT 3000; const LMSTUDIO_URL http://localhost:1234; // 中间件允许跨域Codex CLI 会发送 OPTIONS 预检 app.use(cors()); app.use(bodyParser.json({ limit: 10mb })); // 关键路由/v1/messages - 转发给 LMStudio 并转换格式 app.post(/v1/messages, async (req, res) { try { const { model, system, messages, max_tokens, temperature } req.body; // Step 1: 构建 LMStudio 的 prompt按其要求的格式 let prompt ; if (system) prompt |system|${system}|end|; messages.forEach(msg { if (msg.role user) prompt |user|${msg.content}|end|; if (msg.role assistant) prompt |assistant|${msg.content}|end|; }); prompt |assistant|; // Step 2: 构造 LMStudio 请求体 const lmstudioReq { model: deepseek-coder-6.7b.Q4_K_M.gguf, prompt: prompt, stream: false, options: { num_predict: max_tokens || 1024, temperature: temperature || 0.7, top_p: 0.9, repeat_penalty: 1.1 } }; // Step 3: 调用 LMStudio API const response await fetch(${LMSTUDIO_URL}/v1/chat/completions, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify(lmstudioReq) }); const lmstudioData await response.json(); // Step 4: 转换为 Anthropic 格式 const anthropicResponse { id: msg_${Date.now().toString(36)}, type: message, role: assistant, content: [{ type: text, text: lmstudioData.message?.content || lmstudioData.response || }], model: model || claude-3-haiku-20240307, stop_reason: end_turn, stop_sequence: null, usage: { input_tokens: Math.floor(prompt.length / 4), // 粗略估算 output_tokens: Math.floor((lmstudioData.message?.content || lmstudioData.response || ).length / 4) } }; res.json(anthropicResponse); } catch (error) { console.error(Proxy error:, error); res.status(500).json({ error: Internal server error }); } }); app.listen(PORT, () { console.log(OpenRig Proxy listening on http://localhost:${PORT}); });启动服务node index.js此时http://localhost:3000/v1/messages已成为一个符合 Anthropic 协议的端点。你可以用 curl 测试curl -X POST http://localhost:3000/v1/messages \ -H Content-Type: application/json \ -d { model: claude-3-haiku-20240307, messages: [{role: user, content: Hello, world!}] }如果返回结构正确的 JSON说明代理桥接已通。3.4 Codex 集成验证从 CLI 到桌面端的全链路打通最后一步让 Codex CLI 认识这个本地端点。Codex 的--model参数接受两种格式anthropic/claude-3-haiku-20240307远程或http://localhost:3000本地。但直接执行npx codex chat --model http://localhost:3000会失败因为 Codex 默认只信任https协议且会校验证书。解决方案是设置环境变量绕过验证# 设置 Codex 使用本地代理关键 export CODER_MODEL_ENDPOINThttp://localhost:3000 export NODE_TLS_REJECT_UNAUTHORIZED0 # 启动 Codex CLI注意必须加 --no-browser否则会尝试打开 Chrome npx codex chat --model http://localhost:3000 --no-browser如果一切顺利你会看到 Codex CLI 启动并在终端中显示Connected to http://localhost:3000。输入Hello它应返回来自deepseek-coder的响应。踩坑实录cc switch local proxy failed while handling codex endpoint /responses这个报错90% 源于CODER_MODEL_ENDPOINT环境变量未生效或NODE_TLS_REJECT_UNAUTHORIZED未设置。Codex CLI 启动时会读取环境变量但如果你在 tmux pane 中先启动了node index.js再在另一个 pane 中执行npx codex而没有export这两个变量就会出现此错误。解决方案是在 tmux 的~/.tmux.conf中添加set -g default-shell /bin/bash并在start-rig.sh脚本中统一export所有变量然后tmux new-session -s openrig -d bash -c source ~/openrig/env.sh node ~/openrig/proxy/index.js。Claude Desktop 的集成则更简单只需在系统级别设置 HTTP 代理。在 Ubuntu 上# 设置系统代理影响所有应用包括 Claude Desktop gsettings set org.gnome.system.proxy mode manual gsettings set org.gnome.system.proxy.http host 127.0.0.1 gsettings set org.gnome.system.proxy.http port 3000 gsettings set org.gnome.system.proxy.https host 127.0.0.1 gsettings set org.gnome.system.proxy.https port 3000然后启动 Claude Desktop它会自动将所有请求发往http://127.0.0.1:3000由openrig-proxy处理。这就是 OpenRig 的完整闭环。4. OpenRig 的进阶调优性能瓶颈定位与模型路由策略当 OpenRig 基础链路跑通后下一步是让它真正“好用”。这涉及两个维度性能优化降低延迟、提升吞吐和策略增强支持多模型、动态路由、错误降级。这两者不是锦上添花而是生产级使用的刚需。4.1 性能瓶颈诊断从 tmux 日志看透延迟来源OpenRig 的典型延迟分布在三个环节Codex CLI 解析请求 → openrig-proxy 协议转换 → LMStudio 模型推理。其中前两者是毫秒级后者是秒级。但实际体验中用户常抱怨“响应慢”这往往不是模型本身慢而是中间环节的阻塞。tmux 是你的第一双眼睛。在openrig-proxy的 pane 中开启DEBUGexpress:* node index.js你会看到每条请求的详细生命周期express:router dispatching POST /v1/messages 0ms express:router query : /v1/messages 0ms express:router expressInit : /v1/messages 0ms express:router corsMiddleware : /v1/messages 1ms express:router body-parser : /v1/messages 1ms express:router dispatching POST /v1/messages 1ms openrig-proxy:forwarding to LMStudio 2ms openrig-proxy:LMStudio response received 1247ms express:router dispatching POST /v1/messages 1248ms关键指标是LMStudio response received时间。如果该值稳定在 1200ms说明模型推理正常如果波动剧烈如 200ms → 5000ms则问题出在 LMStudio 层。此时切换到 LMStudio pane观察其日志若出现GPU OOM或CUDA out of memory说明显存不足需降低num_predict或换用 Q4_K_S 量化模型若出现Context length exceeded说明 prompt 过长需在openrig-proxy中添加截断逻辑prompt prompt.slice(-2048)若长时间无日志输出则是 LMStudio 进程卡死需kill -9后重启。实操心得我在一台 RTX 4090 上测试deepseek-coder:33b时发现num_predict: 2048会导致显存峰值达 22GB触发系统 OOM Killer。最终稳定参数是num_predict: 1024temperature: 0.3平均响应时间 850ms。这个数值无法理论推导必须实测——OpenRig 的价值正在于提供这种快速试错的沙盒。4.2 模型路由策略让 Codex CLI 智能选择后端硬编码deepseek-coder-6.7b显然不够灵活。理想状态下npx codex chat --model claude-3-haiku应调用deepseek-coder而--model claude-3-sonnet应调用llama3:70b。这就需要openrig-proxy具备模型路由能力。我们在index.js中扩展路由逻辑// 新增模型映射表 const MODEL_MAP { claude-3-haiku-20240307: { lmstudioModel: deepseek-coder-6.7b.Q4_K_M.gguf, quantization: Q4_K_M, contextLength: 16384 }, claude-3-sonnet-20240229: { lmstudioModel: llama3:70b, quantization: Q4_K_M, contextLength: 8192 }, claude-3-opus-20240229: { lmstudioModel: mixtral:8x7b, quantization: Q4_K_S, contextLength: 32768 } }; app.post(/v1/messages, async (req, res) { const { model } req.body; const route MODEL_MAP[model] || MODEL_MAP[claude-3-haiku-20240307]; // 默认 fallback // ... 其余逻辑不变仅替换 lmstudioReq.model 为 route.lmstudioModel });这样npx codex chat --model claude-3-sonnet-20240229就会自动路由到llama3:70b。但要注意Codex CLI 的--model参数只是字符串它不校验模型是否存在所以openrig-proxy必须做存在性检查if (!fs.existsSync(/home/user/openrig/models/${route.lmstudioModel})) { return res.status(400).json({ error: Model ${route.lmstudioModel} not found }); }4.3 错误降级机制当 LMStudio 挂掉时优雅 fallback 到备用模型生产环境中LMStudio 崩溃是常态。OpenRig 必须具备“故障转移”能力。我们在openrig-proxy中加入重试与降级逻辑async function callLMStudio(prompt, options, attempts 0) { try { const response await fetch(${LMSTUDIO_URL}/v1/chat/completions, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ model: deepseek-coder-6.7b.Q4_K_M.gguf, prompt, stream: false, options }) }); if (!response.ok) { throw new Error(LMStudio returned ${response.status}); } return await response.json(); } catch (error) { if (attempts 2) { console.warn(LMStudio failed, retrying... (${attempts 1}/2)); await new Promise(r setTimeout(r, 1000 * (attempts 1))); // 指数退避 return callLMStudio(prompt, options, attempts 1); } else { // 降级到 CPU 模型如 phi-3:3.8b console.warn(Falling back to phi-3:3.8b); const cpuResponse await fetch(${LMSTUDIO_URL}/v1/chat/completions, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ model: phi-3:3.8b, prompt, stream: false, options: { ...options, num_predict: 512 } }) }); return await cpuResponse.json(); } } }这个机制让 OpenRig 在主力 GPU 模型宕机时仍能提供基础服务而非彻底不可用。这才是一个真正可靠的本地 LLM 工作流。5. OpenRig 的边界与未来它不是万能解药而是特定场景的最优解聊完技术细节我想坦诚地谈谈 OpenRig 的局限性。它很强大但绝不万能。理解它的边界比学会如何部署更重要。5.1 OpenRig 无法解决的三类问题Claude Desktop 的功能阉割即使通过系统代理将请求转发给openrig-proxyClaude Desktop 的 UI 仍会显示“正在连接 Claude 云服务”且所有高级功能如文件上传、代码块执行、多轮对话记忆均不可用。这是因为这些功能依赖 Anthropic 的专有后端服务无法被本地模型模拟。OpenRig 只能接管/v1/messages这一条 API 路径其余全部失效。所以如果你需要 Claude 的完整体验OpenRig 不是替代方案而是补充方案——它让你在离线时仍能获得基础对话能力。多模态模型的支持缺失当前所有 OpenRig 实现都基于文本生成模型LLM。而 Claude 3 系列支持图像输入image_url字段Codex CLI 也预留了多模态接口。但 LMStudio/Ollama 的多模态支持尚不成熟如llava模型的图像编码器与 Anthropic 的base64图像解析不兼容openrig-proxy无法安全地桥接这一层。这意味着npx codex chat --model claude-3-haiku --image ./chart.png这类命令在 OpenRig 下必然失败。企业级安全与审计要求OpenRig 的NODE_TLS_REJECT_UNAUTHORIZED0设置本质上是关闭 TLS