WebRetriever: A Large-Scale Comprehensive Benchmark for Efficient Web Agent Evaluation¶

会议: ECCV 2026
Paper: https://eccv.ecva.net/virtual/2026/poster/5413
PDF: https://media.eventhosts.cc/Conferences/ECCV2026/pdfs/10489.pdf
代码: https://github.com/Mininglamp-AI/WebRetriever
项目: WebRetriever
领域: LLM Agent / 网页智能体评测
关键词: 在线基准、网络请求证据、LLM 裁判、操作文档、端到端提取

一句话总结¶

WebRetriever 将 800 个网站上的 1,550 个任务、基于细粒度交互证据的 NavEval 裁判和三种评测协议结合起来，在本基准获得 91.2% 人工一致率，同时揭示六种智能体的平均人工端到端成功率仅为 11.8%。

研究背景与动机¶

网页智能体的评测不仅要回答“能不能点到目标页面”，还要回答“是否按用户要求设置查询条件，并拿回正确结果”。WebArena 等可控环境方便复现，但网站覆盖有限；Online-Mind2Web 等在线基准更贴近真实网站，却仍难覆盖行业知识、专业操作习惯和多样用户意图。只在少数熟悉网站上获得高分，不能充分说明智能体能处理企业分析或专业资料检索。

另一个瓶颈是成功判定本身。最终截图可能看起来像正确的结果页，却无法证明时间范围、筛选条件或查询字段正确；把整条截图轨迹送给裁判又会引入冗余和高 token 开销。即便导航确实成功，页面中的表格、图表和文档仍可能被读错，因此“到达页面”与“交付答案”必须分开评测。

本文选择同时扩展任务覆盖、裁判可见证据和成功定义，而不是训练一个新的浏览器策略。核心 idea：让裁判看到经过规则整理的真实请求与操作证据，并分别测量无文档导航、有文档导航和包含信息提取的端到端完成率。

方法详解¶

整体框架¶

输入是用户任务、预设网站入口，以及协议允许时提供的操作文档；被测智能体在真实网站上执行动作，Playwright 记录交互证据。NavEval 将动作、过滤后的请求和最终截图交给 LLM，输出导航任务是否成功；端到端协议还要求正确提取目标信息，主实验对此采用人工判定。

整套系统的贡献是任务构建与评测流程，而不是一个可训练的新策略网络。下面的流程图保留数据、协议、证据处理与裁判四个环节；人工端到端分支强调，论文没有在主结果表中提供协议 III 的 NavEval 成功率。

%%{init: {'flowchart': {'rankSpacing': 24, 'nodeSpacing': 28, 'padding': 6, 'wrappingWidth': 400}}}%%
flowchart TD
    DATA["跨领域任务构建"] --> PROTOCOL["三协议与操作文档"]
    PROTOCOL --> RUN["智能体执行<br/>Playwright 记录"]
    RUN --> FILTER["请求证据过滤"]
    FILTER --> JUDGE["多源联合判定"]
    RUN -->|协议 III| HUMAN["人工核验导航<br/>与提取结果"]
    JUDGE --> REPORT["成功率与<br/>人工一致率"]
    HUMAN --> REPORT

关键设计¶

1. 跨领域任务构建：把专业业务约束纳入浏览器任务

网站采样以 SimilarWeb 流量数据为起点，覆盖技术互联网、商业金融、教育研究、文化娱乐旅游、生活服务、医疗、工业和公共服务八类核心行业。作者从各行业流量前 30 个网站出发，再加入权威导航资源中的垂直网站，最终形成 800 个网站的覆盖。这里的重点不是简单增加网站数量，而是避免任务全部集中在购物、订票等日常行为上，让专业知识与真实业务逻辑成为测试内容。

任务由行业专家、管理人员、资深数据分析师和大学生按各自经验提供，将通用或专业意图与领域事实要素结合，再按唯一性、稳定性和逻辑真实性交叉核验。例如，论文指出低频场外交易不应被编造成查询“日内高频数据”的任务，更合理的目标是季度或年度报告。这样的审核是在检查任务是否符合业务现实，而不只是检查网页能否打开。难度按人工执行动作数分级：少于 6 步为简单，6 至 15 步为中等，超过 15 步为困难；这衡量的是人工操作长度，并不等同于模型推理难度。网站更新导致任务失效时，作者计划用同难度任务替换，属于在线维护方案，而非冻结快照的复现保证。

2. 三协议与操作文档：分开测量探索、知识利用和结果交付

