Agent长程搜索的两大痛点被打通了！中科院 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 倍长，它们像雪球一样堆高，把对话空间迅速挤爆。但这些“很长的工具输出”往往只影响“紧接着的下一步决策”，对十几轮之后的决策影响很弱。于是保留所有历史工具输出既浪费上下文，也不划算。

基于这个观察，研究者提出“滑动窗口”上下文管理：

• 把一条多轮轨迹记作 τ = {用户问题 q，助理 a1、工具 t1、助理 a2、工具 t2 …}。

• 设定窗口大小 W 和滑动步长 S。当累计的工具响应数量达到 W，就把更早期的工具响应批量替换成一个占位提示（例如“之前的工具输出已省略，如需请重跑工具”），只保留最近的 W 条工具输出原文；同时，助理自己的推理内容一律完整保留，不做裁剪。这样既不丢“推理脉络”，又把“历史长网页”腾出去。

训练-推理一致（训练时怎么做）

仅仅在推理时滑窗还不够：如果模型是在“完整历史”上训练、却被迫在“滑窗上下文”里推理，就会出现分布不一致，从而不稳。为此，研究者把每条轨迹按推理中的滑窗节奏拆成多段训练序列，让模型在训练期就习惯“有些旧网页被占位符替换”的上下文状态：

• 若一条轨迹有 (T) 次工具调用，则生成

个训练序列；第 1 个序列包含最初的完整上下文；后续第 个序列里，按滑动边界把更早的 换成占位符，只保留窗内的工具原文，以复现推理过程中的真实可见上下文。

• 为避免“重复优化同一段助理输出”带来的冲突，对每个序列做掩码，保证每条助理回复只训练一次。论文里给了一个掩码公式（示意如下），其含义是：在第 (k) 个序列里，只有“新生成的那部分”助理文本参与反向传播，之前出现过的助理文本只当“只读上下文”：

• 这里的位置才计算 loss。这样做就把“推理期的滑窗可见性”一比一复刻到了训练期。

结果与优势（为什么这招比“摘要旧网页”更合算）

• 因为完全不做外部摘要，模型在需要时仍可通过“重跑工具”拿到原始网页内容，没有信息丢失；

• 机制本身不增加一个额外摘要模型的复杂度与算力开销，也更容易纳入端到端强化学习去优化（摘要组件往往是“训练盲点”）；

• 在同样甚至更小的上下文预算下，滑窗法可以把有效互动轮数推得更高：论文报告在32k 上下文就能做到接近 100 轮稳定互动，且在多基准上性能优于“不管理”或“摘要压缩”。表格与图示给出：在 32k/64k/128k 三种限制下，滑窗方案 32k 就达到 ≈33.3%，而另两种策略要到更大上下文才接近这个水平。

训练流程：从冷启动到可验证强化学习

冷启动阶段采用监督微调（Supervised Fine‑tuning）来先把“会用工具、会分步想”的基本功打牢，研究者用能力更强的模型在真实网页环境生成动作轨迹，生成时同样使用动态滑动窗口避免因上下文长度把轨迹掐断，然后把最终答案错误或长度过度的轨迹过滤掉，余下高质量示例经过“多序列构造”训练模型适应动态上下文。强化学习阶段采用组相对策略优化（Group Relative Policy Optimization）来进行策略改进，对同一道题生成多条完整轨迹并依据最终答案是否正确给出可验证的二值奖励，再在组内做标准化得到优势，并把每条轨迹的优势传给它对应的所有训练序列，于是轨迹级的反馈被稳定地用于序列级的参数更新。

具体的工程细节也交代得很实在，基座是 Qwen3‑32B 并启用思考模式，监督微调使用大约3000条高质量轨迹、批大小256、学习率1乘以10的负5次方，强化学习用大约4000个问题、批大小32、学习率2乘以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：主观评测由强模型担任裁判，这是一种常见做法，但也意味着结果在一定程度上受“裁判提示词与模型版本”的影响——研究者在附录给了裁判模板以提高复现性。

相关研究

关于deep search agents，感兴趣您可以再看下这篇综述

华为、牛津联手发布万字报告，揭秘OpenAI、谷歌都在秘密布局的“DR代理”

写在最后

说到底，这套路线把“问题要逼真且难”“上下文要可控且一致”“反馈要可验证且稳定”三件事捏在了一起，才让多轮搜索代理从浅尝辄止变成持续深挖；我更愿意把它看成一种工程视角的整理思路，先守住推理链的连续性，再把最肥的上下文开销按需挪走，最后让训练与推理共享同一种“世界状态”。如果您正把网页搜索、智能分析或企业知识问答做成实用产品，这些改造点完全可以逐步迁入现有系统，不需要推倒重来，就能把“能想多久”和“想得对”这两个老问题同时稳住。

文章来自于微信公众号“AI修猫Prompt”。