設定頁面上，位址填了、金鑰貼了、模型 ID 也對過了，只剩下一個下拉選單：OpenAI Chat Completions、OpenAI Responses、Anthropic Messages。旁邊沒有任何說明文字。

我把三個依序試了一輪，下面是當天的操作順序，以及每一步留下的狀態碼。先講結論：多數情況選第一個；對方只給 Claude 那扇門，選第三個；第二個要等你能說清楚「它到底裝了什麼」。

截圖取自 2026 年 10 月的介面，圖中不含金鑰。

第一輪：選第一個，先讓它回一句話

選 OpenAI Chat Completions，送一句「只回覆 OK」。回 200，有回應。這一步同時證明四件事：位址對、金鑰對、模型 ID 對、欄位也對。

接著我把系統提示放在最上層的 system 欄位，也就是 Anthropic 那套寫法，再送一次。還是 200。但回答裡看不出任何遵守系統提示的跡象。

這裡學到第一件事：200 只代表請求沒被拒絕，不代表欄位被用上了。 之後每次換通訊協定，我都會先問一句：這個欄位是被接受，還是被執行？

第二輪：換第二個，測它記不記得

Responses 的賣點是服務端可以保留對話。我分兩步送：第一步請它記住一個詞，第二步帶上 previous_response_id，問它剛才記了什麼。

第二步的回答，跟完全不帶這個參數的對照組幾乎一樣——它不記得。回應裡 store 有回傳、previous_response_id 也有回傳，欄位都在，行為沒有。

第二件事：欄位被回傳，不等於功能存在。 對第三方服務尤其要留意，因為轉發欄位比實作功能容易太多。

第三輪：換第三個，撞上 401

換成 Anthropic Messages，我把金鑰改放到 x-api-key 標頭，結果回 401，訊息是「未提供令牌」。

原因不是金鑰錯，是我打錯門：那次送的是 OpenAI 式端點，它只認 Authorization: Bearer。把標頭改回來，200。

反過來也試了：這個服務的 Messages 端點同時接受 x-api-key 與 Bearer 兩種寫法；而 OpenAI 式端點只收 Bearer，另一種直接 401。同一把金鑰，換一個標頭就從通到不通，這是照抄別家教學最容易出錯的地方。

另外，官方要求 Messages 的 max_tokens 必填，這個服務不填也回 200。寬鬆是好事，但代表「文件怎麼寫」和「這家怎麼做」是兩件事。

第四輪：故意寫錯，看 404 長什麼樣

把模型 ID 改成不存在的字串，回 404。再把路徑改成不存在的位址，也回 404。兩個都是 404，內容卻不一樣：

• 路徑錯：Invalid endpoint path
• 模型錯：model_not_found，還會指出是哪一個模型

第三件事：404 有兩種。 看到 404 先讀內容，別急著改通訊協定。

順帶一個不用金鑰就能做的方法：空著請求內容去敲端點，回 401 代表門在、只是沒給鑰匙；回 404 代表這條路不存在。

三個問題，決定選哪個

1. 我填的位址背後是哪一家服務？官方、第三方，還是公司自建？
2. 它的文件寫了哪些端點？寫 /chat/completions 是一個答案，只寫 /messages 是另一個。
3. 這次只要對話，還是要對話延續、上網搜尋、接 Claude 系列工具？

我平常使用的是 Crazyrouter：一把金鑰可以呼叫不同廠商的模型，OpenAI 相容與 Anthropic 相容的入口分開提供，正好可以用上面三個問題對一遍。

學到什麼

表面上是通訊協定選錯，實際上是四件事要分開：位址決定送到哪、金鑰決定能不能進、通訊協定決定怎麼送、模型 ID 決定找誰。 四者混在一起排查，就會一直原地打轉。

下次的檢查順序我會這樣走：先用一個不存在的路徑確認路由，再看狀態碼是 401 還是 404，最後才回頭看欄位。順序反過來，就會卡在欄位上出不去。

還有一句值得記著：第三方服務就算收下 store 與 previous_response_id，也不代表它真的記住了上下文——這件事要自己驗過才算數。

參考資料

• OpenAI API 文件：Chat Completions 與 Responses 的欄位定義
• Anthropic Messages API：請求標頭、system 欄位與工具區塊寫法
• DeepSeek Harness 官網：用戶端下載與模型設定入口
• Crazyrouter 文件：OpenAI 相容與 Anthropic 相容兩類接入方式