WebSwarm：让 Deep Research 不再挤在一条搜索轨迹里
一句话概括：WebSwarm 这篇论文抓住了 deep research agent 当前最现实的瓶颈：复杂搜索不是“多开几个 agent”就能解决的。真正难的是，任务一开始并不知道应该怎么拆；线索是在网页搜索过程中逐步显露出来的。WebSwarm 的做法，是把搜索过程组织成一棵会边走边长的递归委派树：每个节点不仅有一个局部目标，还有一个搜索模式；子节点回传的证据，不只是答案材料，也会反过来决定父节点下一步怎么继续展开。
先把几个概念放到桌面上
我们先不要把 WebSwarm 理解成“又一个多智能体框架”。这篇论文真正关心的，是网页搜索里两种压力如何同时出现。
Deep search 像侦探查案。你不知道目标是谁，只能从几个间接线索开始，一边搜索一边提出候选，再用新证据排除或确认。论文里的 BrowseComp-Plus 就是这种任务：答案不在第一页，也不是简单多跳问答，而是要持续改变搜索角度。
Wide search 则像做一张很宽的表。你要覆盖很多实体、很多属性、很多来源，漏一行或错一格都会影响最终结果。WideSearch 和 DeepWideSearch 里的任务经常要求系统枚举一批对象，再为每个对象填字段。
递归委派 是 WebSwarm 的核心动作：一个父节点发现当前证据不够，就创建子节点；子节点自己也可以继续创建子节点。这里重要的不是“层级”这个词，而是任务树不必在一开始固定下来。它可以随着证据返回而继续生长。
搜索模式 则是每个节点的工作协议。WebSwarm 不只问“这个子任务是什么”，还问“这个子任务应该怎么搜”：是原子事实查找，是深挖验证，是并行铺开，还是先枚举未知实体集合。这个目标和模式的绑定，是论文区别于普通 task decomposition 的地方。
为什么一条 ReAct 轨迹不够用？
我们直觉上可能会想：给一个足够强的 ReAct agent，一个足够长的上下文窗口，再让它多搜索几步，复杂网页任务不就能解决吗？
问题在于，复杂搜索不是一条长链，而是一张不断变化的地图。
比如一个问题让你根据若干历史线索找出一个未知人物。前几轮搜索可能只能得到模糊候选；每出现一个候选，又要沿着不同线索去验证。这个过程需要深度。再换一个问题：让你列出多个品牌在 2025 年 6 月的核心产品线，并填充品类、容量、酒精度等字段。这里瓶颈不是某条线索难，而是覆盖面宽、来源多、结构化汇总难。
更麻烦的是，很多任务同时有这两种形态。论文附录的 DeepWideSearch 案例里，系统先要根据“实验性移动设备、连续流工业生产、家族控制”等线索识别出 Henry Ford；识别完之后，任务才变成宽搜索：枚举 2010 到 2024 年间 Ford 在美国首次推出或恢复生产的车型，并为每个车型填价格、尺寸、扭矩、悬挂、ADAS 等字段。
如果把这一切都塞进一个 ReAct 轨迹里，agent 会同时承担规划、搜索、记忆、验证、表格聚合。上下文越来越长，线索越来越杂，某一步错分解或漏证据，后面就很难补回来。已有多智能体系统确实能改善覆盖率，比如并行搜索、交叉检查、结果聚合；但论文指出，它们常见的三个问题是：递归深度浅，通常只在根节点拆一次；协作模式固定，不能让不同局部任务使用不同搜索结构；展开方式弱证据化，常按问题表面语义拆，而不是按网页证据真实组织方式拆。
WebSwarm 的起点就在这里：复杂搜索的结构，不应该由初始 query 一次性决定，而应该由中间证据逐步塑造。
WebSwarm 怎么做：目标和模式一起下发
WebSwarm 把整个搜索过程表示为一棵递归委派树。根节点收到原始任务；每个非根节点都是一个 agent，拿到两样东西：局部目标 q_v 和搜索模式 m_v。边表示一次委派。子节点完成后，把结果 r_v 返回父节点；父节点把这些结果放进自己的证据集合 R_v，再判断是继续委派、修正方向，还是聚合并返回上层。
这个抽象看上去很简单，但有一个关键细节：WebSwarm 委派的不是一组裸 subtask，而是一组“目标—模式”对。论文把它写成 C_v = {(q_i, m_i)}。也就是说，父节点在创建孩子时，同时说明“你要解决什么”和“你应该用什么协作结构解决”。
论文定义了四种搜索模式。
第一种是 atom，原子事实查找。它适合窄而明确的问题，基本就是一个直接使用 web search 和 page browse 的 ReAct 小节点。它的目标是快速找到证据并返回。
第二种是 deep，用于未知目标识别和多约束推理。它不是简单并行堆搜索，而是组织“搜索者—验证者”的串行结构：搜索者从不同线索路径提出候选，验证者独立检查候选是否满足所有约束。这个模式对应的是侦探式任务，核心不是覆盖很多对象，而是持续提出、验证、修正假设。
第三种是 wide，用于并行分治。比如要为一批品牌、车型、城市、赛事填字段，就可以把不同对象或维度交给不同子节点。但 wide 的孩子不一定只能是 atom；如果某个品牌下面还要先枚举产品，再查属性，它可以继续创建 entity_collect 或新的 wide 节点。
第四种是 entity_collect，用于开放集合枚举。它处理的是“目标集合本身不知道有多大”的情况。单一路径容易漏召回，盲目扩散又会引入噪声，所以它会从多个路径召回候选实体，再合并、去重、验证低置信项。论文实现里，entity_collect 的并行搜索路径数设为 3。
这样一来，WebSwarm 不是把所有任务都压进同一个协作范式，而是在同一棵树里混合不同局部结构。某个节点可以深挖，一个兄弟节点可以并行填表，另一个节点可以先枚举实体集合。真正的控制信号来自证据回流：子节点的结果既是答案的一部分，也是下一轮展开的依据。
关键聪明处：先看网页怎么组织，再决定怎么展开
光有递归还不够。递归委派也可能越拆越乱：拆错维度、开太多重复节点、每个子节点重复试错。WebSwarm 因此加了两个引导信号：网页结构探测和同胞节点经验复用。
先看网页结构探测。很多宽搜索任务最难的不是“多开 agent”，而是“沿哪个轴展开”。如果所有信息集中在一两个聚合页上，你按实体拆出几十个并行节点，反而会重复抓同一批页面。如果信息分散在品牌、巡演、年份、组织、事件等外部结构里，你按错误维度拆，又会导致召回不足或聚合噪声。
WebSwarm 给需要宽展开的节点先派一个 Web-Probing Agent。它做轻量搜索和页面阅读，返回一个结构提示 h_v：相关证据大致分布在哪里，有哪些代表性页面，可能沿什么轴展开。父节点再基于这个提示生成子委派。
论文附录有一个很直观的 Taylor Swift 巡演案例。用户要求列出 2010 年 1 月 1 日到 2025 年 5 月 1 日之间 Taylor Swift 官方巡演的每一场演唱会。按年份拆似乎很自然，但网页资料真正的组织方式常常是“按官方巡演页面”：Fearless Tour、Speak Now World Tour、The Red Tour、1989 World Tour、Reputation Stadium Tour、The Eras Tour。Web-probing 发现这个结构后，WebSwarm 就沿“巡演”而不是“年份”展开，再把各巡演页面里的 show-level table 过滤并合并。
第二个引导信号是经验复用。宽搜索里常常有一批同质子任务：为不同品牌找产品属性，为不同车型找配置字段，为不同巡演抽取日期和场馆。它们目标对象不同，但可靠来源、查询模板、页面结构、失败路径可能很相似。
WebSwarm 的处理方式是：先跑少量 scout 子节点，保留它们的搜索轨迹；再从这些轨迹里抽取过程级经验，例如有用查询模式、可靠来源、页面类型、无效路径；最后把这份经验注入给剩余同胞节点。论文特别强调，这种经验只在同一个样本内部、同一个父节点下的同质兄弟节点之间复用，不跨评测样本迁移，因此不会破坏评测独立性。
这两个机制分工很清楚：Web-probing 帮系统“少走错路”，experience reuse 帮后续节点“少重复犯错”。
实验数字：它到底赢在哪里？
论文在四个网页信息寻找 benchmark 上测试 WebSwarm：BrowseComp-Plus、WideSearch、DeepWideSearch 和 GISA。BrowseComp-Plus 测深度事实搜索，报告 accuracy；WideSearch 和 DeepWideSearch 测结构化宽搜索或深宽交织搜索，报告 item-F1、row-F1 和 success rate；GISA 覆盖 item、set、list、table 等多种格式。为控制资源，作者在 BrowseComp-Plus 随机采样 200 个实例，只使用 WideSearch 和 DeepWideSearch 的英文子集；GISA 使用全部 373 个英文任务。所有方法使用相同的 Web-Search 和 Page-Browse 工具，WebSwarm 和多智能体基线主要用 GLM-4.5 作为 backbone，最多允许 200 个 action steps。
主表里，WebSwarm 在 GLM-4.5 下相对 ReAct 的提升非常稳定。
在 BrowseComp-Plus 上，ReAct 是 50.50，WebSwarm 到 68.00，提升 17.50 个 accuracy points，也比最强多智能体基线高 3.50 点。这个提升对应 deep 模式：多条线索路径提出候选，再由独立 verifier 对抗式检查。
在 WideSearch-EN 上，WebSwarm 的 Row F1 是 44.14，Item F1 是 74.37；相对 GLM-4.5 ReAct 的 33.23 和 64.61，分别提升 10.91 和 9.76。这里的价值不只是覆盖更多单元格，而是让行级完整性也上升。
在 DeepWideSearch-EN 上，WebSwarm 的 Row F1 是 29.64，Item F1 是 58.40；相对 ReAct 的 20.08 和 46.63，提升 9.56 和 11.77。这个结果对应论文最关心的混合场景：先深挖出关键实体，再围绕实体展开宽表格。
GISA 上，WebSwarm 也在多个子类上更强：Item 从 27.27 到 40.91，Set 从 51.27 到 61.03，List 从 50.58 到 66.04，Table 从 59.78 到 63.69，Overall 从 55.54 到 62.30。这里的提升幅度没有每个子任务都一样大，但方向一致。
更有说服力的是消融实验。去掉递归委派后，BrowseComp-Plus 从 68.00 掉到 63.50，WideSearch Item F1 从 74.37 掉到 68.38，DeepWideSearch Item F1 从 58.40 掉到 55.79。把所有非 atom 节点强制成 wide，BrowseComp-Plus 掉到 63.00；强制成 deep，WideSearch 掉到 69.94、DeepWideSearch 掉到 54.51。这说明“递归”有用，“局部模式匹配”也有用。不是只要多开 agent 就行，而是要让不同局部瓶颈使用不同协作结构。
Web-probing 的结果更微妙。去掉它后，WideSearch Item F1 甚至从 74.37 轻微到 74.90，DeepWideSearch Item F1 从 58.40 到 58.93；但工具调用大幅增加：WideSearch 平均 web tool calls 从 137.03 到 239.90，DeepWideSearch 从 203.73 到 331.39。换句话说，Web-probing 的主要贡献不是直接涨分，而是减少冗余或错位展开，提高搜索效率。相反，去掉 experience reuse 会让 WideSearch Item F1 从 74.37 降到 71.20，DeepWideSearch 从 58.40 降到 55.48，说明过程级经验更直接影响节点求解质量。
最值得注意的结果：困难样本上限被抬高
如果一个方法只是在简单样本上多花钱，那它对 deep research 的意义有限。论文因此用 ReAct 表现来划分难度。BrowseComp-Plus 里，ReAct 三次采样全过是 Easy，全失败是 Hard，其余是 Mid；WideSearch-EN 则按 ReAct Item F1 排序分组。
结果很符合直觉，也很重要：WebSwarm 的优势随着任务变难而更明显。Hard 子集上，BrowseComp-Plus 从 ReAct 的 0.0 提到 35.7；WideSearch-EN 从 24.5 提到 55.8。论文同时观察到，多智能体方法一般比 ReAct 使用更多工具调用，而 WebSwarm 会随难度自适应增加预算：简单样本相对克制，困难样本分配更多搜索和阅读资源。
这个结果解释了 WebSwarm 的定位。它不是便宜地替代普通搜索 agent，而是把额外成本花在更需要结构化探索的长尾任务上。对于 deep research 产品来说，这恰好是用户最在意的部分：简单问题大家都会答，难题能不能不漏证据、不走死胡同，才是差异。
论文还做了跨 backbone 实验。Qwen3-32B 上，WebSwarm 相对 ReAct 在 BrowseComp-Plus 从 12.00 到 19.50，WideSearch Row F1 从 5.43 到 9.01、Item F1 从 29.11 到 34.47，DeepWideSearch Row F1 从 3.28 到 7.06、Item F1 从 20.53 到 25.54。Qwen3.5-35B 本身更强，但 WebSwarm 仍然提升：BrowseComp-Plus 从 56.50 到 61.00，WideSearch Row F1 从 37.38 到 47.54、Item F1 从 64.82 到 75.91，DeepWideSearch Row F1 从 28.79 到 35.90、Item F1 从 52.46 到 58.34。也就是说，递归编排不是只给弱模型补拐杖；强一些的模型同样能从更合适的搜索结构里受益。
这篇论文证明了什么，也没有证明什么
WebSwarm 证明的第一件事，是复杂网页搜索的瓶颈确实不只是“模型不够聪明”。同一个 GLM-4.5，用 ReAct、一层多智能体、表格化搜索、递归模式化委派，表现差异很大。编排结构本身会影响最终答案质量。
第二，它证明了“递归 + 局部模式”比单一全局协作范式更适合 deep-and-wide 任务。Table 2 里 All-to-wide 和 All-to-deep 的互补失败很有说明力：深搜索任务需要迭代验证，宽搜索任务需要覆盖和聚合，混合任务需要在两者之间切换。
第三，它证明了网页证据的外部结构值得被显式探测。Taylor Swift 巡演按 tour 拆、烈酒产品按 brand 拆、Ford 案例先 deep 后 wide，这些不是模型凭空规划出来的漂亮流程，而是由网页资料的组织方式决定的。
但边界也要说清。
首先，WebSwarm 主要是 inference-time orchestration。论文没有训练模型去学会更好的递归委派、搜索模式选择或协作策略；这些动作仍依赖 base LLM 的理解和推理能力。换句话说，它把“如何组织搜索”写进了框架和 prompt，而不是把这种能力内化进模型参数。
其次，它更贵。论文在 limitation 中明确承认，WebSwarm 需要比单个 ReAct 更多 LLM 调用和 web-tool 请求，因此会带来更高推理成本和延迟。Web-probing 能减少一部分冗余工具调用，但它不是免费午餐；对于简单任务，未必值得启用完整递归结构。
第三，它主要面向文本网页工具。论文当前的工具是 Web-Search 和 Page-Browse，没有充分覆盖图片、视频、音频，也没有扩展到 GUI 级网页操作。对于真实 deep research，很多关键证据可能藏在 PDF 表格、图像、视频片段、交互式页面里，这些还不是 WebSwarm 当前实验的核心范围。
最后，评测本身仍是 benchmark 化的。作者使用 BrowseComp-Plus、WideSearch、DeepWideSearch、GISA，并在部分数据集上出于资源效率抽样或只测英文子集。这足以说明方法在多类任务上有稳定信号，但还不能直接等价为真实商业 deep research 系统的端到端用户体验。
Big Picture：Deep Research 的下一步可能是“搜索控制论”
看完 WebSwarm，我觉得它最有价值的地方不是提出了四个 mode，也不是某个 benchmark 涨了十几个点，而是把 deep research agent 的问题重新框定了。
过去我们常把网页 agent 看成“一个会用搜索工具的模型”。后来多智能体系统出现，问题变成“怎样把任务分给多个模型”。WebSwarm 再往前推一步：真正需要建模的是搜索过程本身的控制流。什么时候深挖？什么时候铺开？什么时候先探测网页结构？什么时候把一个兄弟节点的失败经验传给另一个？什么时候停止继续展开？
这些问题不像传统 QA 那样只关心最终答案，也不像普通 planner 那样只在开头列步骤。它们发生在搜索中途，依赖刚刚返回的证据。WebSwarm 的“progressive recursive delegation”正是对此的一个回答：搜索结构不是 plan 的静态结果，而是 evidence 的动态产物。
如果未来 deep research agent 要更可靠，可能不会只靠更长上下文或更多并行 agent。它需要一套更细的搜索控制论：把网页结构当外部约束，把中间证据当控制信号，把成本预算按难度分配，把经验复用限制在安全边界内。WebSwarm 不是这个方向的终点，但它给了一个清楚的原型：让 agent 不再挤在一条轨迹里，而是在证据回流中长出自己的搜索树。
论文信息与引用
- Xiaoshuai Song, Liancheng Zhang, Kangzhi Zhao, Yutao Zhu, Zhongyuan Wang, Guanting Dong, Jinghan Yang, Han Li, Kun Gai, Ji-Rong Wen, Zhicheng Dou. WebSwarm: Recursive Multi-Agent Orchestration for Deep-and-Wide Web Search. arXiv:2607.08662v1, 2026.
- HTML: https://arxiv.org/html/2607.08662v1
- PDF: https://arxiv.org/pdf/2607.08662v1
- GitHub（论文脚注）: https://github.com/songxiaoshuai/WebSwarm