AI 范式雷达：《从并行到递归：WebSwarm的多Agent深度广度协同搜索范式》

上周阿里巴巴达摩院发布了 WebSwarm——一个渐进式递归多Agent搜索框架。在 BrowseComp-Plus、WideSearch、DeepWideSearch、GISA 四个基准测试上，WebSwarm 全面超越单 Agent ReAct 和多 Agent 并行基线。这篇文章将解析 WebSwarm 的核心原理，并带你理解为什么”从并行到递归”是 Web 搜索 Agent 的下一个范式转移。

为什么传统 Web 搜索 Agent 不够用了

如果你正在构建一个能够自主完成复杂研究任务的 AI Agent，你可能会遇到一个令人沮丧的模式：Agent 在简单的事实问答上表现不错——”谁获得了2024年诺贝尔物理学奖？”“Python 的 GIL 是什么？”——但一旦任务复杂度上升，它的表现就会急剧下降。

这就是当前 Web 搜索 Agent 面临的核心困境。

传统的 ReAct（Reasoning + Acting）式 Agent 采用线性推理模式：观察环境、做出决策、执行动作、再次观察。这个循环在简单任务中有效，但当任务需要同时处理深度和广度时——比如”从2015年到2024年，哪些AI芯片公司在量子计算领域取得了突破？”—Agent 的长轨迹会超出上下文窗口限制，有限的注意力机制无法同时追踪多个搜索分支的证据。

现有多 Agent 系统试图通过并行执行来提升覆盖率：将一个大任务拆分为若干子任务，分配给不同的 Agent 并行处理。但这种方案存在三个根本性局限：

第一，递归深度不足。现有系统仅在根层级分解任务，所有子任务在同一平面上并行执行。如果某个子任务的搜索结果需要进一步深入挖掘——比如发现了一个关键公司后需要追溯其历史、技术路线和竞争对手——当前架构无法自然地支持这种多级递归根树展开。

第二，协作模式僵化。不同子节点被强制使用相同的协作范式（通常是纯并行），但实际搜索任务中可能需要顺序验证、多路径采样聚合、分治等多种策略的混合使用。

第三，缺乏证据驱动的扩展机制。现有系统按查询的表面语义进行任务拆分——比如将”2015-2024年AI芯片量子计算突破”拆分为按年份或按公司的子任务——但这种方式忽略了 Web 上相关信息实际的组织方式（时间线、实体关系、事件集、属性维度），导致搜索方向与真实知识结构脱节。

WebSwarm 的核心论断是：这些局限不是工具调用能力的问题，而是编排范式的问题。从并行到递归的转变，才是释放多 Agent 搜索潜力的关键。

WebSwarm 核心原理：渐进式递归委派框架

WebSwarm 提出了一种渐进式递归委派（Progressive Recursive Delegation）框架，其核心思想是在推理过程中联合构建任务分解、递归扩展和 Agent 协作——而不是将它们作为独立的步骤依次执行。

理解这个框架的关键在于重新思考搜索任务的本质：一个复杂的搜索问题不是一个需要被”拆分”的静态对象，而是一个可以在探索过程中动态展开的结构。

WebSwarm 将每个搜索节点建模为一个独立 Agent，它接收局部目标和搜索模式两个输入。当节点完成搜索后，它将证据向上返回给父节点——但这个过程不是终点。父节点可以根据收到的证据继续扩展新的子节点、修订已有节点的搜索方向、或聚合多个分支的结果来形成综合结论。

这种设计带来了三个层面的创新：

渐进式递归深度。WebSwarm 支持多级递归根树的自然展开。以”2015-2024年AI芯片量子计算突破”为例，根节点可能首先按时间线分解为若干年份子任务；某个年份的子节点发现了一家关键公司后，可以进一步按实体维度分解为公司背景、技术路线和竞争对手三个子分支；每个子分支还可以继续深入。每一层都可以独立选择最适合当前局部目标的搜索模式——这是现有系统完全不具备的能力。

协作适应性。不同子节点可以采用不同的协作范式：并行分治适用于需要同时探索多个独立维度的场景（如同时查询不同公司的技术路线）；顺序搜索验证适用于需要逐步确认假设的场景（如先找到候选公司，再逐一验证其量子计算成果）；多路径采样聚合适用于信息源高度分散、需要从多个角度交叉验证的场景。WebSwarm 根据局部目标动态切换协作模式，而不是强制所有节点使用同一种策略。

