中国股票配资官网搜索智能体也需要「操作系统」：SearchOS 开源多智能体协作框架

让 Agent 上网查资料，已经不算新鲜事。

过去一年多，搜索智能体的能力提升主要沿着一条清晰路径展开：通过强化学习，让模型学会何时搜索、如何构造查询、怎样调用工具，以及如何根据页面内容继续推理。

但模型搜索能力的提升，并不会自然解决长程任务中的系统问题。在复杂的信息检索过程中，模型往往需要动态发现成百上千的实体、补齐大量属性，并在多个来源之间核验事实，有限窗口上下文的模型往往难以完成此类任务。

如果计划、进度、证据和失败记录主要保存在不断增长的对话上下文中，任务拉长后就容易出现几类问题：已经确认的事实随压缩丢失，不同子任务重复查询，多个 Agent 对字段口径理解不一，来源与结论脱钩，系统也很难准确判断 “已经完成多少、还缺什么”。

搜索 Agent 学会调用工具之后，下一个问题是：怎样让它在长程任务里搜得久、不重复、不失忆，还能知道自己究竟搜全了没有？

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

论文链接：https://arxiv.org/abs/2607.15257

GitHub 链接：https://github.com/antins-labs/SearchOS

项目官网：https://antins-labs.github.io/SearchOS/

YouTube 演示合集：https://www.youtube.com/watch?v=DZNXxMcxnMQ&list=PLXMUs3Ayz3EQ

作者介绍

本文的第一作者是张宇尧和高俊杰。张宇尧是中国人民大学高瓴人工智能学院的直博二年级研究生，研究方向主要是信息智能体，曾获 WWW2025 AgentSociety 大赛银牌、阿里巴巴 - 天池杯 xAFAC 大赛冠军，ACL2026 SAC Hightlight 论文奖；高俊杰是清华大学本科生、MBZUAI 的硕士研究生，研究方向为多模态大模型和信息智能体，目前就职于蚂蚁集团。

方法介绍

SearchOS 首先借鉴关系型数据库的设计理念，重新定义了开放域信息检索问题。给定自然语言请求 q, 系统首先创建一个关系搜索模式

其中 T_m 定义了表模式，A_m 是要填写的列，P_m 是区分每一行的主键，R 是表之间的对应关系。

简而言之，关系模式定义了搜索任务的信息结构，用主键识别待收集的实体，用外键连接不同类型的对象。

查一个事实、横向比较、全域调研、等等，各种信息检索问题都可以落到一套关系型模式上。简单任务可能只有几行；复杂任务可以有多张表，通过主键和外键连接。

系统一边发现实体、一边补属性，每个值同时保存 citation，可以回到对应网页和原文位置。

围绕这个定义，SearchOS 做了几项核心设计：

1. 面向搜索的上下文管理

作者的核心判断是：搜索状态应该存在于系统中，而不是存在于对话历史中。围绕这一判断，SearchOS 设计了 Search-Oriented Context Management（SOCM），将一次检索任务维护为四类持续演化的共享状态：

Frontier Tasks：保存带优先级和依赖关系的待办任务，明确哪些任务正在执行、等待或已完成；

Evidence Graph：记录 finding、source、confidence，以及证据之间的关系；

Coverage Map：关系模式的实时补全状态，持续显示哪些实体、属性和跨表依赖仍然缺失；

Failure Memory：记录无效查询、不可访问来源和缺失能力，避免后续 Agent 重复走入同一条失败路径。

可以将这一机制理解为是一种所有 Agent 共用的进度表：谁负责什么任务、收集到哪些信息，哪条路已经不再可行，通过查询一份共享的搜索状态来实现。

2. 流水线并行调度

有了 SOCM，SearchOS 采用了多智能体架构中常见的编排者 - 子智能体架构。在运行时，长生命周期的 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 道贴近真实检索场景的题，答案格式覆盖单项、集合、列表、表格，重点考察开放世界信息收集的全面性。

根据项目公布的 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 在探索过程中随发现的实体关系动态创建表结构的有效性。