让AI手机助手学会反思：一个训练时代之外的可能性

你有没有遇到过这种情况：跟着导航软件走一条平时熟悉的路，结果导航还在提示老的转弯方式，可是那个路口早就改造了，红绿灯挪了位置，原来能左转的地方现在禁左。你只能临时改变主意，绕一圈找新路。

这其实就是今天所有GUI智能体（能够操作手机、电脑界面完成任务的AI程序）面临的核心困境。

**智能体面对的世界，从来不是静止的。**

弹窗会突然跳出来，页面加载会莫名延迟，按钮的位置说变就变。你给智能体规划好的一套操作步骤，可能在执行到一半时就彻底失效了。这篇来自浙江大学团队的论文，讲的就是如何让智能体在这样一个动荡的世界里，学会自己修正错误，而且是不需要重新训练模型的那种修正。

界面在变，智能体的"经验"却不会变

先说说现状。近两年，学界开始流行一个叫"智能体技能"（agent skills，把可复用的操作知识打包成结构化的知识块，供智能体在执行任务时调用）的概念。这个思路听起来挺聪明：与其让每个任务都从零开始摸索，不如把成功的操作流程记录下来，下次遇到类似任务直接拿来用。

问题是，现有的这些技能设计基本上都是"一次性生产、终身使用"的模式。

技能包做好之后，就变成了一个静态文件，供智能体在执行时参考。可如果这个技能包里记录的操作路径过时了怎么办？比如某个App改版了，原来"长按消息弹出回复选项"的操作变成了"点击右下角图标才能回复"，那这个技能包就成了一份错误的说明书，智能体反而会被它带偏。

论文作者归纳了现有技能框架的四个核心问题。

第一，技能通常写成一整篇长文档，规划步骤、定位提示、恢复规则全部混在一起，出了问题很难精准修改某一部分。

第二，界面本身是不稳定的，一个在某个状态下管用的技能，换个场景可能立刻失效，而这类"死循环式的失败"在真实部署里占了超时问题的相当大比例。

第三，很多系统依赖外部的大模型来做"反思"这件事，这不仅增加了延迟，还让反思和实际执行是两张皮，系统谈不上真正的自我进化。

第四，也是最可惜的一点，失败案例里其实藏着大量有用信息，比如哪个按钮的定位方式不靠谱、缺了哪个应急处理分支，但这些教训往往就锁死在某一次的执行记录里，没能变成可以复用的资产。

**你需要的不是一个更完美的静态技能，而是一个能从失败里学习、自己修正自己的活的知识体系。**

这就是论文提出EvoSkill-GUI这个框架的出发点。

把技能拆开来存，而不是塞进一个文件

第一个关键设计，是重新定义"什么是一个技能"。

传统做法是把一个技能写成一篇长文档，包含所有信息。EvoSkill-GUI则把技能拆成了六个独立的文件模块：检索用的元数据、可执行的计划文档、备用定位策略、失败恢复规则、辅助工具（比如读取界面结构的工具），还有失败案例库。

> 结构化技能包：把一个技能的知识拆解成计划（做什么）、备用定位（怎么找元素）、恢复规则（出问题怎么办）、失败案例等多个独立文件，而不是压缩进一整篇文档里。

为什么要这么拆？

设想一下你家里的工具箱。如果所有工具，螺丝刀、扳手、胶带、说明书，全部混在一个大袋子里，你想找一把十字螺丝刀，得把整个袋子倒出来翻半天。但如果工具箱是分格收纳的，螺丝刀在这一格，扳手在那一格，你要用什么直接拿哪一格就行。

论文里的做法本质上就是给技能"分格收纳"。当智能体在执行任务时发现某个界面元素找不到了，这明显是"定位"出了问题，只需要打开备用定位那个文件去修改，不用动其他部分。如果发现是整体的操作顺序错了，那就单独改计划文件。如果不做这种拆分，混在一起的文档每次修改都要担心改动会不会波及其他不相关的部分，改起来又慢又容易出新错。

论文的消融实验证实了这个设计确实有用：用结构化技能包时成功率是69.52%，改回单文件形式后掉到66.67%，差了将近3个百分点。

执行到一半发现不对，能不能马上改

第二个核心机制，论文叫它"即时修订"，也就是智能体在任务执行过程中，如果发现眼前的情况和技能包里写的计划对不上，可以立刻做局部调整，不用等到整个任务失败之后才去反思。

这个设计其实很好理解。

想象你正在照着一份菜谱做菜，菜谱上写"打开冰箱拿出鸡蛋"，结果你打开冰箱发现鸡蛋放在冷冻室而不是冷藏室。这时候你不会说"菜谱错了，我不做这道菜了"，你会当场调整，去冷冻室找。等做完整道菜之后，你才会考虑要不要把菜谱上"鸡蛋位置"这一条给改了。

**如果没有即时修订这个环节，一个小的局部偏差就可能滚雪球式地拖垮整个任务。**

