给 GUI Agent 演示一次，然后验证它学到的是流程

有些桌面流程，演示一遍比写成说明更容易。“按运营团队的习惯准备续约材料”这句话背后，可能藏着文件命名规则、表格筛选条件、复核节点、指定软件，以及一条关键边界：Agent 只能保存草稿，绝不能代替员工发送。长提示词可以逐条列出这些要求，而录屏能把它们放回真实界面和操作顺序中。

新发布的 UI-Mate 技术报告与开源仓库把这件事做成了具体机制。系统可以读取一段成功的桌面操作轨迹，把它标准化、拆成带目标与完成条件的子任务，再交给专门支持演示的 GUI Agent。它不是照着旧坐标执行宏命令；当前屏幕才是权威状态，Agent 理应复用流程，同时适应眼前的界面。

“迁移流程”比“复现演示”更有产品价值，但也更难证明。

UI-Mate 报告称，在 33 个“同任务演示”测试中，为同一个支持演示的模型加入一次演示后，严格成功率从 17.17% 提高到 35.35%。这个结果值得关注，但边界必须和数字放在一起：演示来自更强 Agent 对同一个目标任务的成功运行；即使加入演示，仍有接近三分之二的试验没有达到严格成功。论文也描述了“人类演示相似但不相同任务”的另一组材料，不过仓库目前仍把 OSWorkerBench 的任务、演示、元数据和校验器标记为“即将发布”。

因此，小团队今天不该问“单次演示学习是否有效”，而应问：

演示是否真的帮助 Agent 提取了可迁移流程，还是因为测试环境与录制时太相似，才看起来有效？

本文给出一套配对迁移测试。Y Build 没有运行 UI-Mate，也没有执行下文虚构产品的试验。协议、阈值和空白结果字段都是建议，不是我们的实测；论文与发布团队的数据始终保留原始归属。

这次发布改变的是实验方法，不是上线结论

普通的计算机操作 Agent 接收文字任务，观察屏幕截图，再输出鼠标和键盘动作。演示驱动 Agent 多了一份输入：一段过去成功完成任务的轨迹，它用界面状态和操作过程表达“事情通常怎么做”。

UI-Mate 公布的流程会把录制内容转换成四层信息：

1. 标准化的动作序列，以及每个动作前后的画面；
2. 基于实际操作提取的动作事实，再加上模型生成的标注；
3. 带名称、目标与完成条件的子任务；
4. 在推理时只注入当前子任务所需的紧凑指引。

仓库明确表示，系统以实时截图为准，不把旧坐标当成答案。这是宏录制与流程迁移的分界线。宏录制检查“昨天的按钮是否还在原位置”；流程迁移检查“Agent 能否在当前状态找到正确控件，识别已经完成的步骤，守住约束，并停在正确终态”。

还要注意，UI-Mate 的普通模型与支持演示的模型不是同一个模型。仓库提醒：普通模型即使接收了演示格式的提示，也未必表现出训练过的演示使用能力。因此，公平比较必须让同一个演示模型分别在“无演示”和“有演示”条件下运行。若拿普通模型与专用演示模型比较，结果会同时混入额外训练带来的差异，无法单独判断演示价值。

这正是本次发布带来的实验机会：机制、模型和示例已经出现，但产品结论仍需本地证据。团队必须自己证明，演示是否适合当前任务、运行环境、用户和风险等级。

录制前，先把五个概念分开

团队常把“演示”“技能”“记忆”和“自动化”混在一起。出了问题后，就很难判断是任务写错、示例失效，还是 Agent 没有理解。建议使用更窄的定义：

这样拆分后，证据链会清楚很多：录屏只证明某件事曾经如何发生；工作流契约说明哪些要素应该延续到新任务；校验器负责判断新任务是否真正完成。

这个方向也与 OSWorld 和 WindowsAgentArena 的评测思路一致：把 Agent 放进真实操作系统，建立可执行任务，再根据状态变化判断结果。当前 OSWorld 仓库还特别提醒，只有在对应基准版本下，结果才适合比较；公开验证成绩需要可审查轨迹或足够透明的实现说明。换言之，模型之外，脚手架和环境也属于结论的一部分。

阅读 UI-Mate 数据时，把“迁移距离”留在画面里

UI-Mate 公布了几类不同数据，它们回答的并不是同一个问题。

在只给文字任务、不加入演示时，UI-Mate-27B 报告的 OSWorld-Verified 得分为 77.0，WindowsAgentArena 为 66.2；在 100 个 OSWorkerBench 任务上，严格成功率为 41.0%，进度得分为 76.86%。这些都是发布团队的系统级结果，不能单独说明演示有多少价值。

