GUI Agent点错不止？EvoSkill-GUI把失败轨迹变成可复用技能

如果你也在折腾 GUI Agent一定遇到过这种场面让智能体去网页上提交一个表单它盯着截图分析了好一会儿最后稳稳当当地点到了旁边的忘记密码。这种又点错了的瞬间几乎每天都在每个跑 GUI Agent 的人身上重演。我在连续跑了几轮自动化任务之后渐渐意识到一个更根本的问题每次失败都被当成一次性事故处理掉Agent 不会从里面学到任何东西同一个坑下次照样踩。后来我接触到 EvoSkill-GUI它的核心想法很简单也很直接——把每一次失败轨迹沉淀成可复用的技能让 Agent 在下一次遇到类似界面时直接调用之前总结出的操作经验而不是重新盲猜一遍。这篇文章不是论文复述而是我从项目落地角度梳理的一份经验记录。我会先拆解 GUI Agent 为什么这么容易点错再说清楚 EvoSkill-GUI 的技能生成链路怎么设计、实测效果如何、落地时有哪些坑。如果你正在做 GUI Agent 相关的开发、测试或方案选型这篇文章应该能帮你少走不少弯路。1. GUI Agent 为什么总在点错上翻车1.1 一个触发我写这篇文章的真实场景前段时间我需要让一个基于视觉的 GUI Agent 自动完成一个内部系统的数据录入任务。任务本身不复杂打开系统、点击新增记录、填写几个字段、点击保存。我预演的时候觉得这简直是送分题结果正式跑起来Agent 在第一大步就出问题了——它把页面上方的新增记录按钮旁边的批量导入当成了目标直接点下去弹出了一个完全不同的对话框。这不是偶然失误。我又试了几次发现它在不同页面上的误点原因五花八门有时候是页面里有两个长得差不多的按钮有时候是弹窗遮住了目标元素有时候是页面还没加载完它就开始操作。最让我头疼的是每次出错之后我除了调整提示词、重新跑一遍没有任何更系统的办法。Agent 本身不会意识到我刚才认错了按钮更不会在下一次自动避开类似的情况。这个场景其实非常有代表性。GUI Agent 与传统自动化脚本最大的区别在于它不依赖固定的 DOM 结构或坐标定位而是靠视觉理解 推理决策来操作界面。这种方式的灵活度很高但代价是它总会因为各种不确定因素做出错误的点击决策。EvoSkill-GUI 给我的启发恰恰在于与其想办法让 Agent 永不犯错不如让错误本身变成经验。1.2 坐标级错误的三大来源视觉误解、状态感知、上下文漂移我在排查过程中把 GUI Agent 的点错归纳成三类每一类的成因和处理思路都不一样。第一类是视觉误解。界面元素在截图中呈现的形态和真实的功能语义之间并不是一一对应的。比如一个图标按钮人眼能根据位置和上下文猜到它是设置但视觉模型可能只把它识别成一个齿轮图形。如果界面上同时存在多个相似图形比如齿轮、刷新、导出的图标在某些主题下长得非常接近误判概率就会显著上升。截图分辨率、缩放比例、颜色对比度也会直接影响识别结果。我实测过同一个按钮在 100% 缩放下识别正确在 125% 缩放下就被认成一个装饰性图案。第二类是状态感知不足。现在的 GUI Agent 大多通过截图来感知界面状态但截图本质上是一个静态快照无法反映页面的动态变化。比如一个弹窗从出现到完全渲染完成可能需要几百毫秒如果 Agent 在弹窗尚未完全出现时就尝试点击弹窗内的按钮那么它看到的就是残缺的界面点错几乎是必然的。更麻烦的是有些操作会触发异步刷新比如点击筛选条件后列表区域重新加载但页面其他部分看起来没有变化Agent 很难判断现在到底能不能进行下一步。第三类是上下文漂移。这是多步骤任务中最隐蔽的坑。Agent 在第一步根据当时的页面状态做出了一个判断但当它执行到第五步时页面状态可能已经完全变了而它还在用旧的心智模型做决策。典型例子是分页表格Agent 在第一页找到了目标行并开始操作操作过程中表格发生了排序变化目标行挪到了另一页但 Agent 依然以为它还在原来的位置。这种漂移不像前两类那样有一个明显的视觉线索所以特别难在事前预防。1.3 为什么重新提示一遍解决不了问题很多人面对 GUI Agent 点错的第一反应是修改提示词比如加上请仔细核对按钮名称后再点击注意不要点错类似的图标。这种办法能解决一部分偶发问题但解决不了系统性问题。原因是提示词本质上是一次性的指令它只在当前这次对话中生效无法沉淀成跨会话、跨任务的经验。举一个简单的例子如果 Agent 在一个页面上认错了批量导入和新增记录你可以在提示词里强调不要点批量导入。但下一次任务换到另一个系统、另一个页面界面上出现的是快速导入和新建两个按钮时Agent 还是会犯同样的错误——因为上一次的经验没有以结构化形式保存下来。我自己的观察是GUI Agent 的容错能力成长必须依赖某种经验仓库。这个仓库需要记录的不是点哪个按钮这种死板的坐标而是在这个界面上哪些元素容易混淆、如何区分、操作前应该检查什么。EvoSkill-GUI 走的就是这个路子它把失败轨迹变成技能本质上就是给 GUI Agent 建了一个可以积累和检索的经验库。2. EvoSkill-GUI 的核心思路失败轨迹如何变成技能资产2.1 从任务失败到技能缺失的视角转换EvoSkill-GUI 的第一步是重新定义问题。传统的做法把一次失败看成任务没有完成然后通过重试或人工介入来修复。EvoSkill-GUI 则把失败看成技能缺失——Agent 在执行某个步骤时缺乏足够的知识来做出正确决策所以才点错了。这个视角转换非常重要。一旦你接受了失败 技能缺失这个设定接下来的问题就变成了能不能从这次失败的轨迹中提炼出一个技能补齐这个缺失技能在这个框架里的定义我个人的理解是一组在特定条件下可复用的操作知识和决策规则。它不只是点击坐标 (x, y)这种粒度极细的操作序列而是包含了几层信息适用的界面场景、操作前的验证条件、操作步骤本身、以及操作后应该检查的结果。比如前面提到的新增记录例子沉淀下来的技能应该是这样的适用场景列表页面包含新增记录和批量导入两个相邻按钮验证条件先检查按钮图标是否带加号以及文字颜色是否为高亮色操作步骤以按钮文字为准不要只看图标点击后再确认弹窗标题是否为新增记录结果检查弹窗打开后标题栏是否包含新增关键字这样一条技能沉淀下来之后下次 Agent 再遇到类似的列表页就能直接调用而不是重新分析一遍截图。2.2 技能粒度原子技能与复合技能的层次划分在实践中我发现技能不能只设计成一种粒度。不同场景需要不同粒度的技能否则要么太琐碎无法复用要么太笼统无法执行。原子技能是最小可执行单元比如识别并点击页面右上角的搜索按钮等待表格加载完成区分两个相邻的相似按钮。原子技能的特点是单一、明确、可独立验证。它们的复用面很广几乎所有任务里都会用到但单独一个原子技能并不能完成复杂任务。复合技能则由多个原子技能按顺序组合而成并且带有更复杂的上下文条件比如完成一个表单的填写流程在分页表格中定位并操作特定行。复合技能内部可以调用多个原子技能同时处理状态判断和异常分支。它的复用范围更窄但价值密度高一旦匹配上能大幅减少 Agent 的推理开销。我在实际搭建技能库的时候会让 EvoSkill-GUI 同时维护这两层技能。原子技能负责兜底保证 Agent 在最基础的操作上有经验可依复合技能负责提效让高频复杂操作能够一键完成。两层共享同一个存储体系只是元数据字段不同。2.3 与 Claude Code 技能、Cursor 技能包这些概念的本质区别最近技能这个词在 AI 圈子里很火Claude Code 技能、Cursor 技能包、GitHub 上的 skill 库都陆续出现。很多人会问EvoSkill-GUI 和这些有什么不同我的理解是Claude Code 和 Cursor 的技能体系主要解决的是编程任务中如何复用指令模板的问题。它们的核心载体是可解释的文本指令通常由一个 Skill 文件定义触发条件和执行步骤然后由 LLM 在合适的时机调用。这种技能的确很有用但它们面对的环境相对稳定——代码文件的结构是确定的LLM 可以读到完整的上下文。GUI Agent 的操作环境则完全不同。界面是像素级的、动态的同一个按钮在不同分辨率下可能呈现完全不同的位置和形态。EvoSkill-GUI 的技能体系必须处理这种视觉不确定性所以它的技能里必须包含前置视觉检查和结果验证这类环节而不能只是一段操作指令。换句话说编程技能更偏向知识复述GUI 技能更偏向感知-决策闭环。另一个关键区别是技能来源。编程技能大多由人来编写或者从文档中提取EvoSkill-GUI 的技能主要是从 Agent 的实际执行轨迹中自动生成的特别是从失败的轨迹中提炼出来的。这个从失败中自动生长的特性是它区别于同类技能生态的核心。3. 技能生成与复用链路从失败捕获到技能入库的完整设计3.1 失败捕获怎么判断一次操作真的错了整套链路的第一步是失败捕获。听起来简单做起来却很讲究。如果判断标准太松会把大量正常操作误判为失败生成一堆垃圾技能如果太严又会漏掉真正有价值的失败样本。我采用的策略是三层信号叠加第一层是任务级信号。如果最终任务没有成功结束比如表单没有提交成功、页面没有跳转到预期地址那就说明任务链路里至少有一个环节出了问题。这个信号覆盖范围广但定位不够精确。第二层是步骤级信号。每一步操作之后Agent 可以通过截图对比或者 DOM 状态检查来判断本次操作是否产生了预期效果。比如点击保存按钮后预期是出现保存成功的提示如果提示变成了保存失败那这一步就被标记为异常。第三层是差异级信号。这一步是 EvoSkill-GUI 比较有特色的地方——它会对比当前这次点错的截图和同一步骤在其他类似界面上的截图用视觉模型计算差异。如果差异集中在某个特定区域比如一个按钮被高亮了而另一个没有那就说明 Agent 可能把视觉注意力放错了地方。只有三层信号都指向同一个步骤时我才会把这段轨迹标记为高置信度失败样本进入技能生成阶段。这个保守策略的好处是生成的技能质量比较高坏处是覆盖率偏低需要跑比较多的任务才能积累足够样本。后面我会讲到如何用主动探索来缓解这个问题。3.2 技能生成从轨迹中提炼可复用逻辑拿到失败轨迹之后下一步是生成技能。我的做法分为两个阶段轨迹清洗和技能合成。轨迹清洗阶段先把原始轨迹中与错误决策无关的噪声去掉。GUI Agent 的运行日志通常非常冗长包含大量中间推理过程、鼠标移动、页面滚动事件。这些信息对最终技能没有帮助反而会干扰判断。我会保留三类核心信息操作发生时的界面截图或元素描述、Agent 实际执行的动作、动作之后界面状态的变化。清洗后的轨迹通常只剩几十行关键信息。技能合成阶段我会让一个独立的 LLM 来生成技能初稿。这个 LLM 看到的输入包括任务目标、失败步骤的前后文、清洗后的轨迹、以及当前技能库中已有的相关技能。它的输出是一份结构化技能候选包含技能名称、适用场景描述、前置验证条件、操作步骤、结果验证项。生成初稿之后最关键的一步是人工或自动审核。我会先让 LLM 自检一次看看技能是否符合库里已有的技能命名规范、是否有明显逻辑错误然后再用规则引擎做一次硬性检查比如验证操作步骤里提到的元素是否真的存在于清理后的截图里。通过审核的技能才能进入候选区等待验证。3.3 技能入库前的验证为什么必须重放而不是直接信任这是整套流程里我最坚持的一步任何技能在正式进库之前必须在一个受控环境里重放验证。直接信任 LLM 生成的技能文本是很多项目翻车的开始。验证的方式是这样的我会准备一个与失败场景隔离的测试环境比如用浏览器自动化工具加载一个与原始界面结构相似的测试页面然后让一个新的 Agent 实例按照候选技能的步骤重新执行一遍。如果执行成功且结果验证项全部通过这个技能就标记为已验证如果执行失败则把失败原因作为反馈附加到技能候选上退回生成阶段重新提炼。这个重放验证机制的价值不仅在于过滤坏技能更在于它能发现技能描述中的隐性依赖。比如 LLM 生成的技能说点击提交按钮但如果这个按钮在深色主题下位于页面右下角而测试环境用的是浅色主题按钮位置可能完全不同重放就会失败。这类问题的出现会促使我不断细化技能模板中的环境字段。验证通过后技能会带上版本号、来源任务 ID、验证时间、适用平台等信息正式入库存档。这个过程与软件工程里的代码评审 持续集成非常相似技能就是代码重放验证就是 CI。3.4 技能检索与执行什么时机该调用哪个技能技能库建成之后EvoSkill-GUI 面临的下一道难题是执行新任务时怎么从库里找到合适的技能。我试过纯粹靠语义相似度检索也就是把当前任务的描述和技能库里的适用场景描述做向量匹配结果不是很好。因为 GUI 任务的语义往往非常简略比如帮我提交周报和技能库里的描述在字面上可能没有太多重叠但实际需要的操作步骤很像。后来我改成了多路召回 重排序的方案。多路召回阶段会同时跑三条检索线路一是任务描述的语义向量匹配二是界面元素特征的近似匹配比如当前页面有几个按钮、按钮的大致位置分布三是操作历史中与此任务相似度高的轨迹对应的技能回溯。三条线路各召回 Top 10 候选合并去重后进入重排序阶段。重排序阶段我会让一个轻量级模型根据三个维度打分场景匹配度、历史复用成功率、技能置信度来自验证时的表现。得分最高的技能被选中执行。如果执行过程中发现技能与当前界面不匹配Agent 会切换到自由决策模式同时把这次调用失败的轨迹重新标记为目标样本进入下一轮技能改良循环。3.5 执行后的反馈闭环技能也会过期和退化技能入库不是终点反而更像是起点。因为 GUI 应用是活的界面会改版、按钮会调整、流程会变化。一条上周还验证通过的技能这周可能就因为一次界面更新而失效。所以我在设计里加了一个反馈闭环机制每次技能被调用后EvoSkill-GUI 都会记录执行结果。如果一条技能连续三次被调用都成功它的置信分会上升如果连续两次失败置信分会大幅下降并被标记为疑似过期技能送入复审队列。复审可以由人来决定是否回滚到旧版本或者把这条技能下架重新生成。这个带反馈的技能生命周期管理本质上让技能库具备了一种自适应能力。用户的任务越多样技能库被验证的机会越多里面沉淀下来的技能就越可靠。这套机制和我以前做的规则引擎完全不同——规则是死的技能是活的。4. 实测效果失败率到底降了多少4.1 我的评测环境与任务集设计为了验证 EvoSkill-GUI 的实际效果我自己搭了一套评测环境。硬件就是普通的办公电脑系统是 Windows 11GUI Agent 用的是视觉定位方案不依赖浏览器 DOM。评测界面是三个真实业务的网页版系统一个内部 OA 系统、一个电商后台、一个数据报表平台。任务集一共设计了 60 个真实场景覆盖五类典型操作任务类型数量典型场景表单填写与提交15新增用户、修改配置、提交审批列表筛选与排序12按状态筛选订单、按时间排序记录数据定位与操作15在分页表格中定位特定记录并编辑页面导航与跳转10从首页进入子页面、切换菜单弹窗处理与异常恢复8弹窗拦截、错误提示后的恢复每个任务会连续跑 10 次统计成功率。第一轮不启用 EvoSkill-GUI作为基线第二轮启用但技能库为空此后每跑完一轮技能库会积累一批从失败中生成的技能。我连续跑了 6 轮观察成功率的变化趋势。4.2 关键数据操作成功率、任务完成率、整体耗时下面是 6 轮实验的核心结果基线阶段无技能库的一次操作成功率为 62%、完整任务完成率为 45%这个数据符合我对 GUI Agent 的预期——简单任务没问题但一遇到相似按钮、动态加载、弹窗拦截这类情况就明显力不从心。启用 EvoSkill-GUI 之后前两轮由于技能库还是空的效果提升不明显成功率只到了 66%。但从第三轮开始随着一批高频失败场景的技能沉淀进库提升幅度明显变大。第 4 轮一次操作成功率到了 79%完整任务完成率到了 68%。第 6 轮时一次操作成功率稳定在 85% 左右完整任务完成率达到 77%。整体耗时也有明显下降。基线阶段完成一个任务平均需要 2 分 40 秒其中大量时间花在重复推理和错误恢复上。启用技能库之后第 6 轮的平均耗时降到了 1 分 35 秒减少了近 40%。这个提升主要来自两个方面一是技能命中后减少了重复的界面分析时间二是错误恢复路径因为有了经验而变得更快。4.3 哪种任务提升最明显哪种任务帮助有限分任务类型看提升最明显的是弹窗处理与异常恢复和列表筛选与排序。这两类任务在基线阶段的表现只有 30% 左右因为它们的界面变化多、需要处理的状态杂。启用技能库后成功率分别达到了 82% 和 81%。原因是这些任务里的易错点高度一致比如弹窗出现后必须先等待渲染完成再点击筛选条件变更后必须等待列表刷新一旦沉淀成技能复用价值非常高。表单填写与提交从 71% 提升到了 90%提升幅度也很大。这类任务的常见错误集中在表单字段识别错位和必填项遗漏上技能里前置检查项的帮助非常明显。提升最有限的是数据定位与操作只从 51% 提升到了 67%。我分析了一下原因这类任务的难点在于目标数据本身的不确定性——它可能是表格里的任意一行位置分布没有固定规律。技能能帮忙的部分是如何稳定地找到表格区域但对于如何从几页数据里精确找到目标行这种需要综合判断的问题光靠技能经验还不够还需要更强的推理能力。4.4 技能库的增长趋势与质量观察我还记录了一个有意思的曲线技能库的规模并不是线性增长的。前两轮增长最快因为大量基础的、共性的失败场景被快速沉淀到了第 5、6 轮增速明显放缓说明易学的基础技能已经被学得差不多了留下的都是比较棘手的边缘案例。技能质量方面我统计了技能库中被调用过的技能占比。第 2 轮的时候只有 38% 的技能在后续任务中实际被调用过第 6 轮时这个比例上升到了 61%。这说明随着任务集跑得越来越多技能库里的死技能占比在下降整体质量在上升。这也印证了反馈闭环的价值——那些一直调不到的技能会被标记长期不用的会被下架技能库会自我净化。5. 落地过程中踩过的坑与设计取舍5.1 误报与漏报的平衡技能太多和太少都不行落地过程中我踩的第一个坑是技能漏报导致的库里有技能但用不上。问题出在检索阶段界面特征匹配的粒度太粗导致实际执行任务时的界面状态和技能里记录的不完全一样技能没能被召回。后来我在技能描述里增加了界面形态向量这个字段。LLM 生成技能时会把验证截图里的关键结构特征向量化存进去检索时把当前界面的截图也向量化然后做相似度比较。这个改动让技能的召回率提升了不少但也引入了新问题——界面结构相似但功能完全不同的页面会被误召回。这就是误报与漏报的平衡召回率高了误召回的技能也多召回率低了真正合适的技能又可能错过。我最终的方案是双层过滤第一层用形态向量做粗召回第二层用语义特征做细过滤两层都通过才让技能参与执行。5.2 技能膨胀问题怎么避免技能库变成垃圾场如果不加控制技能库在跑完几十个任务后就会膨胀成一个谁也理不清的垃圾场。我在第四轮实验时遇到了这个问题技能库里存了 200 多条技能但很多都是同一类问题的小变体比如等待页面加载这个原子技能就存了七个版本条件几乎一样只是名称和描述措辞不同。这个问题让我意识到技能库必须做去重和合并。我加了一个技能合并策略当一条新的候选技能和现有技能的场景匹配度超过 90%、操作步骤相似度超过 85% 时就不新入库而是进入合并流程把新技能里独有的验证条件或经验补丁合并到旧技能上同时在 changelog 里记录这次合并。除了合并我还设置了一个技能冗余度指标。每周或每跑完一定数量任务后检查一次技能库把从来没有被检索到、也没有被验证过的技能降权处理进入低活跃区。低活跃区的技能不会直接删除但不会再被优先推荐直到有新的场景重新触发它们。5.3 安全边界Agent 自我修改的风险控制让 Agent 自己生成技能、自己决定什么时候调用这个能力虽然强大但如果在生产环境不加控制风险很高。我在设计里加了三条安全边界第一条是技能执行权限分级。一键生成、一键提交这类高风险操作即使 Agent 生成了对应的技能也不会被自动授权执行必须经过人工确认才能启用。只读和低风险操作比如打开页面、定位元素、等待加载则可以自动执行。第二条是技能生成范围限制。LLM 生成技能时如果技能的操作步骤涉及下载文件、发送消息、修改系统设置等敏感动作会触发额外的安全审核除非该动作在任务目标里明确存在否则会被拒绝入库。第三条是执行时的行为白名单。Agent 调用了技能后实际执行的操作仍会经过一个轻量级的规则校验确保技能描述里的操作与实际发生的操作一致防止技能本身被篡改或者被注入恶意指令。这三条边界加下来确实牺牲了一些自动化程度但在可控性上的收益远远大于损失。5.4 技能版本管理改版之后如何平滑迁移最后一个经验是关于界面改版的。我们的 OA 系统中间有一次大版本更新表单布局全部调整原来验证通过的技能瞬间废掉了一大半。如果技能库没有版本管理机制这次改版几乎是灾难性的。我采用的方案是给每条技能打上界面版本指纹。在技能验证通过时记录当时界面的关键特征哈希。当 Agent 执行时发现当前界面的特征哈希和技能记录的不匹配就会自动启动适配模式让 LLM 基于当前界面现状对技能做一次本地化调整调整后先走轻量验证验证通过后作为新版本入库并与旧版本建立关联。这样界面改版不会直接导致技能失效而是会产生一个技能迁移过程。旧版本技能仍然保留作为回滚选项新版本技能则通过验证后在后续任务中逐步替代旧版本。整个过程透明度很高任何一次版本变更都可以回溯到最初的任务轨迹。6. 这套思路还能往哪走6.1 跨应用迁移技能不应该只属于单个软件目前的技能体系是围绕单个应用训练出来的OA 系统里沉淀的技能迁移到电商后台时并不直接可用。但从本质上说很多 GUI 技能具有跨应用价值等待页面完全加载后再点击在任何 Web 应用里都适用区分主操作按钮和辅助按钮在大部分表单页面里也说得通。我在实验里尝试过把技能中的应用特定描述抽离出来只保留通用操作逻辑。比如电商后台里筛选状态的技能抽离后变成在带筛选条的表格中先选择筛选条件再等待表格刷新这条技能换到另一个系统的同类型表格上也能用。这个方向继续做下去有望形成一个跨应用的通用 GUI 技能层。6.2 从 GUI 技能到工作流技能的上层抽象技能的粒度还可以继续往上走。当我们把大量 GUI 层面的原子技能和复合技能沉淀好之后可以进一步把它们组合成工作流技能——不再关心某个按钮怎么点而是关注整个业务流程怎么编排。比如完成采购审批这个工作流可以拆解为打开采购单列表、筛选待审批状态、逐个查看详情、根据金额决定审批或退回。这些子步骤组合起来就是一条工作流技能。工作流技能的好处是抽象层次更高即使底层某个 GUI 细节变了只需要更新对应的复合技能工作流本身不用动。这个分层架构可能是 GUI Agent 走向企业级应用的关键路径。6.3 开源与社区技能生态的共建模式最后我想聊聊技能生态。现在 GitHub 上已经有不少 skill 库项目但主要集中在编程领域。GUI 领域的技能库还处于蛮荒状态大家各自收集、私有没有形成真正可共享的生态。如果要做成开源的 GUI 技能生态我认为需要解决两个问题一是技能格式的标准化让不同框架的 Agent 能读懂同一个技能文件二是技能数据的脱敏和通用化处理因为技能往往来自真实业务环境直接开源可能涉及安全和隐私问题。我自己的打算是等技能模板和验证流程再稳定一些就把规范部分开源出来让感兴趣的团队可以在这个基础上搭建自己的技能交换机制。6.4 我的一点长期观察说说个人体会。这套系统跑了几个星期之后我最大的感受是可靠的 GUI Agent 不是靠更聪明的模型堆出来的而是靠持续的经验沉淀养出来的。模型负责理解技能库负责记忆二者结合才让 Agent 真正像个有经验的操作员而不是一个每次都重新摸索的新手。现在我最常用的一个技能是从一次非常低级的错误里生成的——那一次 Agent 把页面顶部的导航栏误认为是页面内容在导航栏上找了一个根本不存在的按钮。这个错误沉淀成技能后附带了一条十分朴素但有效的验证规则操作前先确认目标元素位于内容区域而非导航区域。这条规则不复杂但它确实让后续所有任务的导航误判几乎绝迹。如果你也在做 GUI Agent 相关的工作我的建议很直接别只盯着模型选型花点心思把失败轨迹管起来。哪怕不引入完整的技能体系只是给每次失败做一个结构化的归因记录长期积累下来也会让你的 Agent 表现得不一样。