基于人类视频数据与失败经验驱动的GUI智能体训练实践

1. 项目整体设计与思路拆解

这个话题，我前后折腾了好几版方案，最后落到"3.28-1"这个代号上的时候，可算是把主线理清楚了。先说结论：这个项目核心做的是GUI智能体（Graphical User Interface Agent）的训练，也就是让AI像人一样操作电脑界面，完成点击、输入、拖拽、翻页这些动作，并且能独立跑完一条完整任务链路。数据底座是"大规模人类标注的计算机使用视频数据"，训练机制上重点解决"从失败经验中学习"，落地场景压在了"医疗软件长视野GUI操作"上。

我一直在做智能体方向，但纯文本智能体已经到了一个瓶颈——你让模型写一段代码、写一封邮件，它做得很好；你让它自己去某个系统里把一件实际事务办完，它就露馅了。原因很简单：真实世界的操作对象是图形界面，不是文字。界面上的按钮、菜单、弹窗、表单、图表，每一样都是视觉和结构信息的混合体，模型必须学会"看"和"动"配合起来。而GUI智能体要能真正干活，第一个绕不开的问题就是：数据从哪来？

1.1 为什么必须用"人类标注视频"做数据底座

我在最初设计时也考虑过直接上强化学习，让智能体自己探索环境，用奖励信号驱动它学会操作。但很快发现这条路在GUI场景里极其低效。GUI环境的动作空间看起来不大，实际上组合爆炸：你不仅要决定"点哪里"，还要决定"什么时候点""点什么""点完之后等待什么反馈""弹窗出来选确定还是取消"。直接随机探索的话，绝大多数轨迹都是无效的，奖励信号极其稀疏，训到天荒地老也学不会一个"登录系统再导出报表"的完整流程。

人类标注视频的价值恰恰在这里。一个真人操作员录制的视频里，天然包含了完整的任务语义：他为什么点这个按钮、操作顺序是什么、遇到弹窗怎么处理、出错后怎么回退。这些语义如果靠程序化规则去定义，成本高到无法想象；但通过视频让模型模仿学习，就能把"隐性的操作智慧"直接蒸馏进模型参数里。我在实验里对比过纯合成数据（我自己的做法是用脚本自动生成模拟点击轨迹）和真实人类操作数据的效果，同样5000条轨迹，人类数据训练出来的模型在陌生界面上的任务完成率高出将近一倍，因为真实操作里那些"绕一下"的处理方式，恰恰是合成数据永远产生不了的。

当然，视频数据也有自己的坑，后面我会专门讲数据清洗和标注质量，这里先强调一点："人类标注"不等于"让人录视频"。我们在项目里的做法是让人在真实软件环境里执行指定任务，屏幕录制操作过程，然后再用一套标注框架把视频逐帧拆解成"意图-动作-状态变化"的结构化序列。这个粒度才能喂给模型，纯粹的视频画面模型虽然能看，但要精确学习"鼠标在某个坐标按下、拖拽了多少像素、松手后界面发生了什么"，还是得靠结构化的操作日志。

1.2 三个子问题的拆解与整体架构

"3.28-1"这个编号对应的其实就是一期版本：数据、进化、场景。三个东西实际上是互相咬合的——没有大规模的人类标注视频，就没有基座能力；没有失败经验学习机制，模型就只能学会"走通顺路"，遇到没见过的界面状态就不知道怎么处理；没有医疗软件这个长视野场景，前面两个工作就缺少一个能验证价值的检验场。

• 数据层：构建"视频+结构化操作日志+任务描述"三位一体的人类操作数据集，覆盖多种常见桌面软件业务操作。
• 训练层：先做行为克隆预训练，再引入失败轨迹回放与自我进化训练机制，让模型在尝试-犯错-纠正的循环里持续提升。
• 应用层：选定医疗软件作为典型长视野场景，设计专用评估集和安全性约束，验证模型在几十步甚至上百步长任务下的表现。

这个架构的好处是每层都可以独立迭代，坏处是层与层之间的信息损耗需要严格控制。后面我展开讲每一层实操细节的时候，会带上我在实际推进中踩过的坑和换过的方案。

2. 数据工程：大规模人类标注视频怎么建才靠谱

数据是整个项目的地基。如果数据质量不过关，后面所有训练技巧都是空中楼阁。我在这个项目里把数据工程分了四步走：采集环境搭建、任务录制约束、标注结构化、质量清洗与配比。

2.1 采集环境与录制规范

