基于LLM的搜索Agent近年来取得了长足进步，已经从早期的简单问答扩展为能调用工具、浏览网页、提取结构化信息、甚至执行多步推理的自主系统。然而一个核心问题始终没有得到根本解决：当任务性质复杂到既需要沿某个分支深度挖掘，又必须同时覆盖多个方向时，单个Agent的上下文窗口和注意力机制很难兼顾两头。你让它深钻一个方向，它可能遗漏其他重要线索；你让它广撒网全面覆盖，每个方向又都浅尝辄止，哪个都挖不透。大多数现有方案的做法是启动多个Agent并行搜索，各自检索不同的方向，但这种架构缺乏有效的协作和信息交换机制，各节点基本处于"各自为战"的状态。一旦遇到需要交叉验证的场景——比如A方向的结果是否与B方向的结论一致、C方向找到的数据能否修正D方向的推断——这种并行架构的局限性就暴露无遗，各Agent之间无法灵活地互通有无，导致大量重复劳动和遗漏。

WebSwarm这篇论文正是瞄着这个核心痛点来的。它跳出了"并行分工"的传统思路，提出了一种递归式委托的搜索框架，让Agent在推理过程中动态构建搜索拓扑，而不是事先划分好任务再各自执行。这个思路值得深入拆解。

不是分工，是委派

WebSwarm的核心设计理念与传统的"分工"思维有本质区别。传统做法是预先规划任务、分配给固定角色，各司其职，彼此之间很少互动。WebSwarm则让搜索结构在推理过程中动态生长，没有预设的层级或分工，一切由任务本身的特征来决定。系统首先会分析待查信息在网页上是以何种组织形式存在的：是树状的层级结构？是多维交叉的网状分布？还是分散在不同来源中需要关联整合的碎片化信息？基于这个分析结果，它动态决定搜索树应该如何展开，每个分支应该多深、多宽。

具体到执行层面，每个搜索节点都拥有自己的目标和"搜索模式"。节点既能独立完成自己所负责的检索任务，又可以根据任务需要向下委托子节点。子节点执行完搜索后向上级返回结果，父节点收到反馈后可以继续扩展新的分支或者对已有结果进行整合。这个过程天然是递归的——一个子节点在执行过程中发现新的线索，可以继续创建自己的子节点向下深挖，逐层递进，形成一条从根节点直达叶节点的完整搜索链路。整个过程中没有中央调度器去统筹每一步，结构本身就是自组织的。每个节点只对自己的父节点和子节点负责，搜索树在任务推进中自然生长成形。

这个机制和人类做研究的过程高度相似：你先判断问题需要查几个大方向，给每个方向开一个子任务，子任务在执行时发现新的线索就继续下钻，然后所有线索汇总到最上层做综合判断。WebSwarm本质上就是用算法模拟了这个自然且高效的研究流程，只不过把人类的直觉决策替换成了基于上下文的动态推理。

实验数据给什么启示

在BrowseComp-Plus、WideSearch等多个权威测试基准上，WebSwarm在深度搜索、广度搜索以及两者交织的复杂任务中，均显著优于传统的单Agent和多Agent并行方案。尤其是在需要跨页面、跨来源进行信息关联与验证的场景下，WebSwarm的优势更为突出，其递归委托机制使得搜索路径可以被灵活裁剪，不会因为一个分支卡住而影响整体进度，不同分支之间也能通过层级结构实现信息的自然汇聚。

但实验数据中最值得单独拎出来的一个细节是：同层节点之间复用搜索策略所带来的性能提升，比单纯增加递归层数要明显得多。这意味着什么？对工程实践者而言，与其把资源浪费在堆叠更多Agent层级或者调用更大的模型上，不如让同一层级的Agent之间共享搜索经验和策略——比如某个节点发现某种查询方式在当前信息源上特别有效，就把它传给同层节点复用。这种横向协作带来的边际收益，往往比纵向扩展更可观，也更节省计算资源。

WebSwarm目前还停留在论文阶段，距离成熟的工程化产品还有一段距离。但它所揭示的方向已经很清晰了：当任务复杂度超出单个Agent的处理能力时，我们需要的或许不是更大更强的模型，而是一个能根据任务动态组织协作的智能框架。真正的瓶颈不在参数规模，而在协作架构的设计本身——这是当前Agent研究中最值得关注的命题之一。

关于维基框架

维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。

• 官网：https://framewiki.com
• Gitee：https://gitee.com/wiki-framework
• GitHub：https://github.com/wiki-framework
• 示例项目：https://gitee.com/cdkjframework/framewiki-example
• 📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）