论文综述：SearchOS-V1：面向鲁棒开放域信息检索的智能体协作系统

一、论文是干什么的？

想象你和几个同事一起做一份市场调研报告，任务是把某个行业里所有公司的名称、成立时间、创始人、融资轮次都查清楚，填进一张大表格里。如果大家各干各的，没人记笔记，没人同步进度，很容易出现的情况是：小王查了半天发现某个网站根本没有相关信息，但十分钟后老张又不知情地去搜了同一个网站；或者查到后面大家都忘了哪些公司还没查、哪些格子已经填好，最后交上来的表格东一块西一块，还有大量重复劳动。

这正是当前”网页搜索智能体”（会自己上网搜资料、点链接、读网页的 AI Agent）面临的真实问题。现在很多系统会同时派出多个 AI 智能体去分头搜索信息，但这些智能体之间的”记忆”往往只存在于各自的对话历史里，是隐式的、脆弱的。一旦某个方向搜不到有用证据，智能体常常意识不到”这条路走不通”，于是不断重复失败的搜索动作，白白浪费搜索预算（比如允许搜索的次数、允许打开网页的次数），最终导致答案不完整、遗漏很多本该找到的信息。

SearchOS-V1（简称 SearchOS）就是为了解决这个”团队协作失忆症”而设计的一套系统。它的核心思路很朴素：把原本藏在每个智能体脑子里、说不清道不明的”搜索进度”，变成一份大家都能看得见、能持久保存、能共享的”账本”，就像给整个团队配了一块共享白板和一位项目经理，谁查过什么、哪里查不到、还缺哪些信息，全都写在白板上，人人可查、实时更新。

二、核心方法与创新

1. 把”查资料”重新定义为”填一张关系表”

论文的第一个创新是重新定义任务本身。它不再把”开放域信息检索”看作一个模糊的问答任务，而是形式化为”关系型模式补全（relational schema completion）“：系统先根据用户需求搭建一个或多个互相关联的表格（比如”公司表”和”融资事件表”，通过公司ID关联），然后不断发现新的实体（行）、填充属性（列），并且每一个填进去的值都必须绑定一个来源证据（citation），包括来源网址和网页里具体的文字片段。这就像做调查报告时要求”每一句话后面都要标注引用出处”，既保证了可验证性，也让”哪些格子还空着”变得一目了然。

2. Search-Oriented Context Management（SOCM，面向搜索的上下文管理）

这是全文最核心的机制，相当于团队共享的”项目管理看板”，包含四块相互配合的共享状态：

• Frontier Task（前沿任务池）：一个带依赖关系的待办事项列表，记录哪些子任务已完成、哪些正在进行、哪些还没开始，并自动去重，避免两个智能体重复领取同一个任务。
• Evidence Graph（证据图）：把每一条搜索到的”原子事实”存成一个节点，记录它的具体数值、来源、在网页中的位置、绑定到哪个表格字段、置信度、来源可信等级和状态；节点之间还会标注”支持/冲突/细化”关系，类似给每条证据都做了”事实核查交叉引用”。
• Coverage Map（覆盖地图）：把表格里的每一个格子标成”缺失/已填/存疑/不可达”四种状态，并统计支持证据、检测冲突，相当于一张实时更新的进度总览表。
• Failure Memory（失败记忆）：专门记录哪些搜索词没用、哪些网站打不开、哪些”招式”（搜索策略/技能）用了也没效果，防止不同智能体或同一智能体在后续回合里重蹈覆辙——这就像团队白板上专门贴一张”此路不通”的清单。

3. 流水线并行调度（Pipeline-Parallel Scheduling）

传统多智能体系统常常”批处理”式运行：所有智能体一起出发、一起汇报、再一起出发下一轮，如果有人先干完了，也得等最慢的那个。SearchOS 改用类似操作系统调度进程的方式，一旦有智能体的”槽位”空出来，就立刻从任务池里挑一个优先级最高的任务塞进去继续跑，而不用等整批同事都完工。论文用一条调度规则

$$\mathrm{Top}_{\min(b_t, |R_t|)}(R_t; p)$$

表达这个逻辑：从当前就绪任务集合 $R_t$ 中，按优先级 $p$ 挑出最多 $b_t$ 个（受限于并发预算与就绪任务数）分配给空闲智能体。这种”随到随分”的方式减少了智能体的空闲等待时间，效率明显提升。

4. Search Tool Middleware Harness（搜索工具中间件）

这是介于”大模型”和”搜索/浏览工具”之间的一层”管家”，在三个关键节点做拦截和处理，而不需要每次都靠模型自己在提示词里判断：

