企业官网建设流程全解析

1. 项目概述：OpenRig 是什么，它解决的是哪类人的哪类问题？

OpenRig 不是一个官方发布的成熟软件产品，也不是 Node.js 官方生态里的标准库，更不是 Codex 或 YAML 的子项目。它本质上是一套由开发者社区自发整理、组合、配置并开源共享的本地大模型推理与工具链协同运行环境模板。你在网上搜到的“openrig”相关讨论，90%以上指向一个 GitHub 上的开源仓库（通常名为openrig或openrig-template），其核心目标非常明确：让普通开发者、AI 工程师甚至技术爱好者，能在自己的一台 Linux 笔记本或小型服务器上，用尽可能少的手动干预，把多个关键组件——Node.js 运行时、tmux 会话管理器、Codex（注意：此处指代的是某款开源的、支持本地模型接入的 AI 编程助手前端，非 OpenAI 的 Codex 服务）、YAML 配置驱动的模型路由与参数控制——稳定、可复现、可调试地跑起来。

我第一次接触 OpenRig 是在帮一位做边缘 AI 教学的同事搭建课堂演示环境时。他需要向学生展示“如何让一个本地部署的 Llama-3-8B 模型，通过一个类 VS Code 的界面，实时响应代码补全请求，并且所有配置都能用文本文件管理”。当时我们试了五六种方案，要么依赖云 API（网络不稳定）、要么配置分散在十几个文件里（学生根本理不清逻辑）、要么启动命令一长串（每次重启都要查文档）。直到发现 OpenRig 的模板结构——所有东西都收在一个config.yaml里，npm start就能拉起 tmux 的三个窗格（一个跑模型服务、一个跑 Codex 后端、一个跑前端热更新），才真正体会到什么叫“开箱即配置”。

它的核心用户画像很清晰：不满足于纯 Web 端调用 API 的中阶开发者，有 Linux 基础但不想深陷 Docker Compose 编排细节的 AI 应用实践者，以及需要快速构建可交付教学/演示环境的技术讲师。它不解决“怎么训练模型”这种底层问题，而是专注在“怎么让训好的模型，在本地以最省心的方式，变成一个可用的、带 UI 的、可配置的编程助手”。关键词Node.js是它的胶水层，tmux是它的进程管家，Codex是它的交互门面，YAML是它的大脑——这四者缺一不可，共同构成了 OpenRig 的骨架。

你不需要是 DevOps 专家，但得知道npm install和tmux new-session是干什么的；你不需要会写 CUDA 内核，但得能看懂config.yaml里n_gpu_layers: 40这个参数意味着什么；你不需要精通 React，但得理解为什么 Codex 的前端要和后端用 WebSocket 连接。OpenRig 的价值，从来不在“多酷炫”，而在于“多省事”——它把一堆本来要花三天才能对齐版本、打通链路、调通参数的脏活累活，压缩成一次git clone && npm install && npm start，再加一次对 YAML 文件的微调。这才是它能在开发者论坛里被反复提及、被 fork 数千次的真实原因。

2. 整体架构设计与核心组件选型逻辑

2.1 为什么是 Node.js 而不是 Python 或 Rust？

OpenRig 的主控层选择 Node.js，这不是一个随意的决定，而是基于三重现实约束下的最优解。第一重是生态粘性：Codex 的前端（通常是基于 Electron 或类似框架）和绝大多数本地模型 API 封装库（比如llama.cpp的 Node.js binding、ollama的 JS SDK）都天然优先支持 JavaScript/TypeScript。如果强行用 Python 做主控，就得额外维护一套 WebSocket 代理、一套进程间通信桥接、一套日志聚合逻辑——这些在 Node.js 里，用child_process+ws+pino几行代码就能搞定。

第二重是开发体验一致性：整个工作流的最终使用者，大概率是写前端、写脚本、写 Node.js 服务的开发者。他们熟悉package.json的依赖管理，习惯用npm run dev启动服务，能快速读懂index.js里的启动逻辑。换成 Python，光是虚拟环境激活、pip 依赖冲突、Windows 下的路径分隔符问题，就能卡住一半人。我实测过，用 Python 替代 Node.js 主控后，新手首次成功启动的平均耗时从 12 分钟拉长到 47 分钟，主要时间都花在解决pyenv版本错乱和protobuf编译失败上。

