什麼是 Deep Agents SDK？代理人框架背後的設計邏輯

你可能已經用過一些 agent 框架——可能是 LangChain 的 create_agent，可能是 LangGraph 的 workflow，可能是自己用 tool calling 兜起來的版本。

大部分情況它們都夠用。但有一種任務，它們幾乎必然讓你失望：需要多個步驟、中間有大量資訊要處理、而且過程中需要根據進度調整計畫的那種任務。

代理人會開始做、做到一半迷失、重複處理已經處理過的東西，或者更常見的——直接跳過某些步驟，然後交出一個「表面上完成了但其實沒有」的結果。

這不是換一個更聰明的模型就能解決的問題——是框架本身沒有給代理人「在哪裡放東西」和「怎麼安排接下來的事」的能力。

三個大多數框架沒給的東西

回頭看一下 agent 在執行複雜任務時到底缺什麼：

缺 1：沒有規劃能力

大多數 agent 框架的設計是接收 prompt → 決定用哪個工具 → 拿到結果 → 再決定下一步。這個迴圈對單步或兩步的任務沒問題，但換成 15 個步驟的任務，代理人很容易就「活在當下」——只知道現在這一步，不知道後面還有什麼、現在做的這步在整個計畫裡扮演什麼角色。

缺 2：Context 沒地方放

工具的回傳結果會塞進 context window。任務越複雜，累積的資訊越多，context 越快滿。滿了怎辦？要麼截斷（代理人開始遺忘），要麼噴錯（直接掛掉）。

缺 3：跨對話什麼都不記得

每次對話結束，狀態歸零。下次開啟新對話，代理人完全不知道上次做過什麼、學到什麼。如果你的任務跨越多次對話，這個問題每次都會讓你重新開始。

Deep Agents 的定位是「代理人底盤（agent harness）」——核心的 tool calling 迴圈跟其他框架沒什麼兩樣，但它把上面三個缺口都補起來了：

補 1：write_todos 工具

代理人可以在開始執行之前，先呼叫 write_todos 把任務拆分成具體步驟，然後按步驟追蹤進度。不是靠 prompt 工程讓它「記住要規劃」，是直接有一個工具可以做這件事——計畫是外部化的，不需要靠 context 維持。

補 2：Virtual Filesystem

ls、read_file、write_file、edit_file——代理人有自己的虛擬檔案系統。工具的輸出結果不需要全部塞在 context 裡，可以寫到檔案、需要的時候再讀回來。Context window 只裝「現在真正需要的東西」。

補 3：LangGraph Memory Store

跨 session 的長期記憶，基於 LangGraph 的 Memory Store。代理人可以把值得保留的資訊存起來，下一次對話再調用——不是靠摘要或外部筆記，是 SDK 層面直接支援的能力。

三者在同一個生態系裡，但定位不同：

Deep Agents 是建在 LangChain 和 LangGraph 上層的——它繼承了 LangGraph 的 durable execution、streaming、human-in-the-loop，然後再加上代理人底層需要的那三個能力。

適合用的場景：

可以用更輕量方案的場景：

Deep Agents 不是換一個更聰明的模型，是給代理人「計畫板、檔案系統、以及跨對話的記憶」——讓複雜任務有地方拆、有地方放、有地方記。

如果你的 agent 常常在複雜任務裡迷失，下一篇直接來把它裝起來跑一遍。