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

将长程搜索状态外化为系统级共享状态，多智能体在两大基准全F1指标领先

前置知识

工具集成大语言模型智能体（Tool-Integrated LLM Agent）

指能够调用外部工具（如网页搜索、浏览器、计算器）并基于工具返回结果迭代推理的大语言模型智能体。典型代表如ReAct（推理-行动交替）、Plan-and-Solve（先规划后执行）。它们把搜索、浏览、推理、证据收集和综合交织在一起，使模型能力突破其参数内知识。但状态通常以会话历史形式存在，随轮次增长会丢失对任务进度的追踪。

本文的研究对象正是这类智能体在长程、开放域检索任务上的失败模式，理解其工作范式才能理解SearchOS为什么要把状态从会话中外化出来。

关系模式与数据库范式化（Relational Schema & Normalization）

关系数据库用主键（primary key）唯一标识实体，用外键（foreign key）表达跨表关系，用规范化（normalization，Codd 1970）消除冗余和不一致。一张表 $T_m=\langle A_m, P_m\rangle$ 定义属性集 $A_m$ 与主键属性 $P_m$。本文把信息检索形式化为对这种关系模式的补全：发现实体行 $E_m$、填充值矩阵 $Y_m$、并维护与 $Y_m$ 同形状的引用矩阵 $C_m$，每个值都锚定到源URL与原文片段。

本文核心创新之一就是把开放域检索重写为'带锚定引用的关系模式补全'，读者必须懂关系模式才能理解任务定义、覆盖率公式与可验证性。

流水线并行（Pipeline Parallelism）

源于GPU训练（Huang et al., 2019, GPipe；Narayanan et al., 2019, PipeDream）：把模型或任务切分到不同stage，让不同stage同时处理不同micro-batch，从而重叠执行、减少straggler导致的空闲。核心收益是提高设备利用率与吞吐。本文把这一思想迁移到角色级工作调度：不同子任务并发推进，每释放一个agent槽位就立刻回填一个未解决的模式缺口。

SearchOS的'连续调度'公式 $D_t=\mathrm{Top}_{\min(b_t,|R_t|)}(R_t;p)$ 直接借鉴流水线并行思想，是消融实验中吞吐与时间降低24.3%的关键。

中间件与Agent Harness（Middleware & Agent Harness）

软件工程中，中间件是位于应用与底层之间的拦截层，统一处理横切关注点（日志、鉴权、限流）。在LLM Agent语境下，Harness指管控执行、工具、上下文、状态、生命周期与可观测性的基础设施层。SearchOS提出'搜索工具中间件Harness'，在模型调用前后与工具调用后拦截交互，分别完成上下文准备、证据落地加锚、停滞/预算检测，把安全保障从提示词移到系统层。

本文反复强调'系统级而非提示级'，理解中间件/Harness概念才能理解为什么这些保障对异构后训练模型普遍有效。

覆盖驱动的多智能体协作（Coverage-Driven Multi-Agent Collaboration）

把任务进度量化为对模式单元格 $c=(m,e,a)$ 的覆盖率 $\mathrm{Cov}(C_t)$，并据此决定下一步调度哪个未解决缺口。orchestrator建模式并优先级化缺口，explore找候选与源，search收集带引用证据，writer合成报告。各角色通过共享状态（而非点对点消息）协调，每个agent只看角色专属投影。

这是SearchOS相对ReAct/A-MapReduce等会话式协作的本质差异，覆盖率成为可优化目标也是Recall提升+5.5的直接来源。

研究动机

现有工具集成大语言模型驱动的信息检索智能体在处理长程、开放域任务时存在系统性失败。当交互历史不断增长，智能体逐渐丢失对任务进度的追踪，证据被埋没在冗长上下文中，遗漏、重复采集和相互冲突的论断难以被发现；当某条搜索路径无法产出有用信息时，单智能体系统（如ReAct、Plan-and-Solve）会反复发起相似查询或持续探索同一条死胡同，浪费搜索预算并降低最终答案质量。更关键的是，简单增加智能体数量并不能消除这些问题：并行工作者可能重复劳动、在意图字段上产生分歧，或在等待最慢任务时让执行槽位空闲。这些失败的根源在于传统智能体把计划、进度、证据和失败都视为会话中的临时内容，而非系统持久维护的状态，因此无法跨agent共享、无法量化进度、也无法在停滞时被系统主动纠正。

