[Bug]DeepSeek V4 思考模式下 reasoning-only 截断导致 400

[lingyun14beta]

What happened / 发生了什么

使用 DeepSeek 推理模型（deepseek-v4-pro / deepseek-v4-flash，思考模式默认开启）进行多步工具调用对话时，
如果某一步生成因为撞到 max_tokens 限制被截断（finish_reason="length"），且该步模型只输出reasoning_content（思维链），没有输出 content（正文）也没有输出 tool_calls，AstrBot 会把这条「空壳」
assistant 消息（content 为空、tool_calls 为空）原样存入持久化对话历史。

由于本轮对话中此前已经发生过一次真实的工具调用（req.tool_calls_result 非空），_save_to_history 的判空保护（只检查 completion_text 和 tool_calls_result，未考虑 reasoning_content）被绕过，这条残缺消息被完整写入数据库。

下一轮用户再发消息时，AstrBot 会把这条历史消息一并带上发给 DeepSeek，DeepSeek 服务端校验
（assistant 消息要求 content 或 tool_calls 至少一个非空）失败，返回 400

与 #8482 同一现象

Reproduce / 如何复现？

1. 配置一个 DeepSeek 推理模型作为 Provider（deepseek-v4-pro 或 deepseek-v4-flash），保持思考模式为默认开启状态
2. 关闭"流式输出"
3. 在该 Provider 的 max_tokens 中设一个相对偏小的数值
4. 确保注册了至少一个可用的工具/插件
5. 发送一条需要"多步"工具调用才能完成的复杂指令
6. 观察日志：当 agent 达到 max_step 被强制收尾，且最后一步的 completion 显示 content=''、tool_calls=None、reasoning_content 非空、finish_reason='length' 时，说明已经复现出残缺消息（这一步本身不会报错，但已被写入持久化历史）。
7. 再发送任意一条后续消息。
8. 此时复现 400："Invalid assistant message: content or tool_calls must be set"，且主 provider 和 fallback provider 都会失败（污染源是历史消息本身，跟具体模型无关）。

AstrBot version, deployment method (e.g., Windows Docker Desktop deployment), provider used, and messaging platform used. / AstrBot 版本、部署方式（如 Windows Docker Desktop 部署）、使用的提供商、使用的消息平台适配器

v4.26.0-beta.12

OS

Windows

Logs / 报错日志

。

Are you willing to submit a PR? / 你愿意提交 PR 吗？

• Yes!

Code of Conduct

• I have read and agree to abide by the project's Code of Conduct。

[lingyun14beta]

@dosubot review

[dosubot]

我无法执行传统的代码审查（评估 PR/diff 的 bug、设计、性能等）。不过，我可以帮助你：

• 研究相关代码：查找 _save_to_history 的逻辑以及 reasoning_content 的处理方式
• 查找相关 issue/讨论：比如你提到的 [Bug]DeepSeek V4 API 在 无content + 无tool_calls + 有reasoning 时调用API会400报错 #8482 的处理方式
• 回答实现问题：关于如何修复这个 bug 的方案讨论

如果你需要以上任何帮助，请告诉我！

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[lingyun14beta]

@dosu 帮我看看分析的有没有错误

[dosubot]

你的分析是正确的，我验证了代码逻辑，确认了整个 bug 触发链路：

1. _save_to_history 的判空保护确实存在缺口 [1]

if (
    not llm_response.completion_text
    and not req.tool_calls_result
    and not user_aborted
):
    logger.debug("LLM 响应为空，不保存记录。")
    return

当本轮对话已经有过工具调用（req.tool_calls_result 非空）时，即使 completion_text 为空、tool_calls 为空，保护也会被绕过，reasoning-only 的残缺消息会被写入历史。

2. _sanitize_assistant_messages 也不会过滤掉这条消息 [2]

if _is_empty(content) and not tool_calls and not reasoning_content:
    continue

它只在三者全空时才移除，reasoning_content 非空时会保留这条消息。

3. DeepSeek API 校验失败：assistant 消息有 reasoning_content 但 content 和 tool_calls 都为空 → 400 [3]

与 #8482 的关系：两者是同一类问题。#8482 的 PR #8483 修改了 _sanitize_assistant_messages() 来保留 reasoning-only 消息，但并未处理"保留后 DeepSeek 依然拒绝"的根本矛盾 [4]。

建议修复方向：

• 方案 A：在 _save_to_history 增加对 reasoning-only 截断消息的检测，不写入历史（或标记为不完整）
• 方案 B：在 _sanitize_assistant_messages 或发送前的 payload 构建阶段，对于 DeepSeek V4 模型，如果 assistant 消息只有 reasoning_content 而无 content/tool_calls，则注入 content=""

两种方案可以结合使用，从源头和出口两端防御。你打算按哪个方向提 PR？

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[Soulter]

This issue has been fixed by #8483, and #8483 has already been merged. Please wait for the next release.