type
status
date
slug
summary
tags
category
icon
password
原始链接
- 论文 PDF：arXiv PDF
- 开源仓库：antins-labs/SearchOS
- 项目说明与演示：SearchOS README
- 论文聚合页：Hugging Face Papers
为什么今天选它
今天比较了四个新对象：把检索进度做成共享状态的 SearchOS-V1、让人直接改 GUI Agent 计划的 Plover、用证据门控代码 Agent 生命周期的 Proof-or-Stop，以及测试 MCP 工具变化适应力的 MCPEvol-Bench。
Proof-or-Stop 和 MCPEvol-Bench 分别接近最近已经写过的 loop 与评测主题。Plover 的人机纠偏很新，但当前依据主要是 6 人形成性研究和失败案例修复。SearchOS-V1 在 2026 年 7 月 16 日提交，论文、代码、界面和消融实验都已公开。它处理的也是一个很实际的麻烦：搜索 Agent 往往不是不会搜，而是不知道已经找到了什么、还缺什么、哪条路刚刚失败过。
这次选择它，不是因为“Agent 操作系统”这个名字，而是因为它把搜索进度从对话记录里拿出来，变成能检查、能保存、能调度的共享状态。这个改动能直接影响完整性、并行效率、引用质量和失败恢复。论文摘要与提交记录
它想解决的事：长搜索为什么越跑越乱
一般的搜索 Agent 把计划、网页片段、工具结果和阶段总结都塞进上下文。任务一长，几个问题会一起出现：
- 已经确认的事实埋在旧消息里，压缩上下文后可能丢失。
- 多个子 Agent 搜同一实体，花了钱却没有增加覆盖。
- 某条路径失效后，换个说法又搜一遍。
- 并行任务按批次等待，快任务做完后，空出来的位置仍在等最慢的那个。
- 最终报告看起来完整，但很难回答“究竟还缺哪些格子”。
SearchOS 的判断很直接：搜索状态应由系统保存，不能指望模型每轮从聊天记录里重新猜。它先把开放问题整理成“实体 × 属性”的关系表，再围绕空缺单元格派活。每个值都要带来源和原文片段，无法确认的地方保留为空。论文第 1-5 页
核心思想：把“研究问题”改写成可核对的表
假设问题是“列出某领域 20 家公司，并给出创始人、融资额和最近产品”。普通 Agent 会边搜边写段落。SearchOS 会先定义实体和字段，再建立表间关系。公司是一张表，创始人可能是另一张表，两者用标识关联。搜索目标因此从“写一篇像样的文章”变成几个明确动作：
- 找出应当存在的实体行。
- 填充每行的属性。
- 给每个值绑定来源网址和可定位的原文。
- 标记冲突、缺失和无法访问的内容。
- 在写作前检查字段覆盖与实体范围。
这不是把结果简单做成表格。表结构同时承担计划、进度尺和验收清单。哪个格子为空，下一步就搜哪个；两条来源冲突，系统保留两条证据，不直接覆盖；新增实体后，待完成的范围也随之扩大。论文问题定义与 Coverage Map
论文把这个过程称为带引用的关系模式补全。关系数据库、表格检索和 schema-first research 都不是新概念。SearchOS 有价值的地方，是把它们接进 Agent loop，让表结构持续影响派活、停机和写作，而不是只规定最终输出格式。
系统怎么跑
一次任务分成六步。项目框架说明
- Explore：侦察 Agent 先判断问题类型，找权威入口页和候选实体，不急着填全部字段。
- Schema：主调度者根据侦察结果建表，确定主键、属性和表间关系。
- Dispatch：把空缺拆成独立任务，按优先级和依赖关系交给多个搜索 Agent。
- Extract：每次打开网页后，系统自动提取实体、属性、值、来源、原文片段和置信信息。
- Assess：完成一个任务就更新共享状态；新增实体进入表，坏来源进入失败记录，冲突另派核查。
- Synthesize：覆盖检查通过后，写作 Agent 只从共享证据中组织报告，并给出逐项引用。
这里最值得借鉴的不是角色数量，而是写权限的划分。搜索 Agent 负责找页面，却不能随意改全局状态；调度者能建表和派任务；写作 Agent 只读证据和覆盖情况。网页结果进入系统时，由统一的证据处理层写入。这样做减少了“每个 Agent 都用自己的口径记笔记”的漂移。
四份共享状态，比一大段记忆更有用
SearchOS 把搜索状态拆成四部分，合称 SOCM。
Frontier Task 是待办池。每项任务有优先级、依赖、目标格子、当前执行者和重试次数。系统会在派发前重新检查目标格子，避免一个子任务已经填完，另一个仍重复工作。
Evidence Graph 保存原子事实。节点不是整页摘要，而是“某个值来自某页哪段文字，并对应哪张表的哪个格子”。支持、冲突和修正关系都留下，旧证据即使被淘汰也不直接消失，便于回放。
Coverage Map 标记每个格子是缺失、已填、不确定还是不可达。它让“还差什么”变成可计算状态。这里有一个容易误读的边界：开放集合里，覆盖率只衡量已知行，不代表实体已经找全。论文的 Spotify 案例即使显示 100%，仍会再做一次行范围审计。论文案例研究
Failure Memory 记录无效查询、打不开的网站、失效技能、被放弃的分支和被拒绝的证据。相似失败再次出现时，“不要再试”会变得更强。它记的不是泛泛经验，而是可匹配的失败签名与替代建议。论文第 5-6 页
四份状态通过同一套锁定更新方式写入。证据图和覆盖表一起改，任务与失败记录也基于同一版本。这个细节不抢眼，却很要紧。否则一个 Agent 可能看到“证据已出现”，另一个仍看到“格子为空”，并行反而制造更多重复。
Harness 做了什么：模型可以犯错，流程不能装作没看见
SearchOS 在模型和工具之间放了三层控制。论文第 7-8 页
上下文层在每次模型调用前，根据角色取出当前任务、相关证据、空缺和失败记录。历史过长时可以裁掉旧对话，但当前约束和共享状态保留。
证据层在每次浏览工具返回后运行。候选事实必须能绑定到表格字段，也必须在网页原文中找到支撑片段，之后才写入证据图并点亮覆盖格子。访问过网页不等于拿到了证据。
传感层看两个量：覆盖有没有增长，证据节点有没有增加。如果连续一段时间都不变，系统判断这条路径停滞，再选择提醒、换策略、补搜、只收尾或停止分支。时间、搜索次数和迭代次数也有硬上限。
这套做法比在提示词里写“不要重复搜索”可靠。提示词只是请求模型自律；中间控制层能看到每次工具调用，并且有权改路或停机。不过它也没有魔法。证据抽取本身仍由模型完成，字段绑定错了、原文理解错了，系统可能把一个错误值保存得很整齐。
并行调度：空出一个位置，就立即补一项缺口
很多多 Agent 系统按批次运行：一次派 8 个任务，等 8 个都结束，再派下一批。只要有一个任务特别慢，其余 7 个位置就会闲着。SearchOS 改成持续派发。任何子任务完成，系统立刻根据最新覆盖表，把空位交给下一个可执行缺口。
论文在 10 个 WideSearch 问题上做了 3 轮成对比较，共计每种策略 30 条轨迹。持续派发的平均耗时从 629.13 秒降到 476.34 秒，位置利用率从 34.6% 升到 41.7%，每分钟完成任务从 2.99 增至 3.37，模型调用从 341.4 次降到 296.6 次；Item F1 从 79.66 升到 86.75。论文 Table 4-5
效率提升的方向可信，原因也容易解释。但 F1 同时大幅上升不应全归功于调度。搜索带随机性，样本只有 10 个问题，论文也没有给这个差异的显著性检验。更稳妥的结论是：持续派发明显减少等待；它对答案质量的增益还需要更大规模复验。
Skills：把“怎么搜”和“怎么进站”分开
论文版本有 280 个预置技能，分三层：
- 编排技能负责拆题、表结构和最终检查。
- 策略技能处理改写查询、列举实体、消歧、多跳查找、时间推理和卡住后的换路。
- 访问技能封装特定网站的入口、参数、解析和格式归一，有些直接带可执行程序。
运行时不会把全部技能塞进上下文。系统先按任务和网址筛选，再给一个搜索 Agent 最多 3 个技能。论文把所有技能层一起关闭做比较：Item F1 提高 2.0 分，Row F1 提高 3.4 分；100 个 WideSearch 问题上，单任务时间下降 36.6%，搜索调用下降 39.1%，打开网页次数下降 42.7%。论文技能消融
这些数字说明预置经验减少了试错，但不能告诉我们哪一层贡献最大，因为三层是一起关闭的。访问技能也会老化。网站一改版，曾经稳定的程序就可能返回空数据或错字段。技能库越大，维护、隔离和安全审查越像长期成本，而不是一次性资产。
实验结果怎么读
主实验使用 GLM-5 承担各个 Agent 角色，用 Qwen3.5-35B-A3B 抽取证据。每个问题运行 3 次，报告最好的一次，也就是 Max@3。会话上限是 50 次调度迭代、8 个并行子 Agent、每个子 Agent 20 次搜索和 1800 秒。论文实验设置
在 WideSearch 上，SearchOS 的 Item F1 为 80.3，比最强对照高 4.3 分；提升主要来自召回率。更严格的整行 F1 是 56.5，只领先 2.0 分。在 GISA 上，集合题 F1 为 76.5，比最强对照高 13.4 分；表格整行 F1 为 59.7，领先 1.6 分。论文主结果 Table 2
结果和设计目标吻合：覆盖驱动最擅长减少遗漏，尤其适合“尽量列全”的问题。整行指标的领先幅度小得多，说明字段之间的一致性仍是难点。Max@3 也比平均表现乐观；真实产品通常只有一次机会，后续更需要报告首轮成功率、平均成本和尾部耗时。
动态表结构的消融用了 40 个特意挑选、可拆成多表的问题。SearchOS 比“每题挑较优固定表”的理想对照仍高 8.2 个 Item F1，但它最后给 35 题选了单表，只给 5 题选多表。这说明价值不在“表越多越先进”，而在先侦察信息形状，再决定是否拆表。论文 Table 3
真正新的地方，哪些只是工程包装
关系表、主从 Agent、共享任务池、并行搜索、来源引用和技能库都有前例。把系统叫 OS 主要是产品类比，不是新的计算模型。论文也把自己的工作放在 Table-as-Search、A-MapReduce、Web2BigTable 以及通用多 Agent 编排之后来比较。论文相关工作
真正推进了一步的有三点。
第一，表结构不只约束输出，还持续驱动整个执行过程。空格子决定下一项工作，冲突决定核查任务，覆盖和范围审计共同决定是否停止。
第二，证据收集从 Agent 的自觉行为变成工具调用后的默认动作。模型可以忘记整理引用，中间层仍会尝试把页面内容绑定到字段和原文。
第三，多 Agent 的协作媒介不是互相聊天，而是同一份可更新状态。任务、证据、覆盖和失败记录分开保存，每个角色只看到自己需要的投影。这比让一群 Agent 互发长消息更容易审计。
其余部分更像扎实的工程组合：LangGraph 编排、角色分工、浏览器三件套、站点适配程序、终端界面和网页界面。它们让方法能用起来，但不该和研究贡献混为一谈。
对产品和研发的启发
先定义“还缺什么”，再让 Agent 干活。任何长任务都可以做一份外部完成表：要交付哪些对象、字段、证据和验收条件。模型负责判断，系统负责记账。
把字段覆盖和范围完整分开。已知 16 行全部填满，可能仍漏了另外 19 行。搜索、盘点、合规检查和竞品列表都需要第二道“集合是否完整”的审计。
集中写证据。业务 Agent 不应一边执行一边用各自格式改全局记录。统一入口负责原文定位、字段绑定、去重、冲突保留和版本更新，后续复查才有抓手。
并行调度看事件，不看批次。任务时长不均时，谁先结束就立刻补下一项独立工作。前提是依赖关系、写入冲突和预算都在系统层可见。
技能要按层维护。搜索策略和网站访问不是一回事。前者可以跨来源复用，后者需要监控改版、权限、速率限制和数据口径。两类技能用同一套生命周期管理，迟早会失控。
保留中途的人类纠偏入口。项目界面允许用户在运行中补一句“只看 2025 年”或指定权威来源，调度者会用新约束调整后续任务，不必推倒已完成的证据。项目交互说明
风险、局限和还没验证清楚的地方
最根本的问题是开放集合没有天然终点。Coverage Map 能证明已知格子填到了什么程度，不能证明未知实体不存在。论文用行范围审计补这一层，但审计仍依赖模型、入口页和估计数量，无法给出真正的完备性保证。
证据图也不等于事实图。来源权威性、时间有效性、同名实体和上下文条件都可能判断错。当前实验主要检查最终单元格，没有专门测试引用是否真的支撑对应表述、冲突仲裁是否稳健，或恶意网页能否污染证据抽取。
主结果只使用一套角色模型和一套抽取模型，并按三次运行取最好值。论文没有完整披露每题费用，也没有报告低性能尾部。换成更弱模型、更贵搜索接口或企业内网后，效果和成本可能完全不同。
技能消融把三层一起关闭，无法分清收益来自搜索策略、站点程序还是编排提示。预置访问技能还能执行代码，规模扩大后需要沙箱、权限最小化、签名、依赖审计和自动失效检测。论文没有给出这部分安全实验。
项目刚开源不久，仓库仍标记为 Alpha。代码可以通过基础语法检查，公开图片链接也可访问，但仓库没有附带现成测试；完整运行需要模型和搜索服务密钥。因此，本文数字应视为作者在预印本中报告的结果，不是独立复现结论。项目安装与配置
持久化状态还带来数据治理问题。网页缓存、引用片段、用户问题和失败记录可能包含敏感内容。企业落地前要明确保留期限、访问权限、删除范围和来源许可，论文目前没有展开。
今日沉淀
- 长任务先做可检查的完成表，再谈自主执行。
- 已知格子全满，不代表该找的对象已经找全。
- 多 Agent 最好共享状态，少靠互相转述。
- 证据写入应是工具执行的默认后果，不是模型的可选动作。
- 技能带来效率，也把维护和安全成本变成长期账单。