OpenRig：面向本地大模型推理的命令行编排工具详解

1. 项目概述：OpenRig 是什么，它解决的到底是什么问题

OpenRig 这个名字在当前技术社区里出现得越来越频繁，但很多人第一次看到时会下意识把它和“挖矿 rig（矿机）”或者“硬件测试平台”联系起来——这其实是个典型的误读。OpenRig 的本质，是一个面向本地大模型推理与开发工作流的轻量级、可组合、终端优先的命令行驱动型开发环境编排工具。它不提供模型本身，也不封装 UI 界面，而是像一个“数字扳手”，把 Node.js 运行时、tmux 会话管理、Codex 协议适配层、YAML 配置引擎这几样东西拧在一起，形成一套可复现、可版本化、可协作的本地 AI 工程化脚手架。

我第一次在 GitHub 上看到 OpenRig 仓库时，它只有不到 300 行核心代码，README 里第一句话就写着：“If you’re tired of copy-pasting curl commands, editing .env files by hand, and losing tmux panes when your laptop sleeps — this is for you.” 这句话精准击中了我过去半年里反复踩坑的痛点：每次调试一个本地部署的 Llama 3-70B 模型，都要手动开 4 个 tmux pane，分别跑 Ollama server、Codex proxy、前端 mock server 和日志 tail；改一次模型参数就得重写三处 YAML、两处环境变量、再重启整个会话；更别说某次深夜调试时合上笔记本，醒来发现所有 session 全丢，连 prompt template 都没来得及 git commit。OpenRig 就是为这种“真实、高频、琐碎、易错”的本地 AI 开发现场而生的。

它的核心价值不是“多了一个新工具”，而是把原本散落在终端、编辑器、浏览器、配置文件之间的开发动作，收束成一条清晰的 YAML 声明式流水线。你写一个rig.yaml，定义好 model、endpoint、proxy、hooks、env，执行openrig up，它就自动拉起 tmux 会话、启动依赖服务、注入环境变量、绑定端口、输出实时日志流；执行openrig down，它就干净地 kill 所有子进程、释放端口、清理临时文件，不留任何后台残留。这不是 Docker Compose 的替代品——它不抽象容器，也不处理镜像分发；它比 Docker Compose 更贴近开发者的手指，因为它直接操作你每天敲的那些命令、你习惯用的那些工具、你信任的那些终端交互逻辑。

对新手来说，OpenRig 是降低本地大模型调试门槛的“脚手架加速器”：不用再查“如何让 Codex 正确转发 /responses 请求到本地 Ollama”，不用再纠结“tmux 如何保存会话状态”，更不用在package.json里硬塞一堆scripts去模拟服务编排。对资深工程师而言，它是可审计、可 CI/CD 化的本地验证层：rig.yaml可以提交进 Git，团队新人git clone && openrig up就能获得和你完全一致的本地推理环境；CI 流水线里跑openrig test，就能在干净容器中验证模型 API 兼容性，无需启动完整 Web 应用。它不取代任何底层技术，却让 Node.js、tmux、Codex、YAML 这四样东西产生了 1+1+1+1 > 4 的协同效应——而这，正是当前本地 AI 工程化最缺的一块“胶水”。

2. 核心设计思路拆解：为什么是这四件套？为什么不是 Docker 或其他？

OpenRig 的技术选型看似随意，实则每一步都踩在本地 AI 开发的真实约束上。我们来逐层拆解它为何坚定选择 Node.js + tmux + Codex + YAML 这个组合，而不是走 Docker、Kubernetes、Electron 或 Python FastAPI 的路子。

首先是Node.js。很多人看到热词里有 “node.js 安装教程”“node.js 是干什么的”，下意识觉得这是个“前端工具”。但 OpenRig 选 Node.js，恰恰是因为它在终端场景下的不可替代性：极低的安装门槛（curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash - && sudo apt-get install -y nodejs一行搞定）、跨平台二进制分发成熟（.deb/.rpm/.pkg/.exe全覆盖）、原生支持子进程控制（child_process.spawn对接 tmux 和模型服务毫无压力）、以及最重要的——它自带一个稳定、广泛兼容、无需额外安装的 HTTP 客户端（fetch/https.request），这让它能无缝对接 Codex 的 RESTful 接口，无需引入requests、curl或httpx等外部依赖。我试过用 Python 重写核心逻辑，光是处理 Windows 下subprocess.Popen的编码问题和信号传递就花了两天；而 Node.js 在 macOS、Linux、Windows WSL 上表现高度一致，这对一个面向终端用户的工具是生死线。

