UI-Copilot：通过工具集成策略优化推进长程 GUI 自动化 UI-Copilot: Advancing Long-Horizon GUI Automation via Tool-Integrated Policy Optimization

完整流程可拆为四个阶段。第一步 Dataset Curation：在 AndroidControl 上收集 $N$ 条人类轨迹 $\tau^*$，用 GPT-4o 合成每一步的 tool call、thought、summary，得到 $D_{expert}$；再用 GPT-4o 把需要历史/需要计算的场景改写成单轮查询，得到 $D_{tool}$（含 170 条 memory-intensive、80 条 calculation-needed、350 条 no-tool）；合并为 $D_0 = D_{expert} \cup D_{tool}$，再随机切分为 $D_{SFT}$、$D_{RL}^{tool}$、$D_{RL}^{action}$。第二步 Cold Start SFT：在 Qwen2.5VL-7B 上跑 cross-entropy，损失为 $\mathcal{L}_{SFT} = -\mathbb{E}_{(I,\{S_t\},\{a_t\})\sim D_{SFT}}\sum_t \log\pi_\theta(a_t \,|\, I, S_t, H_t)$，让模型先学会五段式输出格式和基础行为克隆。第三步 Tool-Integrated Rollout：策略按公式 (3) 的解耦采样执行——当 $I \sim D_{RL}^{tool}$，固定 off-policy 历史 $H_t^* = \text{summary}^*_{ \eta=0.3$ 以保证 advantage 方差足够。训练硬件为 8 块 A100、共 50 步、batch=16、$G=8$、学习率 $1\times10^{-6}$、最大响应长度 12288 tokens。

技术新颖性主要体现在三个层面。第一，把'Copilot 当外部工具'从 multi-agent workflow 升级为'agent 内置、按需触发'的 agentic RL 范式，避免了固定流水线带来的开销，也避免了 RAG 对检索质量的强依赖——工具调用本身就是策略网络的输出，与决策一体化。第二，Memory Decoupling 用 $H_t$（只含 summary）+ $K$（本地 thought 池）的双层记忆结构替代了之前 MC（full context）、AT（action-thought）两种方案，论文在 Figure 6 给出消融：MS 单独就能在 MemGUI-Bench 拿到 38.0% 平均准确率（MC 仅 34.6%、AT 仅 22.1%），再叠加 Retriever+Calculator 后达到 51.5%，明显优于同等规模的 multi-agent workflow（46.9%）。第三，TIPO 是把 GRPO 适配到工具集成场景的关键工程贡献：理论证明 + 实证同时说明 (a) 工具预测与动作生成应该用不同的 sampling 策略；(b) off-policy / on-policy 选择对结果有 6~8 个点的差距（MS+off-policy 43.4%、MS+on-policy 51.5%）；(c) 数据配比 $|D_{RL}^{action}|:|D_{RL}^{tool}|$ 在 600:2000 时达到最优（47.4%），继续增加会陷入 diminishing return。这些结论对其他 agentic RL 场景（web agent、code agent）也有借鉴价值。

我把论文里没有完全攻克的弱点梳理成三条独立判断。第一，工具集的单薄性是最显眼的工程瓶颈：当前只有 Calculator 和 Retriever 两个工具，遇到需要 OCR / 视觉裁剪 / 网页搜索 / 文件 IO 的真实场景就会失效。改进方向是引入工具注册表 + 可学习的工具 embedding，让策略可以通过 prompt 动态发现新工具，同时引入 tool-creation reward 鼓励策略主动'造工具'。第二，MS rollout 把 thought 完全外置虽然缓解了 context overload，但也让 Retriever 变成了单点失败——一旦 Retriever 在第 18 步召回错误（Figure 23 这种成功 case 显示 Retriever 必须精确读到'top-3 drivers'才能完成表格填写），整个轨迹就会失败。改进方向是把 Retriever 改成 top-k 多路召回 + 主智能体自行选用的 verifiable retrieval，或者把 K 升级成可结构化查询的 SQLite / 向量数据库。第三，训练动力学层面，TIPO 的 decoupled sampling 解决了工具与动作的优化矛盾，但 reward 设计仍然偏稀疏——只有工具格式对、类型对、坐标对的 hard 0/1 奖励，导致训练初期 variance 很低、收敛慢（论文自己也设了 $\sigma>0.3$ 的动态采样阈值）。可以引入 dense reward，例如工具调用的 latency penalty、retriever hit rate、calculator relative error 等，让策略获得更平滑的梯度。第四，Copilot 模型固定为 Qwen3-4B（Figure 6 消融证实这是最优尺寸），如果用户任务涉及不同语言或专业领域，Copilot 也需要可替换，这一点没有给出灵活的接口。

作者在 Limitations 中点明了'扩展到 web search、视觉裁剪等更广谱工具'这一明确方向。基于论文成果可以延伸出几条值得探索的研究线：(1) 把 TIPO 的 decoupled sampling 推广到 web agent / code agent / robotic agent，因为 agentic RL 中工具与动作的优化动力学冲突是普遍现象，理论上 Appendix C 的推导可以原样套用；(2) 把 Memory Decoupling 升级为可学习记忆，例如让主智能体自己决定哪些 thought 写进 K、用什么 schema 写，Retriever 变成可微分的神经检索器；(3) 在工具层面引入 hierarchical tool——Calculator / Retriever 之上再叠一层 Planner，让策略先选 tool family 再选具体 tool，进一步减小 action space；(4) 探索 on-device 部署，UI-Copilot-7B 的 39.1% AndroidWorld 成功率配合 Qwen3-4B 的轻量 Copilot 在 8 块 A100 上 50 步就能训完，有希望压缩成可在手机本地运行的 3B+0.6B 组合；(5) 把 benchmark 从 GUI 拓展到 embodied agent，因为 Figure 24 揭示的 spatial reasoning 失败同样存在于机器人操作场景。

复现友好度整体偏高：作者承诺开源代码与模型权重（论文多次出现 will release），数据集 $D_0$ 的合成 pipeline（GPT-4o 标注）也有清晰描述。硬件门槛中等——训练只需 8 块 A100、共 50 步、batch=16、超参 $\gamma$、$\epsilon$、$\beta$、$\eta$ 都给了具体数值；推理阶段主智能体 7B + Copilot 4B 在单张消费级 GPU（如 RTX 4090）即可部署。潜在复现难点有三处：(i) 训练数据依赖 GPT-4o 合成 thought/summary/tool annotation，API 调用的随机性会让不同人复现出略有差异的 $D_0$，需要锁定 temperature=0 并保存完整 prompt（图 27~29 给出了 system/user prompt 与 retriever/calculator prompt）；(ii) AndroidWorld 评测涉及 Android 模拟器（Android Studio + ADB），环境配置成本比纯文本 benchmark 高；(iii) 一些 reward threshold（如 click 的距离阈值 $\epsilon$、ground-truth bounding box 的扩大系数）只在 Appendix B 给出，复现时必须严格按 Table 3 的 action space 与 B.1-B.2 的 reward 定义实现。总体而言，对于熟悉 MLLM + GRPO 训练栈的团队，应当能在 2~3 周内完成端到端复现。