证据驱动扩展。这是 WebSwarm 最具洞察力的设计：在决定如何分解任务之前，先探测 Web 上相关信息是如何组织的——是时间线结构、实体关系网络、事件集合还是属性维度？然后根据这种实际的信息组织方式来决定分解维度。这避免了按查询表面语义盲目拆分的陷阱——比如一个看似按年份的问题，其答案可能实际上以公司维度的知识图谱形式存在于 Web 上。

架构组件拆解

WebSwarm 的架构由三个核心组件构成：节点构建、递归扩展和证据聚合。理解它们的协作方式是理解整个框架的关键。

节点构建（Node Construction）

每个搜索任务从根节点开始，根节点接收原始查询并执行初始探测——通过少量探索性搜索来了解 Web 上相关信息的大致分布和组织方式。基于探测结果，根节点决定分解维度和协作模式，然后创建第一批子节点。

每个子节点被赋予两个关键信息：局部目标（它需要回答的具体问题）和搜索模式（它应该采用的策略）。这个设计使得子节点不再是”盲从的工人”——它们拥有自己的推理能力和策略选择权，可以根据局部目标的特性动态调整搜索行为。

递归扩展（Recursive Expansion）

这是 WebSwarm 区别于现有系统的核心机制。当一个子节点完成搜索并返回证据后，父节点面临三个选择：继续扩展、修订方向或聚合结果。

如果收到的证据指向了新的探索方向——比如某个搜索结果提到了一个从未被考虑过的实体或时间范围——父节点可以创建新的子节点来深入挖掘这个新发现。这个过程可以无限递归下去，形成一棵动态生长的搜索树。

递归扩展的关键在于证据的质量评估机制。不是所有返回的证据都值得进一步展开——WebSwarm 通过评估证据的信息密度、新颖性和与当前目标的关联度来决定是否继续扩展。这避免了搜索树的无序膨胀，确保递归过程始终聚焦于有价值的探索方向。

证据聚合（Evidence Aggregation）

当搜索树到达某个终止条件时——可能是所有叶子节点都完成了搜索、可能达到了预设的最大深度、也可能父节点认为已有足够的证据形成结论——证据开始从叶子节点向根节点汇聚。

每个节点在向上返回证据之前，会先对收到的子证据进行本地聚合：去重、冲突检测、相关性排序和摘要生成。这个过程确保了向上流动的信息是精炼且有结构的，而不是原始搜索结果的简单拼接。

根节点最终接收所有分支的证据，形成综合结论。这个结论不是简单的投票或平均——它基于证据的权重、一致性和覆盖度来构建一个结构化的答案。

class SearchNode:
    def __init__(self, query, mode="parallel"):
        self.query = query
        self.mode = mode          # parallel | sequential | sampling
        self.children = []        # 子节点列表
        self.evidence = None      # 聚合后的证据
        self.status = "pending"   # pending | expanding | done

    def execute(self):
        """执行搜索并返回证据"""
        results = self.search_engine.query(
            self.query, mode=self.mode
        )
        return self.aggregate(results)

    def expand(self, parent_evidence):
        """根据父节点证据决定是否扩展子节点"""
        if not self.should_expand(parent_evidence):
            self.status = "done"
            return
        
        sub_queries = self.decompose(
            parent_evidence, 
            mode=self.mode
        )
        for sq in sub_queries:
            child = SearchNode(sq, mode=self.infer_mode(sq))
            child.expand(self.evidence)
            self.children.append(child)
        
        # 聚合子节点证据
        self.evidence = self.aggregate_children()
        self.status = "done"

    def should_expand(self, evidence):
        """评估是否有必要继续扩展"""
        info_density = self.compute_info_density(evidence)
        novelty_score = self.measure_novelty(evidence)
        return (info_density > THRESHOLD or 
                novelty_score > NOVELTY_THRESHOLD)

这段伪代码展示了 WebSwarm 递归扩展的核心逻辑：每个节点根据收到的证据评估是否继续扩展，如果扩展则分解为子查询并创建子节点，最后聚合所有子节点的证据。should_expand 函数中的信息密度和新颖度评分是控制搜索树生长的关键阀门——它们确保递归过程既不会过早终止（遗漏重要发现），也不会无限膨胀（浪费计算资源）。

