WebFovea 提出视觉网页智能体四阶段加固框架，WebRetriever 挑战赛得分从 31.0 升至 57.0

视觉网页智能体在真实网站上，模型决策正确时，点击和回报仍可能出错，使端到端答案不可信。

• 场景：作者称统计门户、监管文件、排名和仪表盘上的信息要经过菜单、筛选、表格和图表才能读出。WebRetriever 在 800 个真实网站上有 1,550 个任务；Protocol III 要求从入口 URL 操作站点自身界面，返回可精确核对的单一答案，且轨迹必须到达证据。作者转述该基准的结论：仅导航成功并不能预测任务完成。
• 两层落地：答案须来自本次会话中经界面到达的权威页面，而不是参数记忆、搜索引擎或手写 API。动作须落在目标像素或元素上，效果须被正确感知。作者称到评测时，部分公开参考答案已与活站不符，因此要靠轨迹和最终屏幕证据。
• 缺口：作者称现有工作多改进模型或页面表示。决策仍要经模型与浏览器之间的 harness 往返；他们观察到的许多失败发生在解析、执行、反馈或观察之一，而不是推理。
• 观察：一步只有四段都成功才算成功。一段断裂时，强模型也会点到空白、重输从未送达的文字，或放弃实际已生效的动作。作者的说法是：模型是对的，点击是错的。
• 做法：WebFovea 按四阶段加固往返，并用护栏限制规则与预算。四次提交都用 claude-opus-4-6。作者称隐藏集得分从 31.0 升至 57.0，反映 harness 改动，至多还受活站运行间方差影响；四阶段视角不依赖模型，但个别修复会依赖。

作者把本文放在「给定模型的决策如何到达页面并返回」，而不是更换模型。

网页智能体基准

• 自托管、快照与桌面：WebArena（Zhou 等，2024）用自托管站点；Mind2Web（Deng 等，2024）用离线快照；OSWorld（Xie 等，2024）把评测扩到完整桌面。
• 真实网站：WebVoyager（He 等，2024）在真实网站上评测多模态智能体。WebRetriever（Dong 等，2026）扩到 800 个网站、1,550 个任务，含基础导航、带操作文档的导航和端到端检索，并引入 NavEval：依网络请求、URL 轨迹、动作和最终截图判断导航，与人类专家一致的比例为 91.2%。作者称其核心发现——导航成功本身不能充分预测任务完成——是挑战聚焦 Protocol III 的原因。
• 基线方法与基准：Table 1 列出排行榜上 Protocol III 基线的人工核验成功率：Claude Computer Use / claude-4-8-opus 为 47%，Kimi Agent / Kimi K3 为 28%，Google Computer Use / gemini-2.5-pro 为 21%，Claude Computer Use / claude-4-5-sonnet 为 16%，Browser Use / gpt-4o 为 11%，Agent-E / gpt-4o 为 9%，UI-TARS-1.5 7B 为 8%，SeeAct / gpt-4o 为 6%。作者称这些数字来自另一任务集并经人工核验，不能与挑战分数直接比较。表注 † 表示模型不在挑战批准列表中。

智能体范式

• 视觉坐标：Claude computer use、Gemini computer use，以及端到端训练的 GUI 模型 UI-TARS。论文转述 SeeClick 的结论为：更好的 GUI grounding 能改进这类智能体。
• DOM 与中间路线：Browser Use 把页面序列化为带索引元素；Agent-E 使用 DOM 蒸馏与变化观察；SeeAct 把 GPT-4V 的动作描述落到 HTML 候选上。Set-of-Mark 在截图上叠加元素标签，位于两者之间。这一节只作介绍，没有逐篇批评。

模型与环境的接口

• SWE-agent（Yang 等，2024）：论文称其显示，智能体–计算机接口的设计会强烈影响语言模型解决软件工程任务的效果。作者把本文视为视觉网页智能体上的同类问题。

定位

• 起点：WebFovea 建在组织者发给各队的模板上，即 WebRetriever 仓库中为 UI-TARS 1.5 编写的参考实现的裁剪版。附录 A 的 Table 7 标明继承、修改与新增。
• 区别：作者认为多数相关工作改进的是模型或页面表示；本文固定同一批准模型，考察决策到达页面再返回的路径。作者同时写明，这不是主张模型保持不变：更强或更专门的模型有帮助，不同步骤也可以路由到不同模型、规则或经典视觉工具。

WebFovea 沿用参考实现的观察–思考–行动循环，模型不直接操作浏览器。作者把每一步定义为必须四段都成功的往返（Figure 1、Table 2）；护栏决定允许哪些往返、允许多少次，本身不是往返的一段。

任务与模型所见

• 任务：Protocol III 给出自然语言指令和入口 URL。智能体操作活站，用 finished 提交单一答案。类型包括文档抽取、表单、多源比较、完整检索和图表分析。没有部分分；最终分结合答案正确性，以及对轨迹和代码的人工复核。
• 运行：代码在指定沙箱中跑 100 个隐藏任务。Chrome 经 CDP 驱动，视口 1920×1080；每次评测有固定时间预算，论文未给出该预算的秒数。七天内每天至多一次评测，只返回汇总分。模型须在批准列表内，经 OpenAI 兼容 API 调用。当时最新批准的 Anthropic 模型为 Claude 4.6。全程使用 claude-opus-4-6。
• 计入条件：逐步交互，不得绕过界面、跳到预计算结果或枚举数据 API；实时自主，不得用预存或缓存答案；来源合规，答案来自指定站点，不用搜索引擎或第三方数据。任务开始后不得重试或重置，只可重试单步。
• 输入：每步收到任务、动作空间、硬约束、全文历史、最近五张截图，以及必要时一句上一步反馈。不接收 DOM 或无障碍树，以像素坐标行动。DOM 只给执行器，以及反馈笔记和 read_text。只有一个执行器函数能改浏览器。

解析

• 只留首个动作：作者观察到模型有时在一次回复里写完后续回合、伪造环境响应并调用 finished；有一次在第 1 步就提交答案，从未看到数据。harness 只保留第一对 Thought/Action。
• 剥离自生成标记：模型偶尔在动作后追加聊天模板结束标记。这些标记会被键入搜索框，并因回复回到历史而反复出现（Figure 2）。修复剥掉这类标记和动作后的杂散标记，同时保留框标记。离线重放数字见第 4 问。

执行

• 坐标对齐：参考实现按 UI-TARS 的 smart_resize 映射，假设 28 像素 patch 网格。对 1920×1080，该映射接近恒等，代码把模型坐标当作全分辨率像素。作者发现接口会在模型看到图之前缩小图像。修复是自行把每张截图缩到至多 1440×810，再按发送图像与运行时实测视口之比映射。作者给出的校正因子：发送 1920×1080 时 x/y 为 1.324/1.350；发送 1440×810 时为 1.010/0.993。Figure 3 对比同一点击在对齐前后的落点。
• 元素级动作：原生下拉的弹出层画在页面外，截图里看不见。select 在给定点定位元素并直接设选项，顺序为精确、规范化后、子串。fill 聚焦该点的可编辑元素（含 iframe 内和遮罩下），清空后发送真实击键，并回读实际值；原生日期转为 ISO。旧提示词要求 type 以换行表示提交，旧执行器不按 Enter；现对这种调用按 Enter。
• iframe DOM 回退：嵌入图表和文档查看器会吞掉部分物理点击。无模型调用的探测中，视口底部跨源 iframe 上三次物理点击无效，一次 DOM 级点击有效。若动作落在子 frame 且主、子 frame 都未变化，执行器在该 frame 内派发一套 DOM 鼠标事件（Figure 4）。CAPTCHA 提供方的 frame 被排除：作者称合成事件在测试中无效，且正是反机器人系统会检查的对象。

反馈与观察

• 回报实际变化：动作前后比较 URL、标题、节点数、文本长度、滚动偏移和焦点。作者称这与像素差分不同，不会被时钟或轮播骗过。无变化时，笔记写明点击点下的元素及是否可点击。后补子 frame 指纹，且不把焦点移入 iframe 算作变化；对 hover 和 SVG/canvas 比较页面文本哈希。失败的 select 返回可选项列表。作者称准确反馈必要但不充分，因此与执行器预算一起用。
• 让所需信息进入截图：hover 用于只存在于 tooltip 的值。find_text 把下一处匹配滚入视野，主 frame 没有时搜子 frame，但不返回文本；答案仍须从截图读取，作者称这是该工具被批准的条件，每任务至多 10 次。read_text 返回标签附近至多 600 字符，只许核验已从截图读到的值，每任务至多 5 次。自定义字体把数字放在少用码位上时，read_text 换成问号并报告替换数。作者称不能整段丢弃：一个站点某行只有 3.5% 被混淆，需要的正是这 3.5%。1440×810 的上限也避免接口再次重采样。
• 触发写成规则：作者称模型出错时也常常自信，不能自行决定何时核对，因此把触发写成提示词中的规则，而不是交给模型判断「需要时再用」。使用次数见第 4 问。

