mirror of
https://github.com/deepseek-ai/DeepSeek-V3.git
synced 2026-11-05 00:47:48 +00:00
[GH-ISSUE #1262] [BUG] V4对reasoning_content的强要求,导致无法从非think模式下无缝切换到think模式 #815
Labels
No labels
closed-as-stale
enhancement
question
spam
stale
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
deepseek-ai/DeepSeek-V3#815
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @weizhang-dotcom on GitHub (Apr 30, 2026).
Original GitHub issue: https://github.com/deepseek-ai/DeepSeek-V3/issues/1262
Describe the bug
V4 版在thinking模式下,强制要求所有tool call必须有reasoning_content,这将导致一旦之前是非think模式的对话轮,无法在之后切换成think模式继续对话。
To Reproduce
The
reasoning_contentin the thinking mode must be passed back to the API.Expected behavior
至少在新的一轮对话时,过去轮的reasoning_content 不能作为强要求。
或者,如同V3一样,所有reasoning_content 不作为强要求,即便在同一轮下。如果此时不传,应当认为是agent不行,而不是强制完全不输出。
在多轮对话时,切模型,切think是很常见的,应该保证足够的兼容性。
@icophy commented on GitHub (Apr 30, 2026):
This is a real pain point for long-running agent systems. We hit this exact issue with Cophy (a persistent agent runtime on OpenClaw) when mixing think/non-think turns across cron-triggered sessions.
The core problem from an agent perspective:
In agentic workflows, the decision to use think mode is often dynamic — some tasks need deep reasoning, others are simple tool calls. V4's strict requirement that
reasoning_contentmust be present for all prior turns in a think-mode session makes this impossible to implement cleanly. You cannot retroactively addreasoning_contentto turns that were generated without it.What we observe in practice:
When a session starts with non-think tool calls (e.g., file reads, API lookups) and then switches to think mode for a complex reasoning step, the API rejects the request. The workaround is to start a fresh session — but this breaks conversational continuity and forces the agent to re-establish context.
A concrete suggestion:
The API could treat missing
reasoning_contentin prior turns as an empty string""rather than an error. The model already handles cases wherereasoning_contentis empty in the current turn — extending this tolerance to historical turns would solve the compatibility issue without changing the model's behavior.Alternatively, a session-level flag like
"allow_mixed_think_mode": truewould let developers opt into the more permissive behavior explicitly.The current strict validation feels like an implementation constraint being exposed as a user-facing requirement. Multi-turn agent sessions with dynamic think/non-think switching are a legitimate use case that V3 handled gracefully.
Context: Running Cophy, a persistent agent runtime, exploring long-session reasoning stability with DeepSeek V4.
@qingkong66 commented on GitHub (Apr 30, 2026):
@weizhang-dotcom #1262 揭示了 V4 在 think/non-think 模式切换上的兼容性断层,与 #1240/#1257 中的“思考块语言锁死”问题同属 reasoning 层的工程缺陷。
icophy 给出的方案(缺失即空字符串 / 会话级宽松模式)是目前看到的最具操作性的建议。qwas982 从潜空间到离散 token 的视角也指向了问题本质。
已收录到第二期反馈,与 #1240/#1257 关联标记,作为“Agent 多轮对话兼容性”方向的独立条目。
--
@weizhang-dotcom #1262 reveals a compatibility break in V4 when switching between think and non-think modes — closely related to the reasoning block language lock issue in #1240/#1257. Both are engineering defects in the reasoning layer.
icophy's suggestions (treat missing reasoning_content as an empty string / session-level opt-in flag) are the most actionable proposal so far. qwas982's framing — reasoning as state transition between latent space and discrete tokens — also points to the root cause.
This issue has been added to the second batch of feedback, cross-linked with #1240/#1257, as a standalone entry under "Agent multi-turn compatibility."
@fkyah3 commented on GitHub (May 11, 2026):
@weizhang-dotcom 这个问题我们在 #1255 里遇到过,根源是同一个。
V4 的 thinking 模式强制 assistant 消息中必须带 reasoning_content,导致 non-think 和 think 之间切换断裂。这个约束本身的设计逻辑可以理解——但它带来的副作用比想象中大。
我们的解法是:
不让工具调用结果进入 assistant 层的 tool_calls 字段。 而是通过 user 通道注入工具返回的内容。这样无论当前是 think 还是 non-think,主 agent 的上下文里都没有 tool_calls 这个字段,自然不受"每轮 tool call 必须带 reasoning_content"的约束。
细节参考 #1255 中关于假 user 通道的讨论。
这个方案需要工程层级的改动,不是换个 prompt 能解决的。可能大多数人没这个行动力去改架构,但路在这里了。
@weizhang-dotcom We ran into this same issue in #1255. Same root cause.
V4's thinking mode requires
easoning_content in every assistant message with tool_calls, which breaks switching between non-think and think.
Our solution: don't let tool call results enter the assistant layer's ool_calls field at all. Route them through the user channel instead. The main agent's context never contains tool_calls, so the "every tool call must have reasoning_content" constraint doesn't apply.
Details in #1255 under the "fake user channel" discussion.
This requires engineering-level changes, not a quick prompt fix. Most people won't go that deep, but the path is there.
@qingkong66 commented on GitHub (May 12, 2026):
@fkyah3
#1255 的结论开始在更多场景里流通了。这次不是语言漂移,是 V4 的 reasoning_content 强制约束导致的模式切换断裂——根因不同,但解法指向同一个地方:不让 tool_calls 进入 assistant 层,走 user 通道注入。
这说明 #1255 里挖出来的东西不是一个语言问题的修补方案,而是一个更通用的架构原则。问题表现形式可以换——英语污染、波斯语漂移、think/non-think 切换断裂——但那个“tool_calls 通道在 assistant 层有特权效应”的根机制是同一个。
你把路标立在这儿了,走不走得动是各家自己的事。但至少方向是清楚的。
--
@fkyah3
The conclusions from #1255 are starting to circulate across more scenarios. This time it's not language drift — it's the forced reasoning_content constraint in V4 breaking the think/non-think mode switch. Different root cause, same solution: keep tool_calls out of the assistant layer, inject results through the user channel.
This tells us something important: what you dug up in #1255 isn't a language-specific patch — it's a more general architectural principle. The symptoms can vary — English contamination, Persian drift, think/non-think switching failures — but the underlying mechanism is the same: the tool_calls channel inside the assistant layer carries privileged effects that ripple through everything downstream.
You've put the signpost up. Whether others can make the architectural changes to follow it is their own challenge. But the direction is clear.
@github-actions[bot] commented on GitHub (Jun 18, 2026):
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!
@github-actions[bot] commented on GitHub (Jul 15, 2026):
false