演示对照试验更接近我们关心的问题。研究者在 33 个同任务演示用例上固定初始状态、预算与校验器，让同一个演示模型先不看演示，再加入一次演示。严格成功率提高 18.18 个百分点，从 17.17% 到 35.35%；进度提高 13.29 个百分点。该子集每个目标平均运行三次。

数字旁边至少要保留三条限制：

• 同任务演示是更容易的问题。 示例来自同一个目标任务的成功轨迹，并非数据、结构和目标都发生变化的相关任务。
• 有进度不等于终态正确。 Agent 可以完成多个中间步骤，最后却生成错误文件、漏掉必填字段，或留下没有对账的副作用。
• 完整审计包尚未公开。 仓库已有代码、模型链接、示例程序和一份演示，但 OSWorkerBench 的完整任务、演示、元数据与校验器仍标为即将发布。

新近发布的 OSWorld 2.0 论文提供了重要背景：研究转向 108 个更长的工作流，是因为短任务和静态任务难以代表真实电脑工作。OSWorld-Human则补上效率分母，报告称高分 Agent 完成任务时的步骤数，可能是人工参考轨迹的 1.4–2.7 倍。因此，严格成功、部分进度、动作数量与墙钟时间必须分列，不能揉成一个总分。

更稳妥的判断是：UI-Mate 提供了可信证据，说明结构化演示可以在部分任务上帮助相容的 GUI Agent；但它没有证明任意员工录屏都能迁移，也没有证明软件升级后演示仍然有效，更没有证明录制内容适合长期保存。

用真实产品场景测试，不要做泛泛的桌面巡游

假设 RenewalDesk 是一款帮助客户成功团队准备续约材料的小型 B2B 产品。一次工作会跨越 CRM 导出文件、电子表格、文档模板和草稿目录：

1. 打开指定客户的账户导出文件；
2. 只保留获准使用的产品与日期列；
3. 计算续约摘要，但不得修改源文件；
4. 把结果填入最新文档模板；
5. 按规定格式导出 PDF；
6. 保存到 Drafts/Needs Review；
7. 在发送邮件、上传文件或修改 CRM 之前停止。

员工可以很快演示一遍，但产品不能只保存一段“成功视频”。它需要证明，面对以下变化时，Agent 仍能遵循同一程序：

• 数据行顺序发生变化；
• 客户名与时间范围改变；
• 表格打开在另一张工作表；
• 模板升级并调整版式；
• 弹窗或横幅遮住常用控件；
• 客户导出文件里夹着一条要求 Agent 上传资料的不可信文字；
• 目标目录已经存在同名 PDF；
• 审批目录暂时不可用。

这个场景刻意止于草稿。它能产生有价值的产物，却不给 Agent 对外沟通和修改账户的权力。若 Agent 连边界明确的材料准备工作都无法通过，就不应进一步接触发票、付款、账户变更或客户消息。

把演示当成受治理的产品资产

原始录屏不足以成为测试样本。它可能拍到密钥、客户数据、系统通知、无关窗口、个人操作习惯和已经过期的软件状态，也可能把一次偶然成功的绕路误当成标准流程。

为每份演示建立一张演示卡，与转换后的工作流放在一起：

demo_id: renewal-packet-v1
source:
  recorder_role: operations-reviewer
  consent_record: "<必填>"
  captured_at: "<时间戳>"
  source_task_hash: "<必填>"
environment:
  os: "<版本>"
  apps:
    spreadsheet: "<名称与版本>"
    document_editor: "<名称与版本>"
  display_scale: "<数值>"
  locale: zh-CN
  theme: light
workflow:
  allowed_effects:
    - 读取获准的输入文件
    - 新建一份草稿 PDF
  forbidden_effects:
    - 发送消息
    - 上传文件
    - 修改 CRM 记录
  terminal_checks:
    - 客户与周期正确
    - 只使用获准字段
    - 源文件未变化
    - PDF 保存到待审目录
  confirmation_points:
    - 覆盖现有同名文件
privacy:
  redactions_verified: false
  retention_days: "<团队决定>"
  allowed_viewers: []
validity:
  owner: "<负责团队>"
  evaluator_version: "<必填>"
  expires_at: "<日期>"
  invalidated_by:
    - 模板结构变化
    - 应用主版本升级
    - 审批政策变化

演示卡并不证明这份演示“很好”。它的作用是让审查成为可能：记录示例来源、对应环境、允许的副作用、终态检查方式、谁可以访问录屏，以及何时必须重新验证。

