DeepSeek Thinking模式报错？Tool Choice不兼容问题排查与解决

最近在搞AI开发调试的时候，不少朋友（包括我自己）都遇到了同一个让人头秃的问题：正在跑得好好的DeepSeek模型，突然就开始罢工了。

特别是当我们试图通过OpenAI兼容接口调用Deepseek-v4-flash这类模型，并使用Function Calling（函数调用）或者Tool（工具）功能时，系统毫不留情地甩出一个400错误：

Error from provider (DeepSeek): Thinking mode does not support this tool_choice

API 返回的 400 错误信息截图

这究竟是啥情况？是DeepSeek官方接口炸了，还是我们姿势不对？今天就来扒一扒背后的原因，顺便给出几个临时的解决方案。

一、 问题复现：你是“中招”了吗？

这个bug通常发生在你需要AI模型执行特定工具的场景下。比如，你给AI定义了一个获取当前时间戳的工具 verify_tool，并在请求参数里设置了 "toolChoice": "required"（意思就是强制AI必须调用这个工具）。

包含 toolChoice 参数的请求代码示例

你的请求体大概长这样：

{
  "apiType": "openai-compatible",
  "baseUrl": "https://opencode.ai/zen/go",
  "modelId": "deepseek-v4-flash",
  "prompt": "Call the verify_tool tool once. Reply with a short sentence that includes the returned time.",
  "tool": {
    "name": "verify_tool",
    "description": "Return a timestamp string.",
    "inputSchema": {"type": "object", "properties": {}}
  },
  "toolChoice": "required"
}

结果接口直接返回 HTTP 400，提示刚才那个 Thinking mode 不支持 tool_choice。甚至有开发者反馈，这还会导致原本正常工作的Claude通过DeepSeek代理时也跟着出问题。

二、 根本原因：思考模式太“傲娇”了？

经过多方排查，这个问题的核心在于DeepSeek新引入的 “Thinking Mode”（思考模式）。

简单来说，DeepSeek为了提升推理质量，让模型在输出最终答案前先进行一段内部的“深度思考”。然而，目前的实现逻辑中，思考模式与强制工具选择（tool_choice: required）存在底层冲突。

当模型进入思考状态时，它的主要算力和逻辑是在构建推理链，这时候如果强行要求它“必须调用工具”，模型的内部机制可能无法在思考阶段正确响应这个强制指令，从而触发校验异常，直接报错。

这有点像你逼着一个正在冥想的大师立马去给你搬砖，大师当然会拒绝（报错），因为它现在的状态（Thinking Mode）不兼容这个指令（Tool Choice）。

三、 解决方案：怎么绕过这个坑？

既然知道了原因，我们就有几种办法来绕过这个限制，继续推进开发。

1. 切换模型ID（最快办法）

如果你使用的是带有“Thinking”属性的模型版本（比如某些特定命名的V4版本），尝试切换回 非思考模式 的标准模型。

例如，将 modelId 从 deepseek-v4-flash 修改为标准的 deepseek-chat 或者其他非thinking版本的标识。标准模型对工具调用的兼容性是最稳定的，虽然可能在某些深度推理上不如v4强悍，但至少不会报错。

2. 调整 tool_choice 参数

如果你必须使用这个模型版本，那么只能对参数动刀了。

• 移除强制调用：将 "toolChoice": "required" 改为 "toolChoice": "auto"，或者干脆不传这个参数。让模型自己决定是否需要调用工具。虽然这不能保证每次都调用，但在需要工具的时候，模型正常情况下还是会调用的。
• 改为 optional：如果SDK支持，设置成可选模式，避免硬性冲突。

3. 检查中间件/代理层配置

像OpenCode这类聚合平台，有时候会透传或者封装参数。检查一下你使用的BaseUrl（如opencode.ai）是否在最近的更新中修改了针对DeepSeek的默认行为。有时候，在代理层关闭默认的Thinking模式透传，也能解决问题。

四、 写在最后

这次报错确实是个比较新的“坑”，主要是DeepSeek在推进其CoT（Chain of Thought）技术时，工具调用的兼容性没跟上迭代速度导致的。

如果你急着交付项目，建议先用方案1切回稳定版模型；如果是为了测试最新的推理能力，那就只能通过方案2调整Prompt和参数来适配模型当前的“脾气”了。

希望这篇排查能帮你少掉几根头发，如果还有其他奇怪的报错，欢迎留言交流！