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

模型會調工具之后，狀態管理成了新難題。

作者丨鄭佳美

編輯丨馬曉寧

剛剛，DeepSeek 在官方 API 文檔里給出了一個 thinking mode 和 tool call 結合使用的樣例。表面上看，這只是一個常規的工具調用演示：用戶提出問題，模型判斷需要調用工具，工具返回結果后，模型再繼續生成答案。

但這個樣例真正值得關注的地方，并不是“模型會調用工具”。

今天，模型調用工具已經不是新鮮事。真正重要的是，DeepSeek 把模型的中間思考過程，也變成了 Agent 系統必須保存和管理的一部分。

這里的關鍵字段是reasoning_content。

簡單來說，它記錄的是模型在最終回答之前的中間推理內容。在普通聊天場景里，這類內容很容易被看作調試信息：開發者可以拿來看模型是怎么想的，不看似乎也不影響最終回答。但在 DeepSeek 的 tool call 場景下，情況發生了變化。

官方文檔顯示，只要中間發生了工具調用，相關的reasoning_content就需要被完整保留，并在后續請求中一并傳回去。否則，可能會觸發 400 錯誤。

這說明reasoning_content已經不只是“方便開發者觀察模型思路”的輔助字段，而是 Agent 繼續運行所依賴的上下文狀態。換句話說，它從調試信息，變成了協議流程中的一部分。

01

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 里不明顯，但在生產環境里會非常常見。

02

多模型適配會變得更復雜

更進一步看，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 需要記錄更完整的執行軌跡，包括模型在每一步做了什么、工具調用和工具結果如何對應、上下文是怎么拼接的，以及失敗時能不能恢復現場。

03

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 頂會精華

可獨家暢覽：

專家演講PPT

大會報告全文

熱門論文解讀

學術新星訪談

未經「AI科技評論」授權，嚴禁以任何方式在網頁、論壇、社區進行轉載！

公眾號轉載請先在「AI科技評論」后臺留言取得授權，轉載時需標注來源并插入本公眾號名片。