协议 I 只给任务目标，评价能否导航到符合要求的目标页；协议 II 额外提供操作文档，评价智能体能否利用已有操作经验。文档不是随意写出的提示：智能体先探索任务并生成动作轨迹，NavEval 判定成功后送往标注环节；失败轨迹重新尝试，达到重试上限后由人工修正。标注者继续核验正确性、删除冗余动作，再由 LLM 将精炼轨迹整理为操作手册。这样把“模型是否不知道网站怎么用”与“得到操作说明后仍执行失败”拆成可比较的问题。缓存没有给出重试上限的具体值，也没有完整手册提示词，不能补成确定配置。

协议 III 将终点改为准确取回信息，覆盖文字、文档和图表。任务来源要求权威，答案必须依赖浏览器交互而不能只靠简单搜索，并且查询要对应唯一、稳定的事实答案。协议 I、II 各有 1,000 个任务，其中 550 个重叠且只在文档是否可用上不同；协议 III 有 100 个任务。前两者合并去重为 1,450，计入协议 III 与论文总量 1,550 相符。因此，三个协议不是对同一完整任务集逐级增加条件，主表均值的差异不能直接解释为文档或提取要求的净效应；更直接的证据是固定协议内增删条件的消融实验。

3. 请求证据过滤：补足截图看不到的查询条件

Playwright 在执行过程中记录页面截图、动作和触发的网络请求；NavEval 还利用导航 URL。作者没有把所有流量原样堆给 LLM，而是先按任务入口 URL 的子域匹配保留相关请求，再移除无关或随机字段、规范化结构化载荷、删除无效项，得到紧凑的中间请求序列。其用途是暴露查询与筛选语义：按钮虽然点击了，真正发出去的参数却可能不符合用户条件，而最终截图未必能显示这种差别。

