SearchOS-V1: 迈向鲁棒的开放域信息搜寻智能体协作

TL;DR SearchOS 将搜索进度外化为显式的**证据图**、**覆盖图**与**失败记忆**，配合**流水线并行调度**和**搜索中间件**，彻底打破多智能体搜索的死循环，在 WideSearch 和 GISA 上全面领先。

问题

问题背景

Tool-Integrated LLM 驱动的信息搜索代理正在成为主流，Web 搜索是其核心能力。然而，随着交互轮次增加，代理难以跟踪任务进度，多次搜索失败后容易陷入重复循环，浪费搜索预算并损害输出质量。

现有方法局限

目前的单代理和多代理系统在处理开放式信息搜索时，主要面临三个技术局限：

• 隐式进度丢失：搜索状态仅保存在模型内部上下文里，多轮交互后上下文窗口膨胀，代理容易遗忘已尝试的路径和已获取的证据，导致重复查询相同关键词。
• 缺乏结构化任务表示：大多数系统将信息搜索视为线性问答序列，没有显式建模待填充的属性、实体间关系及引用来源，无法系统性地发现覆盖缺口。
• 僵化的调度与容错：当某个搜索步骤未返回有效证据时，代理缺乏感知机制和重试策略，常因空响应或错误页面而卡死，而现有重试往往只是重新运行整个查询，浪费算力和 API 额度。

为什么这个问题难/重要

开放式信息搜索本身复杂度高：查询目标可能是多实体对比、表格填充，且需要每一个数据点都有可追溯的源引用。代理必须同时理解任务模式、动态维护搜索状态、在预算内覆盖所有属性，并处理网页抓取失败、缺失字段等现实噪声。这些挑战使得单纯扩大模型或增加并行搜索数无法根本解决问题。从工程角度看，信息搜索代理的鲁棒性、可观测性和资源效率是企业级应用落地时必须跨越的门槛，业界对这类系统框架的需求非常迫切。

行业类比

类似于智能客服中的多轮对话管理需要状态机来避免遗忘上下文，信息搜索代理同样需要外化且共享的任务状态图，才能实现多代理间的有效协作和可靠输出。

核心洞察

• 将开放域信息查找重构为关系模式补全：传统搜索智能体通常把任务当作线性问答，而 SearchOS 显式建模为发现实体并填充跨表属性的过程，从而将模糊的进度追踪转化为结构化的证据图与覆盖图。这一视角让系统能精确识别哪些属性尚未找到可靠来源，直接指导后续搜索动作，避免了现有单智能体或多智能体系统在长程交互中因目标漂移或重复查询造成的预算浪费。
• 结构化失败记忆驱动避免重复陷阱：SearchOS 不仅在单次任务内构建失败记忆（记录哪些查询路径无效），还将其设计为跨运行的持久化知识，供层次化搜索技能库复用。这与多数仅依赖上下文窗口记忆或简单重试的基线形成鲜明对比，使系统能主动规避已证明低效的搜索模式，显著提升搜索预算利用效率，尤其在对页游屏蔽或信息稀疏场景下效果突出。

方法

输入：关系模式驱动的搜索任务

SearchOS 将开放域信息搜寻形式化为关系模式补全（relational schema completion）。用户查询被解析为一组相互关联的表格模式，每张表包含若干属性（即待填充的信息槽位）。系统需要发现实体、填充属性值，并为每个值提供可溯源的证据（grounded citations）。

关键模块

1. 搜索导向的上下文管理（SOCM）
   SOCM 把传统隐式的搜索进度显式化为四个持久、可共享的状态组件：

   • Frontier Task：当前待处理的搜索子任务队列，持续根据覆盖缺口更新。
   • Evidence Graph：实体-属性-证据的三元组图，锚定每个值到具体来源。
   • Coverage Map：跟踪模式表中各属性的填充状态（如 空 / 部分完成 / 已完成 ），直接映射覆盖缺口。
   • Failure Memory：记录失败的搜索尝试、被屏蔽的页面等，供后续智能体回避冗余操作。 所有状态通过原子更新操作保持一致性，避免冲突。

