1. 从“treg”这个标题说起：一个被低估的CLI Agent入口
第一次看到“treg”这四个字母，大多数人会一头雾水。它不像“codex cli”那样直白，也不像“claude cli”那样自带品牌辨识度。但如果你最近在折腾 agent 开发、OpenRouter 密钥管理、或者各种 CLI 工具的安装配置，你大概率已经在某个 issue、某条讨论或者某个配置文件里见过它。treg 本质上是一个围绕agent 执行链路做轻量封装的命令行工具，它的定位很明确：把 OpenRouter、各类 API Key、CLI Agent 运行时这几件事串起来，让“我想跑一个 agent”这件事从半小时的配置变成一条命令。
我最初接触 treg 是因为一个很实际的问题：手里同时有 OpenRouter 的密钥、DeepSeek 的 API、还有几个本地 CLI agent 工具（codex cli、claude cli 这类），每次切换模型或者换 provider 都要改环境变量、改配置文件、重启终端，烦得不行。treg 解决的正是这个痛点——它把 provider 配置、密钥读取、CLI 调用参数统一收口到一个入口，你只需要告诉它“用哪个模型、走哪个 key、执行什么任务”，剩下的它来处理。
这篇文章适合三类人看：第一类是想入门 agent 开发但被各种 CLI 安装和 API 配置卡住的新手；第二类是在多个 provider 之间反复横跳、需要统一管理密钥和调用的中级开发者；第三类是对 OpenRouter 生态感兴趣、想搞清楚“openrouter 国内能用吗”“openrouter 如何充值”这些实际问题的人。我会从 treg 的设计思路讲起，拆解它的核心机制，然后给出完整的实操步骤、参数配置、常见报错排查，最后分享一些我在实际使用中踩过的坑和总结出来的技巧。全文基于公开信息和常见实践整理，涉及具体密钥和账号的部分请以你实际拿到的为准。
2. treg 的整体设计与核心思路拆解
2.1 为什么需要一个 CLI 层的 agent 封装
要理解 treg 的价值，先得看清楚现在 agent 开发的碎片化现状。你想跑一个 agent，通常需要这几样东西：一个模型 provider（OpenRouter、DeepSeek、智谱等）、一个 API Key、一个 CLI 运行时（codex cli、claude cli、minimax code cli 等）、以及一套把任务描述传给模型的调用逻辑。这四样东西分散在不同地方，配置方式各不相同。OpenRouter 的 key 放在一个环境变量里，DeepSeek 的 key 放在另一个文件里，codex cli 有自己的安装路径要求，claude cli 在 Mac 上又有一套单独的配置流程。每次换模型，你就要重新对一遍这些配置。
treg 的思路是把这四层抽象成一个统一的调用栈。它不替代任何 CLI 工具，也不替代 OpenRouter，而是在它们之上加了一层“路由+配置”的逻辑。你可以把它理解成一个 agent 调用的调度器：输入是任务描述和模型选择，输出是实际执行结果，中间涉及的密钥读取、provider 路由、CLI 参数拼装全部由 treg 处理。这种设计的好处是解耦——你的任务逻辑和 provider 配置分离，换模型不用改任务代码，换 CLI 工具不用重写调用链路。
从热词里能看到大量关于“agent 框架与编排”“agent 开发学习路线”“harness 和 agent 区别”的搜索，说明很多人正在从“写一个 agent”过渡到“管理一堆 agent”。treg 这类工具正好卡在这个过渡点上，它不教你 agent 的原理，但帮你把 agent 跑起来这件事变得可维护。
2.2 treg 与 OpenRouter 的配合逻辑
OpenRouter 在这个体系里扮演的是“模型聚合层”的角色。你不需要分别去申请 DeepSeek、智谱、MiniMax 的 key，只需要一个 OpenRouter 的 key，就能通过统一接口调用多家模型。这对 agent 开发特别友好，因为 agent 经常需要根据任务类型切换模型——简单任务用便宜的小模型，复杂推理用贵的大模型，代码生成用专门的代码模型。如果每个模型都要单独配置，切换成本太高。
treg 对 OpenRouter 的支持体现在几个层面。第一是密钥管理：treg 会从指定的环境变量或配置文件中读取 OpenRouter 的 API Key，不需要你每次手动 export。第二是模型路由：你可以在 treg 的配置里定义模型别名，比如把“fast”映射到某个便宜模型，“smart”映射到某个强推理模型，调用时直接用别名。第三是错误处理：OpenRouter 返回的 API 错误（比如 context length 超限、key 无效、余额不足）会被 treg 捕获并给出更可读的提示，而不是直接抛一堆 JSON 给你。
这里要特别说明一点：OpenRouter 本身是一个第三方聚合服务，它的可用性、充值方式、国内访问情况都会影响你的使用体验。热词里“openrouter 国内能用吗”“openrouter 如何充值”“openrouter 支付宝”这些搜索量很高，说明这是很多人的实际困扰。我的建议是，在把 treg 接入生产流程之前，先单独验证 OpenRouter 的连通性和计费方式，确保你的使用场景和它的服务条款匹配。treg 只负责调用，不负责解决网络层和支付层的问题。
2.3 方案选型：为什么是 CLI 而不是 SDK
有人可能会问，既然都是调 API，为什么不直接用 Python SDK 或者 HTTP 请求，非要套一层 CLI？这个问题我在刚开始用 treg 的时候也想过。后来想明白了，CLI 的优势在于零依赖集成和跨语言通用。你用 Python 写 agent，SDK 很方便；但你用 shell 脚本做自动化，或者在一个没有 Python 环境的容器里跑任务，CLI 就是最直接的选择。而且 CLI 工具天然适合管道操作，你可以把 treg 的输出直接传给下一个命令，这在构建 agent 工作流的时候非常实用。
另一个原因是调试友好。SDK 调用出错的时候，你往往要加日志、改代码、重新运行。CLI 调用出错，你直接看终端输出就行，参数对不对、key 有没有读到、模型返回了什么，一目了然。对于 agent 开发这种需要反复试错的过程，CLI 的反馈循环更短。
当然 CLI 也有代价，比如参数传递不如 SDK 灵活，复杂逻辑不好表达。所以 treg 的定位不是替代 SDK，而是提供一个“最小可用”的调用入口。你可以用它做快速验证、做脚本集成、做 CI 里的自动化任务，等逻辑复杂了再迁移到 SDK。这种渐进式的路径对学习者比较友好。
3. 核心细节解析与实操要点
3.1 安装与环境准备：避开 codex cli 安装的那些坑
treg 本身是一个轻量工具，安装不复杂，但它依赖的 CLI 运行时（比如 codex cli）安装起来坑不少。热词里“codex cli 安装”“安装 codex cli”“unable to locate the codex cli binary or required runtime components”这些搜索，说明很多人卡在安装环节。我先把通用的环境准备步骤列出来，再讲几个容易出问题的地方。
基础环境要求：一个类 Unix 的终端环境（macOS、Linux、WSL 都行），Node.js 运行时（建议 18 以上），以及一个可用的包管理器（npm、pnpm 或 yarn）。如果你在 Windows 上，强烈建议用 WSL，因为很多 CLI 工具对原生 Windows 的支持不完整，路径处理和权限模型都不一样。
安装 treg 的典型流程是：
# 以 npm 全局安装为例 npm install -g treg # 验证安装 treg --version如果这一步报“command not found”，通常是 npm 全局 bin 目录不在 PATH 里。你可以用npm config get prefix看一下全局安装路径，然后把这个路径下的 bin 目录加到 PATH。macOS 上常见的是/usr/local/bin或~/.npm-global/bin，Linux 上可能是/usr/bin或~/.local/bin。
接下来是 CLI 运行时的安装。以 codex cli 为例，安装方式取决于你用的具体工具。有些是通过 npm 安装，有些是独立二进制。安装完之后一定要验证：
# 检查 codex cli 是否可用 codex --version # 如果报 "unable to locate the codex cli binary" # 检查安装路径是否在 PATH 中 which codex注意：很多“unable to locate the codex cli binary or required runtime components”的报错，根源不是没安装，而是安装路径没进 PATH，或者安装的是某个不兼容的版本。先确认
which能找到，再确认版本号符合要求。
3.2 密钥管理：OpenRouter API Key 的正确打开方式
密钥管理是 treg 使用中最容易出问题的环节。热词里“openrouter api key”“openrouter 密钥获取”“openrouter 密钥大全”“api_key_required”这些搜索，反映出大家对密钥的获取、配置、验证都有困惑。我分几步说清楚。
第一步是获取密钥。你需要在 OpenRouter 的官方入口注册账号，然后在控制台里创建一个 API Key。创建的时候注意权限范围，有些 key 是只读的，有些可以调用所有模型。创建完成后立刻复制保存，因为很多平台只显示一次。
第二步是配置到环境里。treg 通常从环境变量读取密钥，常见的变量名是OPENROUTER_API_KEY。你可以这样设置：
# 临时设置（当前终端会话有效） export OPENROUTER_API_KEY="你的密钥" # 永久设置（写入 shell 配置文件） echo 'export OPENROUTER_API_KEY="你的密钥"' >> ~/.bashrc source ~/.bashrc如果你用 zsh，配置文件是~/.zshrc。设置完之后验证一下：
echo $OPENROUTER_API_KEY能打印出密钥就说明环境变量生效了。如果打印为空，检查一下是不是写错了文件，或者没有 source。
第三步是验证密钥可用性。不要等到跑 agent 的时候才发现 key 有问题，先用一个最简单的调用测试：
# 用 curl 直接测试 OpenRouter 接口 curl -X POST https://openrouter.ai/api/v1/chat/completions \ -H "Authorization: Bearer $OPENROUTER_API_KEY" \ -H "Content-Type: application/json" \ -d '{"model":"openai/gpt-3.5-turbo","messages":[{"role":"user","content":"hi"}]}'如果返回正常，说明 key 和网络都没问题。如果返回{"code":"api_key_required","message":"api key is required in authorization header"}，说明 key 没传对或者格式有问题。如果返回 401，说明 key 无效或过期。
提示：不要把密钥硬编码在脚本里，也不要把包含密钥的文件提交到版本控制。用环境变量或专门的密钥管理工具，这是基本的安全习惯。
3.3 模型路由配置：让 treg 知道该用哪个模型
treg 的核心能力之一是模型路由。你可以在配置文件里定义一组模型别名，每个别名对应一个具体的模型 ID 和 provider。这样调用的时候只需要说“用 smart 模型”，treg 会自动解析成实际的模型 ID。
一个典型的配置文件（假设是~/.treg/config.yaml）长这样：
models: fast: provider: openrouter model: "openai/gpt-3.5-turbo" max_tokens: 2048 smart: provider: openrouter model: "anthropic/claude-3-opus" max_tokens: 8192 code: provider: openrouter model: "deepseek/deepseek-coder" max_tokens: 4096 default_model: fast这个配置的好处是，你换模型的时候只改配置文件，不用改调用命令。比如你发现某个模型涨价了，把smart对应的 model 换掉就行，所有用smart别名的脚本都不用动。
配置里还可以加一些通用参数，比如超时时间、重试次数、温度值。这些参数会作为默认值传给底层 CLI 或 API 调用。对于 agent 场景，重试机制特别重要，因为 agent 经常需要多轮调用，中间某一次失败不应该导致整个任务中断。
defaults: timeout: 60 retries: 3 temperature: 0.7注意：不同 provider 对参数的支持程度不一样。有些模型不支持 temperature 调节，有些对 max_tokens 有上限。配置的时候要查一下目标模型的文档，避免传了不支持的参数导致报错。
3.4 CLI 调用参数详解：从基础到进阶
treg 的命令行参数设计通常遵循“约定优于配置”的原则，最常用的场景用最少的参数就能跑起来。基础调用格式大概是：
treg run --model smart --prompt "帮我写一个 Python 脚本，读取 CSV 并统计每列的空值数量"这里--model指定模型别名，--prompt是任务描述。treg 会读取配置、解析模型、调用底层 CLI 或 API、返回结果。
进阶用法包括几个方向。一是从文件读取 prompt，适合长任务描述：
treg run --model smart --prompt-file ./task.md二是管道输入，适合和其他命令组合：
cat error.log | treg run --model fast --prompt "分析这些错误日志，找出最常见的三个问题"三是输出格式化，方便后续处理：
treg run --model code --prompt "生成一个快速排序函数" --output json四是多轮对话模式，适合需要上下文的 agent 任务：
treg chat --model smart进入交互模式后，你可以连续输入多条消息，treg 会维护上下文。这对于调试 agent 逻辑特别有用，你可以一步步引导模型，观察它的输出变化。
参数的选择背后有实际考量。比如--model用别名而不是完整模型 ID，是为了解耦；--prompt-file支持文件输入，是为了处理超过终端长度限制的长文本；--output json是为了让结果可以被程序解析。这些设计都指向同一个目标：让 treg 既能被人直接使用，也能被脚本和程序调用。
4. 实操过程与核心环节实现
4.1 从零搭建一个可用的 treg 工作环境
我把完整的搭建过程拆成可复现的步骤，你跟着做一遍就能跑起来。假设你用的是 macOS 或 Linux，Windows 用户请用 WSL。
第一步，确认基础环境：
node --version # 应该 >= 18 npm --version # 应该 >= 9如果版本不够，先升级 Node.js。可以用 nvm 管理多版本：
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash nvm install 20 nvm use 20第二步，安装 treg：
npm install -g treg treg --version第三步，配置 OpenRouter 密钥：
export OPENROUTER_API_KEY="你的密钥"第四步，创建 treg 配置文件：
mkdir -p ~/.treg cat > ~/.treg/config.yaml << 'EOF' models: fast: provider: openrouter model: "openai/gpt-3.5-turbo" max_tokens: 2048 smart: provider: openrouter model: "anthropic/claude-3-opus" max_tokens: 8192 default_model: fast defaults: timeout: 60 retries: 3 EOF第五步，验证配置：
treg config list treg run --model fast --prompt "回复 OK 两个字母"如果最后一步能正常返回，说明环境搭好了。如果报错，对照下一节的排查表处理。
4.2 用 treg 跑一个真实的 agent 任务
环境搭好之后，我们跑一个稍微复杂点的任务，看看 treg 在实际 agent 场景下的表现。任务描述：读取一个目录下的所有 Markdown 文件，提取其中的代码块，统计每种编程语言出现的次数。
这个任务需要多步操作：遍历文件、解析内容、统计结果。用 treg 可以这样实现：
# 先让 treg 生成一个处理脚本 treg run --model code --prompt "写一个 Python 脚本，遍历指定目录下所有 .md 文件，提取所有代码块，统计每种语言标记出现的次数，输出 JSON 格式结果" > extract_code.py # 检查生成的脚本 cat extract_code.py # 运行脚本 python extract_code.py ./docs这里 treg 扮演的是“代码生成器”的角色。你给它任务描述，它返回可执行的代码。这种用法在 agent 开发里很常见，相当于把模型当作一个高级的代码补全工具。
另一种用法是让 treg 直接执行任务，而不是生成代码。比如：
treg run --model smart --prompt "分析当前目录下所有 Python 文件的复杂度，找出最需要重构的三个文件，给出理由"treg 会把任务描述和必要的上下文传给模型，模型返回分析结果。这种模式下，treg 更像是一个“智能终端助手”，你描述需求，它给答案。
两种模式各有适用场景。生成代码适合需要复用、需要审查的任务；直接执行适合一次性的分析、总结、判断类任务。实际使用中，我通常会先用直接执行模式快速验证思路，确认可行后再让 treg 生成可复用的脚本。
4.3 参数计算与选择：max_tokens 和 context length 的关系
热词里有一条很具体的报错：“api error: 400 this model's maximum context length is 1048576 tokens. however...”。这个报错说明很多人对 context length 和 max_tokens 的关系不清楚。我在这里展开讲一下。
Context length 是模型一次能处理的最大 token 数，包括输入和输出。Max_tokens 是你希望模型生成的最大 token 数。两者的关系是：输入 token 数 + max_tokens <= context length。如果你传的输入太长，加上 max_tokens 超过了 context length，就会报 400 错误。
举个例子，某个模型的 context length 是 128000 tokens，你传了 120000 tokens 的输入，然后设置 max_tokens 为 16000，加起来 136000 超过了 128000，就会报错。解决办法是减少输入长度，或者降低 max_tokens。
在 treg 的配置里，max_tokens 应该根据任务类型设置。对于简单的问答任务，2048 通常够用；对于代码生成，4096 到 8192 比较合适；对于长文档分析，可能需要 16000 以上。但要注意，max_tokens 设得越大，费用越高，而且模型生成到后面质量可能下降。
提示：如果你不确定该设多少，先用一个较小的值（比如 2048）跑一遍，看看输出是否被截断。如果被截断了，再逐步调大。不要一上来就设成模型上限，那样既浪费钱又可能触发超时。
4.4 多 provider 切换的实操演示
treg 的另一个实用场景是多 provider 切换。假设你同时有 OpenRouter 的 key 和 DeepSeek 的 key，想在两者之间灵活切换。配置可以这样写：
providers: openrouter: api_key_env: OPENROUTER_API_KEY base_url: "https://openrouter.ai/api/v1" deepseek: api_key_env: DEEPSEEK_API_KEY base_url: "https://api.deepseek.com/v1" models: fast: provider: openrouter model: "openai/gpt-3.5-turbo" deep: provider: deepseek model: "deepseek-chat" code: provider: deepseek model: "deepseek-coder"这样配置之后，treg run --model deep --prompt "..."会走 DeepSeek 的接口，treg run --model fast --prompt "..."会走 OpenRouter。你不需要改任何调用命令，只需要在配置里维护好 provider 和模型的映射关系。
这种设计的价值在于，当某个 provider 出问题（比如限流、宕机、涨价），你可以快速把模型别名指向另一个 provider，业务代码不用动。对于依赖 agent 的自动化流程，这种灵活性很重要。
5. 常见问题与排查技巧实录
5.1 安装与运行时报错速查表
我把实际使用中遇到的高频报错整理成表格，方便你快速定位问题。
| 报错信息 | 可能原因 | 排查步骤 | 解决方案 |
|---|---|---|---|
command not found: treg | npm 全局 bin 不在 PATH | npm config get prefix | 把 prefix/bin 加入 PATH |
unable to locate the codex cli binary | CLI 未安装或路径不对 | which codex | 重新安装或修正 PATH |
api_key_required | 密钥未设置或未读取 | echo $OPENROUTER_API_KEY | 设置环境变量并 source |
401 Unauthorized | 密钥无效或过期 | 用 curl 单独测试 | 重新生成密钥 |
400 maximum context length | 输入+输出超过模型上限 | 检查输入长度和 max_tokens | 减少输入或降低 max_tokens |
failed to connect to docker api | Docker 未启动或权限不足 | docker info | 启动 Docker 或加用户组 |
agent execution terminated due to error | 底层 CLI 执行失败 | 查看 treg 详细日志 | 根据日志定位具体原因 |
login failed. check api token | 认证信息错误 | 检查 token 和版本 | 重新登录或更新工具 |
这张表覆盖了大部分常见问题。遇到报错的时候，先看错误信息里的关键词，然后对照表格排查。大部分问题都是环境配置层面的，真正涉及模型本身的错误反而比较少。
5.2 密钥相关的坑与避坑技巧
密钥问题是我踩过最多的坑，这里单独展开讲。第一个坑是密钥泄露。有些人图方便，把密钥写在脚本里然后提交到公开仓库，结果被人扫到滥用。正确的做法是用环境变量，而且环境变量文件要加到.gitignore里。
第二个坑是密钥权限过大。OpenRouter 的密钥可以设置不同的权限范围，有些密钥只能调用特定模型，有些可以调用全部。如果你只是做测试，建议创建一个权限受限的密钥，降低风险。
第三个坑是密钥轮换。长期使用同一个密钥，一旦泄露影响很大。建议定期轮换，treg 的配置支持从环境变量读取，所以轮换的时候只需要更新环境变量，不用改配置文件。
第四个坑是多环境混淆。开发环境、测试环境、生产环境用不同的密钥，但有时候会搞混。我的做法是在 treg 配置里加一个环境标识，不同环境加载不同的配置文件：
export TREG_ENV=production treg run --model smart --prompt "..."treg 会根据TREG_ENV加载对应的配置，避免用错密钥。
5.3 模型调用超时与重试策略
Agent 任务经常涉及多轮调用，中间某一次超时或失败很常见。treg 的重试机制可以缓解这个问题，但配置不当也会带来新问题。我的经验是：重试次数不要设太多，3 次足够；重试间隔要递增，避免短时间内反复冲击同一个接口；对于非幂等的操作（比如写文件、发请求），重试要谨慎。
一个实用的重试配置：
defaults: timeout: 60 retries: 3 retry_backoff: 2retry_backoff: 2表示第一次重试等 2 秒，第二次等 4 秒，第三次等 8 秒。这种指数退避策略在大多数场景下够用。
如果某个模型经常超时，可能是模型本身响应慢，或者你的输入太长。先尝试减少输入，如果还是超时，考虑换一个更快的模型。treg 的模型别名机制让这种切换变得很容易。
5.4 输出质量不稳定的应对方法
用 agent 跑任务，输出质量不稳定是常态。同一个 prompt，有时候结果很好，有时候一塌糊涂。这不是 treg 的问题，而是模型本身的特性。我的应对方法有几个。
第一是加约束。在 prompt 里明确输出格式、长度、风格。比如“用 JSON 格式输出，不要有多余解释”“代码要包含注释和错误处理”。约束越具体，输出越稳定。
第二是分步执行。复杂任务拆成多个简单任务，每一步的输出作为下一步的输入。这样每步的 prompt 都更聚焦，模型不容易跑偏。
第三是加验证。对于关键任务，让 treg 生成结果后，再用另一个模型或者另一轮调用做检查。比如先生成代码，再让模型 review 一遍，找出潜在问题。
第四是保留上下文。多轮对话模式下，模型能看到之前的交互，输出会更连贯。treg 的 chat 模式就是为这种场景设计的。
提示：不要期望一次调用就得到完美结果。Agent 开发的本质是迭代，treg 只是让迭代更快，不改变迭代的必要性。
6. 进阶用法与生态扩展
6.1 把 treg 接入自动化工作流
treg 的 CLI 特性让它很容易接入自动化流程。比如你可以在 CI 里用 treg 做代码审查：
# 在 CI 脚本里 git diff HEAD~1 | treg run --model smart --prompt "审查这些代码变更，指出潜在问题" > review.md或者在定时任务里用 treg 做数据汇总：
# crontab 示例 0 9 * * * /usr/local/bin/treg run --model fast --prompt "汇总昨天的日志，生成日报" >> /var/log/daily.log这种用法的关键是输出要可解析。建议用--output json让 treg 返回结构化数据，方便后续处理。
6.2 与其他 CLI Agent 工具的协作
treg 不排斥其他 CLI 工具，反而可以和它们协作。比如你可以用 treg 做任务规划，用 codex cli 做代码执行：
# treg 生成计划 treg run --model smart --prompt "为这个需求生成一个实现计划" > plan.md # codex cli 执行计划 codex execute --plan plan.md这种分工模式让每个工具做自己擅长的事。treg 擅长路由和配置管理，codex cli 擅长代码执行，claude cli 擅长长文本分析。组合起来，能力比单一工具强很多。
6.3 从 treg 到自定义 agent 框架的演进路径
如果你用 treg 用久了，可能会想自己写一个更定制化的 agent 框架。这是很自然的演进路径。treg 的价值在于帮你快速验证想法，等你摸清了 agent 的调用模式、错误处理、上下文管理这些核心问题，再自己实现就不难了。
演进的时候可以保留 treg 的配置格式，把核心逻辑替换成自己的实现。这样迁移成本最低。也可以把 treg 当作一个参考实现，看它怎么处理密钥、怎么路由模型、怎么重试，然后在你自己的框架里借鉴这些设计。
热词里“agent 开发学习路线”“吴恩达 agent 教程”“agent 框架与编排”这些搜索，说明很多人正在系统学习 agent 开发。我的建议是，先用手头的工具（包括 treg）把东西跑起来，遇到问题再深入原理。纯看教程不动手，很难真正理解 agent 的运作方式。
7. 一些实际使用中的体会
treg 这类工具最大的价值不是技术有多复杂，而是它把一堆琐碎的配置工作收口了。在没有 treg 之前，我每次换模型都要翻文档、改环境变量、重启终端，一套流程下来十几分钟。有了 treg 之后，改一行配置就行。这种效率提升在长期使用中非常可观。
另一个体会是，密钥管理和错误处理是 agent 开发中最容易被低估的部分。很多人把精力放在 prompt 工程和模型选择上，结果被一个环境变量没设置卡半天。treg 在这方面的设计比较务实，它不追求功能大而全，而是把最常用的几个场景做扎实。
最后分享一个小技巧：如果你经常需要在多个项目之间切换，可以为每个项目建一个独立的 treg 配置文件，然后用TREG_CONFIG环境变量指定加载哪个。这样不同项目的模型配置、密钥、参数互不干扰，切换项目的时候只需要改一个环境变量。
export TREG_CONFIG=~/projects/myapp/.treg.yaml treg run --model smart --prompt "..."这个用法我在同时维护三四个 agent 项目的时候特别有用，推荐你也试试。
