[langchain-deepseek] Missing `reasoning_content` in request payload when using deepseek-reasoner with tool calling

快速结论：该报错发生在使用 deepseek-reasoner 模型并开启工具调用（tool calling）时，多轮对话的第二轮请求会因缺少 reasoning_content 字段而返回 400 错误。优先排查你使用的 langchain-deepseek 版本是否已包含修复此问题的补丁。

适用环境：LangChain 生态中的 langchain-deepseek 包，DeepSeek 推理模型 deepseek-reasoner，Python 环境，带有工具绑定的 ChatDeepSeek 类。

最快修复方案：暂无确认的一步修复方案。Issue 中提到的修复 PR 有 #35620 和 #37065，但截至 Issue 关闭时尚未合并。可优先尝试升级 langchain-deepseek 到包含上述修复的最新版本，或参考 Issue 中的修复思路自行在本地应用补丁。

注意事项：Issue 中的修复方案尚未正式合并到主线，自行打补丁需要评估维护成本；且修复涉及请求发送和响应接收两端的字段处理，修改不当可能影响其他模型的兼容性。

问题场景

用户在使用 ChatDeepSeek 且模型指定为 deepseek-reasoner 时，通过 bind_tools() 绑定工具后进行多轮对话。第一轮调用能正常返回包含 reasoning_content 的回复，但当将第一轮的 AIMessage 和 ToolMessage 追加到消息列表并发起第二轮调用时，DeepSeek API 返回 400 错误，提示缺少 reasoning_content 字段。

报错原文

Error code: 400 - {'error': {'message': 'Missing `reasoning_content` field in the assistant message at message index 1. For more information, please refer to https://api-docs.deepseek.com/guides/thinking_with_tools', 'type': 'invalid_request_error', 'param': None, 'code': 'invalid_request_error'}}

原因分析

根据 Issue 中的分析和修复提案，可能原因如下：

DeepSeek 推理模型要求每个 assistant 消息都必须包含 reasoning_content 字段（即使为空字符串）。然而，langchain-deepseek 中的 ChatDeepSeek._get_request_payload() 方法在构造发送给 API 的请求载荷时，没有将之前响应中存储的 reasoning_content 重新注入到后续请求的 assistant 消息中。底层 BaseChatOpenAI._convert_message_to_dict() 并不认识这个 DeepSeek 特有的字段，导致该字段在请求发送时被静默丢弃。

此外，Issue 中也指出了流式（streaming）路径存在的同类问题：接收端 _convert_delta_to_message_chunk 和 _convert_dict_to_message 没有把 reasoning_content 捕获到 AIMessage.additional_kwargs 中，导致信息丢失。

环境排查

确认 langchain-deepseek 包版本，优先升级到最新版，检查是否已包含相关修复。
确认 DeepSeek API 文档中关于 thinking_with_tools 的字段要求：https://api-docs.deepseek.com/guides/thinking_with_tools
如果使用流式输出，额外检查流式路径是否丢失 reasoning_content。
确认是否为多轮对话中第二轮及以后的消息触发，单轮调用不受影响。

解决步骤

优先检查并升级 langchain-deepseek 至包含修复补丁的最新版本，查看 changelog 是否提及 reasoning_content 修复。
若官方版本未修复，可参考 Issue 中 PR #37065 的改动思路，在本地修改 ChatDeepSeek 的 _get_request_payload() 方法：遍历消息列表，为每个 assistant 消息补充 reasoning_content 字段，优先从原始消息的 additional_kwargs 中提取，缺失时置为空字符串。
如果同时使用流式输出，还需检查 _convert_delta_to_message_chunk 和 _convert_dict_to_message 是否能正确保留 reasoning_content 到 additional_kwargs。
验证修复时，建议运行 Issue 中提供的完整复现脚本，确认第二轮调用不再报 400 错误。
若无法自行修改源码，可考虑暂时关闭工具调用功能，或改用非推理模型（如 deepseek-chat）规避该问题。

验证方法

运行 Issue 中的复现代码，确认第二轮 llm_with_tools.invoke(messages) 能正常返回结果而不抛出 400 错误；同时检查第二轮返回的 response2.additional_kwargs 是否包含 reasoning_content 字段，确保字段在对话链路中完整保留。