本文的目标是本文的目标是为开放域信息检索构建一个结构化、可观察、可靠的多智能体框架SearchOS。具体目标包括：第一，将信息检索形式化为带锚定引用的关系模式补全，使开放式请求变成具体且可测量的搜索目标；第二，把搜索进度、证据、覆盖率和失败信息外化为系统级共享状态（而非藏在会话历史中），让所有智能体围绕显式覆盖缺口协调；第三，引入流水线并行调度，避免同步批次带来的空闲时间，提升搜索吞吐；第四，设计系统级中间件Harness，在不依赖提示词约束的情况下统一管控证据处理、上下文管理、预算执行和行为干预，使同一套保障对异构后训练模型普遍生效；第五，提供跨会话可复用的层次化搜索技能库（280个预构建技能）。

与已有工作不同的是，本文的独特切入角度是'系统级而非提示级'。与以往把搜索状态留在会话、计划或通用任务账本中的方法（A-MapReduce、Web2BigTable、Table-as-Search）不同，SearchOS把中间搜索产物（覆盖缺口、带溯源的证据、覆盖率、失败记录）从交互历史中抽出，作为四个独立的持久记忆（Frontier Task、Evidence Graph、Coverage Map、Failure Memory）由系统维护，并用加锁的read-modify-write保证一致性。作者进一步借鉴GPU流水线并行的训练效率优势，将其迁移到角色级工作调度；并借鉴软件工程中间件思想，用Harness接管通常依赖提示词的安全保障。这种'搜索操作系统'式的基础设施思路在多智能体检索领域是首次系统化提出，把'长程信息检索'从agent问题重新框定为系统问题。

核心方法

SearchOS的整体思路是'把脆弱的、隐式的搜索进度转化为显式、持久、共享的状态'。直觉上，长程搜索的关键信息（哪些实体/属性已覆盖、每个值的来源、哪些任务待办、哪些路径已失败）不应让智能体反复从对话历史中推断，而应由系统像维护数据库一样维护。技术路线上，SearchOS被实现为一个状态化的闭环：调度器把未解决的搜索缺口通过SOCM分发给专职智能体，观测结果通过中间件落地、加锚、提交到SOCM，闭环完成后由writer合成带细粒度引用的最终报告。配置上主智能体用GLM-5、证据抽取用Qwen3.5-35B-A3B；每会话上限为50次编排器迭代、8并行子智能体、每子智能体20次搜索、1800秒墙钟预算，每个case取Max@3并×100缩放。整个系统由四大模块构成：SOCM（状态管理）、流水线并行编排、搜索工具中间件Harness、层次化技能库。

核心创新是把开放域信息检索形式化为'带锚定引用的关系模式补全'。给定请求 $q$，系统构建关系搜索模式 $S=\{T_m\}_{m=1}^M$，每张表 $T_m=\langle A_m,P_m\rangle$ 定义属性集 $A_m$ 与主键 $P_m$，$R$ 为表间外键；输出 $O=\{E_m,Y_m,C_m\}_{m=1}^M$ 含实体集 $E_m$、值矩阵 $Y_m$ 和同形状引用矩阵 $C_m$（每个值锚定到源URL与原文片段）。与已有方法本质区别有三：第一，关系模式把开放式请求变成可量化进度的目标，覆盖率 $\mathrm{Cov}(C_t)=\frac{\sum_{c\in\Omega_t}1[s(c)=\text{FILLED}]}{|\Omega_t|+\sum_{m:|E_m(t)|=0}|A_m|}$ 让'还差多少'可计算；第二，每个事实值通过引用矩阵独立可验证，事实核查下沉到单元格粒度；第三，状态外化使角色可解耦（orchestrator建模式、explore找源、search采证、writer合成），各角色只看专属投影 $x^{(r)}_t=\phi_r(M_t;z_t)$ 避免上下文陈旧。

