Skim：用于快速高效网络代理的推测执行框架

# Accio：面向快速高效网页代理的推测执行方案

来源：https://arxiv.org/html/2605.16565，Kevin Hsieh（微软研究院，西雅图，美国），Suman Nath（微软研究院，西雅图，美国），Ravi Netravali（普林斯顿大学，普林斯顿，美国）（2009年6月5日）

###### 摘要。网页代理能够通过直接浏览实时网页自主完成任务，展现出强大的能力，但高昂的每任务成本和延迟限制了其实际应用。我们认为这些开销并非任务本身固有，而是源于其组合方式。具体而言，网站是围绕用户带入的查询而专门构建的，暴露了页面组织中的内在结构以及从任务类型到轨迹的稳定映射，这些共同带来了显著的节省机会——而如今的代理默认在每个步骤都使用前沿模型、浏览器和顺序ReAct执行，无论实际需求如何，都错失了这些机会。我们提出Accio，一种用于网页代理的推测执行框架，它将离线网站结构分析与在线选择和验证推测性快速路径相结合。为了在每页动作（从而每个查询的轨迹）的巨大空间中确保高准确性，Accio将运行时选择简化为对每个网站的任务类型模板和答案格式目录的查找，利用了两者在相同任务类型的查询中保持稳定这一事实。一个小的判断模型将每个快速路径输出与查询和模式进行比对，在罕见的错误推测情况下回退到完整代理，并由快速路径的最终URL进行热启动，以利用上游轨迹的重叠。在流行的基准测试和网页代理中，Accio将每任务中位成本降低了1.9倍，延迟降低了33.4%，同时保持准确性不变。††版权：无

## 1. 引言

网页代理，即通过直接浏览并与实时网站交互来完成任务的基于LLM的系统，正越来越多地部署在检索增强助手、深度研究工具和企业自动化流水线中。诸如WebVoyager（He等人，2024年（https://arxiv.org/html/2605.16565#bib.bib3））、AgentOccam（Yang等人，2024年（https://arxiv.org/html/2605.16565#bib.bib16））和BrowserUse（browser-use，2026年（https://arxiv.org/html/2605.16565#bib.bib18））等代理现在支撑着一个快速增长的产品类别，这些产品能够解析静态语料库无法回答的查询：导航到经过身份验证的页面、跨目录完成多步骤查找、以及从用户无需自行访问的网站中提取结构化信息。这种能力远远超出了无状态检索流水线（例如，Perplexity、ChatGPT浏览）通过查询搜索索引和综合片段所实现的能力——它们无法维护经过身份验证的状态、无法完成多步骤轨迹、也无法访问搜索覆盖范围之外的内容——但代价是巨大的开销：每任务延迟为30-120秒，API成本为0.20-0.50美元，比无状态检索高1-2个数量级。

网页代理的高开销可追溯到三个现成组件，每个组件都针对比它们通常执行的网页任务更广泛的问题而设计。前沿LLM是为长上下文多跳推理而训练的；浏览器是为任意且安全的人类与任何网页交互而设计的；ReAct则是在具有稀疏反馈的无约束环境中用于代理的通用决策框架。每个组件能力都很强，但未能利用网页所展现的结构规律性。

第一个这样的性质是**步骤异质性**。典型网页代理轨迹中的大多数步骤是机械的（获取已知URL、定位页面上标记的字段、点击稳定的导航元素），不需要前沿推理或完整的浏览器执行。第二个是**任务驱动结构**。网站是围绕用户带入的查询而专门构建的，因此URL模板、页面布局和答案格式在相同类型的查询中是稳定的。例如，解决一个arXiv查找的导航模式也适用于下一个查找，只有查询特定的标识符会改变。这些性质共同意味着许多步骤可以在更便宜的组件上运行，并且许多步骤可以通过遵循网站已经揭示的轨迹而完全跳过。

我们对流行的网页代理任务的分析证实了这种机会是巨大的（§2.2（https://arxiv.org/html/2605.16565#S2.SS2））。利用网站结构的手工编写程序，通过使用轨迹知识通过直接URL获取、修剪到包含答案的内容并通过更便宜的模型进行提取，可以在没有任何准确性损失的情况下比现成的ReAct代理快66.7%-94.9%，便宜17.7-100.7倍。然而，在实践中自动化这种策略是困难的；在现成的ReAct循环中简单替换这些更便宜的技术，会使任务成功率平均下降60%。问题在于，便宜的模型难以从典型页面的数百个交互元素中选择正确的动作，而直接URL获取需要事先精确知道对于给定查询，哪个页面将包含答案（§2.3（https://arxiv.org/html/2605.16565#S2.SS3））。更糟糕的是，错误会在轨迹中累积，因此一个错误的步骤可能会使下游的一切失效。因此，核心问题是如何在查询到来时识别哪些捷径对于*该*查询保持准确性——由于任务的异质性、网站内各页面的变化以及每步资源需求的多样性，这个问题变得困难。

