DeerFlow 2.1 是位元組跳動開源的長時程超級代理框架，於 2026 年 10 月底在 GitHub 累積 84,685 個星標。專案在 9 月 24 日發布 2.1.0，自 2.0.0 起合併 772 個拉取請求，把深度研究框架改寫成內建沙箱、記憶體與子代理的執行環境。
DeerFlow 2.1 是什麼？
它是位元組跳動以 MIT 授權開源的代理執行環境，建構在 LangGraph 之上，內建檔案系統、記憶體、沙箱與子代理調度，星標達 84,685 顆。
專案在 2025 年 5 月建立，最初定位是深度研究框架，讓模型自動檢索資料並產出報告。維護團隊觀察到社群把它用在資料管道、簡報產生、儀表板與內容工作流，於是決定不再把它當成需要自行組裝的框架，而是改成開箱即用的執行環境。
命名來自 Deep Exploration and Efficient Research Flow。專案在 2026 年 2 月 28 日登上 GitHub 趨勢榜首位，官方把原因歸於 2.0 版本的重寫，並在 6 月 25 日正式發布 2.0.0。
程式碼組成以 Python 為主，約 3,683 萬位元組，TypeScript 約 638 萬位元組，另有 MDX 文件與 Shell 腳本。倉庫累積 4,590 次提交、11,873 次複製，具名與匿名貢獻者合計 626 位。
為什麼 2.0 要從零重寫架構？
維護團隊發現社群把研究框架用在遠超原設計的場景，於是放棄需要自行接線的框架定位。2.0 與 1.x 不共用任何程式碼，舊版留在獨立分支繼續維護。
這個決定並不溫和。官方文件明言 2.0 是徹底重寫，與 1.x 沒有任何共用程式碼，如果仍需要原本的深度研究框架，必須切換到 1.x 分支，活躍開發已全部轉移到 2.0。
重寫的邏輯是把「框架」換成「執行環境」。官方說法是：DeerFlow 不再是一堆需要自行串接的元件，而是一套附帶電池的執行時，提供檔案系統、記憶體、技能、具沙箱感知的執行能力，以及規劃與派生代理的能力。
從產品角度看，這個轉向把競爭對手從研究工具換成了代理執行平台。同類專案包括 OpenHands、browser-use 與各家的代理 SDK，差別在於 DeerFlow 把工作區、專案、排程與多通道訊息一併做進同一個介面。
2.1 版本最核心的改動是什麼？
重心放在可驗證執行、批次委派、可插拔記憶體、四種新沙箱與企業級授權。發行說明把主題定為信任、規模與可運維性，並列出六項破壞性變更要求升級前處理。
發行說明把 2.1 的主題寫成信任、規模與可運維性三個詞。具體落點是可驗證的代理執行、耐久化的批次委派、可插拔的記憶體後端、四種新增沙箱供應商、樹外擴充系統，以及企業級認證與授權。
破壞性變更寫得相當明確。追蹤識別碼改為無條件附加，每個 Gateway HTTP 回應都帶 X-Trace-Id 標頭，用戶端在執行中繼資料提供的識別碼會被覆寫；記憶體改成可插拔，原本的私有序號設定移入 backend_config 並自動遷移，儲存路徑的語意從檔案改為根目錄。
部署層面同樣收緊。Docker 的對外連接埠預設綁定 127.0.0.1，要對外提供服務必須明確設定 BIND_HOST；E2B 沙箱的副本數成為容量上限，預設等待策略在超限時會直接讓該回合失敗，而不是無限擴張。
可驗證執行如何運作？
每個工具呼叫產生帶執行時戳記的防竄改回執，摘要帳本進入模型上下文。子代理報告必須引用可驗證的交付物，驗收條件由父代理端以檔案存在與測試退出碼判定。
這套機制的目的是處理代理最常見的失效模式：模型聲稱完成，實際上沒有。DeerFlow 2.1 讓每次工具呼叫都附上一份防竄改、由執行時蓋章的回執，並把有上限的回執帳本送進模型上下文，讓模型在後續推理中能核對自己做過什麼。
子代理的報告不再只是自然語言。報告必須引用工具回執，並附上可驗證的交付物控制代碼，由主任務代理交叉核對；委派任務上的驗收條件則在父代理端以確定性方式檢查，包括檔案是否真的存在、記錄下來的測試指令退出狀態為何。任何無法判定的項目一律標記為未驗證。
對需要合規紀錄的團隊，這個設計的好處是可稽核性。代理做了什麼、依據什麼檔案、測試有沒有通過，都能沿著回執鏈回查，而不是只能相信文字敘述。
子代理與批次任務如何規模化？
系統維護的委派帳本避免重複派工，總量上限約束扇出。選用的 batch_task 工具把大量獨立項目做成可續跑的 SQL 批次，支援租約、重試、暫停、續跑與取消。
2.0 已經支援派生代理，2.1 補上的是規模與可恢復性。系統會維護一份委派帳本，記錄哪些任務已被派出去，避免主任務代理重複委派相同工作；扇出總量另有上限，並由一個跨行程的容量控制器統一管理並行度。
新增的 batch_task 工具處理的是另一種形態的工作。它把大量彼此獨立的項目當成耐久批次執行，狀態存進 SQL，具備租約、重試、暫停、續跑與取消，聊天介面另有進度面板。這個設計讓批次工作在 Gateway 重啟後仍可繼續，而不是全部重來。
子代理的上下文取得方式也變得可選。task(context_mode=”snapshot”) 會在派工當下複製一份父對話，避免後續對話改動影響執行中的子任務；子代理的步驟歷史也會持久化並顯示在對話串中。
記憶體後端有什麼選擇？
2.1 引入可插拔設定，可用 OpenViking、mem0、Honcho 三個 HTTP 後端，另附內建 FTS5 與 BM25 檢索，並支援記憶整併與過期修剪。
記憶體從單一實作變成可替換的元件。設定中的 manager_class 決定使用哪個後端，官方提供 OpenViking、mem0 與 Honcho 三個走 HTTP 的選項，另有一個內建的 FTS5 與 BM25 檢索適配器，適合不想引入外部服務的部署。
功能面上補了幾個實務缺口。LLM 協助的記憶整併與過期修剪讓長期記憶不至於無限膨脹；逐代理的增量事實儲存把不同代理的記憶分開；混合淘汰策略則在容量壓力下決定哪些項目先被移除。選用的寫入端去重可避免同一事實被重複記錄。
對自行接手的團隊，理解成本主要在於儲存語意變化。舊版的 storage_path 是檔案路徑，新版視為根目錄，舊格式值會被丟棄並留下警告；自訂儲存類別需要搬到新路徑，並在建構式中接收 config。
沙箱與安全邊界如何設計？
新增 E2B、BoxLite、Tenki 與 OpenSandbox 供應商。本機 Docker 沙箱改用預設 seccomp、丟棄全部能力，埠口只綁橋接閘道。
沙箱是這個專案最需要謹慎對待的部分，因為代理具備系統指令執行與檔案讀寫能力。官方把部署模型寫得很直白：設計上只適用於本機信任環境，僅透過 127.0.0.1 回環介面存取；若要在區域網路或公網伺服器部署，必須自行加上嚴格防護。
2.1 的硬化措施集中在容器層。本機 Docker 沙箱把發佈的埠口綁定到 Docker 橋接閘道、套用 Docker 預設的 seccomp 設定檔、丟棄所有能力，並加上 no-new-privileges；SSH 代理通訊端會從沙箱環境清除；投射進沙箱的技能檔案改為複本而非硬連結，避免沙箱內的寫入改動原始檔。
提示注入的防線同時加厚。新增的輸入清理中介層關閉了兩條已知繞道；模型提示中的不受信任內容，包括記憶事實、SOUL.md、子代理描述與技能中繼資料，一律做 HTML 轉義；網頁擷取與 MCP 來源的工具結果也走同一條信任邊界。
官方對權限的判讀相當直接：Gateway 管理員等同於在主機上執行程式碼。因為管理員可以註冊 stdio MCP 伺服器，而這類啟動器本質上會抓取並執行遠端套件，所以官方要求按此等級授予權限，並用允許清單約束可執行的指令。
企業級認證與權限有哪些？
支援通用 OIDC 與 Keycloak 單一登入、具範圍路由策略的個人存取權杖，以及內建 RBAC 供應商，在工具、模型與沙箱三個層面同時於組裝期與執行期強制授權。
2.1 把授權做成兩個檢查點。組裝期檢查決定某個工具、模型或沙箱能否進入這次執行的可用清單，執行期檢查則在實際呼叫時再確認一次，避免長時間執行的任務在權限被撤銷後仍繼續動作。空的工具允許清單一律拒絕，而不是放行。
帳號體系的變化對自架團隊有直接影響。本機自行註冊可以關閉，改成只允許單一登入來源建立帳號；帳號偏好設定在瀏覽器資料被清除後仍會保留。個人存取權杖支援具範圍的路由策略，適合把部分端點開放給自動化流程。
外部訊息角色另有硬性限制。Gateway 的執行請求與對話狀態更新會拒絕用戶端提供的 system 或 developer 訊息並回傳 400，這個檢查阻止新的角色注入，但不會改寫既有檢查點，所以舊版本若曾接受注入，官方建議改用新對話或由管理員檢視清理。
部署與模型需求是什麼？
需要 Python 3.12 與 Node.js 22 以上，官方建議以 Docker 部署並執行 make setup。模型需相容 OpenAI API，建議具備 10 萬以上上下文。
部署路徑分兩條。官方推薦 Docker，執行 make setup 會啟動互動精靈，引導選擇模型供應商、是否啟用網路搜尋，以及沙箱模式、Bash 存取與檔案寫入等安全選項，產出一份最小化的 config.yaml 並把金鑰寫入 .env。另一條是本機開發模式，需自行安裝 Python 與 Node 相依。
模型選擇相當開放。任何實作 OpenAI 相容 API 的模型都能接入，官方建議挑選上下文視窗 10 萬個 Token 以上、具備推理能力、支援多模態輸入與穩定工具呼叫的模型。設定檔另附多家供應商的範本，包含 OpenAI、Anthropic、DeepSeek、阿里雲百煉、火山引擎豆包、月之暗面 Kimi、智譜與 MiniMax。
介面提供三種形態。瀏覽器工作區包含專案、對話分支、文件架與能力中心；終端工作台提供 TUI 操作；此外還有 MCP 伺服器、排程任務與即時通訊通道的整合，支援的通道包含 Lark、飛書與 Nostr 通訊協定的 Buzz 連接器。
出處連結有哪些？
本文資訊整理自 DeerFlow 的 GitHub 儲存庫、README 與 2.1.0 版本說明，星標與提交數取自 GitHub API，數據截至 2026 年 10 月 30 日。
- GitHub 儲存庫：https://github.com/bytedance/deer-flow
- 2.1.0 版本說明：https://github.com/bytedance/deer-flow/releases/tag/v2.1.0
- 官方網站：https://deerflow.tech
總結：DeerFlow 適合什麼團隊？
適合需要長時程任務、可稽核執行紀錄與自架部署的團隊。若只想要輕量單一任務代理，或無法提供獨立主機與沙箱隔離，投入的維運成本會高於收益。
這次改版最值得注意的地方，是它把不確定性當成工程問題處理。代理宣稱完成卻沒有實際產出，是這個領域最普遍的問題，2.1 用回執、交付物核對與父代理端驗收把這件事變成可檢查的流程，而不是靠提示詞要求模型誠實。
代價是複雜度。2.1 列出六項破壞性變更，涵蓋追蹤識別碼、技能路徑保留、沙箱副本上限、記憶體設定結構與檢查點快照頻率；升級舊部署需要逐項核對，記憶體儲存路徑的語意變化尤其容易在無提示的情況下遺失既有資料。
選型上的判斷點相對清楚。若團隊已經在用 LangGraph 或 LangChain 建構代理，且需要沙箱隔離、稽核紀錄與企業授權，DeerFlow 提供的是省去自行拼裝的完整方案；若需求只是單一任務的自動化，直接呼叫模型 API 搭配少量工具會更省成本。安全上則必須先確認部署環境符合官方要求，因為這套系統的設計前提是本機信任環境，而不是公開網路。
