智能體長程搜尋的兩大痛點被解決了！中科院 DeepMiner 用 32k 跑近百輪，開源領先逼近閉源

中科院的這項工作解決了「深度搜尋智能體」（deep search agents）兩個實實在在的工程痛點：一是問題本身不夠難，導致模型不必真正思考；另一個是上下文被工具回傳的長文本快速塞爆，導致推理過程提早結束。研究者直面挑戰，同時從資料和系統兩端重塑訓練與推論流程，讓複雜的推理既有用又能跑得起來。

您會看到一個清晰的工程取捨：將「高品質、可驗證且跨來源」的問題做成訓練燃料，將「早期工具輸出」視為可隨時取用的快取，而非永久的負擔，並在訓練與推論過程中保持這種上下文狀態的一致性。結果是很直接的改變，智能體不再被迫在第十幾輪收場，而是在標準 32k 的上下文裡穩穩接住多達近百次的工具互動，過程中的推理鏈也能完整保留。最終讓一個 32B 的中等開源模型，也能在「需要查多個網站、要證據、要推理」的任務上穩定、可解釋、成本可控地運作。這正是許多公司將「AI 研究助理或分析師」做成真正能上線並重複使用的關鍵。

問題到底出在哪？

您可能也遇過這個困境：訓練資料「太淺」，學不出真實的研究型行為。現在開源常用的多跳 QA 資料偏向維基百科式，模型容易靠記憶或單頁檢索「矇對」；上線實作後，遇到橫跨多站點、多時間軸、需要核驗的任務就「不會做」。另一個則是上下文爆炸，長流程撐不住。在 32k 上下文下，有效互動通常只能撐十到十五輪，工具回傳的網頁片段普遍比助理的推理文字長五到十倍，增長最快的部分總是把空間吃光。許多系統使用摘要模型來壓縮工具輸出，不過這樣會丟失資訊粒度、系統耦合度變得更複雜，而且更關鍵的是，它難以納入端到端的可驗證強化學習之中，導致訓練時的最優策略與上線時的行為會出現偏差。

核心思路一：反向建構的複雜問題資料

這部分的目標是：做出必須跨多網頁、多步驟推理才能答對，而且答案可被網頁證據核驗的問題，從而在訓練時逼著模型學會「驗證—回溯—分解子目標—跨文獻綜合」的專家式策略。研究者把這稱為一種「反向建構」（reverse construction）的任務生成法。

具體三步驟

第 1 步：以「實體」為錨點，先把真實網頁證據收集齊（資訊必須足夠、且互補）

• 先從維基百科上篩選人名，但只選「曝光度適中」的人物：太冷門會沒有資料可查，太有名又容易被模型「記在參數裡」直接回憶出來，達不到訓練效果。研究者給出這個「適中」的量化參考是近 6 個月的頁面瀏覽量落在一定區間。隨後圍繞每個實體做兩類檢索：一類是直接搜尋人名取得生平資訊，另一類是新聞檢索取得近期動態，通常能拿到幾十個候選網頁。

• 對收集到的網頁做三重篩選：1. 實體對應性：和維基對照，排除「同名不同人」的混淆；2. 資訊互補性：只保留能提供新增且獨立資訊的頁面，去除「重複說法」；3. 網站可信度：去除不可靠來源，保留可信網站。這樣確保以後出題時，資訊是「散落在多頁」「彼此互補」且「可靠」的。

第 2 步：基於多源證據「出題」，並刻意提高難度（強制多源、禁止維基、再做「二次模糊化」）

• 禁止用維基頁面本身來當證據，避免模型在單一結構化來源裡挖答案；

• 明確要求每道題必須綜合至少四個不同來源的資訊，逼迫「跨文件推斷」，而不是單頁檢索；

• 對已經生成的題目再做一次「二次模糊化」：把「具體指稱」替換成「更泛化的描述」（例如把「7 月 2 日出生」改寫為「21 世紀初出生」這類泛化），但同時要保證答案唯一。這樣模型在搜尋時不能一眼對號入座，必須把「泛化描述」與多個頁面細節逐步對應起來，才能定位唯一答案。這一步就是把「資訊匹配」變成「推理還原」。

第 3 步：雙重過濾——先判「容易題」一律剔除，再判「品質問題」嚴格去除

