作者注：Codex 和 WorkBuddy 都不是專爲 Claude 設計的客戶端，報錯幾乎都出在接入層。本文按「端點、工具往返、思考塊」三類，把報錯原文和修法一一對上。
我們自己就踩過這個坑。最開始圖省事，用 OpenAI 兼容協議調 Claude，也就是把它當成一個 OpenAI 模型來用。簡單對話沒有問題，但只要開始調用工具就報錯，重試也沒用。後來把協議換回 Anthropic 原生的 /v1/messages，才跑順。
先判斷你有沒有中招：Codex 一啓動就報 wire_api 相關錯誤，或者 WorkBuddy 能正常聊天、一調用工具就 400，又或者回復內容莫名其妙是空的，那基本就是本文說的情況。
- 模型本身沒壞，問題出在 接入層有三處對不上：端點、工具往返、思考塊。
- 最好修的是第 3 類（思考塊與輸出預算），只需要在客戶端改讀取方式和
max_tokens。 - 難度居中的是第 2 類（工具往返），主要靠翻譯層或網關來修正。
- 最費勁的是第 1 類（端點），只能換客戶端，或者加一層翻譯網關。
全文的結論順序是：原生 Anthropic 協議 > 網關翻譯成 anthropic > OpenAI 兼容 chat。今天可以先做一件事：用下文的對照表確認報錯屬於哪一類。
Codex、WorkBuddy 用 Claude 報錯的 3 類原因核心要點
先解釋幾個術語。Responses、Messages、Chat Completions 可以理解爲三種點菜方式：後廚做的菜一樣，只是菜單格式不同。Codex 只會用 Responses 點菜，Claude 只接 Messages 和 Chat Completions。thinking 塊相當於模型的草稿紙，Anthropic 會校驗這張草稿有沒有被人改過。
| 類別 | 一句話機制 | 主要由誰修 | 修復難度 |
|---|---|---|---|
| 第 1 類 端點對不上 | Codex 只發 Responses，Claude 不接這種格式 | 換工具或網關 | 最費勁 |
| 第 2 類 工具往返對不上 | 翻譯過程中 id、內容塊或思考塊被改動 | 網關爲主 | 中等 |
| 第 3 類 思考塊與預算對不上 | 模型每次都會思考，客戶端仍按老方式讀結果 | 客戶端 | 最省力 |
第 1 類：Codex 調用 Claude 時端點對不上
報錯長什麼樣：Error loading config.toml: wire_api = "chat" is no longer supported. How to fix: set wire_api = "responses".
這段話的意思是：配置裏 wire_api = "chat" 這種寫法已經不再支持，需要改成 responses。
爲什麼：按 Codex 官方配置參考，wire_api 現在只有 responses 一個取值。過去「把 wire_api 改成 chat 兜底」的做法已經失效，新版 Codex 會在加載配置時直接報錯。哪怕這個 provider 根本沒被用到，也會連帶 codex login status 一起跑不起來。另一邊，API易 apiyi.com 上的 Claude 型號只開放 anthropic 和 openai 兩種端點，不提供 /v1/responses。兩頭格式對不上，中間又沒有翻譯，報錯就是必然的。
怎麼修：
1. 客戶端：打開 ~/.codex/config.toml，按報錯提示刪除殘留的 chat 寫法，先讓 Codex 能正常啓動。
2. 換工具：如果只是想用 Claude 寫代碼，直接改用 Claude Code，它走的就是原生 Messages。
3. 網關：如果必須留在 Codex，就加一層能把 Responses 翻譯成 Messages 的網關。供應商地址優先填 Anthropic 原生端點。
驗收標準：codex login status 能正常執行；走網關時，下發一條需要讀文件的指令，Codex 能完整完成一次工具調用。
第 2 類：Claude 工具調用往返對不上
報錯長什麼樣：
– tool_use ids were found without tool_result blocks immediately after
– An assistant message with 'tool_calls' must be followed by tool messages...
– thinking or redacted_thinking blocks in the latest assistant message cannot be modified
– Invalid signature in thinking block. The block is bound to a different conversation.
第一條表示有 tool_use 沒有緊跟對應的 tool_result。第二條是 Chat 格式下的同類問題。第三條表示上一輪的思考塊被改動過。第四條表示思考塊簽名和當前會話對不上。
爲什麼：兼容層要把 Claude 的 text、tool_use、tool_result、thinking 這些內容塊逐塊翻譯成 tool_calls 和 role: tool，之後再翻譯回來。這個過程中只要 id 對錯、內容塊被合併、thinking 塊被挪動，就會返回 400。Responses 裏有 developer 角色，而 Messages 裏沒有，需要併入 system。另外，claude-opus-5-5 不接受以下老寫法：強制 tool_choice（any 或指定工具）、預填 assistant 消息（prefill）、temperature / top_p / top_k。
怎麼修：
1. 網關：每個 tool_use 後面緊跟同 id 的 tool_result，並且 tool_result 要放在 user 消息內容塊的最前面。
2. 網關：上一輪的 assistant 消息原樣回傳，thinking 字段爲空的塊也要帶上；developer 內容併入 system。
3. 客戶端：tool_choice 只保留 auto 或 none，刪掉 prefill 和採樣參數。
4. 客戶端：如果已經出現簽名錯誤，直接新開會話。按 API易 官方 FAQ 的說明，這類報錯有時會被包裝成 Request rejected (429)，但它並不是限流，退避重試也沒用。
5. 換工具：如果 harness 把強制 tool_choice 寫死了，自己改不了，那就換客戶端。
同類 400 的排查思路可以參考 Claude Code 報錯 400 tool use concurrency，這篇講的是 tool_use 與 tool_result 配對失敗時如何逐條定位。
驗收標準：連續多輪工具調用（讀文件、改文件、再讀文件）不再出現 400，同一會話裏也不再出現簽名錯誤。
第 3 類：Claude 思考塊與輸出預算對不上
報錯長什麼樣："thinking.type.enabled" is not supported for this model. Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior. 也可能是 "thinking.type.disabled" is not supported for this model. 還有一種情況不報錯，但回覆是空的或被截斷。
爲什麼：claude-opus-5-5 每次請求都會思考，響應可能以 thinking 塊開頭。客戶端如果按位置讀取 content[0].text，就會讀到空值。思考 token 按輸出計費，也會佔用 max_tokens。從這一代開始，工具調用之間的旁白也放進了 thinking 塊，而默認 display 是 omitted，所以看起來是空的。
怎麼修：
1. 客戶端：thinking 參數要麼省略，要麼寫 thinking: {"type": "adaptive"}，並刪掉 budget_tokens。
2. 客戶端：思考深度改用 output_config.effort 控制，可選 low / medium / high / xhigh / max，默認 medium。
3. 客戶端：讀取回復時按 type 找 text 塊，不要按位置取。
4. 客戶端：max_tokens 要同時覆蓋思考和正文；想看到旁白內容，就把 thinking.display 設爲 summarized。
想徹底理解這套新機制，可以看 解讀 Adaptive Thinking 自適應思考，它說明了 budget_tokens 應該怎麼遷移到 effort 檔位。
驗收標準：同一條提示連續發送幾次，正文都不爲空，也不再出現 thinking.type 相關報錯。
Claude 報錯原文速查對照表
| 報錯原文關鍵詞 | 屬於哪類 | 5 分鐘自檢動作 | 修完還報看哪篇 |
|---|---|---|---|
wire_api = "chat" is no longer supported |
第 1 類 | 檢查 config.toml 裏有沒有殘留的 chat 寫法 | Magpie 教程 |
tool_use ids were found without tool_result |
第 2 類 | 檢查 tool_result 的 id 和位置 | Claude Code 報錯 400 tool use concurrency |
must be followed by tool messages |
第 2 類 | 確認是否經過 Chat 兼容層 | Claude Code 報錯 400 tool use concurrency |
Invalid signature in thinking block |
第 2 類 | 新開會話再試 | 解讀 Adaptive Thinking 自適應思考 |
thinking.type.enabled / 回覆爲空 |
第 3 類 | 刪除 budget_tokens，改爲按 type 讀取 | 解讀 Adaptive Thinking 自適應思考 |
| 簡單對話能通，一調用工具就報錯 | 第 2 類 | 檢查 WorkBuddy 接入協議 | Workbuddy 支持 Claude 原生格式調用嗎 |
修復 Codex、WorkBuddy 調用 Claude 報錯的兩條路線
| 路線 | 適合誰 | 協議優先級 |
|---|---|---|
| A 回到原生客戶端 | 只想用 Claude 寫代碼 | 最高，沒有翻譯損耗 |
| B 加一層翻譯網關 | 必須留在 Codex 或 WorkBuddy | 其次，供應商地址填 anthropic |
| 長期停在 chat 兼容 | 不推薦 | 最低，工具調用和思考塊容易出問題 |
路線 A：在 Codex 裏想用 Claude，就改用 Claude Code。WorkBuddy 官方的模型配置只有 /chat/completions 和「自定義協議」開關，沒有 Anthropic 原生入口，所以在 WorkBuddy 裏別指望拿到原生 thinking。具體可以看 Workbuddy 支持 Claude 原生格式調用嗎，這篇解釋了爲什麼「對話能通、工具報錯」以及能怎麼繞過去。
WorkBuddy 直連的配置方法：進入「設置 → 模型 → 自定義」，Base URL 填 https://api.apiyi.com/v1，模型名填 claude-opus-5-5，Key 使用 API易 apiyi.com 令牌頁創建的那一把。URL 只寫到 /v1，不要自己拼上 /chat/completions。
圖注：重點看 URL 是否只寫到 /v1、模型名是否爲 claude-opus-5-5、「自定義協議」開關是否保持關閉。
路線 B：給 Codex 加網關時，Codex 這邊保持 wire_api = "responses" 不變，由網關把請求翻譯成 Messages 後轉發。WorkBuddy 的自定義模型 URL 指向本地網關，Claude 型號的供應商地址填 Anthropic 原生端點 https://api.apiyi.com。
🎯 技術建議：一個 Key 就能同時驗證原生 Messages 和兼容 chat 兩種端點。建議先在 API易 apiyi.com 用測試額度對比兩種協議下的工具調用效果，再決定走哪條路線。
用 Magpie 給 Codex、WorkBuddy 接 Claude
Magpie 是一個 MIT 協議的社區開源工具，它在本地 127.0.0.1:3425 起一個網關，能在 OpenAI Chat、Responses、Anthropic Messages 之間互相轉換，正好補上第 1 類的缺口。除了手動配置，也可以直接可視化在 Magpie 裏配置。圖形界面填好 API Key 和 Base URL，Codex、WorkBuddy 一起接到同一個網關，不用手改配置文件。完整步驟見 Magpie 教程，裏面講了如何用一個網關統一多個 Agent 的模型來源。
- 供應商頁：添加 Key。API易 在「中轉」分組裏，也可以點「+ 自定義供應商」手動填寫。
- Agent 頁：Codex、WorkBuddy 分別選擇 claude-opus-5-5。
- 新開一個會話，不要沿用舊會話的歷史。
圖注：重點看供應商是否在「中轉」組裏顯示爲可用、Base URL 是否爲 Anthropic 原生地址、Agent 頁兩個開關是否都已打開。
Claude 調用價格與緩存成本
以下價格單位爲美元 / 百萬 tokens，查於 2026-10-28，型號與價格以平臺型號列表爲準：
| 型號 | 輸入 | 輸出 | 緩存讀 | 可用平臺 |
|---|---|---|---|---|
| claude-opus-5-5 | $4 | $20 | $0.2 | API易 apiyi.com |
| claude-sonnet-5-5 | $2 | $10 | $0.1 | API易 apiyi.com |
| claude-haiku-5-5 | $0.1 | $0.5 | $0.01 | API易 apiyi.com |
Agent 每一輪都會重發完整歷史，所以 claude-opus-5-5 的思考 token 按輸出價計費。翻譯層一旦把 system、tools 或前綴的順序打亂，cache_control 斷點就會失效，成本和延遲會同時上升。如果命中率異常，可以看 Claude 緩存命中率掉到 0（diagnostics），這篇講了如何定位斷點失效的原因。
風險與封號自負
Magpie 等網關屬於社區開源工具，不是 API易 的官方組件，我們不做背書，也不提供技術支持。通過這類工具轉發請求，可能會被目標服務限流甚至封號，相關後果由使用者自行承擔。建議先用測試賬號把整條鏈路跑通，確認沒問題後再考慮放到正式賬號上。
這幾種情況別折騰
如果你只是偶爾在 Codex 裏用一次 Claude，或者公司環境不允許安裝額外軟件，又或者你本來就只需要跑 Claude，那就沒必要搭網關。直接換客戶端（改用 Claude Code），或者在 Codex 裏換成原生支持 Responses 的模型，會省事得多。
常見問題 FAQ
Q1：Codex 官方支持 Claude 嗎？
不支持。Codex 只走 Responses，Claude 不提供這種端點，必須經過翻譯層才能用。
Q2：在 API易 上的 Claude 能走 /v1/responses 嗎？
不能。API易 apiyi.com 上的 Claude 型號只開放 anthropic 和 openai 兩種端點。
Q3：報 429 是不是被限流了？
如果報錯內容裏帶 `Invalid signature in thinking block`，那不是限流，而是思考塊簽名校驗失敗，新開會話即可。
Q4：WorkBuddy 能用 Anthropic 原生協議嗎？
官方配置裏沒有 Anthropic 原生入口，只能走 OpenAI 兼容路線，或者經過網關轉換。
Q5：怎麼快速驗證修好了？
用 API易 apiyi.com 的測試額度新開一個會話，連續跑幾輪工具調用，同時確認正文不爲空。
Codex、WorkBuddy 用 Claude 報錯自查清單
- Codex 配置裏已經沒有任何 chat 寫法。
- Claude 請求走的是原生協議或翻譯成 anthropic 的網關，而不是 chat 兼容。
- 每個 tool_use 都有同 id 的 tool_result 緊隨其後。
- 上一輪的 thinking 塊原樣回傳，沒有被改動。
- 沒有使用強制 tool_choice、prefill 或採樣參數。
- 回覆按 type 讀取，並且
max_tokens已爲思考預留空間。
總結
Codex、WorkBuddy 用 Claude 報錯，基本都能歸入端點、工具往返、思考塊這三類。修復順序是：先改客戶端讀取方式，再修翻譯層，最後考慮換客戶端或加網關。協議選擇上，能用原生 Anthropic 就用原生，用不了再讓網關翻譯成 anthropic，不要長期停留在 chat 兼容上。推薦通過 API易 apiyi.com 用同一個 Key 對比不同協議的效果。
📚 參考資料
- Codex 配置參考：wire_api 的取值說明
- 鏈接：
developers.openai.com/codex/config-reference - 說明：確認 wire_api 當前只支持 responses
- Codex 配置加載報錯實例
- 鏈接：
github.com/openai/codex/issues/41816 - 說明：wire_api 報錯的原文出處
- Claude Opus 5.5 遷移指南
- 鏈接：
platform.claude.com/docs/en/models/opus-5-5/migration-guide - 說明：thinking、tool_choice、採樣參數的硬性限制
- Anthropic 工具調用排障
- 鏈接：
platform.claude.com/docs/en/agents-and-tools/tool-use/troubleshooting-tool-use - 說明：tool_use 與 tool_result 的配對規則
- WorkBuddy 模型配置
- 鏈接：
www.workbuddy.ai/docs/zh/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/Model - 說明：自定義模型入口與自定義協議開關
- Magpie 倉庫
- 鏈接：
github.com/yetone/magpie - 說明：社區開源網關，使用前請自行評估風險
作者：APIYI 技術團隊
技術交流：歡迎在 API易 apiyi.com 首頁聯繫我們，更多資料可訪問 docs.apiyi.com 文檔中心