进阶：协作模式自适应与证据驱动扩展

理解了三个核心组件之后，你需要深入 WebSwarm 最精妙的设计：它如何让不同的子节点采用完全不同的协作策略。

并行分治（Parallel Divide-and-Conquer）

当搜索任务可以被清晰地划分为多个独立维度时，WebSwarm 使用并行分治模式。每个子节点负责一个独立的维度，所有子节点同时执行搜索，互不干扰。这种模式适用于”比较类”问题——比如对比三家公司的量子计算技术路线。

顺序验证（Sequential Verification）

当任务需要逐步确认假设时，WebSwarm 切换到顺序模式。第一个子节点的搜索结果决定第二个子节点的查询方向，第二个的结果又影响第三个——形成一条推理链。这种模式适用于”溯源类”问题——比如追溯某项技术的发明者和后续改进者。

多路径采样聚合（Multi-Path Sampling and Aggregation）

当信息源高度分散、单一搜索路径可能遗漏关键证据时，WebSwarm 采用多路径采样策略：从多个不同的起点同时出发进行搜索，然后在汇聚阶段交叉验证和整合结果。这种模式适用于”探索类”问题——比如发现某个领域内所有重要的参与者。

协作模式切换的决策逻辑

WebSwarm 如何决定使用哪种协作模式？答案在于它对 Web 信息组织方式的探测能力。

在任务开始时，根节点执行一次轻量级的探测搜索——不是为了解决问题，而是为了了解”这个问题的答案通常以什么形式存在于 Web 上”。如果探测结果显示相关信息按时间线分布（如技术演进史），WebSwarm 倾向于使用并行分治模式；如果显示信息以实体关系网络存在（如人物-组织-技术的关联图谱），它可能选择顺序验证模式；如果信息高度分散且缺乏明确结构，多路径采样聚合成为首选。

这种基于证据的协作模式选择是 WebSwarm 区别于所有现有系统的核心特征——它不是预设一套固定的策略模板供 Agent 选择，而是根据实际搜索环境动态生成最适合的策略组合。

证据驱动扩展 vs. 语义驱动的盲目拆分

传统方法按查询的表面语义进行任务拆分：将”2015-2024年AI芯片量子计算突破”拆分为按年份的子任务（2015年、2016年……2024年）。这种方式的缺陷在于它假设答案的组织方式与问题的表述方式一致——但 Web 上的知识往往以完全不同的结构存在。

WebSwarm 的探测阶段会先回答一个元问题：这个查询的答案在 Web 上是如何组织的？ 如果探测结果显示，关于”AI芯片量子计算突破”的信息实际上是以公司维度的技术报告形式存在的（每家公司一份白皮书），那么按年份拆分就是低效的——更好的策略是按公司维度分解。

这种从”按问题表述拆分”到”按知识组织方式拆分”的转变，是 WebSwarm 在搜索效率上的核心优势来源。

实际案例与效果验证

WebSwarm 的研究者在四个基准测试上进行了系统性的实验：BrowseComp-Plus、WideSearch、DeepWideSearch 和 GISA。这四个基准覆盖了深度任务（需要长时间多步推理）、广度任务（需要覆盖大量信息源）以及深度与广度交织的复杂任务。

整体表现：全面超越所有基线

在全部四个基准测试上，WebSwarm 持续超越了两种类型的基线模型：单 Agent ReAct 系统和多 Agent 并行系统。这种超越不是某个特定场景下的偶然优势——它覆盖了从纯深度到纯广度再到混合任务的完整光谱。

与单 Agent ReAct 的对比

单 Agent ReAct 在简单事实问答上表现尚可，但在需要同时处理多个搜索分支的任务中迅速崩溃。主要原因有两个：长推理轨迹超出上下文窗口限制，导致早期搜索结果被遗忘；有限的注意力机制无法同时追踪多个证据链。WebSwarm 通过递归委派将这些负担分散到多个独立节点上——每个节点只关注自己的局部目标，避免了单节点的上下文过载问题。

与多 Agent 并行系统的对比