• 難度過濾：用兩條自動化「探針」來淘汰太容易的題：1. 直接搜尋引擎看能否一步搜到實體或答案；2. 零樣本大型模型看能否直接猜中。任何一條能輕易命中，就不是我們想要的「必須多步、多源」題，全部剔除。

• 品質過濾：把會破壞可核驗性的題一律去掉，包括：1. 表述含糊、容易引發歧義；2. 答案本身含糊或不唯一；3. 答案不能從給定參考文件中邏輯推導出來（即證據鏈不足）。過濾後留下的問答對才是「難且可驗」的高品質訓練樣本。

為什麼這招有效？ 因為它正對現實裡的長程檢索任務：資訊分散、信噪參差不齊、必須跨頁比對與回溯確認。現有許多多跳資料集多依賴結構化維基資訊，容易被「淺層檢索 + 模型記憶」解決，無法誘導出「驗證、回溯、規劃」這些真正的「專家型認知行為」。

核心思路二：動態滑動視窗

為何需要新策略？研究者先做了實證分析：在常見的 32k 上下文裡，多數模型大約 10～15 輪就把上下文用滿了；原因在於工具回傳的網頁內容通常是助理回覆的 5～10 倍長，它們像雪球一樣堆高，把對話空間迅速塞爆。但這些「很長的工具輸出」往往只影響「緊接著的下一步決策」，對十幾輪之後的決策影響很弱。於是保留所有歷史工具輸出既浪費上下文，也不划算。

基於這個觀察，研究者提出「滑動視窗」上下文管理：

• 將一條多輪軌跡記作 $\tau$ = {使用者問題 $q$，助理 $a1$、工具 $t1$、助理 $a2$、工具 $t2$ …}。

• 設定視窗大小 W 和滑動步長 S。當累積的工具回應數量達到 W，就把更早期的工具回應批量替換成一個佔位提示（例如「之前的工具輸出已省略，如需請重跑工具」），只保留最近的 W 條工具輸出原文；同時，助理自己的推理內容一律完整保留，不做裁剪。這樣既不丟「推理脈絡」，又把「歷史長網頁」騰出去。

訓練-推論一致性（訓練時怎麼做）

僅僅在推論時滑動視窗還不夠：如果模型是在「完整歷史」上訓練、卻被迫在「滑動視窗上下文」裡推論，就會出現分佈不一致，從而導致不穩定。為此，研究者將每條軌跡按推論中的滑動視窗節奏拆成多段訓練序列，讓模型在訓練期就習慣「有些舊網頁被佔位符替換」的上下文狀態：

• 若一條軌跡有 (T) 次工具呼叫，則生成 $1 + \lfloor (T - W) / S \rfloor$ 個訓練序列。第 1 個序列包含最初的完整上下文；後續的序列裡，按滑動邊界把更早期的工具呼叫換成佔位符，只保留視窗內的工具原文，以重現推論過程中的真實可見上下文。

• 為避免「重複優化同一段助理輸出」帶來的衝突，對每個序列做遮罩（Masking），保證每條助理回覆只訓練一次。論文裡給了一個遮罩公式（示意如下），其含義是：在第 $k$ 個序列裡，只有「新生成的那部分」助理文本參與反向傳播，之前出現過的助理文本只當「唯讀上下文」：

  

• 只有在助理回覆 $a_i$ 的位置才計算 Loss。這樣做就把「推論期的滑動視窗可見性」一比一重現到了訓練期。

結果與優勢（為什麼這招比「摘要舊網頁」更划算）

• 因為完全不做外部摘要，模型在需要時仍可透過「重跑工具」拿到原始網頁內容，沒有資訊丟失；

• 機制本身不增加一個額外摘要模型的複雜度與算力開銷，也更容易納入端到端強化學習去優化（摘要組件往往是「訓練盲點」）；

• 在同樣甚至更小的上下文預算下，滑動視窗法可以把有效互動輪數推得更高：論文報告在 32k 上下文就能做到接近 100 輪穩定互動，且在多基準上性能優於「不管理」或「摘要壓縮」。表格與圖示給出：在 32k/64k/128k 三種限制下，滑動視窗方案 32k 就達到 ≈33.3%，而另兩種策略要到更大上下文才接近這個水準。

訓練流程：從冷啟動到可驗證強化學習

