乔治亚大学等机构联手打造"随机应变"的网页AI助手，让它学会边走边调整策略

这项由美国乔治亚大学、腾讯美国、纽约大学和香港理工大学联合完成的研究，于2026年6月以预印本形式公开，论文编号为arXiv:2606.04391。感兴趣的读者可通过该编号在arXiv平台查阅完整论文。

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

每天有无数人在网上完成各种繁琐的任务：在购物网站搜索商品、在后台系统更新订单信息、在论坛回复帖子、在代码平台提交合并请求……这些任务虽然看起来各有不同，但背后的操作流程往往大同小异。"打开设置页面"、"填写表单"、"点击提交"——这些步骤像是固定的舞步，反复出现在不同任务里。

近年来，研究者开始训练AI助手自动完成这类网页操作。这类助手被称为"网页智能体"（web agent），它们能够接收自然语言指令，然后在真实的网页环境里一步步点击、填写、提交，就像一个熟练的办公室文员。

问题在于，这些AI助手在处理新任务时，往往只能"从零开始"摸索。每完成一个任务，那些辛苦积累的经验就白白丢弃了。为了解决这个浪费，研究者提出了"技能学习"的思路：让AI把完成过的任务流程整理成"技能卡片"，下次遇到类似任务时，直接调用这些卡片，省去重复摸索的工夫。这个思路听起来很美，实际上已经有一些方法在探索——比如储存完整的任务工作流、把操作步骤转化为可执行的程序，或者检索过去的成功经验。

然而，现有方法都有一个共同的盲点：它们只在任务开始时查一次"技能库"，选好几张卡片，然后整个任务过程中就死守这几张卡片不放。这就好比一个厨师在进厨房前查了一遍菜谱，然后不管锅里发生了什么变化，都照着开始时定好的步骤机械执行——即便锅里的水已经烧干、食材已经焦了，也不重新查看该怎么调整。

这篇论文的研究团队把这个问题看得很清楚：网页操作的真实情况是动态变化的。任务刚开始时，你可能在首页；走了几步之后，你可能来到了一个下拉表单；再走几步，你可能进入了一个需要填写特定字段的对话框。每一步的"当前页面状态"都在变，适合调用的技能也在变。如果只在任务开始时选定技能、之后再不更新，那就会出现"技能与状态不匹配"的尴尬——开始时选的技能已经用不上了，而当前页面真正需要的技能却没被召唤出来。

这个问题就是这项研究要解决的核心矛盾：如何让AI助手在每一步操作时，都能根据"当前任务目标"加上"当前页面状态"这两条线索，动态地调取最合适的技能？

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

在回答上面的问题之前，研究团队还需要解决另一个基础难题：技能库里的技能应该有多"大"？

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

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

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

为了确保提取出来的技能真的能用，研究团队还设计了一个验证环节：把原始轨迹里对应的操作步骤替换成对这个技能函数的调用，重新在环境里跑一遍，看看结果是否仍然被判定为成功。只有通过这个替换测试的技能，才会被正式加入技能库。这道验证关就像菜谱在正式出版前必须经过试做测试——只有真正做出合格菜肴的菜谱，才值得收录。

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

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

有了颗粒度合适的技能库之后，研究团队还需要解决另一个问题：在AI助手完成任务的每一步，如何从技能库里找到最合适的那几张卡片？

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

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

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

为了解决这个"高度重复"的问题，研究团队引入了一个叫做"最大边际相关性"（MMR）的重排机制。这个机制的逻辑很直觉：每次选下一张卡片时，不仅要看它跟当前任务和状态有多相关，还要看它跟已经选出来的卡片有多大差异。相关性越高、与已选卡片差异越大，得分就越高。这样选出来的5张卡片，既保证了每张都切题，又保证了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个百分点；与最弱的骨干基线AWM相比，提升幅度更是达到了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找到完整论文，作者们也在GitHub上开放了代码，地址已在论文中给出。如果你感兴趣的话，不妨去看看他们实际提取出来的技能代码长什么样——那些简洁的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学习的局部子程序技能难以充分覆盖这种依赖。