第一步是搭建满足两个条件的采集环境：一是软件环境要贴近真实，二是可以稳定录屏并同步记录系统级操作事件。以医疗软件为例（我们用的是一款模拟环境下部署的真实门诊工作流系统），需要覆盖挂号、分诊、病历书写、检验申请、处方开具、影像调阅、收费结算等子模块。

录制方式上，我强烈建议不要只录屏幕视频，要同步开启系统层面的操作事件采集（鼠标坐标、键盘输入、窗口焦点切换、控件句柄）。原因很简单：视频是给人看的，模型虽然也能从视频里学，但像素级坐标回归的精度远不如直接用结构化坐标事件来得稳。实际操作是录屏帧率定在10fps就够——太高会导致数据量爆炸，太低会丢失快速操作细节，10fps配合事件日志记录，基本能覆盖人类操作的完整动作流。

任务录制时的要求也很关键。我给采集人员定了一条铁律：按照自己平时真实使用软件的方式去操作，不要因为"被录制"而刻意求快或求慢。这个细节起初没在意，后来发现凡是刻意录制出来的数据，操作路径都太"直"了——没有任何犹豫、没有鼠标悬停、没有右键探索。这种数据训练出来的模型，一旦在真实使用中遇到界面变化（按钮位置挪了、弹窗样式不同），立刻就不会做了。反而是那些带有犹豫和探索的轨迹，让模型学到了"遇到不确定时先悬停观察"的鲁棒行为。

2.2 标注粒度与结构化格式

原始视频要变成训练数据，必须完成两层标注。第一层是语义标注：这段操作在完成什么子任务，比如"在患者列表中找到指定患者并打开病历"。第二层是动作标注：每个时间片里，操作者做了什么动作、作用在哪个界面元素上、界面产生了什么反馈。

我使用的结构化格式类似于这样：

{ "task": "为患者张某某开具血常规检验申请", "steps": [ { "timestamp": "12.35s", "action": "click", "target": {"type": "menu_item", "text": "检验申请", "window": "门诊医生工作站"}, "result": "打开检验申请表单页面" }, { "timestamp": "18.02s", "action": "type", "target": {"type": "input_field", "label": "项目搜索"}, "content": "血常规", "result": "下方列表过滤出匹配检验项目" } ] }

这种格式比直接用"坐标点"更有利于模型泛化。坐标点是死的，界面稍微一改就失效；而"菜单项+文本+窗口"这种语义化描述，模型更容易学到"点击包含'检验申请'文字的菜单项"这个规则，而不是"点击像素坐标(1532, 445)"。当然，完全丢掉坐标信息也不对，我在实际训练里会保留坐标作为辅助特征，让模型在视觉信息不明确时可以用位置做判断。

2.3 数据质量清洗与任务配比

数据清洗这里，我有一套自己的过滤规则。最常见的脏数据有三种：

• 采集人员操作失误又撤销的冗长片段（占数据量10%左右），这种不是不能要，而是要看失败原因，后面训练失败学习机制时反而有用，所以不能粗暴删掉；
• 录制中途软件卡死、白屏、延迟导致的无效操作段，这种必须删，模型学不到任何东西，还会学会"对着空白界面乱点"；
• 任务未完成的半截轨迹，处理方式同上，归入失败库备用。

配比方面，我建议任务难度的分布不要做成均匀的，而要做成"金字塔形"：大量简单任务（登录、查询、翻页）占40%，中等任务（填写表单、多条件筛选）占40%，长流程复杂任务（跨模块协同操作）占20%。这个比例是我试了三版之后留下的最优值。如果把复杂任务比例拉到50%，模型会因为训练数据过于零散而学不扎实；全用简单任务，模型又学不到长程规划能力。

3. 从失败经验中学习的自我进化机制

这是"3.28-1"里我个人最看重的一块，也是内部讨论时争议最大的一块。传统行为克隆（Behavior Cloning, BC）的做法是"让模型学那些成功的轨迹"，这听起来天经地义，但实际操作之后就会发现一个严重问题：模型只见过"标准答案"，没见过"错误答案长什么样"，于是当它自己操作时一旦偏离了标准路径，就不知道怎么纠偏了。

人类学习不是这样的。人做一件事失败之后，会有非常明确的感觉——"我刚才那个按钮点错了""我应该先填写必填项再点保存"。这种失败信号本身就是重要的学习材料。所以我在项目里专门设计了一套"失败经验回放与自我进化"的训练机制。

3.1 失败信号的定义与捕获