冷啟動階段採用監督式微調（Supervised Fine‑tuning, SFT）來先把「會用工具、會分步想」的基本功打穩。研究者用能力更強的模型在真實網頁環境生成動作軌跡，生成時同樣使用動態滑動視窗避免因上下文長度把軌跡掐斷，然後將最終答案錯誤或長度過度的軌跡過濾掉，剩餘的高品質範例經過「多序列建構」訓練模型適應動態上下文。強化學習階段採用組相對策略優化（Group Relative Policy Optimization, GRPO）進行策略改進，對同一道題生成多條完整軌跡並依據最終答案是否正確給出可驗證的二值獎勵，再在組內做標準化得到優勢，並將每條軌跡的優勢傳給它對應的所有訓練序列，於是軌跡級的迴饋被穩定地用於序列級的參數更新。

具體的工程細節也交代得很實在，基座是 Qwen3‑32B 並啟用思考模式。監督式微調使用大約 3000 條高品質軌跡、批次大小 256、學習率 $1 \times 10^{-5}$。強化學習使用大約 4000 個問題、批次大小 32、學習率 $2 \times 10^{-6}$。每個問題生成 8 條 rollout，最大軌跡長度四萬 Token、單題回合上限 60，工具視窗大小設定為 5、滑動步長為 3，訓練實作基於 VERL 框架；評估時在 BrowseComp、BrowseComp‑zh、XBench‑DeepSearch 與 GAIA 上統一使用溫度 0.6、top‑p 0.9、最多一百輪互動，並同樣使用視窗 5 加滑動 3 的上下文管理，同時由評審模型以結構化提示詞判定最終答案的正確性。

工具套件與互動細節：三項工具就夠用

許多人第一反應是再加一個摘要模型幫忙壓縮網頁內容，不過研究者把重心放在「讀什麼、怎麼讀、讀到哪一頁就停」。他們只保留三個輕量而高槓桿的工具：用搜尋服務拿到標題、連結和摘要，用抓取服務按分頁把網頁轉換成可捲動的 Markdown 文字，再用頁內查找在長文中定位關鍵詞和附近語境，從而讓模型像人一樣先粗看輪廓再決定是否深讀。您可以把它理解成「把主動權交給代理」，它可以在一頁頁的內容中快進、暫停、退出，而不是被一次性塞進幾千字然後被動消化；因為不做外部摘要，資訊細節不會被提前裁切，端到端訓練也不會出現「看不到真實文本」的優化斷層。

實務演練：一個真實問題是如何被解決的

研究者在附錄裡給了一個案例軌跡，問題要求在蕪雜的線索中鎖定唯一歷史地點，條件涉及是否位於國家首都、是否臨河、開工與完工年份範圍、牆體厚度的數值區間、是否經歷特定時間段的龍捲風與地震破壞、是否在 1980 至 1990 年間被政府收購以及收購當時總統的出生年份落點。這類題目逼著代理跨多個網頁反覆核驗並在必要時回頭重查。在工具配合上，先用搜尋服務摸清候選，再用抓取服務分頁細看關鍵頁面，再透過頁內查找迅速跳到關鍵詞附近段落，同時滑動視窗持續把很早的工具長文本移走、把思考過程完整保存。最後鎖定的答案是達卡的 Ahsan Manzil，整個過程把「跨來源拼接事實與交叉驗證」的套路走得很穩，既沒有依賴內部記憶，也沒有依賴一刀切的摘要。

• 先用搜尋定位與條件相關的候選建築，並記錄它們是否位於首都城市以及是否緊鄰河流兩項資訊，以便快速排除明顯不符的對象。

• 對最有希望的候選使用抓取服務逐頁閱讀，重點核對開工年份與竣工年份是否落在指定閉區間之內，並同時留意頁面是否提及牆體結構與厚度等工程細節。

• 借助頁內查找定位「tornado」「earthquake」等關鍵詞，逐項確認是否存在 1880 至 1890 年的龍捲風破壞記錄，以及 1890 至 1900 年的地震破壞記錄，並比對日期是否嚴格落在範圍內。

• 繼續在同一實體的不同來源中比對「政府收購」的年份，並交叉驗證該年份對應的國家總統是誰，以及這位總統的出生年份是否位於 1920 至 1935 的閉區間內，從而閉合約束鏈。

• 對「牆體厚度」這種不常見於百科摘要的細節，轉向更專業或地方性的資料來源進行補充檢索，再把數值與既有條件核對，確保所有條件同時成立而非各自孤立滿足。