护栏

• 封闭动作集：早期版本有 goto。审计数字见第 4 问。最终没有 URL 导航、JavaScript 或 HTTP。goto 和浏览器级快捷键仍会被解析，只为拒绝并解释。论文写明十四条硬约束，点名的包括：留在站内、用页面自身控件设置指名筛选、只根据本次会话所见作答或提交空答案、仅当答案在当前截图可见且筛选仍在时才 finished。已开始的任务不重试；浏览器断开记为失败。
• 预算与调度：每任务 80 步和 1,800 秒，由执行器拒绝超额调用并附解释。作者称两限会互相制约，时间上限往往先到，只提高其中一限作用不大。连续滚动不再一律在 10 次后结束任务，而是页面也不再变化时才结束。Table 3 中 back 至多 15 次、reload 至多 2 次、click_many 至多 6 次且仅用于图像网格 CAPTCHA。模型调用在 403/429/5xx 和超时时重试，240 秒内至多 6 次。任务从共享队列分发。导航后等待 1 到 8 秒，页面稳定即返回，替代固定 3 秒。

实验设置

• 官方：四次提交，隐藏集 100 题，只返回汇总分。模型均为 claude-opus-4-6。Table 4 的分数是答案准确率；作者称最终提交的人工复核未扣分。
• 本地：经组织者许可，在 100 个公开 Protocol III 任务上开发，确定性分为 dev70 与 holdout30。本地评分含精确匹配、数值匹配（相对容差 0.5%）和日期匹配，以及可选的语义等价 LLM 评审。论文未说明该评审模型，也未报告使用次数。
• 可评分子集：100 个站点中 16 个从作者网络不可达，holdout30 中可评分任务为 25 个。同一代码版本上，这 25 题本地为 52.0%，隐藏集官方为 46.0%。论文未说明该版本对应 Table 4 的哪一次提交。作者称任务集不同，但 6 分差距落在 n=25 时一个二项标准差（约 10 分）之内，故把本地数字当作相对比较的参考。
• 组件比较：一次 100 题评测约 170–230 美元，且只返回汇总分，所以组件在小的定向集合上比较。每次配对都包含已经通过的任务。作者称样本量小，报告的是方向，不是统计显著性。
• 对照：起点是参考实现。作者称从未把参考实现提交到隐藏集。本地用同一模型跑参考实现时，一个 10 题子集一题未解。
• 重复：论文未报告同一版本的重复次数。作者称活站会变化，同版本重复运行会有差异，每份官方分来自单次运行。

主结果

Table 4 为官方隐藏集答案准确率。每次提交捆绑多项改动。

日期	得分	论文列出的主要新增
Aug 29	31.0	坐标对齐、select、hover、reload；封闭动作集与硬约束
Aug 31	41.0	find_text、back；共享队列调度
Sep 1	46.0	token 剥离；fill 与换行 Enter；read_text；滚动中断条件
Sep 2	57.0	iframe 回退；子 frame 搜索；80 步；模型调用重试

• 不能拆到单组件：作者称增益不能归到单个组件。第二次提交的 +10 主要来自完成更多任务。
• 完成度与准确率：第一次评测达到时间上限时只完成 79/100，其中 31 题正确，作者给出的准确率为 39.2%。作者称若按该准确率完成第二次那样的 97 题，得分大约会是 38；因此这 10 分里大约 7 分来自完成更多任务，大约 3 分来自答得更准。
• 名次：作者报告最终 57.0 分（满分 100），在 WebRetriever Challenge 2026 中列第 2，人工复核未扣分。

分阶段配对证据

Table 5 按阶段给出本地 dev 任务的配对结果。+x/−y 为修复/弄坏的任务数。坐标对齐一行是版本级比较。

组件	n	变化
token 剥离（离线，按步）	7,705	551 个污染步全改，7,154 个干净步不改
坐标对齐	24	8→20（+12/−0）
fill + 换行 Enter	10	2→4（+2/−0），步数少 12%
iframe 回退	1	此前未解 → 25 步通过
hover（与对齐一同引入）	5	0→4
步数上限 40→80	8	0–1→4，其中 2 题需要超过 40 步

