多搜少想：重新思考长期智能体搜索的效率与泛化 Search More, Think Less: Rethinking Long-Horizon Agentic Search for Efficiency and Generalization
通过并行证据采集替代顺序推理，实现高效且泛化的长期智能体搜索
前置知识
长期智能体搜索（Long-Horizon Agentic Search）
指需要多步骤工具调用和推理的复杂信息检索任务。与简单的单次搜索不同，这类任务需要智能体在多个时间步内与外部工具（如搜索引擎、网页爬虫）交互，逐步收集和整合证据。典型场景包括多跳问答、深度研究等，任务完成可能需要数十甚至数百次工具调用。
本文的核心研究对象就是长期智能体搜索，理解这一概念是理解论文所有技术创新的基础。
并行证据采集（Parallel Evidence Acquisition）
与传统智能体顺序执行一个推理步骤不同，并行证据采集允许智能体在同一时间步内同时执行多个子任务的工具调用。例如，当需要从多个网页收集信息时，传统方法会依次访问每个网页，而并行方法会同时发起多个请求，显著提高信息获取密度。
这是本文最核心的技术创新——SMTL框架的基础设计，理解它才能理解论文为什么能在效率和性能上取得突破。
强化学习与RLOO算法
强化学习（RL）是通过与环境交互来学习最优策略的方法。RLOO（REINFORCE Leave-One-Out）是一种策略梯度算法，相比GRPO提供无偏的优势估计。本文对RLOO进行了改进，采用token级损失函数、序列级重要性采样进行rollout校正，并过滤负轨迹以稳定训练。
本文采用SFT+RL两阶段训练，理解RLOO算法的改进细节对于复现和理解模型性能至关重要。
上下文管理（Context Management）
在长期任务中，智能体需要在有限的上下文窗口（如128K tokens）内管理大量历史交互。本文设计了周期性计划精炼与溢出触发压缩方案：每5步精炼一次任务计划，当历史达到上下文上限时执行强制精炼并丢弃旧上下文。
这是SMTL能够在固定上下文预算下支持更长有效轨迹的关键机制，直接影响模型的实际部署能力。
子图提取与图网络构建
在数据构建阶段，论文使用LightRAG构建知识图谱，然后通过控制随机游走策略提取任务特定子图。每个子图以目标实体为中心，通过BFS扩展N跳获取支持证据结构，形成需要多跳推理的紧凑、信息密集的任务骨架。
这是SMTL数据构建pipeline的核心技术，理解它才能理解论文如何自动生成高质量训练数据。
研究动机
现有的深度研究智能体主要通过增加推理深度来提升性能，但这在搜索密集型场景中导致了严重的推理成本和延迟问题。以MiroThinker-v1.0-30B为例，在BrowseComp基准测试上需要平均206.0个助手步骤才能达到41.2%的准确率，而Tongyi-DeepResearch-30B也需要75.2个步骤达到43.4%的准确率。这种线性、顺序的推理模式存在根本性的效率瓶颈——大量计算被用于模型端的延长推理，而非有效的外部证据采集。此外，现有智能体在异构研究设置中的泛化能力也面临挑战，确定性问答任务和开放式研究任务通常需要不同的优化目标，使得训练一个在两类任务上都表现良好的单一智能体变得困难。
本文的目标是本文的具体目标是重新审视长期智能体搜索，从效率和泛化两个维度进行优化。具体而言，研究团队希望：(1) 设计一个能够用并行任务分解替代顺序推理的统一智能体框架，实现受限上下文预算下的高效长期推理；(2) 构建一个自动化数据合成pipeline，能够同时支持确定性问答和开放式研究任务的训练数据生成；(3) 通过端到端的监督微调和强化学习训练，在多个基准测试上实现最先进的性能，同时显著减少推理步骤和延迟。
与已有工作不同的是，本文的独特切入角度在于提出了「多搜少想」（Search More, Think Less）的核心理念。与现有方法专注于加深推理深度不同，SMTL认为提升搜索广度是更高效的扩展轴。具体而言，论文指出当前智能体的扩展瓶颈不在于推理深度不够，而在于推理路径的组织方式——线性顺序执行限制了信息获取密度。通过将顺序推理替换为并行证据采集，SMTL能够在每个交互步骤中获取更多候选证据，提高信息密度，从而减少冗余查询重构，生成更短但更有效的轨迹。这种从「深度优先」到「广度优先」的范式转变，使得SMTL在BrowseComp上仅用60.4个步骤（平均3.5次工具调用/步）就达到了44.6%的准确率，而MiroThinker需要206.0个步骤仅达到41.2%。
核心方法
SMTL框架的整体思路是通过并行任务分解和并发工具执行替代顺序推理，结合结构化上下文管理实现高效长期推理。直觉上，传统智能像「单线程」处理问题——每次只做一个搜索，等结果返回后再决定下一步。而SMTL像「多线程」处理——同时启动多个搜索方向，然后根据中间结果动态调整计划。技术路线分为三个层次：(1) 并行智能体工作流：在每个时间步选择就绪子任务并行执行，通过状态聚合函数 $s_{t+1} = F(s_t, \{a_t^{(k)}\}_{k=1}^m, \{o_t^{(k)}\}_{k=1}^m)$ 更新推理状态；(2) 统一数据构建pipeline：集成语料收集、图构建、子图提取、QA生成与验证；(3) 两阶段训练：SFT初始化稳定行为后，通过改进的RLOO强化学习优化轨迹质量。
SMTL的核心创新在于三个层面的「并行化」设计。首先是执行层面的并行：在每个交互步骤中，系统可以同时执行多个待处理子任务的工具调用，而不是像传统方法那样每步只调用一次工具。实验数据显示，SMTL平均每步执行3.5次工具调用，而MiroThinker和Tongyi-DeepResearch都只有1.0次。其次是规划层面的动态性：任务计划 $G_{t+\Delta}^{plan} = R(G_t^{plan}, C_t, P_t, s_t)$ 会根据执行状态定期精炼，已完成的子任务被移除，新子任务被引入。最后是上下文层面的管理：当累积历史达到128K上下文预算时，执行强制计划精炼并丢弃旧上下文，保留最新执行状态和子任务结构。这种设计使得SMTL能够在固定上下文预算下支持更长的有效轨迹。
方法步骤详情
SMTL方法的具体步骤如下：(1) 初始计划构建：给定复合搜索任务T，通过分解函数D构建初始任务计划 $G_0^{plan}$，将问题分解为一组相互关联但部分独立的子任务。(2) 并行执行与工具协调：在每个时间步t，从待处理集合 $P_t$ 中选择就绪子任务 $E_t$，使用可用工具并行执行这些子任务，通过聚合函数F更新推理状态 $s_{t+1}$。(3) 动态计划精炼：每N=5步执行一次精炼，移除已完成子任务，重新检查未解决依赖，可能引入新子任务。(4) 上下文压缩：当历史达到128K上限时，执行强制精炼，丢弃精炼前的所有上下文，从刷新的计划继续执行。(5) 最终答案生成：当所有子任务完成后，通过任务合并生成最终答案。训练阶段则分为两步：首先使用SFT初始化（3.5个epoch，batch size 128，学习率 $1.4 \times 10^{-5}$），然后使用改进的RLOO算法进行强化学习（学习率 $1 \times 10^{-6}$，batch size 32，每个问题生成8个rollout）。
技术新颖性
SMTL的技术新颖性体现在以下几个方面。首先，它提出了一个统一的并行智能体框架，能够同时支持确定性问答和开放式研究任务，而现有方法通常只针对其中一类任务优化。其次，论文设计了自动化数据构建pipeline，通过子图提取和分层问题构建生成高质量训练数据，包括Deep Search数据（图谱知识构建、2-5跳多跳问答）和Deep Research数据（开放式研究问题、轨迹生成与质量过滤）。第三，论文对RLOO算法进行了三项关键改进：采用token级损失函数、序列级重要性采样进行rollout校正、以及过滤由环境问题（如连接超时）导致的负轨迹。最后，上下文管理方案将周期性计划精炼与溢出触发压缩相结合，使得SMTL能够在固定上下文预算下支持更长的有效轨迹，这是现有方法未能实现的。
实验结果
SMTL在多个基准测试上展现出一致的帕累托主导地位。在Deep Search基准上，SMTL-100（100步限制）在BrowseComp上达到43.6%的准确率，略优于Tongyi-DeepResearch-30B（43.4%）和MiroThinker-v1.0-30B（41.2%），同时在XBench-DeepSearch上达到80.0%（优于所有基线），在WebWalker-QA上达到74.9%。当预算增加到300步时，SMTL-300在BrowseComp上提升至48.6%（+5.0），在GAIA上达到75.7%，在XBench-DeepSearch上达到82.0%。效率方面，SMTL-100平均只需60.4个助手步骤（3.5次工具调用/步），而MiroThinker需要206.0个步骤（1.0次工具调用/步），效率提升约70.7%。在Deep Research Bench上，SMTL-100达到45.9%的总体得分，在四个细分维度上表现均衡：全面性42.1%、深度45.6%、指令遵循49.6%、可读性45.5%，超越WebSailor-32B（32.4%）、WebDancer-QwQ（35.9%）等开源基线。消融实验表明，增加最大交互步骤主要通过缓解困难案例的搜索预算约束来提升性能，而非补偿系统性推理错误；增加检索top-k（从4到8）也能显著提升性能，验证了「扩大检索广度是比增加推理长度更高效的扩展轴」的核心观点。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| BrowseComp（深度搜索） | pass@1准确率 | SMTL-100: 43.6%, SMTL-300: 48.6% | MiroThinker-v1.0-30B: 41.2%, Tongyi-DeepResearch-30B: 43.4% | SMTL-300比MiroThinker提升7.4个百分点，步骤减少70.7% |
| GAIA（深度搜索） | pass@1准确率 | SMTL-100: 74.8%, SMTL-300: 75.7% | NestBrowse-30B-A3B: 75.7%, MiroThinker-v1.0-30B: 73.5% | SMTL-300与NestBrowse持平，比MiroThinker提升2.2个百分点 |
| XBench-DeepSearch（深度搜索） | pass@1准确率 | SMTL-100: 80.0%, SMTL-300: 82.0% | Tongyi-DeepResearch-30B: 75.0%, NestBrowse-30B-A3B: 75.0% | SMTL-300比最佳基线提升7.0个百分点 |
| WebWalker-QA（深度搜索） | pass@1准确率 | SMTL-100: 74.9%, SMTL-300: 76.5% | Tongyi-DeepResearch-30B: 72.2%, MiroFlow (GPT-5): 52.6% | SMTL-300比Tongyi提升4.3个百分点 |
| DeepResearch Bench RACE（深度研究） | 总体得分 | SMTL-100: 45.9% | Tongyi-DeepResearch-30B: 45.7%, Kimi-Researcher: 44.6% | SMTL-100比Tongyi提升0.2个百分点，比Kimi提升1.3个百分点 |
局限与改进
尽管SMTL取得了显著成果，但仍存在一些局限性。首先，论文承认在某些基准测试上（如SEAL-0），SMTL的性能（51.4%）与Claude-4.5-Sonnet（53.4%）和GPT-5（51.4%）相比仍有差距，表明在特定任务类型上，基础模型的能力仍然重要。其次，论文的并行执行机制依赖于可用的外部工具和API，当工具响应延迟或不稳定时（如连接超时），可能会影响整体效率。第三，上下文管理方案虽然解决了长轨迹问题，但在强制精炼时可能会丢失一些有价值的早期信息，这在某些需要长期依赖的任务中可能是不利的。此外，论文的实验主要在Qwen3-30B-A3B-Instruct-2507基础上进行，对于其他模型架构的泛化性尚待验证。最后，虽然论文声称SMTL减少了推理步骤，但在某些简单任务上，并行执行的额外开销可能会抵消效率收益。
独立分析的弱点
SMTL的几个潜在弱点值得深入分析。首先，当前的并行执行机制虽然提高了信息获取密度，但缺乏对子任务间依赖关系的精细管理——当子任务之间存在强依赖时，并行执行可能导致重复工作或信息冲突。改进方向可以是引入更智能的依赖检测和任务调度算法。其次，上下文压缩方案采用简单的「丢弃旧上下文」策略，可能会丢失重要的历史信息，可以探索更精细的摘要或选择性保留机制。第三，数据构建pipeline虽然覆盖了多种任务类型，但仍主要基于知识图谱，对于需要实时信息或长文档理解的任务覆盖有限。第四，强化学习阶段使用LLM-as-a-judge进行奖励评估，可能存在评估偏差，可以探索更客观的奖励函数设计。最后，论文的并行执行依赖于固定的工具集，对于需要动态工具选择或工具创建的复杂场景支持不足。
未来方向
论文和基于其成果可以延伸的未来研究方向包括：(1) 探索更高效的并行执行策略，如基于子任务优先级的动态调度、基于资源约束的并行度自适应调整；(2) 改进上下文管理方案，研究基于注意力机制的选择性信息保留，或基于任务结构的层次化压缩；(3) 扩展数据构建pipeline，支持更多任务类型（如多模态任务、实时信息任务）和更复杂的推理结构；(4) 探索更先进的强化学习算法，如基于模型的RL或层次化RL，以进一步提升训练效率；(5) 研究SMTL框架在其他领域的应用，如代码生成、科学发现等需要长期规划的任务；(6) 开发更智能的工具调用策略，支持动态工具选择、工具组合和工具创建。
复现评估
论文在复现方面提供了较好的支持。代码、模型和数据集均已开源（论文中标注了链接），这大大降低了复现门槛。训练细节也描述得相当详细：SFT阶段3.5个epoch，batch size 128，学习率 $1.4 \times 10^{-5}$，最大序列长度65536 tokens；RL阶段学习率 $1 \times 10^{-6}$，batch size 32，每个问题8个rollout，最大序列长度128K tokens。然而，复现仍面临一些挑战：(1) 训练需要较大的计算资源（30B模型的SFT和RL）；(2) 数据构建pipeline依赖TaskCraft语料和LightRAG图构建，需要额外的预处理；(3) 评估使用LLM-as-a-judge，结果可能因评估模型不同而有所差异；(4) 上下文管理方案的实现细节（如精炼时机、压缩策略）可能需要针对不同任务进行调优。总体而言，对于有足够计算资源的研究团队，论文的复现难度中等。
论文图表