Thinking mode does not support this tool_choice?

[gitking]

DeepSeek官方文档明明说了从v3开始，思考模式就支持工具调用了。为什么deepseek-v4-flash还不支持tool_choice? 如果不支持官方文档明确说明一下嘛，让我翻半天文档。

请求报文.json

返回报文.json

[weijiafu14]

先把归属说清楚，免得你在这个仓库里等一个它给不了的答案：Thinking mode does not support this tool_choice 是 DeepSeek API 那边返回的，所以"文档没写清楚"这半的收件人是 DeepSeek 的 API 文档团队，不是 DSH 这个仓库。这个抱怨我理解——文档说支持工具调用、却没说思考模式下 tool_choice 有限制，确实会让人白翻半天。

但在这个仓库里，有一个它确实该回答的问题：

是谁在发 tool_choice，我能不能让它别发？

先看你自己附的那份请求报文

你上传了 请求报文.json——答案就在里面。请确认两件事：

1. body 里有没有 tool_choice 这个字段？
2. 如果有，它的值是什么（"auto" / "none" / 还是一个指定函数的对象）？

这决定了这条该怎么提：

• 如果是 DSH/pi-ai 无条件带上的（哪怕值是 "auto"）→ 那这就是一个 DSH 侧的问题：它在一个不接受该字段的模式下发了这个字段，而配置面没有关掉它的开关；
• 如果是某个工具选择策略触发的（比如强制指定某个函数）→ 那问题变成"这个策略在思考模式下应当降级"。

把这两行贴到帖子里（tool_choice 那一行原文），比三张文档截图更能推动这件事——现在这帖的证据全部指向"官方文档没写"，而那不是这个仓库能改的。

这已经是同一类问题的第四例

"端点不接受 DSH 发的某个字段，而配置面无法表达"——这个形状最近连着出现：

帖	字段	处境
你这条	tool_choice（思考模式下）	待确认是谁发的
#2822	session_id 请求头	openai-responses 路由必发，拒绝下划线 header 名的网关直接 400，而 profile 的 headers 只能新增/覆盖值、无法移除 header 名
#4620	reasoning_content 重放	反过来——端点要求带、DSH 默认不带，有 compat 开关可打开
#4707	OpenRouter 的 provider body 字段	端点接受、DSH 的 compat 名单里没有，加不上

四条合起来说的是一件事：DSH 的 compat 机制设计是对的（协议感知、非法字段会 fail loud），但"能表达哪些字段"这份名单跟不上真实端点的多样性——加不上、去不掉、开不了关。 你这条如果确认是"去不掉"，正好补上 #2822 那一格的第二个实例。

今天能用的绕法

如果确认是 DSH 无条件发的、而你又急着用：在 DSH 和端点之间放一个本地透传器，转发前把 body 里的 tool_choice 删掉，DSH 那边把 baseURL 指到本地端口。

我们仓库里有个可以直接拿来改的（recording-proxy.mjs，独立单文件，拷走 node 直接跑，不需要装任何东西）——它本来是用来录请求体的（请求真发给上游、真实响应原样流回），改成"顺手删一个字段"就是转发前多一行。

性质说清：绕过，不是修复，而且多一跳。但它顺带能让你直接看到 DSH 到底发了什么——对你这个"到底是谁发的 tool_choice"的问题，这本身就是答案。

关于文档那半

如果你想推动 DeepSeek 把这条限制写进 API 文档，那要去他们的 API 文档/支持渠道提，这个仓库改不了。不过你这份材料（官方文档截图 + 请求报文 + 返回报文）已经是很完整的一份反馈了，换个地方提基本可以直接用。

边界与利益相关

我们不修 DSH 自家组件，也不是 DeepSeek API 的维护方。我没有下载你附的那两个 json，所以第一节是让你自己确认的两个问题，不是结论；这条最终属于哪一格，取决于 tool_choice 是谁放进去的。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销——上游模型不接受某个参数这件事，换任何插件都不会改变；第三节那个脚本是独立单文件，拷走就能跑。

[nokkies]

先说一个可能省你时间的结论：这个 tool_choice 不是 harness 发出去的。

我在整个仓库里搜了 tool_choice 和 toolChoice，除了 subagent-codex 的一个测试夹具之外没有任何出现。DeepSeek 适配器构造请求体的地方（packages/llm/llm-deepseek/src/serialize.ts）只放这些字段：

stream: true,
stream_options: { include_usage: true },
...tools !== undefined && tools.length > 0 ? { tools } : {},
...options.temperature !== undefined ? { temperature: options.temperature } : {},
...options.maxTokens === undefined ? {} : { max_tokens: options.maxTokens },

加上 messages / system 和模型名，就是全部。没有 tool_choice，也没有把任意字段透传到请求体的通道 —— 顺带一提，#4707 想要的正是这样一个「自定义 JSON body 字段」的能力，目前并不存在。

所以如果你抓到的请求报文里确实带了 tool_choice，它是在 harness 之外被加进去的：可能是你自己配置的代理/网关，可能是某个插件，也可能这次请求根本不是从 dsh 发出的。建议先确认那份报文是哪个进程发的 —— 如果是经过 one-api / new-api / LiteLLM 之类的中转，这些网关默认给 OpenAI 兼容请求补 tool_choice: "auto" 是很常见的行为，而这恰好会踩到思考模式的限制。

至于「文档说思考模式支持工具调用、却没说不支持 tool_choice」这一点，你说得对，这是文档该写清楚的：支持 tools 和支持 tool_choice 是两件事，前者是能不能用工具，后者是能不能强制/限定某次调用走哪个工具。这属于 API 与文档的问题，不是 harness 的行为，在这里报可能不会有人去改官方文档 —— 不过你把请求/返回报文都附上了，这对定位很有帮助。

如果确认是中转网关加的，通常可以在网关侧把这个参数去掉；如果确认是 dsh 直连发出的，那就是我上面看漏了，把那份 请求报文.json 里的完整 body 贴出来，我再看一遍。

[denial123789]

I added an English provider-boundary note to the reasoning replay guide: https://sandbaseai.github.io/deepseek-harness-handbook/pi-ai-cross-provider-reasoning-replay.html

The guide recommends capturing sanitized outbound JSON keys before changing DSH: a provider response such as Thinking mode does not support this tool_choice is not evidence that the Agent registry or plugin emitted that field. It keeps provider capability and Harness serialization as separate hypotheses.