---
Categories:

"paper_analysis"
Topics:
"multi_agent_systems"
"memory_mechanism"
"rag"
"knowledge_graph"
"reasoning"
"llm"
References:
"renmin_university"
"ant_group"
"searchos"
"widesearch"
"gisa"
Credibility: "100"
CreateDate: 2026-07-18
UpdateDate: 2026-07-18
tags:
star
title: "SearchOS-V1: Towards Robust Open-Domain Information-Seeking Agent Collaboration"
RelatedNotes:
"memory_in_the_age_of_ai_agents_a_survey"
"danus_orchestrating_mathematical_reasoning_agents_with_fact_graph_memory"
"memgpt_towards_llms_as_operating_systems"
dg-publish: true

SearchOS-V1: Towards Robust Open-Domain Information-Seeking Agent Collaboration

基本信息

标题: SearchOS-V1: Towards Robust Open-Domain Information-Seeking Agent Collaboration
第一作者: Yuyao Zhang (Gaoling School of Artificial Intelligence, Renmin University of China; Ant Group)
研究团队: renmin_university, ant_group
会议/期刊: arXiv preprint arXiv:2607.15257v1 [cs.AI], 2026
代码: https://github.com/antins-labs/SearchOS
PDF 文件: [SearchOS-V1](file:///C:/Users/admin/.openclaw/workspace/attachment/papers/20260718_searchos_v1_open_domain_information_seeking_agent_collaboration.pdf)

研究摘要

在工具增强型大语言模型（Tool-Integrated LLMs）蓬勃发展的今天，网络搜索已成为信息检索智能体（information-seeking agents）的核心能力。然而，当这些智能体被推向开放域、长程、多跳的真实信息收集任务时，一个根本性的脆弱性逐渐暴露：随着交互历史的膨胀，智能体越来越难以追踪自己已经证明了什么、还没有证明什么，以及哪些搜索路径已经证明是死胡同。这种记忆的坍塌并不是简单的上下文长度问题，而是结构性的——传统系统把计划、进展、证据与失败都当作临时的对话内容，让智能体在每次决策时从冗长的历史记录中重新推断全局状态。结果是，当搜索尝试无法获得有效证据时，单智能体与多智能体系统都会陷入重复循环，浪费搜索预算，最终降低答案的完整性与可信度。SearchOS-V1 正是针对这一核心问题提出的系统级回应。

本文的核心理论洞见在于：开放域信息检索不应被当作一场无结构的自由对话，而应被形式化为**关系模式补全（relational schema completion）**问题。作者借鉴关系数据库设计中的主键、外键与规范化原则，将用户请求转化为一个由多个关联表组成的搜索模式；智能体的任务于是从“生成一段回答”变成了“发现实体行、填充属性列、并为每个值绑定可验证的引用”。这种重构的深远意义在于，它把原本模糊的“搜索进度”转化为可度量的模式覆盖度，把原本散落在对话中的证据转化为结构化的来源矩阵。每一个被填入表格的值都必须附着一个来源 URL 与一段锚定摘录，从而让最终报告中的每一个事实都可以独立核查。

基于这一形式化，论文提出了四个相互支撑的技术贡献。第一，关系化搜索形式化，将开放域信息检索统一为带引用验证的关系模式补全任务。第二，搜索导向的上下文管理（Search-Oriented Context Management, SOCM），将执行状态外化为 Frontier Task、Evidence Graph、Coverage Map 与 Failure Memory 四种持久共享结构，使多智能体能够在同一份状态上协作。第三，搜索工具中间件 Harness（Search Tool Middleware Harness），在模型调用与工具调用之间插入系统级拦截层，负责注入状态、抽取证据、执行预算、检测停滞，让智能体本身可以专注于局部搜索决策。第四，分层搜索技能系统，将可复用的搜索策略与站点特定的访问路径分离，并在多次运行中从成功与失败轨迹中提炼经验。

实验结果令人信服。在 WideSearch 与 GISA 两个基准上，SearchOS 在所有 headline F1 指标上均领先于所评估的单智能体与多智能体基线。具体而言，SearchOS 在 WideSearch 上取得 80.3 的 Item F1，在 GISA 上取得 76.5 的 Set F1，后者比最强基线高出 13.4 个百分点。这些增益主要集中在召回率与完整性指标上，精准地验证了作者的设计假设：当系统能够显式追踪未覆盖的模式单元、协调并行工作流、并从失败中学习时，长程搜索的完整性可以被显著改善。这项工作不仅为信息检索智能体提供了一种更鲁棒的工程范式，也为未来“智能体操作系统”的发展提供了重要启示——搜索状态应该由系统维护，而不是由智能体在对话中反复重建。

理论框架

2.1 思想谱系：从关系数据库到搜索智能体

SearchOS-V1 的理论根基横跨三个传统领域。其一，关系数据库理论。Codd 于 1970 年提出的关系模型以及 Bernstein 关于范式与函数依赖的研究，为“如何用表、主键、外键组织事实”提供了数学基础。作者将这些经典思想迁移到开放域搜索场景：一个复杂的信息需求可以被分解为多个相互关联的表，主键标识实体，外键表达跨表关系，规范化减少冗余与不一致。其二，工具增强型语言智能体。从 ReAct 到 WebGPT，再到近期的 Search-R1 与 WebThinker，研究者一直在探索如何让语言模型迭代地搜索、浏览与推理。SearchOS 并不否定这些模型级能力，而是指出它们缺少一个系统级支撑层：当交互历史变长时，模型会遗忘已验证的事实与已失败的尝试。其三，多智能体协作系统。AutoGen、MetaGPT 等框架展示了角色分工与消息传递的价值，但协调状态通常仍停留在对话或计划文本中。SearchOS 主张把协调状态彻底外化，使其像数据库事务一样可被锁定、读取与修改。

2.2 核心概念：搜索状态的四重外化

论文将原本隐含在对话中的搜索状态显式化为四个相互关联的抽象。

Frontier Task（前沿任务） 把模式缺口转化为可调度的工作单元。每个任务 $f_{j}$ 包含类型 $κ_{j}$ 、状态 $s_{j}$ 、优先级 $p_{j}$ 、依赖 $B_{j}$ 、目标单元 $Z_{j}$ 、指派智能体 $a_{j}$ 与尝试次数 $n_{j}$ 。只有当所有依赖任务都终止后，任务才会进入就绪集合：

R_{t} = {f_{j} \in F_{t} ∣ s_{j} = PENDING \land B_{j} \subseteq T_{t}}

这里 $T_{t}$ 是已经终止的任务 ID 集合。这个定义使得任务调度天然具备 DAG 依赖语义，避免了随意并行导致的顺序混乱。

Evidence Graph（证据图） 保存原子级发现而非页面级摘要。每个节点 $g_{i} = (v_{i}, u_{i}, x_{i}, b_{i}, γ_{i}, τ_{i}, s_{i})$ 记录了值、来源 URL、支撑片段、模式绑定 $b_{i} = (m_{i}, e_{i}, a_{i})$ 、置信度、来源层级与状态。来源层级 $τ$ 区分“锚定摘录”、“未锚定页面”与“派生摘要”，让系统优先相信直接证据而非二次推理。节点之间通过 SUPPORT、CONFLICT、REFINE 三类关系相连，从而能够表示证据之间的 corroboration 与冲突。

Coverage Map（覆盖图） 把进度量化为模式单元层面的填充状态。每个单元 $c = (m, e, a)$ 可以被标记为 missing、filled、uncertain 或 unreachable。当多个证据支持同一单元时，系统按字典序选择：

g_{c}^{*} = \arg max_{g \in H_{c}} ⟨ τ (g), α (g), γ (g) ⟩

其中 $τ$ 是来源层级， $α$ 是模式对齐度， $γ$ 是经权威性调整后的置信度。如果多个证据互相矛盾，则标记为冲突而非简单覆盖。覆盖率的计算公式为：

C o v (C_{t}) = \frac{\sum_{c \in Ω_{t}} 1 [s (c) = FILLED]}{| Ω_{t} | + \sum_{m : | E_{m} (t) | = 0} | A_{m} |}

分母中的额外项确保：即使一张表暂时没有发现任何实体行，它也不会被误判为已完成。这一细节体现了作者对“已知行”与“应存在行”之间张力的深刻理解。

Failure Memory（失败记忆） 记录不成功的搜索模式，防止不同智能体重复踏入同一条死胡同。每条记录 $w_{k} = (η_{k}, σ_{k}, χ_{k}, n_{k}, t_{k})$ 包含失败类型、任务级签名、纠正建议、复发次数与最近发生时间。复发次数越高，系统对“不要重试”的约束越强。

2.3 数学形式化与搜索目标

整个任务被形式化为一个元组 $T = (q, S)$ ，其中 $q$ 是自然语言请求， $S$ 是关系搜索模式：

S = {T_{m}}_{m = 1}^{M}, R, T_{m} = (A_{m}, P_{m})

$T_{m}$ 表示第 $m$ 张表， $A_{m}$ 是其属性集合， $P_{m}$ 是主键属性集合， $R$ 是外键关系集合。对于每张表，系统需要发现实体集合 $E_{m} = {e_{m, i}}_{i = 1}^{N_{m}}$ 并填充值矩阵 $Y_{m} \in V^{N_{m} \times | A_{m} |}$ 。与传统表格补全不同，每个值必须绑定来源证据，因此系统同时维护同形的引用矩阵 $C_{m}$ 。最终输出为：

O = {E_{m}, Y_{m}, C_{m}}_{m = 1}^{M}

这一形式化的精妙之处在于，它把“开放域信息检索”这个看似无法定义终止条件的问题，转化为一个近似可验证的搜索目标：当模式单元被填充、证据被锚定、冲突被标记、未覆盖单元被承认时，系统就可以给出有理论依据的停止决策。

SOCM 整体状态被定义为：

M_{t} = (F_{t}, G_{t}, C_{t}, W_{t})

每个智能体角色 $r$ 只接收针对其职责的投影：

x_{t}^{(r)} = ϕ_{r} (M_{t}; z_{t})

orchestrator 看到全局缺口与优先级，search agent 看到被指派的单元与相关证据，writer 看到紧凑摘要。投影机制既保护了信息隐私，又避免了模型上下文被完整状态淹没。

2.4 核心算法：流水线并行的连续调度

SearchOS 的调度逻辑可以看作一个事件驱动的流水线。设 $b_{t}$ 为 $t$ 时刻可用的执行槽位数， $R_{t}$ 为就绪任务集合，则系统按优先级 $p$ 选择任务：

D_{t} = {Top}_{min (b_{t}, | R_{t} |)} (R_{t}; p)

每当一个智能体完成并释放槽位，系统立即重新计算 $R_{t}$ 并填充新任务。这与传统批处理调度形成鲜明对比：后者必须等待整批任务全部完成才能进入下一轮，而连续调度通过重叠执行阶段减少了“straggler”造成的空闲。论文明确将这一思想追溯到 Huang et al. (2019) 与 Narayanan et al. (2019) 在 GPU 训练中对 pipeline parallelism 的利用，显示出跨领域方法迁移的自觉。

2.5 假设与适用范围

该理论框架的边界也十分清晰。首先，它假设信息可以被合理地组织成关系模式；对于高度叙事性、难以表格化的请求，模式化本身可能成为负担。其次，它要求每个事实都能追溯到外部来源并锚定到文本片段；这对事实型查询有效，但对需要解释、评价或主观判断的查询则较难直接应用。最后，系统依赖搜索工具与浏览器的稳定性；当大量来源被屏蔽、付费或反爬虫时，引用验证会受到限制。作者在论文中诚实地承认了这些边界，并在实验附录中展示了在不可访问来源下的有界恢复行为。

技术架构

3.1 系统概览：一个状态化的闭环

SearchOS 的整体架构可以被理解为一个“搜索操作系统”：用户输入的请求首先被转化为关系模式，然后被分解为可并行执行的任务，多个专用智能体在共享状态上协作，最终由 writer 生成带引用的结构化报告。系统的四大支柱——SOCM、多智能体编排器、搜索工具中间件 Harness 与分层技能库——并非简单并列，而是形成了一个紧密耦合的闭环。

在这一闭环中，数据流的路径大致如下：用户的自然语言请求 $q$ 进入 orchestrator，orchestrator 构建或更新搜索模式 $S$ ，并把模式缺口转化为 Frontier Task 中的任务；调度器根据当前可用槽位与就绪任务集合 $R_{t}$ 选择要执行的子任务；search agent 或 explore agent 接收到任务后，在上下文中间件准备好的状态投影下进行推理，选择浏览器或技能工具；工具调用结果先经过证据抽取中间件，再进入传感器中间件；如果证据被接受，则原子地更新 Evidence Graph 与 Coverage Map；如果检测到停滞或预算耗尽，Harness 会注入纠正措施或停止分支；最后，当 Coverage Map 显示主要缺口已解决，writer 被激活，基于 Evidence Graph 生成带引用的报告。

3.2 角色分工与工具隔离

为了保持每个角色的行动空间专注，SearchOS 为不同角色分配了不同的工具集，如表所示。

工具组	Orchestrator	Search	Explore	Writer
SimpleBrowser（搜索/打开/查找）	–	✓	✓	–
Schema & Entity CRUD	✓	–	–	–
Task Queue & Coordination	✓	–	–	–
Outline Management	–	–	–	✓
SOCM Read	–	–	–	✓
Skill Catalog（列出/加载）	–	✓	–	✓

这一分工体现了“系统保留状态变更权，智能体保留局部决策权”的设计哲学。Schema 与任务的修改只能由 orchestrator 完成，避免多个智能体同时改写全局结构；浏览与技能加载交给 search 与 explore 智能体，使其能够自主探索；writer 只读 SOCM 状态并管理报告大纲，保证最终输出与证据一致。

3.3 搜索工具中间件 Harness：把治理从提示词中剥离

Search Tool Middleware Harness 是 SearchOS 最具工程野心的组件。它包含三个相互衔接的中间件：Context Middleware、Evidence Extraction Middleware 与 Sensor Middleware。

在每次模型调用前，Context Middleware 将最近历史 $h_{t}$ 、共享状态 $M_{t}$ 与检索到的技能 $K_{t}$ 合成为角色特定的上下文：

v_{t}^{(r)} = ϕ_{r} (M_{t}), K_{t} = TopK_Retrieve (q, S, v_{t}^{(r)})

{\tilde{h}}_{t}^{(r)} = h_{t} \oplus v_{t}^{(r)} \oplus ψ (K_{t})

其中 $\oplus$ 表示上下文组合， $ψ$ 负责渲染技能。关键设计在于：投影保留了目标单元、已锚定证据、缺口与失败记录，但不必序列化整个交互历史。在预算压力下，旧的交互会被裁剪，但状态与活动约束始终保留。

工具调用返回后，Evidence Extraction Middleware 从观察 $o_{t}$ 中抽取候选证据：

E_{t}^{b} = Extract (o_{t}, S, C_{t})

一条候选证据只有在同时满足模式绑定与片段锚定时才会被接受：

E_{t}^{+} = {z \in E_{t}^{b} ∣ Bind (z, S) = 1 \land Anchor (z, o_{t}) = 1}

被接受的证据随后被原子地提交：

(G_{t + 1}, C_{t + 1}) = U_{evidence} (G_{t}, C_{t}, E_{t}^{+})

Sensor Middleware 则负责检测执行是否停滞。它监测两个增量：

Δ {cov}_{t} = C o v (C_{t}) - C o v (C_{t - 1}), Δ {ev}_{t} = | G_{t} | - | G_{t - 1} |

在一个窗口 $w$ 内，如果两者都未增长，则判定为停滞：

s_{t} = 1 [\sum_{j = t - w + 1}^{t} Δ {cov}_{j} = 0 \land \sum_{j = t - w + 1}^{t} Δ {ev}_{j} = 0]

同时，预算压力被定义为迭代次数、搜索次数与运行时间的最大归一化使用率：

ρ_{t} = max {\frac{n_{t}^{iter}}{B^{iter}}, \frac{n_{t}^{search}}{B^{search}}, \frac{τ_{t}}{B^{time}}}

Harness 结合 $s_{t}$ 、 $ρ_{t}$ 与当前缺口决定下一步动作：继续执行、注入纠正、请求回填、进入 drain-only 模式或停止分支。由于这些决策发生在系统层面，同一套安全机制可以跨不同模型、不同角色复用，而不必依赖每个智能体在提示词中“记住”遵守预算。

3.4 分层技能库：从“怎么搜索”到“怎么访问”

SearchOS-V1 包含 280 个预构建技能，分为 orchestrator skills、strategy skills 与 access skills 三层。Orchestrator skills 是全局手册，涵盖任务分解、模式对齐、行集合对齐与综合验证。Strategy skills 是来源无关的方法论，包括查询改写、实体枚举与消歧、结构化抽取、多跳与时序推理、聚合以及停滞恢复。Access skills 则是站点特定的检索与抽取程序，覆盖商业数据库、政府门户、百科全书、公司网站与媒体目录等。每个可执行 access skill 由 skill.md（使用说明）、manifest.yaml（参数模式）与 executor.py（调度与解析）三件组成，例如论文附录中展示的 Senate.gov 技能，将“按州获取现任参议员”封装为带类型的函数调用，隐藏了 URL 构造、HTTP 错误处理与 BeautifulSoup 解析细节。

技能的选择机制也体现了层次化设计：启动时，orchestrator skills 作为共享手册被注入；针对具体任务，系统检索 strategy skills 作为指导，同时把可执行的 access skills 作为类型化工具暴露给 search agent。一个基于查询的 router 会先剪枝 access 技能目录，再进行选择。这种分层让“如何搜索”与“如何访问某个具体网站”解耦：当某个站点改版时，只需更新 access skill；当发现新的搜索模式时，只需更新 strategy skill。

3.5 浏览器接口：共享导航栈

SimpleBrowser 是智能体与网络交互的主要工具。它维护一个共享的导航栈 $B = (P, H, σ)$ ，其中 $P$ 是页面缓存， $H$ 是后进先出的页面历史， $σ$ 是当前视口的滚动位置。浏览器只暴露三个核心操作：search 返回结果页面列表，open 访问指定 URL 或链接 ID，find 在当前页面中按关键词定位匹配片段。栈式设计的优点在于：数字链接 ID 可以通过回溯历史解析到最近包含该链接的页面；导航路径被完整保留，便于后续轨迹分析；find 结果可以锚定到源页面行号，支持高效的页内探索。所有浏览器观察最终都必须经过 Evidence Extraction Middleware 才能成为 Evidence Graph 中的节点，从而确保“访问过页面”不等于“收集到证据”。

实验评估

4.1 实验设计与基准

论文在 WideSearch 与 GISA 两个开放域信息检索基准上评估 SearchOS。WideSearch 包含 200 道人工策划的问题（100 英文、100 中文），覆盖 15 个以上领域，每道题要求智能体收集大量可客观验证的原子事实并组织成完整表格。GISA 包含 373 道人工撰写的查询，反映真实搜索场景，答案格式分为 item、set、list 与 table 四类，便于确定性评分。两个基准都强调深度多跳推理与跨源聚合，对系统的完整性、一致性与可验证性提出了严峻考验。

基线分为单智能体与多智能体两类。单智能体包括 ReAct（Yao et al., 2022）与 Plan-and-Solve（Wang et al., 2023）；多智能体系统包括 A-MapReduce（Chen et al., 2026）、Web2BigTable（Huang et al., 2026）与 Table-as-Search（Lan et al., 2026）。实验配置为：GLM-5 作为各角色智能体的 backbone，Qwen3.5-35B-A3B 负责证据抽取；每个案例运行三次，报告三次中的最佳结果（Max@3），数值已乘以 100；默认限制为每个 session 50 次 orchestrator 迭代、8 个并行子智能体、每个子智能体 20 次搜索、1800 秒墙钟预算。

4.2 主要结果

表 2 汇总了主要结果。SearchOS 在两个基准的六项 headline F1 指标上均取得最佳表现。

基准	指标	ReAct	Plan-and-Solve	Table-as-Search	A-MapReduce	Web2BigTable	Ours	∆
WideSearch	Item·Precision	82.9	83.8	82.4	83.1	78.3	83.9	+0.1
WideSearch	Item·Recall	70.2	72.9	73.5	74.2	73.4	79.7	+5.5
WideSearch	Item·F1	72.9	75.2	75.4	76.0	73.8	80.3	+4.3
WideSearch	Row·Precision	58.0	58.7	57.1	56.9	57.5	59.0	+0.3
WideSearch	Row·Recall	48.8	50.2	51.6	49.8	54.0	55.8	+1.8
WideSearch	Row·F1	50.9	52.2	52.7	51.4	54.5	56.5	+2.0
GISA	Table·Item·F1	74.8	71.2	73.4	72.5	68.1	76.9	+2.1
GISA	Table·Row·F1	58.1	50.7	54.1	52.1	45.3	59.7	+1.6
GISA	Set·F1	61.6	63.1	60.9	62.5	56.7	76.5	+13.4
GISA	List·F1	67.1	53.8	54.2	57.4	65.5	68.1	+1.0
GISA	Item·EM	0.0	16.7	16.7	33.3	50.0	50.0	0.0

在 WideSearch 上，SearchOS 的 Item Precision、Recall、F1 均为最高，其中 Item F1 比最强基线 A-MapReduce 高出 4.3 点。更值得注意的是，增益主要来自 Recall（+5.5），这与 coverage-aware dispatch 的设计目标完全一致：系统通过显式追踪未覆盖单元，减少了遗漏。在更严格的 Row-level 指标上（只有一行所有单元都正确才算正确），SearchOS 同样在 Precision、Recall、F1 上领先，说明其召回优势不仅体现在孤立单元，还能延伸到整行一致性。

在 GISA 上，SearchOS 的领先优势更为夸张。Set F1 达到 76.5，比最强基线 Plan-and-Solve 的 63.1 高出 13.4 点。Set 问题要求完整枚举一个答案集合，这直接受益于 Evidence Graph 的显式收集与 Coverage Map 的完整性检查。Table Item F1 与 Row F1、List F1 也均为最高，Item EM 与 Web2BigTable 持平于 50.0。整体而言，实验结果强有力地证明：把开放域信息检索形式化为关系模式补全，并以共享状态支撑多智能体协作，能够系统性地提升长程搜索的完整性与一致性。

4.3 消融研究：谁在贡献什么

论文通过一系列消融实验进一步定位了各个组件的贡献。首先，关于模式结构，作者在 40 个可分解为多表的问题上比较了固定单表、固定多表与 SearchOS 自主模式规划的效果。

设置	Item Precision	Item Recall	Item F1	Row Precision	Row Recall	Row F1
Fixed Single-Table	54.7	46.7	47.9	33.5	28.2	29.2
Fixed Multi-Table	66.9	55.7	58.3	37.4	32.6	34.2
Oracle Single/Multi	70.3	60.7	62.4	44.8	39.7	41.2
SearchOS	76.3	68.3	70.6	52.7	47.3	48.9

固定多表平均优于固定单表，但在 40 个案例中仅 21 胜、17 负、2 平，说明其优势具有任务依赖性。即使由 Oracle 为每个案例选择更优的固定结构，仍然比 SearchOS 自主规划低 8.2 点 Item F1 与 7.7 点 Row F1。SearchOS 在 40 个案例中为 35 个选择了单表、5 个选择了多表。这一结果说明：模式规划应保留在搜索过程中，根据遇到的实体类型、字段分布、重复模式与关系动态调整，而非在任务开始前固定。

其次，关于流水线并行调度。表 4 展示了在 10 个 WideSearch 案例上连续调度与批调度相比的配对结果。

轮次	Time ∆（↓）	Tokens ∆（↓）	Item F1 ∆（pp）
1	−32.6%	−27.7%	+2.35
2	−32.3%	−31.2%	+15.00
3	−28.6%	−10.8%	+1.85

连续调度在三轮中一致地降低了端到端时间与 token 消耗，并提升了 Item F1。表 5 进一步给出 30 条轨迹上的平均值。

调度策略	Time（s）（↓）	Slot Utilization（↑）	Tasks/min（↑）	LLM Calls（↓）	Item F1（↑）
Batch（Control）	629.13	34.6%	2.99	341.4	79.66
Continuous（Ours）	476.34	41.7%	3.37	296.6	86.75

连续调度平均减少 24.3% 的端到端时间，提高槽位利用率与任务吞吐量，同时减少 LLM 调用次数并获得更高 F1。这表明：在批处理屏障处消除空闲容量，并不会牺牲检索质量，反而通过更快的迭代改善了整体效果。

再次，关于中间件治理。图 5 展示了三个 WideSearch 轨迹——分别在早期、中期、晚期被 Loop Sensor 检测到低进度搜索循环并触发策略切换。在每种情况下，干预都恢复了搜索进展，尽管对覆盖率与实体发现的影响程度不同。这为“传感器能够在不依赖模型自律的情况下重定向停滞搜索”提供了机制级证据。

最后，关于分层技能。表 6 报告了启用与禁用技能的结果。

设置	Item Precision	Item Recall	Item F1	Row Precision	Row Recall	Row F1
Without Skills	82.2	78.5	78.3	56.0	52.4	53.1
With Skills	83.9	79.7	80.3	59.0	55.8	56.5
∆	+1.7	+1.2	+2.0	+3.0	+3.4	+3.4

技能使 Item F1 提高 2.0 点，Row F1 提高 3.4 点。更大的行级增益说明，可复用的分解、搜索与来源访问知识帮助智能体组装出连贯的实体记录，而不仅仅是恢复孤立单元。同时，图 6 显示技能使会话时间减少 36.6%，搜索调用减少 39.1%，页面调用减少 42.7%——质量提升来自更少的试探性错误，而非更多浏览。

4.4 统计稳健性

实验采用 Max@3 报告，并给出了 95% 置信区间（图 6）。虽然 Max@3 会选择三次运行中的最佳结果，可能在某种程度上高估系统性能，但 SearchOS 与基线采用了相同的报告方式，因此相对比较仍然是公平的。更值得注意的是，在几乎所有指标上，SearchOS 的最佳结果不仅高于基线的最佳结果，而且其效率指标（时间、调用次数）也显著优于无技能版本，说明系统的优势并非来自“更努力地搜索”，而是来自“更聪明地搜索”。

案例研究

论文附录 D 提供了三个完整的 WideSearch 轨迹案例，分别展示了并行富化、范围审计与不可访问来源恢复三种典型行为。这些案例比最终分数更能揭示 SearchOS 的工作机制。

5.1 Spotify 2024 排行榜：并行富化

案例 ws_en_022 要求列出 2024 年 Spotify 全球榜与美国榜各前十首歌曲，并补充歌手、语言、词曲作者、制作人、发行日期等元数据。系统最终完成于 362 秒，产生 221 个证据节点，100% 已知单元覆盖率，Item F1 97.5，Row F1 85.0。关键决策在于：orchestrator 首先派遣 explore agent 确认两个权威榜单，然后建立一个以 [Category, Rank] 为复合主键的 20×8 表，最后把 20 首歌曲拆分为四个五歌曲子任务，由四个 search agent 并行填充元数据。这一设计避免了不同子任务独立发现歌曲记录时可能出现的行身份漂移。当所有并行分片完成并合并后，系统仍执行了一次显式行集合审计，确保 20 个预期行全部存在。最后，针对两首歌曲发行日期中不一致的分隔符格式，系统通过 edit_entities 操作进行了修复。这个案例展示了：共享模式先行、并行富化随后、最终审计兜底的工作流程。

5.2 迈克尔·菲尔普斯奖牌：虚假饱和与范围修复

案例 ws_en_016 要求枚举迈克尔·菲尔普斯在奥运会与世界游泳锦标赛个人项目中的奖牌。系统在早期经历了典型的“虚假饱和”：已知单元覆盖率达到 100%，但表只有 16 行，而智能体报告暗示大约有 31 个合格赛事。SearchOS 没有将覆盖率饱和等同于任务完成，而是触发了一次行集合审计，发现缺失的年份与赛事，然后派遣回填 agent。表从 16 行增长到 33 行、再到 35 行。随后，验证阶段发现 2003 年世锦赛 400 米个人混合泳存在两个冲突记录（4:09.09 与 4:11.04），系统通过核对官方来源移除了错误行，并补充了缺失的 2005 年 100 米蝶泳结果，修正了若干 200 米自由泳行的奖牌信息。最终 Item F1 80.1，Row F1 28.2。这一案例的价值在于说明：Coverage Map 控制属性填充，而行集合审计控制召回；两者缺一不可。

5.3 移民相关期刊文章：被屏蔽来源与有界恢复

案例 ws_en_023 要求枚举三家期刊在 2020–2024 年间与迁移相关的文章。orchestrator 首先纠正了一个模糊的期刊名称，然后为每个期刊分配一个 search agent。初始轮次后，系统移除了一篇超范围的 2026 年文章，并为五行不完整记录派遣了元数据任务。然而，Wiley 与 JSTOR 页面反复返回访问检查或 HTTP 402 响应。受影响的 agent 在策略技能指导下转向 Crossref、OpenAlex 与学术论文技能；Loop Sensor 为一个停滞 agent 记录了两次显式策略切换。当剩余来源与单智能体预算耗尽时，系统保留了未解析单元，而不是从不完整推断中捏造元数据。最终返回 57 行，覆盖率 96.3%，Item 与 Row F1 均为 93.8。这一案例说明：恢复机制是有界且证据保留的——系统鼓励来源与工具切换，但资源限制最终会阻止无效搜索，未解析单元保持可见。

将三个案例放在一起，可以得到一个统一图景：exploration 定义可辩护的搜索空间，并行 agent 在共享结构化状态中积累证据，SOCM 暴露具体残差缺口，治理机制根据可观察进度重定向或停止工作。这些正是主实验分数背后的机制来源。

综合价值与局限

6.1 理论意义

SearchOS-V1 的理论贡献在于它重新定义了“长程开放域搜索”的问题边界。此前研究大多集中在如何让单个语言模型更好地搜索与推理；本文则指出，当搜索跨越数十上百次交互时，真正制约可靠性的不是模型能力，而是状态管理。通过把搜索目标形式化为关系模式补全，作者把信息检索从“生成任务”转化为“验证任务”，把进度从“模型自我感觉”转化为“模式覆盖度量”。这一转变不仅提供了新的评估维度，也为未来研究提供了可组合的概念工具：Frontier Task、Evidence Graph、Coverage Map、Failure Memory 可以被单独改进、组合验证，并在不同任务间迁移。

6.2 实践影响

从应用角度看，SearchOS 最适合需要高完整性、可验证性的信息收集场景。例如，学术文献综述、企业竞争情报、尽职调查、政策研究、事实核查等。任何需要把多个来源的事实整合成结构化答案、并能为每个事实提供出处的任务，都可能受益于这种显式状态管理。部署层面，系统需要接入搜索 API、浏览器渲染服务、以及针对关键来源的 access skills；组织内部知识库也可以被封装为 access skill，从而让智能体在私有数据上执行同样的关系化搜索。

6.3 主要优势

论文的强项在于其系统性与工程自觉。首先，它把多个已有想法——关系模式、流水线并行、中间件、分层技能——整合成一个连贯的“搜索操作系统”架构，而不是零散技巧的堆砌。其次，实验设计完整：既有主实验与多个基线比较，也有针对模式结构、调度策略、中间件、技能的消融，还有完整轨迹案例研究。第三，结果不仅关注准确率，也关注效率（时间、token、调用次数），显示出作者对“可部署性”的考虑。最后，写作与附录透明，包括对不可访问来源、虚假饱和等失败情形的诚实展示，增强了研究的可信度。

6.4 局限与风险

然而，该系统也存在不容忽视的局限。第一，模式构建本身是一个关键瓶颈。如果 orchestrator 对请求的理解有误，建立了错误的表、属性或主键，那么后续所有智能体都将围绕一个错误目标工作，最终答案再完整也可能是错的。第二，技能库的建设成本高昂。虽然 280 个预构建技能令人印象深刻，但互联网站点结构不断变化，access skills 需要持续维护；对于长尾来源，系统可能退化为通用浏览器搜索。第三，引用验证并不等同于真理。系统可以确保每个值有来源，但无法保证来源本身可靠；在面对故意误导、过时信息或来源偏见时，Evidence Graph 的置信度机制可能不足以发现问题。第四，预算与停止策略仍有经验性。虽然 50 次 orchestrator 迭代、8 个并行 agent、1800 秒等参数在实验中被证明有效，但不同任务的最优预算可能差异很大，过度预算会浪费资源，不足预算则导致不完整。最后，当前评估集中在英文与中文事实型查询，系统在高度主观、叙事性或需要跨文化解释的任务上的表现尚未验证。

6.5 更广泛的启示

SearchOS 代表了一种范式的转移：从“以智能体为中心”的自主搜索，到“以系统为中心”的状态化搜索。它暗示未来的语言智能体可能更像操作系统中的进程，而系统本身负责内存、调度、文件系统与错误处理。这种视角与 AIOS、MemGPT、AgentFold 等研究相呼应，共同指向“大语言模型作为操作系统核心”的愿景。SearchOS 的特别之处在于，它针对信息检索这一具体场景，把抽象的操作系统隐喻落实为具体的数据结构与调度算法。

延伸阅读与思考

7.1 重要前期工作

SearchOS 直接建立在多条研究线索之上。在单智能体搜索方面，Yao et al. (2022) 的 ReAct 提出了推理与行动交织的范式；Nakano et al. (2021) 的 WebGPT 展示了浏览器辅助问答的潜力；Jin et al. (2025a) 的 Search-R1 与 Wang et al. (2025b) 的 StepSearch 则通过强化学习优化搜索策略。这些工作主要提升模型级能力，而 SearchOS 关注系统级状态。在多智能体系统方面，Wu et al. (2023) 的 AutoGen 提供了对话式协作框架，Hong et al. (2024) 的 MetaGPT 展示了角色化软件开发，Chen et al. (2026) 的 A-MapReduce 与 Huang et al. (2026) 的 Web2BigTable 则将 MapReduce 思想应用于网络搜索。SearchOS 与它们的区别在于把协调状态外化为 SOCM，而不是留在对话或计划文本中。在表格化信息检索方面，Wong et al. (2025) 的 WideSearch、Zhu et al. (2026) 的 GISA 与 Lan et al. (2026) 的 Table-as-Search 都把输出组织为表格，但 SearchOS 进一步引入关系模式、引用矩阵与覆盖度量。

7.2 相关替代方法

对于同一问题，存在不同哲学路径。一条路径是继续强化单智能体：通过更长的上下文窗口、更优的检索策略或后训练，让模型自身记住更多历史。另一条路径是增加反思机制，如 Reflexion（Shinn et al., 2023）或 MemoryBank（Zhong et al., 2024），让智能体主动总结与压缩经验。还有一条路径是“代码即 harness”，如 Ning et al. (2026) 所倡导，用程序直接控制智能体执行。SearchOS 选择了最“重系统”的路径：它不信任任何单一模型记住所有状态，而是把状态持久化、结构化、可投影。这一选择牺牲了一定的灵活性与实现简洁性，但换来了跨模型、跨任务的可复用安全机制。

7.3 未来方向

论文作者已在结论中勾勒出未来方向：扩展到更广领域与多模态场景，提升跨 agent、跨来源、跨任务的适应能力。值得进一步探索的方向包括：自动模式发现——让系统在面对未知请求时，能够从零开始构建或选择最合适的模式；主动冲突消解——不仅标记冲突，还能通过证据权威性、时效性与来源独立性进行裁决；动态预算分配——根据任务难度与中间进展自适应调整搜索预算；以及跨会话 skill 合成——从大量成功轨迹中自动归纳新的 strategy 与 access skills。此外，如何将 SearchOS 的状态化思想与视觉、表格、代码等多模态工具结合，也是一个富有潜力的方向。

7.4 未解决的深层挑战

这一领域最深的未解问题或许是：当信息本身不存在、矛盾或不可获取时，系统应如何表达“不知道”。SearchOS 通过 unreachable 状态与未解析单元保留了这种不确定性，但如何在最终报告中恰当地传达这种不确定性，避免用户过度信任，仍是一个开放问题。另一个深层挑战是来源权威性的评估：系统可以统计引用数量，但难以判断某个来源是否比另一个更权威。此外，随着搜索任务越来越复杂，如何让人类审计与干预数十万 token 的搜索轨迹，也是可解释性与可信性必须面对的难题。

7.5 个人反思

阅读这篇论文时，最令我深思的是它提出的问题本身：我们是否已经过度依赖“更大的模型”来解决本应由系统架构解决的问题？SearchOS 的答案是：至少对于长程信息检索，状态外化与系统级治理比单纯提升模型能力更迫切。它不是否认模型能力的重要性，而是指出模型能力需要一个“操作系统”来放大。把搜索状态从对话中抽离出来，就像把内存从 CPU 中分离出来一样，看似增加了架构复杂度，却为更可靠、更可扩展、更可审计的智能体协作奠定了基础。如果未来的智能体真的成为一种新型操作系统，SearchOS 很可能会被视为早期的重要探索之一。

Topics: