把又一個 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，然後確認配置仍然生效。
- 把每個工具能用的那套寫法記錄下來，思路與金鑰輪換檢查清單相同，免得下一個人重新去發現那個字首、那個結尾斜槓或那個設定檔案。
- 把“端點已驗證”放在記錄的最前面：當某個東西不再工作時，最快的路徑仍然是在改任何工具之前先證明端點可用。