• 在整個查證過程中維持滑動視窗，讓早期工具長文本被佔位提示替代，如果資訊不確定便再次呼叫工具重新抓取原文，這樣既不丟失可追溯性，也不讓上下文被歷史片段拖垮。

實驗結果與可重現設定

把路修平之後，數字表現就能直接說明問題。

研究者在四個「深度網頁研究型」基準上測試模型：

這些基準都屬於需要真實網頁工具的任務，也就是：問題答案不能直接從模型記憶裡取，而必須查網頁、整合、驗證。

DeepMiner‑32B 在 BrowseComp‑en 上給出 33.5 的正確率，相比此前開源代理的區間有明顯提升，而且在 BrowseComp‑zh、XBench‑DeepSearch 與 GAIA 上也呈現同向改進；更有參考意義的是監督式微調版的表現，它在不少基準上已經超過諸多開源代理。這組成績意味著 DeepMiner 在開源體系裡達到了「接近商用等級」的深度網頁推理效果。這提醒我們「高難度且可驗證的資料」本身就能帶來收益，然後在可驗證強化學習與動態上下文的配合下再進一步。評測統一採用溫度 0.6 與 top‑p 0.9 的解碼設定、最多一百輪的互動上限，以及視窗 5 加滑動 3 的上下文管理，同時使用結構化的評審提示詞讓判定過程可追溯，這些細節對您在本地重現會非常關鍵。

滑動視窗機制的效果驗證

這部分單獨測量了三種上下文管理策略的差異：

然後在 64k 和 128k 的上下文長度下再次比較：

• 不管理的方案性能增長很慢，因為網頁太長、雜訊多；

• 摘要方案略有提升，但仍然不及滑動視窗；

• 滑動視窗方案在 32k 時就已達到 128k 摘要方案的性能。

結論：滑動視窗管理不僅節省上下文，還能保持推理穩定性；同等上下文容量下，它能讓模型多推理出將近 4～6 倍的輪數。

研究者在實驗圖中展示了不同上下文長度下三種策略的曲線：滑動視窗曲線幾乎在 32k 時就達到頂峰，而其他方法要到 128k 才接近。

這項工作的意義在哪裡？

• 將「深度搜尋」兩大痛點一併打通：一方面用「反向建構 + 多源合成 + 模糊化 + 嚴格過濾」把訓練任務變「難且真」；另一方面用「滑動視窗」從機制上延長多輪推理的「可持續長度」，而且訓練與推論同分佈，不靠額外摘要模型，不丟細節，不增加系統複雜度。

• 資料效率與能力遷移：即便只是 SFT，也能顯著超越用 HotpotQA 等傳統多跳資料訓練的模型，說明建構的資料更貼合「網頁深研」的真實需求；再疊加 RL，能力持續抬升。

• 工程可行性：在常見的 32k 上下文裡，仍能將互動輪數推向約 100 輪，這對實際系統很關鍵，因為單純擴大上下文（到 128k 甚至更大）帶來的代價很高。

可能的局限與注意點

• 資料與倫理：訓練資料來源於公開網頁，但難免包含個人資訊；研究者承諾只取公開站點、過濾不規範站點與社群媒體，發佈前做匿名化，並對權重開放設置訪問審查，以降低濫用風險。

• 評測裁判依賴 LLM：主觀評測由強模型擔任裁判，這是一種常見做法，但也意味著結果在一定程度上受「裁判提示詞與模型版本」的影響——研究者在附錄提供了裁判模板以提高重現性。

關於深度搜尋智能體，感興趣您可以再看下這篇綜述：

華為、牛津聯手發布萬字報告，揭密 OpenAI、Google 都在祕密佈局的「DR 代理」

結語

說到底，這套路線將「問題要逼真且難」、「上下文要可控且一致」、「迴饋要可驗證且穩定」三件事融合在一起，才讓多輪搜尋代理從淺嘗輒止變成持續深挖。我更願意把它看成一種工程視角的整理思路：先守住推理鏈的連續性，再將最肥大的上下文開銷按需求挪走，最後讓訓練與推論共享同一種「世界狀態」。如果您正將網頁搜尋、智慧分析或企業知識問答做成實用產品，這些改造點完全可以逐步遷入現有系統，不需要推倒重來，就能把「能想多久」和「想得對」這兩個老問題同時穩住。