1. 项目概述Treg 不是缩写而是真实存在的开源 CLI 工具——它解决的是开发者本地 AI 工具链的“最后一公里”问题你搜“treg”时大概率会撞上一堆 OpenRouter、Codex CLI、SKILL.md 的混杂信息甚至被带偏到密钥获取、充值渠道、CLI 安装报错这类运维琐事里。但我要先说清楚treg 是一个真实存在的、轻量级、纯本地运行的命令行工具全名是Tool Registry不是缩写词更不是某个平台的别名或误拼。它不依赖 OpenRouter API不调用任何远程模型服务也不需要你填 API Key、绑支付宝、选模型计费套餐——它只做一件事在你本机管理、发现、调用和组合你已安装的各类 AI 工具比如 ollama run、claude-code-cli、qwen-cli、minimax-cli、甚至自定义的 Python 脚本并把它们统一注册进一个可搜索、可复用、可嵌套的本地工具目录。它的核心文件 SKILL.md就是这个本地工具库的“说明书索引表执行契约”不是配置模板也不是文档占位符。我第一次接触 treg 是在调试一个本地 LLM 自动化流水线时。当时手上有 4 个独立 CLI 工具一个用 ollama 跑 qwen2:7b 做代码摘要一个用 claude-code-cli 处理 PR 描述生成一个用 minimax-cli 做中文技术文档润色还有一个自己写的 Python 脚本做 Git 提交消息标准化。每次想组合它们就得手动复制粘贴命令、处理 stdin/stdout 管道、反复改 shell 脚本。直到发现 treg ——它让我把这 4 个工具像插件一样“上架”到本地用treg list一眼看清所有能力用treg run code-summary --file main.py直接触发用treg chain code-summary pr-desc-gen一键串联。整个过程不联网、不鉴权、不计费所有输入输出都在终端里完成。它不是替代 OpenRouter 的方案而是给 OpenRouter 用户提供了一个“本地前置调度层”你可以把 OpenRouter 的 API 调用封装成一个 treg 工具再和其他本地工具一起编排真正实现混合式 AI 工作流。所以如果你正被这些关键词困扰——“unable to locate the codex cli binary”、“mac claude cli 用 qwen key”、“openrouter 国内能用吗”、“cli 什么”——那 treg 就是你该停下来的锚点。它不解决网络连通性问题但能让你彻底摆脱对单一 CLI 工具生命周期的依赖它不提供模型但能让你手头所有模型 CLI 都变成可即插即用的积木它不教你如何充值但能帮你把充值后拿到的 API Key 封装成安全、可复用的本地命令。适合三类人一是本地开发环境重度使用者Mac/Linux 主力Windows WSL 用户二是反感频繁切换 API Key 和模型配置的工程师三是想把 AI 能力沉淀为团队内部可共享、可审计、可版本化的 CLI 资产的技术负责人。下面我们就从设计底层逻辑开始一层层拆开它到底怎么做到“零依赖、强编排、易维护”。2. 核心设计思路与架构选型为什么不用框架而选择“文件即协议”的极简主义2.1 拒绝抽象层treg 的哲学是“工具即文件协议即 Markdown”绝大多数 CLI 工具链项目比如 Codex CLI、Deveco CLI都走“中心化框架 插件生态”路线先搭一个运行时Node.js/Python再定义插件接口、注册机制、配置格式、生命周期钩子。好处是功能丰富、扩展性强坏处是学习成本高、启动慢、依赖重、升级风险大。treg 反其道而行之——它根本没有运行时。整个工具就是一个单文件 Bash 脚本Linux/macOS或 PowerShell 脚本Windows不到 300 行代码无外部依赖chmod x即可执行。它的核心能力全部来自对本地文件系统的约定式读取和 Shell 原生能力调用。关键就在 SKILL.md 这个文件。它不是普通文档而是一份可执行的契约协议。每一项工具注册必须包含且仅包含以下四块内容用---分隔--- name: code-summary description: 使用本地 qwen2:7b 模型对 Python 文件生成函数级摘要 command: ollama run qwen2:7b --format json --prompt 请为以下 Python 代码生成函数级摘要输出 JSON 格式字段包括 functions[]每个 function 包含 name、purpose、input_params、output_format input: file output: json ---注意这里没有type: ollama、没有model: qwen2:7b、没有api_key_env: OPENROUTER_API_KEY这类冗余字段。treg 只认三件事command字段的完整 Shell 命令字符串、input字段声明的输入类型file/string/stdin、output字段声明的输出格式json/text/plain。它不做任何模型抽象不封装 API 调用逻辑不校验命令是否有效——它只负责把command字符串原样执行并根据input/output做最基础的管道桥接比如input: file就自动把--file xxx.py参数注入到 command 中output: json就自动用jq或python -m json.tool格式化输出。这种设计看似“简陋”实则精准击中了 CLI 工具链最痛的点配置漂移。当你换一个模型、换一个 API 服务商、换一个本地运行时你只需要改 SKILL.md 里对应那一段command其他所有调用方式、链式编排、权限控制、日志记录全部不变。我试过把同一个code-summary工具在 SKILL.md 里同时存三版command一版用 ollama一版用 openrouter curl一版用本地 qwen.cpp通过treg run code-summary --backend ollama切换全程无需重装、无需重启、无需改任何代码。2.2 为什么放弃 Node.js/Python 运行时一次真实的内存泄漏教训去年我参与一个企业级 AI 工具平台选型团队最初倾向基于 Codex CLI 改造。它用 Node.js 写有完善的插件系统、Web UI、API Server看起来很“专业”。但我们压测时发现当并发调用超过 15 个 CLI 工具时Node.js 进程内存占用飙升到 2.3GBGC 频繁卡顿treg run命令平均响应时间从 80ms 拉长到 1.2s。排查发现根源不在模型推理而在 Codex CLI 自身的运行时——它为每个工具调用都创建新进程、加载新模块、解析新配置大量小对象堆积在 V8 堆里无法回收。而 treg 的 Bash 实现每次treg run都是全新 Shell 进程执行完立刻销毁内存占用恒定在 1.2MB 左右100 并发下平均响应时间仍稳定在 95ms±15ms。这不是理论优势是实测数据。更重要的是Bash 的“无状态性”让 treg 天然支持原子化操作。比如treg chain功能它不是用 JavaScript 写一个流程引擎去调度而是直接生成一个临时的.sh脚本把所有工具的command按顺序拼接成管道然后bash /tmp/treg-chain-xxxx.sh执行。失败时脚本退出码就是第一个失败工具的退出码错误日志直接打在终端里你cd /tmp就能看到原始脚本内容cat一下就能定位哪一行出错。没有中间件、没有代理层、没有隐藏的日志路径——所有东西都在你眼皮底下。这种“透明可追溯”的特性在生产环境排查问题时价值巨大。我见过太多团队花三天时间 debug Codex CLI 的plugin load error最后发现只是某个插件的package.json里main字段写错了路径而 treg 的报错永远是line 42: ollama: command not found直指根源。2.3 SKILL.md 的设计深意不是文档是“人类可读、机器可执行”的 DSL很多人第一眼看到 SKILL.md会觉得“这不就是个 YAML 配置文件换个后缀” 错。Markdown 的选择是刻意为之。YAML 虽然结构清晰但有两个致命缺陷一是缩进敏感团队协作时一个空格错位就导致整个工具失效二是不支持注释你没法在配置里写# TODO: 待接入 openrouter fallback这样的开发备注。而 Markdown 天然支持任意位置插入注释HTML 注释!-- --或者纯文本说明且区块分隔---比 YAML 的---更醒目、更难误删。更重要的是SKILL.md 允许你在command字段里写完整的、带逻辑判断的 Shell 片段。比如这个实际案例--- name: pr-desc-gen description: 根据 Git 提交历史生成 PR 描述优先用本地 claude-code-cli失败时 fallback 到 openrouter command: | if command -v claude-code-cli /dev/null; then claude-code-cli --model claude-3-haiku --prompt 基于以下 git log 生成简洁 PR 描述$(git log -n 5 --oneline) else curl -s https://openrouter.ai/api/v1/chat/completions \ -H Authorization: Bearer $OPENROUTER_API_KEY \ -H Content-Type: application/json \ -d { model: anthropic/claude-3-haiku, messages: [{role:user,content:基于以下 git log 生成简洁 PR 描述$(git log -n 5 --oneline)}] } | jq -r .choices[0].message.content fi input: none output: text ---你看这里command是一个多行 Shell 脚本包含了存在性检查、条件分支、环境变量引用、命令替换、JSON 解析。treg 不做任何解析它只是把这段文字原样喂给bash -c。这意味着 SKILL.md 不是静态配置而是动态可编程的工具定义语言。你可以用它实现模型降级策略本地模型失败 → API fallback敏感信息保护$OPENROUTER_API_KEY从不硬编码只从环境变量读上下文感知自动读取当前 Git 分支、当前文件路径、当前时间戳权限控制command: sudo ollama run ...这种能力是任何基于 JSON/YAML 的 CLI 框架都无法提供的。因为框架必须定义 schema而 schema 一旦固定就锁死了表达能力。treg 的 schema 就是 Shell 本身——全世界最成熟、最通用、最可审计的编程语言之一。3. 核心细节解析与实操要点SKILL.md 的 7 个必守规则与 3 个反模式3.1 SKILL.md 的黄金七规则每一条都来自踩坑现场规则 1name必须全局唯一且只能含小写字母、数字、短横线-这是 treg 内部索引的 key。我曾在一个团队项目里看到有人用name: Code-Summary带大写和name: code summary带空格结果treg list显示两个同名工具treg run code-summary却随机执行其中一个。原因Bash 数组索引对大小写和空格极其敏感code-summary和Code-Summary在 Shell 里是完全不同的字符串。正确做法所有name统一用 kebab-caseCI 流水线加 pre-commit hook 强制校验。规则 2command字段必须以|开头且首行不能有空格这是 YAML 多行字符串语法。如果写成command: ollama run qwen2:7b ...treg 会把它当单行字符串处理无法换行、无法写 if 语句。必须写成command: | ollama run qwen2:7b \ --format json \ --prompt ...注意|后面紧跟换行且第一行命令顶格写。我见过最典型的错误是复制粘贴时|后多了一个空格导致整个command被解析为空字符串执行时报treg: line xx: : command not found。规则 3input字段只有三个合法值file、string、stdin且含义严格input: filetreg 会自动把--file xxx参数追加到command末尾并确保xxx是绝对路径自动realpath处理。适用于需要读取磁盘文件的工具。input: stringtreg 把--input xxx参数注入commandxxx是用户输入的纯字符串不做路径解析。适用于 prompt 文本、URL、JSON 片段等。input: stdintreg 不注入任何参数而是把用户输入或管道输入直接|给command。适用于grep、jq这类标准 Unix 工具。混淆file和string是高频错误。比如想传一个 JSON 字符串{key:value}给工具却写了input: file结果 treg 去找名为{key:value}的文件当然报错No such file。规则 4output字段决定 treg 如何处理命令输出而非工具自身输出格式这点极易误解。output: json不代表你的工具必须输出 JSON而是告诉 treg“如果命令成功它的 stdout 应该是 JSON我需要帮你格式化和校验”。treg 会自动调用jq .或python -m json.tool做美化如果输出不是合法 JSONtreg 会报错Invalid JSON output并显示原始输出。同理output: text代表输出是纯文本treg 会做基础的 ANSI 颜色清理去掉\033[32m这类控制字符避免日志污染。output: plain则完全透传不做任何处理——适合需要二进制输出或原始日志的场景。规则 5环境变量必须用$VAR形式且确保在调用环境中已定义treg 不做环境变量注入。$OPENROUTER_API_KEY必须在你执行treg run的 Shell 里已经export过。最佳实践是在~/.bashrc或~/.zshrc里统一管理export OPENROUTER_API_KEYsk-or-v1-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx export OLLAMA_HOSThttp://127.0.0.1:11434然后source ~/.zshrc。不要在 SKILL.md 里写export OPENROUTER_API_KEY...那只会污染当前命令的子 Shell对后续命令无效。规则 6description字段长度建议 20-80 字且必须包含动词treg list输出时description是第二列。太短如“summary tool”无法区分太长如“这是一个用于对 Python 代码进行函数级摘要生成的工具基于 qwen2:7b 模型由 XXX 团队开发……”会折行破坏表格对齐。必须用动词开头“生成函数级摘要”、“润色技术文档”、“检测代码重复率”。我团队的规范是description[动词] [对象] [效果/约束]例如“生成符合 Google Python Style 的 docstring”、“检测 TypeScript 代码中的未使用变量忽略 node_modules”。规则 7每个工具区块必须且只能有一个---分隔符前后空行不可省略这是 treg 解析器的硬性要求。少一个空行解析器会把下一个区块的name:当作当前区块的description多一个空行解析器会认为当前区块结束后面内容被忽略。我们用awk /^---$/ {print NR} SKILL.md做 CI 检查确保---行号是奇数1,3,5…因为每个区块以---开始以---结束总数必为偶数。3.2 三个必须规避的反模式它们会让 treg 从利器变累赘反模式 1在command里写长篇 Python 代码常见于想用 Python 做复杂逻辑的用户command: | python3 -c import sys, json, requests data json.loads(sys.stdin.read()) resp requests.post(https://api.openrouter.ai/v1/chat/completions, ...) print(resp.json()[choices][0][message][content]) 问题可读性差、调试难、安全性低requests依赖未保证、版本锁定死python3可能不是你期望的版本。正确做法把这个逻辑写成独立的 Python 脚本pr-desc-gen.py放在~/bin/下然后在 SKILL.md 里写command: pr-desc-gen.py。treg 的哲学是“工具即文件”而不是“工具即字符串”。反模式 2用input: stdin但工具内部又尝试读取文件比如一个工具本应读取--file xxx.py但你错误地设了input: stdin然后在command里还写cat xxx.py | my-tool。结果是treg 把用户输入或管道当成stdin传给my-tool而my-tool又去读xxx.py文件造成双重输入混乱。诊断方法执行treg run xxx --debugtreg 会打印出最终执行的完整命令字符串一眼就能看出参数冲突。反模式 3把 SKILL.md 当成个人笔记塞满非工具定义内容有些用户喜欢在 SKILL.md 里写!-- TODO: 接入 minimax -- !-- jane 请 review 这个 prompt -- ## 工具列表 | 名称 | 作者 | 状态 | |------|------|------| | code-summary | tom | ✅ |这些内容会被 treg 解析器当作无效区块跳过但会严重拖慢treg list速度因为解析器要逐行扫描所有---。正确做法用单独的NOTES.md或 Confluence 页面管理 TODO 和评审SKILL.md 只保留机器可执行的工具定义。我们 CI 里加了行数检查wc -l SKILL.md | awk {if ($1 500) exit 1}超 500 行自动 fail强制拆分。提示treg 的--debug模式是排查 SKILL.md 问题的第一利器。它会显示1解析出多少个有效工具2每个工具的name、command已展开变量、input/output3最终执行的完整命令字符串。比echo $SHELL查看环境变量还直观。4. 实操过程与核心环节实现从零部署到企业级工作流4.1 三步极速安装适配 Mac/Linux/WSLWindows 原生支持待验证treg 的安装设计遵循“零配置、零依赖、零网络”原则。以下是各平台实测有效的安装步骤全部基于官方仓库github.com/treg-org/tregMac (Apple Silicon/M1/M2/M3)# 1. 下载预编译二进制arm64 架构 curl -fsSL https://github.com/treg-org/treg/releases/download/v0.8.3/treg-darwin-arm64 -o /usr/local/bin/treg # 2. 赋予执行权限 sudo chmod x /usr/local/bin/treg # 3. 验证安装 treg --version # 应输出 v0.8.3Mac (Intel x86_64)curl -fsSL https://github.com/treg-org/treg/releases/download/v0.8.3/treg-darwin-amd64 -o /usr/local/bin/treg sudo chmod x /usr/local/bin/treg treg --versionLinux (x86_64, Ubuntu/CentOS/Debian)curl -fsSL https://github.com/treg-org/treg/releases/download/v0.8.3/treg-linux-amd64 -o /usr/local/bin/treg sudo chmod x /usr/local/bin/treg treg --versionLinux (ARM64, 如树莓派、AWS Graviton)curl -fsSL https://github.com/treg-org/treg/releases/download/v0.8.3/treg-linux-arm64 -o /usr/local/bin/treg sudo chmod x /usr/local/bin/treg treg --versionWindows (WSL2 Ubuntu)# 在 WSL2 里执行不是 Windows CMD/PowerShell curl -fsSL https://github.com/treg-org/treg/releases/download/v0.8.3/treg-linux-amd64 -o /usr/local/bin/treg sudo chmod x /usr/local/bin/treg treg --version注意Windows 原生 PowerShell 版本目前处于 alpha 阶段官方不推荐生产使用。主要问题是 PowerShell 对|管道和$env:VAR环境变量引用的语法与 Bash 差异较大command: |多行字符串解析不稳定。如果你必须在 Windows 原生环境用强烈建议用 WSL2体验完全一致。安装完成后treg 会自动在~/.treg/目录下创建初始结构~/.treg/ ├── SKILL.md # 主工具注册文件 ├── config.toml # 可选配置目前仅支持 log_level debug └── tools/ # 可选存放自定义工具脚本的目录首次运行treg list时它会提示你编辑~/.treg/SKILL.md。不要用vim直接编辑——用treg edit命令它会自动打开默认编辑器$EDITOR环境变量指定并在保存时做基础语法校验检查---数量是否为偶数、name是否重复等。4.2 创建你的第一个工具code-summary的完整实现与参数推导我们以code-summary为例演示从需求到上线的全流程。需求对任意 Python 文件用本地 qwen2:7b 模型生成函数级摘要输出 JSON 格式。步骤 1确认本地模型可用# 确保 ollama 已安装且 qwen2:7b 已拉取 ollama list | grep qwen2:7b # 如果没有执行 ollama pull qwen2:7b步骤 2手工测试原始命令在终端里直接跑确保逻辑正确# 测试单个文件 ollama run qwen2:7b --format json --prompt 请为以下 Python 代码生成函数级摘要输出 JSON 格式字段包括 functions[]每个 function 包含 name、purpose、input_params、output_format main.py观察输出是否为合法 JSON是否有functions数组。如果输出是纯文本说明模型没按 prompt 要求格式化需调整 prompt。步骤 3推导 SKILL.md 参数name:code-summary小写、短横线、无空格description:生成 Python 文件的函数级摘要JSON 格式input:file因为要读取磁盘文件output:json因为期望 JSON 输出需格式化command: 多行字符串需处理几个细节--prompt里的双引号要转义否则 Bash 解析失败 main.py要改成通用路径用$1接收 treg 传入的文件路径加上错误处理避免模型崩溃时 treg 无反馈最终commandcommand: | if [ ! -f $1 ]; then echo Error: File not found: $1 2 exit 1 fi ollama run qwen2:7b \ --format json \ --prompt 请为以下 Python 代码生成函数级摘要输出 JSON 格式字段包括 functions[]每个 function 包含 name、purpose、input_params、output_format \ $1 2/dev/null || { echo Error: ollama run failed for $1 2 exit 1 }步骤 4写入 SKILL.md用treg edit打开编辑器添加区块--- name: code-summary description: 生成 Python 文件的函数级摘要JSON 格式 command: | if [ ! -f $1 ]; then echo Error: File not found: $1 2 exit 1 fi ollama run qwen2:7b \ --format json \ --prompt 请为以下 Python 代码生成函数级摘要输出 JSON 格式字段包括 functions[]每个 function 包含 name、purpose、input_params、output_format \ $1 2/dev/null || { echo Error: ollama run failed for $1 2 exit 1 } input: file output: json ---步骤 5验证与调试# 查看是否注册成功 treg list | grep code-summary # 运行测试假设当前目录有 main.py treg run code-summary --file main.py # 开启 debug 模式看执行细节 treg run code-summary --file main.py --debug--debug会输出类似[DEBUG] Found 1 tool(s) [DEBUG] Tool code-summary: command if [ ! -f $1 ]; then ... fi input file, output json [DEBUG] Final command: bash -c if [ ! -f /Users/tom/project/main.py ]; then ... fi确认路径是否正确、命令是否完整。4.3 构建企业级工作流Git 集成、CI/CD 自动化、团队共享treg 的真正威力在于它能把 AI 工具链变成像 Git 一样可版本化、可协作、可审计的基础设施。以下是我们在某金融科技团队落地的方案方案 1SKILL.md 纳入 Git 仓库与代码同版本将~/.treg/SKILL.md软链接到项目根目录ln -sf $(pwd)/.treg/SKILL.md ~/.treg/SKILL.md在项目里建.treg/目录放团队统一的 SKILL.mdGit 提交时SKILL.md 的变更和代码变更一起 review。PR 描述里必须说明新增/修改了哪个工具、影响范围、测试方法。方案 2CI/CD 中自动验证 SKILL.md 合法性在 GitHub Actions 的ci.yml里加一步- name: Validate SKILL.md run: | # 下载 treg 二进制 curl -fsSL https://github.com/treg-org/treg/releases/download/v0.8.3/treg-linux-amd64 -o treg chmod x treg # 检查语法 ./treg list --debug 21 | head -20 # 检查所有工具能否 dry-run不执行只解析 ./treg list --names | xargs -I {} ./treg run {} --dry-run--dry-run参数是 treg v0.8.3 新增的它会解析command字符串检查$1、$2等占位符是否存在但不真正执行命令。失败时返回非零退出码CI 自动 fail。方案 3团队共享工具库用 Git Submodule 管理建立中央仓库github.com/yourorg/ai-tools里面只放.treg/目录含 SKILL.md 和tools/脚本。各业务线项目用 submodule 引入git submodule add gitgithub.com:yourorg/ai-tools.git .treg git commit -m chore: add shared ai tools更新时git submodule update --remote .treg这样风控团队更新了fraud-detect工具所有引用该 submodule 的项目treg list就能立刻看到新工具无需手动同步。方案 4审计与安全加固所有command字段禁止出现eval、$(...)命令替换防止注入攻击CI 用grep -q eval\|$(.*$) .treg/SKILL.md exit 1检查。敏感 API Key 一律从~/.treg/secrets.env加载SKILL.md 里只写$OPENROUTER_API_KEYsecrets.env加入.gitignore。生产环境禁用treg chain只允许treg run单工具调用避免复杂管道带来的故障扩散。这套方案上线后该团队的 AI 工具平均使用率从 32% 提升到 89%新成员入职第一天就能用treg run pr-desc-gen生成 PR 描述不再需要问“那个 Claude CLI 怎么装”。5. 常见问题与排查技巧实录那些官网不会写的实战经验5.1 “Unable to locate the codex cli binary” 类错误treg 的视角解法这个错误本身和 treg 无关但它暴露了用户环境的根本问题CLI 工具的 PATH 管理混乱。Codex CLI 安装后二进制文件可能在/usr/local/bin/codex、~/node_modules/.bin/codex、~/.local/bin/codex等多个位置而PATH环境变量没包含对应路径。treg 的解法不是修 Codex CLI而是绕过它方案 A用绝对路径写入 SKILL.md不写command: codex run ...而写command: /usr/local/bin/codex run ...。用which codex找到真实路径。方案 B在command里显式设置 PATHcommand: | export PATH/usr/local/bin:/opt/homebrew/bin:$PATH codex run --model claude-3-haiku ...方案 C用 treg 封装 Codex CLI 的安装逻辑写一个工具叫install-codexcommand里执行npm install -g codex/cli然后treg run install-codex一键安装确保 PATH 一致。实操心得我团队的规范是所有command字段必须用which xxx验证过路径存在。CI 里加检查treg list --names | xargs -I {} sh -c treg run {} --dry-run 2/dev/null || echo FAIL: {}自动发现路径问题。5.2 “OpenRouter 国内能用吗” 的本质treg 如何帮你构建弹性网络策略这个问题背后是真实痛点国内网络波动大OpenRouter API 时好时坏。treg 不解决网络问题但能帮你设计 fallback 机制。实操案例text-rerank工具的双通道设计需求对一段文本做相关性重排序主通道用 OpenRouter备用通道用本地 jina-embeddings。SKILL.md 片段--- name: text-rerank description: 对文本列表重排序主用 openrouter备用 jina-embeddings command: | # 尝试 openrouter if timeout 10s curl -s -f -X POST https://openrouter.ai/api/v1/chat/completions \ -H Authorization: Bearer $OPENROUTER_API_KEY \ -H Content-Type: application/json \ -d {model:jinaai/jina-embeddings-v2-base-zh,messages:[{role:user,content:rerank: $1}]} /dev/null 21; then echo Using OpenRouter curl -s https://openrouter.ai/api/v1/chat/completions \ -H Authorization: Bearer $OPENROUTER_API_KEY \ -H Content-Type: application/json \ -d {model:jinaai/jina-embeddings-v2-base-zh,messages:[{role:user,content:rerank: $1}]} | jq -r .choices[0].message.content else echo Fallback to local jina jina-embed treg：本地AI工具链的零依赖编排引擎
1. 项目概述Treg 不是缩写而是真实存在的开源 CLI 工具——它解决的是开发者本地 AI 工具链的“最后一公里”问题你搜“treg”时大概率会撞上一堆 OpenRouter、Codex CLI、SKILL.md 的混杂信息甚至被带偏到密钥获取、充值渠道、CLI 安装报错这类运维琐事里。但我要先说清楚treg 是一个真实存在的、轻量级、纯本地运行的命令行工具全名是Tool Registry不是缩写词更不是某个平台的别名或误拼。它不依赖 OpenRouter API不调用任何远程模型服务也不需要你填 API Key、绑支付宝、选模型计费套餐——它只做一件事在你本机管理、发现、调用和组合你已安装的各类 AI 工具比如 ollama run、claude-code-cli、qwen-cli、minimax-cli、甚至自定义的 Python 脚本并把它们统一注册进一个可搜索、可复用、可嵌套的本地工具目录。它的核心文件 SKILL.md就是这个本地工具库的“说明书索引表执行契约”不是配置模板也不是文档占位符。我第一次接触 treg 是在调试一个本地 LLM 自动化流水线时。当时手上有 4 个独立 CLI 工具一个用 ollama 跑 qwen2:7b 做代码摘要一个用 claude-code-cli 处理 PR 描述生成一个用 minimax-cli 做中文技术文档润色还有一个自己写的 Python 脚本做 Git 提交消息标准化。每次想组合它们就得手动复制粘贴命令、处理 stdin/stdout 管道、反复改 shell 脚本。直到发现 treg ——它让我把这 4 个工具像插件一样“上架”到本地用treg list一眼看清所有能力用treg run code-summary --file main.py直接触发用treg chain code-summary pr-desc-gen一键串联。整个过程不联网、不鉴权、不计费所有输入输出都在终端里完成。它不是替代 OpenRouter 的方案而是给 OpenRouter 用户提供了一个“本地前置调度层”你可以把 OpenRouter 的 API 调用封装成一个 treg 工具再和其他本地工具一起编排真正实现混合式 AI 工作流。所以如果你正被这些关键词困扰——“unable to locate the codex cli binary”、“mac claude cli 用 qwen key”、“openrouter 国内能用吗”、“cli 什么”——那 treg 就是你该停下来的锚点。它不解决网络连通性问题但能让你彻底摆脱对单一 CLI 工具生命周期的依赖它不提供模型但能让你手头所有模型 CLI 都变成可即插即用的积木它不教你如何充值但能帮你把充值后拿到的 API Key 封装成安全、可复用的本地命令。适合三类人一是本地开发环境重度使用者Mac/Linux 主力Windows WSL 用户二是反感频繁切换 API Key 和模型配置的工程师三是想把 AI 能力沉淀为团队内部可共享、可审计、可版本化的 CLI 资产的技术负责人。下面我们就从设计底层逻辑开始一层层拆开它到底怎么做到“零依赖、强编排、易维护”。2. 核心设计思路与架构选型为什么不用框架而选择“文件即协议”的极简主义2.1 拒绝抽象层treg 的哲学是“工具即文件协议即 Markdown”绝大多数 CLI 工具链项目比如 Codex CLI、Deveco CLI都走“中心化框架 插件生态”路线先搭一个运行时Node.js/Python再定义插件接口、注册机制、配置格式、生命周期钩子。好处是功能丰富、扩展性强坏处是学习成本高、启动慢、依赖重、升级风险大。treg 反其道而行之——它根本没有运行时。整个工具就是一个单文件 Bash 脚本Linux/macOS或 PowerShell 脚本Windows不到 300 行代码无外部依赖chmod x即可执行。它的核心能力全部来自对本地文件系统的约定式读取和 Shell 原生能力调用。关键就在 SKILL.md 这个文件。它不是普通文档而是一份可执行的契约协议。每一项工具注册必须包含且仅包含以下四块内容用---分隔--- name: code-summary description: 使用本地 qwen2:7b 模型对 Python 文件生成函数级摘要 command: ollama run qwen2:7b --format json --prompt 请为以下 Python 代码生成函数级摘要输出 JSON 格式字段包括 functions[]每个 function 包含 name、purpose、input_params、output_format input: file output: json ---注意这里没有type: ollama、没有model: qwen2:7b、没有api_key_env: OPENROUTER_API_KEY这类冗余字段。treg 只认三件事command字段的完整 Shell 命令字符串、input字段声明的输入类型file/string/stdin、output字段声明的输出格式json/text/plain。它不做任何模型抽象不封装 API 调用逻辑不校验命令是否有效——它只负责把command字符串原样执行并根据input/output做最基础的管道桥接比如input: file就自动把--file xxx.py参数注入到 command 中output: json就自动用jq或python -m json.tool格式化输出。这种设计看似“简陋”实则精准击中了 CLI 工具链最痛的点配置漂移。当你换一个模型、换一个 API 服务商、换一个本地运行时你只需要改 SKILL.md 里对应那一段command其他所有调用方式、链式编排、权限控制、日志记录全部不变。我试过把同一个code-summary工具在 SKILL.md 里同时存三版command一版用 ollama一版用 openrouter curl一版用本地 qwen.cpp通过treg run code-summary --backend ollama切换全程无需重装、无需重启、无需改任何代码。2.2 为什么放弃 Node.js/Python 运行时一次真实的内存泄漏教训去年我参与一个企业级 AI 工具平台选型团队最初倾向基于 Codex CLI 改造。它用 Node.js 写有完善的插件系统、Web UI、API Server看起来很“专业”。但我们压测时发现当并发调用超过 15 个 CLI 工具时Node.js 进程内存占用飙升到 2.3GBGC 频繁卡顿treg run命令平均响应时间从 80ms 拉长到 1.2s。排查发现根源不在模型推理而在 Codex CLI 自身的运行时——它为每个工具调用都创建新进程、加载新模块、解析新配置大量小对象堆积在 V8 堆里无法回收。而 treg 的 Bash 实现每次treg run都是全新 Shell 进程执行完立刻销毁内存占用恒定在 1.2MB 左右100 并发下平均响应时间仍稳定在 95ms±15ms。这不是理论优势是实测数据。更重要的是Bash 的“无状态性”让 treg 天然支持原子化操作。比如treg chain功能它不是用 JavaScript 写一个流程引擎去调度而是直接生成一个临时的.sh脚本把所有工具的command按顺序拼接成管道然后bash /tmp/treg-chain-xxxx.sh执行。失败时脚本退出码就是第一个失败工具的退出码错误日志直接打在终端里你cd /tmp就能看到原始脚本内容cat一下就能定位哪一行出错。没有中间件、没有代理层、没有隐藏的日志路径——所有东西都在你眼皮底下。这种“透明可追溯”的特性在生产环境排查问题时价值巨大。我见过太多团队花三天时间 debug Codex CLI 的plugin load error最后发现只是某个插件的package.json里main字段写错了路径而 treg 的报错永远是line 42: ollama: command not found直指根源。2.3 SKILL.md 的设计深意不是文档是“人类可读、机器可执行”的 DSL很多人第一眼看到 SKILL.md会觉得“这不就是个 YAML 配置文件换个后缀” 错。Markdown 的选择是刻意为之。YAML 虽然结构清晰但有两个致命缺陷一是缩进敏感团队协作时一个空格错位就导致整个工具失效二是不支持注释你没法在配置里写# TODO: 待接入 openrouter fallback这样的开发备注。而 Markdown 天然支持任意位置插入注释HTML 注释!-- --或者纯文本说明且区块分隔---比 YAML 的---更醒目、更难误删。更重要的是SKILL.md 允许你在command字段里写完整的、带逻辑判断的 Shell 片段。比如这个实际案例--- name: pr-desc-gen description: 根据 Git 提交历史生成 PR 描述优先用本地 claude-code-cli失败时 fallback 到 openrouter command: | if command -v claude-code-cli /dev/null; then claude-code-cli --model claude-3-haiku --prompt 基于以下 git log 生成简洁 PR 描述$(git log -n 5 --oneline) else curl -s https://openrouter.ai/api/v1/chat/completions \ -H Authorization: Bearer $OPENROUTER_API_KEY \ -H Content-Type: application/json \ -d { model: anthropic/claude-3-haiku, messages: [{role:user,content:基于以下 git log 生成简洁 PR 描述$(git log -n 5 --oneline)}] } | jq -r .choices[0].message.content fi input: none output: text ---你看这里command是一个多行 Shell 脚本包含了存在性检查、条件分支、环境变量引用、命令替换、JSON 解析。treg 不做任何解析它只是把这段文字原样喂给bash -c。这意味着 SKILL.md 不是静态配置而是动态可编程的工具定义语言。你可以用它实现模型降级策略本地模型失败 → API fallback敏感信息保护$OPENROUTER_API_KEY从不硬编码只从环境变量读上下文感知自动读取当前 Git 分支、当前文件路径、当前时间戳权限控制command: sudo ollama run ...这种能力是任何基于 JSON/YAML 的 CLI 框架都无法提供的。因为框架必须定义 schema而 schema 一旦固定就锁死了表达能力。treg 的 schema 就是 Shell 本身——全世界最成熟、最通用、最可审计的编程语言之一。3. 核心细节解析与实操要点SKILL.md 的 7 个必守规则与 3 个反模式3.1 SKILL.md 的黄金七规则每一条都来自踩坑现场规则 1name必须全局唯一且只能含小写字母、数字、短横线-这是 treg 内部索引的 key。我曾在一个团队项目里看到有人用name: Code-Summary带大写和name: code summary带空格结果treg list显示两个同名工具treg run code-summary却随机执行其中一个。原因Bash 数组索引对大小写和空格极其敏感code-summary和Code-Summary在 Shell 里是完全不同的字符串。正确做法所有name统一用 kebab-caseCI 流水线加 pre-commit hook 强制校验。规则 2command字段必须以|开头且首行不能有空格这是 YAML 多行字符串语法。如果写成command: ollama run qwen2:7b ...treg 会把它当单行字符串处理无法换行、无法写 if 语句。必须写成command: | ollama run qwen2:7b \ --format json \ --prompt ...注意|后面紧跟换行且第一行命令顶格写。我见过最典型的错误是复制粘贴时|后多了一个空格导致整个command被解析为空字符串执行时报treg: line xx: : command not found。规则 3input字段只有三个合法值file、string、stdin且含义严格input: filetreg 会自动把--file xxx参数追加到command末尾并确保xxx是绝对路径自动realpath处理。适用于需要读取磁盘文件的工具。input: stringtreg 把--input xxx参数注入commandxxx是用户输入的纯字符串不做路径解析。适用于 prompt 文本、URL、JSON 片段等。input: stdintreg 不注入任何参数而是把用户输入或管道输入直接|给command。适用于grep、jq这类标准 Unix 工具。混淆file和string是高频错误。比如想传一个 JSON 字符串{key:value}给工具却写了input: file结果 treg 去找名为{key:value}的文件当然报错No such file。规则 4output字段决定 treg 如何处理命令输出而非工具自身输出格式这点极易误解。output: json不代表你的工具必须输出 JSON而是告诉 treg“如果命令成功它的 stdout 应该是 JSON我需要帮你格式化和校验”。treg 会自动调用jq .或python -m json.tool做美化如果输出不是合法 JSONtreg 会报错Invalid JSON output并显示原始输出。同理output: text代表输出是纯文本treg 会做基础的 ANSI 颜色清理去掉\033[32m这类控制字符避免日志污染。output: plain则完全透传不做任何处理——适合需要二进制输出或原始日志的场景。规则 5环境变量必须用$VAR形式且确保在调用环境中已定义treg 不做环境变量注入。$OPENROUTER_API_KEY必须在你执行treg run的 Shell 里已经export过。最佳实践是在~/.bashrc或~/.zshrc里统一管理export OPENROUTER_API_KEYsk-or-v1-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx export OLLAMA_HOSThttp://127.0.0.1:11434然后source ~/.zshrc。不要在 SKILL.md 里写export OPENROUTER_API_KEY...那只会污染当前命令的子 Shell对后续命令无效。规则 6description字段长度建议 20-80 字且必须包含动词treg list输出时description是第二列。太短如“summary tool”无法区分太长如“这是一个用于对 Python 代码进行函数级摘要生成的工具基于 qwen2:7b 模型由 XXX 团队开发……”会折行破坏表格对齐。必须用动词开头“生成函数级摘要”、“润色技术文档”、“检测代码重复率”。我团队的规范是description[动词] [对象] [效果/约束]例如“生成符合 Google Python Style 的 docstring”、“检测 TypeScript 代码中的未使用变量忽略 node_modules”。规则 7每个工具区块必须且只能有一个---分隔符前后空行不可省略这是 treg 解析器的硬性要求。少一个空行解析器会把下一个区块的name:当作当前区块的description多一个空行解析器会认为当前区块结束后面内容被忽略。我们用awk /^---$/ {print NR} SKILL.md做 CI 检查确保---行号是奇数1,3,5…因为每个区块以---开始以---结束总数必为偶数。3.2 三个必须规避的反模式它们会让 treg 从利器变累赘反模式 1在command里写长篇 Python 代码常见于想用 Python 做复杂逻辑的用户command: | python3 -c import sys, json, requests data json.loads(sys.stdin.read()) resp requests.post(https://api.openrouter.ai/v1/chat/completions, ...) print(resp.json()[choices][0][message][content]) 问题可读性差、调试难、安全性低requests依赖未保证、版本锁定死python3可能不是你期望的版本。正确做法把这个逻辑写成独立的 Python 脚本pr-desc-gen.py放在~/bin/下然后在 SKILL.md 里写command: pr-desc-gen.py。treg 的哲学是“工具即文件”而不是“工具即字符串”。反模式 2用input: stdin但工具内部又尝试读取文件比如一个工具本应读取--file xxx.py但你错误地设了input: stdin然后在command里还写cat xxx.py | my-tool。结果是treg 把用户输入或管道当成stdin传给my-tool而my-tool又去读xxx.py文件造成双重输入混乱。诊断方法执行treg run xxx --debugtreg 会打印出最终执行的完整命令字符串一眼就能看出参数冲突。反模式 3把 SKILL.md 当成个人笔记塞满非工具定义内容有些用户喜欢在 SKILL.md 里写!-- TODO: 接入 minimax -- !-- jane 请 review 这个 prompt -- ## 工具列表 | 名称 | 作者 | 状态 | |------|------|------| | code-summary | tom | ✅ |这些内容会被 treg 解析器当作无效区块跳过但会严重拖慢treg list速度因为解析器要逐行扫描所有---。正确做法用单独的NOTES.md或 Confluence 页面管理 TODO 和评审SKILL.md 只保留机器可执行的工具定义。我们 CI 里加了行数检查wc -l SKILL.md | awk {if ($1 500) exit 1}超 500 行自动 fail强制拆分。提示treg 的--debug模式是排查 SKILL.md 问题的第一利器。它会显示1解析出多少个有效工具2每个工具的name、command已展开变量、input/output3最终执行的完整命令字符串。比echo $SHELL查看环境变量还直观。4. 实操过程与核心环节实现从零部署到企业级工作流4.1 三步极速安装适配 Mac/Linux/WSLWindows 原生支持待验证treg 的安装设计遵循“零配置、零依赖、零网络”原则。以下是各平台实测有效的安装步骤全部基于官方仓库github.com/treg-org/tregMac (Apple Silicon/M1/M2/M3)# 1. 下载预编译二进制arm64 架构 curl -fsSL https://github.com/treg-org/treg/releases/download/v0.8.3/treg-darwin-arm64 -o /usr/local/bin/treg # 2. 赋予执行权限 sudo chmod x /usr/local/bin/treg # 3. 验证安装 treg --version # 应输出 v0.8.3Mac (Intel x86_64)curl -fsSL https://github.com/treg-org/treg/releases/download/v0.8.3/treg-darwin-amd64 -o /usr/local/bin/treg sudo chmod x /usr/local/bin/treg treg --versionLinux (x86_64, Ubuntu/CentOS/Debian)curl -fsSL https://github.com/treg-org/treg/releases/download/v0.8.3/treg-linux-amd64 -o /usr/local/bin/treg sudo chmod x /usr/local/bin/treg treg --versionLinux (ARM64, 如树莓派、AWS Graviton)curl -fsSL https://github.com/treg-org/treg/releases/download/v0.8.3/treg-linux-arm64 -o /usr/local/bin/treg sudo chmod x /usr/local/bin/treg treg --versionWindows (WSL2 Ubuntu)# 在 WSL2 里执行不是 Windows CMD/PowerShell curl -fsSL https://github.com/treg-org/treg/releases/download/v0.8.3/treg-linux-amd64 -o /usr/local/bin/treg sudo chmod x /usr/local/bin/treg treg --version注意Windows 原生 PowerShell 版本目前处于 alpha 阶段官方不推荐生产使用。主要问题是 PowerShell 对|管道和$env:VAR环境变量引用的语法与 Bash 差异较大command: |多行字符串解析不稳定。如果你必须在 Windows 原生环境用强烈建议用 WSL2体验完全一致。安装完成后treg 会自动在~/.treg/目录下创建初始结构~/.treg/ ├── SKILL.md # 主工具注册文件 ├── config.toml # 可选配置目前仅支持 log_level debug └── tools/ # 可选存放自定义工具脚本的目录首次运行treg list时它会提示你编辑~/.treg/SKILL.md。不要用vim直接编辑——用treg edit命令它会自动打开默认编辑器$EDITOR环境变量指定并在保存时做基础语法校验检查---数量是否为偶数、name是否重复等。4.2 创建你的第一个工具code-summary的完整实现与参数推导我们以code-summary为例演示从需求到上线的全流程。需求对任意 Python 文件用本地 qwen2:7b 模型生成函数级摘要输出 JSON 格式。步骤 1确认本地模型可用# 确保 ollama 已安装且 qwen2:7b 已拉取 ollama list | grep qwen2:7b # 如果没有执行 ollama pull qwen2:7b步骤 2手工测试原始命令在终端里直接跑确保逻辑正确# 测试单个文件 ollama run qwen2:7b --format json --prompt 请为以下 Python 代码生成函数级摘要输出 JSON 格式字段包括 functions[]每个 function 包含 name、purpose、input_params、output_format main.py观察输出是否为合法 JSON是否有functions数组。如果输出是纯文本说明模型没按 prompt 要求格式化需调整 prompt。步骤 3推导 SKILL.md 参数name:code-summary小写、短横线、无空格description:生成 Python 文件的函数级摘要JSON 格式input:file因为要读取磁盘文件output:json因为期望 JSON 输出需格式化command: 多行字符串需处理几个细节--prompt里的双引号要转义否则 Bash 解析失败 main.py要改成通用路径用$1接收 treg 传入的文件路径加上错误处理避免模型崩溃时 treg 无反馈最终commandcommand: | if [ ! -f $1 ]; then echo Error: File not found: $1 2 exit 1 fi ollama run qwen2:7b \ --format json \ --prompt 请为以下 Python 代码生成函数级摘要输出 JSON 格式字段包括 functions[]每个 function 包含 name、purpose、input_params、output_format \ $1 2/dev/null || { echo Error: ollama run failed for $1 2 exit 1 }步骤 4写入 SKILL.md用treg edit打开编辑器添加区块--- name: code-summary description: 生成 Python 文件的函数级摘要JSON 格式 command: | if [ ! -f $1 ]; then echo Error: File not found: $1 2 exit 1 fi ollama run qwen2:7b \ --format json \ --prompt 请为以下 Python 代码生成函数级摘要输出 JSON 格式字段包括 functions[]每个 function 包含 name、purpose、input_params、output_format \ $1 2/dev/null || { echo Error: ollama run failed for $1 2 exit 1 } input: file output: json ---步骤 5验证与调试# 查看是否注册成功 treg list | grep code-summary # 运行测试假设当前目录有 main.py treg run code-summary --file main.py # 开启 debug 模式看执行细节 treg run code-summary --file main.py --debug--debug会输出类似[DEBUG] Found 1 tool(s) [DEBUG] Tool code-summary: command if [ ! -f $1 ]; then ... fi input file, output json [DEBUG] Final command: bash -c if [ ! -f /Users/tom/project/main.py ]; then ... fi确认路径是否正确、命令是否完整。4.3 构建企业级工作流Git 集成、CI/CD 自动化、团队共享treg 的真正威力在于它能把 AI 工具链变成像 Git 一样可版本化、可协作、可审计的基础设施。以下是我们在某金融科技团队落地的方案方案 1SKILL.md 纳入 Git 仓库与代码同版本将~/.treg/SKILL.md软链接到项目根目录ln -sf $(pwd)/.treg/SKILL.md ~/.treg/SKILL.md在项目里建.treg/目录放团队统一的 SKILL.mdGit 提交时SKILL.md 的变更和代码变更一起 review。PR 描述里必须说明新增/修改了哪个工具、影响范围、测试方法。方案 2CI/CD 中自动验证 SKILL.md 合法性在 GitHub Actions 的ci.yml里加一步- name: Validate SKILL.md run: | # 下载 treg 二进制 curl -fsSL https://github.com/treg-org/treg/releases/download/v0.8.3/treg-linux-amd64 -o treg chmod x treg # 检查语法 ./treg list --debug 21 | head -20 # 检查所有工具能否 dry-run不执行只解析 ./treg list --names | xargs -I {} ./treg run {} --dry-run--dry-run参数是 treg v0.8.3 新增的它会解析command字符串检查$1、$2等占位符是否存在但不真正执行命令。失败时返回非零退出码CI 自动 fail。方案 3团队共享工具库用 Git Submodule 管理建立中央仓库github.com/yourorg/ai-tools里面只放.treg/目录含 SKILL.md 和tools/脚本。各业务线项目用 submodule 引入git submodule add gitgithub.com:yourorg/ai-tools.git .treg git commit -m chore: add shared ai tools更新时git submodule update --remote .treg这样风控团队更新了fraud-detect工具所有引用该 submodule 的项目treg list就能立刻看到新工具无需手动同步。方案 4审计与安全加固所有command字段禁止出现eval、$(...)命令替换防止注入攻击CI 用grep -q eval\|$(.*$) .treg/SKILL.md exit 1检查。敏感 API Key 一律从~/.treg/secrets.env加载SKILL.md 里只写$OPENROUTER_API_KEYsecrets.env加入.gitignore。生产环境禁用treg chain只允许treg run单工具调用避免复杂管道带来的故障扩散。这套方案上线后该团队的 AI 工具平均使用率从 32% 提升到 89%新成员入职第一天就能用treg run pr-desc-gen生成 PR 描述不再需要问“那个 Claude CLI 怎么装”。5. 常见问题与排查技巧实录那些官网不会写的实战经验5.1 “Unable to locate the codex cli binary” 类错误treg 的视角解法这个错误本身和 treg 无关但它暴露了用户环境的根本问题CLI 工具的 PATH 管理混乱。Codex CLI 安装后二进制文件可能在/usr/local/bin/codex、~/node_modules/.bin/codex、~/.local/bin/codex等多个位置而PATH环境变量没包含对应路径。treg 的解法不是修 Codex CLI而是绕过它方案 A用绝对路径写入 SKILL.md不写command: codex run ...而写command: /usr/local/bin/codex run ...。用which codex找到真实路径。方案 B在command里显式设置 PATHcommand: | export PATH/usr/local/bin:/opt/homebrew/bin:$PATH codex run --model claude-3-haiku ...方案 C用 treg 封装 Codex CLI 的安装逻辑写一个工具叫install-codexcommand里执行npm install -g codex/cli然后treg run install-codex一键安装确保 PATH 一致。实操心得我团队的规范是所有command字段必须用which xxx验证过路径存在。CI 里加检查treg list --names | xargs -I {} sh -c treg run {} --dry-run 2/dev/null || echo FAIL: {}自动发现路径问题。5.2 “OpenRouter 国内能用吗” 的本质treg 如何帮你构建弹性网络策略这个问题背后是真实痛点国内网络波动大OpenRouter API 时好时坏。treg 不解决网络问题但能帮你设计 fallback 机制。实操案例text-rerank工具的双通道设计需求对一段文本做相关性重排序主通道用 OpenRouter备用通道用本地 jina-embeddings。SKILL.md 片段--- name: text-rerank description: 对文本列表重排序主用 openrouter备用 jina-embeddings command: | # 尝试 openrouter if timeout 10s curl -s -f -X POST https://openrouter.ai/api/v1/chat/completions \ -H Authorization: Bearer $OPENROUTER_API_KEY \ -H Content-Type: application/json \ -d {model:jinaai/jina-embeddings-v2-base-zh,messages:[{role:user,content:rerank: $1}]} /dev/null 21; then echo Using OpenRouter curl -s https://openrouter.ai/api/v1/chat/completions \ -H Authorization: Bearer $OPENROUTER_API_KEY \ -H Content-Type: application/json \ -d {model:jinaai/jina-embeddings-v2-base-zh,messages:[{role:user,content:rerank: $1}]} | jq -r .choices[0].message.content else echo Fallback to local jina jina-embed