本文目录

用官方 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 上下文：