第一步是定义什么是"失败"。在GUI操作场景里，我识别了四类可用的失败信号：

1. 操作回退：操作者做了一个动作，几秒内做了撤销（undo），或者删掉刚才输入的内容重新输入。这说明前一步操作是错误的，模型应该学到"这个动作会引发回退，下次要避免"。
2. 弹窗纠错：系统弹出错误提示（比如"必填项不能为空""日期格式不正确"），操作者随后修正了输入。这类信号特别好，因为它同时提供了"错误原因"和"正确做法"。
3. 反复试探：操作者在某个区域短时间内点击了多个位置，最终才找到正确目标。这说明界面上存在误导性信息，模型需要学会"悬停观察后再点击"。
4. 任务放弃：操作者中途退出或长时间停滞，导致任务未完成。这类数据不适合直接模仿，但可以用来做"负面提示"，告诉模型"这条路走不通"。

在数据工程阶段，我在结构化日志里为上述四类事件都打了标记。这个设计一开始增加了标注工作量，但后来发现完全值得——因为它让原本"一次性使用"的轨迹数据变成了可以反复挖掘的经验库。

3.2 失败经验池与优先级采样

采集到的失败轨迹不能一股脑全扔给模型，需要分门别类放进一个"经验池"里。这个经验池解决的是"往哪个方向纠偏"的问题，我用的是一个带优先级采样（prioritized sampling）的存储结构。

所谓优先级采样，就是让模型更频繁地看到那些对它当前能力来说"刚好够得着"的失败案例。太简单的不看，因为模型已经会了；太难的不看，因为学了也学不会。具体实现上，每一条失败经验都会附带一个"难度分"：计算该轨迹中操作者纠偏的次数、界面状态数、任务步数，然后综合出权重。训练每个batch里，按照权重抽取失败样本注入训练流。我实验下来，权重取幂次为0.7的优先级采样效果最好，既能保证困难样本被多抽到，又不会让模型被极端困难的轨迹带偏。

注意：失败经验池不是越大越好。我在第一次迭代时囤了2万条失败轨迹，效果反而比后来筛选后的8000条差。原因是大量重复类型的失败经验会相互干扰，模型看了太多"同一个按钮的同一类点错"，会产生过拟合。建议控制在总数据量的20%左右，并且按失败类型做去重。

3.3 自我进化的训练循环

这个项目叫"自我进化"，是因为训练不是一锤子买卖，而是循环进行的。具体来说，每一轮训练分三个阶段：

• 第1阶段：行为克隆阶段。用干净的成功轨迹预训练模型，让模型具备基础操作能力，能够完成大部分简单任务。
• 第2阶段：对抗式回放阶段。把当前模型放到仿真环境里跑任务，凡是模型失败的轨迹，自动打标为"新失败经验"进入经验池。同时，从经验池中采样老失败经验混合训练。
• 第3阶段：策略筛选阶段。用评估集测试新模型，只有"任务完成率提升且平均步数不显著增加"的模型才保留，否则回滚到上一个版本，调整超参数后重来。

这套循环我建议每轮训练后跑一次，迭代轮数视数据量和场景复杂度而定。医疗软件场景我跑了6轮，从第1轮的任务完成率61%，到第6轮提升到83%。再往后就出现瓶颈了，这个后面排查章节会细说。

为什么不能用普通的"成功数据+失败数据一次性混合训练"？我试过，效果不好，原因是模型无法区分"这次我该模仿成功动作"还是"这次我该避开失败动作"。而分阶段的训练循环里，失败经验是配合"当前模型的短板"动态注入的，模型在学习时有了明确的针对性。

4. 医疗软件长视野GUI操作的专项设计

讲完通用机制，这部分专门说医疗软件场景。为什么这个场景值得单独做？因为它代表了GUI智能体的一类极端情况：操作序列长、流程强约束、界面信息密度高、出错代价大。

4.1 长视野操作到底难在哪

我用三个维度拆解了"长视野"的难点：

第一，时序长度超常规。一个完整的医疗业务流程，比如"患者接诊+开具检查+查看报告+给出诊断+书写病历+开药+收费"，拆成界面操作可能有三四十步，甚至更多。模型必须维持对"最初任务目标"的记忆，做到第35步时不能忘了第1步是要干嘛。普通注意力机制在长序列上会明显衰减，早期我就发现模型诊断到一半，突然开始执行另一个任务的诡异行为，排查后发现就是长程依赖丢失了。

