随机应变网页AI助手：乔治亚大学联合研发动态策略调整

这篇关于网页AI助手的研究，由美国乔治亚大学、腾讯美国、纽约大学和香港理工大学联合完成，论文以预印本形式发布于2026年6月，编号为arXiv:2606.04391。如需查阅原文，在arXiv平台搜索该编号即可。

一、从“死记硬背”到“随机应变”——网页AI助手面临的真实困境

每天有大量用户在网页上处理各类重复性任务：电商平台搜索商品、后台系统更新订单、论坛回复帖子、代码平台提交合并请求……这些任务表面多样，底层操作逻辑却高度相似。“打开设置页面”、“填写表单”、“点击提交”——这些步骤像固定舞步，反复出现在不同任务中。

近年来，研究者开始训练AI助手自动完成这类网页操作，这类助手被称为“网页智能体”。它们能接收自然语言指令，在真实网页环境中逐步完成点击、填写、提交等动作，如同一位熟练的办公室文员。

问题在于，这些AI助手处理新任务时，往往只能“从零开始”摸索。每完成一个任务，积累的经验就被丢弃。研究者的解决思路很自然：让AI将已完成的任务流程整理成“技能卡片”，下次遇到类似任务时直接调用，避免重复试错。这个方向已有初步探索——例如存储完整任务工作流、将操作步骤转化为可执行程序、或检索过往成功经验。

可惜，现有方法存在共同的盲点：它们只在任务开始时查询一次“技能库”，选定几张卡片后，整个任务中便死守这些卡片不再更新。这就像厨师进厨房前查阅一遍菜谱，然后无论锅里发生什么——水烧干、食材焦糊——都机械照做，绝不重新调整。

研究团队精准指出：网页操作的本质是动态变化的。任务初始可能在首页，几步后可能进入下拉表单，再几步后可能遇到需填写特定字段的对话框。每一步的“当前页面状态”都在变，适合调用的技能也在变。若只在任务开始时选定技能、之后不再更新，就会出现“技能与状态不匹配”的尴尬——初始选定的技能已派不上用场，而当前页面真正需要的技能却未被召唤。

这项研究要解决的核心矛盾正是：如何让AI助手在每一步操作时，都能同时依据“当前任务目标”和“当前页面状态”两条线索，动态调取最合适的技能？

二、先学会“分段总结”——让技能颗粒度恰到好处

在解决上述问题之前，研究团队还需处理另一个基础难题：技能库里的技能应该有多“大”？

假如每张技能卡片记录的是整个任务从头到尾的完整流程，那么这张卡片携带的信息过多、过于具体，只有在完全相同的任务场景下才能复用，很难套用到中途某个特定页面状态上。反过来，如果每张卡片只记录一个单独的点击或填写动作，那又太“原子化”，对AI助手几乎无指导意义——毕竟“点击某个按钮”这类操作，AI本身就能完成，无需专门存储。

研究团队采用了一种精妙的方法解决粒度问题，称为“滑动窗口提取”。用切胶卷比喻：一段成功完成的任务操作轨迹，就像一卷拍摄完毕的胶卷。团队既不是将整卷胶卷装成一张技能卡，也不是把每一帧单独裁出，而是用一个长度在2到5帧之间的“小窗口”，沿胶卷滑动，截出一段段连续的小片段。每个片段包含2到5个连续操作步骤，恰好对应那些“有意义的小程序”——比如“打开账户菜单，点击地址设置，等待表单加载”，或者“填写起点，填写终点，点击搜索”。

每个小片段提取后，还需经过一道“审核”工序。研究团队使用语言模型判断该片段是否构成一个“可复用、依赖当前页面状态的子程序”。通过审核的片段会被进一步转化为一张标准技能卡片，包含两部分：一段自然语言描述，说明该技能适用什么场景、在什么页面状态下生效；一段可执行的Python代码，直接实现这些操作步骤。

为确保提取的技能真正可用，团队还设计了验证环节：将原始轨迹中对应的操作步骤替换为对该技能函数的调用，重新在环境中执行，检查结果是否仍被判定为成功。只有通过替换测试的技能才会被正式加入技能库。这道验证关相当于菜谱在正式出版前必须经过试做测试——只有能做出合格菜肴的菜谱才值得收录。

这种“文字描述加可执行代码”的双重表示方式，是这项研究的巧思之一：文字描述负责“找到你”——用语言匹配检索查询；代码负责“执行你”——被AI助手直接调用完成操作。两者分工明确，缺一不可。

三、技能也要“看时机”——状态感知的动态检索机制

