base_url 的事这是整条线最该读懂的一篇。读完你会发现所谓「接中转」根本不是一项技能， 而是三个旋钮的事——而且后面每换一个工具（编辑器、常驻 agent、消息网关）， 拧的都是同样这三个。
本文写什么原理、三个旋钮、它做不到的事、你交出去了什么、怎么自己验。 本文不做任何中转服务之间的对比或排名，理由在第七节。 本文也不写我们自己连的是什么。
Claude Code、Codex、以及后面要讲的常驻 agent，在调用模型这件事上做的是同一件朴素的事： 往某个地址 POST 一段 JSON，等一段 JSON 回来。
这段请求里只有三样东西是「可变」的：
知道这一点，「中转」就没什么可神秘的了——它就是你把第一样换成了别的地址。 那个地址后面的服务收下请求、转给真正的模型、把结果转回来。
因为请求的形状是公开协议，不是哪家的私有格式。目前实际在用的主要是两系：
| 协议系 | 谁在用 | 说明 |
|---|---|---|
| OpenAI 系 | 大量服务声称「OpenAI 兼容」 | 内部还分 chat-completions 与 responses 两种线，不是一回事，见第四节 |
| Anthropic 系 | Claude 的消息接口 | Claude Code 走这一系 |
「兼容」的准确含义是：它接受同样形状的 JSON，返回同样形状的 JSON。 客户端并不知道、也不关心对面是谁——它只检查形状对不对。
它听起来像某种代理或绕行。实际上从客户端的角度看， 那就是一个正常的 API 端点，和官方端点在协议层面没有区别。 差别只在于：这个端点背后的服务，替你把请求送到了别处。
这张表是整条线的骨架。后面每一篇要接端点，都回来看这张表。
| 工具 | ① 地址 | ② key | ③ 模型 | 写在哪 |
|---|---|---|---|---|
| Claude Code | ANTHROPIC_BASE_URL | ANTHROPIC_AUTH_TOKEN 或 ANTHROPIC_API_KEY | ANTHROPIC_MODEL / 设置里的 model | 环境变量，或 settings.json 的 env 块 |
| Codex | base_url | env_key（指向某个环境变量） | 顶层 model | ~/.codex/config.toml 的 [model_providers.X] |
| Hermes | base_url | OPENAI_API_KEY | model | ~/.hermes/config.yaml，key 落 ~/.hermes/.env |
三个工具、三种文件格式，但概念完全一样。Hermes 甚至把这件事挑明了—— 它的文档说，每个模型槽位（主模型、辅助任务、压缩、兜底）用的都是同一组三个键。
具体每个工具怎么落地，在下一篇逐个走一遍。
OpenAI 系内部分 chat-completions 和 responses 两条线。
端点只支持前者、而客户端按后者发，结果通常不是干净的报错，
而是奇怪的字段错误、空回复、或者工具调用整个失灵。
Codex 把这件事做成了一个显式的键 wire_api，就是因为这个坑够常见。
接任何非官方端点，先确认它支持哪套协议。这比调别的参数都重要。
返回体里的模型名是对面写的字符串，客户端只是照单显示。 换句话说，「我配的是 A，界面显示 A」什么都证明不了。
怎么验见第六节。但先记住：这一层是靠信任撑着的，不是靠协议撑着的。
你和中转服务之间是一份新的关系，和原厂之间的关系并不因此消失或转移。 额度、条款、责任分别归谁，换端点这个动作一个字都没改。
这是最要紧的一条，单独一节讲。
agent 类工具的请求里装的不是一句问题，是一堆上下文： 它读过的源文件、目录结构、报错信息、你的项目记忆文件、你打的每一句话。
这些内容对中转服务是明文可见的。这不是缺陷，是转发这个动作的定义—— 它得看得懂请求才能转发。
正确的问法是：「我愿不愿意让这条链路上的每一方看到这些内容？」
一个可操作的分法——按活分路，而不是全都走同一条：
🟢 开源项目、公开文档、练手代码 → 走哪条都行
🟡 自己的私有项目 → 想清楚再选，至少知道对方是谁
🔴 公司代码、客户数据、含密钥的环境 → 先过合规，不是先过技术
顺带一提，这条判据对编辑器自带的「填自己的 key」同样适用—— 那条路也会改变数据处理的归属方。
| 验 | 怎么做 | 看什么 |
|---|---|---|
| 通不通 | 发一个最小请求（一句话、不带工具） | 能不能拿到形状正确的返回。先排除协议问题，再谈别的 |
| 工具调用行不行 | 让它做一件必须动工具的事（读个文件） | 很多端点「聊天能通、工具调用挂」，而这恰恰是 agent 的命根子 |
| 长上下文行不行 | 喂一个大文件 | 有的端点在长上下文上会截断或变慢，短请求测不出来 |
这是最常见的无效验证。模型对自己身份的自述本来就不可靠—— 它可能答错、可能答的是训练数据里的旧名字、可能被系统提示覆盖。 拿这个当证据，正反两个方向都会得出错误结论。
真要判断，只能靠能力侧写：拿几道你熟悉的、不同档次模型表现明显不同的任务 跑一遍，看行为像不像。这也不是铁证，但比问它自己强得多。
本站有一条写死的规矩：不宣称中立，就不必披露；一旦文章本身讲的就是这门生意的利益结构，就必须披露。
横评是最典型的「宣称中立」。而我们自己就在用其中一条链路—— 这种情况下做横评，无论排序结果如何都不干净。
所以做法是：这一篇给原理和判据，让你自己排； 下一篇给操作，并且如实说明我们自己那层用的是哪家。 事实层可以说，结论层不替你下。
ANTHROPIC_BASE_URL ·
ANTHROPIC_AUTH_TOKEN / ANTHROPIC_API_KEY · ANTHROPIC_MODEL，
可写进 settings.json 的 env 块。
Codex：~/.codex/config.toml 中 [model_providers.ID] 的
base_url / env_key / wire_api，顶层 model 与 model_provider。
Hermes：每个模型槽位统一三键 provider / model / base_url，
官方说明 base_url「指向自定义 OpenAI 兼容端点，使用 OPENAI_API_KEY 认证」。
三家官方文档，2026-08-21 核。wire_api 取值 responses 或 chat-completions，
这是「OpenAI 兼容」内部存在分线的直接证据。