论文的消融数据也印证了这一点：去掉即时修订后，成功率从69.52%跌到62.86%，掉了将近7个百分点。这说明，在长任务链条里，光靠一份固定不变的计划走到黑是靠不住的，弹窗、延迟加载、控件挪位这些干扰，几乎每次执行都可能遇上。

出了错，谁来判断问题出在哪

任务失败之后怎么办？EvoSkill-GUI这里的设计有点意思，它没有引入一个更强大的外部模型来当裁判，而是用同一个执行模型，扮演另一重角色，叫"批评者"（critic）。

> 批评者：在EvoSkill-GUI框架里指的是负责诊断失败轨迹的角色，由同一个backbone模型扮演，但运行在独立的会话中，只能看到执行过程中留下的客观记录（截图、操作日志），看不到智能体当时的思考过程或技能包本身。

这里有个很微妙的设定，叫"信息隔离"。批评者在诊断这次失败时，只能看到执行过程留下的痕迹，比如截图序列、具体做了哪些操作，但绝对看不到执行者当时脑子里是怎么想的、参考了哪个技能文件、更不知道任务的标准答案是什么。

为什么要这么严格地隔离信息？

这就像一个案发现场的独立调查员，不能提前知道嫌疑人的口供，也不能看到警方内部的推理笔记，只能根据现场留下的客观证据来还原真相。如果调查员提前知道了嫌疑人的说法，很容易被带偏，顺着对方的逻辑走，而不是真正独立地找出问题所在。

论文的消融实验显示，去掉信息隔离之后，成功率从69.52%掉到60.95%，跌了将近9个百分点，这是所有消融项里降幅最大的一项。可见批评者如果继承了执行者原本错误的思路，诊断质量会明显打折扣。

研究团队还专门人工审核了143条批评者给出的诊断意见，其中115条是准确的，占比80.4%。剩下的28条里，最值得注意的一类错误是批评者会误判失败为成功，导致任务被提前终止而没有继续修订。这提醒我们，即便是设计精巧的自我诊断机制，也不是万无一失的。

修改哪个文件，是有讲究的

批评者给出诊断之后，执行者会拿着这份诊断报告，通过一套受限的工具接口，去修改技能包里具体的文件。这套工具只允许读取、写入、追加、列出、搜索这几种操作，不能随意改动技能包结构之外的内容。

论文对不同类型的失败做了一个细致的可修复性分析，挺有启发。

计划层面的错误最容易被修复，23个案例里有16个通过修改计划文件成功了，修复率69.6%。定位失误的修复率降到50%，12个案例里修好了6个。而"缺少应急处理分支"这类问题最难修，4个案例只修好了1个，修复率只有25%。

这个数据其实揭示了一件挺实在的事：不同类型的错误，修复的难度天差地别。计划性的错误往往是"少做了一步"或者"顺序错了"，只要把这一步补上就行，逻辑清晰、边界明确。但缺少应急分支这种问题，本质上是要求智能体预判一种它之前完全没遇到过的意外情况，这种预见性的补全难度天然更高。

有了经验，下次能不能少走弯路

技能修好了之后，还需要能被找到、被复用，不然每次任务都从零构建技能包，等于白忙活。

论文设计了一套基于元数据的检索机制。

> 元数据：技能包中记录任务意图、所属App、平台、关键词等结构化信息的部分，用于快速匹配相似任务，而不需要读取整篇技能内容。

检索打分公式结合了词汇重合度和语义相似度，还加了对App匹配和关键词命中的加分项，同时对查询里那些技能包缺失的关键概念做扣分处理。这套机制和传统的全文检索相比，效果差距相当悬殊。

论文测试了12个MobileWorld里的技能复用案例，元数据检索的平均得分是0.88，全文检索只有0.41。在设定的检索阈值0.6之下，元数据检索12个案例全部命中，全文检索只命中了1个。

这就好比你在图书馆找书。如果书架上每本书都贴着写清楚"作者、类别、关键词"的标签卡片，你一眼就能锁定要找的那本。但如果没有标签，你只能翻开每本书的正文去搜索关键词，长篇小说里到处都是重复的词汇，"她说""他走进房间"这种句子到处都是，光凭文字重叠很难判断这本书是不是你要的那本。技能文件也是这样，长文本里表面词汇的重合，未必代表任务本质相关，结构化的元数据标签反而更精准。

数据说话：多个模型都吃到了甜头

理论说了这么多，实际效果到底怎样？论文在三个基准测试上做了系统验证，覆盖手机和电脑两大平台。

在MobileWorld这个手机使用基准上，效果相当亮眼。Claude-Sonnet-4.6从57.1%提升到67.6%，Qwen3.6-Plus从53.3%飙升到69.5%，涨了超过16个百分点。开源的小模型也没有落下，Qwen3.6-35B-A3B从32.4%提升到44.8%，MAI-UI-8B从29.5%提升到37.1%。