方法步骤详情

方法分四层。步骤一（SOCM状态管理）：维护 $M_t=\langle F_t,G_t,C_t,W_t\rangle$。Frontier Task $F_t$ 是依赖感知任务池，任务 $f_j=(\kappa_j,s_j,p_j,B_j,Z_j,a_j,n_j)$ 含类型/状态/优先级/依赖/目标单元格/分配/尝试数，就绪集 $R_t=\{f_j\mid s_j=\text{PENDING}\wedge B_j\subseteq T_t\}$。Evidence Graph $G_t=(N_t,L_t)$ 存原子发现而非页面摘要，节点 $g_i=(v_i,u_i,x_i,b_i,\gamma_i,\tau_i,s_i)$ 记录值/源/片段/绑定/置信度/溯源层级/状态，关系 $R_E=\{\text{SUPPORT},\text{CONFLICT},\text{REFINE}\}$。Coverage Map 为单元格 $c=(m,e,a)$ 记录状态/支撑集/冲突标记，多发现共存按 $g^*_c=\arg\max_{g\in H_c}\langle\tau,\alpha,\gamma\rangle$ 选最优。Failure Memory $W_t=\{w_k\}$ 存失败类型/签名/纠正建议/复发数。步骤二（流水线并行编排）：orchestrator-worker架构，时刻 $t$ 调度 $D_t=\mathrm{Top}_{\min(b_t,|R_t|)}(R_t;p)$，每完成一任务即更新SOCM、重算 $R_t$、回填释放槽位。步骤三（中间件Harness）：三分量执行流 $e^{(r)}_t=H_{\text{ctx}}(h_t,M_t)$、$M_{t+1}=H_{\text{evidence}}(o_t,M_t)$、$a_{t+1}=H_{\text{sensor}}(M_t,M_{t+1},\xi_t)$；Context投影状态并检索技能，Evidence抽候选 $E^+_t=\{z\mid \text{Bind}(z,S)=1\wedge\text{Anchor}(z,o_t)=1\}$（要求模式绑定+片段锚定），Sensor算停滞 $s_t$ 与预算压力 $\rho_t=\max(\frac{n^t_{\text{iter}}}{B_{\text{iter}}},\frac{n^t_{\text{search}}}{B_{\text{search}}},\frac{\tau^t}{B_{\text{time}}})$ 决定继续/纠正/回填/终止。步骤四（层次化技能）：280个预构建技能分orchestrator/strategy/access三类，启动注入orchestrator技能，每任务按查询路由检索strategy与access技能，可执行access技能成为typed tool。

技术新颖性

技术新颖性体现在五层。第一，关系模式形式化为该领域提供统一可验证目标，把实体发现、属性补全、证据归因纳入同一目标函数，并使覆盖率 $\mathrm{Cov}$ 成为可量化进度信号——这是Table-as-Search/Web2BigTable等表格补全视角未显式建模的。第二，SOCM把搜索状态彻底外化到会话之外，用加锁read-modify-write更新，配合角色专属投影避免上下文陈旧；这种'搜索操作系统'式记忆在多智能体检索领域是首次系统化提出，覆盖了既有记忆/反思工作未覆盖的任务依赖、观测冲突、溯源层级与失败记录四类信息。第三，流水线并行调度首次把GPU训练中的流水线效率优势迁移到角色级工作流，通过事件驱动回填把slot利用率从34.6%提升到41.7%、端到端时间降低24.3%。第四，搜索工具中间件Harness把安全保障从提示词移到系统层，使同一套管控对异构后训练模型普遍生效——这是对'提示工程不可靠'问题的工程化回应。第五，层次化技能（strategy vs access解耦）让'如何搜'与'如何到达某站点'解耦，并能从失败轨迹中学习精炼，使技能可跨会话复用。

**Figure 3**: Illustration of middleware interventions in the Search Agent loop

**Figure 4**: Pre-built skills: (a) weighted keyword frequency; (b) access-skill counts and mean functions by domain

