三分钟看懂 Qwen-UI-Agent（上）：会看屏幕、会敲命令，还会主动找你的 AI
一句话看懂：普通 GUI Agent 像一个只会照着屏幕点按钮的“远程操作员”；Qwen-UI-Agent 想做的，则是一个能看懂手机和电脑、会用命令行提高效率、能跨设备接力，甚至会在合适时机主动提供帮助的“数字执行者”。
假设你收到一条航班取消通知。
普通聊天机器人最多告诉你：“建议查询其他航班或高铁。”普通 GUI Agent 可能替你打开购票软件，再一步步点击查询。
Qwen-UI-Agent 想做得更多：它先理解通知意味着什么，再查询替代航班和高铁，结合你下午的会议判断最晚到达时间，给出候选方案；得到你确认后，它还能继续在手机上处理行程，在电脑上修改日程表，并把更新后的文件发给相关人员。
这也是论文标题中 Real-World Centric 的真正含义：研究重点不再只是“模型能不能点中按钮”，而是“它能不能在真实数字世界里把一件复杂事情办完”。
1. 它到底是什么？
Qwen-UI-Agent 是阿里巴巴 MAI-UI 团队提出的通用 GUI Agent，覆盖四类环境：
手机：打开 App、点击、滑动、输入、跨 App 搬运信息；
电脑：操作桌面软件、文件、表格和系统功能；
网页：在动态页面里搜索、筛选、填写和提交；
DeepSearch：检索多个来源、核对证据，再把结论带回 GUI 继续执行。
它不是四个互不相干的机器人，而是让同一个模型在统一的“观察—思考—行动”循环中切换环境。
在第 (t) 步，模型看到的内容可以写成：
$$ o_t = \left(o_t^{GUI},;o_t^{CLI},;o_t^{API}\right) $$也就是：屏幕截图、命令执行结果和外部服务返回值可以同时成为它的观察。模型再结合用户要求和历史操作，决定下一步怎么做。
图 1：论文 Figure 2 裁切图。一次任务可以在搜索、手机 GUI、电脑 GUI 与 CLI 之间连续流转。
2. 为什么传统 GUI Agent 还不够？
很多 GUI Agent 在基准测试里表现不错，到了真实手机上却容易“掉链子”。原因很直观：测试环境通常干净、稳定、可以一键重置；真实 App 却会出现弹窗、验证码、权限申请、登录过期、网络波动和界面改版。
论文将下一代 GUI Agent 面临的变化概括为几条主线：
过去的 GUI Agent | Qwen-UI-Agent 想走向的形态 |
|---|---|
在模拟器里完成固定任务 | 在真实设备、真实 App 和真实网络里运行 |
手机、网页、电脑各做各的 | 一个任务跨平台延续 |
只会点击、输入和滑动 | GUI、CLI、API 混合执行 |
一次只走一步 | 一次生成一组可连续执行的动作 |
等用户下命令 | 从通知等信号中主动发现需求 |
人工不断造数据、查失败 | Agent 辅助生成任务、诊断失败并推动下一轮训练 |
真正的难点已经从“识别按钮”变成了一个系统问题：模型、设备、环境、数据、训练和安全控制必须一起设计。
3. GUI 是眼睛，CLI 是手
这是整篇论文最容易被低估、却很实用的设计。
如果要在表格里处理几百行数据，纯 GUI Agent 需要不断定位单元格、点击菜单和输入公式。人类工程师通常不会这么做，而是直接写一段脚本。
Qwen-UI-Agent 因此支持两种互补方式：
GUI 负责看与交互：适合识别界面、理解图片、操作没有 API 的 App；
CLI 负责快速执行：适合批量处理文件、运行脚本、修改结构化数据；
API 负责高效取信息：适合搜索与结构化服务调用。
更关键的是，它可以在同一条轨迹里混着用。例如先用 Bash 找到文件并生成图表，再打开 LibreOffice，亲眼确认图表有没有正确显示。
这就像给 Agent 配了两套器官：CLI 是手，GUI 是眼睛。手负责快，眼睛负责确认有没有真的做对。
图 2：论文 Figure 3 裁切图。沙箱、真实设备、GUI+CLI 与统一接口共同构成环境基础设施。
一次还能做多个动作
传统 Agent 往往每做一次点击，都要重新截图、重新推理。Qwen-UI-Agent 允许一次决策输出有顺序的一组动作：
$$ a_t = \left(a_t^{(1)},a_t^{(2)},\ldots,a_t^{(K_t)}\right) $$只要中间不需要观察新状态，就可以连续执行。比如“点击输入框—输入关键词—按回车”不必拆成三轮模型调用。
论文的行为统计显示，在电脑任务中，约 40% 的动作输出采用批量形式。这能缩短轨迹，但也有边界：如果下一步依赖页面是否加载成功，就必须重新观察，不能盲目连点。
4. 为什么一定要上真实手机？
团队搭建了一个包含 100 多台物理手机、150 多个 App 的真实设备运行环境。
这不是把手机接上数据线那么简单。系统还要处理：
哪台设备、哪个账号和哪个 App 当前可用；
网络或设备异常后，任务应该重试还是换机；
一台手机上的多个虚拟屏幕如何对应不同 Agent；
登录、验证码、支付、权限等步骤何时交还用户；
一次失败究竟是模型判断错了，还是环境本身坏了。
论文设计了健康感知调度器：异常设备会被暂时拉入黑名单，修复并重新验证后才恢复。完整轨迹还会被审查，结果被分成“成功、模型失败、环境失败”三类。
图 3：论文 Figure 4 裁切图。真实设备运行并不是单一模型能力，而是一套包含调度、人工接管、证据审查和环境恢复的闭环。
论文还利用虚拟屏幕，让一台物理手机同时承载多个独立 App 会话。在其设备集群中，这使真实设备 rollout 的总体吞吐量提升约 20 倍。注意，这里的 20 倍是训练和采样吞吐提升，不等于单个任务执行速度提升 20 倍。
5. 它为什么会“主动找你”？
普通 Agent 的工作模式是：用户先意识到问题，再组织语言下命令。
Qwen-UI-Agent 在模型上方增加了一个轻量 Harness 层。它可以读取手机通知这一类及时、可控的信号，把孤立事件整理成一个待办：
识别发生了什么，例如航班取消；
找到相关日程和约束，例如下午必须到场的会议；
并行查询航班、高铁与交通时间；
汇总成可决策方案；
涉及预订、支付等高风险操作时，先询问用户。
图 4：论文 Figure 6 裁切图。Harness 负责“何时开始”和“如何跨平台接力”，核心模型负责具体执行。
这里有一个重要区别：主动服务不等于擅自替用户做决定。 论文的动作空间专门加入 ask_user，涉及敏感数据、付款或后果较大的操作时，应由用户确认或接管。
6. 一个例子看懂“跨平台”
论文展示了这样的工作流：Agent 同时在多个手机虚拟屏幕中查询餐厅，在不同 App 里收集评分，然后把结果交给电脑端整理为本地报告。
图 5：论文 Figure 12 裁切图。手机负责多 App 并行搜索，电脑负责汇总成报告。
这比简单“远程控制手机”多了三层能力：
上下文没有因为换设备而丢失；
子任务可以并行，而不是排队逐个完成；
中间产物能跨设备继续使用。
7. 上篇小结：真正的升级不是“点得更准”
Qwen-UI-Agent 的核心价值可以压缩成一句话：
它把 GUI Agent 从“屏幕点击模型”扩展成了一个由真实设备、混合动作、跨平台状态和主动服务共同组成的执行系统。
但系统搭起来只是第一步。它怎么学会不点错、不重复、不提前宣布完成？为什么要把 SFT、动作级 RL 和在线 RL 分成三层？论文中那些漂亮的 92.2%、97.5% 又该怎样理性看待？
这些问题放在下篇讲。
资料来源
Zhou et al., Qwen-UI-Agent Technical Report: Toward Next-Generation Real-World Centric Foundation GUI Agents, arXiv:2607.28227, 2026。