中国人民大学与蚂蚁集团联手打造：当AI搜索遭遇"迷路困境"，SearchOS如何为智能体团队装上"导航大脑"？

这项由中国人民大学高岭人工智能学院与蚂蚁集团联合开展的研究，于2026年7月16日以arXiv预印本形式公开发布，论文编号为arXiv:2507.15257v1，分类属于计算机科学人工智能领域。有兴趣深入了解的读者可通过该编号查询完整论文。

一、当AI"搜索员"迷失在自己的笔记堆里

每个人都有过这样的经历：在一个巨大的图书馆里找资料，越找越乱，手里的便条纸越叠越高，却渐渐忘了自己最初要找的是什么。到最后，不是在原来翻过的书架前来回转悠，就是因为找不到关键信息而交出一份残缺不全的报告。

当今的AI搜索智能体，正面临着相同的困境。这类智能体被设计用来在互联网上自动搜索、浏览、归纳信息，处理那些需要大量收集事实、跨越多个来源、最终整合成完整报告的复杂任务。然而随着任务越来越深入，智能体与各类网页打交道的记录越堆越长，它就开始"找不着北"——已经确认的信息被淹没在庞杂的对话历史里，没找到的信息也无从追踪，搜索失败了还会在同一条死胡同里反复钻，白白耗掉宝贵的搜索次数。

更麻烦的是，当多个智能体协同工作时，这些问题会成倍放大。不同的智能体可能在做重复的事情，或者在任务分工上产生误解，或者当其中一个搜索任务拖拖拉拉时，其他所有人都只能干等着，整个系统的效率大打折扣。

研究团队把这个核心问题归结为一句话：**搜索状态应该由系统来维护，而不是让每个智能体反复从对话历史中猜测**。正是基于这个洞察，他们开发了SearchOS——一个专门为长周期、开放域信息搜索任务设计的多智能体协作框架。

二、把"开放式找资料"变成"填写一张有规则的表格"

SearchOS解决这个问题的第一步，是把原本模糊的搜索任务变成一个可以精确衡量进度的具体目标。研究团队借鉴了数据库设计中的"关系型数据库"思路——你可以把它理解为一套有严格规则的表格系统。

当用户提出一个问题，比如"帮我整理2024年Spotify全球和美国榜单前十歌曲的歌手、语言、词曲作者、制作人和发行日期"，SearchOS不会漫无边际地开始搜索，而是先构建一个"关系型搜索架构"：这个架构定义了需要几张表格、每张表格里有哪些列（属性）、哪一列是主键用来唯一标识每一行数据、不同表格之间通过哪些列关联起来。

更关键的一点是，架构里每个格子里填的数据不是凭空写上去的——每一个数值都必须附带"出处"，也就是具体的网页链接和网页上对应的原文片段。研究团队把这个设计叫做"带引用的关系型架构补全"（relational schema completion with grounded citations）。这套设计的好处在于，搜索进度变得可测量：哪些格子已经填完、哪些还空着、哪些数据有冲突，一目了然，任何人都可以验证每个数据从哪儿来的。

至于那些需要发现多少个实体（比如有多少首歌上榜）的开放性问题，系统会随着搜索的推进动态扩展表格的行数，覆盖率的计算也会随之更新，确保"所有已知行都填完"并不等同于"任务真正完成"。

三、SearchOS的"大脑调度中心"：四块共享记忆板

有了明确的表格任务之后，SearchOS需要一套机制让所有参与的智能体都能实时共享最新进展，而不是各自为战、互不知情。为此，研究团队设计了一个名为"面向搜索的上下文管理系统"（Search-Oriented Context Management，简称SOCM）的共享状态模块。可以把SOCM理解为一块四格白板，挂在所有智能体都能看到的地方，随时更新、随时查阅。

