演進(jìn))
1. 從 Deep Research 到 Super Agent Harness 的認(rèn)知躍遷1.1 為什么 DeerFlow 2.0 值得單獨(dú)拿出來(lái)聊DeerFlow 這個(gè)項(xiàng)目在開(kāi)源社區(qū)里一直是個(gè)挺特別的存在。第一代出來(lái)的時(shí)候很多人把它當(dāng)成一個(gè)能自動(dòng)查資料寫(xiě)報(bào)告的工具本質(zhì)上還是 Deep Research 的思路——給一個(gè)話題它去搜索、閱讀、匯總最后吐出一份結(jié)構(gòu)化的研究報(bào)告。這個(gè)定位在 2024 年到 2025 年上半年是夠用的因?yàn)槟菚r(shí)候大家對(duì) AI 的期待還停留在幫我省掉查資料的時(shí)間。但到了 2.0字節(jié)把定位直接改成了 Super Agent Harness。這個(gè)詞拆開(kāi)看就很有意思Harness 在工程語(yǔ)境里是線束、約束框架、測(cè)試夾具的意思放到 Agent 領(lǐng)域它指的是一套讓 Agent 能夠穩(wěn)定運(yùn)行、可觀測(cè)、可干預(yù)、可復(fù)現(xiàn)的運(yùn)行時(shí)骨架。換句話說(shuō)DeerFlow 2.0 不再只是一個(gè)研究工具而是一個(gè)讓各種 Agent 能力跑得穩(wěn)、管得住、看得見(jiàn)的底座。這個(gè)轉(zhuǎn)變背后的邏輯其實(shí)很實(shí)在。我接觸過(guò)不少團(tuán)隊(duì)他們用第一代 Deep Research 類(lèi)工具的時(shí)候最頭疼的不是它不夠聰明而是它跑起來(lái)之后我完全不知道它在干嘛。搜索了幾輪、讀了哪些頁(yè)面、中間有沒(méi)有跑偏、最后結(jié)論是怎么來(lái)的全靠它自己說(shuō)。一旦結(jié)果不對(duì)你連從哪一步開(kāi)始排查都不知道。Super Agent Harness 要解決的就是這個(gè)問(wèn)題——把 Agent 的執(zhí)行過(guò)程從黑盒變成白盒把不可控的自主循環(huán)變成可編排、可中斷、可回放的工作流。所以這篇內(nèi)容適合誰(shuí)看如果你是做 AI 應(yīng)用開(kāi)發(fā)的想找一個(gè)能承載復(fù)雜 Agent 邏輯的框架那 DeerFlow 2.0 的架構(gòu)設(shè)計(jì)值得逐層拆如果你是做研究、做內(nèi)容、做數(shù)據(jù)分析的想理解為什么有些 Agent 跑得穩(wěn)有些跑得飄那它里面的 Harness 機(jī)制能給你很多啟發(fā)哪怕你只是剛?cè)腴T(mén) Agent 開(kāi)發(fā)把它當(dāng)成一個(gè)工業(yè)級(jí) Agent 系統(tǒng)長(zhǎng)什么樣的參考樣本也比看一堆玩具 demo 強(qiáng)得多。1.2 Deep Research 的天花板到底在哪要理解 2.0 為什么要進(jìn)化得先看清楚 1.0 那套 Deep Research 模式的天花板。Deep Research 的核心鏈路其實(shí)很清晰接收 query → 拆解子問(wèn)題 → 并行搜索 → 抓取網(wǎng)頁(yè) → 抽取信息 → 匯總成報(bào)告。這條鏈路在信息檢索摘要這個(gè)場(chǎng)景里是成立的但一旦任務(wù)變復(fù)雜問(wèn)題就暴露了。第一個(gè)問(wèn)題是狀態(tài)不可持久。Deep Research 通常是一次性的跑完就結(jié)束中間狀態(tài)不保留。如果你想讓它在第二天接著昨天的進(jìn)度繼續(xù)深挖或者基于上次的結(jié)果做增量更新基本做不到。第二個(gè)問(wèn)題是工具調(diào)用不可擴(kuò)展。很多 Deep Research 實(shí)現(xiàn)里工具是硬編碼的——搜索、抓取、總結(jié)就這三板斧。你想加一個(gè)調(diào)用內(nèi)部數(shù)據(jù)庫(kù)或者執(zhí)行一段代碼驗(yàn)證假設(shè)的能力得改核心代碼。第三個(gè)問(wèn)題是過(guò)程不可干預(yù)。Agent 跑到一半發(fā)現(xiàn)方向錯(cuò)了你只能等它跑完再重來(lái)沒(méi)法在中途喊停、調(diào)整、繼續(xù)。這三個(gè)問(wèn)題歸結(jié)起來(lái)就是一句話Deep Research 是一個(gè)封閉的流水線而真實(shí)世界的任務(wù)需要的是一個(gè)開(kāi)放的運(yùn)行時(shí)。DeerFlow 2.0 的 Super Agent Harness 就是沖著這個(gè)開(kāi)放運(yùn)行時(shí)去的。它把 Agent 的執(zhí)行拆成了可持久化的狀態(tài)、可插拔的工具、可觀測(cè)的步驟讓整個(gè)系統(tǒng)從跑一次就完變成可以長(zhǎng)期運(yùn)行、持續(xù)演進(jìn)。1.3 Super Agent Harness 到底Harness了什么Harness這個(gè)詞在軟件工程里最經(jīng)典的用法是 test harness——測(cè)試夾具它負(fù)責(zé)給被測(cè)對(duì)象提供穩(wěn)定的運(yùn)行環(huán)境、輸入輸出控制和結(jié)果記錄。Super Agent Harness 借用了這個(gè)隱喻它要 harness 的是 Agent 的執(zhí)行過(guò)程。具體來(lái)說(shuō)它管三件事。第一是生命周期管理一個(gè) Agent 任務(wù)從創(chuàng)建、執(zhí)行、暫停、恢復(fù)到終止每個(gè)狀態(tài)都有明確的定義和轉(zhuǎn)移規(guī)則不會(huì)出現(xiàn)跑著跑著不知道去哪了的情況。第二是能力編排Agent 能調(diào)用哪些工具、按什么順序調(diào)、調(diào)用的輸入輸出怎么校驗(yàn)這些都在 Harness 層統(tǒng)一管理而不是散落在各個(gè) Agent 實(shí)現(xiàn)里。第三是可觀測(cè)性每一步執(zhí)行了什么、花了多久、消耗了多少 token、中間產(chǎn)出了什么全部記錄下來(lái)支持回放和審計(jì)。這三件事聽(tīng)起來(lái)像是工程細(xì)節(jié)但恰恰是這些細(xì)節(jié)決定了 Agent 能不能從 demo 走向生產(chǎn)。我見(jiàn)過(guò)太多 Agent 項(xiàng)目demo 階段驚艷一上生產(chǎn)就各種翻車(chē)根因幾乎都在這三件事上沒(méi)做好。DeerFlow 2.0 把這層單獨(dú)抽出來(lái)做成 Harness思路是對(duì)的——把通用的運(yùn)行時(shí)能力和具體的業(yè)務(wù)邏輯解耦讓上層 Agent 開(kāi)發(fā)者只需要關(guān)注我要做什么而不用操心怎么跑得穩(wěn)。2. 核心架構(gòu)拆解Harness 層到底怎么設(shè)計(jì)的2.1 狀態(tài)機(jī)驅(qū)動(dòng)的執(zhí)行模型DeerFlow 2.0 的執(zhí)行模型是狀態(tài)機(jī)驅(qū)動(dòng)的這是它和第一代最大的區(qū)別之一。第一代的執(zhí)行更像是一個(gè)遞歸函數(shù)——拆解問(wèn)題、遞歸搜索、返回結(jié)果調(diào)用棧就是它的狀態(tài)。這種方式在簡(jiǎn)單場(chǎng)景下沒(méi)問(wèn)題但一旦需要中斷、恢復(fù)、并行分支遞歸模型就捉襟見(jiàn)肘了。狀態(tài)機(jī)模型把 Agent 的執(zhí)行拆成一組離散的狀態(tài)和轉(zhuǎn)移。一個(gè)典型的任務(wù)會(huì)經(jīng)歷這些狀態(tài)INIT初始化→PLANNING規(guī)劃→EXECUTING執(zhí)行→REVIEWING審查→COMPLETED完成中間還可能進(jìn)入WAITING等待外部輸入、PAUSED暫停、FAILED失敗等狀態(tài)。每個(gè)狀態(tài)都有明確的進(jìn)入條件、執(zhí)行邏輯和退出條件。這種設(shè)計(jì)的好處是可持久化。因?yàn)闋顟B(tài)是離散的你可以把當(dāng)前狀態(tài)序列化存到數(shù)據(jù)庫(kù)里下次從任意一個(gè)狀態(tài)恢復(fù)。這就解決了第一代跑完就沒(méi)了的問(wèn)題。你可以讓一個(gè)研究任務(wù)跑三天中間每天只跑幾個(gè)小時(shí)剩下的時(shí)間它就在PAUSED狀態(tài)等著完全不消耗資源。另一個(gè)好處是可干預(yù)。因?yàn)闋顟B(tài)轉(zhuǎn)移是顯式的你可以在任意一個(gè)狀態(tài)節(jié)點(diǎn)插入人工審核。比如任務(wù)跑到REVIEWING狀態(tài)時(shí)先暫停讓人看一眼中間結(jié)果確認(rèn)沒(méi)問(wèn)題再讓它繼續(xù)。這在需要高準(zhǔn)確率的場(chǎng)景里非常關(guān)鍵——你不能讓 Agent 自己跑完一百步才發(fā)現(xiàn)第一步就錯(cuò)了。提示狀態(tài)機(jī)的狀態(tài)粒度需要仔細(xì)設(shè)計(jì)。太粗了比如只有運(yùn)行中和完成兩個(gè)狀態(tài)起不到干預(yù)作用太細(xì)了每一步都一個(gè)狀態(tài)會(huì)讓狀態(tài)管理本身變成負(fù)擔(dān)。DeerFlow 2.0 的粒度大致是一個(gè)語(yǔ)義完整的步驟一個(gè)狀態(tài)這個(gè)粒度在實(shí)際使用中比較平衡。2.2 工具抽象層與能力注冊(cè)機(jī)制Harness 的第二塊核心是工具抽象層。在 DeerFlow 2.0 里所有 Agent 能調(diào)用的能力——不管是搜索、網(wǎng)頁(yè)抓取、代碼執(zhí)行、還是調(diào)用外部 API——都被統(tǒng)一抽象成工具通過(guò)一套注冊(cè)機(jī)制掛載到 Harness 上。這套機(jī)制的關(guān)鍵在于接口標(biāo)準(zhǔn)化。每個(gè)工具都要聲明自己的名稱(chēng)、描述、輸入?yún)?shù) schema、輸出格式。Harness 在執(zhí)行時(shí)會(huì)根據(jù) Agent 的決策去查找對(duì)應(yīng)的工具校驗(yàn)輸入?yún)?shù)是否符合 schema執(zhí)行后把輸出按標(biāo)準(zhǔn)格式返回。這樣做的好處是Agent 不需要知道工具的具體實(shí)現(xiàn)只需要知道有這么個(gè)能力輸入什么、輸出什么。我特別想強(qiáng)調(diào)的是輸入?yún)?shù)校驗(yàn)這一環(huán)。很多 Agent 項(xiàng)目翻車(chē)就翻在這里——Agent 生成了一個(gè)格式不對(duì)的參數(shù)工具直接報(bào)錯(cuò)整個(gè)任務(wù)掛掉。DeerFlow 2.0 在 Harness 層做了 schema 校驗(yàn)參數(shù)不對(duì)的時(shí)候不是直接拋異常而是返回一個(gè)結(jié)構(gòu)化的錯(cuò)誤信息給 Agent讓它自己修正后重試。這個(gè)設(shè)計(jì)看起來(lái)小但對(duì)任務(wù)成功率的影響非常大。工具注冊(cè)還支持動(dòng)態(tài)加載。你可以把工具定義成獨(dú)立的模塊運(yùn)行時(shí)按需加載而不是全部打包進(jìn)主進(jìn)程。這對(duì)于工具數(shù)量多的場(chǎng)景很重要——你可能有幾十個(gè)工具但一個(gè)具體任務(wù)只需要其中三五個(gè)動(dòng)態(tài)加載能顯著降低啟動(dòng)開(kāi)銷(xiāo)和內(nèi)存占用。2.3 記憶與上下文管理策略Agent 跑長(zhǎng)任務(wù)最大的敵人是上下文窗口。DeerFlow 2.0 在 Harness 層做了一套記憶管理機(jī)制把短期上下文和長(zhǎng)期記憶分開(kāi)處理。短期上下文就是當(dāng)前步驟需要的信息——當(dāng)前子任務(wù)的目標(biāo)、上一步的輸出、相關(guān)的工具返回結(jié)果。這部分直接放在 prompt 里控制在一個(gè)合理的 token 預(yù)算內(nèi)。長(zhǎng)期記憶則是整個(gè)任務(wù)過(guò)程中積累的所有信息——搜索過(guò)的頁(yè)面、抽取的事實(shí)、中間結(jié)論。這部分不直接進(jìn) prompt而是存在外部存儲(chǔ)里需要的時(shí)候通過(guò)檢索召回。這套機(jī)制的核心是分層召回。當(dāng) Agent 需要某個(gè)信息時(shí)Harness 會(huì)先從短期上下文里找找不到再?gòu)拈L(zhǎng)期記憶里檢索。檢索用的是向量相似度加關(guān)鍵詞混合的方式保證召回的準(zhǔn)確性。召回的內(nèi)容會(huì)經(jīng)過(guò)壓縮和摘要再注入到當(dāng)前上下文里避免把原始的長(zhǎng)文本直接塞進(jìn)去。實(shí)測(cè)下來(lái)這套機(jī)制對(duì)長(zhǎng)任務(wù)的穩(wěn)定性提升很明顯。第一代跑超過(guò)二十輪搜索之后上下文就開(kāi)始混亂經(jīng)常出現(xiàn)忘了前面查過(guò)什么的情況。2.0 因?yàn)橛辛朔謱佑洃浥芪迨喴陨弦廊荒鼙３诌壿嬤B貫。2.4 可觀測(cè)性與回放機(jī)制可觀測(cè)性是 Harness 最被低估的價(jià)值。DeerFlow 2.0 會(huì)記錄每一步執(zhí)行的完整軌跡時(shí)間戳、狀態(tài)轉(zhuǎn)移、調(diào)用的工具、輸入?yún)?shù)、輸出結(jié)果、消耗的 token、耗時(shí)。這些數(shù)據(jù)存在結(jié)構(gòu)化的日志里支持按任務(wù) ID 查詢和回放?；胤艡C(jī)制特別有用。當(dāng)一個(gè)任務(wù)結(jié)果不對(duì)時(shí)你可以把整個(gè)執(zhí)行軌跡調(diào)出來(lái)一步步看它是在哪里跑偏的。是規(guī)劃階段就錯(cuò)了還是某個(gè)工具返回了錯(cuò)誤信息還是上下文召回召回了不相關(guān)的內(nèi)容有了軌跡排查效率比看最終輸出猜原因高一個(gè)數(shù)量級(jí)。這套可觀測(cè)性還支持指標(biāo)聚合。你可以統(tǒng)計(jì)一類(lèi)任務(wù)的平均步數(shù)、平均 token 消耗、工具調(diào)用成功率、失敗原因分布。這些指標(biāo)對(duì)于優(yōu)化 Agent 策略非常關(guān)鍵——比如你發(fā)現(xiàn)某個(gè)工具調(diào)用失敗率特別高那就去優(yōu)化那個(gè)工具的 schema 或者 Agent 的調(diào)用邏輯。3. 實(shí)操?gòu)牧愦钜粋€(gè)基于 DeerFlow 2.0 的研究 Agent3.1 環(huán)境準(zhǔn)備與依賴安裝先說(shuō)環(huán)境。DeerFlow 2.0 是 Python 項(xiàng)目建議 Python 3.10 以上3.11 或 3.12 更穩(wěn)。依賴管理用 uv 或者 poetry 都行我個(gè)人偏好 uv裝得快、鎖得準(zhǔn)。# 用 uv 創(chuàng)建虛擬環(huán)境 uv venv --python 3.11 source .venv/bin/activate # 安裝核心依賴 uv pip install deerflow-core deerflow-tools # 如果需要網(wǎng)頁(yè)抓取能力 uv pip install deerflow-tools-web # 如果需要代碼執(zhí)行能力 uv pip install deerflow-tools-code這里有個(gè)坑要注意deerflow-tools-code會(huì)依賴一個(gè)沙箱環(huán)境來(lái)執(zhí)行代碼默認(rèn)用的是本地 subprocess 沙箱。如果你在生產(chǎn)環(huán)境用強(qiáng)烈建議換成容器化沙箱否則 Agent 生成的代碼可能對(duì)你的宿主機(jī)造成影響。DeerFlow 2.0 支持配置沙箱后端在配置文件里指定sandbox.backend docker就行。模型方面DeerFlow 2.0 本身不綁定特定模型通過(guò) OpenAI 兼容接口對(duì)接。你可以用任何提供兼容接口的模型服務(wù)。配置在config.yaml里llm: provider: openai_compatible base_url: https://your-endpoint/v1 api_key: ${LLM_API_KEY} model: your-model-name max_tokens: 8192 temperature: 0.3溫度建議設(shè)低一點(diǎn)0.2 到 0.4 之間。Agent 任務(wù)需要的是穩(wěn)定和可復(fù)現(xiàn)不是創(chuàng)意發(fā)散。溫度太高會(huì)導(dǎo)致同樣的輸入每次跑出來(lái)的規(guī)劃都不一樣調(diào)試起來(lái)很痛苦。3.2 定義你的第一個(gè) Agent 任務(wù)DeerFlow 2.0 的任務(wù)定義用的是聲明式配置加代碼鉤子的混合模式?；A(chǔ)的任務(wù)描述用 YAML復(fù)雜的邏輯用 Python 鉤子。一個(gè)最小的研究任務(wù)定義長(zhǎng)這樣task: name: market_research description: 調(diào)研某個(gè)細(xì)分市場(chǎng)的玩家、規(guī)模和趨勢(shì) max_steps: 30 timeout_minutes: 60 tools: - web_search - web_fetch - summarize - write_report states: - INIT - PLANNING - EXECUTING - REVIEWING - COMPLETEDmax_steps這個(gè)參數(shù)很關(guān)鍵。它限制了 Agent 最多執(zhí)行多少步防止它陷入無(wú)限循環(huán)。我一般設(shè) 20 到 50 之間具體看任務(wù)復(fù)雜度。設(shè)太小任務(wù)跑不完設(shè)太大萬(wàn)一跑偏了浪費(fèi)資源。DeerFlow 2.0 還支持max_tokens_total和max_wall_time兩個(gè)限制建議都配上多重保險(xiǎn)。工具列表里web_search和web_fetch是內(nèi)置的summarize和write_report需要你自己實(shí)現(xiàn)或者用官方提供的。實(shí)現(xiàn)一個(gè)自定義工具其實(shí)很簡(jiǎn)單from deerflow.tools import BaseTool, ToolResult class SummarizeTool(BaseTool): name summarize description 把一段長(zhǎng)文本壓縮成要點(diǎn) input_schema { type: object, properties: { text: {type: string, description: 待壓縮的文本}, max_points: {type: integer, default: 5} }, required: [text] } async def execute(self, text: str, max_points: int 5) - ToolResult: # 這里調(diào)用你的摘要邏輯 summary await self._do_summarize(text, max_points) return ToolResult(successTrue, datasummary)注意input_schema一定要寫(xiě)清楚這是 Harness 做參數(shù)校驗(yàn)的依據(jù)。schema 寫(xiě)得越明確Agent 調(diào)用時(shí)出錯(cuò)的概率越低。3.3 配置 Harness 的運(yùn)行參數(shù)Harness 的運(yùn)行參數(shù)決定了 Agent 跑起來(lái)的行為特征。幾個(gè)關(guān)鍵參數(shù)我逐個(gè)說(shuō)。并發(fā)度harness.max_concurrent_tools控制同時(shí)能跑多少個(gè)工具調(diào)用。默認(rèn)是 3如果你的工具都是 IO 密集型的比如搜索、抓取可以調(diào)到 5 到 8。但如果工具有資源競(jìng)爭(zhēng)比如都寫(xiě)同一個(gè)文件就得調(diào)低甚至設(shè)成 1。重試策略harness.retry.max_attempts和harness.retry.backoff。工具調(diào)用失敗時(shí)的重試次數(shù)和退避策略。搜索類(lèi)工具建議重試 2 到 3 次退避用指數(shù)退避。代碼執(zhí)行類(lèi)工具建議不重試或者只重試 1 次因?yàn)槭⊥沁壿嬪e(cuò)誤重試也是白搭。上下文預(yù)算harness.context.max_tokens控制注入 prompt 的上下文上限。這個(gè)值要和你用的模型窗口匹配。比如模型窗口是 32k那這個(gè)值設(shè) 24k 左右比較合適留出空間給輸出。設(shè)太大容易觸發(fā)截?cái)嘣O(shè)太小信息不夠。狀態(tài)持久化harness.persistence.backend可以選memory、sqlite、redis。開(kāi)發(fā)階段用memory就行生產(chǎn)環(huán)境建議redis或者postgres支持多實(shí)例共享狀態(tài)。harness: max_concurrent_tools: 5 retry: max_attempts: 3 backoff: exponential context: max_tokens: 24000 recall_top_k: 8 persistence: backend: redis url: ${REDIS_URL}recall_top_k是長(zhǎng)期記憶召回時(shí)返回的條數(shù)。設(shè)太小可能漏掉關(guān)鍵信息設(shè)太大又會(huì)擠占上下文。8 到 12 之間是個(gè)比較舒服的區(qū)間實(shí)測(cè)下來(lái)召回準(zhǔn)確率和上下文占用的平衡點(diǎn)大概在這里。3.4 跑起來(lái)一次完整的研究任務(wù)實(shí)錄配置好之后啟動(dòng)任務(wù)deerflow run --task market_research --input 調(diào)研國(guó)內(nèi)新能源汽車(chē)充電樁市場(chǎng)的頭部玩家和競(jìng)爭(zhēng)格局任務(wù)啟動(dòng)后Harness 會(huì)先進(jìn)入PLANNING狀態(tài)讓模型生成一個(gè)執(zhí)行計(jì)劃。這個(gè)計(jì)劃通常是一組子問(wèn)題比如充電樁市場(chǎng)的主要玩家有哪些、各玩家的市場(chǎng)份額和布局、行業(yè)增長(zhǎng)趨勢(shì)和驅(qū)動(dòng)因素、政策環(huán)境等等。然后進(jìn)入EXECUTING逐個(gè)子問(wèn)題去搜索、抓取、抽取。每完成一個(gè)子問(wèn)題會(huì)進(jìn)入REVIEWING做一次自檢——檢查信息是否充分、是否有矛盾、是否需要補(bǔ)充搜索。如果自檢通過(guò)繼續(xù)下一個(gè)如果不通過(guò)回到EXECUTING補(bǔ)充。整個(gè)過(guò)程你可以在終端看到實(shí)時(shí)日志也可以打開(kāi) Web UI 看可視化的執(zhí)行軌跡。我一般會(huì)開(kāi)著 Web UI因?yàn)槟芸吹矫恳徊降妮斎胼敵龇奖汶S時(shí)發(fā)現(xiàn)問(wèn)題。跑完之后任務(wù)進(jìn)入COMPLETED輸出一份結(jié)構(gòu)化的報(bào)告。報(bào)告里不僅有結(jié)論還有每個(gè)結(jié)論對(duì)應(yīng)的信息來(lái)源和執(zhí)行步驟。這個(gè)可追溯的設(shè)計(jì)很實(shí)用——你可以點(diǎn)開(kāi)任何一個(gè)結(jié)論看它是從哪個(gè)頁(yè)面、哪次搜索得出來(lái)的。4. 踩坑實(shí)錄那些文檔里不會(huì)寫(xiě)的問(wèn)題4.1 工具調(diào)用死循環(huán)怎么破這是最常見(jiàn)的問(wèn)題。Agent 調(diào)用一個(gè)工具返回結(jié)果不理想它決定換個(gè)參數(shù)再調(diào)一次還是不行再換……然后就卡在那里了。DeerFlow 2.0 內(nèi)置了一個(gè)循環(huán)檢測(cè)機(jī)制會(huì)記錄最近 N 次工具調(diào)用的簽名工具名參數(shù)哈希如果發(fā)現(xiàn)重復(fù)調(diào)用超過(guò)閾值就強(qiáng)制中斷當(dāng)前分支讓 Agent 重新規(guī)劃。這個(gè)閾值默認(rèn)是 3可以在配置里調(diào)。但光靠自動(dòng)檢測(cè)不夠我一般還會(huì)在工具實(shí)現(xiàn)里加一層保護(hù)。比如搜索工具如果同一個(gè) query 在短時(shí)間內(nèi)被調(diào)用了兩次第二次直接返回緩存結(jié)果并附帶一個(gè)提示這個(gè)查詢剛剛執(zhí)行過(guò)結(jié)果相同。這樣 Agent 看到提示后通常會(huì)換策略。還有一種死循環(huán)是規(guī)劃-執(zhí)行-審查之間的循環(huán)。Agent 規(guī)劃了一個(gè)步驟執(zhí)行完審查不通過(guò)重新規(guī)劃又規(guī)劃出同樣的步驟。這種循環(huán)的根因通常是審查標(biāo)準(zhǔn)太嚴(yán)或者規(guī)劃能力不足。解決辦法是在審查環(huán)節(jié)加一個(gè)最大重規(guī)劃次數(shù)限制超過(guò)就降級(jí)處理——要么接受當(dāng)前結(jié)果要么標(biāo)記為部分完成。4.2 上下文污染與信息串味長(zhǎng)任務(wù)跑到后面上下文里堆了太多信息模型開(kāi)始串味——把 A 子問(wèn)題的結(jié)論用到 B 子問(wèn)題上或者把不相關(guān)的信息當(dāng)成相關(guān)的。這個(gè)問(wèn)題的根因是上下文管理不夠精細(xì)。DeerFlow 2.0 雖然有分層記憶但如果召回策略沒(méi)調(diào)好還是會(huì)污染。我的經(jīng)驗(yàn)是每個(gè)子任務(wù)用獨(dú)立的上下文空間子任務(wù)之間只通過(guò)結(jié)構(gòu)化的結(jié)論傳遞信息不傳遞原始上下文。具體做法是在 Harness 配置里開(kāi)啟context.isolation per_subtask。這樣每個(gè)子任務(wù)有自己的短期上下文長(zhǎng)期記憶是共享的但召回時(shí)會(huì)帶上子任務(wù)標(biāo)簽做過(guò)濾。實(shí)測(cè)下來(lái)這個(gè)設(shè)置能把信息串味的概率降低一大半。另一個(gè)技巧是定期壓縮。任務(wù)跑到一定步數(shù)后把之前的詳細(xì)上下文壓縮成摘要只保留關(guān)鍵結(jié)論和未解決的問(wèn)題。DeerFlow 2.0 支持配置context.compression_threshold超過(guò)這個(gè)步數(shù)就觸發(fā)壓縮。我一般設(shè) 15 到 20 步。4.3 模型輸出格式不穩(wěn)定Agent 任務(wù)里模型經(jīng)常需要輸出結(jié)構(gòu)化的內(nèi)容——比如一個(gè) JSON 格式的執(zhí)行計(jì)劃或者一個(gè)特定格式的工具調(diào)用參數(shù)。但模型有時(shí)候會(huì)自由發(fā)揮輸出格式不對(duì)導(dǎo)致解析失敗。DeerFlow 2.0 在 Harness 層做了輸出修復(fù)機(jī)制。當(dāng)解析失敗時(shí)它會(huì)嘗試用規(guī)則修復(fù)比如補(bǔ)全缺失的括號(hào)、去掉多余的 markdown 標(biāo)記修復(fù)不了再把錯(cuò)誤信息返回給模型讓它重新生成。這個(gè)機(jī)制能救回大部分格式問(wèn)題但不是萬(wàn)能的。更根本的解決辦法是用結(jié)構(gòu)化輸出能力。如果你的模型支持 function calling 或者 JSON mode一定要開(kāi)啟。DeerFlow 2.0 會(huì)自動(dòng)檢測(cè)模型能力并優(yōu)先使用結(jié)構(gòu)化輸出。開(kāi)啟之后格式錯(cuò)誤率能從百分之十幾降到百分之一以下。還有一個(gè)經(jīng)驗(yàn)是schema 要寬松。定義工具輸入 schema 時(shí)不要把所有字段都設(shè)成 required能設(shè)默認(rèn)值的就設(shè)默認(rèn)值。required 字段越多模型出錯(cuò)的概率越大。寧可讓工具在運(yùn)行時(shí)做二次校驗(yàn)也不要在 schema 層面卡太死。4.4 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方向解決辦法任務(wù)卡住不動(dòng)工具調(diào)用死循環(huán)看日志里最近的工具調(diào)用簽名調(diào)低循環(huán)檢測(cè)閾值工具層加緩存結(jié)果前后矛盾上下文污染檢查召回的內(nèi)容是否跨子任務(wù)開(kāi)啟子任務(wù)上下文隔離格式解析失敗模型輸出不穩(wěn)定看原始輸出和解析錯(cuò)誤開(kāi)啟結(jié)構(gòu)化輸出放寬 schema任務(wù)跑太久規(guī)劃過(guò)于發(fā)散看執(zhí)行步數(shù)和子任務(wù)數(shù)量限制 max_steps優(yōu)化規(guī)劃 prompt工具調(diào)用失敗率高schema 定義有問(wèn)題看失敗調(diào)用的參數(shù)簡(jiǎn)化 schema增加默認(rèn)值內(nèi)存占用持續(xù)增長(zhǎng)長(zhǎng)期記憶未清理看記憶存儲(chǔ)的大小配置記憶過(guò)期策略定期歸檔恢復(fù)后行為異常狀態(tài)序列化不完整對(duì)比恢復(fù)前后的狀態(tài)檢查持久化配置確保所有狀態(tài)字段都存了這張表是我自己踩坑總結(jié)的基本覆蓋了八成以上的常見(jiàn)問(wèn)題。遇到問(wèn)題先查表能省不少時(shí)間。4.5 幾個(gè)提升穩(wěn)定性的獨(dú)家技巧第一個(gè)技巧是給工具加超時(shí)。任何工具調(diào)用都要設(shè)超時(shí)尤其是網(wǎng)絡(luò)相關(guān)的。DeerFlow 2.0 支持在工具定義里設(shè)timeout_seconds默認(rèn)是 30 秒。搜索和抓取類(lèi)工具建議設(shè) 15 到 20 秒代碼執(zhí)行類(lèi)設(shè) 60 秒。超時(shí)后 Harness 會(huì)中斷調(diào)用并返回超時(shí)錯(cuò)誤Agent 可以選擇重試或者換策略。第二個(gè)技巧是關(guān)鍵步驟加人工確認(rèn)。不是所有步驟都需要人工但關(guān)鍵決策點(diǎn)——比如最終報(bào)告的大綱、核心結(jié)論的取舍——可以配置成需要人工確認(rèn)。DeerFlow 2.0 支持在狀態(tài)轉(zhuǎn)移時(shí)插入human_approval鉤子觸發(fā)后任務(wù)暫停等人工在 UI 上點(diǎn)確認(rèn)再繼續(xù)。這個(gè)功能在需要高準(zhǔn)確率的場(chǎng)景里非常有用。第三個(gè)技巧是用影子模式做灰度。新配置或者新工具上線前先用影子模式跑——Agent 正常執(zhí)行但新配置的結(jié)果只記錄不生效和舊配置的結(jié)果做對(duì)比。跑一段時(shí)間確認(rèn)新配置確實(shí)更好再切換。DeerFlow 2.0 支持配置shadow_mode指定哪些步驟走影子邏輯。第四個(gè)技巧是日志分級(jí)。Harness 的日志默認(rèn)是 INFO 級(jí)別信息量很大。生產(chǎn)環(huán)境建議調(diào)到 WARNING只在出問(wèn)題時(shí)開(kāi) DEBUG。但有個(gè)例外——工具調(diào)用的輸入輸出建議始終記錄哪怕在 WARNING 級(jí)別。因?yàn)檫@是排查問(wèn)題最關(guān)鍵的線索丟了就得重跑。5. 從 Harness 視角看 Agent 工程的未來(lái)走向5.1 為什么框架會(huì)向運(yùn)行時(shí)演進(jìn)DeerFlow 從 1.0 到 2.0 的演進(jìn)其實(shí)反映了一個(gè)更大的趨勢(shì)Agent 領(lǐng)域的競(jìng)爭(zhēng)焦點(diǎn)正在從能力轉(zhuǎn)向可靠性。第一代 Agent 框架拼的是我能調(diào)用多少工具、我能處理多復(fù)雜的任務(wù)但用下來(lái)大家發(fā)現(xiàn)能力再?gòu)?qiáng)跑不穩(wěn)都是白搭。所以下一階段的框架會(huì)越來(lái)越像運(yùn)行時(shí)——提供穩(wěn)定的執(zhí)行環(huán)境、完善的資源管理、細(xì)粒度的可觀測(cè)性。這跟傳統(tǒng)后端從寫(xiě)業(yè)務(wù)邏輯到依賴中間件的演進(jìn)路徑很像。早期大家什么都自己寫(xiě)后來(lái)發(fā)現(xiàn)數(shù)據(jù)庫(kù)、消息隊(duì)列、緩存這些通用能力應(yīng)該抽出來(lái)做成中間件業(yè)務(wù)代碼只關(guān)注業(yè)務(wù)。Agent Harness 就是這個(gè)思路在 Agent 領(lǐng)域的落地。它把狀態(tài)管理、工具編排、上下文管理、可觀測(cè)性這些通用能力抽出來(lái)讓 Agent 開(kāi)發(fā)者只關(guān)注我的 Agent 要做什么。這個(gè)分工一旦形成Agent 開(kāi)發(fā)的效率和質(zhì)量都會(huì)有質(zhì)的提升。5.2 多 Agent 協(xié)作在 Harness 層怎么落地DeerFlow 2.0 的 Harness 設(shè)計(jì)天然支持多 Agent 協(xié)作。因?yàn)闋顟B(tài)是持久化的、工具是注冊(cè)制的、上下文是隔離的多個(gè) Agent 可以共享同一個(gè) Harness各自跑各自的任務(wù)通過(guò)共享的長(zhǎng)期記憶和消息機(jī)制協(xié)作。一個(gè)典型的模式是規(guī)劃 Agent 執(zhí)行 Agent 審查 Agent三件套。規(guī)劃 Agent 負(fù)責(zé)拆解任務(wù)執(zhí)行 Agent 負(fù)責(zé)具體操作審查 Agent 負(fù)責(zé)質(zhì)量把關(guān)。三個(gè) Agent 通過(guò) Harness 的消息隊(duì)列通信規(guī)劃 Agent 產(chǎn)出計(jì)劃后發(fā)給執(zhí)行 Agent執(zhí)行 Agent 完成后發(fā)給審查 Agent審查不通過(guò)再打回執(zhí)行 Agent。這種模式比單 Agent 全包的好處是職責(zé)清晰、可獨(dú)立優(yōu)化。規(guī)劃不行就調(diào)規(guī)劃 Agent 的 prompt執(zhí)行不行就換執(zhí)行 Agent 的模型互不影響。而且因?yàn)?Harness 記錄了所有消息協(xié)作過(guò)程完全可追溯出問(wèn)題容易定位。5.3 給正在選型 Agent 框架的人幾句實(shí)在話如果你正在選 Agent 框架我的建議是先想清楚你的場(chǎng)景需要什么。如果只是做個(gè) demo 或者簡(jiǎn)單任務(wù)輕量級(jí)框架就夠了上 Harness 反而是過(guò)度設(shè)計(jì)。但如果你要做的是需要長(zhǎng)期運(yùn)行、需要人工干預(yù)、需要審計(jì)追溯的生產(chǎn)級(jí)應(yīng)用那 Harness 這層能力是繞不過(guò)去的。DeerFlow 2.0 在這方面的優(yōu)勢(shì)是它把 Harness 做成了核心而不是附屬。很多框架也有狀態(tài)管理、也有工具注冊(cè)但都是順帶做的深度和完整性不夠。DeerFlow 2.0 是把這些當(dāng)成一等公民來(lái)設(shè)計(jì)的用起來(lái)能感覺(jué)到差別。當(dāng)然它也不是沒(méi)有短板。生態(tài)還在建設(shè)中第三方工具的數(shù)量比不上一些老牌框架文檔雖然全但有些地方不夠細(xì)需要看源碼才能完全理解。不過(guò)考慮到它開(kāi)源不久這個(gè)成熟度已經(jīng)不錯(cuò)了。最后說(shuō)一句Agent 工程這個(gè)領(lǐng)域變化很快今天的最佳實(shí)踐明天可能就過(guò)時(shí)了。與其糾結(jié)選哪個(gè)框架不如把 Harness 這套思路理解透——狀態(tài)機(jī)、工具抽象、分層記憶、可觀測(cè)性這些概念不管用什么框架都是通用的。理解了這些換框架的成本就很低因?yàn)槟阒雷约阂氖鞘裁础? DeerFlow 2.0 深度拆解：從 Deep Research 到 Super Agent Harness 的架構(gòu)演進(jìn)
1. 從 Deep Research 到 Super Agent Harness 的認(rèn)知躍遷1.1 為什么 DeerFlow 2.0 值得單獨(dú)拿出來(lái)聊DeerFlow 這個(gè)項(xiàng)目在開(kāi)源社區(qū)里一直是個(gè)挺特別的存在。第一代出來(lái)的時(shí)候很多人把它當(dāng)成一個(gè)能自動(dòng)查資料寫(xiě)報(bào)告的工具本質(zhì)上還是 Deep Research 的思路——給一個(gè)話題它去搜索、閱讀、匯總最后吐出一份結(jié)構(gòu)化的研究報(bào)告。這個(gè)定位在 2024 年到 2025 年上半年是夠用的因?yàn)槟菚r(shí)候大家對(duì) AI 的期待還停留在幫我省掉查資料的時(shí)間。但到了 2.0字節(jié)把定位直接改成了 Super Agent Harness。這個(gè)詞拆開(kāi)看就很有意思Harness 在工程語(yǔ)境里是線束、約束框架、測(cè)試夾具的意思放到 Agent 領(lǐng)域它指的是一套讓 Agent 能夠穩(wěn)定運(yùn)行、可觀測(cè)、可干預(yù)、可復(fù)現(xiàn)的運(yùn)行時(shí)骨架。換句話說(shuō)DeerFlow 2.0 不再只是一個(gè)研究工具而是一個(gè)讓各種 Agent 能力跑得穩(wěn)、管得住、看得見(jiàn)的底座。這個(gè)轉(zhuǎn)變背后的邏輯其實(shí)很實(shí)在。我接觸過(guò)不少團(tuán)隊(duì)他們用第一代 Deep Research 類(lèi)工具的時(shí)候最頭疼的不是它不夠聰明而是它跑起來(lái)之后我完全不知道它在干嘛。搜索了幾輪、讀了哪些頁(yè)面、中間有沒(méi)有跑偏、最后結(jié)論是怎么來(lái)的全靠它自己說(shuō)。一旦結(jié)果不對(duì)你連從哪一步開(kāi)始排查都不知道。Super Agent Harness 要解決的就是這個(gè)問(wèn)題——把 Agent 的執(zhí)行過(guò)程從黑盒變成白盒把不可控的自主循環(huán)變成可編排、可中斷、可回放的工作流。所以這篇內(nèi)容適合誰(shuí)看如果你是做 AI 應(yīng)用開(kāi)發(fā)的想找一個(gè)能承載復(fù)雜 Agent 邏輯的框架那 DeerFlow 2.0 的架構(gòu)設(shè)計(jì)值得逐層拆如果你是做研究、做內(nèi)容、做數(shù)據(jù)分析的想理解為什么有些 Agent 跑得穩(wěn)有些跑得飄那它里面的 Harness 機(jī)制能給你很多啟發(fā)哪怕你只是剛?cè)腴T(mén) Agent 開(kāi)發(fā)把它當(dāng)成一個(gè)工業(yè)級(jí) Agent 系統(tǒng)長(zhǎng)什么樣的參考樣本也比看一堆玩具 demo 強(qiáng)得多。1.2 Deep Research 的天花板到底在哪要理解 2.0 為什么要進(jìn)化得先看清楚 1.0 那套 Deep Research 模式的天花板。Deep Research 的核心鏈路其實(shí)很清晰接收 query → 拆解子問(wèn)題 → 并行搜索 → 抓取網(wǎng)頁(yè) → 抽取信息 → 匯總成報(bào)告。這條鏈路在信息檢索摘要這個(gè)場(chǎng)景里是成立的但一旦任務(wù)變復(fù)雜問(wèn)題就暴露了。第一個(gè)問(wèn)題是狀態(tài)不可持久。Deep Research 通常是一次性的跑完就結(jié)束中間狀態(tài)不保留。如果你想讓它在第二天接著昨天的進(jìn)度繼續(xù)深挖或者基于上次的結(jié)果做增量更新基本做不到。第二個(gè)問(wèn)題是工具調(diào)用不可擴(kuò)展。很多 Deep Research 實(shí)現(xiàn)里工具是硬編碼的——搜索、抓取、總結(jié)就這三板斧。你想加一個(gè)調(diào)用內(nèi)部數(shù)據(jù)庫(kù)或者執(zhí)行一段代碼驗(yàn)證假設(shè)的能力得改核心代碼。第三個(gè)問(wèn)題是過(guò)程不可干預(yù)。Agent 跑到一半發(fā)現(xiàn)方向錯(cuò)了你只能等它跑完再重來(lái)沒(méi)法在中途喊停、調(diào)整、繼續(xù)。這三個(gè)問(wèn)題歸結(jié)起來(lái)就是一句話Deep Research 是一個(gè)封閉的流水線而真實(shí)世界的任務(wù)需要的是一個(gè)開(kāi)放的運(yùn)行時(shí)。DeerFlow 2.0 的 Super Agent Harness 就是沖著這個(gè)開(kāi)放運(yùn)行時(shí)去的。它把 Agent 的執(zhí)行拆成了可持久化的狀態(tài)、可插拔的工具、可觀測(cè)的步驟讓整個(gè)系統(tǒng)從跑一次就完變成可以長(zhǎng)期運(yùn)行、持續(xù)演進(jìn)。1.3 Super Agent Harness 到底Harness了什么Harness這個(gè)詞在軟件工程里最經(jīng)典的用法是 test harness——測(cè)試夾具它負(fù)責(zé)給被測(cè)對(duì)象提供穩(wěn)定的運(yùn)行環(huán)境、輸入輸出控制和結(jié)果記錄。Super Agent Harness 借用了這個(gè)隱喻它要 harness 的是 Agent 的執(zhí)行過(guò)程。具體來(lái)說(shuō)它管三件事。第一是生命周期管理一個(gè) Agent 任務(wù)從創(chuàng)建、執(zhí)行、暫停、恢復(fù)到終止每個(gè)狀態(tài)都有明確的定義和轉(zhuǎn)移規(guī)則不會(huì)出現(xiàn)跑著跑著不知道去哪了的情況。第二是能力編排Agent 能調(diào)用哪些工具、按什么順序調(diào)、調(diào)用的輸入輸出怎么校驗(yàn)這些都在 Harness 層統(tǒng)一管理而不是散落在各個(gè) Agent 實(shí)現(xiàn)里。第三是可觀測(cè)性每一步執(zhí)行了什么、花了多久、消耗了多少 token、中間產(chǎn)出了什么全部記錄下來(lái)支持回放和審計(jì)。這三件事聽(tīng)起來(lái)像是工程細(xì)節(jié)但恰恰是這些細(xì)節(jié)決定了 Agent 能不能從 demo 走向生產(chǎn)。我見(jiàn)過(guò)太多 Agent 項(xiàng)目demo 階段驚艷一上生產(chǎn)就各種翻車(chē)根因幾乎都在這三件事上沒(méi)做好。DeerFlow 2.0 把這層單獨(dú)抽出來(lái)做成 Harness思路是對(duì)的——把通用的運(yùn)行時(shí)能力和具體的業(yè)務(wù)邏輯解耦讓上層 Agent 開(kāi)發(fā)者只需要關(guān)注我要做什么而不用操心怎么跑得穩(wěn)。2. 核心架構(gòu)拆解Harness 層到底怎么設(shè)計(jì)的2.1 狀態(tài)機(jī)驅(qū)動(dòng)的執(zhí)行模型DeerFlow 2.0 的執(zhí)行模型是狀態(tài)機(jī)驅(qū)動(dòng)的這是它和第一代最大的區(qū)別之一。第一代的執(zhí)行更像是一個(gè)遞歸函數(shù)——拆解問(wèn)題、遞歸搜索、返回結(jié)果調(diào)用棧就是它的狀態(tài)。這種方式在簡(jiǎn)單場(chǎng)景下沒(méi)問(wèn)題但一旦需要中斷、恢復(fù)、并行分支遞歸模型就捉襟見(jiàn)肘了。狀態(tài)機(jī)模型把 Agent 的執(zhí)行拆成一組離散的狀態(tài)和轉(zhuǎn)移。一個(gè)典型的任務(wù)會(huì)經(jīng)歷這些狀態(tài)INIT初始化→PLANNING規(guī)劃→EXECUTING執(zhí)行→REVIEWING審查→COMPLETED完成中間還可能進(jìn)入WAITING等待外部輸入、PAUSED暫停、FAILED失敗等狀態(tài)。每個(gè)狀態(tài)都有明確的進(jìn)入條件、執(zhí)行邏輯和退出條件。這種設(shè)計(jì)的好處是可持久化。因?yàn)闋顟B(tài)是離散的你可以把當(dāng)前狀態(tài)序列化存到數(shù)據(jù)庫(kù)里下次從任意一個(gè)狀態(tài)恢復(fù)。這就解決了第一代跑完就沒(méi)了的問(wèn)題。你可以讓一個(gè)研究任務(wù)跑三天中間每天只跑幾個(gè)小時(shí)剩下的時(shí)間它就在PAUSED狀態(tài)等著完全不消耗資源。另一個(gè)好處是可干預(yù)。因?yàn)闋顟B(tài)轉(zhuǎn)移是顯式的你可以在任意一個(gè)狀態(tài)節(jié)點(diǎn)插入人工審核。比如任務(wù)跑到REVIEWING狀態(tài)時(shí)先暫停讓人看一眼中間結(jié)果確認(rèn)沒(méi)問(wèn)題再讓它繼續(xù)。這在需要高準(zhǔn)確率的場(chǎng)景里非常關(guān)鍵——你不能讓 Agent 自己跑完一百步才發(fā)現(xiàn)第一步就錯(cuò)了。提示狀態(tài)機(jī)的狀態(tài)粒度需要仔細(xì)設(shè)計(jì)。太粗了比如只有運(yùn)行中和完成兩個(gè)狀態(tài)起不到干預(yù)作用太細(xì)了每一步都一個(gè)狀態(tài)會(huì)讓狀態(tài)管理本身變成負(fù)擔(dān)。DeerFlow 2.0 的粒度大致是一個(gè)語(yǔ)義完整的步驟一個(gè)狀態(tài)這個(gè)粒度在實(shí)際使用中比較平衡。2.2 工具抽象層與能力注冊(cè)機(jī)制Harness 的第二塊核心是工具抽象層。在 DeerFlow 2.0 里所有 Agent 能調(diào)用的能力——不管是搜索、網(wǎng)頁(yè)抓取、代碼執(zhí)行、還是調(diào)用外部 API——都被統(tǒng)一抽象成工具通過(guò)一套注冊(cè)機(jī)制掛載到 Harness 上。這套機(jī)制的關(guān)鍵在于接口標(biāo)準(zhǔn)化。每個(gè)工具都要聲明自己的名稱(chēng)、描述、輸入?yún)?shù) schema、輸出格式。Harness 在執(zhí)行時(shí)會(huì)根據(jù) Agent 的決策去查找對(duì)應(yīng)的工具校驗(yàn)輸入?yún)?shù)是否符合 schema執(zhí)行后把輸出按標(biāo)準(zhǔn)格式返回。這樣做的好處是Agent 不需要知道工具的具體實(shí)現(xiàn)只需要知道有這么個(gè)能力輸入什么、輸出什么。我特別想強(qiáng)調(diào)的是輸入?yún)?shù)校驗(yàn)這一環(huán)。很多 Agent 項(xiàng)目翻車(chē)就翻在這里——Agent 生成了一個(gè)格式不對(duì)的參數(shù)工具直接報(bào)錯(cuò)整個(gè)任務(wù)掛掉。DeerFlow 2.0 在 Harness 層做了 schema 校驗(yàn)參數(shù)不對(duì)的時(shí)候不是直接拋異常而是返回一個(gè)結(jié)構(gòu)化的錯(cuò)誤信息給 Agent讓它自己修正后重試。這個(gè)設(shè)計(jì)看起來(lái)小但對(duì)任務(wù)成功率的影響非常大。工具注冊(cè)還支持動(dòng)態(tài)加載。你可以把工具定義成獨(dú)立的模塊運(yùn)行時(shí)按需加載而不是全部打包進(jìn)主進(jìn)程。這對(duì)于工具數(shù)量多的場(chǎng)景很重要——你可能有幾十個(gè)工具但一個(gè)具體任務(wù)只需要其中三五個(gè)動(dòng)態(tài)加載能顯著降低啟動(dòng)開(kāi)銷(xiāo)和內(nèi)存占用。2.3 記憶與上下文管理策略Agent 跑長(zhǎng)任務(wù)最大的敵人是上下文窗口。DeerFlow 2.0 在 Harness 層做了一套記憶管理機(jī)制把短期上下文和長(zhǎng)期記憶分開(kāi)處理。短期上下文就是當(dāng)前步驟需要的信息——當(dāng)前子任務(wù)的目標(biāo)、上一步的輸出、相關(guān)的工具返回結(jié)果。這部分直接放在 prompt 里控制在一個(gè)合理的 token 預(yù)算內(nèi)。長(zhǎng)期記憶則是整個(gè)任務(wù)過(guò)程中積累的所有信息——搜索過(guò)的頁(yè)面、抽取的事實(shí)、中間結(jié)論。這部分不直接進(jìn) prompt而是存在外部存儲(chǔ)里需要的時(shí)候通過(guò)檢索召回。這套機(jī)制的核心是分層召回。當(dāng) Agent 需要某個(gè)信息時(shí)Harness 會(huì)先從短期上下文里找找不到再?gòu)拈L(zhǎng)期記憶里檢索。檢索用的是向量相似度加關(guān)鍵詞混合的方式保證召回的準(zhǔn)確性。召回的內(nèi)容會(huì)經(jīng)過(guò)壓縮和摘要再注入到當(dāng)前上下文里避免把原始的長(zhǎng)文本直接塞進(jìn)去。實(shí)測(cè)下來(lái)這套機(jī)制對(duì)長(zhǎng)任務(wù)的穩(wěn)定性提升很明顯。第一代跑超過(guò)二十輪搜索之后上下文就開(kāi)始混亂經(jīng)常出現(xiàn)忘了前面查過(guò)什么的情況。2.0 因?yàn)橛辛朔謱佑洃浥芪迨喴陨弦廊荒鼙３诌壿嬤B貫。2.4 可觀測(cè)性與回放機(jī)制可觀測(cè)性是 Harness 最被低估的價(jià)值。DeerFlow 2.0 會(huì)記錄每一步執(zhí)行的完整軌跡時(shí)間戳、狀態(tài)轉(zhuǎn)移、調(diào)用的工具、輸入?yún)?shù)、輸出結(jié)果、消耗的 token、耗時(shí)。這些數(shù)據(jù)存在結(jié)構(gòu)化的日志里支持按任務(wù) ID 查詢和回放?；胤艡C(jī)制特別有用。當(dāng)一個(gè)任務(wù)結(jié)果不對(duì)時(shí)你可以把整個(gè)執(zhí)行軌跡調(diào)出來(lái)一步步看它是在哪里跑偏的。是規(guī)劃階段就錯(cuò)了還是某個(gè)工具返回了錯(cuò)誤信息還是上下文召回召回了不相關(guān)的內(nèi)容有了軌跡排查效率比看最終輸出猜原因高一個(gè)數(shù)量級(jí)。這套可觀測(cè)性還支持指標(biāo)聚合。你可以統(tǒng)計(jì)一類(lèi)任務(wù)的平均步數(shù)、平均 token 消耗、工具調(diào)用成功率、失敗原因分布。這些指標(biāo)對(duì)于優(yōu)化 Agent 策略非常關(guān)鍵——比如你發(fā)現(xiàn)某個(gè)工具調(diào)用失敗率特別高那就去優(yōu)化那個(gè)工具的 schema 或者 Agent 的調(diào)用邏輯。3. 實(shí)操?gòu)牧愦钜粋€(gè)基于 DeerFlow 2.0 的研究 Agent3.1 環(huán)境準(zhǔn)備與依賴安裝先說(shuō)環(huán)境。DeerFlow 2.0 是 Python 項(xiàng)目建議 Python 3.10 以上3.11 或 3.12 更穩(wěn)。依賴管理用 uv 或者 poetry 都行我個(gè)人偏好 uv裝得快、鎖得準(zhǔn)。# 用 uv 創(chuàng)建虛擬環(huán)境 uv venv --python 3.11 source .venv/bin/activate # 安裝核心依賴 uv pip install deerflow-core deerflow-tools # 如果需要網(wǎng)頁(yè)抓取能力 uv pip install deerflow-tools-web # 如果需要代碼執(zhí)行能力 uv pip install deerflow-tools-code這里有個(gè)坑要注意deerflow-tools-code會(huì)依賴一個(gè)沙箱環(huán)境來(lái)執(zhí)行代碼默認(rèn)用的是本地 subprocess 沙箱。如果你在生產(chǎn)環(huán)境用強(qiáng)烈建議換成容器化沙箱否則 Agent 生成的代碼可能對(duì)你的宿主機(jī)造成影響。DeerFlow 2.0 支持配置沙箱后端在配置文件里指定sandbox.backend docker就行。模型方面DeerFlow 2.0 本身不綁定特定模型通過(guò) OpenAI 兼容接口對(duì)接。你可以用任何提供兼容接口的模型服務(wù)。配置在config.yaml里llm: provider: openai_compatible base_url: https://your-endpoint/v1 api_key: ${LLM_API_KEY} model: your-model-name max_tokens: 8192 temperature: 0.3溫度建議設(shè)低一點(diǎn)0.2 到 0.4 之間。Agent 任務(wù)需要的是穩(wěn)定和可復(fù)現(xiàn)不是創(chuàng)意發(fā)散。溫度太高會(huì)導(dǎo)致同樣的輸入每次跑出來(lái)的規(guī)劃都不一樣調(diào)試起來(lái)很痛苦。3.2 定義你的第一個(gè) Agent 任務(wù)DeerFlow 2.0 的任務(wù)定義用的是聲明式配置加代碼鉤子的混合模式?；A(chǔ)的任務(wù)描述用 YAML復(fù)雜的邏輯用 Python 鉤子。一個(gè)最小的研究任務(wù)定義長(zhǎng)這樣task: name: market_research description: 調(diào)研某個(gè)細(xì)分市場(chǎng)的玩家、規(guī)模和趨勢(shì) max_steps: 30 timeout_minutes: 60 tools: - web_search - web_fetch - summarize - write_report states: - INIT - PLANNING - EXECUTING - REVIEWING - COMPLETEDmax_steps這個(gè)參數(shù)很關(guān)鍵。它限制了 Agent 最多執(zhí)行多少步防止它陷入無(wú)限循環(huán)。我一般設(shè) 20 到 50 之間具體看任務(wù)復(fù)雜度。設(shè)太小任務(wù)跑不完設(shè)太大萬(wàn)一跑偏了浪費(fèi)資源。DeerFlow 2.0 還支持max_tokens_total和max_wall_time兩個(gè)限制建議都配上多重保險(xiǎn)。工具列表里web_search和web_fetch是內(nèi)置的summarize和write_report需要你自己實(shí)現(xiàn)或者用官方提供的。實(shí)現(xiàn)一個(gè)自定義工具其實(shí)很簡(jiǎn)單from deerflow.tools import BaseTool, ToolResult class SummarizeTool(BaseTool): name summarize description 把一段長(zhǎng)文本壓縮成要點(diǎn) input_schema { type: object, properties: { text: {type: string, description: 待壓縮的文本}, max_points: {type: integer, default: 5} }, required: [text] } async def execute(self, text: str, max_points: int 5) - ToolResult: # 這里調(diào)用你的摘要邏輯 summary await self._do_summarize(text, max_points) return ToolResult(successTrue, datasummary)注意input_schema一定要寫(xiě)清楚這是 Harness 做參數(shù)校驗(yàn)的依據(jù)。schema 寫(xiě)得越明確Agent 調(diào)用時(shí)出錯(cuò)的概率越低。3.3 配置 Harness 的運(yùn)行參數(shù)Harness 的運(yùn)行參數(shù)決定了 Agent 跑起來(lái)的行為特征。幾個(gè)關(guān)鍵參數(shù)我逐個(gè)說(shuō)。并發(fā)度harness.max_concurrent_tools控制同時(shí)能跑多少個(gè)工具調(diào)用。默認(rèn)是 3如果你的工具都是 IO 密集型的比如搜索、抓取可以調(diào)到 5 到 8。但如果工具有資源競(jìng)爭(zhēng)比如都寫(xiě)同一個(gè)文件就得調(diào)低甚至設(shè)成 1。重試策略harness.retry.max_attempts和harness.retry.backoff。工具調(diào)用失敗時(shí)的重試次數(shù)和退避策略。搜索類(lèi)工具建議重試 2 到 3 次退避用指數(shù)退避。代碼執(zhí)行類(lèi)工具建議不重試或者只重試 1 次因?yàn)槭⊥沁壿嬪e(cuò)誤重試也是白搭。上下文預(yù)算harness.context.max_tokens控制注入 prompt 的上下文上限。這個(gè)值要和你用的模型窗口匹配。比如模型窗口是 32k那這個(gè)值設(shè) 24k 左右比較合適留出空間給輸出。設(shè)太大容易觸發(fā)截?cái)嘣O(shè)太小信息不夠。狀態(tài)持久化harness.persistence.backend可以選memory、sqlite、redis。開(kāi)發(fā)階段用memory就行生產(chǎn)環(huán)境建議redis或者postgres支持多實(shí)例共享狀態(tài)。harness: max_concurrent_tools: 5 retry: max_attempts: 3 backoff: exponential context: max_tokens: 24000 recall_top_k: 8 persistence: backend: redis url: ${REDIS_URL}recall_top_k是長(zhǎng)期記憶召回時(shí)返回的條數(shù)。設(shè)太小可能漏掉關(guān)鍵信息設(shè)太大又會(huì)擠占上下文。8 到 12 之間是個(gè)比較舒服的區(qū)間實(shí)測(cè)下來(lái)召回準(zhǔn)確率和上下文占用的平衡點(diǎn)大概在這里。3.4 跑起來(lái)一次完整的研究任務(wù)實(shí)錄配置好之后啟動(dòng)任務(wù)deerflow run --task market_research --input 調(diào)研國(guó)內(nèi)新能源汽車(chē)充電樁市場(chǎng)的頭部玩家和競(jìng)爭(zhēng)格局任務(wù)啟動(dòng)后Harness 會(huì)先進(jìn)入PLANNING狀態(tài)讓模型生成一個(gè)執(zhí)行計(jì)劃。這個(gè)計(jì)劃通常是一組子問(wèn)題比如充電樁市場(chǎng)的主要玩家有哪些、各玩家的市場(chǎng)份額和布局、行業(yè)增長(zhǎng)趨勢(shì)和驅(qū)動(dòng)因素、政策環(huán)境等等。然后進(jìn)入EXECUTING逐個(gè)子問(wèn)題去搜索、抓取、抽取。每完成一個(gè)子問(wèn)題會(huì)進(jìn)入REVIEWING做一次自檢——檢查信息是否充分、是否有矛盾、是否需要補(bǔ)充搜索。如果自檢通過(guò)繼續(xù)下一個(gè)如果不通過(guò)回到EXECUTING補(bǔ)充。整個(gè)過(guò)程你可以在終端看到實(shí)時(shí)日志也可以打開(kāi) Web UI 看可視化的執(zhí)行軌跡。我一般會(huì)開(kāi)著 Web UI因?yàn)槟芸吹矫恳徊降妮斎胼敵龇奖汶S時(shí)發(fā)現(xiàn)問(wèn)題。跑完之后任務(wù)進(jìn)入COMPLETED輸出一份結(jié)構(gòu)化的報(bào)告。報(bào)告里不僅有結(jié)論還有每個(gè)結(jié)論對(duì)應(yīng)的信息來(lái)源和執(zhí)行步驟。這個(gè)可追溯的設(shè)計(jì)很實(shí)用——你可以點(diǎn)開(kāi)任何一個(gè)結(jié)論看它是從哪個(gè)頁(yè)面、哪次搜索得出來(lái)的。4. 踩坑實(shí)錄那些文檔里不會(huì)寫(xiě)的問(wèn)題4.1 工具調(diào)用死循環(huán)怎么破這是最常見(jiàn)的問(wèn)題。Agent 調(diào)用一個(gè)工具返回結(jié)果不理想它決定換個(gè)參數(shù)再調(diào)一次還是不行再換……然后就卡在那里了。DeerFlow 2.0 內(nèi)置了一個(gè)循環(huán)檢測(cè)機(jī)制會(huì)記錄最近 N 次工具調(diào)用的簽名工具名參數(shù)哈希如果發(fā)現(xiàn)重復(fù)調(diào)用超過(guò)閾值就強(qiáng)制中斷當(dāng)前分支讓 Agent 重新規(guī)劃。這個(gè)閾值默認(rèn)是 3可以在配置里調(diào)。但光靠自動(dòng)檢測(cè)不夠我一般還會(huì)在工具實(shí)現(xiàn)里加一層保護(hù)。比如搜索工具如果同一個(gè) query 在短時(shí)間內(nèi)被調(diào)用了兩次第二次直接返回緩存結(jié)果并附帶一個(gè)提示這個(gè)查詢剛剛執(zhí)行過(guò)結(jié)果相同。這樣 Agent 看到提示后通常會(huì)換策略。還有一種死循環(huán)是規(guī)劃-執(zhí)行-審查之間的循環(huán)。Agent 規(guī)劃了一個(gè)步驟執(zhí)行完審查不通過(guò)重新規(guī)劃又規(guī)劃出同樣的步驟。這種循環(huán)的根因通常是審查標(biāo)準(zhǔn)太嚴(yán)或者規(guī)劃能力不足。解決辦法是在審查環(huán)節(jié)加一個(gè)最大重規(guī)劃次數(shù)限制超過(guò)就降級(jí)處理——要么接受當(dāng)前結(jié)果要么標(biāo)記為部分完成。4.2 上下文污染與信息串味長(zhǎng)任務(wù)跑到后面上下文里堆了太多信息模型開(kāi)始串味——把 A 子問(wèn)題的結(jié)論用到 B 子問(wèn)題上或者把不相關(guān)的信息當(dāng)成相關(guān)的。這個(gè)問(wèn)題的根因是上下文管理不夠精細(xì)。DeerFlow 2.0 雖然有分層記憶但如果召回策略沒(méi)調(diào)好還是會(huì)污染。我的經(jīng)驗(yàn)是每個(gè)子任務(wù)用獨(dú)立的上下文空間子任務(wù)之間只通過(guò)結(jié)構(gòu)化的結(jié)論傳遞信息不傳遞原始上下文。具體做法是在 Harness 配置里開(kāi)啟context.isolation per_subtask。這樣每個(gè)子任務(wù)有自己的短期上下文長(zhǎng)期記憶是共享的但召回時(shí)會(huì)帶上子任務(wù)標(biāo)簽做過(guò)濾。實(shí)測(cè)下來(lái)這個(gè)設(shè)置能把信息串味的概率降低一大半。另一個(gè)技巧是定期壓縮。任務(wù)跑到一定步數(shù)后把之前的詳細(xì)上下文壓縮成摘要只保留關(guān)鍵結(jié)論和未解決的問(wèn)題。DeerFlow 2.0 支持配置context.compression_threshold超過(guò)這個(gè)步數(shù)就觸發(fā)壓縮。我一般設(shè) 15 到 20 步。4.3 模型輸出格式不穩(wěn)定Agent 任務(wù)里模型經(jīng)常需要輸出結(jié)構(gòu)化的內(nèi)容——比如一個(gè) JSON 格式的執(zhí)行計(jì)劃或者一個(gè)特定格式的工具調(diào)用參數(shù)。但模型有時(shí)候會(huì)自由發(fā)揮輸出格式不對(duì)導(dǎo)致解析失敗。DeerFlow 2.0 在 Harness 層做了輸出修復(fù)機(jī)制。當(dāng)解析失敗時(shí)它會(huì)嘗試用規(guī)則修復(fù)比如補(bǔ)全缺失的括號(hào)、去掉多余的 markdown 標(biāo)記修復(fù)不了再把錯(cuò)誤信息返回給模型讓它重新生成。這個(gè)機(jī)制能救回大部分格式問(wèn)題但不是萬(wàn)能的。更根本的解決辦法是用結(jié)構(gòu)化輸出能力。如果你的模型支持 function calling 或者 JSON mode一定要開(kāi)啟。DeerFlow 2.0 會(huì)自動(dòng)檢測(cè)模型能力并優(yōu)先使用結(jié)構(gòu)化輸出。開(kāi)啟之后格式錯(cuò)誤率能從百分之十幾降到百分之一以下。還有一個(gè)經(jīng)驗(yàn)是schema 要寬松。定義工具輸入 schema 時(shí)不要把所有字段都設(shè)成 required能設(shè)默認(rèn)值的就設(shè)默認(rèn)值。required 字段越多模型出錯(cuò)的概率越大。寧可讓工具在運(yùn)行時(shí)做二次校驗(yàn)也不要在 schema 層面卡太死。4.4 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方向解決辦法任務(wù)卡住不動(dòng)工具調(diào)用死循環(huán)看日志里最近的工具調(diào)用簽名調(diào)低循環(huán)檢測(cè)閾值工具層加緩存結(jié)果前后矛盾上下文污染檢查召回的內(nèi)容是否跨子任務(wù)開(kāi)啟子任務(wù)上下文隔離格式解析失敗模型輸出不穩(wěn)定看原始輸出和解析錯(cuò)誤開(kāi)啟結(jié)構(gòu)化輸出放寬 schema任務(wù)跑太久規(guī)劃過(guò)于發(fā)散看執(zhí)行步數(shù)和子任務(wù)數(shù)量限制 max_steps優(yōu)化規(guī)劃 prompt工具調(diào)用失敗率高schema 定義有問(wèn)題看失敗調(diào)用的參數(shù)簡(jiǎn)化 schema增加默認(rèn)值內(nèi)存占用持續(xù)增長(zhǎng)長(zhǎng)期記憶未清理看記憶存儲(chǔ)的大小配置記憶過(guò)期策略定期歸檔恢復(fù)后行為異常狀態(tài)序列化不完整對(duì)比恢復(fù)前后的狀態(tài)檢查持久化配置確保所有狀態(tài)字段都存了這張表是我自己踩坑總結(jié)的基本覆蓋了八成以上的常見(jiàn)問(wèn)題。遇到問(wèn)題先查表能省不少時(shí)間。4.5 幾個(gè)提升穩(wěn)定性的獨(dú)家技巧第一個(gè)技巧是給工具加超時(shí)。任何工具調(diào)用都要設(shè)超時(shí)尤其是網(wǎng)絡(luò)相關(guān)的。DeerFlow 2.0 支持在工具定義里設(shè)timeout_seconds默認(rèn)是 30 秒。搜索和抓取類(lèi)工具建議設(shè) 15 到 20 秒代碼執(zhí)行類(lèi)設(shè) 60 秒。超時(shí)后 Harness 會(huì)中斷調(diào)用并返回超時(shí)錯(cuò)誤Agent 可以選擇重試或者換策略。第二個(gè)技巧是關(guān)鍵步驟加人工確認(rèn)。不是所有步驟都需要人工但關(guān)鍵決策點(diǎn)——比如最終報(bào)告的大綱、核心結(jié)論的取舍——可以配置成需要人工確認(rèn)。DeerFlow 2.0 支持在狀態(tài)轉(zhuǎn)移時(shí)插入human_approval鉤子觸發(fā)后任務(wù)暫停等人工在 UI 上點(diǎn)確認(rèn)再繼續(xù)。這個(gè)功能在需要高準(zhǔn)確率的場(chǎng)景里非常有用。第三個(gè)技巧是用影子模式做灰度。新配置或者新工具上線前先用影子模式跑——Agent 正常執(zhí)行但新配置的結(jié)果只記錄不生效和舊配置的結(jié)果做對(duì)比。跑一段時(shí)間確認(rèn)新配置確實(shí)更好再切換。DeerFlow 2.0 支持配置shadow_mode指定哪些步驟走影子邏輯。第四個(gè)技巧是日志分級(jí)。Harness 的日志默認(rèn)是 INFO 級(jí)別信息量很大。生產(chǎn)環(huán)境建議調(diào)到 WARNING只在出問(wèn)題時(shí)開(kāi) DEBUG。但有個(gè)例外——工具調(diào)用的輸入輸出建議始終記錄哪怕在 WARNING 級(jí)別。因?yàn)檫@是排查問(wèn)題最關(guān)鍵的線索丟了就得重跑。5. 從 Harness 視角看 Agent 工程的未來(lái)走向5.1 為什么框架會(huì)向運(yùn)行時(shí)演進(jìn)DeerFlow 從 1.0 到 2.0 的演進(jìn)其實(shí)反映了一個(gè)更大的趨勢(shì)Agent 領(lǐng)域的競(jìng)爭(zhēng)焦點(diǎn)正在從能力轉(zhuǎn)向可靠性。第一代 Agent 框架拼的是我能調(diào)用多少工具、我能處理多復(fù)雜的任務(wù)但用下來(lái)大家發(fā)現(xiàn)能力再?gòu)?qiáng)跑不穩(wěn)都是白搭。所以下一階段的框架會(huì)越來(lái)越像運(yùn)行時(shí)——提供穩(wěn)定的執(zhí)行環(huán)境、完善的資源管理、細(xì)粒度的可觀測(cè)性。這跟傳統(tǒng)后端從寫(xiě)業(yè)務(wù)邏輯到依賴中間件的演進(jìn)路徑很像。早期大家什么都自己寫(xiě)后來(lái)發(fā)現(xiàn)數(shù)據(jù)庫(kù)、消息隊(duì)列、緩存這些通用能力應(yīng)該抽出來(lái)做成中間件業(yè)務(wù)代碼只關(guān)注業(yè)務(wù)。Agent Harness 就是這個(gè)思路在 Agent 領(lǐng)域的落地。它把狀態(tài)管理、工具編排、上下文管理、可觀測(cè)性這些通用能力抽出來(lái)讓 Agent 開(kāi)發(fā)者只關(guān)注我的 Agent 要做什么。這個(gè)分工一旦形成Agent 開(kāi)發(fā)的效率和質(zhì)量都會(huì)有質(zhì)的提升。5.2 多 Agent 協(xié)作在 Harness 層怎么落地DeerFlow 2.0 的 Harness 設(shè)計(jì)天然支持多 Agent 協(xié)作。因?yàn)闋顟B(tài)是持久化的、工具是注冊(cè)制的、上下文是隔離的多個(gè) Agent 可以共享同一個(gè) Harness各自跑各自的任務(wù)通過(guò)共享的長(zhǎng)期記憶和消息機(jī)制協(xié)作。一個(gè)典型的模式是規(guī)劃 Agent 執(zhí)行 Agent 審查 Agent三件套。規(guī)劃 Agent 負(fù)責(zé)拆解任務(wù)執(zhí)行 Agent 負(fù)責(zé)具體操作審查 Agent 負(fù)責(zé)質(zhì)量把關(guān)。三個(gè) Agent 通過(guò) Harness 的消息隊(duì)列通信規(guī)劃 Agent 產(chǎn)出計(jì)劃后發(fā)給執(zhí)行 Agent執(zhí)行 Agent 完成后發(fā)給審查 Agent審查不通過(guò)再打回執(zhí)行 Agent。這種模式比單 Agent 全包的好處是職責(zé)清晰、可獨(dú)立優(yōu)化。規(guī)劃不行就調(diào)規(guī)劃 Agent 的 prompt執(zhí)行不行就換執(zhí)行 Agent 的模型互不影響。而且因?yàn)?Harness 記錄了所有消息協(xié)作過(guò)程完全可追溯出問(wèn)題容易定位。5.3 給正在選型 Agent 框架的人幾句實(shí)在話如果你正在選 Agent 框架我的建議是先想清楚你的場(chǎng)景需要什么。如果只是做個(gè) demo 或者簡(jiǎn)單任務(wù)輕量級(jí)框架就夠了上 Harness 反而是過(guò)度設(shè)計(jì)。但如果你要做的是需要長(zhǎng)期運(yùn)行、需要人工干預(yù)、需要審計(jì)追溯的生產(chǎn)級(jí)應(yīng)用那 Harness 這層能力是繞不過(guò)去的。DeerFlow 2.0 在這方面的優(yōu)勢(shì)是它把 Harness 做成了核心而不是附屬。很多框架也有狀態(tài)管理、也有工具注冊(cè)但都是順帶做的深度和完整性不夠。DeerFlow 2.0 是把這些當(dāng)成一等公民來(lái)設(shè)計(jì)的用起來(lái)能感覺(jué)到差別。當(dāng)然它也不是沒(méi)有短板。生態(tài)還在建設(shè)中第三方工具的數(shù)量比不上一些老牌框架文檔雖然全但有些地方不夠細(xì)需要看源碼才能完全理解。不過(guò)考慮到它開(kāi)源不久這個(gè)成熟度已經(jīng)不錯(cuò)了。最后說(shuō)一句Agent 工程這個(gè)領(lǐng)域變化很快今天的最佳實(shí)踐明天可能就過(guò)時(shí)了。與其糾結(jié)選哪個(gè)框架不如把 Harness 這套思路理解透——狀態(tài)機(jī)、工具抽象、分層記憶、可觀測(cè)性這些概念不管用什么框架都是通用的。理解了這些換框架的成本就很低因?yàn)槟阒雷约阂氖鞘裁础?