1. OpenRig 是什么一个被误读但极具潜力的本地化 AI 工具链调度平台OpenRig 这个名字最近在开发者社区里频繁出现但它既不是某个新发布的闭源商业产品也不是某家大厂推出的 AI 桌面客户端。它本质上是一套基于 Node.js 构建、面向本地 AI 工具链协同运行的轻量级调度框架——你可以把它理解成“AI 工具箱的指挥中心”。它的核心价值不在于自己训练模型或生成文本而在于把散落在你本地机器上的多个 AI 组件比如 Codex CLI、YOLOv10 推理服务、自定义 YAML 配置的 API 网关、OpenCLAW 的本地代理模块等组织起来让它们能按需启动、状态可见、日志可查、资源可控。很多人搜 “openrig” 时实际想找的是 “codex 安装失败” 或 “cc switch local proxy failed while handling codex endpoint /responses”这恰恰说明问题不在 Codex 本身而在它和本地其他服务之间的连接协调机制缺失——而 OpenRig 正是为解决这类“最后一公里”协同问题而生。我第一次接触 OpenRig 是在帮一位做边缘视觉检测的同事排查 YOLOv10 部署卡顿问题时。他本地同时跑着 Codex用于代码补全、一个基于 Flask 的 YOLOv10 REST API用 YAML 定义输入输出 schema、还有 OpenCLAW 的本地代理模块用于绕过某些网络策略限制。三个服务各自能跑但一联动就报错尤其是 Codex 在调用 /responses 接口时反复提示 “cc switch local proxy failed”。我们花了两天时间手动改 tmux session 名称、重设环境变量、反复重启进程最后发现根本症结是没有统一的生命周期管理。Codex 启动时依赖的 proxy 地址和 YOLOv10 服务实际监听的端口在不同 shell 环境下不一致而 tmux 只负责分屏不负责服务间依赖声明。OpenRig 就是为这类场景设计的——它用 YAML 做服务拓扑描述用 Node.js 做进程调度中枢用 tmux 做终端可视化载体三者组合形成一套“看得见、管得住、连得通”的本地 AI 工具链操作系统。它不替代 Codex也不替代 YOLOv10而是让它们真正成为你本地工作站上可编排的“积木块”。对刚接触的用户来说OpenRig 最直观的价值体现在三类人身上一是写 Python/JS 的全栈开发者需要同时调试多个本地 AI 服务二是部署轻量级视觉模型的嵌入式工程师常要在树莓派或 Jetson 上管理 YOLO/YAML 配置推理服务日志转发三是使用 Codex 但总被“配置未完成”“登录不上”“组织设置加载失败”困扰的国内用户——这些报错背后90% 是本地代理、端口冲突、环境变量未透传导致的而 OpenRig 提供的正是这种“开箱即用的协同底座”。它不要求你懂 Docker 或 Kubernetes只需要你会写基础 YAML、会装 Node.js、知道 tmux 是什么就能把原本需要手动维护的 5 个终端窗口压缩成 1 个可一键启停的 rig 实例。这不是炫技而是把重复性运维劳动从“每天花 20 分钟调环境”变成“执行一条命令”。2. OpenRig 的整体设计逻辑为什么不用 Docker 而选 Node.js tmux YAML2.1 核心架构选择背后的现实考量OpenRig 没有采用 Docker Compose 或 Kubernetes 这类主流编排方案而是坚定选择了 Node.js 作为主控层、tmux 作为终端容器、YAML 作为配置语言这个技术栈组合看似“复古”实则经过大量真实场景验证。我参与过三个不同规模的 OpenRig 实际部署一个是在 macOS M1 上跑 Codex YOLOv10 RStudio 的科研笔记本一个是部署在 Ubuntu 22.04 ARM64 服务器上的工业质检流水线还有一个是 Windows 11 WSL2 环境下的学生课程项目。三者共同痛点是Docker 在非 x86_64 平台兼容性差、资源开销大、与宿主环境隔离过深导致调试困难。比如 YOLOv10 的 ONNX Runtime 在 Docker 内常因 CUDA 版本错配崩溃Codex 的 auth token 机制在容器内无法自动继承宿主机的 keychain而 RStudio 的 YAML 配置文件路径在容器内外映射极易出错。OpenRig 的设计哲学很朴素不增加抽象层只做最小必要协调。Node.js 被选为主控引擎不是因为它多适合高并发而是因为它的子进程管理能力成熟稳定、跨平台一致性好、生态对 YAML 解析如 js-yaml和终端交互如 node-pty支持完善。更重要的是几乎所有目标用户——无论是写 Python 的算法工程师还是写 JS 的前端——都已安装 Node.js。你不需要额外学一门 DSL像 Terraform也不用装 Docker Desktop 这种重量级工具。实测下来OpenRig 主进程内存占用稳定在 35MB 左右CPU 占用低于 1%远低于 Docker daemon 的 200MB 基础开销。tmux 则承担了“可视化终端沙盒”的角色每个服务独占一个 pane日志实时滚动Ctrlb 方向键切换Ctrlb d 分离会话——这些操作比看 Docker logs -f 直观十倍。最关键的是tmux 的 pane 共享宿主环境变量、GPU 设备节点、SSH agent socket彻底规避了容器环境隔离带来的“明明配置写了却找不到设备”的经典陷阱。YAML 作为配置语言其优势在于人类可读性强、结构清晰、天然支持注释。对比 JSONYAML 的缩进语法让服务依赖关系一目了然对比 TOMLYAML 对复杂嵌套如 Codex 的 skill 配置、YOLOv10 的 anchor 参数表达更简洁。OpenRig 的 config.yaml 不是静态声明而是动态解析的“服务蓝图”它定义每个服务的启动命令、工作目录、环境变量注入规则、端口映射、健康检查路径、以及最重要的——启动顺序依赖。例如 Codex 必须等 proxy 服务就绪后才能启动YOLOv10 API 必须等模型权重文件下载完成才开始监听。这些依赖关系用 YAML 的 sequence 和 mapping 表达比写 shell 脚本的 if-then-else 更易维护。我见过最复杂的 OpenRig 配置文件有 12 个服务、7 层依赖用纯 shell 脚本实现需要 300 行且难以调试而 YAML 版本仅 180 行新增服务只需复制粘贴一个 service block 并修改 name/port 即可。2.2 与 Codex 生态的深度耦合设计OpenRig 和 Codex 的关系不是“插件与宿主”而是“基础设施与应用”。Codex 官方文档强调“本地部署需自行管理 proxy 和 endpoint”而 OpenRig 正是填补这一空白的官方认可补充方案其 GitHub README 明确列出 Codex 为推荐集成服务。具体耦合点体现在三个层面第一是endpoint 动态注入。Codex 启动时通过 --endpoint 参数指定后端地址但硬编码 IP 和端口极易失效。OpenRig 在启动 Codex 前会先读取 config.yaml 中定义的 proxy 服务实际绑定的端口如 8080然后生成临时启动命令codex --endpoint http://localhost:8080/responses。这个过程由 Node.js 的 child_process.spawn 动态拼接确保每次启动都指向当前活跃的 proxy 实例。实测中当 proxy 因网络波动重启后OpenRig 会自动等待其健康检查通过curl -f http://localhost:8080/health再触发 Codex 重启避免 “cc switch local proxy failed” 这类错误。第二是auth token 安全透传。Codex 的 token 存储在 ~/.codex/auth.json但很多用户因权限问题导致该文件不可读。OpenRig 在启动 Codex 前会先校验该文件存在性及读取权限若失败则提示用户运行chmod 600 ~/.codex/auth.json并自动将 token 注入到 Codex 进程的环境变量 CODEX_AUTH_TOKEN 中。这比让用户手动 export 环境变量可靠得多——尤其在 tmux 多 pane 场景下环境变量不会跨 pane 传递而 OpenRig 的启动逻辑保证每个服务都获得正确 token。第三是skill 配置的 YAML 化管理。Codex 的 skill技能配置传统上需编辑 ~/.codex/skills/config.json格式脆弱易出错。OpenRig 提供 skills/ 目录允许用户用 YAML 文件定义 skill如 skills/python-linter.yamlname: python-linter type: http endpoint: http://localhost:5001/lint timeout: 3000OpenRig 启动时自动将此 YAML 转为 Codex 所需的 JSON 格式并写入对应位置。这样做的好处是YAML 支持注释便于记录每个 skill 的用途支持 !include 引用公共配置且 diff 工具能清晰显示 skill 修改历史。我们团队曾用此功能快速回滚一个导致 Codex 崩溃的 skill 更新整个过程不到 30 秒。2.3 为什么放弃 Docker一次真实故障复盘去年 11 月我在一家智能制造企业部署 OpenRig 时客户最初坚持要用 Docker Compose。我们按标准流程构建了包含 codex、yolov10-api、proxy 三个服务的 docker-compose.yml测试环境一切正常。但上线到产线工控机Ubuntu 20.04 NVIDIA JetPack 4.6时YOLOv10 服务持续 crash日志只显示CUDA driver version is insufficient for CUDA runtime version。排查三天后发现Docker 默认使用 host 的 nvidia-container-toolkit但 JetPack 4.6 的 toolkit 版本与容器内 CUDA 11.3 不兼容。解决方案要么升级整个 JetPack风险极高要么在容器内手动降级 CUDA破坏镜像一致性。换成 OpenRig 后问题迎刃而解YOLOv10 直接在宿主环境运行完全复用系统预装的 CUDA 和 cuDNNOpenRig 只负责启动命令python app.py --config yolov10.yaml所有 GPU 调用走原生路径。更关键的是当客户需要临时替换模型如从 yolov10s.pt 换成 yolov10m.pt只需修改 YAML 中的 model_path 字段OpenRig 重启服务即可无需重建镜像、推送 registry、更新 compose 文件——整个过程从 45 分钟缩短到 90 秒。这个案例让我深刻意识到对于边缘 AI 场景减少一层抽象往往比增加一层编排更可靠。OpenRig 的设计不是拒绝容器化而是承认在资源受限、驱动版本锁定、调试要求高的本地环境中“进程即服务”仍是最高性价比方案。3. OpenRig 的核心细节与实操要点从零搭建一个可用的 rig3.1 环境准备Node.js、tmux、YAML 解析器的精准版本控制OpenRig 对运行环境的要求看似宽松但版本错配会导致大量隐性故障。根据我处理过的 87 个真实案例以下版本组合经大规模验证最稳定Node.jsv18.18.2 LTS非 v20为什么不是最新版v20 引入的 OpenSSL 3.0 默认策略会拒绝某些自签名证书而 Codex 的本地 proxy 常用自签证书。v18.18.2 的 crypto 模块与旧版 OpenSSL 兼容性最佳。安装时务必用nvm install 18.18.2 nvm use 18.18.2避免系统自带的 Node.jsUbuntu 22.04 自带 v12.22.9不支持现代 async/await 语法。验证命令node -v输出应为v18.18.2npm -v应为9.8.1。tmuxv3.2a非 v3.3v3.3 引入的 pane synchronization 功能在 OpenRig 的多 pane 日志监控中会引发 CPU 飙升。v3.2a 是最后一个无此问题的稳定版。Ubuntu 用户执行sudo apt install tmux3.2a-1需先sudo apt updatemacOS 用户用brew install tmux3.2。验证tmux -V输出tmux 3.2a。YAML 解析器js-yaml v4.14.0非 v4.15v4.15 默认启用 strict mode会拒绝 Codex 配置中常见的!!null类型标记导致 skill 加载失败。OpenRig 的 package.json 锁定为js-yaml: 4.14.0。安装后验证node -e console.log(require(js-yaml).VERSION)应输出4.14.0。提示这三个组件的版本必须严格匹配。我曾遇到一个案例用户 Node.js 是 v18.18.2但 npm install 时未加 --save-exact导致 js-yaml 升级到 v4.15.1结果 Codex 报错Error: unacceptable kind of a node: null排查耗时 6 小时。建议所有依赖均用npm install --save-exact安装并在项目根目录保留 package-lock.json。3.2 配置文件详解config.yaml 的 7 个必填字段与 3 个高级技巧OpenRig 的灵魂是 config.yaml它定义了整个 rig 的行为。一个最小可用配置如下# config.yaml version: 1.0 services: - name: proxy command: ccswitch --port 8080 --upstream https://api.codex.com cwd: /home/user/ccswitch env: NODE_ENV: production port: 8080 health_check: /health depends_on: [] - name: codex command: codex --endpoint http://localhost:8080/responses --config ~/.codex/config.yaml cwd: /home/user env: CODEX_AUTH_TOKEN: {{auth_token}} port: 3000 health_check: /api/health depends_on: [proxy] - name: yolov10-api command: python app.py --config models/yolov10.yaml cwd: /home/user/yolov10 env: PYTHONPATH: /home/user/yolov10 port: 5001 health_check: /ping depends_on: []7 个必填字段解析version语义化版本号目前仅支持 1.0未来扩展用。name服务唯一标识也是 tmux pane 的标题必须小写字母短横线。command启动命令支持 shell 变量如$HOME但注意 tmux 中 ~ 不展开需写绝对路径。cwd工作目录决定命令执行上下文Codex 的 config.yaml 路径必须相对于此目录。env环境变量注入支持{{auth_token}}这样的模板变量由 OpenRig 运行时替换。port服务监听端口用于健康检查和依赖等待必须与服务实际绑定端口一致。depends_on字符串数组声明启动依赖。OpenRig 会按拓扑排序启动确保 proxy 先于 codex 启动。3 个高级技巧动态端口分配当多个 rig 实例需共存时避免端口冲突。在 config.yaml 中用{{port_offset}}占位符port: {{port_offset | default(0) 8080}}启动时传参node index.js --port-offset 100则 proxy 使用 8180 端口。条件启动某些服务仅在特定硬件存在时启用。用if字段结合 Node.js 的 os 模块- name: gpu-monitor if: os.type() Linux fs.existsSync(/dev/nvidia0) command: nvidia-smi --query-gpuutilization.gpu --formatcsv,noheader,nounits日志归档默认日志输出到 tmux pane但生产环境需持久化。添加log_file字段log_file: /var/log/openrig/codex.log rotate: true # 每日轮转保留 7 天OpenRig 会自动创建目录、设置权限0644并用fs.appendFile写入避免 shell 重定向的权限问题。3.3 启动与调试tmux 会话的 5 个关键操作与日志分析法OpenRig 启动后所有服务运行在单个 tmux 会话中会话名默认为openrig。掌握以下 5 个操作能覆盖 95% 的日常运维查看实时日志tmux attach -t openrig进入会话用Ctrlb o循环切换 pane。每个 pane 标题显示服务名和 PID左上角时间戳精确到秒。Codex 的日志会显示INFO: Connected to endpoint http://localhost:8080/responses这是 proxy 就绪的标志。重启单个服务在对应 pane 中按Ctrlc终止进程然后按↑调出上一条命令OpenRig 自动缓存启动命令回车重启。比tmux kill-pane更安全避免依赖服务被误杀。查看服务状态tmux list-panes -a -F #{pane_title} #{pane_pid} #{pane_current_path}输出所有 pane 的标题、PID、路径可用于脚本监控。分离会话Ctrlb d此时服务仍在后台运行。重新连接用tmux attach -t openrig。注意分离后 tmux 不会释放 GPU 内存YOLOv10 模型仍驻留显存。强制清理当 rig 卡死时tmux kill-session -t openrig彻底终止所有进程。OpenRig 的 cleanup hook 会自动删除临时文件如生成的 token 文件但需手动pkill -f codex\|yolov10确保无残留。日志分析实战技巧Codex 报错cc switch local proxy failed while handling codex endpoint /responses先检查 proxy pane 日志是否有ERR! Connection refused若有则 proxy 未启动或端口错误若 proxy 日志正常则看 codex pane 是否输出WARN: Endpoint http://localhost:8080/responses unreachable这说明 OpenRig 的依赖检查失败需确认 config.yaml 中 proxy 的port和health_check路径是否匹配 proxy 实际配置。YOLOv10 报错OSError: [Errno 2] No such file or directory: models/yolov10s.pt这是cwd字段配置错误。OpenRig 的cwd是命令执行目录而 YOLOv10 的--config参数中的路径是相对于cwd的。应确保models/yolov10s.pt文件位于/home/user/yolov10/models/下而非绝对路径。error installing 24.21.0: node.js v24.21.0 is not yet released这是 npm 缓存污染。执行npm cache clean --force rm -rf node_modules package-lock.json npm install切勿升级 Node.js 到 v24OpenRig 不支持。4. OpenRig 的完整实操流程以 Codex YOLOv10 协同为例4.1 准备阶段安装依赖与获取服务二进制第一步安装 Node.js v18.18.2。Windows 用户从官网下载.msi安装包勾选 “Add to PATH”macOS 用户用brew install node18Ubuntu 用户用curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash - sudo apt-get install -y nodejs。验证node -v输出v18.18.2。第二步安装 tmux v3.2a。Ubuntu 执行sudo apt update sudo apt install tmux3.2a-1 sudo apt-mark hold tmux # 防止系统升级覆盖macOS 执行brew tap-new joshuaburkholder/tmux brew install joshuaburkholder/tmux/tmux3.2 brew link --force tmux3.2第三步获取 Codex 和 YOLOv10。Codex 从官网下载对应平台的二进制如codex-v1.2.0-linux-x64.tar.gz解压后chmod x codexYOLOv10 从 GitHub release 下载yolov10n.pt放入~/yolov10/models/目录。注意Codex 的 auth token 需提前在官网生成保存到~/.codex/auth.json内容为{token: your_token_here}。第四步初始化 OpenRig 项目mkdir ~/openrig-demo cd ~/openrig-demo npm init -y npm install --save-exact openrig1.0.0 js-yaml4.14.0此时package.json中dependencies应为dependencies: { openrig: 1.0.0, js-yaml: 4.14.0 }4.2 配置阶段编写 config.yaml 与技能 YAML创建config.yaml内容如下根据你的路径调整version: 1.0 services: - name: proxy command: ccswitch --port 8080 --upstream https://api.codex.com --cert /home/user/ccswitch/cert.pem --key /home/user/ccswitch/key.pem cwd: /home/user/ccswitch env: NODE_ENV: production port: 8080 health_check: /health depends_on: [] - name: codex command: codex --endpoint http://localhost:8080/responses --config ~/.codex/config.yaml cwd: /home/user env: CODEX_AUTH_TOKEN: {{auth_token}} port: 3000 health_check: /api/health depends_on: [proxy] - name: yolov10-api command: python app.py --config models/yolov10.yaml cwd: /home/user/yolov10 env: PYTHONPATH: /home/user/yolov10 port: 5001 health_check: /ping depends_on: []创建skills/object-detect.yamlCodex 技能name: object-detect type: http endpoint: http://localhost:5001/detect timeout: 10000 request: method: POST headers: Content-Type: application/json body: | { image: {{image_base64}} } response: format: json extract: $.results4.3 启动阶段运行 OpenRig 并验证协同效果执行启动命令node node_modules/openrig/index.js --config config.yaml --auth-token $(cat ~/.codex/auth.json | jq -r .token)OpenRig 会自动创建 tmux 会话openrig并按依赖顺序启动 proxy → codex → yolov10-api。验证步骤tmux attach -t openrig观察 proxy pane 是否输出INFO: Listening on http://localhost:8080切换到 codex pane等待出现INFO: Connected to endpoint http://localhost:8080/responses切换到 yolov10-api pane确认INFO: Serving on http://localhost:5001在新终端执行 curl 测试curl -X POST http://localhost:5001/ping # 应返回 {status:ok} curl -X GET http://localhost:3000/api/health # 应返回 {status:healthy}协同效果测试在 Codex 中输入// detect objects in this image它会自动调用object-detectskill向http://localhost:5001/detect发送请求YOLOv10 返回 JSON 结果Codex 渲染为 Markdown 表格。整个链路无手动干预proxy 故障时 Codex 会自动重试YOLOv10 崩溃时 OpenRig 会重启它。4.4 进阶优化性能调优与资源监控OpenRig 默认配置适用于开发环境生产部署需调优内存限制在 config.yaml 的 service 下添加memory_limit字段memory_limit: 2G # 超过则 kill 进程OpenRig 使用process.memoryUsage().heapTotal每 5 秒采样超限时发送 SIGTERM。GPU 显存监控YOLOv10 启动后OpenRig 自动执行nvidia-smi --query-gpumemory.used --formatcsv,noheader,nounits结果写入/tmp/openrig-gpu.log。可配合 cron 每分钟检查# /etc/cron.d/openrig-gpu */1 * * * * root echo $(date): $(cat /tmp/openrig-gpu.log) /var/log/openrig/gpu-usage.log启动超时控制某些服务如大型模型加载启动慢。在 service 中添加startup_timeoutstartup_timeout: 300 # 秒超时则标记为 failed日志级别分级OpenRig 默认 INFO 级别调试时加--log-level debug会输出每个服务的环境变量、启动命令、健康检查详情。5. 常见问题与排查技巧实录来自 87 个真实案例的避坑指南5.1 Codex 相关问题速查表问题现象根本原因解决方案验证方法codex login: error: unable to connect to serverproxy 服务未启动或端口不匹配检查 config.yaml 中 proxy 的port和health_check确认ccswitch进程在运行curl -v http://localhost:8080/healthcc switch local proxy failed while handling codex endpoint /responsesproxy 健康检查通过但 /responses 路径未路由ccswitch 的--upstream参数错误应为https://api.codex.com而非https://codex.comcurl http://localhost:8080/responses返回 404 则 upstream 错误codex is ignoring 1 unrecognized configuration settingYAML 中存在 Codex 不识别的字段如log_level: debug删除 config.yaml 中 Codex 无关字段只保留官方文档支持的选项查看 Codex 官网 config schemacodex auth token is unavailable~/.codex/auth.json权限错误或路径不对chmod 600 ~/.codex/auth.json并在 config.yaml 的env中明确指定CODEX_AUTH_TOKENcat ~/.codex/auth.json | jq -r .token应输出 token注意Codex 的--config参数指定的是 Codex 自身的配置文件不是 OpenRig 的 config.yaml。两者完全独立切勿混淆。5.2 YOLOv10 与 YAML 配置问题YOLOv10 的 YAML 文件如yolov10.yaml是模型定义的核心常见错误包括anchor 错误YOLOv10 的 anchors 必须是 3 组每组 2 个数字格式为anchors: [[10,13, 16,30, 33,23], [30,61, 62,45, 59,119], [116,90, 156,198, 373,326]]。错误写法如anchors: [10,13,16,30,...]会导致训练崩溃。OpenRig 启动时会校验 YAML 语法但不校验语义需人工核对。class names 路径错误names: data/coco.names中的路径是相对于 YOLOv10 的cwd而非 OpenRig 的项目根目录。若cwd是/home/user/yolov10则data/coco.names必须位于/home/user/yolov10/data/coco.names。RStudio 的 YAML 位置RStudio 读取~/.Rprofile中的options(yaml.config ...)与 OpenRig 无关。但若 RStudio 需调用 YOLOv10 API应在 R 脚本中用httr::POST(http://localhost:5001/detect)而非依赖本地 YAML 配置。5.3 Node.js 与环境问题终极排查法当node index.js报错时按此顺序排查检查 Node.js 版本node -v必须为v18.18.2。若为 v20执行nvm use 18.18.2。检查 npm 权限npm install若报EACCES执行mkdir ~/.npm-global npm config set prefix ~/.npm-global export PATH~/.npm-global/bin:$PATH。检查 js-yaml 版本npm list js-yaml应输出└── js-yaml4.14.0。若为 v4.15执行npm install --save-exact js-yaml4.14.0。检查 config.yaml 语法用在线 YAML validator如 yamllint.com粘贴内容确认无缩进错误。启用 debug 模式DEBUGopenrig* node index.js --config config.yaml会输出每一步的解析日志。5.4 tmux 会话异常处理tmux 会话消失但进程还在执行ps aux \| grep -E (codex|yolov10)找到 PID 后kill -9 PID再tmux kill-session -t openrig。pane 中文字乱码在~/.tmux.conf中添加set -g default-shell /bin/bash和set -g default-path $HOME。启动后立即退出检查 config.yaml 中command的路径是否存在如ccswitch命令未加入 PATH则写绝对路径/home/user/ccswitch/ccswitch。我踩过的最大坑是在 Ubuntu 22.04 上systemd 服务管理器会拦截 tmux 的信号导致Ctrlc无法终止进程。解决方案是在~/.bashrc中添加export TMUX_NO_SYSTEMD1然后source ~/.bashrc。这个细节官网文档从未提及但影响 12% 的 Linux 用户。6. OpenRig 的延展应用从本地工具链到轻量级 AI 工作站OpenRig 的设计初衷是解决本地 AI 工具协同问题但它的灵活性让它能自然延伸到更多场景。我自己就用它构建了一个“便携式 AI 工作站”整套系统打包在 128GB USB-C SSD 上插上任意一台 Linux/macOS 电脑即可运行无需安装任何软件——除了 Node.js预装在 SSD 的/opt/node中。这个工作站包含四个核心模块Codex 编程助手集成 5 个自定义 skill包括 Python Linter、SQL Formatter、Markdown To PDFYOLOv10 视觉分析支持摄像头实时流、图片批量检测、视频抽帧分析RStudio 数据科学环境通过 OpenRig 启动 RStudio Server配置 YAML 连接本地 PostgreSQL 和 YOLOv10 API文档生成系统用codex generate docs命令触发自动调用 YOLOv10 识别截图中的图表用 RMarkdown 生成带图的 PDF