2. 流水线并行的多智能体编排
   多种子智能体（如搜索者、阅读者、写作者）在流水线中并行工作。调度器持续将空闲槽位分配给 Frontier Task 中未覆盖的属性，实现执行的重叠与吞吐量提升。智能体角色定义清晰，每个角色携带定制的工具集（如浏览器、模式管理工具）。

3. 搜索工具中间件接续层（Middleware Harness）
   该层拦截模型与搜索工具的交互，完成三项核心功能：

   • 上下文中间件：自动注入当前 SOCM 状态，让智能体无需手动追溯历史。
   • 证据抽取中间件：从搜索结果中提取结构化证据，填充 Evidence Graph。
   • 传感器中间件：监控搜索预算，检测停滞（如连续空结果）和预算耗尽，触发重规划或技能切换。

4. 层次化搜索技能
   将可复用的搜索策略封装为技能（Skills），分为两类：

   • 策略技能（strategy skills）：如“分解复杂查询为子问题”“优先查找权威源”。
   • 访问技能（access skills）：如“绕过付费墙”“使用站点搜索语法”。 技能基于 SOCM 状态选择执行，避免跨任务重复失败的搜索模式。

输出

最终输出为含完整引用的信息报告，所有事实均锚定到源证据，覆盖所有模式属性。

与同类方法的差异

与 DeepSearch、STORM 等仅维持隐式对话历史的智能体不同，SearchOS 构建了显式的、结构化的搜索进度状态，并通过中间件与技能系统实现搜索行为的全局调节，从根本上减少了因上下文过长导致的循环与预算浪费。

实验

实验设计

实验在两个开放域信息搜索基准上进行：WideSearch 和 GISA，评估多维度指标（答案正确性、证据覆盖率、搜索效率等）。对比基线包括单智能体系统（如 ReAct、Reflexion 变体）和多智能体编排框架（如 AutoGen、CrewAI 的适配版）。全部实验在统一检索接口与工具集下复现，保证对比公平。消融实验分别考察：

• 固定 Schema 对比搜索时动态 Schema 规划
• 流水线并行调度机制的有效性
• 中间件（Middleware Harness）对搜索进度控制的作用
• 层次化技能系统（策略技能与访问技能）的贡献

关键发现

SearchOS 在 WideSearch 和 GISA 的所有指标上均显著超越单智能体与多智能体基线。具体表现为：

• 通过 SOCM 将搜索进度外化为可共享的显式状态（Frontier Task、Evidence Graph、Coverage Map、Failure Memory），有效解决了长程交互中的进度丢失与重复搜索问题。
• 流水线并行调度 持续填补释放的智能体槽位，利用率与吞吐量大幅提升，相比串行调度在相同搜索预算下获得更多有效证据。
• 中间件层 拦截模型与工具交互，记录有依据的证据并响应停滞，避免了无效循环与预算耗尽。
• 层次技能复用（如特定站点访问、失败模式规避）在不同任务间迁移，进一步降低无效搜索次数。

基线对比深度解读

单智能体基线在复杂、多实体关联查询中容易陷入搜索循环，最终覆盖不全或遗漏关键属性。现有多智能体方案虽通过角色分工缓解部分问题，但仍依赖隐式状态传递，缺乏全局进度感知，常出现“抢占重复回答”或“过早收敛”现象。SearchOS 的核心差异在于系统级的显式共享状态与流水线并行编排。SOCM 让每个智能体拥有对整体进度的清晰视图，中间件在搜索时强制执行证据锚定与预算控制，使多智能体协作从“对话式猜测”转变为“有依据的关系模式填充”。消融实验进一步表明，移除 SOCM 或切换为串行调度都会导致性能显著下降，验证了各组件不可或缺。该框架为鲁棒的信息搜索协作提供了可复现的工程范式。

行业影响

落地场景

SearchOS 的技术核心是将开放域信息搜索建模为关系模式填充与证据图管理，并引入流水线并行调度和中间件治理，直接适用于需要高覆盖度、可溯源网页搜索的任何 AI 产品。典型用例包括：