其次是tmux。为什么不用screen？不用systemd --user？甚至不用 Docker 的--detach？因为 tmux 提供了唯一一种既满足“进程守护”又保留“交互可见性”的方案。systemd --user启动的服务默认不输出 stdout/stderr 到终端，调试时你得journalctl -u xxx去翻日志，效率极低；Docker detach 后你得docker logs -f，但无法像 tmux 那样随时Ctrl-b o切换 pane 查看不同服务的实时输出；screen虽然功能类似，但其会话恢复机制在 macOS 上长期存在 bug（特别是休眠唤醒后），而 tmux 的resurrect插件经过数年打磨已非常稳定。OpenRig 的up命令本质就是生成一段 tmux 脚本：创建命名会话 → 分割多个 pane → 在每个 pane 中执行指定命令 → 自动重命名 pane 标签（如 “ollama-server”、“codex-proxy”、“log-tail”）。这种“所见即所得”的调试体验，是任何后台守护进程都无法提供的。

第三是Codex。这里必须澄清一个关键点：OpenRig 使用的 Codex，不是 GitHub Copilot 的 Codex，也不是某个闭源商业产品，而是开源社区维护的 Codex 协议兼容代理实现（典型代表是codex-proxy或codex-local）。它的作用，是把标准 OpenAI API 格式的请求（如POST /v1/chat/completions），无损转换为本地模型服务（Ollama、llama.cpp、Text Generation WebUI）能理解的格式（如POST /api/chat或POST /completion），并做响应体反向映射。为什么非它不可？因为当前几乎所有大模型前端 SDK（LangChain、LlamaIndex、Vercel AI SDK）都默认对接 OpenAI 兼容接口，如果你强行改 SDK 源码去适配 Ollama 原生 API，每次 SDK 升级都会冲突。Codex 作为中间协议层，让你“零修改”接入本地模型——这也是为什么热词里大量出现 “ccswitch 配置 codex”、“codex 接入 deepseek”、“codex 配置失败”——大家真正卡住的，从来不是模型本身，而是协议桥接这最后一公里。OpenRig 把 Codex 的启动、配置、健康检查全部纳入 YAML 声明，彻底消灭了手动npm run codex -- --host 0.0.0.0:3000 --model llama3这类易错操作。

最后是YAML。为什么不用 JSON？不用 TOML？甚至不用纯 JavaScript 配置？因为 YAML 是目前唯一能在“人类可读性”和“机器可解析性”之间取得完美平衡的格式。JSON 不支持注释，而 OpenRig 的配置里大量需要说明（如# 此处填 Ollama 模型名，非 HuggingFace ID）；TOML 在嵌套结构和数组表达上远不如 YAML 直观；JavaScript 配置虽然灵活，但会引入执行风险（恶意配置可执行任意代码）且无法被静态分析工具校验。更重要的是，YAML 的锚点（&anchor）和引用（*anchor）机制，让复杂配置复用成为可能——比如你有 5 个不同 rig，它们共享同一套env和hooks，只需定义一次base_env: &base_env { ... }，其余地方env: *base_env即可。我在实际项目中用这个特性，把一个包含 12 个服务、37 个环境变量、8 类 hook 的 rig.yaml 从 420 行压缩到 186 行，且可读性反而提升。

这四件套组合的底层逻辑，是“最小可行抽象”原则：不试图重新发明轮子，而是把现有最佳实践用最薄的胶水粘合。它不解决模型训练，不解决 GPU 调度，不解决分布式推理——它只解决“让本地模型调试这件事，变得像git pull && npm start一样确定、简单、可重复”。这恰恰是当前 AI 工具链中最被忽视，也最影响生产力的一环。

3. 核心细节解析与实操要点：从零搭建一个可用的 OpenRig 环境

要真正用好 OpenRig，不能只停留在npm install -g openrig && openrig init这种表面操作。我带过 7 个不同背景的工程师落地 OpenRig，发现 83% 的首次失败都源于对三个核心细节的理解偏差：YAML 配置的层级语义、Codex 代理的端口绑定逻辑、以及 tmux 会话的生命周期管理。下面我将用一个真实案例——“本地运行 DeepSeek-V2-Chat 并通过 Codex 暴露为 OpenAI 兼容 API”——带你逐行拆解关键配置和避坑要点。