• 坐标对齐：该版本还含其他改动，基线仍可用 goto，其分数被抬高。作者将大部分增益归因于对齐，因为点偏使任务循环到步数上限；触达步数上限的任务占比从 67% 降到 4%。作者称真实增益若有差别只会更大。真实页面上 3 个目标的偏差从 122–189 px 变为 1–5 px（Table 5）。Figure 3 中，旧映射把下采样图上的 (287,400) 几乎原样执行到页面 (285,396)；对齐后把 (284,396) 按 4/3 映到 (379,528)。摘要写每次点击落在预期坐标的 3/4；正文写两个任务上预期与点击位置之比为 4/3。
• iframe 与 find_text：Figure 4 的 Tableau 任务在步数上限 40 或 80 的更早运行中从未解出。作者称物理点击无效后，子 frame 指纹显示无变化，执行器改派 DOM 点击，仪表盘随之重绘。Table 5 另有 find_text 单任务：40 步失败，改为 12 步通过。六个定向任务上，把 find_text 的触发改成规则后，使用数从 2 增到 3；从一开始就写成规则的 read_text 在 5 个任务中被使用。作者称被使用不等于有帮助。
• 污染回合：本地 305 个任务回合中 15 个（4.9%）被模板标记污染；13 个可计分回合里 12 个失败。成功率在污染回合为 7.7%，干净回合为 41.7%。作者称这是观察性比较，不是修复本身的对照；修复是否改动干净步，由上面的离线重放检查。

负面结果

• 反馈单独不够：加入「无可见变化」笔记后，10 个空转任务仍为 0/10，总步数仍为 400。作者称笔记到达了模型，思考里也承认了，但模型继续重复该动作。作者因此让执行器强制预算。
• 空转启发式：连续 6 次无变化就停止的规则，中止了一个否则会成功的任务，且没有挽回任何任务，作者将其撤回。
• read_text 与预先指标：read_text 在 6 个定向任务的 5 个中被使用，但一个都没修好；一个标签匹配了 124 个元素。它也没有弄坏任务，因此保留，每任务上限 5 次。为 fill 预先选定的指标（更少的重复输入）为 6→6；作者称改进出现在步数上，数字见 Table 5。早期在过时版本上把步数上限从 40 提到 65 没有增益；作者称应在上游修复之后重做消融。

失败归类与开销

• Table 6：按全部本地运行中的最好结果归类 100 个公开任务。正确数是任一单版本的上界，且有的任务落入多个桶。作者给出的近似计数：答对约 55；参考答案过时或定义不同 13（公开集，不是隐藏集）；网络不可达 16；结构性问题 6；能力缺口约 4；路径未找到或决策错误 3。结构性问题在表中写为图像网格 CAPTCHA、仅 canvas 的界面、答案需要键入 URL 或跨多页。作者称其余错误里有许多不是智能体造成的。
• 捷径审计：早期带 goto 的 dev70 运行有 692 次 goto：70 题中 18 题直接查询数据 API，21 题访问搜索引擎，正确答里 58% 来自这类捷径。提交前最后一次 24 题回归中，作者称每个最终页面都经站点自身界面到达，没有搜索引擎访问，也没有手写 URL。
• 开销：平均每步约 10.6k 输入 token 和 127 输出 token，输入约为输出的 83 倍。作者称几乎全因每步重发最近五张截图。100 题约 170–230 美元。规定的 OpenAI 兼容端点不能用提示词缓存。

其他消融与分析

• 快捷键拦截：Table 5，n=10，0→2（+2/−0）；与反馈笔记和后来移除的 goto 一起交付。
• 滚动中断条件：Table 5，n=3，挽回 2 个任务。
• reload 预算：5 个任务中挽回 2 个、另 2 个省下预算、0 个变差。
• 换行形式：356 次 type 中 79 次（22%）带有提示词承诺但旧执行器不发送的换行。
• 调用中断：305 个回合中 4 个（1.3%）因反复 403 或连接错误在第 0 步结束；之后加入重试。
• 点击范围：首次完整运行的 1,312 次点击均未出现在 x=1440 以右或 y=810 以下。

作者指出的局限与后续方向