第三重是轻量级进程管理适配性：Node.js 的child_process.spawn对子进程的 stdin/stdout/stderr 控制粒度极细，配合tmux的send-keys命令，可以做到精确到毫秒级的命令注入与日志捕获。而 Python 的subprocess.Popen在处理长时间运行、频繁 IO 的模型服务进程时，容易出现缓冲区阻塞或信号丢失。OpenRig 里那个著名的restart-model快捷键（Ctrl+B, R），背后就是 Node.js 主进程监听 tmux 窗格状态，一旦检测到模型服务崩溃，立刻kill -9并重新spawn，整个过程控制在 800ms 内——这个响应速度，是 Python 很难稳定保证的。

所以，Node.js 在这里不是“因为流行”，而是“因为够用、够快、够稳”。它就像一辆底盘扎实的皮卡：不炫技，但拉货稳、爬坡快、维修方便。

2.2 tmux：为什么不用 systemd 或 Docker？

你可能会问：既然要管理多个长期运行的服务，为什么不直接用systemd写 unit 文件？或者更现代一点，用docker-compose.yml？答案很实在：调试成本太高，学习曲线太陡，且违背 OpenRig “开箱即用” 的初心。

systemd的优势在于系统级守护，但劣势也致命：日志分散在journalctl里，进程状态要systemctl status查，重启要sudo systemctl restart，而 OpenRig 的典型使用场景是——你在咖啡馆用笔记本调试，没有 root 权限，也不想每次改个参数就 sudo 一把。更重要的是，systemd的依赖关系定义（After=、Wants=）在模型服务、Codex 后端、前端热更新这三者之间极其脆弱。比如模型服务启动慢了 2 秒，Codex backend就会因连接超时直接退出，而systemd默认不会自动重试，你需要写复杂的RestartSec=和StartLimitIntervalSec=，这已经超出“快速演示”的范畴。

Docker 更是如此。docker-compose up看似一键，但实际隐藏了巨大复杂度：你需要提前安装 Docker Engine，配置 NVIDIA Container Toolkit（如果跑 GPU 模型），处理 volume 权限映射（config.yaml放哪？模型文件放哪？日志输出到哪？），还要面对docker network的 DNS 解析问题——Codex 前端访问http://localhost:3000没问题，但访问http://model-service:8080就可能跨网段失败。我见过太多人在docker-compose.yml里折腾extra_hosts和network_mode: host两小时，最后发现只是忘了在config.yaml里把model_host从localhost改成host.docker.internal。

tmux 则完全不同。它就是一个终端复用器，Linux/macOS 自带，无需额外权限，所有操作都在当前用户会话内。OpenRig 的start.sh脚本本质就是：

tmux new-session -d -s openrig tmux send-keys -t openrig 'cd ./model-server && npm start' C-m tmux split-window -h -t openrig tmux send-keys -t openrig 'cd ./codex-backend && npm start' C-m tmux split-window -v -t openrig tmux send-keys -t openrig 'cd ./codex-frontend && npm run dev' C-m tmux attach-session -t openrig

这段脚本的每一行，都是肉眼可见、可打断、可修改、可重放的。学生在课堂上跟着敲，出错了删掉重来，5 秒就能恢复现场。这才是 OpenRig 真正的“低门槛”所在——它不追求架构的“正确性”，而追求操作的“确定性”。

2.3 Codex：这里指的不是 OpenAI 的 Codex

这是最容易产生误解的一点。网络搜索里大量出现的codex login、codex auth token、codex is ignoring unrecognized configuration，几乎全部指向 OpenAI 早已下线的 Codex 服务或某些第三方封装的 API 代理。但 OpenRig 里的 Codex，是一个完全独立的、开源的、本地优先的 AI 编程助手项目，常见名称包括codex-local、codex-cli或codex-desktop。它的核心能力是：提供一个 VS Code 风格的编辑器界面，后端对接本地模型 API（如llama.cpp的/completion端点），支持代码补全、注释生成、函数解释等基础功能，并通过 YAML 配置控制提示词模板、上下文长度、采样温度等参数。

它之所以被选入 OpenRig，关键在于其极简的本地化部署模型。主流的开源替代品如 Continue.dev、Tabby，虽然功能更强，但安装包动辄 200MB+，依赖 Rust 编译，启动时要下载 3GB 的模型权重。而 Codex-local 的设计哲学是“最小可行交互”：前端用 Vite 构建，静态资源打包后不到 5MB；后端用 Express，核心逻辑不到 300 行；模型接口完全遵循 OpenAI 兼容协议，这意味着你只要把llama.cpp或Ollama跑起来，它就能直接连上，零适配成本。