第一块格子叫"前沿任务池"（Frontier Task）。这里存放着所有待处理的子任务，每个任务都记录了它的类型、当前状态（待分配、进行中、已完成）、优先级、依赖关系（哪些任务必须在它之前完成）、负责它的智能体是谁，以及尝试过几次。任务池会自动检查依赖是否满足——只有所有前置任务都结束了，一个任务才会进入"可分配"状态。如果某个格子在分配任务的瞬间已经被别的智能体填完了，这个任务就会直接关闭，避免重复劳动。

第二块格子叫"证据图谱"（Evidence Graph）。每个智能体找到的每一条具体信息都以节点形式存储在这里，节点记录了数值本身、来源网址、网页上的原文片段、它对应的是哪张表的哪一行哪一列、可信度评分，以及它的"出处等级"——直接引用原文的可信度高于没有原文片段的页面引用，页面引用又高于二次推导出来的摘要。节点之间还有"支持"、"冲突"、"补充"三种关系边，当两条信息互相矛盾时，系统会标记冲突而不是随意覆盖其中一条。

第三块格子叫"覆盖率地图"（Coverage Map）。这是一张实时更新的表格填写状态图：每个格子的状态可能是"缺失"、"已填"、"不确定"或"无法获取"。当同一个格子有多条证据支持时，系统会按照出处等级、架构匹配度和可信度三个维度的优先级排序，选出最优的那条作为该格子的代表证据。这块格子让搜索进度从"感觉上差不多了"变成了一个精确的百分比数字。

第四块格子叫"失败记忆库"（Failure Memory）。每次搜索失败——不管是查询词没找到有用结果、目标网站无法访问、某个搜索技巧失效，还是某条数据被验证不符合架构要求——都会被记录在这里，附带失败类型、失败特征签名、纠正建议，以及同样的失败发生了多少次。随着同一失败模式反复出现，系统给出的"别再尝试这条路"的警告信号会越来越强。这套记忆跨所有智能体共享，避免一个智能体踩过的坑被另一个智能体再踩一遍。

四种记忆的所有更新都通过同一个锁定的读-改-写接口进行，确保任何时刻所有智能体看到的都是同一个版本的状态，不会出现数据不一致的情况。

四、流水线并行调度：不让任何一个工位闲着

有了共享状态板之后，SearchOS还需要解决"怎么调度"的问题。传统的多智能体系统通常采用批次调度：把一批任务同时派出去，等所有人都完成了才进入下一批。这个方式有一个明显的弱点——只要有一个任务拖拖拉拉，其他已经完成的智能体就只能空等，工位白白闲着。

SearchOS借鉴了深度学习训练中"流水线并行"（pipeline parallelism）的思想：每当一个智能体完成任务并释放了工位，系统立刻从任务池里抓取下一个优先级最高、依赖条件已满足的任务填进去，绝不让工位空着。这个"事件驱动"的持续调度策略，让整个系统的多个子任务可以在时间上重叠推进，就像一条高效的流水线。

实验数据说明了这个设计有多实际：在同等并发数量（8个智能体）的条件下，持续调度相比批次调度平均减少了24.3%的端到端时间，工位利用率从34.6%提升到41.7%，每分钟完成的任务数从2.99提升到3.37，同时大模型调用次数减少了（从341.4次降到296.6次），搜索质量也提升了（Item F1从79.66提升到86.75）。效率和质量双双提升，原因在于持续调度消除了批次间的闲置浪费，而不是靠堆更多计算资源换来的。

五、四种专业角色的分工协作

SearchOS中共有四种智能体角色，各司其职，通过SOCM而非直接对话来协调，有点像一个高效的编辑团队：每个人专注自己的工作，通过共享的项目看板来了解整体进展，而不是不停地开会汇报。

总协调员（Orchestrator）负责构建和调整关系型架构、将架构分解为具体子任务、设置任务优先级，以及决定什么时候可以停下来。它是唯一有权限修改架构和任务池的角色。

探索员（Explore Agent）负责在搜索初期摸清信息分布的地形：哪些网站可能有价值、目标实体的大致范围是什么、应该优先从哪里入手。它的工作成果是为后续的搜索任务提供"先验知识"，避免搜索员一头雾水地乱闯。

