搜索智能体也需要「操作系统」：SearchOS 开源多智能体协作框架

过去一年多，搜索智能体的能力提升主要沿着一条清晰路径展开：通过强化学习，让模型学会何时搜索、如何构造查询、怎样调用工具，以及如何根据页面内容继续推理。但模型搜索能力的提升，并不会自然解决长程任务中的系统问题。

在复杂的信息检索过程中，模型往往需要动态发现成百上千的实体、补齐大量属性，并在多个来源之间核验事实，有限窗口上下文的模型往往难以完成此类任务。如果计划、进度、证据和失败记录主要保存在不断增长的对话上下文中，任务拉长后就容易出现几类问题：已经确认的事实随压缩丢失，不同子任务重复查询，多个 Agent 对字段口径理解不一，来源与结论脱钩，系统也很难准确判断 '已经完成多少、还缺什么'。

来自人大和蚂蚁最新的研究工作 SearchOS 给出的答案，是把搜索状态做成一种可以调度的基础设施，并提供系统级的多智能体搜索协作。

SearchOS 首先借鉴关系型数据库的设计理念，重新定义了开放域信息检索问题。给定自然语言请求 q，系统首先创建一个关系搜索模式，其中 T_m 定义了表模式，A_m 是要填写的列，P_m 是区分每一行的主键，R 是表之间的对应关系。简单任务可能只有几行；复杂任务可以有多张表，通过主键和外键连接。

围绕这个定义，SearchOS 设计了 Search-Oriented Context Management（SOCM），将一次检索任务维护为四类持续演化的共享状态：Frontier Tasks（保存带优先级和依赖关系的待办任务）、Evidence Graph（记录 finding、source、confidence 及证据间关系）、Coverage Map（关系模式的实时补全状态）、Failure Memory（记录无效查询、不可访问来源和缺失能力）。这一机制可理解为所有 Agent 共用的进度表。

在运行时，长生命周期的 Orchestrator 负责统一规划、调度和收敛。它先通过 Explore 阶段理解问题并发现候选实体，再建立包含主键和表间关系的搜索模式，将尚未补全的实体、属性或关系拆成任务，分派给多个短生命周期 Search Agent。调度上采用流水线并行和连续派发机制，将每个搜索子任务看作 micro-batch，不同任务错峰进入、交叠推进，提高 Agent 槽位利用率和整体吞吐量。

为了让控制逻辑不依赖 Agent 自己记住并执行，SearchOS 在模型和工具之间加了一层搜索工具中间层（Search Tool Middleware Harness），包含 Context Middleware（按需注入相关状态并控制上下文规模）、Sensor Middleware（识别循环、重复查询和停滞）、Evidence Extraction Middleware（结构化抽取、单位归一、citation 锚定和证据入库）。每个搜索 Agent 只需处理局部搜索子任务，状态治理、证据处理和异常干预由系统层统一完成。

SearchOS 还构建了面向搜索 Agent 的层次化技能体系，将技能分为 orchestration、strategy 和 access 等类型。在开源的第一个版本中，作者们预置了约 280 个技能。Strategy skills 沉淀排名检索、多跳搜索、实体消歧等 '如何搜索' 的方法；access skills 处理反爬、登录墙、动态页面和深层目录等 '如何访问' 的问题。技能可以按任务路由和复用，也可以从成功与失败的搜索轨迹中继续演化。

作者同时指出，SearchOS-V1 的核心贡献是如何将搜索过程中的中间产物抽象为跨 Agent 共享的系统状态，并为任务执行提供基础设施。如何从数据源、交互轨迹以及用户意图自动化生成大规模技能，论文中明确留给后续工作来介绍和讨论。

为了评测 SearchOS 的有效性，作者们在两个开放信息检索基准上进行了评测。第一个是 WideSearch，面向大规模宽表信息收集，包含 200 道人工题（中英各 100），跨 15+ 领域，答案要落成可核验的完整表。另一个是 GISA，有 373 道贴近真实检索场景的题，答案格式覆盖单项、集合、列表、表格，重点考察开放世界信息收集的全面性。

根据项目公布的 max@3 结果，SearchOS 在全部 F1 指标上领先参评的单智能体与多智能体基线。其中 WideSearch Item F1 为 80.3、Row F1 为 56.5；GISA 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 在探索过程中随发现的实体关系动态创建表结构的有效性。