为了应对这些挑战，我们提出了**Accio**，一种用于现有网页代理的即插即用加速框架。Accio背后的关键洞察是，网站**足够可预测，可以离线预计算**导航路径，并且**足够结构化，可以在线验证**答案的正确性。相对于查询频率，网站变化较慢，因此一次任务类型的轨迹模式在未来的许多查询中仍然有效。此外，由于网站对任务结果页面（例如，搜索结果）施加了稳定的格式，快速路径的输出可以轻松地针对查询和预期模式进行验证，而无需调用昂贵的代理。基于此，Accio离线分析每个可访问的网站，为每个任务类型记录适用的捷径（到达其结果页面的URL模式）以及正确输出的样子（这些页面的答案模式）。在运行时，当查询到达时，Accio查阅该分析，如果被覆盖，则通过直接URL获取和便宜模型处理推测性地尝试快速路径，仅当一个小型判断模型判定结果与查询和记录的模式一致时才接受。失败时，Accio回退到完整的ReAct代理，并在快速路径达到的URL处热启动——由于轨迹共享可预测的前缀，即使失败的捷径也减少了代理必须重做的工作。

我们在两个代表性基准测试（WebVoyager、WebShop）上，针对三个流行的基于ReAct的网页代理（BrowserUse、AgentOccam、WebVoyager）评估了Accio。我们考虑了两种部署模式，它们利用相同的底层机制。在**加速**模式下，Accio将每任务中位成本降低了1.9倍，延迟降低了33.4%，同时保持准确性。在**聚合**模式下，Accio将节省的计算预算重新投资到多次试验中，探索不同的轨迹并使用验证器选择的输出。在单次试验基线的成本预算内，这将端到端准确性提升了高达16.7个百分点（多数投票为4.2个百分点）。

参见图注 图1. 代表性的基于ReAct的网页代理的工作流程。代理循环执行渲染、观察、推理和动作步骤，直到任务完成。

## 2. 背景与动机

网页代理产生的巨额开销并非任务本身固有。我们研究这些开销的来源，识别使其可避免的结构性质，并描述自动化消除这些开销所面临的挑战。

参见图注 图2. 代理收敛到答案所需的ReAct步骤数量分布。

参见图注 图3. 每步延迟的细分。动作包括打字、点击、谷歌搜索和滚动，而推理涉及在网页输入上运行前沿模型。

### 2.1. 网页代理概述

典型的网页代理，如WebVoyager（He等人，2024年（https://arxiv.org/html/2605.16565#bib.bib3））、AgentOccam（Yang等人，2024年（https://arxiv.org/html/2605.16565#bib.bib16））、BrowserUse（browser-use，2026年（https://arxiv.org/html/2605.16565#bib.bib18））和SeeAct（Zheng等人，2024年（https://arxiv.org/html/2605.16565#bib.bib17）），通过将前沿LLM与无头浏览器结合，在ReAct执行循环中运行（Yao等人，2023年（https://arxiv.org/html/2605.16565#bib.bib4））（图1（https://arxiv.org/html/2605.16565#S1.F1））。在每个步骤，代理在浏览器中加载当前页面，观察其渲染表示（作为序列化的DOM树或屏幕截图），推理下一步要采取的动作，并通过标准浏览器原语（如点击、键入输入、滚动和导航）对该页面执行该动作。每一步都需要一次完整的LLM调用，处理当前页面表示以及运行中的交互历史。循环重复，直到代理决定任务完成、认为无法完成或步骤预算耗尽。

网页代理旨在执行需要浏览面向人类的网站以检索目标信息的任务。示例任务包括查询电子商务目录中的产品价格和可用性、从学术仓库检索论文摘要和引用计数、比较教育平台上的课程设置、总结最新发布的新闻文章、以及从预订网站收集预订详情。它们不同于调用结构化API或为程序化访问设计的MCP服务器的工具使用代理（例如，在本地文件和开发者工具上操作的编码代理（Mündler等人，2024年（https://arxiv.org/html/2605.16565#bib.bib37）；Bouzenia and Pradel，2024年（https://arxiv.org/html/2605.16565#bib.bib39））），也不同于从搜索引擎结果中综合答案而无需访问底层页面的无状态检索流水线（Liang，2026年（https://arxiv.org/html/2605.16565#bib.bib38））。网页代理的定义性特征是它在**实时网页**上操作，并且必须推理随网站和查询变化的页面内容和交互模式。

