作者丨郑佳美
编辑丨马晓宁
DeepSeek 近期在官方 API 文档中提供了一个结合 thinking mode 与 tool call 的示例。表面上看，这仅是常规的“用户提问 - 模型调用工具 - 返回结果 - 生成答案”流程。然而，该案例的核心价值不在于展示模型如何调用工具，而在于揭示了中间思考过程在 Agent 系统中的关键地位。
关键字段reasoning_content记录了模型在最终回答前的推理内容。在传统聊天场景中，这通常被视为可选的调试信息；但在 DeepSeek 的 tool call 场景下，若工具调用过程中产生的reasoning_content未被完整保留并传回后续请求，将直接触发 400 错误。
这意味着reasoning_content已从辅助性的调试信息，升级为 Agent 运行协议中不可或缺的状态组成部分。
01
Agent 的「中间状态」管理
传统 Agent 框架设计相对简单，通常仅需按顺序拼接用户输入、模型回复及工具往返数据。但在 thinking mode 与 tool call 结合的场景下，模型调用工具前的中间推理不再是可随意丢弃的“草稿”。若缺失这部分内容，不仅会导致上下文不完整，更可能引发 API 层面的执行错误。
这对 Agent Harness（Agent 调度系统）提出了更高要求。它不再仅仅是消息转发器和工具执行器，还必须具备管理模型执行中间状态的能力。正如解题过程，若仅保留“需要查数据”的结论而丢弃推导步骤，后续逻辑将无法衔接。
DeepSeek 的reasoning_content在此场景下即为关键的“草稿纸”。此外，需注意模型在工具调用阶段返回的content字段可能为空，这并非错误，而是表示模型正处于中间执行步骤。Agent 系统需具备流程意识，准确判断当前是中间态还是终态，避免误判。
这一变化暴露了 Agent 生产化的核心痛点：状态管理。一个成熟的 Agent 往往涉及多轮意图理解、工具调用、结果分析及再生成。每一步都依赖前序上下文的完整性。若中间状态管理失当，极易导致工具结果错位、消息裁剪错误或服务重启后无法恢复现场等问题。
02
多模型适配复杂度的提升
DeepSeek 的设计也增加了多模型 Agent 平台的适配难度。不同模型供应商在 reasoning、tool call 及上下文回传机制上存在显著差异。通用 Agent Runtime 不能简单地将所有模型统一为单一的role + content格式，而必须深入理解各模型协议规则，区分哪些是日志信息，哪些是影响执行的关键状态。
由于reasoning_content需随请求回传，这将占用上下文窗口并增加 Token 成本。任务越复杂，中间推理内容越长，成本压力越显著。因此，系统需实施更精细的上下文管理策略：明确区分必须回传的内容、可压缩摘要的内容以及仅用于日志记录的信息，以平衡成本与稳定性。
同时，可观测性变得至关重要。在 Agent 场景中，排查问题不能仅依赖输入输出和错误码，更需记录完整的执行轨迹，包括每一步的模型行为、工具调用对应关系及上下文拼接逻辑，以便在出现如reasoning_content丢失导致的 400 错误时能快速定位根源。
03
Agent 的核心难点转移
DeepSeek 的这一案例指向了一个重要趋势：Agent 的竞争焦点正从“模型是否会调用工具”转向“系统能否高效管理整个执行过程”。
模型调用工具仅是第一步，生产环境下的真正挑战在于实现模型、工具、上下文与中间状态的稳定协同。reasoning_content的出现提醒开发者，中间推理内容已成为 Agent 正常运行的必要组件。
未来 Agent 框架的核心竞争力，将取决于对复杂任务中间状态的管理能力——何时保留、回传、压缩或清理，这些决策将直接决定 Agent 的稳定性、成本控制及可维护性。模型会调用工具已不稀奇，真正的难点在于让 Agent 在多轮推理与复杂上下文中持续、稳定且可恢复地运行。
参考链接：
https://api-docs.deepseek.com/guides/thinking_mode
https://deepseekv4pro.com/news/deepseek-july6-thinking-mode-tool-call-samples
https://api-docs.deepseek.com/api_samples/thinking_mode_api_example_tool_call