• 一个模型（§6.2）：全部结果使用 claude-opus-4-6。作者称四阶段视角不依赖模型，但尚未展示每项修复可以迁移；坐标对齐和 token 剥离针对的是该模型及其 API 的问题。
• 隐藏集没有同模型基线（§6.2）：从未提交参考实现本身，因此 31.0 的起点已经包含若干修复。本地用该模型跑参考实现时，10 题子集一题未解。
• 小样本（§6.2）：组件证据来自 1–24 个任务的定向集合，显示方向，不是显著性。
• 活站（§6.2）：站点会变化，有的从作者网络不可达，同版本重复运行会有差异，每份官方分来自单次运行。
• 开发数据（§6.2）：在公开 Protocol III 任务上开发，本地数字不能与排行榜分数比较。
• 后续方向（§6.3）：作者按预期收益相对工作量排序：把不同步骤路由到大或小的多模态模型、规则或经典视觉程序；用 OCR、感知哈希和模板匹配补充反馈与观察；在 finished 前用独立、新上下文的模型调用核验答案，针对错行和错表；在挑战 API 约束之外使用带提示词缓存和 tool-use 的原生 API，作者估计成本可降 55–70%，并去掉自由文本解析及由此而来的大部分解析失败；截图旁展示带坐标的可交互元素列表并做 A/B，作者称混合方案并不自动更好；对 PDF 和表格做下载后解析，以及按任务类型的短清单和按站点的操作笔记（类似 Protocol II）；在同站生成有程序化真值的合成任务，把教师轨迹蒸馏到更小的开放模型。

实验覆盖范围

• 官方运行：四次隐藏集提交，每次 100 题，只返回汇总分；七天内每天至多一次评测；使用的模型是批准列表中的 claude-opus-4-6（§3、Table 4）。
• 本地划分：100 个公开 Protocol III 任务，分为 dev70 与 holdout30；16 个站点从作者网络不可达，holdout30 可评分 25 题（§5.1）。
• 组件与重放：配对集合为 1–24 个任务；token 修复另有 7,705 步离线重放；每次配对包含已通过任务（§5.3、Table 5）。
• 评分与复核：本地为精确、数值（相对容差 0.5%）和日期匹配，另有可选 LLM 评审，论文未说明该模型；官方分结合答案正确性与轨迹、代码的人工复核，作者称最终提交未扣分（§3、§5.1、Table 4）。
• 论文写明未做或未报告的项：参考实现未在隐藏集上提交（§6.2）。论文未报告同一版本的重复次数，也未报告可选 LLM 评审与人工复核的一致性。

WebFovea 是参加 WebRetriever Challenge 2026、走 Protocol III 的视觉网页智能体。作者报告成绩为第 2 名、57.0 分（满分 100）。

• 问题：从入口 URL 操作真实站点并交回可核对答案时，模型并不直接接触浏览器。作者把每一步拆成解析、执行、反馈、观察，并认为许多看似推理错误的失败出在这四段：回复被读错、点击没落在目标上、页面反应被报错，或模型没看到所需信息。
• 做法：四次提交都用 claude-opus-4-6。只保留首个动作，并剥离自生成的聊天模板标记；截图缩至至多 1440×810 后按视口比映射坐标；用 select、fill 和 iframe 内的 DOM 事件处理像素点击无法完成的控件；用 DOM 与子 frame 指纹、文本哈希回报变化。观察侧有 hover、不回传文本的 find_text，以及只用于核验的 read_text。动作集封闭，硬约束和步数、时间、单动作预算由执行器强制。
• 结果：隐藏集答案准确率依次为 31.0、41.0、46.0、57.0（Table 4），最终人工复核未扣分。作者称第二次的 10 分里大约 7 分来自做完更多题、大约 3 分来自答得更准。含坐标对齐及其他改动的版本，在 24 个 dev 任务上从 8/24 到 20/24（Table 5）；作者将大部分增益归因于对齐，并注明基线仍有 goto。305 个本地回合中 4.9% 被模板标记污染，污染回合成功率 7.7%，干净回合 41.7%。只加无变化笔记时，10 个空转任务仍为 0/10。
• 作者的结论：作者根据自身经验认为，活站上的失败常常不在推理，而在决策如何被执行和回报。作者列出的原则包括：先定位断裂阶段，再责怪模型；动作在提示词、解析器、执行器和反馈中一致定义；预算由执行器强制；触发写成规则；复合动作只在能去掉一类静默失败时才加。作者称四阶段视角不依赖模型，因此应当能带到更强模型、模型组合和新环境，但尚未展示每项修复都可以迁移。