過去半年我在 Agent 論文和工業(yè)落地之間來回橫跳最深的感受是Agentic RAG 和深度研究這兩個詞已經(jīng)被用到快沒有邊界了。搜索引擎、企業(yè)知識庫、論文總結(jié)工具全都往“深度研究”上靠但真正能打通“檢索 → 證據(jù)核驗 → 長程任務(wù)執(zhí)行 → 可控成本”這條鏈路的方案屈指可數(shù)。這篇文章是《Agent 論文和工業(yè)界實戰(zhàn)總結(jié)》的第二篇聚焦 Agentic RAG 和深度研究這條線。我會先把論文里反復(fù)出現(xiàn)的架構(gòu)共性講明白再給出一套我在工業(yè)項目里實際用過的方案最后聊效率邊界——也就是哪些任務(wù)值得上 Agent哪些任務(wù)用 Agent 純屬浪費預(yù)算。1. Agentic RAG 到底在解決什么問題1.1 傳統(tǒng) RAG 的三個死穴先統(tǒng)一一下認知傳統(tǒng) RAG 就是那套“查一遍就回答”的流水線用戶問題 → embedding 召回 top-k → 拼上下文 → 讓模型生成答案。這套東西在社區(qū)和產(chǎn)品里跑了兩年多夠用但也捅出了不少婁子。我印象最深的一個場景某自動駕駛公司做事故歸因分析業(yè)務(wù)方問“上周深圳試點區(qū)域三起事故的共性是什么”。傳統(tǒng) RAG 拿到這句話后直接向量檢索召回的是一堆碎片化片段有的講天氣有的講傳感器有的講路口設(shè)計彼此之間沒有鏈條。最后模型強行綜合輸出一份看似流暢、實則每個判斷都缺乏確鑿出處的報告。業(yè)務(wù)方追問一句“你說‘夜間占比高’依據(jù)是哪個文檔的哪個章節(jié)”當場答不上來。這就是傳統(tǒng) RAG 的三個死穴第一單次查詢的歧義和缺失一個問題往往有多個子意圖一次 embedding 檢索只能表達一層含義第二多跳信息鏈條斷裂A 文檔定義概念B 文檔描述現(xiàn)象C 文檔給出數(shù)據(jù)需要串聯(lián)三層信息一步檢索做不到第三無法自我糾錯檢索結(jié)果為空或者質(zhì)量差的時候系統(tǒng)沒有修正機制只能硬著頭皮生成于是幻覺就來了。1.2 把檢索權(quán)交給模型本身Agentic RAG 的核心變化只有一句話把“檢索什么、要不要檢索、檢索結(jié)果夠不夠”這個決策權(quán)從相似度計算交還給模型。傳統(tǒng) RAG 里檢索是固定動作Agentic RAG 里檢索是模型根據(jù)當前信息缺口動態(tài)觸發(fā)的一個工具調(diào)用。我自己理解這套東西喜歡用“人查資料”來類比。一個人接到陌生問題不會只搜一次就寫結(jié)論他會先搜一輪泛讀發(fā)現(xiàn)某個術(shù)語不懂再針對性搜術(shù)語解釋找到一份來源但覺得不夠權(quán)威換成官方文檔查證最后發(fā)現(xiàn)某個關(guān)鍵數(shù)據(jù)缺失繼續(xù)補一次定向檢索。Agentic RAG 就是把這套行為顯式化模型每走一步都能看到當前已收集的證據(jù)、還缺什么、下一步該搜什么。這里繞不開論文。ReAct 提出推理軌跡和動作交替執(zhí)行的框架是“思考→行動→觀察”的雛形Self-RAG 更進一步讓模型在 generate 前判斷是否需要檢索并生成 IsRel、IsSup、IsUse 這類反思信號決定答案是足夠支撐還是需要補充檢索CRAGCorrective RAG則給檢索結(jié)果加了“評估-修正”的動作如果檢索質(zhì)量差不是簡單放棄而是觸發(fā)修正檢索。到了 STORM 這類長文研究系統(tǒng)多輪頭腦風暴生成問題清單、再并行檢索寫作的思路基本就是今天深度研究產(chǎn)品的論文形態(tài)。1.3 論文里反復(fù)出現(xiàn)的架構(gòu)共性我把 Agentic RAG 和深度研究相關(guān)的十幾篇論文放一起看發(fā)現(xiàn)架構(gòu)上高度趨同逃不出四個組件規(guī)劃器Planner負責把主問題拆成子問題生成檢索計劃和查詢詞。工具層Tool Layer封裝向量檢索、網(wǎng)頁搜索、數(shù)據(jù)庫查詢、文檔閱讀器等能力模型按需調(diào)用。工作記憶Working Memory存已收集的證據(jù)、中間結(jié)論、待辦事項通常以結(jié)構(gòu)化筆記或摘要形式存在。反思門Reflection Gate在回答前評估證據(jù)充分性、一致性、信源可信度決定繼續(xù)檢索還是直接作答。這個共性值得強調(diào)因為很多工業(yè)方案把 Agent 做得花里胡哨本質(zhì)還是在給這四個組件堆裝飾。看清楚這個骨架后面做工程選型、加功能、排查問題時心里會非常有底。2. 深度研究的核心鏈路從問題拆解到長程執(zhí)行2.1 問題拆解好的查詢是成功的一半深度研究的第一道關(guān)卡不是檢索而是把模糊問題變成一組可檢索、可驗證、互不重疊的子問題。規(guī)劃這一步做不好后面每一步檢索都是浪費。我在實際項目里常用的拆解策略有三種改寫把口語問題改成適合檢索的查詢詞、分解把多跳問題拆成多個單跳子問題、假設(shè)枚舉對研究性任務(wù)列出候選假設(shè)逐個去驗證。比如“生成式 AI 在金融風控中的應(yīng)用趨勢”我不會讓 agent 直接搜這一句話而是讓它拆成生成式 AI 風控的典型場景、頭部機構(gòu)的落地案例、監(jiān)管態(tài)度與合規(guī)約束、技術(shù)瓶頸與評估指標、近一年公開報告的結(jié)論變化。規(guī)劃提示詞里我會強制模型輸出 JSON 格式的子問題列表每個子問題帶上預(yù)期檢索源類型官方報告、論文、新聞、論壇和優(yōu)先級。這樣做的好處是子問題可并行執(zhí)行而不是讓 agent 一步一步線性推進同時每個子問題的檢索結(jié)果獨立評估出了問題定位也快。這里的實操心得是不要迷信模型一次就能拆出高質(zhì)量子問題。我通常會讓模型先拆一輪再用一個輕量檢查步驟去重、補漏、刪掉明顯超出任務(wù)范圍的子問題。這個小門神幫我減少了不少無效檢索。2.2 多步檢索的策略選擇檢索策略不是越復(fù)雜越好要看任務(wù)形態(tài)。我按經(jīng)驗把策略分成三類策略適用場景特點風險順序迭代檢索問題依賴強需要逐步深入ReAct 式思考-行動循環(huán)每步依賴上一步結(jié)論步數(shù)多、延遲高并行子問題檢索子問題彼此獨立一次拆解多個查詢并發(fā)執(zhí)行大幅降延遲上下文拼接成本高混合策略先廣后深第一輪并行泛覽再對關(guān)鍵缺口順序深挖實現(xiàn)復(fù)雜度高但兼顧質(zhì)量與速度實踐里一個標準的深度研究任務(wù)我會用“先并行、后順序”的混合策略。比如研究“多模態(tài)大模型在工業(yè)質(zhì)檢中的落地”第一輪并行搜市場報告、技術(shù)論文、標桿案例、供應(yīng)商方案每個分支獨立跑第一輪結(jié)果回來后規(guī)劃器判斷哪些分支證據(jù)薄弱或存在矛盾鎖定兩三個關(guān)鍵缺口再做第二輪順序深挖。下面給一個最簡的 Agentic RAG 主循環(huán)偽代碼這是我自研方案里最核心的骨架# 最簡 Agentic RAG 主循環(huán)偽代碼 def research_agent(question): notes [] for step in range(max_steps): plan llm.plan( questionquestion, notesnotes, historydecision_log ) action plan[action] # search | verify | answer if action answer: return llm.answer(question, notes) docs search(plan[query], top_k8) evidence extract_evidence(docs, plan[query]) notes merge_into_notes(notes, evidence) verdict llm.judge( questionquestion, notesnotes, missingplan.get(gaps, []) ) if verdict[sufficient]: return llm.answer(question, notes) if verdict[contradiction]: notes.append(additional_search_for_resolution(verdict[conflict])) return llm.answer(question, notes)注意幾個關(guān)鍵點merge_into_notes不是簡單把文本拼進上下文而是做去重、溯源、按子問題歸類llm.judge是成本最高的調(diào)用我控制它的頻率只有當新增證據(jù)達到閾值或者出現(xiàn)矛盾時才觸發(fā)max_steps一定要設(shè)硬上限否則長任務(wù)會無限發(fā)散。2.3 長程任務(wù)的記憶與狀態(tài)管理深度研究和普通 RAG 的最大差異是長程——任務(wù)動輒十幾步、幾十步上下文窗口再大也會被塞爆。很多人第一步就搞錯把所有檢索結(jié)果一股腦塞進 prompt結(jié)果就是早期信息被稀釋、模型注意力漂移、回答質(zhì)量斷崖式下跌。我的方案是結(jié)構(gòu)化工作筆記scratchpad代替全文拼接。每個子問題對應(yīng)一組證據(jù)條目每條證據(jù)保存來源 ID、原文引用片段、提取出的關(guān)鍵斷言、業(yè)已驗證狀態(tài)。規(guī)劃和反思時只讀摘要級筆記只有到最終組織答案時才引用完整證據(jù)片段。一個典型的狀態(tài)對象長這樣{ task_id: deep-research-1024, sub_questions: [ 生成式AI在風控中的典型場景, 頭部機構(gòu)落地案例, 監(jiān)管約束與合規(guī)要求 ], evidence: { claim_A: [ {source: s3, quote: 某銀行將生成式AI用于反欺詐規(guī)則生成準確率提升7%}, {source: s7, quote: 同一案例在行業(yè)報告中的二次描述} ], claim_B: [{source: s5, quote: 某地監(jiān)管要求算法備案與人工復(fù)核}] }, pending: [需要確認 claim_A 的時間范圍是否為2024-2025], decision_log: [ 已排除來源s2非官方博客且與s5矛盾, 已確認s3與s7為同一事件的不同報道可交叉引用 ] }這個設(shè)計帶來的直接收益上下文占用可控每步新增的 token 只增量增長可觀測性極好出問題直接看 decision_log 和 pending可緩存同一個子問題的證據(jù)做 key-value 緩存后續(xù)任務(wù)直接復(fù)用。3. 證據(jù)核驗讓檢索結(jié)果經(jīng)得起追問3.1 引用溯源能力的工程化深度研究產(chǎn)品能不能被信任核心指標是引用精度citation precision——也就是每條斷言是否有對應(yīng)來源支撐來源是否是真實可查的。工業(yè)落地時我強制要求三件事第一句子級引用。答案的每個關(guān)鍵斷言后面必須掛來源編號引用粒度是句子而不是整段。這需要在生成提示詞里寫死規(guī)則并讓模型先出示證據(jù)、再寫結(jié)論。第二引用即約束。模型只能基于已檢索到的內(nèi)容作答禁止輸出檢索范圍之外的信息。我用一個硬性校驗生成完成后逐句檢查斷言是否能在 notes 中找到對應(yīng)的 quote。找不到就標記為疑似幻覺觸發(fā)修正或刪除。第三信源分級。不同來源的可信度權(quán)重不同我在狀態(tài)對象里給每條證據(jù)標注來源類型官方文檔/權(quán)威論文權(quán)重最高行業(yè)媒體次之論壇和自媒體最低。組織答案時優(yōu)先采用高權(quán)重來源低權(quán)重來源只作為補充視角。3.2 多源交叉驗證與矛盾處理證據(jù)核驗的第二層是交叉驗證。一條關(guān)鍵斷言我要求至少有兩個獨立來源支撐才能寫進最終答案。所謂“獨立”是指來源之間沒有轉(zhuǎn)載關(guān)系——同一篇新聞稿轉(zhuǎn)載一百次本質(zhì)上還是一個來源。實際工程里我做了個簡單的“證據(jù)一致性打分”把對同一斷言的多個證據(jù)片段喂給輕量模型讓它輸出“一致 / 沖突 / 互為補充”三類標簽。一致的進入可信證據(jù)池沖突的單獨列出來不讓它混入結(jié)論互為補充的可以合并描述。這里最反直覺的一點是不要試圖強行消除矛盾。真實世界的資料就是會有沖突比如不同機構(gòu)對同一指標給出不同統(tǒng)計口徑。深度研究產(chǎn)品要做的是把分歧呈現(xiàn)出來告訴用戶“來源 A 說 X來源 B 說 Y差異原因是統(tǒng)計口徑不同”而不是硬造一個統(tǒng)一結(jié)論。我在產(chǎn)品里專門留了一個“爭議點”區(qū)塊用戶反饋反而比“看似完美的統(tǒng)一答案”更信任我們。3.3 自我批判與對抗回讀模型是生成器也是最好的批判者。論文里 Self-RAG 的反思信號、CRAG 的檢索修正本質(zhì)上都是在引入一個自我評估回路。工業(yè)落地時我在最終答案出來前加一道對抗回讀adversarial re-read讓模型扮演一個挑刺的審核員針對答案里的每個關(guān)鍵斷言反向?qū)ふ曳醋C或證據(jù)缺口。我在提示詞里這么寫你是一名嚴格的證據(jù)審核員。以下是待審核答案和它引用的證據(jù)集。 對答案中每個關(guān)鍵斷言執(zhí)行 1. 指出該斷言對應(yīng)的證據(jù) quote 2. 判斷 quote 是否完整支持斷言警惕過度推斷、范圍擴大 3. 列出證據(jù)集中可能推翻該斷言的反證條目 4. 輸出結(jié)論通過 / 需修改 / 需補充檢索。 只輸出 JSON。這道工序每輪任務(wù)會增加一次到兩次模型調(diào)用但收益巨大。實測下來深度研究答案的“斷言-證據(jù)匹配率”能從七成左右提升到九成以上而且很多模型自作主張的過度推斷都會被篩出來。如果你的系統(tǒng)對答案正確性要求高這一步絕對不能省。4. 工業(yè)界實戰(zhàn)一條能扛住真實流量的深度研究方案4.1 工具與框架選型先說框架。我不建議一上來就套重型框架。LangGraph、Dify、CrewAI 我都試過Dify 做原型驗證最快拖拽界面十幾分鐘能跑通一個 agentCrewAI 的多角色編排很直觀適合演示但生產(chǎn)環(huán)境我更傾向 LangGraph 或者直接自研主循環(huán)。原因很簡單深度研究對狀態(tài)控制、可觀測性、步數(shù)管理與緩存的要求非常具體低代碼工具到了這個復(fù)雜度會變成束縛。檢索后端我采用混合檢索方案BM25 文本檢索 向量檢索并行再用 RRFReciprocal Rank Fusion融合排序。向量庫我用過 Milvus、Qdrant、pgvector結(jié)論是中小規(guī)模 pgvector 夠用百萬級以上文檔量直接上 Milvus。重排層用 cross-encoder 模型做精排把融合后的 top 30 壓縮到 top 8。這一步對最終答案質(zhì)量影響非常大不能省。4.2 關(guān)鍵工程細節(jié)并行、緩存與重排深度研究延遲和成本的敵人是串行調(diào)用。我在工程上做了三層優(yōu)化并行子查詢拆解出的子問題用 asyncio 并發(fā)執(zhí)行控制并發(fā)數(shù)為 6 左右避免打爆檢索服務(wù)。第一輪檢索的墻鐘時間能從 30 秒壓到 8 秒左右。查詢級緩存與證據(jù)級緩存相同或相似查詢直接命中緩存檢索回來的文檔片段按內(nèi)容哈希去重重復(fù)訪問同一來源時不重復(fù)計費也不重復(fù)進上下文。緩存命中率高的時候研究任務(wù)的 token 成本能降四成。動態(tài) top-k 與自適應(yīng)預(yù)算不固定每次檢索返回數(shù)量。泛覽階段 top_k 給 10深挖階段給 4。步數(shù)上限按問題復(fù)雜度動態(tài)分配簡單問題 4 步中等 6 步復(fù)雜報告類任務(wù)給到 12 步。下面是我常用的配置樣例可以直接抄RETRIEVAL_CFG { top_k_hybrid: 30, rerank_top_k: 8, chunk_size: 1024, chunk_overlap: 128, parallel_workers: 6, step_cap: 8, reflection_frequency: 3, latency_budget_s: 45, source_cache_ttl_h: 24 }幾個參數(shù)的解釋chunk_size 1024 是經(jīng)驗值太小碎片化嚴重、信息不完整太大噪音多、檢索精度下降reflection_frequency 3 表示每 3 步做一次全局證據(jù)評估而不是每步都做省掉大量重復(fù)判斷l(xiāng)atency_budget_s 是硬性預(yù)算超過直接進入收尾作答避免用戶等太久。4.3 成本、延遲與效率邊界這是我這篇文章最想展開的部分。效率邊界不是一個模糊概念它是可以量化衡量的。直接說實測數(shù)據(jù)單輪傳統(tǒng) RAG 的端到端延遲在 2 到 4 秒單次調(diào)用成本約 0.02 到 0.05 元Agentic RAG 帶反思、多步檢索后延遲會到 10 到 30 秒成本翻 3 到 5 倍深度研究任務(wù)拆解 5 到 10 個子問題、多輪深挖、最終成文延遲通常在 30 秒到 3 分鐘成本是傳統(tǒng) RAG 的 10 到 20 倍。所以我給團隊立了一條非常明確的分流規(guī)則信息密度低的直接問答走傳統(tǒng) RAG需要跨源交叉、多條件約束、窮舉綜述的任務(wù)才走深度研究。比如“公司年假制度是什么”這種事實型問題用深度研究就是拿大炮打蚊子多出的成本和延遲完全無意義而“對比三家供應(yīng)商的架構(gòu)方案并給出選型建議”這種綜合分析型問題才值得動用完整鏈路。另一個效率邊界是反思步數(shù)的邊際收益遞減。我做過統(tǒng)計在 12 步上限的任務(wù)里前 6 步的檢索覆蓋率提升最明顯到第 8 步之后每多一步增加的“有效新證據(jù)”數(shù)量驟降。因此我在產(chǎn)品里設(shè)置了早停機制——當連續(xù)兩次反思都判定“證據(jù)充足、無新增缺口”時直接進入生成階段不再機械執(zhí)行剩余步數(shù)。這個機制能把平均步數(shù)從 9 壓縮到 6質(zhì)量幾乎無損。深度研究的性能邊界還體現(xiàn)在任務(wù)類型上它擅長“知識報告類”任務(wù)比如行業(yè)調(diào)研、競品分析、技術(shù)選型、論文綜述不擅長需要實時數(shù)據(jù)的操作型任務(wù)比如航班查詢、股價快照、庫存狀態(tài)。后者應(yīng)該接 API 而不是接檢索 agent。這一點在設(shè)計產(chǎn)品之初就要想清楚否則做出來的東西既慢又貴用戶的耐心撐不了幾次。5. 常見問題排查與避坑清單5.1 檢索漂移與重復(fù)檢索我遇到最多的問題就是檢索漂移agent 越搜越偏從“生成式 AI 在風控中的應(yīng)用”一路漂到“大模型的訓練成本”完全離題。排查下來根源通常是規(guī)劃器中缺少范圍約束或者反思門沒有對比“當前檢索結(jié)果與主問題的相關(guān)性”。解決辦法給規(guī)劃器加一個scope_check步驟每次生成子查詢前先過一遍主問題的主題關(guān)鍵詞同時給反思門加“離題檢測”當檢索結(jié)果的語義相似度低于閾值時強行拉回主問題并丟棄無關(guān)證據(jù)。另外重復(fù)檢索同一來源的問題也要靠緩存加狀態(tài)檢查來堵我要求 agent 在生成查詢前先看 evidence 里是否已有該來源命中就直接跳過。5.2 證據(jù)與答案不一致癥狀是答案看著比證據(jù)“豐富”很多模型擅自補了檢索結(jié)果里沒有的細節(jié)。這種往往是提示詞里的約束不夠硬或者反思門沒有對最終的斷言做逐條校驗。我現(xiàn)在的做法是三層兜底生成階段提示詞里寫死“只能用給定證據(jù)”生成后用對抗回讀逐條比對斷言和 quote比對不過的句子要么刪除要么觸發(fā)一次補充檢索。三層下來答案和證據(jù)的不一致率已經(jīng)壓到很低但代價是多花一次模型調(diào)用項目要結(jié)合成本預(yù)算取舍。5.3 長任務(wù)死循環(huán)與上下文爆炸長程任務(wù)跑著跑著就出問題的場景很常見某一步的工具返回格式異常agent 重試同樣的動作或者 notes 越攢越多prompt 超長模型開始胡言亂語。我的經(jīng)驗是給系統(tǒng)上四道保險硬步數(shù)上限step_cap超了就強制進入 finalize哪怕質(zhì)量打折工具錯誤重試上限最多重試 2 次換用摘要模式或直接跳過筆記窗口滑動保留最近的證據(jù)全文 早期證據(jù)的摘要防止上下文膨脹checkpoint 所以每完成一個子問題就把狀態(tài)對象落庫任務(wù)中斷可以從中斷點恢復(fù)。5.4 評估與回歸深度研究系統(tǒng)改一版提示詞就可能在看不見的地方劣化沒有評估體系等于裸奔。我搭了一套輕量評估集50 道多跳問題覆蓋事實型、對比型、綜述型三類每次改動后跑一遍記錄四組指標——引用精度斷言有引的比例、答案正確率用 LLM judge 打分、檢索命中率證據(jù)中包含關(guān)鍵信息的比例、效率指標平均步數(shù)和延遲。這里分享一個經(jīng)驗LLM judge 評估答案質(zhì)量時要把“引用精度”單獨打分不要混在“答案正確性”里?；煸谝黄饡屧u分失去診斷價值——一個答案可能內(nèi)容全對但是引用是編的這種情況下必須判定為不合格否則流到線上就是事故。寫在最后這套內(nèi)容我踩了不少坑才慢慢成型。如果只留一條建議那就是從最簡的 agent loop 開始先跑通檢索-反思-作答三步再逐步加并行、交叉驗證、對抗回讀這些重型武器。不要一開始就上多 agent 辯論、復(fù)雜圖編排復(fù)雜度一旦上來排查問題的成本會指數(shù)級上漲。深度研究目前最適合的定位是“知識報告類任務(wù)”——一個人要花兩三天才能完成的資料收集和綜述agent 用幾分鐘給出一份可溯源、有據(jù)可查的初稿。后續(xù)我還在試的方向是把結(jié)構(gòu)化的領(lǐng)域知識圖譜接進證據(jù)核驗環(huán)節(jié)讓“交叉驗證”不再只靠文本相似度而是能對實體、關(guān)系層面的矛盾做判斷扛得住更刁鉆的追問。