• 上下文中间件：在模型推理前，把与当前角色相关的状态摘要和检索到的”技能”拼装好喂给模型；
• 证据抽取中间件：在把一条观察结果正式写入证据图之前，先校验它是否既绑定了表格字段、又能定位到网页原文片段（双重校验），防止”张冠李戴”或”无中生有”；
• 传感器中间件：持续监控覆盖率、证据数量等指标的变化量，一旦某个智能体连续若干轮没有任何进展（判定为”卡住了”）或预算即将耗尽，就主动触发干预（比如切换策略、终止无效分支）。

5. 分层搜索技能库

系统内置约280个预先设计好的”搜索技能”，分三层：调度层（任务拆解、表格对齐、结果校验）、策略层（改写查询、枚举实体、结构化抽取、时间推理）、访问层（针对数据库、政府网站、百科、企业官网等不同信源的具体检索方法）。相当于给每个智能体配了一本”武功秘籍”，遇到不同类型的网站知道该用哪招，而不是每次都从零摸索。

打个比方，如果说传统多智能体搜索像是几个侦探各自凭记忆办案、偶尔口头汇报进度，SearchOS 更像是给整个侦探团队配了一块实时更新的案件看板（证据链、嫌疑排除清单、任务分工表），外加一位不知疲倦的调度员随时补位、一位记录员专门核对每条证据的出处，效率和完整性自然更高。

三、使用了哪些模型和计算资源？

• 智能体主干模型：GLM-5，承担 orchestrator（编排/建表）、explore（候选实体发现）、search（证据收集）、writer（报告合成）等多种角色。
• 证据抽取模型：Qwen3.5-35B-A3B（专门用于从网页内容中抽取并校验证据）。
• 执行约束（资源预算）：每个会话最多50轮编排迭代、最多8个子智能体并行、每个智能体最多20次搜索、单次会话总耗时预算1800秒（约30分钟）。
• 评测方式：采用”三次运行取最优”（Max@3）并按百分制换算得分。
• GPU/训练细节：论文中未提及自行训练模型所需的GPU型号、数量或训练时长，SearchOS 更像是一套基于现成大模型API（GLM-5、Qwen3.5系列）搭建的系统级编排框架，而非从头训练新模型，因此暂无相关信息关于底层模型的预训练/微调计算资源与耗时。

四、实验结果

论文在两个基准上做了测试：

基准	指标	SearchOS	最强基线	提升
WideSearch（200题，15+领域）	Item-level F1	80.3	76.0（A-MapReduce）	+4.3
WideSearch	Row-level F1	56.5	54.5（Web2BigTable）	+2.0
WideSearch	召回率	79.7%	74.2%	+5.5%
GISA（373题，四种答案格式）	Set F1	76.5	63.1	+13.4
GISA	Table Item F1 / Row F1 / List F1	76.9 / 59.7 / 68.1	-	-
GISA	Exact Match	50.0%（打平最优）	-	-

几项消融实验也很能说明问题：

• 去掉”自主建表”能力、改用固定单表模式，Item F1 下降8.2分、Row F1 下降7.7分，说明系统能根据问题复杂度智能决定”要不要拆多张表”（87.5%的情况用单表，12.5%用多表）非常关键。
• 把流水线并行调度换回传统批处理调度，端到端耗时增加24.3%，智能体槽位利用率从41.7%降到34.6%，LLM调用次数增加13.2%，Item F1 从86.75降到79.66——说明”随到随分”的调度方式既省时间又省钱还提分。
• 去掉分层技能库，Item F1 下降2.0分、Row F1 下降3.4分，同时会话耗时增加36.6%、搜索调用增加39.1%、页面加载增加42.7%——说明”武功秘籍”确实能让智能体少走弯路。
• 中间件里的”卡住检测”（Loop Sensor）在早期、中期、后期不同阶段的停滞情况下都能观察到干预后覆盖率重新提升。

总体而言，SearchOS 的提升主要体现在”召回率”和”信息完整性”上——也就是说，它不是让答案更准，而是让答案更全，遗漏更少，这正好对应论文想解决的”重复循环导致遗漏”痛点。

五、潜在应用与已落地应用

潜在应用场景：

• 企业竞品/行业调研自动化（自动生成公司名录、融资信息表）
• 政务/公开数据的结构化信息汇总（如政策文件、法规条款的批量核对）
• 学术文献的实体信息聚合（作者、机构、基金编号等的交叉整理）
• 电商/招聘等场景中大规模、多来源信息的表格化整理
• 任何需要”广度优先、追求完整覆盖”而不是”单点问答”的深度搜索任务

已落地案例：

• 项目已开源在 GitHub：antins-labs/SearchOS，仓库简介为”像操作系统调度进程一样调度搜索智能体”（Schedule search agents the way an OS schedules processes）。
• 论文由蚂蚁集团（Ant Group）与中国人民大学高瓴人工智能学院联合完成，属于工业界与学术界结合的实际系统级工作，具备直接产品化的背景，但公开资料中未提及具体已上线的商业产品名称，暂无相关信息关于其在蚂蚁集团内部具体业务中的落地细节。

六、网络上的讨论与评价

通过检索论文标题、arXiv编号以及相关关键词，目前只找到 arXiv 原文页面、GitHub 项目页面等一手资料，未检索到 Reddit、Twitter/X、知乎或技术博客上的专门讨论帖。考虑到该论文在 HuggingFace 上获得了58票（说明在 HuggingFace 论文社区有一定关注度），但暂无广泛的第三方评价或深度解读文章，如实说明：目前网络上围绕本文的公开讨论较为有限，多为论文列表/检索聚合页面的收录，尚未发现有分量的独立评测或争议性讨论。

Sources:

• arXiv abstract
• arXiv HTML 全文
• HuggingFace 论文页
• GitHub - antins-labs/SearchOS

七、思维导图

mindmap
  root((SearchOS-V1：开放域信息检索智能体协作))
    研究背景与问题
      现有方法的局限
        隐式上下文导致进度易丢失
        证据稀缺时陷入重复搜索循环
        单/多智能体系统缺乏共享状态
        搜索预算浪费导致输出不完整
      本文解决的核心挑战
        如何将隐式进度显式化、持久化、共享化
        如何在大规模宽域检索中保证召回完整性
    方法与技术贡献
      任务重构
        关系型模式补全 relational schema completion
        多表主外键结构
        实体行发现与属性列填充
        证据引用矩阵（值-来源URL-锚定片段）
      Search-Oriented Context Management SOCM 面向搜索的上下文管理
        Frontier Task 前沿任务池
          依赖感知任务池
          状态追踪与去重
        Evidence Graph 证据图
          节点：数值/来源/片段/字段绑定/置信度/可信等级
          边：Support关系
          边：Conflict关系
          边：Refine关系
        Coverage Map 覆盖地图
          缺失/已填/存疑/不可达四态
          支持证据集合
          冲突检测
        Failure Memory 失败记忆
          无效查询记录
          不可访问来源记录
          失败技能模式记录
      流水线并行调度
        四类智能体角色
          orchestrator 建表编排
          explore 候选实体发现
          search 证据收集
          writer 报告合成
        事件驱动持续分派
        调度规则 Top_min(b_t,|R_t|)(R_t;p)
        对比批处理调度提升槽位利用率
      Search Tool Middleware Harness 搜索工具中间件
        Context Middleware 上下文中间件（角色状态投影+技能检索）
        Evidence Extraction Middleware 证据抽取中间件（双重校验：字段绑定+片段锚定）
        Sensor Middleware 传感器中间件（停滞检测与预算压力监控）
      分层搜索技能库
        约280个预置技能
        调度层技能：任务拆解/模式对齐/合成校验
        策略层技能：查询改写/实体枚举/结构化抽取/时序推理
        访问层技能：数据库/政府网站/百科/企业站点
      浏览器抽象层
        LIFO页面栈
        缓存内容与跨页查找
    实验设计与结果
      数据集与Baseline
        WideSearch 200题 15+领域 中英双语
        GISA 373题 四种答案格式
        对比A-MapReduce、Web2BigTable等基线
        Max@3评测协议
      主要指标结果
        WideSearch Item F1 80.3
        WideSearch Row F1 56.5
        GISA Set F1 76.5（+13.4）
        GISA EM 50.0%
      消融实验结论
        固定单表 vs 自主建表：F1下降7-8分
        批处理 vs 流水线调度：耗时+24.3% F1降至79.66
        去除技能库：会话耗时+36.6% 搜索调用+39.1%
        Loop Sensor干预在多阶段恢复搜索进度
    理论分析与洞察
      为什么有效
        显式共享状态减少重复劳动
        证据双重校验降低幻觉绑定
        持续调度降低智能体空闲
      局限性与边界条件
        依赖预置技能库覆盖度
        1800秒会话预算与8并发上限的资源约束
        证据抽取模型对长尾网页结构的鲁棒性未知
    影响与展望
      潜在应用场景
        企业竞品与行业调研自动化
        政务与法规信息结构化汇总
        学术实体信息聚合
        电商与招聘多源信息表格化
      未来研究方向
        面向更大规模实体图的调度优化
        跨语言、跨模态证据整合
        与端到端训练型搜索模型的结合