3.1 YAML 配置的深层语义与常见陷阱

OpenRig 的rig.yaml不是简单的键值对列表，而是一个具有严格层级语义的声明式蓝图。我们来看一个精简但完整的示例：

# rig.yaml name: "deepseek-v2-rig" version: "1.0" services: ollama: command: "ollama run deepseek-coder:6.7b" port: 11434 healthcheck: url: "http://localhost:11434/api/tags" timeout: 5000 interval: 10000 codex: command: "npx codex-proxy --host 0.0.0.0:3000 --model deepseek-coder:6.7b --backend http://localhost:11434" port: 3000 depends_on: ["ollama"] healthcheck: url: "http://localhost:3000/health" timeout: 3000 interval: 5000 frontend: command: "cd ./my-app && npm run dev" port: 5173 depends_on: ["codex"] env: NODE_ENV: "development" CODER_MODEL: "deepseek-coder:6.7b" # 注意：此处的 CODER_MODEL 是给 frontend 用的，和 codex 的 --model 参数无关 hooks: pre_up: - "echo 'Starting DeepSeek-V2 rig...'" - "ollama list | grep deepseek-coder || ollama pull deepseek-coder:6.7b" post_down: - "echo 'Rig stopped. Cleaning up...'" logging: level: "info"

这个配置里藏着几个极易踩坑的关键点：

提示：depends_on不是 Docker Compose 里的“等待就绪”，而是 OpenRig 的启动顺序保证。它只确保ollama进程先于codex启动，但不等待ollama的/api/tags返回成功。所以必须配合healthcheck字段——OpenRig 会在ollama启动后，每隔 10 秒向http://localhost:11434/api/tags发 GET 请求，连续 3 次成功才认为服务就绪，然后启动codex。很多用户配置了depends_on却没加healthcheck，导致 Codex 启动时 Ollama 还没加载完模型，报错ECONNREFUSED。

注意：command字段中的端口绑定必须显式指定--host 0.0.0.0。Codex 默认只监听127.0.0.1，这意味着它只能被本机访问。但 OpenRig 的frontend服务（如 Vite 开发服务器）通常运行在另一个 tmux pane，其网络命名空间与 Codex 相同，所以127.0.0.1是通的；然而，如果你后续想用手机或另一台电脑访问这个 API（比如测试移动端集成），就必须改成0.0.0.0。我见过太多人卡在这里，反复检查防火墙、端口转发，最后发现只是 Codex 没加--host 0.0.0.0。

警告：env字段定义的环境变量，只注入到 OpenRig 自身进程及其子进程中，不会自动透传给services里定义的 command。上面配置里的CODER_MODEL变量，对codex-proxy命令完全无效。正确做法是在codex.command中直接写死，或使用 YAML 的字符串插值（如果 OpenRig 版本支持）：

codex: command: "npx codex-proxy --host 0.0.0.0:3000 --model ${CODER_MODEL} --backend http://localhost:11434"

但更推荐的做法是：把所有 service-specific 的变量，直接写在对应 service 的command里，保持配置的自包含性，避免隐式依赖。

3.2 Codex 代理的核心参数与调试技巧

Codex 代理是 OpenRig 的“神经中枢”，它的配置错误会导致整个 rig 无法对外提供服务。我们重点解析npx codex-proxy命令中几个最关键的参数：

• --model deepseek-coder:6.7b：这个参数告诉 Codex，“当收到 OpenAI 格式的/v1/chat/completions请求时，应将其转换为 Ollama 的/api/chat请求，并在model字段填入deepseek-coder:6.7b”。注意，这里的模型名必须和ollama list输出的 NAME 列完全一致（包括大小写和冒号），否则 Ollama 会返回model not found。我建议永远先执行ollama list确认模型名，再写入 YAML。

• --backend http://localhost:11434：这是 Codex 转发请求的目标地址。必须是http://开头，不能是https://（除非你给 Ollama 配了 TLS）；端口必须和ollamaservice 的port字段一致；localhost是对的，因为 Codex 和 Ollama 运行在同一台机器的同一网络命名空间（tmux 会话内），localhost解析为 127.0.0.1 完全正确。曾有用户改成http://192.168.1.100:11434，结果 Codex 启动失败——因为 tmux pane 内没有该 IP 的路由。

• --host 0.0.0.0:3000：如前所述，这是对外暴露的监听地址。0.0.0.0表示监听所有网卡，3000是端口。你可以根据需要改成8000或5000，但要确保该端口未被占用（lsof -i :3000或netstat -tulpn | grep :3000）。

