ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

Oh-My-Pi (omp) 配 TaoToken:models.yml 的 Base URL 统一指向一处

Oh-My-Pi (omp) 配 TaoToken:models.yml 的 Base URL 统一指向一处 ~/.omp/agent/models.yml 里 anthropic、openai、deepseek 各写一段 baseUrl切一次默认模型要改好几处这是 Oh-My-Piomp上手后最先乱掉的位置。TaoToken 在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 给出的兼容通道把这几条线收成一条所有 provider 的 baseUrl 指向同一个地址apiKey 复用同一把 Key而 omp 里的/models切换、omp --provider参数、settings.json 里的 defaultModel 一个字都不用改。下面按原文 3.1 到 3.3 的节奏把 auth.json 和 models.yml 两处改完再回头验证 omp 能不能正常起会话、这套凭证能不能被正确记账。1. 从 auth.json 到 models.ymlomp 的多供应商配置为什么越写越长1.1 原文 3.1 的样子每个 provider 一把自家 Key按原文的思路凭证文件 ~/.omp/agent/auth.json 是按 provider 名分组的每一组里放一个 type 和一个 key。你接了三家文件里就有三个 sk- 开头的字符串长得还各不相同{ anthropic: { type: api_key, key: YOUR_ANTHROPIC_KEY }, openai: { type: api_key, key: YOUR_OPENAI_KEY }, deepseek: { type: api_key, key: YOUR_DEEPSEEK_KEY } }这份文件本身没问题问题出在它的「维护成本」上。每家供应商的 Key 有各自的有效期、各自的额度口径、各自的失败提示你换一次主力模型就要先想清楚这次动的是哪一把 Key。更麻烦的是Key 一旦泄漏你只能去对应的那家控制台单独吊销剩下两把还在原地待命。1.2 原文 3.2 的样子baseUrl 跟着供应商走models.yml 是 omp 真正干活的配置。原文里每个 provider 都带自己的 baseUrl、api 协议字段、apiKey 引用和 models 列表形如providers: anthropic: baseUrl: https://api.anthropic.com api: anthropic-messages apiKey: YOUR_ANTHROPIC_KEY models: - id: claude-sonnet-4 name: Claude Sonnet 4 contextWindow: 200000 openai: baseUrl: https://api.openai.com/v1 api: openai-completions apiKey: YOUR_OPENAI_KEY deepseek: baseUrl: https://api.deepseek.com api: openai-completions apiKey: YOUR_DEEPSEEK_KEY这种写法的好处是直观谁家的模型走谁家的域名一眼就看明白。代价是每加一家供应商你就要多维护一组 baseUrl、多准备一把 Key、多记一个协议字段名。供应商数量一上来models.yml 会从二十行涨到一百多行其中真正有用的信息模型 id 和上下文长度反而被淹没。1.3 切一次模型要动的地方到底有几处假设你现在的默认是 anthropic 的 claude-sonnet-4想临时切到 deepseek 上的推理模型做一次长上下文分析。按原文的配置结构你至少要在三个地方保持一致auth.json 里有 deepseek 这组凭证、models.yml 里 deepseek 段的 apiKey 引用指向正确、settings.json 或者命令行里指定的 provider 名和 models.yml 的键名拼写完全一致。任何一处对不上omp 启动时不会给你一个温柔的提示而是直接报鉴权失败或者 provider 不存在。再往后一步是「对账」。三个控制台、三套用量报表、三种计费单位你想知道这个月在模型上花了多少得开三个页面手动加。真正让人烦的不是配置难写而是这些配置之间没有单一事实来源改一处另外两处靠记忆同步。下面要做的就是把这三处压成一处。2. 创建一把 Key把 auth.json 收敛成一份凭证2.1 打开官网创建 API Key先打开 TaoToken 完成注册然后在控制台里创建一把 API Key。创建完先别关页面复制出来的那串字符后面要同时填进 auth.json 和 models.yml所以建议先粘贴到一个临时文本里。同时顺手看一眼模型广场把你要用的几个模型 id 抄下来——不是所有模型都能叫 claude-sonnet-4 或 deepseek-v4-proid 拼错一个字符报错信息往往只说「模型不存在」排查起来很费时间。这一步对应原文「申请或复制各家 Key」的位置只是原来要开三个控制台、走三遍流程现在只走一遍。原文里chmod 600那一步依然要做因为凭证文件本质上还是凭证文件收敛成一把 Key 不代表它变得可以随便放。2.2 改写 ~/.omp/agent/auth.json新的 auth.json 结构不变还是 provider 名到{type, key}的映射但每个 provider 里的 key 都是同一串{ anthropic: { type: api_key, key: YOUR_API_KEY }, openai: { type: api_key, key: YOUR_API_KEY }, deepseek: { type: api_key, key: YOUR_API_KEY } }注意这里刻意保留了 anthropic / openai / deepseek 这几个键名。omp 在切换 provider 时会按这些名字去找凭证键名留着/models和--provider的体验就不会被打断。如果你习惯用环境变量方式注入也可以把这三个值都写成同一个环境变量名然后在 shell 里 export 一次效果等价。改完之后把权限收紧chmod 600 ~/.omp/agent/auth.json ls -l ~/.omp/agent/auth.json2.3 旧 Key 先备份再清理不建议直接在原文件上改。更稳妥的做法是先复制一份auth.json.bak确认新配置能跑通之后再删旧内容。原因很简单omp 的报错不会告诉你「是第几个 provider 的 Key 失效了」只会给一个模糊的鉴权失败。留着旧文件出问题的时候你能快速回滚到可用状态再慢慢对比差异。旧的那几把 Key 建议在各自控制台里吊销尤其是曾经写进过脚本、贴进过聊天窗口的那些。凭证收敛的意义不只是少改几处配置也包括出事时你只需要处理一把 Key而不是翻三个后台确认到底哪一把泄漏了。3. models.yml三家 provider 的 baseUrl 统一指向同一处3.1 保留什么、替换什么动手之前先列个清单。需要保留的字段provider 键名、models 列表里的 id / name / contextWindow / maxTokens、reasoning 这类模型特性标记。需要替换的字段只有一个每个 provider 下的 baseUrl全部改成https://taotoken.net/api。需要保持一致的字段是 apiKey三个 provider 引用同一把在官网创建的 Key。这里有个容易混的点官网落地页和接口地址不是一回事。注册、创建 Key、看模型广场、查用量走 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 而写进 models.yml 的 baseUrl 必须是https://taotoken.net/api末尾不要加/v1也不要带任何查询参数。这两者混用是新手最常见的翻车原因。3.2 可复制的 providers 段下面这段可以直接替换你 models.yml 里的 providers 部分只需要把 YOU_API_KEY 换成你自己创建的那把把模型 id 换成模型广场上真实存在的providers: anthropic: baseUrl: https://taotoken.net/api api: anthropic-messages apiKey: YOUR_API_KEY models: - id: claude-sonnet-4 name: Claude Sonnet 4 contextWindow: 200000 maxTokens: 8192 - id: claude-opus-4 name: Claude Opus 4 contextWindow: 200000 maxTokens: 16000 openai: baseUrl: https://taotoken.net/api api: openai-completions apiKey: YOUR_API_KEY models: - id: gpt-4o name: GPT-4o contextWindow: 128000 deepseek: baseUrl: https://taotoken.net/api api: openai-completions apiKey: YOUR_API_KEY models: - id: deepseek-v4-pro name: DeepSeek V4 Pro reasoning: true contextWindow: 1000000写完之后最直观的变化是三个 provider 的 baseUrl 一模一样apiKey 一模一样只有键名、协议字段和模型列表不同。你以后再也不会因为「哪个 provider 的域名记错了」而排查半天。3.3 api 字段怎么填anthropic-messages 还是 openai-completionsapi 字段决定 omp 用哪种请求格式跟上游对话这个字段不要因为 baseUrl 改了就去动它。原来 Anthropic 系用anthropic-messagesOpenAI 系和 DeepSeek 系用openai-completions改完 baseUrl 之后这两类的划分基本不变。判断依据不是「上游是谁家的」而是「这套模型走哪种风格的接口」模型广场上一般会标注照着填就行。如果你用的是本地 vLLM 那类自建服务它通常也是 openai-completions 风格这部分保持原样即可不需要为了统一而强行改协议字段。统一的是通道地址和凭证不是请求语义。3.4 模型 id 以模型广场为准原文里给出的模型 id 是当时的示例这种信息变化很快。稳妥的做法是每次加模型之前先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的模型广场搜一下确认 id 拼写、上下文窗口和是否支持推理参数再抄进 models.yml。凭记忆写 id 是这套配置里最便宜也最贵的错误——便宜在于改一行就好贵在于你可能花二十分钟怀疑是 Key 或 baseUrl 的问题。顺便说一句 contextWindow 和 maxTokens这两个值填错不会直接导致报错但会让 omp 的上下文压缩策略判断失误表现为长会话中途莫名其妙丢上下文。它们也应该跟模型广场上的标注保持一致。4. settings.json、/models与--provider保持原样4.1 defaultProvider / defaultModel / roles 不用改settings.json 里跟模型相关的主要是 defaultProvider、defaultModel 和 roles 三段。这三段写的是「用哪个 provider 的哪个模型」而 provider 键名和模型 id 都没变所以文件内容一行都不用动{ defaultProvider: anthropic, defaultModel: claude-sonnet-4, roles: { default: { model: claude-sonnet-4 }, plan: { model: claude-opus-4 } } }这点值得强调接入改造只发生在 auth.json 和 models.yml角色路由、技能目录、LSP 配置、压缩阈值这些全部保持原样。改动面越小回滚成本越低。4.2omp --provider与交互里的/models命令行启动仍然可以按 provider 指定omp --provider deepseek --model deepseek-v4-pro omp --provider anthropic --model claude-sonnet-4 omp --role plan进入交互界面后/models依旧列出 models.yml 里配好的那些模型切换逻辑走的是同一套 provider 键名。也就是说从使用者的角度看这次改造几乎是隐形的命令没变、快捷键没变、会话历史也没受影响变的只是「请求实际发到了哪里」。4.3 本地 vLLM 那一段要不要跟着改如果你的 models.yml 里还有 local 这类指向http://localhost:8000/v1的 provider可以保留不动。自建服务的地址本来就应该指向本机统一走兼容通道只针对那些需要外部凭证的商用模型。混着用完全没问题omp 不关心某个 provider 背后是真域名还是转发地址它只关心格式对不对。5. 验证发一条消息再回控制台对账5.1 启动前的三项自检改完文件之后先做三件事确认 auth.json 的权限是 600、确认 models.yml 的 YAML 缩进没被编辑器改成 tab、确认 baseUrl 末尾没有多出/v1或斜杠。YAML 对缩进敏感从网页复制的配置最容易在models:下面那一层出错而报错信息通常只会说解析失败不会告诉你具体哪一行。omp --version head -c 200 ~/.omp/agent/models.yml5.2 在会话里发一句话启动 omp随便让它做点轻量的事比如列一下当前目录的 Python 文件或者解释一段函数。关键不是任务有多难而是确认请求能发出去、能回得来、不报鉴权错误。如果这一步通过了可以在界面里用/models切到另一个 provider 再试一次验证三把「同一把 Key」的配置都通了。5.3 回控制台看这次调用有没有记上回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的用量面板确认刚才那两三次调用都在账上模型名和 provider 对得上。这一步是整套配置里最有价值的部分你终于只需要在一个页面里看所有模型的消耗而不是开三个控制台逐个对。如果用量里没有记录说明请求可能根本没走出去那就要回到 baseUrl 和 Key 上去查而不是怀疑模型本身。6. 改完 models.yml 后常见的几种报错6.1 baseUrl 末尾多写了 /v1这是最高频的一个。落地页的链接上出现过各种路径很多人顺手就把/v1也带进了 baseUrl。写进工具的地址固定是https://taotoken.net/api不带/v1不带查询参数。多一个后缀表现可能是 404也可能是路径拼接出错后的奇怪报错。6.2 apiKey 与 auth.json 的引用名对不上原配置里 apiKey 写的是环境变量名改造后有人把它换成了字面量 Key有人保持引用形式但忘了在 auth.json 里同步。两种方式都行但同一个文件里不要混着来。如果你选了引用形式记得让三个 provider 引用同一个名字如果选了字面量记得改 Key 的时候三处一起改——或者干脆只留一处这正是这次改造想解决的问题。6.3 401 与「模型不存在」401 一般指向凭证问题Key 拼错、Key 被吊销、或者 auth.json 权限不对导致读不到。模型不存在类的报错则指向 id 拼写尤其是带版本号和日期后缀的那些抄的时候容易漏字符。还有一种少见情况是 provider 键名在 models.yml 里改了但 settings.json 的 defaultProvider 没跟着改表现是启动时提示找不到默认 provider。这三类错误各自的排查方向完全不同先看清报错文本再动手比盲目改文件快得多。7. 跑通之后的下一步配置跑通之后建议先做一次端到端的对照用同一个任务分别跑一次原来最常用的模型和刚接入的另一个模型比一比响应速度和输出质量顺便在控制台确认两边都记上了账。想把这次接入的用法固定下来可以去 模型对话 用同一把 Key 发条测试消息确认模型 id 没抄错长期在终端里写代码的话可以看看 Coding Plan 的额度是否够用需要重新生成或管理 Key直接进 控制台 API Keys。如果后面你还想把这把 Key 用到别的终端工具上环境变量的对照写法可以参考 Claude Code 接入文档思路和 omp 这边是一致的地址统一填https://taotoken.net/api凭证统一用同一把 Key剩下的交给工具自己。
RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进