2.2.2 Trajectory Data Collection 在讲什么

这一小节讲的是：为了教会 GUI-Owl-1.5 真正在手机/电脑/网页上“按步骤操作”，他们怎么大规模、但又尽量高质量地收集“操作轨迹数据”。一条轨迹可以理解为：在某个任务指令下，模型每一步看到了什么界面、做了什么动作，最后是否把任务完成了。

它的核心思路是一个“混合式”流水线：能自动的尽量自动，自动搞不定的再用人工兜底，同时用虚拟环境补齐高频基础动作和真实环境难以稳定采集的场景。

流程分 4 块

1) 用人工写“任务流程图”DAG，把任务拆成可控的子步骤

• 标注人员先为某类 App/场景写一个 DAG 有向无环图：
  • 节点=原子子任务，比如“打开应用”“进入设置页”“点击某按钮”。
  • 边=正常情况下允许发生的步骤跳转（UI 状态演化下可行的转移）。
• 然后从“起点节点集合”采样一条到“终点节点集合”的路径，就得到一个多步任务骨架（一个常见工作流）。
• 每个节点都有一句子指令模板（可填槽位，比如城市名、文件名），把这些子指令按顺序拼起来并“润色重写”，就得到最终给模型的任务指令。

直观理解：先用人工把“常见操作流程”画成地图，任务就不会完全靠 LLM 瞎编，从源头减少“幻觉任务/离谱步骤”。

2) 在真实设备上自动跑轨迹，并用“检查点”判定跑到哪一步是对的

• 给定任务指令后，让一个自动化 agent 在真实设备环境里执行，生成轨迹 τ（每一步包含观察 o 和动作 a）。
• 关键是：他们为 DAG 路径上的每个子任务节点定义一个 检查点判定函数 ϕk：看当前观察 ot 时，第 k 个子任务算不算完成（是/否）。
• 跑完整条轨迹后，系统会计算：从第 1 步开始，连续完成了多少个子任务前缀（文中用 m(τ) 表示最长完成前缀长度）。

为什么要这样做：真实环境里自动跑经常中途翻车，如果直接把整段都当“正确示范”会把后面错误步骤也学进去。

3) 如果没全做对：截断到最后一个“确认做对”的检查点，并把剩余任务改写成新任务

当自动跑出来的轨迹没完成全部子任务时：

• 截断：只保留到“最后一次满足已完成前缀的检查点”为止的那段轨迹（确保留下的都是干净的、被验证过的正确片段）。
• 任务修复/重写：把已经完成的子任务从原 DAG 路径里删掉，只保留未完成的后半段，形成“剩余任务指令 Irem”，并把“剩余任务 + 已验证前缀轨迹”作为一个训练样本保存。

直观理解：

• 做对的部分留下来当标准答案；
• 做错之后的部分不硬喂给模型；
• 同时把“后续没做完的目标”单独生成一个新任务，方便后续继续收集或训练。

4) 自动搞不定的用人工示范；真实环境难采的用虚拟环境批量造

这部分是为了“覆盖面”和“成本”：

4.1 人工示范兜底

• 对那些自动尝试多次仍失败的任务，让专家在同样的真实设备上手动操作，录制高质量轨迹作为金标准。

4.2 虚拟环境补齐高频动作与困难场景

• 真实应用常有 CAPTCHA、反爬、不可控反馈，导致探索效率低、轨迹噪声大。
• 他们做了基于网页渲染的虚拟环境，专门覆盖：滚动、拖拽等细粒度原子操作，以及文档/表格编辑等高频难点场景。
• 虚拟环境能提供更精确的子任务完成反馈（类似真实环境的检查点机制），同样能“成功则收下，失败则截断保留干净前缀”。
• 对一些“标准做法很固定”的场景，还可以直接写脚本/RPA 策略执行，一次性低成本生成大量高质量成功轨迹。

一句话总结

2.2.2 就是在讲：用 DAG 把任务步骤标准化，再在真实设备/虚拟环境里自动跑轨迹；跑的时候用检查点验证进度，失败就截断保留正确前缀并重写剩余任务；自动不行就用人工示范补齐，从而得到规模大、噪声低的轨迹数据集。