搜索员（Search Agent）是主力执行者：针对具体的表格格子，通过搜索、浏览网页、从网页中提取符合架构要求的证据，把数据填入表格。它是唯一可以使用技能库（后面会介绍）的角色。

撰写员（Writer Agent）在搜索工作基本完成后登场，读取证据图谱中积累的所有已验证信息，按照结构化大纲撰写最终报告，每一处数据都附带精确的内联引用。它没有搜索权限，只能读取已有的状态，确保报告完全基于已验证的证据。

六、搜索工具中间件护甲：把安全保障从提示词里搬出来

以上这套机制解决了"应该做什么"的问题，但还有另一个棘手问题：智能体在实际执行中会遇到各种意外，比如忘记任务状态、提示词里写的注意事项随着对话变长而被忽视、网页加载出错、陷入反复发出相似搜索请求的死循环、超出搜索次数预算等等。

传统做法是把所有这些安全规则都写进提示词，让智能体自己记住和遵守。但实验证明，这种方式对不同的智能体表现参差不齐——随着上下文变长，智能体越来越容易忘记提示词里的约束。

SearchOS的解决方案是把这些控制逻辑从提示词里搬出来，交给一个系统级的"搜索工具中间件护甲"（Search Tool Middleware Harness）来强制执行。这个护甲在智能体推理循环的两个关键节点介入，就像一个默默守护在旁边的监督员。

在每次大模型推理之前，"上下文中间件"先出手：它从SOCM中提取当前任务的相关状态（而不是把完整历史塞给模型），从技能库中检索当前任务适用的搜索技巧，把两者加上最近的操作历史拼接成模型真正看到的输入。当预算压力大的时候，它会修剪掉较早的交互历史，但始终保留状态和约束规则。

在每次工具调用（搜索、打开网页、关键词定位）执行完之后，"证据提取中间件"立刻介入：它从网页内容中提取所有可能的候选证据，但只有同时通过"架构绑定"（这条数据确实对应架构中某个格子）和"原文锚定"（网页上确实有这段原文）两项检查的数据，才会被正式写入证据图谱和覆盖率地图。这个过程是原子性的：要么同时更新两个记忆模块，要么都不更新，确保两者始终保持一致。

在整个执行过程中，"传感器中间件"持续监测两个指标：覆盖率变化（最近一段时间新填了多少格子）和证据图谱变化（最近新增了多少证据节点）。当这两个数字在连续若干轮内都是零时，系统判定搜索陷入了停滞。与此同时，传感器还计算预算压力——综合迭代次数、搜索次数、已用时间三个维度的利用率，取最大值。根据停滞状态和预算压力的组合，护甲会决定是继续执行、注入一条纠正建议（比如换一个搜索词或换一个网站）、请求补充任务、进入"只消化不新增"模式，还是强制停止这个分支。

因为这些干预发生在系统层面而非提示词层面，同样的保障机制对所有类型的智能体和所有角色都同等有效，不依赖某个特定模型是否"记性好"。实际轨迹分析显示，无论是在搜索早期、中期还是晚期触发循环检测，策略切换之后覆盖率都能重新开始增长。

七、层级化搜索技能库：让经验积累下来、反复使用

SearchOS的最后一个设计，是为搜索员提供一个可复用的技能库系统。这套系统把搜索知识分成三个层次，像一本不断更新的专业操作手册。

最上层是"协调员技能"，对应总协调员使用的全局策略：如何分解任务、如何对齐多张表格的行数据、如何验证最终合成结果的完整性。

中间层是"策略技能"，对应与具体信息来源无关的搜索方法：如何重新表述查询词、如何枚举和消歧义实体、如何进行结构化提取、如何处理多跳推理（需要从A推导到B再推导到C）、如何处理时间性问题、如何做聚合分析，以及当搜索陷入僵局时如何突破。