我在测试不同 Codex 实现时发现，codex-local的config.yaml里只需要填三行：

model: endpoint: "http://localhost:8080/v1" api_key: "sk-xxx" # 任意字符串，llama.cpp 不校验 model_name: "llama3:8b"

而 Continue.dev 的配置文件则需要定义server,models,providers,templates,context,editor六大区块，超过 200 行 YAML。对于 OpenRig 这种强调“五分钟上手”的模板，前者是刚需，后者是负担。

2.4 YAML：为什么不是 JSON、TOML 或环境变量？

YAML 成为 OpenRig 的配置中枢，绝非偶然。它在可读性、可维护性、可扩展性三者之间，找到了一个近乎完美的平衡点。

JSON 的问题是过于严格。一个多余的逗号、一个没引号的布尔值、一个换行缩进错误，都会导致整个配置解析失败。而 OpenRig 的典型用户，可能是刚学完 Python 基础的学生，让他写{"model":{"endpoint":"http://localhost:8080/v1","api_key":"sk-xxx"}}，远不如写：

model: endpoint: http://localhost:8080/v1 api_key: sk-xxx

来得直观。更重要的是，YAML 原生支持锚点与别名（&default/*default），这让 OpenRig 的config.yaml可以轻松实现“一份配置，多环境复用”。比如：

defaults: &defaults n_ctx: 4096 n_batch: 512 n_gpu_layers: 40 llama3-8b: <<: *defaults model_path: "./models/llama3-8b.Q4_K_M.gguf" phi-3-mini: <<: *defaults model_path: "./models/phi-3-mini.Q4_K_M.gguf" n_gpu_layers: 20 # 显存小的机器降级

这种结构，JSON 根本无法表达，TOML 虽然支持表继承但语法笨重，环境变量则完全无法描述嵌套结构。OpenRig 的config.yaml通常包含 5~8 个顶级区块（model,codex,frontend,logging,tmux,network），每个区块下又有 3~10 个参数，总行数在 80~150 行之间。YAML 的缩进语法让这种层级关系一目了然，修改时只需关注自己关心的那一块，不会误触其他部分。

提示：OpenRig 的config.yaml不是“配置文件”，而是“运行契约”。它定义了整个环境的行为边界——模型加载几层、前端端口开在哪、tmux 窗格命名规则、日志级别设为 debug 还是 info。改错一个参数，可能导致整个链路中断，所以务必养成“改前备份、改后验证”的习惯。

3. 核心细节解析与实操要点拆解

3.1 Node.js 版本与依赖管理的隐性陷阱

OpenRig 对 Node.js 版本的要求，表面看是>=18.0.0，但实际踩坑点远不止于此。我统计过 GitHub Issues 里前 50 个“npm install 失败”的案例，72% 的根源在于Node.js 与 native addon 的 ABI（应用二进制接口）不匹配。

具体来说，OpenRig 依赖的几个关键包：

• node-llama-cpp：封装 llama.cpp 的 Node.js binding，编译时需匹配 Node.js 的 V8 引擎版本；
• @tensorflow/tfjs-node（如果启用 TF.js 后端）：依赖特定版本的 libtensorflow；
• sharp（用于前端图片处理）：需要匹配系统的 libvips 版本。

这些 native addon 在npm install时会触发node-gyp rebuild，而node-gyp的编译结果，严格绑定于当前 Node.js 的NODE_MODULE_VERSION。例如，Node.js v18.18.2 的NODE_MODULE_VERSION是 108，v20.11.0 是 115，v22.2.0 是 120。如果你用nvm install 22装了最新版，但node-llama-cpp的 prebuild binary 只发布了到 v20 的版本，npm install就会卡在gyp ERR! build error，然后开始漫长的源码编译——在树莓派上，这个过程可能持续 40 分钟以上，且大概率因内存不足失败。

我的实操建议是：永远用nvm use指定一个经过 OpenRig 仓库 CI 验证的 LTS 版本。目前（2024 年中）最稳妥的是v18.20.2（对应NODE_MODULE_VERSION=108）或v20.13.1（对应NODE_MODULE_VERSION=115）。检查方法很简单：打开 OpenRig 仓库的.github/workflows/ci.yml，找到node-version:字段，那里写的版本就是经过全链路测试的黄金版本。

另一个常被忽略的细节是package-lock.json的锁定策略。OpenRig 的package.json里，很多依赖写的是^1.2.0这样的 caret range，这意味着npm install会安装1.2.x中最新的 patch 版本。但某些 patch 版本（如sharp@3.3.0）会悄悄升级 libvips 到 8.15，而 Ubuntu 22.04 默认的 libvips 是 8.12，导致运行时报libvips.so.42: cannot open shared object file。解决方案是：在npm install后，立即执行npm ci。npm ci会严格按package-lock.json里的 exact version 安装，跳过 semver 解析，彻底规避 patch 版本带来的 ABI 不兼容风险。

注意：npm ci要求项目根目录必须存在package-lock.json，且不能有node_modules文件夹。所以标准流程是：rm -rf node_modules package-lock.json && git checkout -- package-lock.json && npm ci。别图省事用npm install，那是在给自己埋雷。

3.2 tmux 会话的健壮性设计：不只是分屏那么简单

OpenRig 的tmux脚本看似简单，但其背后的健壮性设计，才是它能稳定运行数天的关键。默认的tmux new-session命令，创建的是一个“临时会话”，一旦你的 SSH 连接断开，tmux 会话就会被 kill。而 OpenRig 的start.sh里，一定会包含：

# 确保 tmux server 已启动，且会话持久化 tmux has-session -t openrig 2>/dev/null || tmux new-session -d -s openrig

has-session检查会话是否存在，-d参数让新会话在后台 detached 模式启动，这样即使你本地终端关闭，tmux server 依然在运行，所有子进程不受影响。这是实现“服务常驻”的第一步。

第二步是进程健康检查与自动重启。OpenRig 的 Node.js 主控进程（index.js）里，会定期执行：

// 每 30 秒 ping 一次各服务端口 const services = [ { name: 'model', port: 8080 }, { name: 'codex-backend', port: 3001 }, { name: 'frontend', port: 3000 } ]; services.forEach(service => { const controller = new AbortController(); setTimeout(() => controller.abort(), 5000); // 5秒超时 fetch(`http://localhost:${service.port}/health`, { signal: controller }) .catch(err => { console.error(`[HEALTH] ${service.name} down:`, err.message); // 触发 tmux 重启该窗格 execSync(`tmux send-keys -t openrig:'${service.name}' 'Ctrl+C' C-m`, { stdio: 'ignore' }); setTimeout(() => { execSync(`tmux send-keys -t openrig:'${service.name}' '${getStartCommand(service)}' C-m`, { stdio: 'ignore' }); }, 1000); }); });

这段逻辑，让 OpenRig 具备了基础的自愈能力。当llama.cpp因显存溢出崩溃时，/health接口返回 503，Node.js 主进程立刻发送Ctrl+C终止 tmux 窗格里的旧进程，等待 1 秒后，再发送新的启动命令。整个过程无需人工介入，用户刷新前端页面，3 秒内就能看到服务恢复。

第三步是日志隔离与滚动。OpenRig 的tmux窗格默认不保存历史日志，但实际生产中你需要查问题。解决方案是在start.sh里为每个窗格添加日志重定向：

tmux send-keys -t openrig 'cd ./model-server && npm start 2>&1 | tee ../logs/model.log' C-m tmux send-keys -t openrig 'cd ./codex-backend && npm start 2>&1 | tee ../logs/backend.log' C-m

tee命令将 stdout 和 stderr 同时输出到终端和文件，../logs/目录需提前创建。更进一步，可以用logrotate配置每日滚动，避免日志文件无限增长。

3.3 Codex 配置的核心参数与调试技巧

Codex 的config.yaml是 OpenRig 的“神经中枢”，其中几个参数直接影响用户体验，必须精准理解其含义：

最关键的调试技巧是启用 Codex 的 debug 日志。在config.yaml的logging区块里，设置：

logging: level: "debug" file: "./logs/codex-debug.log"

然后启动后，观察codex-debug.log里的请求链路：

[DEBUG] Received request from frontend: {"messages":[{"role":"user","content":"如何用 Python 计算斐波那契数列？"}]} [DEBUG] Forwarding to model endpoint: POST http://localhost:8080/v1/chat/completions [DEBUG] Model response received: {"choices":[{"message":{"content":"def fib(n):...}}]} [DEBUG] Sending response to frontend

如果卡在Forwarding to model endpoint，说明 Codex 后端能连通，但模型服务无响应，问题在llama.cpp；如果卡在Received request from frontend，说明前端到后端的 WebSocket 连接失败，检查frontend.port和浏览器 CORS 设置。

另一个高频问题：代码补全延迟高。这通常不是模型慢，而是n_ctx（上下文长度）设置过大。llama.cpp的推理速度与n_ctx呈平方级关系。n_ctx: 4096时，首 token 延迟可能达 800ms；降到2048，延迟降至 300ms。OpenRig 的config.yaml里，n_ctx应根据你的 GPU 显存动态调整：RTX 3090（24GB）可设4096，RTX 4060（8GB）建议1024，树莓派 CM4（2GB）只能设512。

3.4 YAML 配置的继承与覆盖机制详解

OpenRig 的config.yaml支持 YAML 的高级特性，其中最实用的是Merge Key (<<)和Anchor (&)。它们让一份配置文件能同时服务于多个模型、多种硬件环境，而无需复制粘贴。

假设你的config.yaml结构如下：

# 定义全局默认值 defaults: &defaults n_gpu_layers: 40 n_batch: 512 n_threads: 8 verbose: false # 定义模型专属配置 models: llama3-8b: <<: *defaults model_path: "./models/llama3-8b.Q4_K_M.gguf" n_ctx: 4096 phi-3-mini: <<: *defaults model_path: "./models/phi-3-mini.Q4_K_M.gguf" n_ctx: 2048 n_gpu_layers: 20 # 显存小，减少 GPU 层 # Codex 配置引用模型 codex: model: endpoint: "http://localhost:8080/v1" api_key: "sk-xxx" model_name: "llama3-8b"

这里<<: *defaults的作用，是把defaults锚点定义的所有键值对，浅拷贝到当前节点下。phi-3-mini继承了n_gpu_layers: 40，但又用自己的n_gpu_layers: 20覆盖了它，最终生效的是20。这种机制，让配置既保持 DRY（Don't Repeat Yourself），又具备足够的灵活性。

更强大的是Environment-based Override。OpenRig 的启动脚本start.sh会读取环境变量OPENRIG_ENV，并自动加载对应的覆盖文件：

# start.sh 片段 ENV=${OPENRIG_ENV:-"dev"} if [ -f "config.$ENV.yaml" ]; then echo "Loading config override: config.$ENV.yaml" # 合并 config.yaml 和 config.dev.yaml yq eval-all '. as $item ireduce ({}; . * $item)' config.yaml config.$ENV.yaml > config.merged.yaml fi

这样，你可以创建config.dev.yaml（开发环境，verbose: true,n_ctx: 1024）和config.prod.yaml（生产环境，verbose: false,n_ctx: 4096），通过OPENRIG_ENV=prod npm start切换，无需修改主配置。

实操心得：YAML 的<<合并是浅层的，不支持深层嵌套覆盖。比如defaults里定义了logging: {level: "info"}，你不能在phi-3-mini里只覆盖logging.level，而必须重写整个logging对象。这是 YAML 规范限制，不是 OpenRig 的 bug。

4. 完整实操流程与核心环节实现

4.1 环境准备：从零开始的 15 分钟部署

以下步骤基于 Ubuntu 22.04（WSL2 或物理机），全程无需 root 权限，所有操作在$HOME/openrig目录下完成。

第一步：安装 Node.js（nvm 方式）

# 安装 nvm curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc # 安装并切换到验证过的 LTS 版本 nvm install 18.20.2 nvm use 18.20.2 node -v # 应输出 v18.20.2 npm -v # 应输出 9.9.2

第二步：克隆 OpenRig 仓库并安装依赖

# 创建项目目录 mkdir -p ~/openrig && cd ~/openrig # 克隆官方推荐模板（以 github.com/openrig/template 为例） git clone https://github.com/openrig/template.git . git checkout v1.2.0 # 使用稳定 tag，避免 master 分支的未测试变更 # 安装依赖（注意：必须用 npm ci！） rm -rf node_modules package-lock.json npm ci

第三步：准备模型文件

OpenRig 默认不附带模型，你需要自行下载。推荐使用llama.cpp官方量化模型：

# 创建模型目录 mkdir -p ./models # 下载 Llama3-8B 4-bit 量化版（约 4.2GB） wget https://huggingface.co/TheBloke/Llama-3-8B-Instruct-GGUF/resolve/main/Llama-3-8B-Instruct.Q4_K_M.gguf -O ./models/llama3-8b.Q4_K_M.gguf # 验证文件完整性（可选） sha256sum ./models/llama3-8b.Q4_K_M.gguf # 应与 Hugging Face 页面上的 checksum 一致

第四步：配置config.yaml

用你喜欢的编辑器（如nano）打开config.yaml，重点修改以下部分：

# 修改模型路径 model: model_path: "./models/llama3-8b.Q4_K_M.gguf" # 确保路径正确 # 根据你的 GPU 调整 GPU 层 llama_cpp: n_gpu_layers: 40 # RTX 3090/4090 可用 40；RTX 4060 用 20；CPU 模式设为 0 # 确保端口不冲突 frontend: port: 3000 backend: port: 3001 # 模型服务端口 model_server: port: 8080

第五步：启动 OpenRig

# 赋予启动脚本执行权限 chmod +x ./start.sh # 启动（会自动创建 tmux 会话） ./start.sh

此时，终端会自动 attach 到 tmux 会话，显示三个窗格：

• 左上：model-server日志，应看到llama.cpp server listening on http://127.0.0.1:8080
• 右上：codex-backend日志，应看到Codex backend started on http://localhost:3001
• 下方：codex-frontend日志，应看到VITE v4.5.2 ready in 123 ms

第六步：访问前端界面

打开浏览器，访问http://localhost:3000。你应该看到一个简洁的 Codex 编辑器界面。在输入框里输入Hello world，按下Ctrl+Enter，等待 2~3 秒，即可看到模型生成的补全内容。

实测心得：首次启动时，llama.cpp需要将模型文件加载到 GPU 显存，这个过程可能长达 60~120 秒（取决于模型大小和显存带宽）。期间model-server窗格会显示loading model...，这是正常现象，耐心等待即可。后续重启会快得多，因为显存已缓存。

4.2 模型服务（llama.cpp）的深度调优

OpenRig 的模型服务默认使用llama.cpp的server模式，但其默认参数对大多数消费级 GPU 并不友好。以下是针对不同硬件的调优指南：

GPU 显存 < 8GB（如 RTX 4060）：

llama_cpp: n_gpu_layers: 20 n_ctx: 2048 n_batch: 256 threads: 6 verbose: false

n_gpu_layers: 20表示只把前 20 层 Transformer 放到 GPU，其余在 CPU 计算，平衡速度与显存占用。n_batch: 256降低批处理大小，避免显存 OOM。

GPU 显存 ≥ 12GB（如 RTX 3090/4090）：

llama_cpp: n_gpu_layers: 45 # 尝试最大值，llama.cpp 会自动降级 n_ctx: 4096 n_batch: 512 threads: 12 verbose: false # 启用 Flash Attention（需 CUDA 12.1+） flash_attn: true

flash_attn: true可提升长上下文推理速度 20~30%，但要求 CUDA 版本 ≥ 12.1。检查方法：nvcc --version。

纯 CPU 模式（无 GPU）：

llama_cpp: n_gpu_layers: 0 n_ctx: 2048 n_batch: 128 threads: $(nproc) # 使用全部 CPU 核心 main_gpu: 0 # 启用 AVX2 加速（Intel CPU） use_mmap: true use_mlock: false

use_mmap: true允许内存映射加载模型，避免一次性将整个 GGUF 文件读入 RAM，对 8GB 内存的机器至关重要。

所有这些参数，最终都会被llama.cpp/server的启动命令拼接：

./bin/server \ -m ./models/llama3-8b.Q4_K_M.gguf \ -c 4096 \ -b 512 \ -ngl 40 \ -t 12 \ --port 8080 \ --host 127.0.0.1

你可以直接在model-server窗格里按Ctrl+B, :进入 tmux 命令模式，输入respawn-pane重启服务，实时测试不同参数的效果。

4.3 Codex 前端的定制化开发

OpenRig 的 Codex 前端基于 Vite + React，结构清晰，非常适合二次开发。核心文件路径：

./codex-frontend/ ├── src/ │ ├── App.tsx # 主应用组件 │ ├── components/ # UI 组件 │ │ ├── Editor.tsx # Monaco 编辑器封装 │ │ └── ChatPanel.tsx # 对话面板 │ ├── hooks/ # 自定义 hook │ │ └── useCodex.ts # 与 Codex 后端通信 │ └── utils/ # 工具函数 ├── vite.config.ts # Vite 配置 └── index.html

最常见的定制需求是修改默认提示词（System Prompt）。编辑src/hooks/useCodex.ts，找到getSystemPrompt()函数：

export const getSystemPrompt = () => { return `You are a senior Python developer working at a fintech company. Your task is to write clean,