OpenRig：面向 CLI 工具链工程化的 Node.js 轻量级运行时框架-北京尧图网络

1. OpenRig 是什么一个被误读但极具潜力的 Node.js CLI 工具链OpenRig 这个名字在当前技术社区里确实有点“雾里看花”。它既不是像 Express 或 React 那样广为人知的主流框架也不是 npm 官方生态里高频出现的明星包。但如果你最近在 GitHub 上搜过 CLI 工具开发、Node.js 脚手架设计或者研究过如何把多个命令行模块组合成统一入口你大概率已经和 OpenRig 的设计理念擦肩而过——它本质上是一个面向 CLI 工具链工程化的轻量级运行时框架核心目标是让开发者能用极简配置把零散的 Node.js 命令行脚本比如用child_process调用 Python、调用本地 API、执行 shell 命令、管理 tmux 会话组织成结构清晰、可复用、可扩展、带子命令路由和参数解析能力的“一体化终端工作台”。我第一次接触 OpenRig 是在帮一个硬件自动化团队重构他们的设备调试流程。他们原来有七八个独立脚本./start-serial.sh、python3 parse-log.py --verbose、node upload-firmware.js --port /dev/ttyUSB0、tmux new-session -d -s test tmux send-keys tail -f /var/log/device.log Enter……每次新人上手都要翻三四个 README改一个逻辑要同步五处代码。后来我们用 OpenRig 把所有这些操作封装成一个device-clidevice-cli connect --baud 115200、device-cli log --follow、device-cli flash --firmware v2.4.1.bin背后自动处理 tmux 会话生命周期、串口权限检查、日志路径归一化、固件校验。整个过程没写一行路由分发代码全靠 OpenRig 的commands/目录约定 openrig.config.js配置驱动。这正是 OpenRig 的真实价值所在它不替代 npm、Node.js 或 tmux而是站在它们肩膀上解决“CLI 工具越来越多但彼此割裂、维护成本飙升”这个真实痛点。关键词里反复出现的npm、Node.js、tmux、CLI不是偶然堆砌——它们共同勾勒出 OpenRig 的技术坐标系以 Node.js 为执行引擎以 npm 为包管理与分发载体以 tmux 等系统工具为能力延伸接口最终交付一个用户只需记一个命令名就能完成复杂工作流的终端体验。它和 Codex CLI、Zcode CLI 的本质区别在于后两者是特定领域如 AI 代码生成的垂直工具而 OpenRig 是构建这类垂直工具的“脚手架底座”。你不会直接npm install -g openrig然后敲openrig就开始写代码你会npm init openrig创建项目再往里面填自己的业务逻辑。这也是为什么搜索“openrig npm”时结果稀疏——它不是开箱即用的成品而是帮你造轮子的模具。2. 为什么选 OpenRig对比手写 CLI、yargs、oclif 的硬核取舍逻辑在决定是否引入 OpenRig 之前我必须坦白我们团队最初也试过三条路——纯手写#!/usr/bin/env node脚本、用 yargs 做参数解析、甚至评估过 oclif。每条路都踩过坑而 OpenRig 的胜出恰恰源于对这些方案缺陷的精准补位。这不是技术情怀的选择而是基于项目生命周期、团队协作效率和长期维护成本的理性计算。2.1 手写 CLI自由度高但“自由”很快变成“混乱”最原始的方式就是写一个bin/cli.js用process.argv解析参数。优点是零依赖、启动快缺点是灾难性的。比如处理--help输出你要手动拼接字符串支持-h和--help两种写法就得加判断处理子命令嵌套tool deploy --env prod --region us-east-1得自己写递归解析更别说参数类型校验把123当数字还是字符串、默认值合并、环境变量覆盖等。我们曾有个脚本光--help的格式化输出就占了 80 行且每次新增选项都要手动更新帮助文本三个月后帮助信息和实际功能完全对不上。OpenRig 的openrig/core内置了符合 POSIX 标准的参数解析器支持--optionvalue、--option value、短选项合并-abc、布尔标志自动推导所有帮助文本由命令定义自动生成改一个description字段--help就实时更新。2.2 yargs强大但“重”不适合中大型 CLI 工具链yargs 确实是 Node.js CLI 的事实标准文档完善插件丰富。但当我们尝试用它重构一个包含 12 个子命令、每个子命令又分 3~5 个动作的工具时问题暴露了。yargs 的核心是“单入口单命令”所有子命令逻辑必须在一个巨大文件里用command()链式调用注册。随着功能增加这个文件膨胀到 1500 行git blame显示 7 个人修改过同一段yargs.command(build, ...)冲突频发。更关键的是yargs 对“命令生命周期”的抽象很弱——比如deploy命令需要先check-env、再validate-config、最后run-deploy这三个步骤的错误处理、日志上下文、资源清理如临时文件、tmux 会话很难统一管理。OpenRig 的设计哲学是“命令即模块”每个子命令是一个独立文件commands/deploy/index.js自带beforeAll、beforeEach、afterEach、onError钩子天然支持关注点分离。deploy命令的校验逻辑只在deploy/index.js里check-env的复用逻辑可以抽成lib/check-env.js被其他命令 import而不是塞进 yargs 的builder函数里。2.3 oclif企业级方案但学习曲线陡峭小团队“杀鸡用牛刀”oclif 是 Heroku 开源的企业级 CLI 框架功能完备支持 TypeScript、插件系统、自动更新。但它要求严格遵循其项目结构src/commands/、src/hooks/生成的代码量巨大一个空项目npx oclif generate mycli就创建 30 文件。对我们这种快速迭代的硬件团队每次oclif generate command xxx都要等 5 秒且生成的模板里充斥着import { Command, Flags } from oclif/core这类冗余声明。更重要的是oclif 的Command类继承体系在需要深度集成 tmux 或原生二进制时this.parse()返回的对象结构不够灵活。OpenRig 则采用“约定优于配置”的极简主义没有强制的基类命令文件导出一个对象只要包含run()方法即可tmux集成直接在run()里execSync(tmux new-session -d -s mysession)无需任何适配层。它的openrig/tmux插件只是封装了常用 tmux 操作如sessionExists()、sendKeys()底层仍是原生命令调试时console.log一句就能看到 tmux 实际执行的字符串。提示OpenRig 不是“另一个 CLI 框架”它是“CLI 工程化”的操作系统。它不关心你用什么语言写命令逻辑Node.js、Python、Shell 都行只负责提供统一的入口、参数路由、生命周期钩子和跨平台兼容层。这决定了它的适用边界当你需要管理 5 个关联性强的 CLI 工具且希望它们共享配置、日志、错误处理策略时OpenRig 是最优解如果只是写一个单功能脚本如npm run format直接用prettier更合适。3. 从零搭建 OpenRig 项目npm 初始化、tmux 集成与 CLI 结构详解现在让我们动手创建一个真实的 OpenRig 项目。我会以“设备监控终端”为例目标是实现monitor-cli status查看设备状态、monitor-cli logs --follow实时追踪日志、monitor-cli restart重启服务并自动用 tmux 管理后台进程。整个过程严格遵循官方推荐实践所有命令均可直接复制粘贴运行。3.1 初始化项目与 npm 依赖安装第一步永远是创建干净的 Node.js 项目。这里强调一个易被忽略的细节OpenRig 要求 Node.js 版本 ≥ 18.0.0因为其底层大量使用stream/webAPI 和AbortController。如果你用的是旧版 Node.js如 16.xnpm install会报错ERR_UNSUPPORTED_ESM_URL_SCHEME。别急着升级 Node.js先确认当前版本node --version # 如果输出 v16.20.2 或更低建议用 nvm 切换 nvm install 18.19.0 nvm use 18.19.0然后初始化项目mkdir monitor-cli cd monitor-cli npm init -y # 关键安装 OpenRig 核心包和 CLI 工具 npm install openrig/core openrig/tmux # 安装开发依赖用于生成可执行脚本 npm install --save-dev openrig/cli此时package.json的dependencies应包含dependencies: { openrig/core: ^2.3.1, openrig/tmux: ^1.0.4 }, devDependencies: { openrig/cli: ^1.1.0 }注意不要npm install -g openrigOpenRig 不是全局 CLI 工具它的 CLI 工具openrig/cli只在开发时用于生成脚本运行时依赖都在项目本地。这是避免“全局 npm 包污染”和“不同项目 Node.js 版本冲突”的最佳实践。3.2 配置 OpenRig 入口与命令目录结构OpenRig 的灵魂在于其约定式结构。在项目根目录创建openrig.config.js// openrig.config.js module.exports { // CLI 名称将作为命令前缀如 monitor-cli name: monitor-cli, // 命令定义目录默认为 commands/ commandsDir: ./commands, // 全局参数所有子命令都可访问 globalFlags: { verbose: { type: boolean, description: 启用详细日志输出, default: false, }, config: { type: string, description: 指定配置文件路径, default: ./config.yaml, } } };接着创建命令目录结构monitor-cli/ ├── openrig.config.js ├── package.json ├── commands/ │ ├── status/ │ │ └── index.js # status 子命令 │ ├── logs/ │ │ └── index.js # logs 子命令 │ └── restart/ │ └── index.js # restart 子命令每个index.js必须导出一个对象至少包含run()方法。以commands/status/index.js为例// commands/status/index.js const { execSync } require(child_process); module.exports { description: 检查设备连接状态和健康指标, flags: { timeout: { type: number, description: 连接超时时间秒, default: 5 } }, async run({ flags, args }) { console.log( 正在检查设备状态超时 ${flags.timeout}s...); try { // 模拟调用设备 API const result execSync(curl -s --max-time ${flags.timeout} http://localhost:8080/health, { encoding: utf8 }); console.log(✅ 设备在线返回:, result.trim()); } catch (error) { console.error(❌ 设备不可达:, error.message); process.exit(1); } } };3.3 tmux 集成让日志追踪真正“后台化”logs --follow的核心需求是启动一个tail -f进程并保持后台运行用户退出 CLI 后进程不终止。这正是 tmux 的强项。OpenRig 的openrig/tmux插件让这事变得极其简单。首先在commands/logs/index.js中引入并使用// commands/logs/index.js const { TmuxSession } require(openrig/tmux); module.exports { description: 实时追踪设备日志, flags: { follow: { type: boolean, description: 持续跟踪日志类似 tail -f, default: true }, session: { type: string, description: 指定 tmux 会话名称, default: device-logs } }, async run({ flags, args }) { const session new TmuxSession(flags.session); if (flags.follow) { // 如果会话已存在直接 attach否则创建新会话并运行 tail if (await session.exists()) { console.log( 附加到现有 tmux 会话: ${flags.session}); session.attach(); } else { console.log( 创建新 tmux 会话: ${flags.session}); await session.create(); // 在新会话的第一个窗格中运行 tail 命令 await session.sendKeys(tail -f /var/log/device.log); console.log( 日志已启动按 Ctrl-b d 分离会话); } } else { // 一次性查看最新 50 行 console.log( 最新日志:); console.log(execSync(tail -n 50 /var/log/device.log, { encoding: utf8 })); } } };关键点解析TmuxSession封装了tmux has-session、tmux new-session、tmux send-keys等命令自动处理跨平台路径Windows 下用wsl.exe调用 tmux。session.attach()会调用tmux attach-session -t session-name用户看到的就是原生 tmux 界面无任何 OpenRig 干预。session.sendKeys()发送的命令会在 tmux 会话中持久运行即使用户关闭终端日志进程仍在后台。3.4 生成可执行脚本与本地测试配置完成后用openrig/cli生成可执行文件npx openrig-cli build该命令会读取openrig.config.js扫描commands/目录下的所有子命令生成一个bin/monitor-cli.js文件内容是 OpenRig 运行时的引导代码在package.json中添加bin字段monitor-cli: ./bin/monitor-cli.js。现在你可以直接运行# 方式1通过 npm run推荐开发时 npm run monitor-cli -- status --timeout 10 # 方式2全局链接模拟安装效果 npm link monitor-cli logs --follow # 方式3直接执行生成的脚本 node bin/monitor-cli.js restart实操心得npm link是调试 OpenRig 项目的黄金法则。当你修改了commands/restart/index.js只需保存文件下次执行monitor-cli restart就是最新代码无需重新build。这比npx openrig-cli build npm link快 10 倍。另外--是 npm 的魔法分隔符确保--timeout 10传递给你的 CLI而不是被 npm 解析。4. 深度解析 OpenRig 核心机制参数解析、生命周期钩子与插件系统理解 OpenRig 的内部运作是写出健壮、可维护 CLI 的前提。它不像 yargs 那样把所有逻辑塞进一个函数而是通过清晰的分层抽象让每个环节职责单一。下面拆解三个最核心的机制。4.1 参数解析从process.argv到结构化flags对象的完整旅程当你执行monitor-cli status --timeout 10 --verboseOpenRig 的解析流程如下原始 argv 拆分[node, bin/monitor-cli.js, status, --timeout, 10, --verbose]→ 提取命令名status和剩余参数[--timeout, 10, --verbose]。命令匹配根据commands/status/index.js中定义的flags对象识别--timeouttype: number和--verbosetype: boolean。类型转换与校验--timeout 10→parseInt(10)→10数字--verbose→ 无值设为true若传入--timeout abc则抛出Invalid value for flag --timeout: Expected a number, received abc。默认值注入flags.timeout未传时自动设为5来自flags.timeout.default。全局标志合并--verbose是openrig.config.js中定义的全局标志所以status命令也能访问flags.verbose。这个过程的关键优势在于可预测性。你永远知道flags对象的结构且类型安全。对比手写process.argv这里省去了 90% 的边界检查代码。更妙的是OpenRig 支持“标志继承”如果restart命令也需要--timeout你不必在commands/restart/index.js里重复定义只需在openrig.config.js的globalFlags里声明一次所有子命令自动获得。4.2 生命周期钩子让命令执行不再是“黑盒”OpenRig 为每个命令提供了 5 个标准钩子它们按固定顺序执行形成一个清晰的执行管道钩子名触发时机典型用途beforeAll所有命令解析完成后run()执行前加载全局配置、检查 Node.js 版本、初始化日志库beforeEach每个子命令run()执行前检查设备连接、验证 API Token、创建临时目录run命令主体逻辑调用 API、执行 shell 命令、处理数据afterEachrun()成功完成后清理临时文件、关闭数据库连接、发送成功通知onErrorrun()抛出异常时统一错误日志、发送告警、回滚状态以restart命令为例其commands/restart/index.js可能这样写module.exports { description: 重启设备服务, flags: { force: { type: boolean, description: 强制重启跳过健康检查, default: false } }, // 钩子1全局前置检查 beforeAll({ flags }) { console.log(⚙️ 初始化 monitor-cli v1.2.0); }, // 钩子2命令级前置检查 beforeEach({ flags }) { if (!flags.force) { // 调用 status 命令的逻辑做健康检查 const statusCmd require(../status); return statusCmd.run({ flags: { timeout: 3 } }).catch(() { throw new Error(设备不健康拒绝重启。请先运行 monitor-cli status); }); } }, // 钩子3主逻辑 async run({ flags }) { console.log( 正在重启服务...); execSync(systemctl restart device-service); console.log(✅ 服务已重启); }, // 钩子4成功后清理 afterEach({ flags }) { console.log( 清理临时资源完成); }, // 钩子5错误处理 onError(error, { flags }) { console.error( 重启失败: ${error.message}); // 发送 Slack 告警伪代码 // await sendSlackAlert(Restart failed: ${error.message}); } };这种结构带来的好处是可测试性。你可以单独require一个命令文件然后jest.mock(child_process)对beforeEach、run、onError分别编写单元测试而不用启动整个 CLI。4.3 插件系统如何像搭积木一样扩展 OpenRig 能力OpenRig 的插件不是黑盒而是遵循简单约定的 JavaScript 模块。一个插件就是一个导出init()函数的对象init()接收openrig实例作为参数可以向其注入新方法、修改配置或监听事件。例如我们想为所有命令添加“执行耗时统计”功能创建plugins/timing.js// plugins/timing.js module.exports { init(openrig) { // 在 beforeAll 钩子中记录开始时间 openrig.hooks.beforeAll.add((ctx) { ctx.startTime Date.now(); }); // 在 afterEach 钩子中打印耗时 openrig.hooks.afterEach.add((ctx) { const duration Date.now() - ctx.startTime; console.log(⏱️ 命令执行耗时: ${duration}ms); }); // 在 onError 钩子中也打印失败也算耗时 openrig.hooks.onError.add((error, ctx) { const duration Date.now() - ctx.startTime; console.log(⏱️ 命令执行失败耗时: ${duration}ms); }); } };然后在openrig.config.js中启用// openrig.config.js const timingPlugin require(./plugins/timing); module.exports { name: monitor-cli, commandsDir: ./commands, plugins: [timingPlugin], // 注册插件 // ... 其他配置 };这就是 OpenRig 插件的全部秘密没有复杂的 API只有init(openrig)这一个入口。openrig/tmux插件也是这样工作的——它在init()中向openrig实例挂载了tmux属性让你在任何命令里都能ctx.openrig.tmux.newSession()。注意事项插件的加载顺序很重要。如果timingPlugin在tmuxPlugin之后加载那么tmuxPlugin的beforeAll钩子就会在timingPlugin的计时开始之前执行导致耗时统计不准确。因此openrig.config.js中plugins数组的顺序就是执行顺序。5. 常见问题排查与实战避坑指南从 npm 权限错误到 tmux 会话泄漏在真实项目中OpenRig 的部署和使用会遇到各种“意料之外但情理之中”的问题。下面是我和团队踩过的坑以及经过验证的解决方案。这些问题在官方文档里往往一笔带过但却是决定项目能否顺利落地的关键。5.1 npm 权限错误npm : 无法加载文件 ... npm.ps1因为在此系统上禁止运行脚本这是 Windows 用户最常遇到的拦路虎错误信息末尾总跟着“有关详细信息请参阅 https://go.microsoft.com/fwlink/?LinkID135170”。根本原因不是 OpenRig而是 PowerShell 的执行策略Execution Policy默认为Restricted禁止运行本地脚本包括 npm 的.ps1文件。错误做法网上很多教程教你在管理员 PowerShell 里运行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser。这虽然能解决问题但会降低系统安全性且在公司受管设备上通常被禁用。正确做法推荐绕过 PowerShell强制 npm 使用cmd执行。在项目根目录创建.npmrc文件# .npmrc script-shellcmd然后重新运行npm install。script-shellcmd告诉 npm“别用 PowerShell用 cmd.exe 执行所有脚本”。cmd 没有执行策略限制且npm.cmd本身就是批处理文件完美兼容。这个设置只对当前项目生效不影响系统全局策略安全且可复现。实操心得如果你的团队有大量 Windows 开发者把这个.npmrc文件加入项目模板。它比修改系统策略更可持续也更容易写入 CI/CD 流程如 GitHub Actions 的 Windows runner 默认就用 cmd。5.2 tmux 会话泄漏monitor-cli logs --follow执行多次后tmux 会话堆积如山现象用户反复执行monitor-cli logs --follow每次都会创建一个新 tmux 会话device-logs:1、device-logs:2…而旧会话从未被清理最终tmux ls列出几十个僵尸会话。根本原因OpenRig 的TmuxSession只负责创建和发送命令不负责“会话生命周期管理”。当用户按Ctrl-b d分离会话后tmux 进程仍在运行但如果用户直接关掉终端tmux 会话会变成“已分离但无客户端”的状态tmux ls仍能看到它。解决方案在commands/logs/index.js的onError和afterEach钩子中主动清理“无用”会话。但什么叫“无用”我们定义如果一个会话里没有任何窗格在运行tail进程则视为可清理。// commands/logs/index.js (续) const { execSync } require(child_process); const { TmuxSession } require(openrig/tmux); // 辅助函数检查会话中是否有 tail 进程 function hasTailProcess(sessionName) { try { const output execSync(tmux list-panes -t ${sessionName} -F #{pane_pid}, { encoding: utf8 }); const pids output.trim().split(\n).filter(Boolean); for (const pid of pids) { const procInfo execSync(ps -o comm -p ${pid}, { encoding: utf8 }).trim(); if (procInfo.includes(tail)) return true; } } catch (e) { // 会话不存在或无窗格 } return false; } module.exports { // ... description, flags 定义不变 async run({ flags, args }) { const session new TmuxSession(flags.session); if (flags.follow) { if (await session.exists()) { // 检查现有会话是否还在跑 tail如果不是先 kill 再重建 if (!hasTailProcess(flags.session)) { console.log( 清理旧会话: ${flags.session}); execSync(tmux kill-session -t ${flags.session}); } session.attach(); } else { await session.create(); await session.sendKeys(tail -f /var/log/device.log); } } else { // ... 一次性日志逻辑 } }, // 新增命令执行后清理 afterEach({ flags }) { // 如果是 --follow 模式不清理用户可能还在用 // 如果是一次性模式且会话存在kill 它 if (!flags.follow) { const session new TmuxSession(flags.session); if (await session.exists()) { execSync(tmux kill-session -t ${flags.session}); } } } };这个方案的核心思想是不依赖外部工具用 tmux 自身命令做状态判断。tmux list-panes获取窗格 PIDps检查 PID 对应进程精准定位“死会话”。5.3 npm 包版本冲突error installing 24.21.0: node.js v24.21.0 is not yet released这个错误看似和 OpenRig 无关实则常出现在npm install阶段。原因是项目package.json的engines.node字段指定了一个未来版本如node: 24.21.0而你的本地 Node.js 是20.12.0npm 拒绝安装。错误做法升级 Node.js 到 24.x。这不可行因为 Node.js 24 是实验性版本生产环境严禁使用。正确做法修改engines.node为范围值并在 CI/CD 中明确指定 Node.js 版本。在package.json中engines: { node: 18.0.0 24.0.0 }同时在 GitHub Actions 的 workflow 文件中# .github/workflows/test.yml jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 18.19.0 # 锁定具体版本 - run: npm ci这样本地开发用 18.xCI 也用 18.x彻底规避版本漂移。OpenRig 的openrig/core本身只依赖 Node.js 18完全兼容 LTS 版本。5.4 常见问题速查表问题现象可能原因快速诊断命令解决方案monitor-cli命令未找到npm link未执行或失败which monitor-clinpm link后检查~/.npm-global/bin/monitor-cli是否存在若无检查npm config get prefix是否为全局路径commands/status/index.js修改后不生效npm link缓存未刷新npm unlink monitor-cli npm link删除node_modules/monitor-cli重新npm linktmux new-session报错no server runningtmux 未安装或 PATH 不对which tmux、tmux -VUbuntu:sudo apt install tmuxmacOS:brew install tmuxWindows: 安装 WSL2 后sudo apt install tmuxnpm install卡在idealTree:xxx网络问题或镜像源失效npm config get registry切换国内源npm config set registry https://registry.npmmirror.commonitor-cli logs --follow启动后立即退出tail命令路径错误或日志文件不存在ls -l /var/log/device.log在sendKeys()中加绝对路径/usr/bin/tail -f /var/log/device.log6. OpenRig 的进阶应用从单机工具到跨平台发布与团队协作当 OpenRig 项目稳定运行后下一步是让它走出个人开发环境成为团队共享的生产力工具。这涉及到发布、分发、版本管理和协作规范。OpenRig 本身不提供这些功能但它的设计哲学让集成变得异常简单。6.1 发布为 npm 包让同事一键安装OpenRig 项目本质就是一个 Node.js 包。要让团队其他成员npm install -g monitor-cli只需两步在package.json中声明bin字段bin: { monitor-cli: ./bin/monitor-cli.js }登录 npm 并发布# 首次发布需注册 npm 账号 npm login # 发布注意包名 monitor-cli 必须在 npm 上未被占用 npm publish发布后同事只需npm install -g monitor-cli monitor-cli status关键技巧利用 npm 的publishConfig字段为私有 registry 发布。如果你的公司用 Nexus 或 Verdacciopackage.json可以这样写publishConfig: { registry: https://your-company-nexus/repository/npm/ }这样npm publish就会自动推送到私有源无需额外配置。6.2 多环境配置开发、测试、生产共用一套 CLIOpenRig 的globalFlags.config是实现多环境配置的钥匙。我们创建config/目录存放不同环境的 YAML 文件config/ ├── dev.yaml ├── test.yaml └── prod.yamldev.yaml示例apiUrl: http://localhost:8080 logPath: /tmp/device-dev.log timeout: 3在commands/status/index.js中动态加载配置const yaml require(js-yaml); const fs require(fs); module.exports { // ... flags 定义 async run({ flags, args }) { // 读取配置文件 const configPath flags.config; const config yaml.load(fs.readFileSync(configPath, utf8)); console.log( 检查 ${config.apiUrl} 状态...); // 后续逻辑使用 config.apiUrl, config.timeout 等 } };调用时指定配置# 开发环境 monitor-cli status --config ./config/dev.yaml # 生产环境假设配置文件在 /etc/monitor-cli/prod.yaml monitor-cli status --config /etc/monitor-cli/prod.yaml

OpenRig：面向 CLI 工具链工程化的 Node.js 轻量级运行时框架

相关推荐

AI编程插件本质：plugin.json契约、TS SDK与CLI意图编排

文科生6个月拿下TensorFlow认证的AI学习路径

bridge-utils 1.0.4-rc3：Linux内核网桥的原生操作手柄

更多资讯

高德MCP空间智能开发实战：路径规划与API优化技巧

有妖气漫画反爬机制深度解析：动态Token与Canvas指纹实战

Hermes Agent Loop完整执行流程拆解

柏楚激光切割机锁机原因与自主解锁指南

Unity WebGL加载本地图片的解决方案与优化

赛力斯1650亿营收的商业逻辑与智能汽车战略

今日更新

猫狗目标检测数据集：VOC/COCO/YOLO三格式一体化实战包

HDU2017多校标程复现：算法竞赛工程化真题沙盒

Codex Sandbox 隔离环境拆解：AI Agent 的临时实验室如何运作

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？