把又一个 agent 接到 OpenAI 兼容端点上，听起来每次都一样，而实际从来不是。OpenAI 兼容端点配置因工具而异，因为每个工具暴露的配置面不同：Gemini CLI 通过环境变量改端点，Aider 需要在环境变量之外再加一个模型名前缀，Cline 一切都走 GUI 的 provider 面板，而 Continue 用配置键覆盖各模型的默认值。本指南把这四个都接上，形式与最初的三工具实战相同：一个密钥、几个 agent，不靠猜。它也是早先那篇总纲文章的延伸，那篇文章讲的是最早一批进入测试的工具。
动手配置工具之前：先验证 OpenAI 兼容端点
有一步应当在任何工具配置之前完成：证明端点本身可用。用你的密钥发一个最小请求，再读回模型列表，这样在你开始改配置之前，“工具连不上”和“端点到不了”就已经被区分开。平台自己的文档涵盖了端点细节，包括用于 API 调用的 base URL 和模型列表端点。在企业网络中，还要先加一个前置条件：为 TLS 拦截准备自定义证书包，企业网络指南对 CLI 场景做了通用讲解。这两项检查做完之后，后面所有失败都属于工具配置问题，也就是本文的余下部分。
Gemini CLI：用环境变量指定自定义 base URL
在这四个工具中，Gemini CLI 最依赖环境变量。官方配置参考记录了你实际会碰到的三个变量：
GEMINI_API_KEY用于提供你的密钥。文档建议把它写进你的 shell 配置文件，比如~/.bashrc或~/.zshrc，或者放在一个.env文件里。GOOGLE_GEMINI_BASE_URL在使用 API key 认证时覆盖 Gemini API 请求的默认 base URL。文档要求它是合法 URL 且使用 HTTPS，除非指向 localhost。官方示例：export GOOGLE_GEMINI_BASE_URL="https://my-proxy.com"，或在 Windows PowerShell 中：$env:GOOGLE_GEMINI_BASE_URL="https://my-proxy.com"。GEMINI_MODEL设置默认模型，覆盖内置默认值，例如export GEMINI_MODEL="<model-name>"。
Gemini CLI 也支持走设置文件的路线：settings.json中的字符串可以用$VAR_NAME、${VAR_NAME}或${VAR_NAME:-DEFAULT_VALUE}语法引用环境变量，在加载设置时解析，因此像"apiKey": "$MY_API_TOKEN"这样的值可以让机密不落进文件本身。用户级文件位于~/.gemini/settings.json，而项目级的.gemini/settings.json会在该项目内覆盖它。综合起来看，这是四者中最干净的分工：密钥和模型用环境变量，端点用 base URL 覆盖，必要时再经由设置文件做一层间接引用。
Aider：OpenAI 兼容端点与 openai/ 前缀
Aider 通过两个标准环境变量连接，再加一个常被跳过的步骤。它的 OpenAI 兼容文档展示了配置方式：
# Mac/Linux
export OPENAI_API_BASE=<endpoint>
export OPENAI_API_KEY=<key>
# Windows
setx OPENAI_API_BASE <endpoint>
setx OPENAI_API_KEY <key>在 Windows 上，文档还提醒你在执行setx命令之后需要重启 shell。随后在启动 Aider 时，模型名要带一个openai/前缀：
cd /to/your/project
aider --model openai/<model-name>这个前缀是文档规定的方式，用来告诉 Aider：它在跟一个 OpenAI 兼容端点说话，而不是把模型名当成别的东西。它也正是会被悄悄漏掉的那一步：环境变量看起来已经齐了，端点对手动请求也有响应，而 Aider 仍像什么都没配一样，因为调用模型时没带前缀。文档还提到，Aider 在使用它不认识的模型时会发出警告，这对自定义端点是正常现象，不要误读成故障。
Cline：在 GUI 中选择 OpenAI Compatible provider
Cline 在这方面完全不用环境变量。在它的设置面板里， OpenAI Compatible provider 页面描述了三个要紧的设置：
- Base URL。文档明确说这里不能填
https://api.openai.com/v1，那是 OpenAI 官方 API 的 URL；这里必须是你所用提供商给你的端点。页面特别强调这是关键一步。 - API Key。来自你提供商的密钥。
- Model ID。你想使用的模型名称或标识符。
在面板里，你把 API provider 选为“OpenAI Compatible”，填入 Base URL，粘贴密钥，然后选择或输入 Model ID。文档中有一条提醒对任何兼容提供商都适用：不同服务可用的 model ID 不同，确切标识符的正确来源是你所用提供商自己的文档。这里没有配置文件要改，也没有 shell 要重启；整套配置都活在扩展的 UI 里，这也是它从不像环境变量类工具那样以相同方式失效的原因。如果你以前接过编辑器侧的工具，这个模式与 Cursor 实战形式相同，只是面板不同。
Continue：配置里的 apiBase 与 apiKey
Continue 是配置文件驱动的，其官方配置参考记录了兼容端点所需的两个键：
apiBase可以覆盖按模型指定的默认 API base。措辞很关键：这个覆盖是相对于各模型自身默认值的，所以不设置它，就意味着某些模型仍保留它们自己的 base。apiKey是随请求发送的键，参考文档说明它通过 Bearer 头传输。
实际配置看起来就是一个填好这些字段的 provider 条目，例如：
models:
- name: my-custom-model
provider: openai
apiBase: https://your-endpoint.example/v1
apiKey: YOUR_API_KEY
model: <model-name>这里的坑比其他几个更微妙：因为apiBase覆盖的是默认值而不是全局替换，只配置部分模型的团队最终会得到一个混合状态：一部分流量去了预期的位置，一部分没有。对你打算路由的每一个模型都显式设置该字段，才是干净的做法。
配置面横向对比
| 工具 | 端点配置 | 凭据 | 模型选择 | 常见陷阱 |
| --- | --- | --- | --- | --- |
| Gemini CLI |GOOGLE_GEMINI_BASE_URL环境变量 |GEMINI_API_KEY（shell 配置文件或.env） |GEMINI_MODEL变量 | 变量设在了 CLI 会话并不继承的那个 shell 里 |
| Aider |OPENAI_API_BASE环境变量 |OPENAI_API_KEY变量 |aider --model openai/<model-name>| 忘了加openai/前缀 |
| Cline | 设置面板：OpenAI Compatible provider、Base URL 字段 | API Key 字段 | Model ID 字段 | 填了 OpenAI 官方 URL 而不是提供商的 |
| Continue |apiBase配置键（覆盖各模型默认值） |apiKey配置键（Bearer 头） |model字段 | 让apiBase对某些模型保持未设置，于是它们保留默认 base |
四个工具，四个配置面：一个环境变量、一套前缀仪式、一个 GUI 面板、一对配置键。它们谁也不比谁更难，只是失效的方式不同。
它们共有的坑
这四者身上，大多数支持工单都出自同样的五个问题：
- 结尾的
/v1。兼容端点与工具在 base URL 是否包含版本段这一点上各有不同。当配置立刻失败时，先试另一种写法，再去怀疑别的东西，并记录下能用的那套配置用的是哪种写法。 - 模型名格式与模型列表。工具接受的名称应当与端点在模型列表中报告的一致。当工具允许自由输入模型名时，一个笔误表现出来就像连接问题。
- 只活在一个 shell 里的环境变量。在终端里导出的变量只对该会话生效。把它们持久化到工具实际运行时所用的那个 profile 里，或者写进工具自己的配置里，就像 Gemini CLI 的设置文件允许的那样。
- 机密漂进仓库。密钥应当待在占位符和环境变量里，绝不进入提交的文件或截图； CI 中的编程 agent 指南里的 CI 卫生模式原样适用于本地工具。
- 企业网络。拦截代理和私有证书颁发机构横在工具与端点之间；把证书当作前置条件处理，而不是调试时的意外，顺序与企业网络指南所述一致。
验证检查清单
- 在碰任何工具之前，用一次最小请求和一次模型列表确认端点。
- 按每个工具自己的配置面去配置：环境变量、前缀加环境变量、GUI 面板，或配置键。
- 在每个工具里跑一条最小命令，确认它完成了一次真实请求。
- 检查工具报告的模型与端点与你配置的一致。
- 重启工具和 shell，然后确认配置仍然生效。
- 把每个工具能用的那套写法记录下来，思路与密钥轮换检查清单相同，免得下一个人重新去发现那个前缀、那个结尾斜杠或那个设置文件。
- 把“端点已验证”放在记录的最前面：当某个东西不再工作时，最快的路径仍然是在改任何工具之前先证明端点可用。