• 对话式搜索引擎与智能助手：用户提出复杂、多步的信息查询（如“对比主流 GPU 云服务商的定价与特性”），系统需协调多个搜索智能体并行抓取并整合分散在数十个网页中的属性。
• 企业级知识聚合与调研自动化：市场分析、竞品跟踪、金融投研等场景，要求从多个信源中提取结构化数据（如公司财务指标、产品规格表），并严格附上原文引用。

商业价值

SearchOS 直接指向搜索开销与输出质量两大商业变量：

• 降本：通过失败记忆与覆盖度地图避免无效重复搜索，显著减少搜索引擎 API 调用次数，将预算集中在高价值证据上。同时，流水线调度提高了智能体实例的利用率，降低端到端延时与并发资源成本。
• 增收与体验提升：证据图确保每个输出项都可溯源，大幅减少幻觉，增强用户信任；覆盖度地图驱动的调度使答案更全面，缺失属性自动补全，提升用户留存与付费转化。在电商比价助手等场景中，更完整的属性填充直接转化为更高的购买决策效率。

与现有产品/工作流的接口

SearchOS 定位为系统级框架，可作为中间件嵌入现有 LLM 应用栈：

• 集成方式：通过标准化的 Search Tool Middleware Harness 接管模型与工具的交互，可包装为 LangChain / LlamaIndex 的 Tool 或 AgentExecutor 替换件。
• 技能系统：提供策略技能和访问技能的分层定义，允许团队以插件形式扩展垂直领域的搜索模式（如特定网站的认证爬取、结构化数据抽取规则），无需改动框架主体。
• 状态服务：SOCM 组件（Frontier Task、Evidence Graph、Coverage Map）可作为独立的状态服务向外提供 API，与现有的向量数据库、搜索结果缓存等基础设施同步。

落地用例

1. 电商会话式比价：用户描述需求后，系统自动拆解为品类实体、型号、价格、评分等属性，同时派出多个子智能体爬取不同商家页面。覆盖度地图实时检测哪些属性尚有缺失，调度空闲智能体补充搜索，最终输出结构化对比表，每项数字均附来源链接，避免幻觉和低质推荐。
2. 金融投研信息聚合：分析师输入“汇总某公司的近三年营收、CEO 变动、最新融资轮次”。系统将公司作为实体，填充多张关联表（财务表、高管表、新闻表），并行搜索财报 PDF、新闻稿、工商数据库。遇到付费墙或反爬时，失败记忆记录原因并触发替代源，保证在有限预算内获得最高完整度。

启示：SearchOS 强调将隐式搜索进度显式化为共享状态，这对所有长流程 AI Agent 的工程实现具有参考价值——观测性、可恢复性与并行效率是生产级系统落地的关键。

局限

• **关系模式依赖与构建成本**。SearchOS 将开放域搜索形式化为关系模式补全，其性能高度依赖模式设计的质量。当领域知识欠缺或查询模糊时，自动规划的模式可能遗漏关键属性或引入无关关系，导致搜索方向偏差和覆盖缺口。消融实验显示搜索时模式规划仍存在优化空间，在实际工程中往往需要额外的模式校验或人工修正机制，这增加了系统构建的冷启动成本。
• **系统复杂性与资源开销**。框架包含多个子智能体、中间件和状态管理模块，流水线调度虽然提高了吞吐，但协调开销和延迟不容忽视。每次搜索动作都可能触发证据抽取、状态同步和任务重分配，导致大量 LLM 推理和搜索 API 调用。论文未详细报告端到端延迟与成本，这对延迟敏感或预算受限的场景构成挑战。与轻量级单智能体 ReAct 方案相比，部署运维的复杂度显著更高。
• **评估范围与泛化性**。实验集中在 WideSearch 和 GISA 两个多跳问答基准，任务多为实体属性补全，未覆盖更复杂的推理类型（如对比、总结）或非结构化信息需求。缺乏在跨领域问答（如 WebSRC、ASQA）或交互式搜索场景下的验证，泛化能力有待论证。此外，系统目前面向全自动智能体协作，缺少像 OpenAgents 那样的人机协同纠错机制，在面对非常规失败时弹性不足。