调试 Codex 最有效的方法，是绕过 OpenRig，直接手动启动它并观察日志：

# 1. 先确保 Ollama 已运行 ollama serve & # 2. 手动启动 Codex，开启详细日志 npx codex-proxy --host 0.0.0.0:3000 --model deepseek-coder:6.7b --backend http://localhost:11434 --log-level debug # 3. 在另一个终端发送测试请求 curl -X POST http://localhost:3000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-coder:6.7b", "messages": [{"role": "user", "content": "Hello"}] }'

如果返回{"error":{"message":"model not found","type":"invalid_request_error"...}}，说明 Codex 没找到模型，检查--model参数；如果返回{"error":{"message":"connect ECONNREFUSED 127.0.0.1:11434"...}}，说明 Ollama 没启动或端口不对；如果 curl 命令卡住无响应，大概率是--host没设对，或者防火墙拦截了 3000 端口。

3.3 tmux 会话管理的实操细节与恢复策略

OpenRig 的up命令本质是调用 tmux 创建一个名为openrig-deepseek-v2-rig的会话，并在其中创建多个 pane。理解 tmux 的会话生命周期，是避免“rig 启动后找不到日志”“合盖后服务消失”等问题的关键。

首先，OpenRig 默认创建的会话是attached（已连接）状态，这意味着你执行openrig up后，终端会自动进入 tmux 会话，显示所有 pane 的实时输出。此时按Ctrl-b d可以 detach（分离）会话，回到普通 shell，而所有服务仍在后台运行。要重新连接，只需tmux attach-session -t openrig-deepseek-v2-rig。

提示：OpenRig 的down命令，会向 tmux 会话发送kill-session命令，强制终止所有 pane 中的进程。但如果你是手动Ctrl-b ddetach 后关机，tmux 会话默认会被系统杀死（除非你启用了tmux resurrect插件）。因此，强烈建议所有用户在使用 OpenRig 前，先配置 tmux-resurrect：

# 安装 resurrect 插件 git clone https://github.com/tmux-plugins/tpm ~/.tmux/plugins/tpm # 在 ~/.tmux.conf 中添加 set -g @plugin 'tmux-plugins/tpm' set -g @plugin 'tmux-plugins/tmux-resurrect' # 重载配置 tmux source-file ~/.tmux.conf # 安装插件 prefix + I (prefix 通常是 Ctrl-b)

配置好后，每次openrig up启动的会话，都会被自动保存。即使断电、崩溃、合盖，只要tmux进程还在，你执行prefix + Ctrl-r就能一键恢复所有 pane 和命令。

其次，OpenRig 为每个 service 分配的 pane 标签（pane title）是动态生成的，格式为[service-name] [pid]。例如ollama 12345。这个 pid 是ollama serve进程的 PID，不是 tmux pane 的 ID。当你需要单独 kill 某个 service（比如 Ollama 卡死），不要kill 12345，而应该先进入对应 pane（Ctrl-b o循环切换），然后Ctrl-c发送 SIGINT。因为ollama serve是前台进程，Ctrl-c会优雅退出；而kill -9 12345可能留下僵尸进程或锁文件。

最后，一个鲜为人知但极其有用的技巧：OpenRig 支持openrig exec <service> <command>。比如你想在ollamapane 中执行ollama list，不用手动切过去，直接：

openrig exec ollama "ollama list"

OpenRig 会自动找到ollamaservice 对应的 tmux pane，发送命令并返回输出。这在写自动化脚本或 CI 流水线时非常高效。

4. 实操过程与核心环节实现：从初始化到生产级验证的全流程

现在我们把前面所有知识点串起来，完成一个端到端的 OpenRig 实战：从零开始，搭建一个支持 DeepSeek-V2-Chat 的本地推理环境，并通过 Codex 暴露为标准 OpenAI API，最终用一个简单的 Node.js 脚本验证其可用性。整个过程我将记录每一步的命令、预期输出、常见问题及解决方案，确保你能 100% 复现。

4.1 环境准备与依赖安装（5 分钟）

第一步永远是确认基础环境。OpenRig 对系统要求极低，但必须确保以下四项已就绪：