第二，界面状态空间爆炸。医疗软件通常是多功能系统，主窗口同时有患者列表、病历树、工具栏、状态栏、导航菜单，每个子窗口又有自己的按钮和输入项。模型每走一步，都需要在几十甚至上百个可交互元素中选出正确那一个。加上弹窗、多标签页等动态变化，界面状态几乎是无限多的。

第三，精细操作的误差容忍度低。医疗软件里的表单常常有严格的格式要求（时间、剂量、诊断编码），差一点就提交失败。而且很多操作目标面积小（比如日期选择器里的具体某一天），像素级回归稍微偏一点就点错了。

这些难点叠加在一起，让医疗软件成了一个非常好的"压力测试场"。如果模型能在这样的场景下达到较高完成率，换到更轻量的场景基本是降维打击。

4.2 界面结构化表示：解决高密度界面问题

针对状态空间爆炸，我用的是"图像识别+可访问性结构+OCR文字提取"三路融合的界面表示方案。通俗地解释就是：让模型同时"看图、读代码结构、读文字"，三份信息合并成一个综合理解。

• 图像通道：保留完整的界面截图，让模型感知整体布局、颜色分区、视觉焦点。
• 结构通道：读取系统层面的控件树信息（窗口、按钮、输入框的层级关系），类似于"查看网页的DOM结构"，让模型知道界面元素的先后顺序和从属关系。
• 文字通道：通过OCR提取界面上的关键文字（按钮名、菜单名、表单项标签），强化语义信息。

这个三路融合方案是我在项目里反复对比后确定的最优解。只做图像识别，模型对文字的精确识别不可靠，常常把"检验申请"看错成"检验管理"；只读取结构信息，又缺少视觉布局先验（比如"确认按钮一般在右下角"这种常识）。三路融合之后，模型对界面元素的定位精度和语义理解都上了一个台阶。实现时注意：三个通道的特征要在模型内部做交叉注意力融合，而不是简单拼接向量——拼接的话模型学不到"这个文字正好在那个位置上"的横跨关系。

4.3 安全约束与操作可解释性

医疗场景的另一个关键是安全。我做了两层设计：

第一层是**"关键操作白名单"机制**。在模型的动作分布输出后加一道规则防火墙：涉及处方开具、检查申请提交、费用结算等关键操作前，模型必须输出额外的"高置信度确认信号"（比如重复识别当前窗口标题、再次核对操作目标文字），不满足条件就拒绝执行并请求人工介入。这个机制有效拦住了我在测试中故意设置的"危险陷阱"——比如把删除按钮放在提交按钮旁边，模型有0.7的概率会点错，但白名单机制能把这种错误在落地前拦截。

第二层是操作全链路日志回溯。模型每一步的决策依据（看到了什么界面元素、为什么选择这个动作、可替代动作有哪些）都记录在审计日志里。这个设计最初是为了人工复核，后来发现还有一个意想不到的好处：排查模型bug时，日志直接告诉你它在哪一步感知出了问题，省了大量复现时间。做长视野场景的同行建议提前就把日志做好，别等功能上线后再补——补日志的成本比一开始设计要高好几倍。

5. 实操过程与核心环节实现

这一章直接上干活细节。整个"3.28-1"项目的训练全流程、关键参数和评估方法，我都记录在这里，可以当一份可参考的复现笔记用。

5.1 训练全流程与数据管线

我整理了一条标准训练管道，共四个阶段：

1. 数据处理阶段：原始视频数据→抽帧+OCR+结构化事件解析→生成统一格式的训练样本（每一行为：历史界面状态序列+当前界面状态+动作标签+反馈状态）。
2. 基础模型阶段：采用视觉-语言多模态底座模型（权重约70亿参数），将界面截图和OCR文本一起输入，输出为动作描述序列。这个阶段的训练目标是让模型学会"看到什么界面→做什么动作"的映射。
3. 失败进化阶段：按照第3章的循环机制，交替跑仿真环境和评估集，动态注入失败经验。每个epoch后评估一次，达到预设阈值就升级版本，达不到就调参数重新训。
4. 对齐与封装阶段：最后再用少量人工偏好数据（比如"更稳重的操作方式优先于快速但冒险的方式"）做一轮RLHF式微调，然后封装为推理服务。