最底层是"访问技能"，对应特定网站的操作方式：Spotify官网怎么导航、美国参议院官网（Senate.gov）如何抓取议员信息、学术数据库OpenAlex如何查询、各类政府门户怎么绕过繁琐的页面结构直取数据。目前SearchOS-V1已预置了280个跨领域的技能，其中商业类138个、政府类36个、组织类33个，还有教育、通用API等类别。

有些访问技能不只是文字说明，而是打包成了"可执行访问技能"：一份说明文档（告诉智能体这个技能能做什么）、一份参数清单（定义调用接口）、一段实际运行的代码（负责发请求、处理错误、解析网页、输出标准化结果）。这样智能体只需要告诉技能"给我查一下俄克拉荷马州现任参议员"，背后的HTTP请求、网页解析、格式转换都由代码自动完成，智能体不需要从头摸索每个网站的结构。

技能检索通过向量相似度在任务相关维度上进行筛选，确保搜索员在每次任务开始时只看到真正相关的技能子集，而不是被全部280个技能压垮。

消融实验数据显示，加入技能库之后，Item F1提升了2.0个百分点，Row F1提升了3.4个百分点；更显著的是效率改善：每个任务的搜索会话时长减少了36.6%，搜索次数减少了39.1%，网页打开次数减少了42.7%。换句话说，技能库带来的质量提升不是靠更多搜索换来的，而是靠减少了无效探索。

八、实验结果：在两个权威榜单上均拿下第一

研究团队在两个开放域信息搜索基准测试上评估了SearchOS的表现，并与五个对照系统做了比较——其中ReAct和"计划后求解"（Plan-and-Solve）代表单智能体方法，A-MapReduce、Web2BigTable和Table-as-Search代表多智能体方法。

第一个基准测试是WideSearch，包含200道人工精选的问题（100道英文、100道中文），每道题都需要智能体从超过15个领域收集大量可验证的原子事实并整理成完整表格。SearchOS在所有指标上均排名第一：Item级别F1达到80.3（相比最强基准的76.0提升了4.3个百分点）、Precision达到83.9、Recall达到79.7；Row级别（要求一行里所有格子都正确才算分）的F1达到56.5，Precision 59.0，Recall 55.8。增益主要集中在召回率上，符合覆盖率导向调度设计的预期目标。

第二个基准测试是GISA，包含373道人工设计的查询，答案有四种结构类型：表格（Table）、集合（Set）、列表（List）和单项（Item）。这个测试同时要求深度多跳推理和广度跨来源聚合，难度更高。SearchOS在所有类型上均领先：Table类型Item F1达到76.9（+2.1），Table类型Row F1达到59.7（+1.6），List F1达到68.1（+1.0），Item精确匹配（EM）达到50.0（与最强基准持平）。最引人注目的是Set类型F1达到76.5，相比最强基准的63.1高出了13.4个百分点——这正是需要正确枚举完整答案集合的题型，覆盖率驱动的完整性检查在这里发挥了最大作用。

在架构设计的消融实验中，研究团队从40道可以拆分为多表架构的题目出发，发现固定单表和固定多表哪个更好是因题而异的，就算知道每道题用哪种固定架构更好、手动选最优架构，也仍然比SearchOS的动态架构规划低8.2个Item F1百分点。在实际运行中，SearchOS对这40道题里35道选择了单表架构、5道选择了多表架构，说明任务类型本身决定了最优结构，而不是"多表一定更好"。

九、三个真实搜索案例：系统在实战中的行为

除了汇总数据，研究团队还通过具体案例展示了SearchOS在执行层面的行为逻辑。

以Spotify 2024榜单任务为例（数据集中编号ws_en_022），系统先派出探索员确认两个官方榜单的数据来源和行数范围，再创建一张20行8列的表格（主键为"榜单类别+排名"的组合），接着把20首歌分成4批各5首、同时派出4个搜索员并行收集元数据，总协调员在每个搜索员完成后立刻更新覆盖率地图。覆盖率从25%逐步攀升到68.8%、89.4%，最终到达100%。但系统没有立即停下来——因为"所有已知格子都填完"不代表行数本身是完整的，总协调员额外做了一次行集合审计，确认20行全部符合两个官方榜单，才进入修复阶段（修正两条日期格式不一致的记录）。整个任务耗时362秒，221个证据节点，Item F1达到97.5。