### 2.2. 专业化的机会

我们首先使用三种网页代理——BrowserUse、AgentOccam、WebVoyager——以及§5（https://arxiv.org/html/2605.16565#S5）中概述的实验方法，对WebVoyager基准测试中的151个代表性任务的每任务开销进行了分析。总体而言，我们发现每任务延迟范围为30-120秒，转化为每任务模型推理的API成本为0.20-0.50美元。深入挖掘，这种开销分解为两个因素，每个因素都贡献显著：轨迹所需的步骤数量，以及每个步骤的开销。如图2（https://arxiv.org/html/2605.16565#S2.F2）所示，中位任务需要4个步骤，80%的任务至少需要7个步骤。图3（https://arxiv.org/html/2605.16565#S2.F3）将每个步骤分解为浏览器动作和LLM推理延迟，表明两者都有显著贡献（LLM推理中位延迟为4.7秒，浏览器动作中位延迟为6.6秒）。由于动作决策依赖于当前页面内容和至今的轨迹，每步推理成本随着历史积累而增长。

我们认为这些开销并非底层网页代理任务所固有。相反，它们源于*统一地*在所有步骤上应用沉重、通用的组件——前沿模型推理、完整浏览器渲染和迭代的ReAct循环，每个组件都专为比典型网页代理任务广泛得多的问题而设计——而不考虑需求。接下来，我们描述网页的三个内在性质，这些性质使得这种统一性变得不必要，并且共同为加速提供了巨大的专业化机会。

参见图注 图4. 每任务中导航步骤的百分比分布，即，在页面之间移动代理，而不是通过提取答案、比较值、修改页面状态来直接满足任务要求。

参见图注 图5. 一个任务中某一步骤的网页状态输入。红色圆圈标记了搜索栏，这是下一个动作（键入查询）中唯一承载负载的元素。输入的其余部分（产品推荐、图像、侧边栏链接等）不是必需的。

**大多数步骤是导航性的。** 大多数网页代理任务涉及只读信息检索（产品价格、论文的引用计数、课程的先修要求），答案通常集中在一个或几个目标页面上。到达这些页面涉及搜索、过滤、分页、点击结果等。然而，这些步骤主要是导航性的——用于在页面之间移动的步骤，而不是直接满足任务要求——而不是承载负载的推理。图4（https://arxiv.org/html/2605.16565#S2.F4）说明了这一点，显示在我们的基准测试中，中位任务中66.7%的步骤纯粹是导航性的。此外，在给定的网站上，这种导航通常遵循查询不变的模式：每个Amazon购物任务涉及搜索然后产品页面导航，每个arXiv查找将标识符解析为摘要页面，每个GitHub任务通过所有者名称定位仓库。知道该模式的代理因此可以在一次直接获取中到达目标，而不是通过多步ReAct循环重新发现它，只需替换查询特定的标识符即可。

参见图注 图6. 手工优化程序的延迟。

参见图注 图7. 手工优化程序的成本。

参见图注 图8. 每个网站可通过仅HTTP执行解决的任务比例。许多网站支持通过直接检索而无需浏览器交互即可解决大部分任务。

**许多页面不需要浏览器。** 对于许多网站，嵌入任务答案的内容是在服务器端渲染的，并在HTTP响应体中完整到达（例如，Amazon产品页面、arXiv摘要、GitHub仓库视图）。在这些情况下，普通的HTTP获取返回浏览器本应显示的内容，而无需脚本和渲染的高开销。图8（https://arxiv.org/html/2605.16565#S2.F8）证实这很常见：在我们基准测试中，55.8%的任务所需内容完全可以通过HTTP获取访问，而无需调用浏览器。只有当客户端JavaScript产生承载负载的内容时（例如，交互式地图、动态揭示的产品变体），浏览器执行仍然是必要的，即使如此，这些开销也仅对依赖于动态生成内容的特定步骤才是必要的。跳过部分浏览器执行可以消除大量开销。

参见图注 图9. 手工优化程序（左）与相应的现成ReAct轨迹（右）在Amazon检索任务上的比较。

表1. 页面噪声对提取准确性的影响。Qwen2.5-14B在仅嵌入必要信息的小型去噪页面内容上与GPT-4o相匹配，但在完整页面上性能急剧下降，而GPT-4o保持相对稳健。

**大多数步骤不需要前沿模型。** 典型的网页呈现数百个可能的动作，以交互元素的形式与广告、推荐小部件、导航铬和相关内容侧边栏一起出现。