剛剛，DeepSeek 文檔更新，Agent 開發者要注意這個字段

**DeepSeek API文档更新：thinking mode与tool call结合，agent开发者需留意这一关键字段**

模型调用工具的能力已不再是新闻，但当推理过程与工具调用深度耦合，Agent系统的状态管理便悄然成为新难题。日前，DeepSeek在官方API文档中更新了一则thinking mode（思考模式）与tool call（工具调用）结合使用的示例。表面看，这只是一次常规的功能演示——用户提问、模型判断需要调用工具、工具返回结果、模型继续生成最终答案。但真正值得开发者警惕的，并不是“模型会调用工具”本身，而是一个字段被赋予了全新的地位：**reasoning_content**。 reasoning_content记录的是模型在给出最终回答之前的中间推理过程。在普通对话场景下，这类内容往往被视为调试信息，供开发者观察模型的思考路径，即便忽略也不影响对话流程。但在DeepSeek此次更新的工具调用示例中，情况发生了根本性变化。文档明确指出：只要过程中发生工具调用，相关的reasoning_content就必须被完整保留，并在后续请求中原样传回。一旦缺失，可能直接触发400错误。这意味着，reasoning_content已从“可选的调试字段”升级为“必保的协议状态”，成为Agent系统继续运行所依赖的上下文组成。 这一变化，把很多Agent框架此前并未重视的一环推到了前台：中间状态管理。在以往相对简单的Agent设计中，系统只需保存用户输入、模型回复、工具调用及工具返回结果，然后将这些消息按顺序拼接后再次提交给模型。处理单次工具调用的任务时，这种模式通常够用。然而，一旦加入thinking mode，模型在调用工具前会产出一段推理内容，这部分内容恰恰是后续推理的逻辑起点。如果被随意丢弃，不仅可能导致模型“断片”，API层面也会拒绝服务。 Agent Harness——即Agent背后的调度系统——过去负责的是消息转发和工具执行，现在则多了一项关键职责：完整保留并管理模型执行过程中的中间状态。reasoning_content就像一张草稿纸，虽不必直接展示给用户，但系统必须知道它的存在，并在合适时机将其送回模型。这其中有一个极易被忽略的细节：当模型处于thinking mode并准备调用工具时，它返回的content字段可能为空。若Agent系统仅凭content字段有无判断流程，就会误判为失败。要正确处理这一过程，系统必须具备“流程意识”，理解当前步骤是中间推理、工具调用还是最终回答，而不是只处理孤立的消息。 更进一步看，DeepSeek这一设计将给多模型Agent平台的适配工作带来更高的复杂度。长期以来，通用Agent平台倾向于设计一套统一的消息格式，将不同模型压成同样的role+content结构。但不同模型供应商对reasoning、tool call、上下文回传以及流式输出的处理并不一致。同样一个字段，在这家模型里是可选项，在另一家可能就必须保留。Agent Runtime若想支持多个模型，不能只做格式翻译，更要理解各模型协议背后的运行规则：哪些内容只是日志，哪些内容影响后续执行，哪些必须回传，哪些应在内部消化。 中间状态的管理还直接关联token成本。因为reasoning_content一旦必须随后续请求一起传回，就会持续占用上下文窗口。任务越复杂、工具调用次数越多、推理内容越长，成本压力就越明显。过去一些系统为节省token，可能直接删去中间日志或裁剪历史消息，但在新规则下，简单粗暴的裁剪可能导致上下文破坏甚至请求失败。因此，Agent系统需要更精细地管理上下文：哪些内容下一轮必须携带，哪些可以压缩为摘要，哪些仅需保留在日志中，哪些能在任务结束后删除。没有这种分层管理，就只能在成本失控和稳定性下降之间二选一。 同样受影响的还有可观测性。在传统聊天机器人中，排查问题主要依靠用户输入、模型输出、耗时、错误码和token消耗。在Agent场景中，仅凭这些信息远远不够。一次400错误，表面是API请求失败，真正原因很可能是上一轮的reasoning_content未完整传回。如果日志只记录了用户问题与最终错误信息，开发者很难追溯根源。生产级的Agent必须记录更完整的执行轨迹：模型在每一步做了什么推理、工具调用与工具结果如何对应、上下文如何拼接、失败时能否恢复现场。唯有如此，才能支撑起真正的可观测与可调试。 DeepSeek这次更新的样例虽小，却清晰指向一个趋势：Agent开发的焦点正在从“模型能否调用工具”转向“系统能否管理好整个执行过程”。模型会调工具只是起点，真正进入生产环境后，更大的挑战在于让模型、工具、上下文与中间状态稳定地协同运转。razoning_content的升级正是这一趋势的标志——它提醒开发者，某些看似辅助的信息，在特定场景下已变成Agent正常运行的必要部件。未来Agent框架的核心竞争力，或许不再是谁接入了更多的模型或工具，而是谁能把多轮推理、多次调用、复杂上下文中的中间状态管理得更加稳定、低成本且可恢复。这比让模型学会调用工具，要难得多。