另一个案例（ws_en_016）展示了"假饱和"的情况：覆盖率已达100%但表格只有16行，而两个搜索员的报告暗示应有约31个符合条件的赛事。系统正确拒绝了"已完成"的判断，派出补充任务，表格最终扩展到35行，同时还在验证过程中检测到一条重复记录并剔除了错误数据。

还有一个案例（ws_en_023）展示了受阻时的有界恢复：任务涉及Wiley和JSTOR上的学术文章，这两个网站反复返回访问限制或HTTP 402错误。传感器记录了智能体的两次策略切换，引导它转而使用Crossref和OpenAlex等替代数据源。当所有可尝试的来源和预算都耗尽后，系统没有编造未能找到的数据，而是保留了这些格子为"无法获取"状态，最终输出57行、96.3%覆盖率、Item F1和Row F1都达到93.8。

这三个案例共同说明了系统控制循环的三个关键原则：先探索后固定实体范围、把格子填满和行集合完整分别处理、在有界代价内恢复而不是无限尝试或无中生有。

说到底，SearchOS做的事情可以用一句话来概括：把AI搜索团队从"各自凭记忆做事"升级为"共享一块实时更新的任务板做事"。

过去，每个智能体都把所有任务进展、已知证据、失败教训存在自己的"对话历史"里，随着时间推移越来越难以管理。SearchOS把这些信息全部外化成四块明确的共享状态板——任务池、证据图谱、覆盖率地图、失败记忆——并用流水线调度确保没有工位空置，用中间件护甲确保搜索不会失控，用技能库确保有效的搜索模式可以反复复用。

这套设计在两个权威基准测试上均取得了所有对比方法中的最高F1得分，尤其在需要枚举完整答案集合的问题类型上大幅领先。从实用角度看，这意味着当你需要AI帮你做一份需要大量核实事实的复杂调研报告时，这类系统级设计将是可靠性和完整性的关键保障，而不是仅仅靠"模型更聪明"来解决问题。

研究团队表示，下一步计划将SearchOS扩展到更广泛的任务领域和多模态场景，并进一步提升系统在不同智能体、不同数据源之间的适应性。你可能想进一步思考的是：当AI系统需要为医学研究、法律文件审查或财务分析等对准确性要求极高的场景收集和归纳大量信息时，这套"让搜索状态对所有参与者都透明可见"的框架，能否成为一种通用的可靠性基础设施？完整论文可通过arXiv编号2507.15257查阅。

Q&A

Q1：SearchOS的SOCM是什么，有什么用？

A：SOCM是SearchOS的共享状态管理模块，相当于挂在所有智能体都能看到的四格白板。它记录了当前待处理的任务池、每条找到证据的来源和内容、每个表格格子的填写状态，以及之前失败过的搜索路径。这样每个智能体都能实时了解整体进展，不用从庞杂的对话历史里猜，也不会重复别人已经做过或失败过的工作。

Q2：SearchOS的流水线并行调度比批次调度强在哪？

A：批次调度要等一批任务全部完成才能开始下一批，只要有一个任务慢了，其他空闲的智能体工位就得干等着。SearchOS的持续调度是每当一个智能体完成任务释放工位，立刻从任务池抓取下一个优先级最高的任务填进去。实验显示这样能减少24.3%的总耗时，工位利用率提升7个百分点，同时搜索质量也更高。

Q3：SearchOS的搜索技能库里存的是什么内容？

A：技能库包含三类可复用知识：全局协调策略（如何分解任务和验证结果）、与来源无关的搜索方法（如何改写查询词、处理多跳推理、从困境中突破），以及针对特定网站的操作技能（比如怎么从美国参议院官网抓取议员信息、怎么调用学术数据库API）。目前已预置280个技能，实验显示加入技能库后搜索时间减少约37%、搜索次数减少约39%。