有了粒度合适的技能库后，研究团队还需解决另一个关键问题：在AI助手每一步操作中，如何从技能库里找到最合适的那几张卡片？

这个检索过程设计了两条“查找线索”。第一条是任务目标——即最初收到的自然语言指令，比如“帮我把用户A的送货地址更新为XX路XX号”。该线索贯穿整个任务始终，告诉检索系统大致任务类型。第二条是当前页面状态——即AI助手此刻正在看的网页内容。原始页面内容往往非常冗长（网页的“可访问性树”结构包含大量元素信息），因此研究团队先用语言模型将其压缩成一段简洁的“状态摘要”，用操作性词汇描述当前页面类型及可执行的操作——例如“这是一个地址信息填写表单，当前可执行填写字段、点击保存等操作”。

这两条线索被加权合并，共同为技能库中的每张卡片打分：任务目标与该卡片的描述有多相似？当前页面状态与该卡片的描述有多相似？最终分数是两者加权平均。研究团队将各占一半权重设为默认配置，实验结果也证实这是最优比例——偏重任何一方都会导致性能下降。

不过，仅靠相关性评分还不够。因为技能是从滑动窗口中提取的，许多相邻窗口提取出的技能内容高度重叠——就像同一段操作被裁成了略微偏移的好几个片段。如果直接取相关性最高的5张卡片，很可能5张都在描述同一件事，只是表述略有不同。这就好比你去图书馆员推荐书，对方推荐5本书内容完全雷同，只是封面颜色不同——毫无帮助。

为解决“高度重复”问题，研究团队引入了一个称为“最大边际相关性”（MMR）的重排机制。该机制的逻辑很直观：每次选下一张卡片时，不仅要看它与当前任务和状态的相关度，还要看它与已选卡片的差异度。相关度越高、与已选卡片差异越大，得分越高。这样选出的5张卡片，既保证每张都切题，又保证彼此之间互不雷同，覆盖不同操作场景。

每次检索得到的这5张技能卡片，仅在当前这一步决策时有效。AI助手看到这些卡片，若发现某张卡片描述的操作正好符合当前页面状态，就可以直接调用对应的代码函数，一次性执行多个步骤；若无合适的卡片，则退回单步操作模式。完成这一步后，下一步重新检索，根据新页面状态召唤新卡片。

这就是这套方法的完整名称——“状态感知动态检索”（SGDR，State-Grounded Dynamic Retrieval）的由来。

四、持续学习、不断积累——在线技能学习的完整闭环

除了检索机制，这项研究还搭建了一个完整的“边做边学”框架，称为“在线技能学习”。核心思想很简单：AI助手按顺序逐一完成任务，每完成一个任务，就从本次轨迹中提取新技能并加入技能库；下一个任务来临时，这个更新过的技能库就成为可用资源。任务一个接一个到来，技能库一步步积累壮大，就像工匠在日常工作中慢慢积累一套工具箱。

这个框架有一个重要约束：AI助手在完成任务时，无法确认自己是否真正成功。网页操作的结果很多时候不是立即可见的，或需要外部验证。因此研究团队引入了一个“评估模型”，在每个任务完成后，由评估模型根据任务指令和整个操作轨迹，给出“成功”或“失败”的二元判断。只有被判定为成功的轨迹，才会被用来提取新技能。

这个设计保证了技能库里积累的都是“有效经验”，不会被失败轨迹污染。评估模型的判断虽非完美，可能偶尔误判，但整体上为技能库的质量提供了保障。

整个流程形成一个完整闭环：执行任务 → 评估结果 → 提取技能 → 更新技能库 → 执行下一个任务。每一轮循环都在让AI助手变得更有经验，下次遇到相似情境时表现更好。

五、真实网页环境里的实战检验——实验结果详解

研究团队在WebArena这个广泛使用的网页智能体评测平台上验证了SGDR。WebArena模拟了五类真实网站的操作场景，分别是电商购物（Shopping）、后台管理（Admin）、论坛讨论（Reddit）、代码协作平台（GitLab）和地图导航（Map）。研究团队剔除了少数需要跨网站操作的任务，最终使用了764个单一域名任务，在每个域名下维护独立技能库，避免不同网站的技能互相干扰。

为公平比较，研究团队将SGDR与四个对照方法对比：完全不使用技能库、每次独立从头完成任务的“纯净基线”（Vanilla）；以及三种现有在线技能学习方法——以自然语言工作流形式存储技能的AWM、以可执行程序形式存储技能的ASI，以及检索过去成功经验辅助决策的CER。这三种方法都是“任务级静态检索”的代表——在任务开始时检索一次，之后不再更新。