多 Agent 并行系统在覆盖率上优于单 Agent，但在深度和协作适应性方面存在明显不足。所有子节点使用相同的搜索策略，无法根据局部目标的特性动态调整；任务仅在根层级分解一次，无法支持多级递归根树展开。WebSwarm 在这些维度上的优势尤为显著——在需要深度挖掘的任务中，递归扩展能力使得 WebSwarm 能够发现并行系统完全遗漏的关键证据。

Before vs After 的直观对比

为了更清晰地展示 WebSwarm 的效果，以下是处理同一类复杂搜索任务时的典型对比：

• 无 WebSwarm（ReAct 单 Agent）：线性搜索轨迹在遇到第一个分支点后开始迷失方向，上下文窗口在约第15步被填满，后续搜索结果无法被有效利用，最终答案遗漏了约40%的关键证据
• 多 Agent 并行系统：所有子节点同时执行相同策略的搜索，覆盖率有所提升但深度不足——对于需要追溯技术演进路径的任务，只能停留在表面信息层面，无法深入挖掘关键实体的历史关联
• WebSwarm（递归委派）：根节点探测到知识以公司维度组织后按实体分解；发现关键公司后自动扩展出技术路线和竞争对手子分支；每个子分支根据局部目标选择最优搜索模式；最终聚合阶段交叉验证所有证据，答案覆盖了约92%的关键信息

数据背后的启示

WebSwarm 的性能优势揭示了一个更深层的规律：多 Agent 系统的价值不在于”更多的 Agent”，而在于”更好的编排”。当 Agent 的数量增加但协作方式仍然是扁平并行时，收益很快会遇到瓶颈；而当每个 Agent 能够在递归结构中动态调整策略、根据证据驱动扩展方向时，系统的能力呈现出指数级增长的趋势。

反方观点与边界条件

在讨论任何新技术框架时，保持批判性思维是必要的。WebSwarm 虽然提出了一个有吸引力的范式转移方案，但它并非没有局限性和潜在风险。以下是几个需要认真考虑的反方观点和边界条件。

递归深度的控制难题：探索 vs. 效率的永恒权衡

WebSwarm 的递归扩展机制允许搜索树无限生长——理论上这带来了最大的灵活性，但实践中也带来了严重的效率问题。如果 should_expand 函数的阈值设置不当，搜索树可能过度膨胀，消耗大量计算资源却只产生边际收益；反之，如果阈值过于保守，又可能过早终止有价值的探索路径。

这个权衡没有通用的最优解——它高度依赖于具体任务的复杂度、可用计算资源和时间约束。在实际部署中，研究者需要针对每个应用场景进行精细的调优，这增加了工程落地的复杂性。

探测阶段的成本：元搜索的开销

WebSwarm 在任务开始时执行一次探测搜索来了解信息的组织方式——这个设计虽然精妙，但也引入了额外的延迟和 Token 消耗。对于简单任务而言，探测阶段可能比实际搜索本身更昂贵；只有当任务的复杂度足够高、信息结构足够复杂时，探测阶段的投入才能获得足够的回报。

这意味着 WebSwarm 并非在所有场景下都是最优选择——对于事实性问答或结构化数据查询等简单任务，传统的单 Agent ReAct 方案可能更加高效。

证据聚合的准确性风险

WebSwarm 的证据聚合机制依赖于对子节点返回证据的去重、冲突检测和摘要生成。当多个子节点的搜索结果存在矛盾时（比如不同来源对同一事件的不同描述），聚合过程需要做出判断——保留哪个版本？如何标注不确定性？这些决策的质量直接影响最终答案的可靠性。

当前的实现可能无法完全处理复杂的证据冲突场景，特别是在涉及主观性内容或争议性话题时。这是一个需要在后续迭代中重点改进的方向。

适用场景的边界条件

WebSwarm 的价值在以下场景中最为显著：任务需要同时处理深度和广度、信息源高度分散且缺乏明确结构、答案的组织方式与问题表述不一致。但在以下场景中，它的价值可能有限：

• 简单事实查询：答案存在于单一来源或结构化数据库中时，递归委派带来的复杂性是多余的
• 实时性要求极高的场景：探测阶段和多轮递归扩展引入的延迟可能无法满足实时响应需求
• 高度结构化的知识领域：当 Web 上的信息已经以清晰的时间线、分类体系或图谱形式组织时，简单的并行搜索可能就足够了