在AndroidWorld测试集上，两个不同的种子设置下分别提升了2.6%和6.0%。

桌面端的OSWorld基准同样有明显改善。GUI-Owl-1.5-8B模型的整体成功率从46.7%提升到54.8%，个别应用像VLC播放器的提升幅度高达42.7个百分点。Qwen3-VL-8B-Instruct模型的整体表现从23.8%提升到34.3%，涨了10.5个百分点。

**这种跨模型、跨平台的一致性提升，说明技能包提供的程序性指导，本身具备相当的普适价值，不依赖某个特定模型的能力上限。**

论文还做了一个挺重要的对照实验，把EvoSkill-GUI的三轮进化和普通的"多次独立采样后选最好结果"（pass@3）策略放在一起比较，在token消耗相近的前提下，前者达到69.5%的成功率，后者只有62.8%，token开销EvoSkill-GUI甚至还略低一些。这说明性能提升是真的来自反思驱动的技能进化，而不是简单靠多试几次撞出来的运气。

进化到第几轮就该停了

技能进化不是无止境的，论文观察到一个很实用的规律。

多个模型的进化曲线都表现出前几轮涨幅明显、后面逐渐趋于平稳的特征。研究团队专门把Qwen3.6-Plus拉长到五轮观察，前三轮成功率从56.2%涨到68.6%，累计涨了12.4个百分点，但第四轮和第五轮加起来只多涨了0.9个百分点。

这个规律其实挺贴近生活经验。学一项新技能的头几次练习进步最快，因为最明显的错误都被逐一发现和纠正了。练到后面，剩下的都是些细枝末节的打磨，进步速度自然放缓。论文因此把三轮进化定为一个性能和成本之间比较划算的平衡点。

技能库会不会越用越丰富

除了单次任务的修复能力，论文还关心了一个更长期的问题：技能库随着使用会不会持续积累价值，还是说每次都在推倒重来。

研究团队构建了一个232个任务的连续测试集，前116个任务用来构建技能库，后116个是相关的变体任务。结果显示，技能库确实在持续增长，从任务10时的9个技能，涨到任务110时的69个技能，进入第二阶段之后进一步涨到98个技能，复用率达到56.1%。

更有意思的是失败恢复分析：整体89次初次失败的执行里，最终有27次通过技能修订被救回来了，其中19次是靠复用已有的技能库完成的救援。

这说明技能库不是一次性用品，它更像是一个不断吸收经验、越用越顺手的知识积累系统。

写在后面

读完这篇论文，我印象最深的其实不是那些成功率提升的数字，而是"信息隔离"这个设计背后的判断力。

研究团队完全可以引入一个更强大的外部模型来当裁判，这样理论上诊断质量应该更高。但他们坚持用同一个模型扮演执行者和批评者两个角色，代价是牺牲了一部分诊断的绝对准确率，换来的却是整个系统不依赖任何额外资源就能自我进化的能力。这种取舍本身就是一种工程哲学：不追求单点最优，而是追求整体系统的自洽和可持续。

另一个让我意外的细节是不同类型错误修复率的巨大差异，计划错误69.6%对比缺少应急分支25.0%。这个数字侧面说明，让AI预见未曾遭遇过的意外情况，比修正已知的操作序列难得多。这某种程度上也是人类学习的规律，纠正已犯过的错误相对容易，真正难的是预判从未发生过的意外。

论文里那个OSWorld上出现的负面案例也值得琢磨：给已经能一步到位的简单操作套上复杂的技能指导，反而可能画蛇添足，多绕了几步弯路。这提醒我们，任何辅助系统都有它适用的边界，长流程、结构稳定的场景是它的主场，简单直接的任务未必需要这套复杂的脚手架。

一个训练时代之外的智能体，究竟能进化到什么程度，会不会有一天它积累的经验反而比我们手工设计的规则更懂这个不断变化的数字世界？

Q&A

Q1：EvoSkill-GUI是什么？

A：EvoSkill-GUI是浙江大学团队提出的一套训练免费框架，让GUI智能体能够在执行手机或电脑操作任务时，把执行失败的经验实时反思并写回结构化技能包里，不需要重新训练模型就能持续改进。

Q2：EvoSkill-GUI相比传统技能框架的核心区别是什么？

A：传统技能框架把知识写成一份静态长文档，用完就不再改动。EvoSkill-GUI把技能拆成计划、备用定位、恢复规则、失败案例等多个独立文件，并且能在执行过程中即时修订，失败后还会用同一个模型扮演独立批评者去诊断问题、精准修改对应文件。

Q3：EvoSkill-GUI在实际测试中效果如何？

A：在MobileWorld、AndroidWorld、OSWorld三个基准上都取得了明显提升，最高涨幅分别达到16.2%、6.0%和10.5%，并且对Claude、Qwen等多种不同规模的模型都有效。