刚刚，DeepSeek 文档更新，Agent 开发者要注意这个字段

模型会调工具之后，状态管理成了新难题。

刚刚，DeepSeek 在官方 API 文档里给出了一个 thinking mode 和 tool call 结合使用的样例。表面上看，这只是一个常规的工具调用演示：用户提出问题，模型判断需要调用工具，工具返回结果后，模型再继续生成答案。

但这个样例真正值得关注的地方，并不是“模型会调用工具”。

今天，模型调用工具已经不是新鲜事。真正重要的是，DeepSeek 把模型的中间思考过程，也变成了 Agent 系统必须保存和管理的一部分。

这里的关键字段是 reasoning_content。

简单来说，它记录的是模型在最终回答之前的中间推理内容。在普通聊天场景里，这类内容很容易被看作调试信息：开发者可以拿来看模型是怎么想的，不看似乎也不影响最终回答。但在 DeepSeek 的 tool call 场景下，情况发生了变化。

官方文档显示，只要中间发生了工具调用，相关的 reasoning_content 就需要被完整保留，并在后续请求中一并传回去。否则，可能会触发 400 错误。

这说明 reasoning_content 已经不只是“方便开发者观察模型思路”的辅助字段，而是 Agent 继续运行所依赖的上下文状态。换句话说，它从调试信息，变成了协议流程中的一部分。

Agent 的「中间状态」

过去很多 Agent 框架的设计相对简单。系统主要保存用户输入、模型回复、工具调用和工具返回结果，然后把这些信息按顺序拼接起来，再交给模型继续处理。这种方式在简单任务里通常够用。比如用户问天气，模型调用天气接口，拿到结果后给出回答，整个流程很直观。

但 DeepSeek 的样例提醒我们，在 thinking mode 和 tool call 结合之后，Agent 要管理的东西变多了。模型在调用工具之前的中间推理，并不是可以随手丢掉的“草稿”。如果这部分内容没有被保留下来，后续请求的上下文就可能不完整。模型可能无法接上前面的推理过程，API 层面也可能直接报错。

这就对 Agent Harness 提出了更高要求。

Agent Harness 可以理解为 Agent 背后的调度系统。它负责把用户问题交给模型，把模型生成的工具调用拿出来执行，再把工具结果交还给模型，让模型继续往下走。

以前，它更像是一个消息转发器和工具执行器；但在 DeepSeek 这个样例里，它还需要管理模型执行过程中的中间状态。

这有点像一个人做一道复杂题。最后答案当然重要，但中间列出来的步骤也很关键。如果你把草稿纸全部扔掉，只留下“我需要查一个数据”这句话，下一步很可能就接不上了。

DeepSeek 的 reasoning_content，在 tool call 场景里就像这张草稿纸。它不一定直接展示给用户，但系统自己必须知道它存在，并且在合适的时候把它带回上下文里。

这里还有一个容易被忽略的细节：在工具调用过程中，模型返回的 content 可能是空的。这并不一定代表模型出错了。

因为此时模型可能并不是要给用户一个最终回答，而是在表达“我需要继续调用某个工具”。如果 Agent 系统只盯着 content 字段，看到它为空就判断失败，就会误判整个流程。

所以，在 Agent 场景下，判断一次模型调用是否正常，不能只看有没有自然语言回复。系统还要理解当前这一步是不是中间步骤，模型是不是正在调用工具，工具结果是否已经返回，后续是否还需要继续生成。

也就是说，Agent Harness 需要具备流程意识，而不是只处理一条条孤立的消息。

这背后暴露的是 Agent 生产化里的一个核心问题：状态管理。

一个真正可用的 Agent，往往不会只经历一次模型调用。它可能先理解用户意图，再决定调用工具；工具返回结果后，模型继续分析；如果结果不够，还可能再次调用另一个工具；最后才生成用户能看到的答案。

这个过程中，每一步都依赖前面的上下文。用户说了什么、模型刚才做了什么、为什么调用这个工具、工具返回了什么、下一步应该接着哪里走，这些都需要被系统稳定地保存下来。

如果中间状态管理不好，Agent 就很容易出问题。比如工具结果和前面的工具调用对不上，某一轮 assistant message 被错误裁剪，服务重启后无法恢复之前执行到哪一步，或者因为丢失 reasoning_content 导致下一次 API 请求失败。

这些问题在 demo 里不明显，但在生产环境里会非常常见。

多模型适配会变得更复杂

更进一步看，DeepSeek 这个设计也会让多模型 Agent 平台的适配变得更复杂。

过去很多平台会倾向于设计一个统一的消息格式，用同一套方式对接不同模型。但现实是，不同模型供应商对 reasoning、tool call、上下文回传和流式输出的设计并不完全一致。同一个字段，在某个模型里可能只是可选信息，在另一个模型里却可能是后续调用必须保留的状态。

这意味着，一个通用 Agent Runtime 如果想同时支持多个模型，就不能简单地把所有模型都压成同一种 role + content 格式。它必须理解不同模型协议背后的运行规则：哪些内容只是日志，哪些内容会影响下一步执行，哪些内容必须回传，哪些内容应该留在内部系统里。

这也是为什么 reasoning_content 这个字段值得关注。它看起来只是 API 返回里的一个字段，但它实际上把一个更深层的问题暴露出来：Agent 系统不能只关心最终回答，还必须知道哪些中间内容会影响后续执行。

如果 reasoning_content 必须随着后续请求一起传回模型，它就会占用上下文窗口，也会带来额外 token 成本。任务越复杂，工具调用次数越多，中间推理内容越长，成本压力就越明显。

过去一些系统为了省 token，可能会直接删除中间日志或者裁剪历史消息。但在这种模式下，裁剪不能太粗暴。因为有些内容虽然用户看不到，却是模型继续执行所需要的。

因此，Agent 系统需要更精细地管理上下文。哪些内容是下一轮调用必须带上的，哪些可以压缩成摘要，哪些只需要保存在日志里，哪些可以在任务结束后清理掉，这些都需要被明确区分。否则，要么成本失控，要么上下文被破坏，Agent 稳定性下降。

可观测性也会变得更重要。

在普通聊天机器人里，排查问题通常看用户输入、模型输出、耗时、错误码和 token 消耗。但在 Agent 场景里，这些信息远远不够。因为 Agent 出错，不一定是模型不会回答，也不一定是工具坏了，而可能是中间状态没有被正确保存和回放。

比如一次 400 错误，表面上看是 API 请求失败，真正原因却可能是上一轮的 reasoning_content 没有被完整传回去。如果日志里只记录了用户问题和最终失败信息，开发者很难定位问题。

因此，生产级 Agent 需要记录更完整的执行轨迹，包括模型在每一步做了什么、工具调用和工具结果如何对应、上下文是怎么拼接的，以及失败时能不能恢复现场。

Agent 的难点正在转移

DeepSeek 这个 thinking mode + tool call 样例虽然很小，但它指向了一个重要趋势：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

文章来自于微信公众号 “AI科技评论”，作者 “AI科技评论”