理解这些边界条件有助于你判断 WebSwarm 是否适合你的具体应用场景。

未来1-2个周期的雷达观察点

基于 WebSwarm 当前的研究进展和工程实践中的挑战，以下是几个值得在未来 1-2 年内重点关注的雷达观察点：

递归深度的自动化控制能否实现

目前的 should_expand 函数依赖人工设定的阈值——信息密度阈值和新颖度阈值需要根据具体场景调优。未来的研究方向可能是引入自适应的递归深度控制机制：让系统根据任务的复杂度、已获取证据的质量分布和剩余预算动态调整扩展策略，而不是依赖固定的阈值参数。这类似于操作系统中的内存管理算法——从静态分配转向动态调度。

多 Agent 搜索树的可视化与可解释性

随着递归深度的增加，WebSwarm 生成的搜索树可能变得非常庞大和复杂。如何向人类用户清晰地展示这个搜索过程——哪些分支被扩展了、为什么被扩展、哪些证据被聚合了、哪些被丢弃了——是一个重要的工程挑战。可视化工具不仅需要展示最终结果，还需要呈现整个推理路径的结构化摘要，让用户能够理解 Agent 的决策逻辑。

搜索模式自动选择的学习机制

目前 WebSwarm 通过探测阶段来推断合适的协作模式——但这仍然是一种启发式方法。未来的方向可能是训练专门的元学习器（meta-learner），让它根据查询的特征和历史搜索结果的模式，自动预测最优的协作策略组合。这种从”规则驱动”到”数据驱动”的转变将大幅提升系统的适应性和效率。

与知识图谱和结构化数据的融合潜力

WebSwarm 目前主要面向非结构化的 Web 搜索场景。但如果将其递归委派框架与知识图谱、数据库查询等结构化数据源结合——让 Agent 在适当的时候从非结构化搜索切换到结构化查询——可能会产生显著的叠加效应。这种混合搜索架构可能是未来复杂研究任务的标准解决方案。

总结与行动清单

WebSwarm 提出了一种有吸引力的范式转移：从扁平并行的多 Agent 协作转向渐进式递归委派，通过联合构建任务分解、递归扩展和证据聚合来同时处理深度和广度交织的复杂搜索任务。它的核心价值在于将 Web 搜索从”按问题表述拆分”转变为”按知识组织方式探索”——让 Agent 像人类研究员一样，在探索过程中动态调整搜索策略和方向。

你现在可以做的：

1. 评估你的搜索任务的复杂度特征。如果你的任务需要同时处理多个维度的信息、且答案的组织方式与问题表述不一致，WebSwarm 的递归委派范式可能带来显著收益——考虑在原型系统中实现最小化的递归扩展机制
2. 在你的 Agent 框架中引入探测阶段。即使不采用完整的 WebSwarm 架构，在复杂搜索任务开始时加入一次轻量级的信息结构探测（了解答案以什么形式存在于 Web 上），也能显著提升后续搜索策略的选择质量
3. 关注证据聚合的质量评估方法。多 Agent 系统的核心挑战之一是如何可靠地整合来自不同分支的证据——建立证据去重、冲突检测和加权聚合的标准化流程是提升系统可靠性的基础工作
4. 在深度与广度交织的任务上测试现有方案。如果你的当前架构在处理这类任务时表现不佳，WebSwarm 揭示的递归委派范式可能是一个值得探索的方向

未来雷达观察点：

• 自适应递归深度控制。 如果系统能够根据任务特征动态调整搜索树的生长策略，而不是依赖人工设定的阈值，WebSwarm 的工程落地门槛将大幅降低——这将使递归多 Agent 搜索从研究原型走向生产可用。
• 混合搜索架构的成熟。 当 WebSwarm 式的递归委派框架与知识图谱、数据库查询等结构化数据源深度融合时，复杂研究任务的自动化水平可能迎来质的飞跃——关注这一方向的最新进展。

References

• WebSwarm: Recursive Multi-Agent Orchestration for Deep-and-Wide Web Search (arXiv:2607.08662)
• BrowseComp-Plus Benchmark
• WideSearch Benchmark
• DeepWideSearch Benchmark
• GISA Benchmark
• ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022)