1. 从零认识 openrig它到底解决什么问题第一次看到 openrig 这个名字很多人会以为是某个硬件支架项目毕竟 rig 在英文里有“装配、支架”的意思。但如果你最近在折腾 Claude Code、Codex 这类终端 AI 编程助手就会明白它出现的语境——这是一套围绕终端 AI 编码工具做统一编排、会话管理和多模型接入的开源方案。简单说openrig 想干的事情是把你散落在 tmux 会话、多个 CLI 工具、多个模型供应商之间的工作流收拢成一套可复用、可切换、可观测的“装备架”。我自己是从 Claude Code 开始入坑的。最开始只是想在终端里让 AI 帮我改改脚本、写写测试结果越用越深问题也跟着来了Claude Code 一套配置Codex 一套配置本地还跑着 LM Studio 的模型偶尔又想切到 DeepSeek 或者 GLM 试试性价比。每个工具都有自己的登录态、自己的配置文件、自己的会话历史切来切去特别容易乱。更麻烦的是这些 CLI 工具大多默认独占一个终端你想同时开两个任务就得开两个窗口时间一长 tmux 里全是会话自己都记不清哪个是哪个。openrig 的核心价值就在这里。它不是要替代 Claude Code 或者 Codex而是站在它们之上做一层“编排层”。你可以把它理解成一个终端 AI 工具的调度台统一管理会话、统一处理模型切换、统一记录上下文让 Claude Code、Codex 这些工具在一个可控的框架里跑起来。对于每天要在终端里和 AI 打交道的人来说这套东西能省下大量重复配置和上下文切换的时间。适合读这篇内容的人大概有三类。第一类是刚接触 Claude Code 或 Codex 的新手还在纠结 Node.js 怎么装、环境怎么配、登录为什么老失败第二类是已经用了一段时间但被多工具、多模型、多会话搞得有点烦的中级用户第三类是想把终端 AI 工作流沉淀成团队规范的人需要一套可复制、可维护的方案。不管你在哪一类openrig 背后的思路都值得了解一下因为它代表了一种趋势终端 AI 工具正在从“单点工具”走向“工作流基础设施”。需要提前说明的是openrig 本身还在演进中社区里关于它的讨论也夹杂着大量 Claude Code、Codex 的安装和使用问题。所以这篇内容不会只讲 openrig 本身而是把它放回真实的终端 AI 工作流里把相关的 Node.js 环境、tmux 会话管理、模型接入这些环节一起讲清楚。毕竟脱离这些上下文单讲一个编排工具是讲不透的。2. 核心思路拆解为什么要在终端 AI 工具之上再加一层2.1 终端 AI 工具的“孤岛问题”到底出在哪Claude Code 和 Codex 这类工具的设计哲学其实很相似它们都是命令行程序通过标准输入输出和你交互背后调用大模型 API 来完成代码理解、生成、修改等任务。这种设计的好处是轻量、可组合、不依赖图形界面特别适合在服务器或者远程开发环境里用。但问题也恰恰出在这里——每个工具都是一个独立的进程有自己的配置目录、自己的认证方式、自己的会话状态。我举个实际例子。Claude Code 的配置通常放在用户目录下的隐藏文件夹里Codex 也有自己的配置路径。你如果同时用这两个工具就得分别登录、分别设置模型、分别管理历史记录。更麻烦的是当你想要切换模型供应商时比如从官方 API 切到本地 LM Studio或者切到 DeepSeek、GLM 这类第三方接口每个工具的切换方式还不一样。有的改环境变量有的改配置文件有的得重新登录。次数多了你就会开始怀疑人生我只是想换个模型为什么要折腾这么久tmux 在这里扮演了一个有意思的角色。很多人用 tmux 来管理终端会话因为它可以让你在一个 SSH 连接里开多个窗口、多个面板断开后还能恢复。于是自然而然地大家会把 Claude Code 跑在一个 tmux 窗口里Codex 跑在另一个窗口里本地模型服务再开一个窗口。这确实解决了“同时跑多个工具”的问题但没有解决“统一管理”的问题。你的 tmux 会话列表越来越长每个会话里跑着什么、用的哪个模型、上下文到哪了全靠脑子记。openrig 要解决的就是这个“孤岛问题”。它的思路不是把 Claude Code 和 Codex 合并成一个工具而是在它们之上抽象出一层统一的会话管理和模型路由层。你可以把它想象成一个“终端 AI 工具的机架”每个工具还是原来的工具但它们的启动、配置、会话状态都由 openrig 来统一编排。2.2 编排层的三个核心能力会话、模型、上下文openrig 这类编排工具的核心能力我总结下来主要是三块会话管理、模型路由、上下文衔接。会话管理解决的是“我在哪、我在干什么”的问题。传统的做法是你手动开 tmux 窗口手动启动工具手动记录这个窗口是干嘛的。openrig 的做法是让你用统一的命令来创建、切换、恢复会话每个会话有明确的标识和元数据。比如你可以创建一个叫“重构用户模块”的会话指定用 Claude Code 跑模型用某个特定版本再创建一个叫“写单元测试”的会话指定用 Codex 跑模型切到本地。切换的时候不用去翻 tmux 窗口列表直接按会话名切过去就行。模型路由解决的是“用哪个模型”的问题。终端 AI 工具通常支持多种模型接入方式但配置起来比较分散。openrig 把模型配置集中管理你可以在一个地方定义好所有可用的模型端点包括官方 API、第三方兼容接口、本地 LM Studio 服务等然后在创建会话时直接指定用哪个。切换模型不需要改工具本身的配置只需要在 openrig 层面切换路由就行。这对于需要频繁对比不同模型效果的场景特别有用。上下文衔接解决的是“之前聊到哪了”的问题。终端 AI 工具的会话历史通常存在本地但格式和位置各不相同。openrig 可以在一定程度上统一上下文的读取和注入让你在切换工具或模型时不至于完全丢失之前的对话脉络。当然这块能力受限于各个工具本身的开放程度不可能做到完美但至少能减少重复描述背景的麻烦。2.3 为什么选择 tmux 作为底层支撑openrig 选择 tmux 作为底层会话支撑这个决策我觉得很务实。tmux 几乎是所有终端重度用户的标配稳定、成熟、跨平台而且它的会话模型天然适合做“持久化工作区”。你可以在 tmux 里创建会话、窗口、面板每个面板跑一个进程断开 SSH 后进程继续运行下次连上来还能恢复。用 tmux 做底层还有一个好处它和终端 AI 工具的交互模式很契合。Claude Code 和 Codex 都是长时间运行的交互式进程需要持续的终端会话。如果你直接用 nohup 或者后台任务来跑交互体验会很差。tmux 提供了一个“可附加的终端”你可以随时 attach 上去看进度、发指令也可以 detach 下来去干别的。openrig 把这套机制封装起来让你不用手动敲 tmux 命令但底层还是 tmux 在干活。这里有个细节值得注意tmux 的会话和窗口管理是有学习成本的。新手经常搞混 session、window、pane 这三个概念。简单类比一下session 就像一栋楼window 就像楼里的房间pane 就像房间里的隔断。你可以在一栋楼里开多个房间在一个房间里打多个隔断。openrig 的价值之一就是把这套概念包装成更直观的“工作区”和“任务”降低使用门槛。2.4 和直接使用 Claude Code、Codex 的对比很多人会问我直接用 Claude Code 不也挺好吗为什么要多一层这个问题很合理。如果你只是偶尔用一下任务单一模型固定那确实没必要上编排层。但如果你符合下面几种情况编排层的价值就会显现出来。第一种情况是多模型对比。你想知道同一个任务Claude 和 GPT 系列哪个写得更好或者官方 API 和本地模型哪个更划算。没有编排层的时候你得手动改配置、重启工具、重新描述任务。有编排层的时候你可以在同一个会话框架下快速切换模型任务描述和上下文还能保留。第二种情况是多任务并行。你同时在做几个不同的任务每个任务需要不同的工具和模型。没有编排层的时候你的 tmux 里会堆满窗口时间一长就乱了。有编排层的时候每个任务是一个独立的会话有名字、有状态、有记录管理起来清晰很多。第三种情况是团队协作。你想把一套终端 AI 工作流分享给同事让他们也能快速上手。没有编排层的时候你得写一堆文档解释怎么装 Node.js、怎么配 Claude Code、怎么连本地模型。有编排层的时候你可以把配置模板化别人拉下来改改就能用。当然编排层也有代价。它增加了一层抽象意味着多了一个需要学习和维护的东西。openrig 本身还在发展中文档和社区支持可能不如 Claude Code 官方那么完善。所以我的建议是先把手头的工具用熟等到确实遇到多工具、多模型、多会话的管理痛点时再考虑引入编排层。3. 环境准备Node.js、tmux 和终端 AI 工具的安装要点3.1 Node.js 版本选择与安装避坑Claude Code 和 Codex 这类工具大多是基于 Node.js 开发的所以 Node.js 环境是第一步。这里最容易踩的坑就是版本问题。网上经常能看到类似“error installing 24.21.0: node.js v24.21.0 is not yet released”这样的报错原因通常是版本号写错了或者用了不存在的版本。Node.js 的版本号是有严格规范的偶数版本是 LTS长期支持版奇数版本是当前版不是随便编一个数字就能装的。我的建议是直接用 Node.js 20 或 22 的 LTS 版本。这两个版本目前生态兼容性最好Claude Code、Codex 以及大多数相关工具都测试过。安装方式有几种我按推荐程度排一下。第一种是用 NodeSource 的安装脚本适合 Ubuntu 和 Debian 系统。命令大概是先下载脚本然后指定版本执行。这种方式的好处是能精确控制版本而且后续可以用系统包管理器更新。第二种是用 nvmNode Version Manager适合需要频繁切换 Node.js 版本的场景。nvm 可以让你在同一台机器上装多个版本按项目切换。第三种是直接去 Node.js 官网下载二进制包解压后配置环境变量。这种方式最原始但可控性最强适合不想引入额外包管理器的场景。注意不管你用哪种方式装完之后一定要验证。运行node -v和npm -v确认版本号符合预期。如果提示命令找不到大概率是环境变量没配好检查 PATH 里有没有 Node.js 的 bin 目录。还有一个常见问题是权限。在 Linux 上直接用系统包管理器装 Node.js有时候会遇到全局包安装权限不足的问题。这时候要么用 sudo要么配置 npm 的全局目录到用户目录下。我个人的习惯是尽量不用 sudo 装全局 npm 包而是把 npm 的 prefix 配置到用户目录这样更干净也不容易污染系统环境。3.2 tmux 的安装与基础配置tmux 的安装相对简单Ubuntu 和 Debian 上直接apt install tmux就行macOS 上用 Homebrew 装。装完之后建议做一点基础配置不然默认的快捷键和状态栏用起来不太顺手。配置文件在用户目录下的.tmux.conf。我通常会改几个地方把前缀键从默认的 Ctrlb 改成 Ctrla因为 Ctrlb 在很多终端里是翻页键容易冲突开启鼠标支持方便用鼠标切换面板和调整大小设置状态栏显示当前会话名和窗口列表这样一眼就能看清自己在哪。这些配置网上有很多现成的模板不用自己从头写。对于 openrig 这类工具来说tmux 的会话命名很重要。默认情况下 tmux 会话名是数字时间一长根本分不清。建议在创建会话时就指定有意义的名字比如用项目名或者任务名。openrig 如果做了封装应该会自动处理这部分但了解底层机制有助于排查问题。提示如果你在 tmux 里跑 Claude Code 或 Codex遇到终端显示错乱的情况先检查 TERM 环境变量。有时候 tmux 的 TERM 设置和工具期望的不一致会导致颜色和光标异常。可以在 tmux 配置里显式设置set -g default-terminal screen-256color试试。3.3 Claude Code 与 Codex 的安装和登录Claude Code 和 Codex 的安装方式类似通常是通过 npm 全局安装或者下载官方提供的安装包。安装完成后第一次运行会引导你登录。登录方式一般有两种一种是浏览器授权终端里会显示一个链接你在浏览器里完成授权后回到终端另一种是输入 API Key适合无图形界面的服务器环境。这里有个高频问题登录不上或者提示“your organization has disabled claude subscription access”。这种情况通常和账号权限有关不是技术问题。如果你用的是团队账号可能需要管理员在后台开启相应权限。个人账号一般不会有这个问题。遇到登录问题时先确认网络能正常访问相关服务然后检查账号状态最后再看工具版本是不是太旧。Codex 这边有个常见报错是“codex is ignoring 1 unrecognized configuration setting”意思是配置文件里有它不认识的字段。这通常是因为你参考了旧版本的配置示例或者手动改配置时写错了键名。解决办法是检查配置文件把不认识的字段删掉或者对照官方文档确认正确的字段名。Codex 的配置格式在不同版本间可能有变化升级后最好重新检查一遍配置。还有一个问题是“codex无法加载组织设置”。这个和登录态有关可能是 token 过期了也可能是组织配置有变更。重新登录通常能解决。如果重新登录还不行检查一下是不是有多个配置文件冲突比如同时存在全局配置和项目级配置优先级搞错了。3.4 本地模型接入LM Studio 与第三方 API 的配置思路很多人用 Claude Code 或 Codex 的时候会想接入本地模型或者第三方 API原因无非是成本、隐私或者模型效果对比。LM Studio 是一个比较流行的本地模型运行工具它提供了一个兼容 OpenAI 接口的本地服务。Claude Code 和 Codex 如果支持自定义 API 端点就可以指向 LM Studio 的本地地址。配置的关键在于两点一是 API 端点地址二是模型名称。LM Studio 默认的本地服务地址通常是http://localhost:1234/v1模型名称就是你在 LM Studio 里加载的模型标识。在 Claude Code 或 Codex 的配置里把 API base URL 改成这个地址把 API Key 随便填一个非空值本地服务通常不校验然后指定模型名称就行。第三方 API 的配置类似比如 DeepSeek、GLM 这些它们大多提供兼容 OpenAI 格式的接口。你需要拿到 API Key确认接口地址然后在工具配置里填入。这里有个细节不同第三方接口对请求格式的支持程度不一样有的完全兼容有的部分兼容。如果遇到调用失败先看错误信息再对照接口文档检查请求格式。注意接入第三方 API 时注意不要在配置文件里明文写 API Key尤其是如果你打算把配置分享出去。可以用环境变量来传递 Key配置文件里只写变量名。这样既安全也方便在不同环境间切换。4. 实操过程用 openrig 组织一套终端 AI 工作流4.1 初始化 openrig 与目录结构规划假设你已经装好了 Node.js、tmux也装好了 Claude Code 和 Codex接下来就是引入 openrig。由于 openrig 本身还在演进具体的安装命令可能会变但整体流程是类似的先通过包管理器或者源码方式获取 openrig然后运行初始化命令生成默认配置。初始化之后你会得到一个配置目录里面通常包含几个部分全局配置、模型定义、会话模板、日志目录。我建议在初始化之后先别急着改配置而是先跑一遍默认流程看看它是怎么工作的。理解默认行为之后再按自己的需求调整。目录结构规划这块我的经验是尽量把配置和项目分离。全局配置放在用户目录下定义通用的模型端点和默认行为项目级配置放在项目目录里定义这个项目特有的会话模板和模型偏好。这样不同项目之间不会互相干扰也方便把项目配置纳入版本控制。4.2 定义模型端点官方、第三方、本地的统一管理openrig 的一个核心能力是统一管理模型端点。你可以在配置里定义多个模型每个模型有名称、类型、API 地址、认证方式等字段。比如定义一个“claude-official”指向官方 API定义一个“deepseek”指向第三方接口定义一个“local-lmstudio”指向本地服务。定义好之后创建会话时就可以按名称引用模型。这样做的好处是当你需要切换模型时不用去改 Claude Code 或 Codex 本身的配置只需要在 openrig 层面指定不同的模型名。对于需要频繁对比模型的场景这个能力非常实用。这里有个实操细节不同模型对上下文长度、并发请求、计费方式的支持不一样。建议在模型定义里加上备注字段记录这个模型的特点和限制。比如本地模型可能上下文短一些第三方 API 可能有速率限制。这些信息在切换模型时很有参考价值。4.3 创建和管理会话从 tmux 窗口到命名工作区openrig 的会话管理是建立在 tmux 之上的。当你创建一个会话时它实际上是在 tmux 里开了一个新的 session 或 window然后在里面启动指定的工具。你可以给会话起名字指定用哪个工具、哪个模型、哪个工作目录。我自己的习惯是按任务来命名会话比如“fix-auth-bug”“write-api-tests”“refactor-db-layer”。这样在会话列表里一眼就能看出每个会话在干什么。openrig 如果支持会话标签或者分组那就更好可以按项目或者优先级来组织。会话的恢复也很重要。tmux 本身支持 detach 和 attachopenrig 应该把这套机制封装得更友好。比如你可以列出所有活跃会话看到每个会话的状态然后选择 attach 到某个会话继续工作。对于长时间运行的任务这个能力很关键你不需要一直守着终端。4.4 在会话中调用 Claude Code 和 Codex 的实操记录实际在会话里用 Claude Code 或 Codex 的时候体验和直接跑差不多但因为有了 openrig 的封装启动参数和环境变量都由它来管理。你不需要记住每个工具的启动命令和配置路径只需要告诉 openrig 你要用哪个工具、哪个模型。我记录一个典型的操作流程。首先创建一个会话指定用 Claude Code模型用官方 API工作目录指向某个项目。openrig 会在 tmux 里开一个窗口启动 Claude Code并自动注入配置。然后我 attach 到这个会话开始和 Claude Code 交互让它帮我分析代码、生成修改建议。任务进行到一半我想换个模型试试于是 detach 出来用 openrig 的命令切换这个会话的模型再 attach 回去。Claude Code 可能需要重启才能生效但会话本身还在工作目录和上下文都保留着。Codex 的流程类似只是工具不同。Codex 在某些方面和 Claude Code 有差异比如它对配置文件格式的要求更严格对模型名称的匹配更敏感。用 openrig 管理的好处是这些差异被封装在工具适配层里你不需要在每个会话里手动处理。4.5 会话持久化与断线恢复的配置要点终端 AI 工作流最怕的就是断线丢上下文。tmux 本身解决了进程持久化的问题但 openrig 如果能在会话层面做更多比如自动保存会话元数据、记录最后活跃时间、支持会话快照那就更好了。配置持久化的时候注意几个点。一是 tmux 的会话在服务器重启后会丢失除非你配置了 tmux 的持久化插件或者用 systemd 管理。二是 openrig 自己的会话记录要存在可靠的位置最好是用户目录下的数据目录不要放在临时目录。三是如果会话里跑的任务有重要输出记得定期导出或者记录到日志文件。提示如果你在远程服务器上用这套工作流建议把 tmux 和 openrig 的配置都纳入版本控制换机器的时候直接拉下来就能用。配置文件里不要放敏感信息API Key 用环境变量或者单独的密钥文件管理。5. 常见问题与排查技巧实录5.1 安装与版本类问题速查问题现象可能原因排查思路error installing 24.21.0: node.js v24.21.0 is not yet released版本号不存在或写错去 Node.js 官网确认可用版本改用 LTS 版本安装 Claude Code 后命令找不到全局 bin 目录不在 PATH检查 npm prefix 配置确认 bin 目录已加入 PATHCodex 提示 unrecognized configuration setting配置文件字段名错误或版本不匹配对照官方文档检查字段删除不认识的配置项登录时提示组织已禁用访问账号权限问题确认账号类型联系管理员开启权限或改用个人账号本地模型调用失败API 地址或模型名不对确认 LM Studio 服务已启动检查端口和模型标识5.2 模型接入与切换的典型故障模型接入这块最常见的问题是地址写错、Key 无效、模型名不匹配。排查的时候按顺序来先确认服务本身能访问比如用 curl 直接调一下 API 端点再确认 Key 有效有些第三方接口会返回明确的鉴权错误最后确认模型名和接口期望的一致大小写和连字符都要注意。切换模型时如果工具没有生效可能是配置缓存的问题。有些工具会缓存配置改了配置文件后需要重启才生效。还有些工具支持热切换但需要特定的命令或者信号。openrig 如果做了封装应该会处理这些细节但了解底层机制有助于排查。另一个坑是上下文长度。不同模型的上下文窗口不一样切换到一个上下文更短的模型时之前的长对话可能会被截断。这时候要么精简上下文要么换回长上下文模型。在 openrig 的模型定义里标注上下文长度可以帮助你在切换时做出判断。5.3 tmux 会话管理中的坑tmux 用久了会遇到各种小问题。比如会话里的进程卡死attach 上去没反应或者窗口太多找不到想要的又或者 detach 之后忘了会话名不知道怎么回去。这些问题的根源通常是缺乏规范。我的经验是给 tmux 会话和窗口起有意义的名字并且定期清理不用的会话。openrig 如果提供了会话列表和清理命令就尽量用它来管理不要手动敲 tmux 命令。手动操作容易出错而且不好追溯。还有一个坑是终端尺寸变化。有时候你 attach 到一个会话发现显示错乱这是因为 tmux 记录的窗口尺寸和当前终端不一致。解决办法是 detach 再 attach或者用 tmux 的 resize 命令调整。在 openrig 里如果遇到类似问题先检查是不是 tmux 层面的原因。5.4 我踩过的三个真实坑和解决过程第一个坑是 Node.js 版本冲突。我一开始用系统包管理器装了 Node.js后来又用 nvm 装了一个版本结果 PATH 里两个版本打架Claude Code 跑起来报奇怪的模块错误。解决过程是彻底卸载系统版本的 Node.js统一用 nvm 管理并且在 shell 配置里确保 nvm 的初始化在 PATH 设置之前。第二个坑是 tmux 里的环境变量丢失。我在 shell 里配了 API Key 的环境变量但 tmux 会话里读不到。原因是 tmux 启动时继承的环境变量和当前 shell 不一致。解决办法是在 tmux 配置里显式传递需要的环境变量或者用 openrig 的配置来管理 Key不依赖 shell 环境。第三个坑是模型切换后上下文丢失。我本来以为切换模型后对话历史还在结果发现工具重启后上下文清空了。后来才明白上下文是存在工具自己的会话里的切换模型如果导致工具重启上下文就没了。解决办法是在切换前把关键上下文导出或者用 openrig 的会话快照功能保存状态。5.5 性能与资源占用的优化建议终端 AI 工具加上 tmux 和 openrig资源占用主要来自几个方面Node.js 进程本身、模型 API 调用的网络开销、tmux 会话的内存占用。一般来说单个会话的资源占用不大但同时开很多会话时就要注意了。优化建议有几个。一是及时清理不用的会话不要让它一直挂着。二是本地模型服务如果不用的时候关掉它占的内存和显存都不少。三是 openrig 的日志级别调低一点避免大量日志写入影响性能。四是如果网络不稳定考虑在模型调用层加重试和超时配置避免卡死。注意如果你在资源受限的机器上跑本地模型注意监控内存和显存使用。LM Studio 加载大模型时可能占用几个 GB 的内存加上 Node.js 和 tmux小内存机器容易吃紧。6. 进阶玩法把 openrig 融入日常开发流6.1 多项目并行时的会话组织策略当你同时推进多个项目时会话组织就变得很重要。我的做法是按项目建顶层分组每个项目下面再按任务建会话。比如项目 A 下面有“修 bug”“写文档”“重构”三个会话项目 B 下面有“调研”“原型”两个会话。openrig 如果支持标签或者分组就用它来组织如果不支持就在会话命名上做文章用统一的前缀。这样组织的好处是你随时能看清每个项目的进展也方便在项目间切换。切换的时候不需要重新配置环境因为每个会话的环境是独立的openrig 会帮你维护好。6.2 结合 VS Code 的混合工作流虽然 Claude Code 和 Codex 是终端工具但很多人日常还是在 VS Code 里写代码。把终端 AI 工具和 VS Code 结合起来可以形成一套混合工作流。比如在 VS Code 的集成终端里 attach 到 openrig 的会话一边看代码一边让 AI 改代码。VS Code 也有 Claude Code 的扩展可以在编辑器里直接调用。这种混合工作流的关键是终端和编辑器的协同。openrig 管理的会话可以在 VS Code 终端里访问工作目录指向项目根目录这样 AI 改的文件和你在编辑器里看的是同一份。切换模型或者工具时VS Code 这边不需要做什么只要终端会话还在就行。6.3 团队共享配置的注意事项如果你想把这套工作流分享给团队有几个点要注意。一是配置文件里的敏感信息要剥离API Key 用环境变量或者密钥管理服务。二是文档要写清楚依赖和版本要求避免别人装错版本。三是提供一键初始化的脚本降低上手成本。openrig 如果支持配置模板或者导出功能那就更方便。你可以把一套调好的配置导出成模板别人导入后改改模型端点和 Key 就能用。团队内部还可以约定统一的会话命名规范和模型命名规范减少沟通成本。6.4 后续可以扩展的方向这套工作流还有很多可以扩展的地方。比如加一个会话状态面板实时显示每个会话在跑什么、用了多少 token、花了多少钱。比如加一个模型效果对比功能同一个任务自动跑多个模型把结果并排展示。比如加一个上下文管理工具自动压缩和摘要长对话节省 token。openrig 作为一个编排层理论上可以接入更多工具和模型。只要工具提供命令行接口模型提供兼容 API就能纳入这套框架。这也是编排层思路的价值所在它不绑定特定工具而是提供一套通用的组织方式。我个人在实际操作中的体会是终端 AI 工作流的效率提升很大程度上不取决于单个工具多强而取决于整个流程有多顺。工具之间的切换成本、上下文丢失的成本、配置管理的成本这些加起来往往比模型本身的差异影响更大。openrig 这类编排工具的价值就是把这些摩擦成本降下来让你把精力集中在真正重要的事情上——也就是你正在解决的问题本身。