跑了二十輪好好的，突然開始 400 Bad Request — 你要找的是觸發條件，不是拼寫錯誤

跑著跑著開始 400，和第一次請求就 400，是兩個不同的問題。第 20 輪到第 21 輪之間，你的配置沒有變，變的是你的請求。再把配置讀一遍不會有任何發現，因為配置本來就沒錯。真正要做的是找出那一個元素——它把一個能透過的請求變成了被拒絕的請求。這件事有一套機械的做法，大約五分鐘。

你看到的報錯

API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages: roles must alternate between \"user\" and \"assistant\", but found multiple \"user\" roles in a row"}}

400 Bad Request

{"type":"error","error":{"type":"invalid_request_error","message":"messages.3: `tool_use` ids were found without `tool_result` blocks immediately after: toolu_xxxxxxxx. Each `tool_use` block must have a corresponding `tool_result` block in the next message."}}

{"type":"error","error":{"type":"invalid_request_error","message":"messages.4: `tool_result` block(s) provided when previous message does not contain any `tool_use` blocks"}}

四種都是 invalid_request_error。意思是請求送達了伺服器、被解析了、然後因為格式不對被拒絕——所以網路、憑證、模型名這三樣都是好的，否則你看到的會是另一個狀態碼。問題在你發出去的那個 body 裡面。

先把問題一分為二

本頁講的是右邊那一欄。如果你第一次請求就 400，那是普通的配置問題，最快的修法是拿請求體逐欄位對照端點文件裡的形狀。

觸發多輪 400 的三類條件

第 1 類和第 3 類在控制台里長得一模一樣——都只是 400。只有最小復現能把它們分開。而且，做出復現也是唯一能讓運營方接得住的報告方式。

按這個順序排查

# a) 不管你的客戶端把它的 verbose / debug 日誌叫什麼，開啟它，找到發出去的 body
#    存成 request.json

# b) 客戶端不肯給，就在前面掛一個記錄用的代理，然後把失敗那一輪重跑一次
export ANTHROPIC_BASE_URL=http://127.0.0.1:8080

jq '.messages | length' request.json      # 實際發出去多少條訊息
wc -c request.json                        # 這個 body 到底有多大

jq -r '.messages[] | "\(.role)\t\([.content[]?.type] | join(" "))"' request.json | tail -20

user      text
assistant text tool_use
user      tool_result
assistant text

# <模型 id>：從 https://api.9coding.com/v1/models 裡複製一個
curl -sS -w '\n%{http_code}\n' https://api.9coding.com/v1/messages \
  -H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"<模型 id>","max_tokens":16,"messages":[{"role":"user","content":"hi"}]}'

curl -sS -w '\n%{http_code}\n' https://api.9coding.com/v1/messages \
  -H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  --data-binary @request.json

jq '.messages |= .[-6:]' request.json > try-history.json

什麼時候這不是你的問題

如果第 4 步得到的最小復現已經很小了——一條普通訊息加宣告的工具，或者一輪工具呼叫，或者一張圖——它還是 400，那問題就不是形狀。是那個欄位的支援程度。

四分鐘的 curl，能換來一張任何文件都不會給你的支援矩陣。每一格都對你的端點實測一次，把結果寫下來：

一個端點可以接受基本的訊息形狀，同時在隔壁那一欄就不完整了——支援不是一個是非題，它是有顆粒度的。某一格掛了，你的排查就結束了：把最小的那份失敗 body 和狀態碼發給運營方。那是他們接得住的報告，也正是這份復現值得做出來的原因。

在認定它一直就是壞的之前，先看一眼運營方的狀態頁與變更日誌——昨天還能用、今天不能用的欄位，那是事故，不是限制。我們的在狀態頁。

提問題時請帶上 request id——9Coding 的報錯響應裡都有一個，形如 (request id: 2026...)。這個 id 加上時間戳、模型名和完整報錯文字，就能把那一次呼叫查出來。只說「用不了」的反饋沒法排查。

請求不合法，和對話漲過了視窗，不是同一個問題

400 invalid_request_error 表示你發出去的 body 本身不是一個合法的請求：訊息陣列裡有東西違反了規則，而刪多少歷史都不會讓那條規則被滿足。裝不下則正好相反——請求形狀完全沒問題，只是它太大了，所以裁剪就是全部的修法。分辨的抓手就一個：刪掉無關的舊訊息會不會有變化。會，你就走錯頁了，請看上下文超長。

相關報錯

• context length exceeded — 當它是大小問題，不是形狀問題
• 401 Unauthorized — 兩層認證，一條錯誤資訊
• 連線錯誤 — 分辨網路、代理與端點
• 429 Too Many Requests — 上游容量，以及重試到底在做什麼
• 全部報錯速查 — 排查手冊總表