实验结果

核心发现在两项基准全面领先。WideSearch（200题）：SearchOS取得Item Precision 83.9、Recall 79.7、F1 80.3，相对最强基线A-MapReduce（F1 76.0）+4.3，增益集中在Recall（+5.5）符合覆盖感知调度目标，Precision仍为所有方法最高；更严的Row级Row F1 56.5领先次优Web2BigTable（54.5）+2.0，Recall优势延伸到整行一致性。GISA（373题）：所有题型F1均领先，最大增益在Set题型（76.5 vs 次优63.1，+13.4），Table Item F1 76.9、Table Row F1 59.7、List F1 68.1均最高，Item EM 50.0并列最佳。消融：（1）固定模式vs自主规划（40例）：自主Item F1 70.6 vs Oracle 62.4（+8.2），证明模式规划应留在搜索过程中；（2）流水线调度（30轨迹）：连续调度时间降24.3%（629.13s→476.34s），slot利用率34.6%→41.7%，吞吐2.99→3.37 tasks/min，LLM调用341.4→296.6，Item F1 79.66→86.75；（3）技能消融（100题Max@3）：Item F1 78.3→80.3、Row F1 53.1→56.5（+3.4），同时session时间-36.6%、search调用-39.1%、page调用-42.7%。Figure 5的早/中/晚停滞干预轨迹机制级证明Loop Sensor能将停滞搜索重新导向有效工作。

**Table 2**: Main results on WideSearch and GISA

**Table 3**: Relational Schema Completion analysis (Fixed schemas vs SearchOS planning)

**Table 4**: Round-wise scheduling results (median across 10 cases)

**Table 5**: Pipeline scheduling ablation on WideSearch (mean across 30 trajectories per policy)

**Table 6**: Skill ablation results (Max@3)

**Figure 5**: Middleware-governance trajectories on WideSearch

**Figure 6**: Efficiency with and without skills on the same 100 WideSearch questions

查看结构化数据

任务	指标	本文	基线	提升
WideSearch 大规模信息收集（Item级）	Item F1（×100，Max@3）	80.3	A-MapReduce 76.0	+4.3（Recall 79.7 vs 74.2，+5.5）
WideSearch 整行一致性（Row级）	Row F1（×100，Max@3）	56.5	Web2BigTable 54.5	+2.0
GISA 集合枚举类问题	Set F1（×100，Max@3）	76.5	Plan-and-Solve 63.1	+13.4（全题型最大增益）
GISA 表格类问题	Table Item F1 / Table Row F1	76.9 / 59.7	ReAct 74.8 / 58.1	+2.1 / +1.6
流水线并行调度消融（WideSearch 30轨迹）	端到端时间 / slot利用率 / Item F1	476.34s / 41.7% / 86.75	Batch 629.13s / 34.6% / 79.66	时间-24.3%，利用率+7.1pp，F1+7.09
技能消融（WideSearch 100题）	Row F1 / session时间 / page调用	56.5（带技能）	53.1（无技能）	Row F1 +3.4，时间-36.6%，page调用-42.7%
自主模式规划 vs Oracle固定模式（40例）	Item F1 / Row F1	70.6 / 48.9（SearchOS动态选表）	62.4 / 41.2（Oracle取更好固定模式）	+8.2 / +7.7

局限与改进

作者明确指出SearchOS-V1聚焦于'外化搜索状态、为中间搜索产物提供系统级基础设施'，而大规模搜索智能体技能合成（从数据源、搜索轨迹、用户意图自动构造技能）留待后续工作——这意味着当前280个预构建技能仍依赖人工编写，迁移到新领域需额外工程。从实验设置看，所有结果均采用Max@3（每case跑3次取最优）并×100缩放，这一报告口径明显优于单次运行口径，可能高估真实部署稳定性；作者未报告均值或方差，难以判断运行间波动。GISA的Item EM仅50.0（与最强基线Web2BigTable并列），表明在要求整表精确匹配的硬指标上SearchOS并未取得突破。配置上每case允许50次编排迭代、8并行子智能体、1800秒墙钟预算，相对各基线是否使用同等预算作者未完全对齐说明，公平性存疑。主智能体用GLM-5、证据抽取用Qwen3.5-35B-A3B，方法对其他模型族的泛化未验证。从我的观察看，关系模式补全假设可能不天然适合所有开放式问题（如纯叙述性、无结构化表格输出的任务），Schema规划选错表结构导致系统性偏差的失败模式未被分析。

