来自人大和蚂蚁最新的研究工作 SearchOS 给出的答案是把搜索状态做成一种可以调度的基础设施并提供系统级的多智能体搜索协作。让 Agent 上网查资料已经不算新鲜事。过去一年多搜索智能体的能力提升主要沿着一条清晰路径展开通过强化学习让模型学会何时搜索、如何构造查询、怎样调用工具以及如何根据页面内容继续推理。但模型搜索能力的提升并不会自然解决长程任务中的系统问题。在复杂的信息检索过程中模型往往需要动态发现成百上千的实体、补齐大量属性并在多个来源之间核验事实有限窗口上下文的模型往往难以完成此类任务。如果计划、进度、证据和失败记录主要保存在不断增长的对话上下文中任务拉长后就容易出现几类问题已经确认的事实随压缩丢失不同子任务重复查询多个 Agent 对字段口径理解不一来源与结论脱钩系统也很难准确判断 “已经完成多少、还缺什么”。搜索 Agent 学会调用工具之后下一个问题是怎样让它在长程任务里搜得久、不重复、不失忆还能知道自己究竟搜全了没有来自人大和蚂蚁最新的研究工作 SearchOS 给出的答案是把搜索状态做成一种可以调度的基础设施并提供系统级的多智能体搜索协作。论文链接https://arxiv.org/abs/2607.15257GitHub 链接https://github.com/antins-labs/SearchOS项目官网https://antins-labs.github.io/SearchOS/YouTube 演示合集https://www.youtube.com/watch?vDZNXxMcxnMQlistPLXMUs3Ayz3EQ作者介绍本文的第一作者是张宇尧和高俊杰。张宇尧是中国人民大学高瓴人工智能学院的直博二年级研究生研究方向主要是信息智能体曾获 WWW2025 AgentSociety 大赛银牌、阿里巴巴 - 天池杯 xAFAC 大赛冠军ACL2026 SAC Hightlight 论文奖高俊杰是清华大学本科生、MBZUAI 的硕士研究生研究方向为多模态大模型和信息智能体目前就职于蚂蚁集团。方法介绍SearchOS 首先借鉴关系型数据库的设计理念重新定义了开放域信息检索问题。给定自然语言请求 q, 系统首先创建一个关系搜索模式其中 T_m 定义了表模式A_m 是要填写的列P_m 是区分每一行的主键R 是表之间的对应关系。简而言之关系模式定义了搜索任务的信息结构用主键识别待收集的实体用外键连接不同类型的对象。查一个事实、横向比较、全域调研、等等各种信息检索问题都可以落到一套关系型模式上。简单任务可能只有几行复杂任务可以有多张表通过主键和外键连接。系统一边发现实体、一边补属性每个值同时保存 citation可以回到对应网页和原文位置。围绕这个定义SearchOS 做了几项核心设计1. 面向搜索的上下文管理作者的核心判断是搜索状态应该存在于系统中而不是存在于对话历史中。围绕这一判断SearchOS 设计了 Search-Oriented Context ManagementSOCM将一次检索任务维护为四类持续演化的共享状态Frontier Tasks保存带优先级和依赖关系的待办任务明确哪些任务正在执行、等待或已完成Evidence Graph记录 finding、source、confidence以及证据之间的关系Coverage Map关系模式的实时补全状态持续显示哪些实体、属性和跨表依赖仍然缺失Failure Memory记录无效查询、不可访问来源和缺失能力避免后续 Agent 重复走入同一条失败路径。可以将这一机制理解为是一种所有 Agent 共用的进度表谁负责什么任务、收集到哪些信息哪条路已经不再可行通过查询一份共享的搜索状态来实现。2. 流水线并行调度有了 SOCMSearchOS 采用了多智能体架构中常见的编排者 - 子智能体架构。在运行时长生命周期的 Orchestrator 负责统一规划、调度和收敛。它先通过 Explore 阶段理解问题并发现候选实体再建立包含主键和表间关系的搜索模式将尚未补全的实体、属性或关系拆成任务分派给多个短生命周期 Search Agent。在 Agent 调度上SearchOS 采用了两类成熟的 AI Infra 思路一类是流水线并行机制让不同频次同时处于流水线的不同阶段另一类连续派发某个请求一结束就立即把新请求补进空出的计算槽位而不是等待整批任务全部完成。可以把每个搜索子任务看作一个 micro-batch把 search → open → find 看作一条搜索流水线。多个 Search Agent 执行完整搜索链但不同任务会错峰进入、交叠推进哪个 Agent 先完成调度器就马上把新的 Schema 缺口转化为任务补进空闲槽位。这样既能让不同搜索阶段在时间上重叠也能避免被一批任务中最慢的那个拖住从而提高 Agent 槽位利用率、整体吞吐量和墙钟效率。3. 搜索工具中间层长程搜索里模型会丢任务状态、忽略约束实际应用时还会遇到工具报错、无效输出、死循环和预算控制等问题。只靠 Prompt 提醒很难控制各种商用或开源模型的异常行为。为了让这些控制逻辑不依赖 Agent 自己记住并执行SearchOS 在模型和工具之间加了一层搜索工具中间层 Search Tool Middleware Harness 其中Context Middleware 负责按需注入相关状态并控制上下文规模Sensor Middleware 识别循环、重复查询和停滞Evidence Extraction Middleware 负责结构化抽取、单位归一、citation 锚定和证据入库。每个搜索 Agent 只需处理局部搜索子任务实现干净、连贯地推理和搜索而状态治理、证据处理和异常干预由系统层统一完成。4. 层次化搜索技能库SearchOS 还构建了面向搜索 Agent 的层次化技能体系将技能分为 orchestration、strategy 和 access 等类型。在开源的第一个版本中作者们预置了约 280 个技能。其中 Strategy skills 沉淀排名检索、多跳搜索、实体消歧等 “如何搜索” 的方法access skills 处理反爬、登录墙、动态页面和深层目录等 “如何访问” 的问题。技能可以按任务路由和复用也可以从成功与失败的搜索轨迹中继续演化并在隔离工作进程中执行。作者同时指出SearchOS-V1 的核心贡献是如何将搜索过程中的中间产物抽象为跨Agent共享的系统状态并为任务执行提供基础设施。如何从数据源、交互轨迹以及用户意图自动化生成大规模技能论文中明确留给后续工作来介绍和讨论。实验结果为了评测 SearchOS 的有效性作者们在两个开放信息检索基准上进行了评测。 第一个是 WideSearch 这是一个面向大规模宽表信息收集的任务 包含 200 道人工题中英各 100 跨 15 领域答案要落成可核验的完整表。另一个是 GISA 有 373 道贴近真实检索场景的题答案格式覆盖单项、集合、列表、表格重点考察开放世界信息收集的全面性。根据项目公布的 max3 结果SearchOS 在全部 F1 指标上领先参评的单智能体与多智能体基线。其中 WideSearch Item F1 为 80.3、Row F1 为 56.5GISA Table Item F1 为 76.9、Set F1 为 76.5。在要求枚举完整集合的 Set F1 上SearchOS 比次优基线高 13.4 分其增益主要来自 Coverage Map 驱动的持续补漏。为了进一步验证关系搜索模式的灵活性作者们还在 40 道可拆成多表的题上进行了实验。他们首先使用 GPT5.5 预先构建了单表和多表结构并分别进行收集任务。结果表明即便人为给每道题提前指定最优表结构Oracle Item F1 仍比 SearchOS 低 8.2 Row F1 低 7.7 。这表明真实场景下不同信息收集任务适用的表结构不同从而验证了 SearchOS 在探索过程中随发现的实体关系动态创建表结构的有效性。基于流水线并行的连续派发机制能够显著提高系统的吞吐量、降低模型调用次数和运行时间同时提高效果Case 研究则进一步表明所设计的 Sensor 中间件能够在搜索过程的早期、中期和后期停滞时干预 Agent 搜索行为从而推动搜索过程的顺利完成。预先构建的技能则进一步缩短了系统的运行时间并显著降低了搜索和 Jina API 的调用次数从而降低了一次搜索任务的所需成本。总结在 SearchOS 中作者们所尝试解决的并不是 “怎样再设计一个搜索 Agent 或算法”而是一个更基础也更加本质的问题当搜索成为长程、多角色协作、需要持续恢复和证据追溯与核验的系统任务时Agent 之间应该共享什么状态系统又该如何调度、监督并收敛它们。目前 SearchOS 已提供 CLI、全屏 TUI 和 Web 研究工作台。用户可以实时查看 Schema 补全进度、Agent 任务流和逐格证据中途退出后也可以继续运行或回头复盘。项目支持多家模型服务商和本地部署首次运行可通过配置向导完成设置如果你是做竞品研究、学校 / 产品对比、榜单或作品完整枚举、多跳信息核验或者在咨询、投研、BD、科研里经常要做 “尽量找全、每条都有出处” 的长程调研这个框架很值得试试看。