评测使用了两种规模不同的语言模型作为AI助手的大脑：参数量较大、能力更强的GPT-4.1，以及参数量较小的开源模型QWEN3-4B。所有与语言模型相关的组件——技能提取、状态摘要生成、动作规划、评估判断——都统一使用同一个骨干模型，确保对比公平性。

测试结果相当清晰。使用GPT-4.1作为骨干模型时，SGDR的平均任务成功率达到37.5%，而表现最好的对照方法CER只有33.9%，提升约3.6个百分点；与最弱的基线相比，提升幅度达9.7个百分点。使用轻量级的QWEN3-4B时，SGDR达到24.3%，超过CER的22.1%，提升2.2个百分点，相对提升幅度约10%。

从各网站域名看，提升最显著的是Admin域名——在GPT-4.1下，从ASI的41.4%跃升至SGDR的47.7%，接近七个百分点的绝对提升。购物、Reddit、地图域名也都有明显提升。唯一表现相对不突出的是GitLab域名，研究团队给出了合理解释：GitLab上的许多任务涉及仓库分叉、合并请求等操作，这些操作依赖特定的仓库前置状态，跨任务复用局部技能难度更大，更适合保留完整任务流程的方法。

除成功率外，研究团队还统计了平均完成任务所需的步骤数。SGDR在此指标上同样领先：使用GPT-4.1时平均仅需4.8步，而Vanilla需6.0步，CER需6.4步。步骤数减少的原因很直观——当AI助手调用一张技能卡片时，卡片中的代码可一次性执行多个原始操作（多次点击和填写），省去逐步摸索的过程，效率自然更高。

研究团队还绘制了随着任务流推进的“累积成功率曲线”，在四个域名下观察各方法随时间的变化趋势。总体而言，SGDR的曲线普遍高于其他方法，尤其在Admin和Reddit两个域名上优势明显，说明随着技能库不断积累，SGDR能更有效地利用历史经验改善后续任务表现。

六、拆解每一个设计选择——消融实验的逻辑

为验证SGDR每个设计选择的必要性，研究团队在Shopping、Reddit和Map三个域名上做了一系列“拆零件”实验，每次去掉或替换其中一个组件，观察性能变化。

首先是检索信号的消融。当仅使用任务目标（不考虑当前页面状态）来检索技能时，Shopping、Reddit、Map三个域名的成功率分别为30.3%、32.6%、30.8%。当仅使用当前页面状态（不考虑任务目标）来检索时，成绩更差，分别为28.4%、30.7%、29.6%。两者结合、各占一半权重时，成绩最高，分别为34.6%、35.9%、32.3%。该实验清晰表明：任务目标和页面状态这两条线索缺一不可。单独依赖任何一方，表现都比两者结合差，且偏向页面状态的单独使用比偏向任务目标更差。

接着是MMR重排的消融。当完全不使用MMR、只按相关性得分直接取前N名时，三个域名的成绩分别掉到31.1%、31.4%、30.8%，明显低于使用MMR时的表现。这验证了去重性的必要性——若不处理技能库里大量重叠的片段，检索结果会堆满高度相似的卡片，真正有用的多样化选项反而进不来。在不同MMR平衡参数λ下，λ=0.7（相对偏重相关性、兼顾多样性）表现最好。λ过大时多样性保护减弱，λ过小时相关性保障不足，两端都会导致性能下降。

最后是技能提取粒度的消融。用整条完整轨迹作为一张技能卡时，三个域名的成绩分别为31.1%、32.4%、28.8%；用单个动作作为技能单元时，成绩最差，分别为29.5%、24.7%、25.4%；使用滑动窗口提取的中等粒度技能时，成绩最高，分别为34.6%、35.9%、32.3%。这个实验印证了研究团队最初的直觉：太粗糙的技能复用率低，太细碎的技能无指导意义，只有恰到好处的“局部子程序”粒度，才能在复用性和表达力之间取得平衡。

七、真实技能长什么样——五个域名的案例展示

为让结果更直观，研究团队展示了从五个不同网站域名中提取出的真实技能案例。

在地图导航域名中，有一个任务要求查询从卡内基梅隆大学到匹兹堡社保局能否在一小时内开车到达。完成该任务后，SGDR从成功轨迹中提取出了一个驾车路线查询技能：接受起始字段ID、目的地字段ID、搜索按钮ID作为页面结构参数，接受起始位置和目的地字符串作为任务内容参数，然后依次填写两个输入框并点击搜索。这张技能卡片的关键特点是将“页面结构”和“任务内容”分开存储——未来遇到任何需要查询驾车路线的页面，只要从页面上识别出对应的输入框和按钮ID，就能直接调用该卡片。