独立分析的弱点

弱点一：技能库构建成本高且领域绑定。280个预构建技能跨商业/政府/组织/教育/通用API等域（Figure 4b显示commercial 138、government 36、organization 33个等），但access技能需为每个站点单独编写typed executor（如Senate.gov），迁移到金融/医学/法律等新域需重写大量技能；改进方向是把Skill Builder扩展为可自动扩展的流水线。弱点二：Max@3报告口径掩盖运行间方差，三次取最优在生产部署中不可复现，建议补充均值±标准差或Min/Median并公开随机种子与轨迹。弱点三：复杂中间件带来工程债。Context/Evidence/Sensor三层中间件、SOCM四记忆的加锁read-modify-write在分布式或更高并发下可能成为瓶颈，文中只测到8并行子智能体未给scale-out曲线；改进方向是引入异步事务或CRDT式合并并补scaling law。弱点四：硬指标EM未突破。GISA Item EM仅50.0，在要求精确全集匹配任务上仍有上限，可结合自一致性投票或事后校验pass。弱点五：对GLM-5/Qwen3.5强依赖，中间件部分依赖模型遵循工具调用规范，对弱模型鲁棒性未验证，建议补做跨模型族（GPT/Claude/Llama）迁移实验。

未来方向

作者明确两条未来工作：其一，将大规模搜索智能体技能合成从数据源、搜索轨迹和用户意图中自动化（把Skill Builder从论文概念框做成完整流水线，目前标注'Stay tuned'）；其二，把SearchOS扩展到更广领域和多模态设置，改进跨智能体/源/任务适应性。基于本成果可延伸的方向包括：第一，把SOCM状态外化思想迁移到非检索型长程任务（代码仓库级Agent、科学实验自动化、多轮对话记忆），Evidence Graph与Failure Memory有较强通用性；第二，把流水线并行调度公式 $D_t=\mathrm{Top}_{\min(b_t,|R_t|)}(R_t;p)$ 推广到任意DAG化Agent工作流量化straggler收益；第三，把Sensor的预算压力 $\rho_t$ 与停滞检测 $s_t$ 作为RL信号训练自适应早停/换策略；第四，将关系模式补全与RAG结合作为企业知识库增量填充引擎；第五，把引用矩阵 $C_m$ 细粒度溯源用于事实核查与可验证AI；第六，把角色分工推广到更多专业角色（如fact-checker、conflict-resolver）。

复现评估

复现评估中等偏上。作者提供了项目主页（https://antins-labs.github.io/SearchOS）、代码仓库（https://github.com/antins-labs/SearchOS）与YouTube演示，这是正面信号。论文给出较完整的实验配置：主智能体GLM-5、证据抽取Qwen3.5-35B-A3B、Max@3、×100缩放、50次编排迭代/8并行子智能体/每子智能体20次搜索/1800秒墙钟上限，附录C给出浏览器接口（search/open/find）完整签名。基准WideSearch与GISA均为公开数据集。但存在明显缺口：未公开随机种子、未给出运行间方差（仅Max@3）、未公开280个技能的具体内容与构造方式、未公开GLM-5的提示词与中间件实现细节、未说明与各基线是否在同等预算下对比。算力层面，1800秒/case×3次×数百题的规模对中小团队不友好，且依赖商用闭源模型GLM-5与Qwen3.5-35B-A3B，第三方难以精确复现。综合判断：框架思想、公式与消融结论可被复用并部分复现，但端到端数值复现难度较大。

SearchOS-V1：面向鲁棒开放域信息检索的多智能体协作系统 SearchOS-V1: Towards Robust Open-Domain Information-Seeking Agent Collaboration