用统一符号可把规则过滤写成下式，其中请求序列为 \(R\)，网站 URL 为 \(U\)，\(R'\) 是过滤结果。缓存中的原式 (2) 存在排版抽取损坏，下面仅按紧邻文字整理其含义，并非增加新的算法。

\[ R'=\mathcal{F}_{\mathrm{rule}}(R,U). \]

规则在这里负责组织证据，不负责穷举每个任务的成功条件；最终语义判断仍由 LLM 完成。这区别于为每个网站维护脆弱的硬编码成功规则。不过，子域过滤可能漏掉跨域服务的关键请求，字段清理也可能删掉相关信号，这是由设计推导出的风险，论文主文没有量化它。图 4 还出现 HTML 快照、DOM/XPath 解析等辅助采集步骤，但正文没有提供足够细节将其解释为独立贡献模块。

4. 多源联合判定：让动作、请求和最终视觉状态相互核验

NavEval 的原始输入包括任务描述 \(T\)、网站 URL \(U\)、请求序列 \(R\)、动作序列 \(A\) 与最终截图 \(I\)。过滤发生在评测器内部，随后裁判联合理解这些信息并给出二元结果；它不是只根据“智能体声称已经完成”判成功。请求提供细粒度条件，动作解释操作过程，最终截图提供可见终态，三者互补，但不意味着发出正确请求就自动证明答案正确。

\[ P=\operatorname{NavEval}(T,U,R,A,I),\qquad P\in\{\mathrm{True},\mathrm{False}\}. \]

实现中的裁判采用 Claude-4.5-Sonnet；评测的是既有智能体，无新增训练损失或优化目标。指标上，成功率 SR 表示被判成功的任务占比，人工一致率 AR 表示自动标签与人工标签相同的占比。为避免缓存原式 (3)、(4) 的抽取乱码造成歧义，依据正文定义规范化为下式，其中 \(\hat y_t\) 是自动标签、\(y_t\) 是人工标签，表格按百分数报告。人工 SR 则将第一式中的 \(\hat y_t\) 换为 \(y_t\)。

\[ \mathrm{SR}=\frac{1}{|\mathcal T|}\sum_{t\in\mathcal T}\hat y_t, \qquad \mathrm{AR}=\frac{1}{|\mathcal T|}\sum_{t\in\mathcal T}\mathbf 1[\hat y_t=y_t]. \]

AR 衡量逐任务标签一致性，不是智能体成功率，也不是简单比较两个成功率均值。即使平均 SR 接近，也可能在不同任务上错判；反过来，任务失败占比很高时，总体 AR 可能掩盖对少数成功任务的误判，因此还需要按标签分组的误差分析。

实验关键数据¶

主实验¶

所有任务从指定入口开始，限制搜索引擎访问，避免实时检索捷径替代网页操作。下表取原表 2 的人工 SR，全部单位为 %；这不是 NavEval 的 AR。

智能体	协议 I：导航	协议 II：带文档导航	协议 III：端到端
SeeAct	9.2	17.1	6.0
Agent-E	11.6	20.4	9.0
UI-TARS-1.5	16.5	24.8	8.0
Browser-Use	24.0	31.6	11.0
Gemini-2.5-Pro (Computer-Use)	37.1	45.2	21.0
Claude-4.5 (Computer-Use)	28.1	36.3	16.0
平均	21.1	29.2	11.8

裁判质量方面，下表摘选原表 3、4。WebRetriever 部分统一使用 Claude-4.5-Sonnet 裁判，便于区分证据组织方式与模型骨干；外部基准的对比骨干不同，不能把差距全部归因于 NavEval 设计。

数据集	自动评测方法	裁判骨干	平均 AR (%)
WebRetriever	Autonomous Eval	Claude-4.5-Sonnet	75.9
WebRetriever	AgentTrek Eval	Claude-4.5-Sonnet	62.7
WebRetriever	WebVoyager	Claude-4.5-Sonnet	77.1
WebRetriever	WebJudge	Claude-4.5-Sonnet	81.0
WebRetriever	NavEval	Claude-4.5-Sonnet	91.2
Online-Mind2Web	WebJudge	WebJudge-7B	87.2
Online-Mind2Web	NavEval	Claude-4.5-Sonnet	97.0

消融实验¶

下表合并原表 5、6 的两组条件消融，数值为 SR (%)。文档消融的基准值对应原表 2 的 NavEval 列，而不是上方人工列；提取消融的完整条件对应协议 III 人工结果。不同判定口径不混算。

协议与条件	Gemini-2.5-Pro (Computer-Use)	Claude-4.5 (Computer-Use)
协议 I，原始无文档	40.9	31.3
协议 I，加入文档	49.2	39.7
协议 II，原始有文档	50.1	40.1
协议 II，移除文档	41.4	31.9
协议 III，要求信息提取	21.0	16.0
协议 III，取消提取要求	43.0	34.0

关键发现¶

同骨干下，NavEval 在 WebRetriever 的 AR 比 WebJudge 高 10.2 个百分点，支持“证据组织方式有价值”，但不能由此单独量化规则过滤的贡献。
固定协议 I 加文档，两个模型分别增加 8.3、8.4 个百分点；固定协议 II 去文档，分别下降 8.7、8.2 个百分点。这比直接相减跨协议均值更能支持操作文档有效。
协议 III 去掉提取要求后，成功率分别提高 22.0、18.0 个百分点，直接说明导航到达与最终信息交付存在明显差距；这不是提取模块的独立准确率。
原表 2 中 NavEval 平均 SR 为 23.6% 和 32.3%，分别高于人工的 21.1% 和 29.2%。高 AR 并不意味着没有成功率高估。

亮点与洞察¶

把网络请求作为可审计证据。 网页上的可见结果往往隐藏了查询参数，裁判增加请求上下文后才能更细地核对用户约束；这一思路可迁移到表单填写和企业检索工具评测。
把知识可用性作为实验变量。 操作手册通过探索、筛选、人工精炼和生成得到，让“不会操作”与“不会利用说明”成为不同的诊断问题。
改变成功的终点。 取消提取要求带来的大幅变化提醒评测者，导航高分不代表可交付答案；应同时保留过程与结果指标。

局限与展望¶

在线维护不等于版本间等价。 作者提出替换失效任务，但相同人工动作数不能保证相同语义难度；未来需要记录任务版本、网站状态和配对评测结果。
局部采样深度与覆盖广度不同。 800 个网站、1,550 个任务覆盖面广，但难以据此断言每个网站的多种业务流程都已充分测试；协议 III 仅 100 个任务。
裁判误差尚未完全展开。 主文将骨干自偏好与规则过滤消融放在补充材料，当前缓存不含这些结果，不能补写去掉过滤后的 AR 或断言无自偏好；也未提供足够的混淆矩阵和置信区间。
效率缺少直接量化。 请求压缩与自动裁判有降低人工和 token 成本的动机，但缓存主文没有延迟、token 数或费用对比，不能报告具体加速倍数。
条件控制限制外推。 禁用搜索引擎有利于隔离交互能力，却与允许自由搜索的生产助手不同；跨域请求过滤和端到端自动核验还需要更细的鲁棒性评测。

评分¶

新颖性：4/5。主要创新在真实任务覆盖、请求证据组织和部署导向协议的组合，而非新的基础模型。
实验充分度：4/5。覆盖六种智能体、多个裁判和外部基准，并有文档与提取消融；过滤、自偏好、成本分析在当前缓存中不完整。
写作质量：4/5。三协议逻辑清楚，但需要区分人工与自动 SR，以及补充修复缓存中损坏的公式排版。
价值：4/5。对企业网页智能体评测具有明确诊断意义，尤其能暴露“导航成功但答案不合格”的部署风险。