DeerFlow 2.0：位元組跳動開源的“超級智慧體執行框架”，把子智慧體、記憶和沙箱裝進一個執行時

DeerFlow 的全名是 Deep Exploration and Efficient Research Flow，最初是位元組跳動開源的深度研究框架。README 講了這個專案後來的變化：社群把它用到了資料管道、生成幻燈片、搭建儀表盤和自動化內容流程上，這些都是團隊沒有預想到的用法。團隊因此認識到，DeerFlow 不只是一個研究工具，而是一個“執行框架”（harness），為智慧體提供真正完成工作所需的基礎設施，於是決定從頭重寫。2.0 與 1.x 不共享任何程式碼，原來的深度研究框架保留在 1.x 分支，活躍開發已經轉到 2.0。官方還寫道，2.0 釋出後，DeerFlow 在 2026 年 2 月 28 日登上了 GitHub Trending 第一名。截至 2026 年 10 月 13 日，倉庫約有 83,766 個星標、11,654 個派生，MIT 許可，用 Python 編寫，建立於 2025 年 5 月 7 日，最近一次推送就在 10 月 13 日。

按 README 的定義，DeerFlow 2.0 不再是一個需要自己拼裝的框架，而是“開箱即用、可完全擴充套件”的超級智慧體執行框架：基於 LangGraph 和 LangChain，自帶檔案系統、記憶、技能、能感知沙箱的執行，以及規劃並派生子智慧體處理多步驟複雜任務的能力。它是模型無關的，只要實現了相容 OpenAI 的介面就可以使用，官方更推薦有長上下文（10 萬詞元以上）、推理能力、多模態輸入和可靠工具呼叫的模型，並明確建議使用 Doubao-Seed-2.0-Code、DeepSeek v3.2 和 Kimi 2.5 來執行。搜尋與抓取方面，它整合了位元組跳動 BytePlus 自研的 InfoQuest 工具集，支援免費線上體驗。

核心特性可以歸為幾塊。技能與工具：工作區側欄裡的“能力中心”（Capability Center）可以管理外掛（MCP 伺服器與飛書整合）和技能，內建技能與使用者建立或匯入的技能分開列出，社群頁支援匯入 .skill 壓縮包。子智慧體：每個子智慧體預設執行在獨立上下文中，看不到主智慧體或其他子智慧體的內容，這樣能讓它專注於手頭任務；task 呼叫支援 isolated（預設）和 snapshot 兩種模式，snapshot 會把父智慧體保留的對話和壓縮摘要作為歷史背景交給子智慧體，代價是更多輸入詞元。上下文工程：會話內主動做摘要，把已完成子任務的結果解除安裝到檔案系統，壓縮不再需要的內容，使它能在多步驟長任務裡不撐爆視窗；對工具輸出還有預覽預算和結構化摘要。長期記憶由名為 DeerMem 的元件負責，按對話、使用者和智慧體分別做去抖，預設安靜期 30 秒，最長等待 300 秒。另外還有會話目標、手動上下文壓縮、聊天歸檔、專案與文件架、定時任務（可預覽 cron 觸發時間，並有生命週期與安全上限），以及嵌入式 Python 客戶端和終端工作臺。

執行方式在 README 裡分得很細。快速開始部分先配置模型，再選擇執行方式，推薦 Docker，也可以本地開發，並可選用 LangGraph Studio 除錯；對已有檢出的升級、多模型提供方、已存在執行的流式操作、個人訪問令牌等都有專門章節。沙箱部分尤其值得看：AIO 沙箱在不確定的隱式 shell 結果或會話建立之後會被回收，回收前閘道器會把容器 ID 或 Pod UID 記錄到隔離目錄，這些記錄在停止失敗和閘道器重啟後仍然保留；只有在後端確認沒有殘留容器或 Pod 之後，才會清除舊記錄，不能把“刪除確認”或“健康檢查失敗”當作充分證據。這種對失敗路徑的保守處理，說明它是為了長時間無人值守的使用場景寫的。

最該提前讀的是安全章節。README 說，DeerFlow 具有系統命令執行、資源操作和業務邏輯呼叫等高許可權能力，預設設計為部署在本地可信環境中，也就是隻透過 127.0.0.1 迴環地址訪問。如果把它放在區域網、公有云伺服器等多終端可訪問的環境裡而沒有嚴格措施，會有未授權呼叫、被網際網路掃描器發現後批次觸發高風險操作，以及合規和法律風險。Docker 棧預設只在 127.0.0.1 釋出入口埠，本地的 make dev 和 make start 也只繫結迴環；要從別的機器訪問，需要在 .env 裡設定 BIND_HOST，並且應當先做好措施：用 iptables 或硬體防火牆做 IP 白名單，用 nginx 之類的反向代理開啟強認證，把智慧體和可信裝置放進專用 VLAN。全新例項沒有賬號，任何不是僅迴環的部署都應在啟動後立即透過 /setup 建立管理員賬號。README 還特別說明：閘道器管理員可以註冊 stdio MCP 伺服器，這些會在閘道器容器裡執行命令；介面只允許預設的 npx、uvx 等白名單命令，並拒絕能求值任意程式碼的引數，但這只是縱深防禦而不是邊界，必須把閘道器管理員視為等同於主機上的程式碼執行許可權。

我們的判斷是，DeerFlow 2.0 值得讀的是它的工程取捨，而不是星標數。它把子智慧體隔離、上下文摘要、檔案系統解除安裝、沙箱回收這些通常藏在內部的細節寫進了文件，對想自己搭智慧體基礎設施的人是一份難得的參照。需要保留的有三點：其一，README 篇幅很大，功能迭代很快，很多章節描述的是當前原始碼的行為，部署前應對照具體版本；其二，它的威力和風險來自同一件事，也就是能執行命令和讀寫檔案，所以預設的本地迴環繫結不應被隨手改掉；其三，模型推薦裡有明顯的廠商傾向，實際效果仍取決於你接入的模型與任務。建議先在隔離的容器裡、用只含測試資料的目錄執行，再決定是否接入真實資料和外部渠道。