本文目錄

用官方 DeepSeek API、開著思考模式又帶工具呼叫時，光禿禿的 400 往往更像歷史丟了，而不是工具 schema 寫錯。DeepSeek《Thinking Mode》指南寫得很清楚：請求帶 tools 時，必須在後續每一次請求裡完整回傳此前各輪的 reasoning_content。故意丟掉，或經只保留 content 的儲存、代理、序列化層弄丟，API 都會拒收。下文按北京時間 2026 年 10 月 26 日該指南整理。僅供參考；本站暫時還沒有實測復現，也沒有驗證修復。 關於 DeepSeek 工具呼叫 400 的回饋，可透過網站底部站長聯絡方式提交。

症狀：思考模式 + tools 時回 400

DeepSeek 的 Chat Completions 預設開啟思考模式。模型先輸出思維鏈，再給最終答案。這兩部分作為助手訊息上的同級欄位到達：reasoning_content 與 content。

一旦同時傳入 tools 陣列，DeepSeek 就要求對話歷史裡留住這段思維鏈。文件寫明：若程式碼沒有正確回傳 reasoning_content，API 會回傳 400。本文只談這一類失敗——不是鑑權失敗、不是限流，也不是把所有 400 一鍋端。

規則：回傳歷史全部 reasoning_content

凡請求攜帶 tools：

  • 回傳此前所有輪次的 reasoning_content。
  • 這些值會拼進模型上下文。
  • 即使某輪模型沒有發起工具呼叫，也必須在後續每一次請求裡繼續回傳。

官網範例裡最穩妥的預設寫法，是把 SDK 回傳的整條助手訊息物件直接追加：

python
messages.append(response.choices[0].message)

該物件已包含 content、reasoning_content、tool_calls。明示寫法等價於：

python
messages.append({
    "role": "assistant",
    "content": response.choices[0].message.content,
    "reasoning_content": response.choices[0].message.reasoning_content,
    "tool_calls": response.choices[0].message.tool_calls,
})

若自建歷史只按 role + content 重建助手訊息，就會默默丟掉 reasoning_content——下一輪帶 tools 的請求就可能直接 400。

請求不帶 tools 時

不帶 tools 時，規則反過來：

  • 不必回傳 reasoning_content。
  • 即便傳了，API 也會忽略，且不會拼進上下文。

因此從不掛工具的多輪對話可以只留 content，行為仍符合「多輪對話」一節。硬性要求從請求裡出現 tools 那一刻起才生效。

reasoning_content 常在哪裡被丟掉

訪客側常見剝欄位位置：

  • 客戶端訊息儲存只持久化 role 與 content，再拼下一輪歷史。
  • 代理／閘道只放行 OpenAI 形欄位，把 reasoning_content 當未知鍵丟掉。
  • 歷史庫／ORM 有 content 欄、沒有思維鏈欄。
  • 手寫 JSON 序列化抄了同輪的 tool_calls，卻漏了兄弟欄位 reasoning_content。

若在 SDK 回應與下一次請求之間還有自建層，請在追加工具結果、再打下一發 completion 的前後，確認該欄位還能完整走一圈。

這不是什麼

邊界說清楚，這篇才好用：

  • 不是 DeepSeek 上每一個 HTTP 400 都等於丟了 reasoning_content。 非法載荷、鑑權問題、其他校驗失敗也會 400。當思考模式與 tools 同時在場時，把它當成文件寫明的原因之一即可。
  • 不是 DeepSeek Harness 安裝教學。 安裝或接線 coding harness 是另一篇——見 DeepSeek Harness 安裝教學：Windows、Linux、CLI 與外掛。本文只談思考模式 + tools 的 API 歷史回傳規則。
  • 範圍是官方 DeepSeek API。 上文跟官方 Thinking Mode 文件；第三方中轉可能不同，請另查對方文件。

相關閱讀

站內相近的 DeepSeek／harness 上下文：