DeerFlow這個(gè)詞最近在Agent圈子里刷屏頻率相當(dāng)高。它是字節(jié)跳動(dòng)開源的一個(gè)聚焦DeepResearch場景的推理框架核心目標(biāo)就一件事把“深度研究”這種多步、多源、需要交叉驗(yàn)證的復(fù)雜任務(wù)從靠人肉調(diào)Prompt碰運(yùn)氣變成一條工程化的多Agent流水線。我本地部署跑通一整套檢索問答流程后把它的設(shè)計(jì)邏輯、核心模塊、配置參數(shù)和踩坑點(diǎn)都捋了一遍這篇文章就是一份可以直接對著操作的完整筆記適合剛接觸Agent框架的人也適合已經(jīng)在用其他大模型編排工具、想橫向?qū)Ρ确桨覆町惖拈_發(fā)者。1. 先搞清楚DeerFlow到底解決的是什么問題1.1 從“單輪問答”到“多步深度研究”普通的大模型對話是什么樣的你問一句模型答一句回答依賴訓(xùn)練數(shù)據(jù)和有限的上下文記憶。大多數(shù)聊天機(jī)器人本質(zhì)上是在做一個(gè)“單輪生成”任務(wù)頂多是RAG檢索增強(qiáng)生成把相關(guān)文檔塞進(jìn)上下文讓模型基于資料回答。這解決了一些信息時(shí)效性問題但和真正的“研究”還差得很遠(yuǎn)。深度研究DeepResearch的場景是用戶提出一個(gè)開放性問題比如“幫我調(diào)研一下當(dāng)前無人配送車的落地難點(diǎn)”這個(gè)問題本身不是一段話能說清楚的。它需要被拆解成政策法規(guī)、技術(shù)路線、成本結(jié)構(gòu)、頭部玩家、落地案例等多個(gè)子問題每個(gè)子問題要去檢索、篩選、閱讀至少好幾篇資料不同資料里的說法可能互相矛盾需要交叉驗(yàn)證最后還要把幾百頁的原始信息壓縮成一份帶引用的結(jié)構(gòu)化報(bào)告。DeerFlow干的就是這件事。它把“研究”這個(gè)抽象動(dòng)作拆成規(guī)劃、檢索、閱讀、分析、生成幾個(gè)階段每個(gè)階段對應(yīng)專門的模塊再由大模型智能體去編排和調(diào)度。用一個(gè)不準(zhǔn)確的類比普通ChatBot是問路指個(gè)方向就行DeerFlow是派一個(gè)調(diào)研團(tuán)隊(duì)出去組長定提綱組員分頭查資料最后匯總寫報(bào)告。1.2 DeerFlow在Agent生態(tài)里的定位市面上做Agent編排的工具不少有通用型的LangChain、LlamaIndex這類框架也有各種偏對話式的Agent SDK。DeerFlow的差異化在于它不做通用Agent平臺(tái)而是把“深度研究”這一個(gè)場景做深做透。這意味著什么你拿到手的是一個(gè)已經(jīng)定義好的多Agent協(xié)作骨架有Agent負(fù)責(zé)拆解問題有Agent負(fù)責(zé)執(zhí)行搜索有Agent負(fù)責(zé)提煉總結(jié)。你不需要自己從零設(shè)計(jì)Agent之間的消息協(xié)議、任務(wù)狀態(tài)管理和上下文傳遞項(xiàng)目已經(jīng)把這些固定成一套可復(fù)用的模板。加上流程中內(nèi)置了搜索重寫、檢索去重、引用溯源這些深度研究場景特有模塊對做知識(shí)問答、行業(yè)調(diào)研、技術(shù)情報(bào)這類應(yīng)用的人來說上手門檻確實(shí)比用通用框架拼裝要低。1.3 為什么深度研究場景值得一個(gè)專門框架可能有人會(huì)問我用通用框架自己搭一套不行嗎當(dāng)然可以但深度研究這種場景比較特殊有幾個(gè)繞不開的坑一是上下文長度管理。研究一個(gè)復(fù)雜問題可能要搜索幾十次把每個(gè)網(wǎng)頁全文都塞進(jìn)上下文窗口再大也扛不住。必須設(shè)計(jì)一個(gè)“先抽取、再匯總”的中間層把原始網(wǎng)頁轉(zhuǎn)成結(jié)構(gòu)化要點(diǎn)再按需加載。二是任務(wù)規(guī)劃能力。問題怎么拆、拆到什么粒度、先后順序如何安排直接決定檢索質(zhì)量和答案完整度。沒有專門的規(guī)劃模塊大模型很容易拆出重復(fù)或者遺漏的子問題。三是引用溯源。做研究不是聊天用戶需要知道某個(gè)結(jié)論來自哪篇資料。通用RAG能回溯到文檔但DeerFlow會(huì)把每個(gè)信息片段的來源一直帶到最終報(bào)告里形成類似論文引用的效果。這些需求疊在一起用通用框架硬拼當(dāng)然能做但拼出來的系統(tǒng)對開發(fā)者經(jīng)驗(yàn)要求極高。DeerFlow把這套最佳實(shí)踐直接內(nèi)置等于幫開發(fā)者省掉了一輪輪試錯(cuò)。2. DeerFlow核心設(shè)計(jì)思路拆解2.1 多Agent協(xié)作架構(gòu)誰指揮誰執(zhí)行DeerFlow整體是一個(gè)多Agent協(xié)作的流水線按“總指揮-執(zhí)行者-匯總者”的模式運(yùn)轉(zhuǎn)。我建議把它的角色大致理解成四類第一類是研究規(guī)劃Agent輸入用戶問題輸出一個(gè)結(jié)構(gòu)化的研究計(jì)劃包含多個(gè)子問題和優(yōu)先級(jí)。這個(gè)Agent決定“研究什么”。第二類是檢索Agent接收子問題后把它改寫成一個(gè)或多個(gè)適合搜索引擎的查詢詞再從返回結(jié)果中篩選出高價(jià)值鏈接。這個(gè)Agent決定“去哪找”。第三類是內(nèi)容分析Agent對選中的網(wǎng)頁做正文抽取和信息提煉每個(gè)子問題對應(yīng)提煉出若干條帶引用的要點(diǎn)。這個(gè)Agent決定“哪些信息有用”。第四類是報(bào)告生成Agent收集所有中間結(jié)果梳理邏輯線索組織語言生成最終答案或研究報(bào)告。這個(gè)Agent決定“怎么表達(dá)”。這種分工不是憑空拍腦袋核心考量是降低單個(gè)Agent的認(rèn)知負(fù)擔(dān)。如果讓一個(gè)Agent既規(guī)劃又搜索又總結(jié)它在一個(gè)超長上下文中很容易丟失初始目標(biāo)越到后面越跑偏。拆成多個(gè)角色后每個(gè)Agent的上下文是相對聚焦的規(guī)劃Agent只需要安心想問題拆解檢索Agent只需要安心挑鏈接模型的錯(cuò)誤率會(huì)明顯下降還方便并行處理多個(gè)子問題。2.2 檢索層設(shè)計(jì)搜索不是簡單調(diào)APIDeerFlow的檢索層是我覺得最值得學(xué)習(xí)的一塊。它沒有把搜索API的返回結(jié)果直接丟給大模型而是做了好幾層處理。首先是查詢改寫。用戶的子問題往往是句子形式而搜索引擎更適應(yīng)關(guān)鍵詞形式。“當(dāng)前無人配送車在開放道路上的運(yùn)營牌照要求有哪些”會(huì)被改寫成多個(gè)查詢詞變體提高召回。這一步通常會(huì)借助大模型完成但也可以用模板化的關(guān)鍵詞抽取接口。其次是結(jié)果篩選。搜索API返回的鏈接質(zhì)量參差不齊有很多SEO垃圾站、內(nèi)容農(nóng)場。項(xiàng)目會(huì)結(jié)合標(biāo)題相關(guān)性和域名可信度做一輪粗篩有些實(shí)現(xiàn)里還會(huì)用一個(gè)輕量級(jí)打分模型做排序。然后是正文抽取。點(diǎn)開鏈接拿到的網(wǎng)頁有大量導(dǎo)航、廣告、JS代碼DeerFlow會(huì)做正文提取再按長度截?cái)嗷蛘甙炊温浞指钷D(zhuǎn)成后續(xù)Agent能處理的結(jié)構(gòu)化文本塊。這一步非常關(guān)鍵直接影響最終報(bào)告質(zhì)量——如果正文抽取太臟再強(qiáng)的模型也提煉不出干凈的信息。2.3 推理引擎大模型在這個(gè)框架里扮演什么角色DeerFlow本身不是一個(gè)大模型它是一個(gè)大模型編排框架。項(xiàng)目支持對接主流的商用模型接口也支持本地部署的開源模型。不同環(huán)節(jié)對模型能力的要求其實(shí)不一樣。在規(guī)劃和報(bào)告生成環(huán)節(jié)需要較強(qiáng)的推理能力和長文本組織能力建議用能力強(qiáng)的模型。在抽取環(huán)節(jié)主要是從網(wǎng)頁里總結(jié)要點(diǎn)更考驗(yàn)對細(xì)節(jié)的抓取能力用中等規(guī)模的模型通常就夠。項(xiàng)目實(shí)踐中比較好的做法是讓“規(guī)劃模型”和“抽取模型”分開配置而不是所有環(huán)節(jié)都堆同一個(gè)大模型這樣成本和效果都能兼顧。另一個(gè)我覺得值得注意的設(shè)計(jì)是結(jié)構(gòu)化輸出約束。框架會(huì)要求大模型按固定的JSON Schema輸出規(guī)劃結(jié)果和抽取結(jié)果這樣下游解析邏輯才能穩(wěn)定運(yùn)行。如果你自己玩過讓模型輸出JSON就知道不約束的話模型經(jīng)常會(huì)在JSON里夾帶解釋文字。DeerFlow在這塊做了系統(tǒng)級(jí)封裝你調(diào)用時(shí)只需要指定想得到的字段它會(huì)在請求層完成輸出格式的校驗(yàn)和糾錯(cuò)。2.4 狀態(tài)管理與上下文組織信息如何不丟不亂多Agent協(xié)作最大的工程難題是中間狀態(tài)怎么管理。一個(gè)研究任務(wù)會(huì)產(chǎn)生大量中間數(shù)據(jù)研究計(jì)劃、子問題狀態(tài)、每個(gè)子問題的檢索結(jié)果、抽取出的要點(diǎn)、最終報(bào)告草稿。DeerFlow用一套結(jié)構(gòu)化的Task管理機(jī)制來組織這些數(shù)據(jù)。每個(gè)子問題對應(yīng)一個(gè)TaskTask里有自己的狀態(tài)字段待處理、處理中、已完成、關(guān)聯(lián)的搜索結(jié)果列表、抽取出的要點(diǎn)列表。完成一個(gè)子問題后任務(wù)狀態(tài)會(huì)更新報(bào)告生成Agent再從所有已完成Task里匯總數(shù)據(jù)。這種“任務(wù)表 結(jié)果池”的設(shè)計(jì)用工程思維解決了大模型應(yīng)用常見的不穩(wěn)定問題——即使某個(gè)子問題處理失敗也不會(huì)拖垮整個(gè)流水線重啟時(shí)還能跳過已完成任務(wù)。3. 從零搭建環(huán)境準(zhǔn)備與快速啟動(dòng)3.1 環(huán)境要求與依賴安裝先說結(jié)論DeerFlow對硬件不算挑剔因?yàn)橹赜?jì)算都在模型接口側(cè)本地主要跑的是Agent編排邏輯。我實(shí)測下來的基礎(chǔ)要求Python 3.10以上8GB內(nèi)存足夠跑Demo磁盤預(yù)留幾GB放依賴和緩存就夠了。安裝依賴建議用uv或者conda這類虛擬環(huán)境工具盡量不要直接pip裝到全局環(huán)境。拉下倉庫后一般只需執(zhí)行一條安裝命令項(xiàng)目會(huì)把核心依賴裝好。需要注意網(wǎng)絡(luò)環(huán)境部分依賴源在國內(nèi)訪問比較慢如果安裝超時(shí)可以配置鏡像源。依賴版本方面有個(gè)容易踩的坑DeerFlow對大模型SDK版本有一定要求如果你機(jī)器上已經(jīng)裝過舊版本的接口SDK安裝時(shí)可能會(huì)沖突。穩(wěn)妥的做法是新建干凈的虛擬環(huán)境再按倉庫的依賴說明安裝。3.2 配置模型與搜索API跑通DeerFlow前需要準(zhǔn)備兩類外部服務(wù)一類是大模型推理接口另一類是搜索服務(wù)。模型接口方面DeerFlow通常兼容OpenAI格式的調(diào)用協(xié)議這意味著你可以配置任何支持該協(xié)議的提供商無論是云端的商用模型還是本地用vLLM部署的開源模型。配置方式一般是設(shè)置接口地址和API Key環(huán)境變量。以我常用的方式為例我會(huì)在項(xiàng)目根目錄建一個(gè).env文件寫清模型名、接口地址、密鑰這些信息框架啟動(dòng)時(shí)會(huì)自動(dòng)加載。搜索服務(wù)方面項(xiàng)目通常內(nèi)置了搜索提供方的適配器配置方式和模型類似。如果你暫時(shí)沒有付費(fèi)搜索API也可以用免費(fèi)的實(shí)現(xiàn)但檢索質(zhì)量會(huì)打折扣后續(xù)生成報(bào)告的質(zhì)量會(huì)受影響。建議有條件的話直接用主流的搜索服務(wù)商API搜索結(jié)果質(zhì)量是整條鏈路的上限。3.3 跑通第一個(gè)搜索問答Demo環(huán)境配好后跑通第一個(gè)Demo通常用兩種方式一種是直接運(yùn)行倉庫里提供的命令行入口另一種是啟動(dòng)帶界面的本地Web服務(wù)。我第一次跑的時(shí)候用的是命令行方式一條命令傳入問題看到終端里滾動(dòng)輸出每個(gè)子問題的檢索和分析日志最后在輸出目錄里生成一份帶引用的報(bào)告文件。一條典型的調(diào)用鏈路大概是你輸入問題后終端先顯示規(guī)劃Agent生成的子問題列表然后是檢索Agent逐條搜索的日志再是抽取Agent提煉的要點(diǎn)最終生成報(bào)告。整個(gè)過程的詳細(xì)日志都能看到非常有助于理解框架內(nèi)部工作流。如果你只想驗(yàn)證功能測試一個(gè)不太復(fù)雜的問題就行比如“某個(gè)技術(shù)方向的核心挑戰(zhàn)有哪些”。首次運(yùn)行模型接口調(diào)用比較多等待時(shí)間正常在兩三分鐘左右。跑通之后再去換復(fù)雜問題調(diào)參。3.4 配置項(xiàng)解讀與建議下面是我實(shí)測后覺得比較關(guān)鍵的配置項(xiàng)。配置項(xiàng)作用推薦設(shè)置規(guī)劃模型負(fù)責(zé)拆解研究問題選擇推理能力強(qiáng)的模型抽取模型負(fù)責(zé)提煉網(wǎng)頁要點(diǎn)與規(guī)劃模型解耦中檔模型即可搜索API提供檢索結(jié)果優(yōu)先選覆蓋面和時(shí)效性好的服務(wù)商檢索深度每個(gè)子問題搜索次數(shù)從每子問題3-5條結(jié)果起步每輪參考鏈接數(shù)送入抽取層的鏈接數(shù)量控制在5-10個(gè)過多會(huì)稀釋質(zhì)量上下文窗口上限單Agent最大可用上下文按模型上限設(shè)置過小會(huì)截?cái)喾治鲞@里特別提醒一下有些配置項(xiàng)對最終效果影響很大不要照抄默認(rèn)值就完事。比如檢索深度設(shè)得太淺信息覆蓋不足報(bào)告會(huì)顯得單薄設(shè)得太深耗時(shí)和成本成倍增加還可能引入噪聲信息。我習(xí)慣先從小配置起步看報(bào)告質(zhì)量再逐步加深。4. 檢索問答核心流程從提問到成文的全鏈路4.1 意圖拆解與任務(wù)規(guī)劃一個(gè)好的問題等于成功一半我拿一個(gè)具體問題來說?！罢{(diào)研一下當(dāng)前無人配送車的落地難點(diǎn)”直接把這個(gè)句子丟給搜索API返回結(jié)果大概率是泛泛的行業(yè)新聞。DeerFlow的規(guī)劃Agent會(huì)把問題拆成更具體的子問題我實(shí)測到的拆分大致包括無人配送車的技術(shù)成熟度現(xiàn)狀、相關(guān)的合規(guī)與路權(quán)管理要求、商業(yè)化運(yùn)營的成本結(jié)構(gòu)、頭部企業(yè)的產(chǎn)品與融資進(jìn)展、當(dāng)前落地場景和典型案例。這個(gè)拆解質(zhì)量我覺得是決定報(bào)告含金量的第一道關(guān)卡。拆得全面后面的檢索才能覆蓋到位拆得顆粒度合理每個(gè)子問題才能形成獨(dú)立的檢索查詢而不是互相重疊。如果你想在DeerFlow基礎(chǔ)上自己做優(yōu)化最好的切入點(diǎn)是檢查子問題列表看有沒有遺漏的關(guān)鍵角度。4.2 檢索執(zhí)行與信息篩選中間層決定了信息天花板每個(gè)子問題會(huì)進(jìn)入檢索執(zhí)行階段。這里的核心是把子問題改寫成有效的搜索查詢語句然后從搜索引擎返回的結(jié)果列表里篩選出值得深入閱讀的鏈接。篩選階段通?？磶讉€(gè)指標(biāo)標(biāo)題是否回答了子問題的核心疑問、域名是否有可信度、發(fā)布時(shí)間是否夠新。DeerFlow會(huì)把候選鏈接連同摘要信息交給后續(xù)模塊避免把質(zhì)量差的內(nèi)容送進(jìn)抽取環(huán)節(jié)浪費(fèi)模型調(diào)用。有一次我測試時(shí)某子問題返回的鏈接全是泛泛的行業(yè)報(bào)告沒有一篇涉及具體案例導(dǎo)致后續(xù)抽取出的信息非?？辗骸：髞碚{(diào)整了檢索深度和查詢改寫粒度引入了更具體的查詢詞比如把“落地難點(diǎn)”改成“某市無人配送運(yùn)營牌照要求”這種具體問法效果立刻不一樣。4.3 綜合分析與答案生成引用是深度研究的靈魂所有子問題都處理完后報(bào)告生成Agent開始工作。它會(huì)重新讀取用戶原始問題回顧所有子任務(wù)的總結(jié)要點(diǎn)然后組織出一篇有邏輯層次的回答。DeepResearch場景下報(bào)告生成最鮮明的特點(diǎn)就是引用溯源。DeerFlow的抽取階段會(huì)記錄每條要點(diǎn)的來源URL報(bào)告生成時(shí)會(huì)把這些來源帶到最終文本。我看到的輸出報(bào)告里關(guān)鍵結(jié)論后都會(huì)帶上來源標(biāo)記。這一點(diǎn)對深度研究場景極其重要因?yàn)橛脩粜枰藢?shí)信息的真實(shí)性和時(shí)效性尤其是技術(shù)調(diào)研、投資分析這類嚴(yán)肅場景。我在實(shí)際使用中比較欣賞的一點(diǎn)是DeerFlow在生成報(bào)告時(shí)會(huì)把原始資料中互相矛盾的說法都呈現(xiàn)出來而不是只挑一個(gè)作為結(jié)論。深度研究的一個(gè)任務(wù)就是揭示不確定性這一點(diǎn)框架的設(shè)計(jì)考慮到了。4.4 效果調(diào)優(yōu)的關(guān)鍵參數(shù)體驗(yàn)飛一樣的提升如果覺得默認(rèn)配置生成的報(bào)告不夠好我建議按下面的順序去調(diào)第一優(yōu)先調(diào)整檢索質(zhì)量。想清楚你的問題需要什么類型的資料在查詢改寫上多下功夫。第二調(diào)整抽取模型的提示詞或者換更強(qiáng)的抽取模型。很多情況下問題出在抽取環(huán)節(jié)遺漏了關(guān)鍵信息而不是報(bào)告生成環(huán)節(jié)不會(huì)寫。第三調(diào)節(jié)不同模型的溫度參數(shù)。規(guī)劃和分析類任務(wù)建議用低溫度0到0.3追求穩(wěn)定如果報(bào)告讀起來太死板可以適當(dāng)提高報(bào)告生成模型的溫度。還有一個(gè)容易被忽略的點(diǎn)就是給每個(gè)子問題的結(jié)果數(shù)量設(shè)一個(gè)合理的上限。把20條鏈接全部塞給抽取模型反而會(huì)稀釋注意力模型會(huì)在不重要網(wǎng)頁上浪費(fèi)上下文。我的經(jīng)驗(yàn)是優(yōu)先保證前幾條鏈接的信息被充分挖掘比追求數(shù)量更有效。5. 常見問題與排查技巧實(shí)錄5.1 部署階段的高頻報(bào)錯(cuò)環(huán)境問題是最先遇到的。我見過最多的報(bào)錯(cuò)是依賴安裝失敗尤其是大模型接口SDK和系統(tǒng)已裝版本重復(fù)或者互相依賴沖突。解決思路是干凈環(huán)境重新安裝依賴遇到編譯型依賴出錯(cuò)就裝對應(yīng)系統(tǒng)依賴包。搜索API連接失敗也很常見。最典型的癥狀是任務(wù)卡在檢索步驟不再往下走。排查時(shí)先確認(rèn)你已經(jīng)正確設(shè)置搜索API的密鑰確認(rèn)賬戶還有可用額度再確認(rèn)網(wǎng)絡(luò)能正常訪問搜索服務(wù)。我經(jīng)常發(fā)現(xiàn)有些看起來像代碼問題的問題實(shí)際只是密鑰少了一個(gè)前綴或者復(fù)制時(shí)多了個(gè)空格排查的時(shí)候務(wù)必對配置逐字符檢查。模型接口超時(shí)同樣高頻尤其是使用在線模型時(shí)研究任務(wù)特別長單個(gè)Agent調(diào)用鏈可能超過接口超時(shí)限制?？梢园呀涌诔瑫r(shí)參數(shù)調(diào)大或者把研究報(bào)告拆成更短的階段調(diào)用減少單次調(diào)用時(shí)間。5.2 效果類問題答非所問、報(bào)告空泛報(bào)告生成完畢但內(nèi)容空泛是效果類問題的集中體現(xiàn)。遇到這種情況第一排查點(diǎn)不是報(bào)告生成Agent而是中間的信息抽取結(jié)果。先看檢索到的網(wǎng)頁到底有沒有干貨。如果抽取出的要點(diǎn)本身就只是泛泛介紹說明上游鏈接質(zhì)量或者抽取精度出了問題。我遇到過一種典型情況某個(gè)子問題返回的鏈接質(zhì)量都不錯(cuò)但抽取Agent只提取了前幾段的內(nèi)容漏掉了頁面中部的核心數(shù)據(jù)表格。后來換了抽取模型并調(diào)整了抽取指令要求它對數(shù)字和表格信息做重點(diǎn)提取報(bào)告立刻充實(shí)很多。對標(biāo)點(diǎn)引用的準(zhǔn)確性存疑時(shí)可能是網(wǎng)頁正文抽取不干凈導(dǎo)致的。檢查正文抽取環(huán)節(jié)是否把廣告、相關(guān)內(nèi)容區(qū)的文本也帶了進(jìn)來這些噪聲文本會(huì)被模型誤當(dāng)成有效信息來源。這個(gè)排查點(diǎn)操作成本低見效快。5.3 性能與成本怎么取舍深度研究任務(wù)要比普通對話“燒”不少算力主要體現(xiàn)在反復(fù)調(diào)用大模型。一次比較復(fù)雜的調(diào)研規(guī)劃、檢索改寫、抽取、報(bào)告生成加起來可能要調(diào)用幾十次大模型接口。成本控制是實(shí)操中繞不開的話題。我實(shí)際用的策略是分模型配置規(guī)劃和報(bào)告生成用最強(qiáng)模型檢索改寫和抽取用中檔模型。絕大多數(shù)情況下抽取任務(wù)用中檔模型的效果和高端模型差別不大但成本占比很低。如果想讓成本再降就限制檢索深度和每輪鏈接數(shù)這個(gè)參數(shù)直接決定上游需要抽取多少網(wǎng)頁。另一個(gè)切實(shí)可行的做法是開啟結(jié)果緩存。DeerFlow對中間結(jié)果做了持久化。我對同一話題調(diào)整參數(shù)重跑時(shí)之前已經(jīng)完成的子任務(wù)結(jié)果會(huì)直接復(fù)用不用重復(fù)調(diào)用模型和搜索API。這在迭代調(diào)優(yōu)階段能省很多費(fèi)用和時(shí)間。5.4 避坑指南速查表癥狀可能原因排查順序解決方案任務(wù)卡在檢索階段搜索API配置有誤檢查密鑰、額度、網(wǎng)絡(luò)重新配置API細(xì)查環(huán)境變量報(bào)告內(nèi)容泛泛而談上游信息抽取不足檢查抽取結(jié)果再看報(bào)告換抽取模型調(diào)整抽取指令引用來源錯(cuò)誤正文抽取混入噪聲查看原始正文抽取效果優(yōu)化正文提取邏輯清理頁面噪聲模型接口超時(shí)單次調(diào)用鏈過長查看日志超時(shí)位置增大超時(shí)時(shí)間拆分任務(wù)鏈回答遺漏關(guān)鍵子問題規(guī)劃Agent拆分不完整審閱生成的子問題列表重寫問題描述增加背景說明最后再補(bǔ)充一點(diǎn)個(gè)人體會(huì)DeerFlow的價(jià)值不僅僅是它本身更在于它把深度研究這類復(fù)雜任務(wù)的標(biāo)準(zhǔn)解法完整地演示了一遍。我建議拿到手不要光拿來跑Demo而是去讀讀它的Agent消息流轉(zhuǎn)和狀態(tài)管理代碼這些設(shè)計(jì)思路對你自己搭任何多Agent應(yīng)用都有直接參考價(jià)值。跑過幾輪以后你現(xiàn)在再回去看那些單純靠一個(gè)超長Prompt硬撐深度問答的項(xiàng)目會(huì)明顯感受到工程化處理和不處理的區(qū)別。這個(gè)項(xiàng)目迭代蠻快建議你拉到新版本后自己實(shí)測配置項(xiàng)和默認(rèn)值跟著版本更新再核對一遍。