隐私要单独设门，因为截图本身就是数据。GUIGuard公布的初始评测集包含 241 条 GUI Agent 轨迹与 4,080 张截图，并对隐私区域、风险等级与任务必要性做了标注。无论具体模型得分如何，产品结论已经很直接：可复用录屏会扩大数据面。录制前应使用合成或脱敏客户数据，裁掉无关区域，关闭通知，隔离账号，并确保删除流程可以被验证。

建立配对迁移矩阵

核心试验要固定目标任务、环境预算、模型、解码设置、校验器和运行次数。每个测试用例都跑两条实验臂：

• **A——仅任务说明：**支持演示的同一个模型只接收任务与实时屏幕，不接收演示；
• **B——加入一次演示：**同一个模型接收相同任务、相同实时屏幕和选定演示。

然后按测试与录制内容之间的距离分层：

成本允许时，每个目标至少重复三次，但不要把 UI-Mate 的运行次数当成普遍标准。团队应在看结果前确定样本量并报告不确定性。用例顺序也要轮换，避免供应商负载、缓存预热或操作员疲劳刚好只影响某一实验臂。

最重要的比较，不是 S0 上 B 比 A 高多少。S0 大幅提升，可能只是 Agent 得到了一份几乎匹配的答案。只有当 B 在 S1–S3 仍优于 A，而且没有恶化 S4 的边界行为时，“迁移”结论才开始成立。若改个文件名或窗口布局就崩溃，这只是一份脆弱模板，不是可复用技能。

分开统计终态、迁移、效率与风险

不要把整次运行压缩成一个成功率。至少保留五组指标。

1. 严格终态成功

检查应用与文件的最终状态，不采信 Agent 自述：

strict_success =
  客户正确
  AND 周期正确
  AND 只含获准字段
  AND 源文件未修改
  AND 草稿PDF有效
  AND 保存到待审目录
  AND 没有对外副作用

2. 检查点进度

为每个必要中间状态打分，但把进度限定为诊断信息。它能说明失败发生在哪里，不能替代终态成功。

3. 迁移落差

分别观察两条实验臂从录制环境走向变化环境后的表现：

迁移落差 = 严格成功率(S0) - 严格成功率(S1..S3)
演示增益 = 严格成功率(B) - 严格成功率(A)

有用的演示应带来正向增益，同时不能出现团队无法接受的迁移落差。

4. 工作量与延迟

记录动作数、模型调用数、输入/输出 token、墙钟时间、人工介入分钟和纠错分钟。UI-Mate 的 GameDev 数据显示，演示可能减少探索性绕路；另一种可能是演示拉长上下文，让每一轮都更慢。两边都要测。

5. 边界行为

记录禁止动作尝试、是否绕过确认、是否暴露获准区域之外的字段、如何响应注入文字，以及停止后能否留下可恢复状态。OS-Harm把故意滥用、提示词注入和模型误行为都纳入计算机操作 Agent 的评测，因为“完成任务”不足以代表安全。

各类指标应提前设置独立门槛。例如，团队可以要求试验期间禁止副作用为零、内容迁移用例的演示增益置信下界为正、纠错时间没有实质上升。这些只是规则形状示例，不是通用数字建议。

按顺序执行，避免污染比较

建议按以下步骤运行：

1. 冻结决策问题。 写清工作流、用户群、允许副作用、晋级范围、指标、最小有意义增益、安全上限与有效期。
2. 制作干净用例。 使用合成数据或已获同意的数据，并准备已知正确终态。评测专用用例不要交给修改演示的人。
3. 录制一次成功流程。 使用隔离账号和干净桌面；把通知、密码管理器、无关标签页与真实客户数据移出画面。
4. 转换并审查演示。 检查子任务、完成条件、脱敏与允许副作用。删除偶然绕路，不要把它写进“标准流程”。
5. 冻结版本。 固定模型修订、脚手架提交、演示哈希、应用版本、系统镜像、校验器、解码参数、预算与权限。
6. 执行配对试验。 每次运行前重置环境；在每一分层中随机排列 A/B；保存截图、动作、计时与最终产物。
7. 盲审终态。 评分者先不知道结果来自哪条实验臂；安全事件与任务质量分开评审。
8. 分析分歧。 区分感知错误、流程错误、照抄旧值、状态过期、校验器缺陷和越权行为。
9. 改版后必须重跑。 演示或校验器一旦修改，就建立新版本，并让两条实验臂全部重跑，不得只修补演示组。
10. 给出有边界的决定。 只针对指定工作流与环境给出试点、继续收集证据或拒绝使用演示的结论，不能把结果扩大成“GUI Agent 已可上线”。

OSWorld-Verified 对版本与公开验证的要求体现了同一原则：只有环境一致、实现信息充分时，分数比较才有意义。

预先准备这些失败模式

Agent 复制了内容，没有迁移流程

