DeerFlow 2.0：把 Agent 變工作流
DeerFlow 2.0 是一個開源 AI agent 編排框架，把長任務拆成子代理、沙盒執行與持久記憶，適合研究、寫程式與多步驟工作流。
DeerFlow 2.0 是開源 AI agent 編排框架，把複雜工作拆成多個子代理來協作完成。
說真的，這類工具很多。能真的跑長任務的，很少。DeerFlow 這次衝到 GitHub Trending 第一名，原因不難懂。它不是做一個聊天殼，而是做一套工作流。
2.0 版本主打長時間執行。它有沙盒、持久記憶、子代理拆工，還能把中間結果壓縮。講白了，就是想讓 AI 不要一忙就失憶。
| 項目 | 內容 | 意義 |
|---|---|---|
| 版本 | 2.0 rewrite | 整個 agent 流程重做 |
| 授權 | MIT | 可自由修改與部署 |
| 執行環境 | AioSandboxProvider /mnt/user-data | 把檔案與 shell 操作隔離 |
| 模型支援 | OpenAI-compatible LLMs | 可接多家模型供應商 |
| 記憶 | Persistent local profile | 保留使用者偏好與上下文 |
DeerFlow 到底是什麼
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
DeerFlow 是一個開源 AI agent orchestration framework。它的核心想法很直白。不要把所有事丟給一個模型硬扛。先拆任務，再分派給子代理，最後把結果整合回來。
這種設計很適合研究、寫程式、資料整理。因為這些工作不是一問一答就能結束。你會需要查資料、比對內容、跑工具、存中間狀態，還要記住前面做過什麼。
DeerFlow 的做法比較像一個小型專案經理。它有工作流程、工具、記憶、沙盒。它不是在陪你聊天。它是在幫你把事情做完。
- 用
.skill檔定義工作流。 - 主代理負責拆工與協調。
- 每個任務跑在隔離容器裡。
- 中間步驟會被摘要壓縮。
- 本地記憶可跨 session 保留。
為什麼 2.0 重寫很重要
2.0 不是小修小補。它是重寫。這通常代表一件事。前一版的架構，撐不住更長、更雜的任務。這在 agent 領域很常見。
很多 demo 在 3 分鐘內很漂亮。真的跑到 30 分鐘，問題就來了。上下文爆掉、工具輸出太吵、狀態亂掉，最後整個流程開始飄。
DeerFlow 對這件事下手很直接。它會把完成的步驟摘要化，把中間資料丟到磁碟，還會清掉不重要的歷史紀錄。這種設計很務實。因為長任務最怕的，不是算力不夠，而是流程失控。
“The future of AI is not just about scaling models, but also about building systems around them that can handle complex tasks reliably.” — Demis Hassabis
這句話出自 Demis Hassabis 的 2024 諾貝爾獎演講。拿來看 DeerFlow 很剛好。因為它的重點不是模型多大，而是系統怎麼把模型管好。
我覺得這才是現在 agent 工具的分水嶺。不是誰會講故事，而是誰能把雜事收拾乾淨。
實際功能有哪些
DeerFlow 的功能清單很像給工程師看的。它支援任何 OpenAI-compatible LLM，也能接 MCP server 或 Python functions。再加上內建 web search、檔案操作、bash 執行，基本上已經不是單純聊天框了。
它還有幾個很實用的入口。你可以從終端機操作，也可以在 Python 裡直接呼叫 DeerFlowClient。這對要把 agent 整合進現有軟體的人很重要。
另一個亮點是 sandbox。它把檔案與 shell 行為關在隔離環境裡。這點很土，但很必要。因為 AI 一旦亂寫檔案或亂跑指令，整台伺服器就會很精彩。
- 可用 claude-to-deerflow 走 CLI。
- 支援串流輸出，適合命令列工作流。
- 可直接嵌入 Python 應用。
- 可擴充自訂 API、檔案與 MCP 工具。
跟一般 agent 工具有什麼差別
很多 agent 工具還是單輪思維。丟 prompt，回一段答案，頂多再呼叫一次工具。這種模式適合問答，不太適合長流程工作。
DeerFlow 想處理的是另一種情境。像是研究專題、整理多份資料、掃 codebase、寫出一段可執行的程式，再把結果回填成報告。這些事都需要狀態管理。
差別很明顯。單一聊天型工具重速度。DeerFlow 重流程。前者像速食。後者像你真的在開專案會議。
- 單輪聊天工具適合快問快答。
- DeerFlow 適合研究與多步驟任務。
- 封閉平台常把流程藏起來。
- DeerFlow 讓 workflow 可見，也可改。
這裡還有一個現實問題。用這類框架，你要學會管技能、管工具、管沙盒。門檻比較高。可是一旦流程跑順，穩定度通常比亂接 prompt 高很多。
從產業角度看，這類開源框架正在往基礎設施走。大家已經不太滿足於「能 demo」。大家要的是「能交付」。
開發者該怎麼看這件事
如果你現在也在做 agent，DeerFlow 很值得看。尤其是你已經被 context 爆掉、工具亂飛、流程中斷這些問題修理過好幾次。它的思路很像把 agent 拆成可管理的零件。
你可以把它想成一個可編排的 AI 工作台。不是一個模型單打獨鬥，而是一組角色分工。這對研究團隊、資料團隊、內部自動化，都很有吸引力。
接下來真正重要的，不是它功能列多長，而是社群能不能快速做出實用 .skill。如果技能生態起得來，DeerFlow 才會從「很會講」變成「真的能用」。
我會先看兩件事。第一，長任務穩不穩。第二，整合成本高不高。只要這兩項表現不差，它就有機會變成很多團隊的預設 agent 層。
這波對 AI 開發代表什麼
AI 工具現在很像經歷分工期。聊天模型負責對話。工作流框架負責執行。沙盒負責安全。記憶負責延續。這四個東西分開後，系統才比較像樣。
DeerFlow 2.0 正好卡在這個位置。它不是要取代 LLM。它是要把 LLM 放進一個比較能做事的架構裡。這種方向很務實，也比較像工程世界會接受的樣子。
所以，如果你在找下一個 agent 實驗專案，這套值得試。不是因為它最花俏，而是因為它把很多實際問題都先想到了。這才是開發者最省時間的地方。
如果你要我下注，我會說接下來比的不是誰的 prompt 最會寫，而是誰的 workflow 最耐跑。這題，DeerFlow 已經先交了一份像樣的答案。