在GitLab域名中，有一个技能负责在合并请求页面填写评论并提交：接受评论框ID、提交按钮ID和评论内容作为参数，填写后点击提交。在Reddit域名中，有一个结构几乎完全相同的技能，负责在论坛评论线程中回复：填写回复框并点击发布按钮。这两张来自完全不同网站的技能，展示了相似的“填写-提交”操作模式如何在不同网页上反复出现。

在购物域名中，有一个更复杂的技能，将搜索商品和添加到心愿单这两步操作合并为一个三步子程序：在搜索框填写商品名称，点击搜索，然后点击“添加到心愿单”按钮。这个例子说明SGDR能够提取多步骤的复合操作，不仅仅是简单的两步填写。

在后台管理域名中，有一个技能负责在订单详情页面选择快递公司：点击“添加追踪号”按钮展开界面，然后在下拉菜单里选择对应的快递公司名称。该技能使用了`select_option`操作（选择下拉选项），与前面几个主要依赖`fill`和`click`的技能形成互补，说明SGDR能覆盖多种不同类型的网页交互操作。

这些案例共同说明一件事：SGDR学到的技能始终保持着“结构参数”与“内容参数”分离的模式。结构参数（各类元素ID）从当前页面的可访问性树中读取，内容参数（查询词、评论内容、快递公司名称）从任务指令中提取。这种分离使得技能既能适应不同页面状态，又能响应不同任务需求。

说到底，这项研究做的事情，就是让AI助手不再“一条路走到黑”，而是在每一步都重新打量周围环境，再决定该用哪张“经验卡”。这听起来像理所当然的事情，但在实际系统设计里，能把这件事做好并不容易——既要保证技能的粒度合适（不能太粗也不能太细），又要让检索信号同时兼顾任务大方向和当前页面具体状态，还要解决技能库里大量重复片段带来的冗余问题。

这项工作的意义不仅仅是提升了几个百分点的成功率，更在于它指出了现有在线技能学习方法的一个系统性盲点：在任务级别做技能检索，是不够的。真正有效的技能复用，必须发生在操作的每一步，必须与当前的具体情境紧密绑定。

当然，这项研究也坦诚地指出了自身局限。实验仅在WebArena一个平台上进行，涵盖的网站类型和操作模式有限，在更广泛的网页环境中是否同样有效，有待进一步验证。此外，SGDR目前只是非参数化地积累和检索技能，没有探索如何将学到的技能融入模型本身的权重更新——这是一个有趣的未来方向。

对于好奇这个方向的读者，可通过arXiv编号2606.04391找到完整论文，代码也已开源。如果你感兴趣，不妨去看看他们实际提取出的技能代码长什么样——那些简洁的Python函数，读起来比想象中直观得多。

Q&A

Q1：SGDR方法和传统的网页AI技能学习方法有什么本质区别？

A：传统方法只在任务开始时根据任务说明检索一次技能卡片，之后整个任务过程中固定使用这些卡片不再更新。SGDR的核心区别在于，它在执行任务的每一步都会根据当前页面状态重新检索技能库，把“当前任务目标”和“当前页面状态”两条线索合并计算相关性，使得可用技能随着页面变化而动态更新，从而避免了任务初始选定的技能与后续页面状态不匹配的问题。

Q2：SGDR的滑动窗口提取是什么意思，为什么不直接存储完整的任务流程？

A：滑动窗口提取是指把一段完整的成功任务轨迹，用长度为2到5步的小窗口逐段截取，得到若干连续的操作小片段，每段代表一个局部子程序。不存完整任务流程的原因是，完整流程太过具体，只能在完全相同的任务起点复用；而单个动作又太细碎，没有指导意义。2到5步的小片段恰好对应“打开设置页”或“填写并提交表单”这类有意义的操作单元，既足够具体可执行，又小到可以在任务中途的任意状态被调用。

Q3：WebArena实验中SGDR在哪个网站域名提升最大，哪个最小，为什么？

A：提升最大的是后台管理（Admin）域名，在GPT-4.1下从41.4%提升到47.7%，接近6个百分点的绝对提升，原因可能是Admin任务中存在大量可复用的表单操作模式，适合局部技能的积累和检索。提升相对最小的是GitLab域名，因为GitLab任务常常涉及仓库分叉、合并请求等依赖特定仓库前置状态的操作，这类任务需要保留完整的任务级别上下文，SGDR学习的局部子程序技能难以充分覆盖这种依赖。