1. Node.js LTS（v20.x 或 v22.x）：不是最新版 v24，因为热词里提到error installing 24.21.0: node.js v24.21.0 is not yet released，说明 v24 尚不稳定。我推荐 v20.12.2（2024 年 6 月最新 LTS）。

   # 检查是否已安装 node -v # 应输出 v20.x.x npm -v # 应输出 10.x.x # 如果未安装，macOS 用 Homebrew brew install node@20 brew link --overwrite node@20 # Ubuntu/Debian curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash - sudo apt-get install -y nodejs # Windows：从 https://nodejs.org/dist/ 下载 v20.x.x LTS 安装包，勾选 "Add to PATH"

2. tmux（>= 3.2a）：检查版本tmux -V，低于 3.2 的需升级。Ubuntu 22.04 默认是 3.2a，够用；macOSbrew install tmux；Windows WSLsudo apt install tmux。

3. Ollama（>= 0.3.0）：这是运行本地模型的引擎。官网下载地址https://ollama.com/download，安装后执行ollama --version确认。

4. Git（用于克隆示例）：git --version。

注意：不要用nvm管理 Node.js 版本。OpenRig 是全局 CLI 工具，nvm的 shell hook 会导致openrig命令在 tmux pane 中找不到正确的 Node.js 版本。务必用系统级安装（Homebrew/apt/Windows Installer）。

4.2 初始化 OpenRig 项目与配置编写（10 分钟）

创建项目目录，初始化 OpenRig：

mkdir deepseek-rig && cd deepseek-rig npm init -y npm install -g openrig # 全局安装 CLI openrig init # 生成默认 rig.yaml

openrig init会生成一个基础模板，但我们按 DeepSeek-V2 需求重写rig.yaml。将以下内容保存为rig.yaml：

name: "deepseek-v2-rig" version: "1.0" services: ollama: command: "ollama serve" port: 11434 healthcheck: url: "http://localhost:11434/api/tags" timeout: 5000 interval: 10000 codex: command: "npx codex-proxy --host 0.0.0.0:3000 --model deepseek-coder:6.7b --backend http://localhost:11434 --log-level info" port: 3000 depends_on: ["ollama"] healthcheck: url: "http://localhost:3000/health" timeout: 3000 interval: 5000 log: command: "tail -f /tmp/openrig-deepseek.log" # 这个 service 用于集中查看所有日志，需配合 hooks 写入 env: NODE_ENV: "development" hooks: pre_up: - "echo '=== Starting DeepSeek-V2 Rig ==='" - "ollama list | grep 'deepseek-coder:6.7b' || (echo 'Pulling deepseek-coder:6.7b...' && ollama pull deepseek-coder:6.7b)" - "touch /tmp/openrig-deepseek.log" post_up: - "echo 'Rig is ready! Test with: curl http://localhost:3000/health'" pre_down: - "echo 'Shutting down rig...'" post_down: - "rm -f /tmp/openrig-deepseek.log" - "echo 'Rig stopped.'" logging: level: "info"

关键改动说明：

• ollama.command改为ollama serve（前台模式），而非ollama run（交互模式），因为run会阻塞终端，无法被 OpenRig 管理。
• codex.command显式添加--log-level info，确保日志可读。
• 新增logservice，用tail -f实时跟踪日志文件，方便集中监控。
• hooks.pre_up中加入ollama pull检查，避免首次运行时因模型未下载而失败。

4.3 启动与验证（3 分钟）

执行启动命令：

openrig up

预期行为：

• 终端自动进入 tmux 会话，显示 3 个 pane：
  • [ollama] xxxxx：输出time=2024-06-15T10:00:00Z level=info msg="Listening on 127.0.0.1:11434"
  • [codex] yyyyy：输出INFO codex-proxy listening on http://0.0.0.0:3000
  • [log] zzzzz：初始为空，等待日志写入

如果一切正常，稍等 10-15 秒（等待 healthcheck 通过），在新终端执行：

curl http://localhost:3000/health # 应返回 {"status":"ok","codex_version":"x.y.z","backend":"ollama"} curl -X POST http://localhost:3000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-coder:6.7b", "messages": [{"role": "user", "content": "Write a Python function to calculate factorial."}] }' | jq '.choices[0].message.content' # 应返回类似 "def factorial(n):\n if n == 0 or n == 1:\n return 1\n else:\n return n * factorial(n-1)"

常见问题速查表：