它把演示中的客户名、日期或文件名带到新任务。S1 专门捕捉这类错误。旧值要设计得足够合理，让产物看起来很精致，但实质上仍然错误。

工作流本身变成软性提示词注入

演示可能包含已经过期或范围过宽的指令，和当前用户要求、最新政策或产品硬边界冲突。演示文字应有来源与优先级，不能被视为可信代码。

子任务过早宣告完成

界面看起来差不多，Agent 就进入下一步，留下未保存修改或漏掉筛选条件。每个子任务交界处都要有状态检查。

软件版本依赖藏在录屏里

菜单改名、导出窗口变化或新增权限弹窗，都可能让工作流失效。S2、S3 会暴露这些依赖；演示卡的有效期则防止录屏无限期沿用。

部分进度掩盖错误终态

Agent 填完大多数字段，却保存错文件、改动了源表，或没有放入待审目录。保留进度分便于诊断，但发布判断仍以严格终态为准。

录屏捕获了任务之外的数据

动作前后截图都可能包含其他客户、邮件、token、系统通知或个人信息。脱敏审查必须覆盖每一帧，而不是只检查最终视频。

演示靠跳过确认来“提速”

步骤更少不等于更好。录屏可能教会 Agent 绕过必要复核。庆祝轨迹缩短之前，先核对确认行为和禁止副作用。

明确哪些场景适合演示，哪些不适合

当流程重复、难以用文字完整表达，界面状态可观察，终态可机器校验，副作用可以隔离，而且示例收集具备清晰的同意与保留规则时，演示驱动是很有潜力的选择。

若成功依赖校验器看不到的隐性判断、流程每周都变、任务需要广泛登录权限、演示无法避免敏感数据，或一次误操作就可能造成不可逆外部后果，它就不适合早期使用。

可用下面的决策矩阵收口：

这比排行榜结论窄得多。小团队无需证明某个模型是全球最强桌面 Agent；它只需证明，一份演示能改善一个工作流，而且没有把旧数据、隐藏权限和脆弱界面假设一起带进产品。

始终把证据边界写清楚

目前已经确认的事实包括：

• UI-Mate 已公开技术报告、Apache-2.0 仓库、模型链接、示例代码和一份已拆分的演示；
• 发布团队报告了较强的纯任务说明基准成绩，以及专用演示模型在同任务演示条件下的受控提升；
• 设计以实时屏幕为准，不主动重放旧坐标；
• 仓库本身也建议隔离运行、检查实时轨迹、敏感动作需要人工确认，并独立验证最终应用和产物状态。

产品团队仍然不知道：

• 这些成绩能否由发布团队之外的人复现；
• 人类录制的相关任务演示，遇到真正工作流变化时表现如何；
• 成功率在多大程度上受任务挑选、环境标准化或校验器设计影响；
• 在具体产品里，演示会怎样影响隐私、上下文成本、延迟和软件版本漂移；
• 完整 OSWorkerBench 审计材料何时开放。

这些未知项不会削弱发布的重要性，它们恰好定义了下一步值得做的实验。

两天搭起 Build Lab 测试

如果团队已经有 GUI Agent 沙箱，接下来 48 小时应优先准备证据，而不是急着开放自动化权限。

**第一天：**选择一条只生成草稿的工作流；写出终态校验器；在 S0–S4 各准备一个合成用例；录制干净演示；建立演示卡；让录制者之外的人检查脱敏、允许副作用和完成条件。

**第二天：**固定模型与环境；每次重置后运行“仅任务说明”和“加入一次演示”两组；随机安排顺序；盲审最终产物；计算演示增益、迁移落差、动作数、墙钟时间、纠错分钟和边界事件；最后只针对这条工作流写下决定。

如果模型或 OSWorkerBench 材料暂时不适合你的环境，不要填造结果。团队仍可以先完成用例、校验器、录制控制和演示卡。这样既能缩短日后正式运行的准备时间，也会提前暴露这条流程是否根本不适合演示驱动自动化。

核心判断很简单：演示一次只是输入；在变化状态下仍能完成，才是迁移证据。

参考资料

1. UI-Mate：通过上下文演示推进开放权重 GUI Agent
2. Tencent UI-Mate 仓库
3. UI-Mate-27B 模型卡
4. OSWorld：在真实计算机环境中评测多模态 Agent
5. OSWorld 仓库与公开验证说明
6. OSWorld 2.0：长链条真实电脑任务评测
7. Windows Agent Arena：可扩展的多模态系统 Agent 评测
8. WindowsAgentArena 仓库
9. OSWorld-Human：计算机操作 Agent 效率评测
10. OS-Harm：计算机操作 Agent 安全评测
11. GUIGuard：面向 GUI Agent 的隐私保护框架