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

本文作者：鄭佳美

2026-07-14 12:08

導(dǎo)語：模型會調(diào)工具之后，狀態(tài)管理成了新難題。

模型會調(diào)工具之后，狀態(tài)管理成了新難題。

作者丨鄭佳美

編輯丨馬曉寧

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

但這個樣例真正值得關(guān)注的地方，并不是“模型會調(diào)用工具”。

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

這里的關(guān)鍵字段是 reasoning_content。

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

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

這說明 reasoning_content 已經(jīng)不只是“方便開發(fā)者觀察模型思路”的輔助字段，而是 Agent 繼續(xù)運(yùn)行所依賴的上下文狀態(tài)。換句話說，它從調(diào)試信息，變成了協(xié)議流程中的一部分。

Agent 的「中間狀態(tài)」

過去很多 Agent 框架的設(shè)計(jì)相對簡單。系統(tǒng)主要保存用戶輸入、模型回復(fù)、工具調(diào)用和工具返回結(jié)果，然后把這些信息按順序拼接起來，再交給模型繼續(xù)處理。這種方式在簡單任務(wù)里通常夠用。比如用戶問天氣，模型調(diào)用天氣接口，拿到結(jié)果后給出回答，整個流程很直觀。

但 DeepSeek 的樣例提醒我們，在 thinking mode 和 tool call 結(jié)合之后，Agent 要管理的東西變多了。模型在調(diào)用工具之前的中間推理，并不是可以隨手丟掉的“草稿”。如果這部分內(nèi)容沒有被保留下來，后續(xù)請求的上下文就可能不完整。模型可能無法接上前面的推理過程，API 層面也可能直接報(bào)錯。

這就對 Agent Harness 提出了更高要求。

Agent Harness 可以理解為 Agent 背后的調(diào)度系統(tǒng)。它負(fù)責(zé)把用戶問題交給模型，把模型生成的工具調(diào)用拿出來執(zhí)行，再把工具結(jié)果交還給模型，讓模型繼續(xù)往下走。

以前，它更像是一個消息轉(zhuǎn)發(fā)器和工具執(zhí)行器；但在 DeepSeek 這個樣例里，它還需要管理模型執(zhí)行過程中的中間狀態(tài)。

這有點(diǎn)像一個人做一道復(fù)雜題。最后答案當(dāng)然重要，但中間列出來的步驟也很關(guān)鍵。如果你把草稿紙全部扔掉，只留下“我需要查一個數(shù)據(jù)”這句話，下一步很可能就接不上了。

DeepSeek 的 reasoning_content，在 tool call 場景里就像這張草稿紙。它不一定直接展示給用戶，但系統(tǒng)自己必須知道它存在，并且在合適的時(shí)候把它帶回上下文里。

這里還有一個容易被忽略的細(xì)節(jié)：在工具調(diào)用過程中，模型返回的 content 可能是空的。這并不一定代表模型出錯了。

因?yàn)榇藭r(shí)模型可能并不是要給用戶一個最終回答，而是在表達(dá)“我需要繼續(xù)調(diào)用某個工具”。如果 Agent 系統(tǒng)只盯著 content 字段，看到它為空就判斷失敗，就會誤判整個流程。

所以，在 Agent 場景下，判斷一次模型調(diào)用是否正常，不能只看有沒有自然語言回復(fù)。系統(tǒng)還要理解當(dāng)前這一步是不是中間步驟，模型是不是正在調(diào)用工具，工具結(jié)果是否已經(jīng)返回，后續(xù)是否還需要繼續(xù)生成。

也就是說，Agent Harness 需要具備流程意識，而不是只處理一條條孤立的消息。

這背后暴露的是 Agent 生產(chǎn)化里的一個核心問題：狀態(tài)管理。

一個真正可用的 Agent，往往不會只經(jīng)歷一次模型調(diào)用。它可能先理解用戶意圖，再決定調(diào)用工具；工具返回結(jié)果后，模型繼續(xù)分析；如果結(jié)果不夠，還可能再次調(diào)用另一個工具；最后才生成用戶能看到的答案。

這個過程中，每一步都依賴前面的上下文。用戶說了什么、模型剛才做了什么、為什么調(diào)用這個工具、工具返回了什么、下一步應(yīng)該接著哪里走，這些都需要被系統(tǒng)穩(wěn)定地保存下來。

如果中間狀態(tài)管理不好，Agent 就很容易出問題。比如工具結(jié)果和前面的工具調(diào)用對不上，某一輪 assistant message 被錯誤裁剪，服務(wù)重啟后無法恢復(fù)之前執(zhí)行到哪一步，或者因?yàn)閬G失 reasoning_content 導(dǎo)致下一次 API 請求失敗。

這些問題在 demo 里不明顯，但在生產(chǎn)環(huán)境里會非常常見。

多模型適配會變得更復(fù)雜

