1. 问题引入当推理内容成为“违禁品”最近在折腾 DeepSeek 的 API 时我遇到了一个挺有意思的坑。场景是这样的我需要实现一个复杂的多轮对话流程其中涉及到调用外部工具Tool-Calling并且希望模型在调用工具前能先进行一些“思考”把推理过程reasoning也返回给我方便我调试和记录。这听起来是个很合理的需求对吧毕竟 DeepSeek-V4 模型本身是支持reasoning_content这个参数的官方文档里也提到了可以在请求中开启推理痕迹。于是我按照常规思路构建了一个包含tools列表和reasoning参数的请求体信心满满地发了出去。结果迎头就是一盆冷水——服务器返回了一个400 Bad Request错误错误信息直指reasoning_content字段大意是“此字段不被允许”或“无效参数”。那一刻的感觉很微妙。不是 500 内部服务器错误也不是 429 限流而是一个明确的 400告诉你请求的格式有问题。但问题在于我的请求体明明是按照我认为正确的格式构建的。这让我意识到问题可能不在“我有没有这个字段”而在于“我在什么情况下、以什么方式提供了这个字段”。这个错误背后很可能隐藏着 API 设计上的一些边界条件或者尚未完全开放的“特性”。对于需要深度集成 AI 能力到生产环境的开发者来说这种看似简单的参数报错往往意味着工作流的中断和额外排查成本的增加。2. 核心矛盾Tool-Calling 与 Reasoning 的互斥性首先我们需要彻底理解reasoning_content和Tool-Calling这两个功能各自是什么以及为什么它们在一起会“打架”。2.1reasoning_content是什么reasoning_content是 DeepSeek 等新一代大模型提供的一个“思维链”Chain-of-Thought, CoT可视化功能。当你在请求中设置reasoning参数例如{reasoning: {type: enabled, content: reasoning_content}}模型在生成最终回复content之前会先将其内部的推理过程、思考步骤输出到一个单独的字段里。这个功能对于调试复杂问题、理解模型决策逻辑、甚至进行教学演示都极具价值。它让你不再是黑盒的输入端和输出端能窥见中间的计算“草稿纸”。2.2 Tool-Calling 的工作机制Tool-Calling或者说函数调用是大模型与外部世界交互的核心机制。你预先定义好工具函数的规格名称、描述、参数 schema模型在对话过程中如果判断需要调用某个工具来获取信息或执行操作它就不会直接生成普通文本回复而是生成一个结构化的“工具调用请求”。这个请求通常包含tool_calls数组里面指明了要调用哪个工具以及传入什么参数。然后你的程序需要执行这个工具并将结果以特定格式tool_call_id 执行结果再次传给模型模型再基于工具返回的结果生成最终的文本回复。这是一个多步骤的、交互式的过程。2.3 冲突的根源响应结构的“二选一”问题的核心就在这里。一个标准的、成功的 API 响应其choices[0].message的结构在单次请求中通常是“互斥”的模式 A普通对话或开启推理message对象包含role和content字段。如果开启了推理还会包含reasoning_content字段。这里没有tool_calls。模式 B决定调用工具message对象包含role和tool_calls字段。这里没有content字段也不应该有reasoning_content字段。因为模型此时的“输出”不是一个自然语言结论而是一个待执行的动作指令。当我们同时请求reasoning_content并提供了tools列表时模型内部可能陷入了逻辑矛盾它被要求“既要展示思考过程输出 reasoning_content又要决定是否调用工具可能输出 tool_calls”。而 API 的服务端在验证请求或准备响应结构时可能判定这两种输出模式在单次请求中无法共存或者reasoning_content特性尚未适配到 Tool-Calling 流程中因此直接拒绝了请求返回 400 错误。注意这是一种基于常见 API 设计和错误现象的合理推测。具体是服务端验证规则导致还是模型本身在该模式下的输出不稳定需要根据实际的错误信息来判断。但无论如何现象是在涉及tools的多轮对话中直接请求reasoning_content会失败。3. 逐步排查定位 400 错误的精确原因遇到 400 错误不要慌它其实是比 5xx 错误更友好的信号说明问题大概率出在客户端。我们需要像侦探一样系统地排查请求的每一个环节。3.1 审查请求体格式与兼容性这是第一步也是最基础的一步。你的请求体可能看起来没问题但魔鬼藏在细节里。参数位置确保reasoning参数是放在messages数组的同级而不是放在某个message对象内部。错误的放置位置会直接导致参数不被识别。正确示例{ model: deepseek-chat, messages: [...], tools: [...], reasoning: {type: enabled, content: reasoning_content} // 与 messages, tools 同级 }错误示例{ model: deepseek-chat, messages: [ {role: user, content: 你好, reasoning: {...}} // 错误reasoning 不能放在单条消息里 ], tools: [...] }参数值检查reasoning的值是否完全符合 API 文档要求。例如type字段是否只能是enabledcontent字段名是否准确不同模型版本或不同时间点参数格式可能有微调。模型版本确认你调用的模型端点model参数是否正确支持reasoning功能。不是所有模型或所有版本的 API 都支持。DeepSeek-V4 通常支持但务必核对官方文档的最新说明。Tools 定义检查tools数组的定义是否合法。每个工具的function描述中parameters的 JSON Schema 是否有效存在无效 schema 可能导致整个请求被拒绝。3.2 模拟最小化请求隔离问题构建一个最简单的、能复现错误的请求。这能帮你排除其他复杂因素的干扰。去除 Tools先发送一个不包含tools参数但包含reasoning参数的请求。如果成功返回了reasoning_content说明推理功能本身和你的基础请求格式是没问题的。保留 Tools去除 Reasoning再发送一个包含tools但不包含reasoning参数的请求。如果成功进入了 Tool-Calling 流程返回了tool_calls说明你的工具定义和基础对话流程没问题。两者结合最后发送同时包含tools和reasoning的请求。如果此时报 400 错误那么就确凿地证明了问题是这两者的组合导致的而不是其中任何一个单独的问题。3.3 分析错误响应解读服务器信息服务器返回的 400 错误通常会在响应体中携带更详细的错误信息。一定要仔细阅读这个 JSON 响应体。错误类型type可能是invalid_request_error。错误信息message这是关键。信息可能直接说“reasoning‘ is not allowed when ’tools‘ are present.”当存在 ‘tools‘ 时不允许使用 ’reasoning‘或者“Field ‘reasoning_content’ is not recognized.”字段 ‘reasoning_content’ 未被识别。不同的措辞指向不同层面的问题是业务逻辑禁止还是参数名错误。错误参数param如果提供了它会明确指出是哪个参数有问题比如“param”: “reasoning”。根据这个信息你就能精准定位到是 API 当前明确禁止这种组合还是你的请求格式有误。4. 本地中继方案曲线救国的实现思路既然直接请求行不通而你又确实需要同时获取推理过程和工具调用能力我们就需要设计一个“曲线救国”的方案。核心思想是在本地进行流程拆分和控制模拟出“推理 - 决定是否调用工具 - 执行工具 - 继续推理”的完整链条。这本质上是一个轻量级的 Agent 运行框架。4.1 方案架构设计我们不再依赖单次 API 调用同时完成推理和工具调用决策。而是将流程分解为多个步骤由本地代码中继服务器来串联。架构流程如下用户请求到达中继你的应用将用户请求发送给你自己搭建的本地中继服务而不是直接发给 DeepSeek API。第一跳获取推理过程中继服务首先构造一个不带tools参数但带reasoning参数的请求发给 DeepSeek API。这一步的目的是“强迫”模型进行思考并将思考过程reasoning_content返回给你。此时模型的回复是纯文本包含它对问题的分析和可能需要的工具。本地逻辑判断中继服务收到包含reasoning_content的回复后在本地解析这段推理文本。你可以使用简单的规则如关键词匹配“需要查询”、“调用XX接口”或者用一个更小的、成本低的模型比如 DeepSeek-R1来分析这段推理判断用户意图是否需要调用工具以及调用哪个工具。第二跳执行工具调用如果本地判断需要调用工具中继服务则构造第二个请求。这个请求包含tools参数并将第一跳得到的推理内容或原始问题作为上下文的一部分放入messages中但不包含reasoning参数。然后将请求发给 DeepSeek API。模型会根据这个新的、包含了工具定义的上下文生成结构化的tool_calls。执行工具并组织最终回复中继服务执行tool_calls指定的工具获取结果。然后它可以选择方案A简单拼接直接将第一跳的reasoning_content和最终的工具调用结果整合返回给用户。例如“【思考过程】xxx...【执行结果】yyy...”。方案B再次合成将工具执行结果作为新的消息连同历史对话和第一跳的推理再发起一次不带tools和reasoning的API调用让模型生成一个融合了所有信息的、自然流畅的最终回复然后返回给用户。4.2 关键代码示例Node.js/Python 思路以下是一个高度简化的、概念性的代码框架展示中继服务的核心逻辑。// 假设使用 Node.js 和 axios const axios require(axios); async function relayChat(userMessage) { // 步骤1获取推理内容 const reasoningResponse await axios.post(https://api.deepseek.com/chat/completions, { model: deepseek-chat, messages: [{ role: user, content: userMessage }], reasoning: { type: enabled, content: reasoning_content } // 注意第一跳没有 tools }, { headers: { Authorization: Bearer ${API_KEY} } }); const reasoningContent reasoningResponse.data.choices[0].message.reasoning_content; console.log(模型推理过程, reasoningContent); // 步骤2本地逻辑判断这里用简单关键词匹配示例 let finalAnswer reasoningResponse.data.choices[0].message.content; // 先假设不需要工具 if (reasoningContent.includes(查询) || reasoningContent.includes(调用)) { // 步骤3进行工具调用 const toolResponse await axios.post(https://api.deepseek.com/chat/completions, { model: deepseek-chat, messages: [ { role: user, content: userMessage }, // 可以把推理内容作为系统提示或上一条AI消息加入增强上下文 { role: assistant, content: 我的思考${reasoningContent} } ], tools: [ /* 你的工具定义列表 */ ] // 注意第二跳没有 reasoning }, { headers: { Authorization: Bearer ${API_KEY} } }); const toolCalls toolResponse.data.choices[0].message.tool_calls; if (toolCalls toolCalls.length 0) { // 步骤4执行工具 const toolResults await executeTools(toolCalls); // 步骤5组织最终回复这里采用方案A简单拼接 finalAnswer 【模型思考过程】\n${reasoningContent}\n\n【工具调用与结果】\n; toolResults.forEach(result { finalAnswer 调用 ${result.toolName}结果${result.result}\n; }); // 也可以在这里进行方案B再调用一次API生成总结性回复 } } return finalAnswer; } async function executeTools(toolCalls) { // 根据 toolCalls 执行实际工具如调用外部API、查询数据库等 const results []; for (const call of toolCalls) { if (call.function.name get_weather) { const weather await fetchWeather(call.function.arguments.location); results.push({ toolCallId: call.id, toolName: call.function.name, result: weather }); } // ... 其他工具 } return results; }4.3 方案的优缺点与注意事项优点完全可控你掌握了整个流程的拆分与组合可以灵活处理推理内容和工具调用的关系。功能实现绕开了 API 的直接限制实现了“既能看到思考又能用工具”的核心需求。增强逻辑可以在本地判断环节加入更复杂的业务逻辑比如工具调用权限校验、结果过滤等。缺点与成本延迟增加从一次 API 调用变成了至少两次网络往返时间RTT翻倍整体延迟显著增加。成本翻倍Token 消耗和 API 调用费用基本会翻倍因为你需要发起多次请求。逻辑复杂你需要自己维护多轮对话的状态messages历史并确保在多次请求中上下文连贯、不丢失。判断准确性本地判断是否需要调用工具其准确性依赖于规则或小模型可能不如原生的 Tool-Calling 决策精准。提示在实现中继时务必妥善管理messages历史。每次向 API 发起新请求时messages数组应该包含从对话开始到当前步骤的所有有效消息以维持模型的上下文理解。这包括用户消息、之前AI的回复含reasoning_content、工具调用请求和工具执行结果。5. 替代方案与未来展望除了本地中继这个“重型”方案根据你的具体需求也可以考虑一些更轻量级的替代思路。5.1 分步调试法如果你的主要目的是调试而非在生产环境中同时使用两者可以采取分步策略在开发阶段关闭tools开启reasoning观察模型对问题的“原始想法”。根据推理内容手动或半自动地构造出你认为模型应该发出的tool_calls进行测试。在生产环境关闭reasoning开启tools让流程自动运行。 这种方法将“理解”和“执行”阶段在时间上分离用人工智慧弥补了自动化流程的缺口。5.2 依赖模型内部能力尝试优化你的system提示词systemmessage。用清晰的指令要求模型在回复中以自然语言的形式先阐述其推理步骤然后再给出答案或决定调用工具。例如“请按以下步骤思考1. 分析问题核心2. 判断是否需要外部信息3. 如果需要指出需要什么工具和参数4. 最终给出答案或执行调用。” 虽然这样得不到结构化的reasoning_content字段但模型很可能在content文本中遵循你的指令实现类似的效果。这牺牲了结构化数据换来了单次请求的简洁。5.3 关注官方更新当前的问题很可能是由于reasoning作为一个较新的高级特性与tools功能的集成尚未完全成熟或稳定。最根本的解决方案是等待官方更新。持续关注 DeepSeek 的官方文档、更新日志和开发者社区。很可能在未来的某个模型版本或 API 版本中会正式支持两者同时启用。届时我们现在讨论的所有 workaround 都可以弃用直接使用官方简洁优雅的方式。在我自己的项目中我最终根据对延迟和成本的容忍度选择了本地中继方案。虽然引入了一些复杂度但它给了我最大的灵活性和对流程的洞察力。每次看到reasoning_content里模型一步步拆解问题再到成功触发工具调用并返回结果整个过程的透明感对于构建可靠的 AI 应用来说增加的这点开发成本是值得的。当然我也时刻准备着一旦官方支持了就第一时间切换回更简洁的模式。技术栈的选择往往就是在现状约束和未来期望之间寻找最佳平衡点。