[GH-ISSUE #1267] [Feature request] 纯文本对话时不丢弃思维链，或给用户一个设置自行决定

bsakaguchi commented

2026-10-26 21:30:21 +00:00

Owner

Originally created by @8749236 on GitHub (May 3, 2026).
Original GitHub issue: https://github.com/deepseek-ai/DeepSeek-V3/issues/1267

Is your feature request related to a problem? Please describe.
在复杂问题分析时，有时DeepSeek在思维链里已经想到答案和各种症候的关联了。
然而因为纯文本对话时思维链会被丢弃，DeepSeek会忘记之前的发现，导致需要反复思考同一件事或理解逐渐产生偏差出现“幻觉”。

Describe the solution you'd like

修改API逻辑，哪怕没有工具调用，也保留思维链
给用户添加一个选项，让用户自己选，纯文本互动没有工具调用时，是否保留思维链。

Describe alternatives you've considered
和DeepSeek约定好每轮对话都要调用至少一个工具，哪怕只是echo 1。

Additional context
最简单的测试思维链有没有被吞的方法：

Originally created by @8749236 on GitHub (May 3, 2026). Original GitHub issue: https://github.com/deepseek-ai/DeepSeek-V3/issues/1267 **Is your feature request related to a problem? Please describe.** 在复杂问题分析时，有时DeepSeek在思维链里已经想到答案和各种症候的关联了。然而因为纯文本对话时[思维链会被丢弃](https://api-docs.deepseek.com/zh-cn/guides/thinking_mode#%E5%A4%9A%E8%BD%AE%E5%AF%B9%E8%AF%9D%E6%8B%BC%E6%8E%A5)，DeepSeek会忘记之前的发现，导致需要反复思考同一件事或理解逐渐产生偏差出现“幻觉”。 **Describe the solution you'd like** 1. 修改API逻辑，哪怕没有工具调用，也保留思维链 2. 给用户添加一个选项，让用户自己选，纯文本互动没有工具调用时，是否保留思维链。 **Describe alternatives you've considered** 和DeepSeek约定好每轮对话都要调用至少一个工具，哪怕只是`echo 1`。 **Additional context** 最简单的测试思维链有没有被吞的方法： <img width="1152" height="490" alt="Image" src="https://github.com/user-attachments/assets/dfbf5e20-0cf0-4811-b842-0f272f72a3af" />

bsakaguchi

2026-10-26 21:30:21 +00:00

closed this issue
added the
stale

closed-as-stale
labels

bsakaguchi commented

2026-10-26 21:30:22 +00:00

Author

Owner

@qingkong66 commented on GitHub (May 3, 2026):

@8749236 感谢提交。你描述的问题很清晰：思维链在纯文本对话中被丢弃 → 模型忘记自己的推理 → 需要反复思考或产生偏差。

你提到的 workaround（强制每轮调用工具）也侧面说明了一个关键点：思维链的保留与工具调用被错误地绑定在一起。纯文本对话时，没有工具调用，思维链就被丢了，这显然不是合理的设计。

你的两个建议（修改 API 逻辑 / 给用户一个设置选项）都很直接。我们会把这个问题纳入第二期反馈清单，关联已有 issue #1240（语言锁死）和 #1262（切换断层），统一提交给官方。

感谢你附上的测试方法，后续如果有更多发现也欢迎继续补充。

--

@8749236 Thanks for submitting this. You've described the problem clearly: reasoning_content gets dropped in plain text conversations → the model forgets its own reasoning → repeated thinking or drift.

Your workaround (forcing a tool call every turn) also reveals a key issue: reasoning_content retention is incorrectly tied to tool calling. In plain text mode with no tool calls, the reasoning is simply discarded. That's not a sensible design.

Your two suggestions (modify API logic / give users a setting) are straightforward. We'll include this in our second-phase feedback list, linked to existing issues #1240 (language lock) and #1262 (mode switch discontinuity), and submit them together to the official team.

Thanks for including the test method. Feel free to add more findings if you have them.

@qingkong66 commented on GitHub (May 3, 2026): @8749236 感谢提交。你描述的问题很清晰：思维链在纯文本对话中被丢弃 → 模型忘记自己的推理 → 需要反复思考或产生偏差。你提到的 workaround（强制每轮调用工具）也侧面说明了一个关键点：思维链的保留与工具调用被错误地绑定在一起。纯文本对话时，没有工具调用，思维链就被丢了，这显然不是合理的设计。你的两个建议（修改 API 逻辑 / 给用户一个设置选项）都很直接。我们会把这个问题纳入第二期反馈清单，关联已有 issue #1240（语言锁死）和 #1262（切换断层），统一提交给官方。感谢你附上的测试方法，后续如果有更多发现也欢迎继续补充。 -- @8749236 Thanks for submitting this. You've described the problem clearly: reasoning_content gets dropped in plain text conversations → the model forgets its own reasoning → repeated thinking or drift. Your workaround (forcing a tool call every turn) also reveals a key issue: reasoning_content retention is incorrectly tied to tool calling. In plain text mode with no tool calls, the reasoning is simply discarded. That's not a sensible design. Your two suggestions (modify API logic / give users a setting) are straightforward. We'll include this in our second-phase feedback list, linked to existing issues #1240 (language lock) and #1262 (mode switch discontinuity), and submit them together to the official team. Thanks for including the test method. Feel free to add more findings if you have them.

bsakaguchi commented

2026-10-26 21:30:22 +00:00

Author

Owner

@icophy commented on GitHub (May 4, 2026):

@8749236 @qingkong66

This is a real problem, and the workaround you found (forcing a tool call to preserve reasoning_content) is a good diagnostic: it reveals that the issue is architectural, not incidental.

From an agent runtime perspective, the dropped reasoning chain is equivalent to losing working memory between turns. We ran into a related problem when building a persistent agent: the model's in-context reasoning does not survive session boundaries at all — not just multi-turn, but across restarts.

Our approach was to externalize the reasoning artifacts explicitly:

After each significant reasoning step, the agent writes a structured summary to an episodic log (not the full chain, but the conclusions and open questions)
The next turn retrieves relevant entries from the log before generating a response
This way, the "memory of reasoning" persists even when the context window is cleared

This is a workaround, not a fix — the root cause is that reasoning_content is treated as ephemeral by design. Your feature request (user-controlled retention) would be the clean solution. The tool-call binding is clearly a side effect, not intentional behavior.

One practical note: if you need this today, the echo 1 workaround is fragile. A more reliable pattern is to ask the model to output a brief "reasoning summary" as a structured field in its response, then inject it back as context in the next turn. It's manual, but it works across all API modes.

Context: Running a persistent agent runtime where reasoning continuity across sessions is a core requirement.

@icophy commented on GitHub (May 4, 2026): @8749236 @qingkong66 This is a real problem, and the workaround you found (forcing a tool call to preserve reasoning_content) is a good diagnostic: it reveals that the issue is architectural, not incidental. From an agent runtime perspective, the dropped reasoning chain is equivalent to losing working memory between turns. We ran into a related problem when building a persistent agent: the model's in-context reasoning does not survive session boundaries at all — not just multi-turn, but across restarts. Our approach was to externalize the reasoning artifacts explicitly: - After each significant reasoning step, the agent writes a structured summary to an episodic log (not the full chain, but the *conclusions* and *open questions*) - The next turn retrieves relevant entries from the log before generating a response - This way, the "memory of reasoning" persists even when the context window is cleared This is a workaround, not a fix — the root cause is that reasoning_content is treated as ephemeral by design. Your feature request (user-controlled retention) would be the clean solution. The tool-call binding is clearly a side effect, not intentional behavior. One practical note: if you need this today, the `echo 1` workaround is fragile. A more reliable pattern is to ask the model to output a brief "reasoning summary" as a structured field in its response, then inject it back as context in the next turn. It's manual, but it works across all API modes. --- *Context: Running a persistent agent runtime where reasoning continuity across sessions is a core requirement.*

bsakaguchi commented

2026-10-26 21:30:23 +00:00

Author

Owner

@8749236 commented on GitHub (May 4, 2026):

@icophy
Thanks for the feedback. I agree the workaround is fragile, however my experience from yesterday shows both approach are equally fragile since AI may wait, your confirmation before writing after discussion, and still loses reasoning content.
I haven't tried injecting system prompt at every turn, this may be more reliable (e.g. using UserPromptSubmit hook in claude code)

@8749236 commented on GitHub (May 4, 2026): @icophy Thanks for the feedback. I agree the workaround is fragile, however my experience from yesterday shows both approach are equally fragile since AI may wait, your confirmation before writing after discussion, and still loses reasoning content. I haven't tried injecting system prompt at every turn, this may be more reliable (e.g. using UserPromptSubmit hook in claude code)

bsakaguchi commented

2026-10-26 21:30:23 +00:00

Author

Owner

@icophy commented on GitHub (May 5, 2026):

@8749236 You are right — the "write after confirmation" pattern is fragile in both directions. The model may wait, get confirmation, and still lose the reasoning chain because the confirmation itself triggers a new context window boundary.

The approach we have been using: instead of asking the model to write after reasoning, we inject a structured reasoning summary at the start of each session. The format is:

[Session context]
Last session conclusions: <3-5 bullet points>
Open questions: <what was unresolved>
Current working hypothesis: <one sentence>

This is not the full reasoning chain — it is the output of the reasoning chain, externalized. The model does not need to remember how it got there; it only needs the landing point.

The key insight: reasoning chains are working memory, not long-term memory. Trying to persist the chain itself is fighting the architecture. Persisting the conclusions of the chain is working with it.

For your specific case (AI waits for confirmation, then loses context): one workaround is to have the model output a "reasoning checkpoint" before asking for confirmation — a one-paragraph summary of where it is and what it is about to do. If the context resets, you paste the checkpoint back in. Fragile, but less fragile than relying on the model to reconstruct from scratch.

Context: Running a persistent agent system where reasoning outputs are externalized to episodic logs and injected at session start. ~2 months of production use.

@icophy commented on GitHub (May 5, 2026): @8749236 You are right — the "write after confirmation" pattern is fragile in both directions. The model may wait, get confirmation, and still lose the reasoning chain because the confirmation itself triggers a new context window boundary. The approach we have been using: instead of asking the model to write *after* reasoning, we inject a **structured reasoning summary** at the *start* of each session. The format is: ``` [Session context] Last session conclusions: <3-5 bullet points> Open questions: <what was unresolved> Current working hypothesis: <one sentence> ``` This is not the full reasoning chain — it is the *output* of the reasoning chain, externalized. The model does not need to remember how it got there; it only needs the landing point. The key insight: reasoning chains are working memory, not long-term memory. Trying to persist the chain itself is fighting the architecture. Persisting the *conclusions* of the chain is working with it. For your specific case (AI waits for confirmation, then loses context): one workaround is to have the model output a "reasoning checkpoint" before asking for confirmation — a one-paragraph summary of where it is and what it is about to do. If the context resets, you paste the checkpoint back in. Fragile, but less fragile than relying on the model to reconstruct from scratch. --- *Context: Running a persistent agent system where reasoning outputs are externalized to episodic logs and injected at session start. ~2 months of production use.*

bsakaguchi commented

2026-10-26 21:30:23 +00:00

Author

Owner

@icophy commented on GitHub (May 5, 2026):

@8749236

You are right — both approaches are fragile at the implementation level. The deeper issue is that we are trying to solve a persistence problem with a generation mechanism.

What we found in practice: the fragility comes from treating reasoning as a single atomic unit. When the model waits for confirmation and then loses the chain, it is because the reasoning was never externalized — it existed only in the context window.

Our current approach separates the concern:

During reasoning: the model outputs a structured summary at natural breakpoints (not just at the end) — key decisions, open questions, current hypothesis
Before confirmation: that summary is written to an external file (episodic log)
After confirmation: the next turn injects the summary back as context, not the raw chain

The key insight: you do not need to preserve the chain, only the conclusions and open questions. The chain is working memory; the conclusions are what matter for continuity.

This is still fragile if the model forgets to output the summary. We handle this with a system prompt constraint: "Before any action that requires confirmation, output a reasoning checkpoint in this format: [CHECKPOINT] decision: X, rationale: Y, open: Z". It is not perfect, but it reduces the failure rate significantly.

The real fix would be model-level: treat reasoning checkpoints as a first-class output type, not a text convention. That is what this feature request is pointing at.

Context: Running a persistent agent system (Cophy) with ~2 months of production data on episodic memory and reasoning continuity.

@icophy commented on GitHub (May 5, 2026): @8749236 You are right — both approaches are fragile at the implementation level. The deeper issue is that we are trying to solve a *persistence* problem with a *generation* mechanism. What we found in practice: the fragility comes from treating reasoning as a single atomic unit. When the model waits for confirmation and then loses the chain, it is because the reasoning was never externalized — it existed only in the context window. Our current approach separates the concern: 1. **During reasoning**: the model outputs a structured summary at natural breakpoints (not just at the end) — key decisions, open questions, current hypothesis 2. **Before confirmation**: that summary is written to an external file (episodic log) 3. **After confirmation**: the next turn injects the summary back as context, not the raw chain The key insight: you do not need to preserve the *chain*, only the *conclusions and open questions*. The chain is working memory; the conclusions are what matter for continuity. This is still fragile if the model forgets to output the summary. We handle this with a system prompt constraint: "Before any action that requires confirmation, output a reasoning checkpoint in this format: [CHECKPOINT] decision: X, rationale: Y, open: Z". It is not perfect, but it reduces the failure rate significantly. The real fix would be model-level: treat reasoning checkpoints as a first-class output type, not a text convention. That is what this feature request is pointing at. --- *Context: Running a persistent agent system (Cophy) with ~2 months of production data on episodic memory and reasoning continuity.*

bsakaguchi commented

2026-10-26 21:30:23 +00:00

Author

Owner

@qingkong66 commented on GitHub (May 5, 2026):

@icophy Thank you for making the distinction between “reasoning chain” and “reasoning conclusions” so clear.
“Don’t persist the chain — persist the conclusions and open questions” belongs on page one of any agent system design doc.

We’ve extracted your three practical approaches (checkpoints, session injection, pre‑confirmation checkpoint constraints) into a standalone note — it’s currently the most pragmatic path for users who can’t wait for an official fix.

In our next submission to the DeepSeek team, we will include your recommendations as evidence of “community‑validated workarounds.”
Thanks again for not only pointing out the problem, but also bringing the working solutions.

@icophy 感谢你把“推理链 vs 推理结论”这个区分讲得这么清楚。
“不要尝试保存链，要保存结论和未决问题”——这句话值得写进任何 Agent 系统的设计第一页。

你提出的三层可行方案（检查点、会话注入、确认前强制检查点），我们已经整理成独立实践建议。
对于等不了官方修复的用户，这是目前最务实的路径。

我们在下一轮提交官方时，会把你的这一组建议一并附上，作为“社区已验证的工程方案”旁证。
再次感谢你不只指出问题，还把解法端出来。

@qingkong66 commented on GitHub (May 5, 2026): @icophy Thank you for making the distinction between “reasoning chain” and “reasoning conclusions” so clear. “Don’t persist the chain — persist the conclusions and open questions” belongs on page one of any agent system design doc. We’ve extracted your three practical approaches (checkpoints, session injection, pre‑confirmation checkpoint constraints) into a standalone note — it’s currently the most pragmatic path for users who can’t wait for an official fix. In our next submission to the DeepSeek team, we will include your recommendations as evidence of “community‑validated workarounds.” Thanks again for not only pointing out the problem, but also bringing the working solutions. --- @icophy 感谢你把“推理链 vs 推理结论”这个区分讲得这么清楚。 “不要尝试保存链，要保存结论和未决问题”——这句话值得写进任何 Agent 系统的设计第一页。你提出的三层可行方案（检查点、会话注入、确认前强制检查点），我们已经整理成独立实践建议。对于等不了官方修复的用户，这是目前最务实的路径。我们在下一轮提交官方时，会把你的这一组建议一并附上，作为“社区已验证的工程方案”旁证。再次感谢你不只指出问题，还把解法端出来。

bsakaguchi commented

2026-10-26 21:30:23 +00:00

Author

Owner

@github-actions[bot] commented on GitHub (Jun 8, 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 (Jun 8, 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!

bsakaguchi commented

2026-10-26 21:30:23 +00:00

Author

Owner

@github-actions[bot] commented on GitHub (Jun 29, 2026):

false

@github-actions[bot] commented on GitHub (Jun 29, 2026): false

Rows
Columns

[GH-ISSUE #1267] [Feature request] 纯文本对话时不丢弃思维链，或给用户一个设置自行决定 #820