问题现象	可能原因	解决方案
openrig up报错Command failed: tmux new-session -d -s openrig-deepseek-v2-rig	tmux 未安装或 PATH 不对	which tmux确认路径，export PATH="/usr/local/bin:$PATH"临时修复
codexpane 显示Error: Cannot find module 'codex-proxy'	npx未正确安装codex-proxy	手动执行npx codex-proxy --version，若失败则npm install -g codex-proxy
curl返回{"error":{"message":"model not found"...}}	ollama list中无deepseek-coder:6.7b	手动执行ollama pull deepseek-coder:6.7b，再openrig down && openrig up
curl卡住无响应	Codex 的--host是127.0.0.1而非0.0.0.0	修改rig.yaml，重启openrig up

4.4 生产级验证：用 Node.js 脚本模拟真实 SDK 调用（5 分钟）

最后一步，证明 OpenRig 不仅能跑通 curl，还能被主流 SDK 无缝集成。创建test-sdk.js：

// test-sdk.js import { OpenAI } from "openai"; const openai = new OpenAI({ apiKey: "dummy-key", // Codex 不校验 key，填任意值 baseURL: "http://localhost:3000/v1", // 指向 Codex }); async function main() { const completion = await openai.chat.completions.create({ model: "deepseek-coder:6.7b", // 必须和 ollama list 一致 messages: [{ role: "user", content: "Explain how OpenRig works in 3 bullet points." }], }); console.log("Response:", completion.choices[0].message.content); } main().catch(console.error);

安装依赖并运行：

npm install openai node test-sdk.js

如果看到清晰的三段式回答，恭喜，你的 OpenRig 环境已达到生产可用级别：它能被任何遵循 OpenAI API 规范的 SDK、前端框架、CLI 工具直接调用，无需任何代码修改。

5. 常见问题与排查技巧实录：来自 7 个真实项目的故障库

在带团队落地 OpenRig 的过程中，我系统性地记录了所有报错、超时、连接拒绝类问题，并按发生频率和解决难度做了分级。下面这份“故障库”，是我从 7 个项目、23 次部署、156 小时调试中提炼出的精华，每一条都附带根因分析和一招见效的解决方案。

5.1 高频问题（发生率 > 60%）

问题：openrig up后codexpane 立即退出，日志显示Error: listen EADDRINUSE: address already in use :::3000

• 根因分析：端口 3000 已被其他进程占用。常见于：之前openrig up未正常down，tmux 会话残留导致 Codex 进程未退出；或本地有其他服务（如另一个 Codex 实例、Vite 项目、Python Flask）占用了 3000 端口。
• 一招解决：执行lsof -i :3000（macOS/Linux）或netstat -ano | findstr :3000（Windows），找到 PID，kill -9 <PID>。更彻底的方案是，在rig.yaml中为codex.port换一个不常用的端口，如3001或8080，并同步更新baseURL。

问题：curl http://localhost:3000/health返回curl: (7) Failed to connect to localhost port 3000: Connection refused

• 根因分析：Codex 进程根本没启动成功，或启动后立即崩溃。根本原因 90% 是--backend地址错误。
• 一招解决：手动启动 Codex，开启 debug 日志：

  npx codex-proxy --host 0.0.0.0:3000 --model deepseek-coder:6.7b --backend http://localhost:11434 --log-level debug

  观察输出。如果第一行就报Error: connect ECONNREFUSED 127.0.0.1:11434，说明 Ollama 没运行或端口不对；如果卡在INFO codex-proxy listening...后无响应，说明--host没生效，检查是否漏了0.0.0.0:。

问题：ollama run deepseek-coder:6.7b在终端能跑，但openrig up启动后模型加载极慢（> 5 分钟）

• 根因分析：Ollama 默认使用 CPU 推理，而deepseek-coder:6.7b是 6.7B 参数模型，在 CPU 上加载权重、分配内存耗时巨大。OpenRig 的healthcheck默认 5 秒超时，3 次失败就判定服务异常。
• 一招解决：在ollamaservice 的healthcheck中，大幅增加timeout和interval：

  healthcheck: url: "http://localhost:11434/api/tags" timeout: 30000 # 30秒超时 interval: 60000 # 60秒检查一次

  同时，确保你的机器有足够内存（建议 ≥ 16GB RAM），并考虑为 Ollama 配置 GPU 加速（OLLAMA_NUM_GPU=1环境变量）。

5.2 中频问题（发生率 20%~40%）

问题：openrig down后，lsof -i :3000仍显示有进程，openrig up再次失败

• 根因分析：OpenRig 的down命令通过 tmux 发送kill-session，但某些情况下（如 Codex 进程被 SIGKILL 强杀），tmux