阿里通义实验室（Tongyi Lab，X-PLUG 团队）开源了跨平台 GUI 智能体框架 Mobile-Agent-v3，其核心是专为 GUI 感知、定位与端到端操作训练的多模态模型系列 GUI-Owl。该框架在 ScreenSpot-v2、ScreenSpot-Pro、OSWorld-G、Android World、OSWorld 等多个 GUI 自动化基准测试中声称达到 SOTA 水平。与依赖通用大模型处理界面理解与坐标定位的主流方案不同，Mobile-Agent-v3 选择先打造一个专门负责视觉定位的模型，再将其嵌入多智能体协作流程，形成一条更重感知层、更强调执行确定性的技术路线。
多智能体分工：一个状态池驱动四个角色
Mobile-Agent-v3 的整体结构围绕四个角色展开：Manager、Executor、ActionReflector 和 Notetaker。它们共同继承同一个抽象基类，通过共享一个 InfoPool 数据结构完成状态传递。InfoPool 中保存指令、计划、动作历史、错误描述、重要笔记等字段，所有角色都读取并写入这份状态，没有额外的消息队列或独立通信协议。
这种设计让整套流程非常透明。任何一步由谁触发、写入哪些字段、下一步又读取哪些内容，都可以通过代码直接追踪。Manager 负责制定高层计划并判断任务是否完成；Executor 不做规划，只从当前子目标出发，在固定动作集合中选择下一步操作；ActionReflector 根据操作前后的两张截图，把结果分为 A、B、C 三类，分别代表成功或部分成功、跳转到错误页面、以及界面没有变化。
容错机制：连续失败才触发重新规划
框架的容错逻辑建立在连续失败阈值之上。主循环会检查最近两次动作结果，只有当这两次都是 B 或 C 类失败时，才会触发 error_flag_plan 标志。随后，Manager 会在下一轮规划时收到“可能卡住”的提示，并被要求评估当前状态、判断是否需要修改整体计划。
- 单次失败不会立刻打断计划，允许 Executor 层面的小幅重试；
- 连续失败才把决策权上收到 Manager，类似“先自己尝试，再寻求调整”的操作逻辑；
- 如果上一步只是输出格式解析失败并被标记为 invalid，系统会跳过 Manager，直接让 Executor 重试，避免非操作层面的错误干扰规划层。
Notetaker 则承担“工作记忆”的角色。只有当动作被判定为 A 类，并且用户显式开启该功能时，它才会把当前界面中与任务目标相关的信息记录到 important_notes 中，供后续规划使用。这类笔记不是模型训练阶段的知识，而是执行过程中动态积累的上下文。
动作空间：放弃索引点击，押注坐标定位
在具体执行层面，Mobile-Agent-v3 实际使用的动作集合比代码中定义的完整列表更窄。Executor 真正可调用的原子动作包括：回答用户问题、点击坐标、长按坐标、输入文本、触发系统按键，以及滑动。与一些同时提供结构化索引点击和坐标点击的方案不同，该框架没有提供基于无障碍树或其他结构化信息的索引点击方式，坐标点击是唯一的定位路径。
这一选择与 GUI-Owl 的定位能力直接相关。该模型输出的是绝对像素坐标，而不是相对坐标。框架说明中提到，如果使用输出 0 到 1000 相对坐标的模型，例如 Seed-VL、Qwen-VL-2 或 Qwen-VL-3，需要设置对应的坐标类型参数。这意味着 Mobile-Agent-v3 的默认路径是围绕 GUI-Owl 的坐标输出能力构建的，而不是把视觉模型当作通用接口，再依赖外部结构化信息补全定位。
这种路线减少了对外部结构化信息的依赖。在真实移动环境中，自定义控件、游戏界面、WebView 等场景经常缺少稳定的无障碍树信息，坐标级视觉定位因此可能更具通用性。但代价是，框架对模型本身的定位精度要求更高，模型能力直接决定执行上限。
工程取向：透明、可读，但依赖模型能力
从代码结构看，Mobile-Agent-v3 并没有追求复杂的事件系统或分布式智能体通信，而是用一个固定步数上限的主循环串联全部角色。默认最大步数为 25，每一步按截图、错误检测、规划、动作选择、执行、反思、笔记的顺序推进。若 Manager 输出中包含 Finished，主循环即结束。
这种朴素的工程实现降低了理解和二次开发的门槛，也让容错逻辑、状态流转和动作执行都暴露在可直接阅读的代码路径中。相比把复杂逻辑隐藏在消息总线或中间件里的设计，这种方式更适合研究者快速理解多智能体 GUI Agent 的运行机制。
不过，框架的简洁也意味着更多能力被前置到模型侧。规划质量、动作选择、坐标定位、错误判断，都高度依赖底层多模态模型的表现。GUI-Owl 作为专门训练的 GUI 模型，是这套系统区别于通用 VLM 方案的关键所在；而框架本身更多承担的是组织流程、管理状态和控制失败边界的作用。
对移动端自动化测试而言，这条路线提供了一个值得关注的样本：不是简单把大模型接入测试脚本，而是先围绕界面感知与坐标定位建立专用模型，再通过多智能体分工把规划、执行、反思拆开。它能否在真实业务环境中稳定落地，仍取决于 GUI-Owl 在复杂界面、动态控件和长任务中的实际表现，但从架构上看，Mobile-Agent-v3 已经把“专用 GUI 模型 + 多智能体流程”的组合展示得相当清楚。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/mobileagentv3-yu-guiowl-yi-dong-duan-gui-agent-de-duo-zhi