更進(jìn)一步看，DeepSeek 這個設(shè)計(jì)也會讓多模型 Agent 平臺的適配變得更復(fù)雜。

過去很多平臺會傾向于設(shè)計(jì)一個統(tǒng)一的消息格式，用同一套方式對接不同模型。但現(xiàn)實(shí)是，不同模型供應(yīng)商對 reasoning、tool call、上下文回傳和流式輸出的設(shè)計(jì)并不完全一致。同一個字段，在某個模型里可能只是可選信息，在另一個模型里卻可能是后續(xù)調(diào)用必須保留的狀態(tài)。雷峰網(wǎng)

這意味著，一個通用 Agent Runtime 如果想同時(shí)支持多個模型，就不能簡單地把所有模型都壓成同一種 role + content 格式。它必須理解不同模型協(xié)議背后的運(yùn)行規(guī)則：哪些內(nèi)容只是日志，哪些內(nèi)容會影響下一步執(zhí)行，哪些內(nèi)容必須回傳，哪些內(nèi)容應(yīng)該留在內(nèi)部系統(tǒng)里。

這也是為什么 reasoning_content 這個字段值得關(guān)注。它看起來只是 API 返回里的一個字段，但它實(shí)際上把一個更深層的問題暴露出來：Agent 系統(tǒng)不能只關(guān)心最終回答，還必須知道哪些中間內(nèi)容會影響后續(xù)執(zhí)行。

如果 reasoning_content 必須隨著后續(xù)請求一起傳回模型，它就會占用上下文窗口，也會帶來額外 token 成本。任務(wù)越復(fù)雜，工具調(diào)用次數(shù)越多，中間推理內(nèi)容越長，成本壓力就越明顯。

過去一些系統(tǒng)為了省 token，可能會直接刪除中間日志或者裁剪歷史消息。但在這種模式下，裁剪不能太粗暴。因?yàn)橛行﹥?nèi)容雖然用戶看不到，卻是模型繼續(xù)執(zhí)行所需要的。雷峰網(wǎng)(公眾號：雷峰網(wǎng))

因此，Agent 系統(tǒng)需要更精細(xì)地管理上下文。哪些內(nèi)容是下一輪調(diào)用必須帶上的，哪些可以壓縮成摘要，哪些只需要保存在日志里，哪些可以在任務(wù)結(jié)束后清理掉，這些都需要被明確區(qū)分。否則，要么成本失控，要么上下文被破壞，Agent 穩(wěn)定性下降。

可觀測性也會變得更重要。

在普通聊天機(jī)器人里，排查問題通常看用戶輸入、模型輸出、耗時(shí)、錯誤碼和 token 消耗。但在 Agent 場景里，這些信息遠(yuǎn)遠(yuǎn)不夠。因?yàn)?Agent 出錯，不一定是模型不會回答，也不一定是工具壞了，而可能是中間狀態(tài)沒有被正確保存和回放。

比如一次 400 錯誤，表面上看是 API 請求失敗，真正原因卻可能是上一輪的 reasoning_content 沒有被完整傳回去。如果日志里只記錄了用戶問題和最終失敗信息，開發(fā)者很難定位問題。

因此，生產(chǎn)級 Agent 需要記錄更完整的執(zhí)行軌跡，包括模型在每一步做了什么、工具調(diào)用和工具結(jié)果如何對應(yīng)、上下文是怎么拼接的，以及失敗時(shí)能不能恢復(fù)現(xiàn)場。

Agent 的難點(diǎn)正在轉(zhuǎn)移

DeepSeek 這個 thinking mode + tool call 樣例雖然很小，但它指向了一個重要趨勢：Agent 的重點(diǎn)正在從“模型會不會調(diào)用工具”，轉(zhuǎn)向“系統(tǒng)能不能管理好整個執(zhí)行過程”。

模型能調(diào)用工具，只是第一步。真正進(jìn)入生產(chǎn)環(huán)境后，更大的挑戰(zhàn)是讓模型、工具、上下文和中間狀態(tài)穩(wěn)定地協(xié)同工作。reasoning_content 的意義也正在這里：它提醒開發(fā)者，模型的中間推理內(nèi)容在某些場景下已經(jīng)不只是觀察窗口，而是 Agent 正常運(yùn)行的一部分。

未來 Agent 框架的核心競爭力，可能不只是接入了多少模型、支持了多少工具，而是能不能把復(fù)雜任務(wù)中的中間狀態(tài)管理好。什么時(shí)候保留，什么時(shí)候回傳，什么時(shí)候壓縮，什么時(shí)候清理，什么時(shí)候用于排查問題，這些都會直接影響 Agent 的穩(wěn)定性、成本和可維護(hù)性。

模型會調(diào)用工具，已經(jīng)不稀奇了。

真正難的是，讓 Agent 在多輪推理、多次工具調(diào)用和復(fù)雜上下文中，持續(xù)、穩(wěn)定、可恢復(fù)地跑下去。

參考鏈接：

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