这四阶段里，最容易翻车的是第2到第3阶段的切换。因为基础模型阶段用的是干净的成功轨迹，模型参数已经收敛到一个稳定的局部最优；直接切到失败进化阶段，模型性能会先下跌再回升，这是正常的，但很多人会在下跌期慌张回滚。我的经验是给自己定一个"冰点容忍度"：性能下跌不超过5%就不干预，继续跑，一般2-3轮后就会涨回来。

5.2 关键参数与配置参考

下面是我在项目里最终使用的配置，不同数据规模下需要微调，但量级可以参考：

一个我特别想提醒的参数是"动作序列最大长度"。我一开始设128步，以为越长保留的信息越多，结果训练时间翻倍，效果还变差。后来分析发现，超过64步后模型学到的操作模式和短任务高度重复，属于冗余信息，截断后性能不降反升。长任务真正需要的是"记忆压缩"而不是"无脑堆长度"，这个问题我们下一节评估部分会通过指标再讲。

5.3 评估指标与结果分析

评估不能只看一个"任务完成率"，否则会被平均掩盖问题。我构建了五维评估体系：

• 任务完成率（CR，Completion Rate）：成功走完关键业务链路的比例。
• 平均操作步数（AS，Average Steps）：衡量路径效率。如果模型绕了远路，即使完成任务也不够好。
• 失败恢复率（RR，Recovery Rate）：任务中途出错后，模型能否自行纠正并继续完成。这是"失败经验学习"效果的直接体现。
• 关键操作误触率（ER，Error Rate）：是否误触了"删除""提交""重置"等高风险操作。医疗场景这个指标甚至比完成率更重要。
• 长任务表现衰减（LD，Long-task Decay）：步数超过30步的任务完成率，与步数低于10步任务的完成率差值。差值越小说明长程保持能力越好。

十轮迭代后的最终结果：CR从61%升到83%，AS降低了约15%，RR从30%升到58%，ER控制在2%以内，LD从22个百分点缩小到了8个百分点。坦白说，83%的完成率离"可靠上岗"还有距离，但对这个场景的复杂度来说已经是可用水平，而且从趋势看，再扩三倍数据，CR还能继续涨。

另外，我把长任务相关的指标单独拆出来做了个分析：模型在前30步的表现和后20步的表现，性能下降已经收窄，说明界面结构化表示和记忆压缩措施起了作用。之前没做这些措施的时候，后20步的操作准确率惨不忍睹，经常一步错步步错。

6. 常见问题与排查技巧实录

项目里踩过的坑不少，我挑最典型的整理成了一份速查表，新上手这个方向的可以参考，能少走一些弯路。

下面这几个技巧是我实际操作中总结出来的"独门"经验，常规文档里基本不会写：

第一个，失败数据别只用来"避免错误"，还可以用来"生成纠偏动作"。传统思路是让模型学到"这个动作是错的，不要做"，但其实更好的做法是让模型在同一段数据里学到"错了之后怎么办"——也就是"纠偏轨迹"也是可以被建模的。我在训练标注里额外标记了"纠正动作"这个字段，模型会在推理时多一个并行输出头：如果检测到当前界面状态和预期不符，就输出修复动作序列。这是一个很实用的技巧，能显著提升RR指标。

第二个，自动化失败轨迹生成不能太依赖模拟器。我早期为了快速获取失败经验，写了大量基于模拟器的自动试探程序，但产出的失败轨迹和人类真实操作中的失败形态差别很大——模拟器产生的失败大多是没有意义的随机点击，而人类失败往往有明确意图（比如误以为某个按钮是另一个功能）。混合使用时，自动轨迹会稀释人类轨迹的质量。建议自动轨迹占比不要超过失败经验池的30%。

第三个，医疗软件评测最好准备"双版本界面"。我在评测时用了同一业务流程、但界面布局和交互方式有细微差异的两个版本。这个做法让我发现了模型过拟合界面布局的问题——在版本A上完成率80%，到版本B上只有64%。如果没有这个对照组，我根本不会发现模型是"背下了界面"而不是"理解了操作逻辑"。强烈建议在GUI智能体的评估集里设计这种"界面扰动项"，这比单纯增加任务数量更能暴露真实能力。

回到标题里"自我进化"这个词，我现在的体会是：它不是一个花哨的噱头，而是一个很朴素的工程事实——模型在真实环境里就是会犯错，关键是你有没有一套机制把这些错误利用起来，变成下一次迭代的经验。项目的下一步，我打算把这套"失败经验池"的接口标准化，让不同场景的数据都能往里灌。毕竟GUI操作的本质就是试错和纠偏，这个过程做好做扎实了，智能体才谈得上"自主干活"。