文章总结： FairyMobileGUIAgent是一个结合RGR、OCA、EMA框架的移动GUI多智能体系统，旨在解决指令模糊性、任务复杂性和环境动态性挑战。其架构包括全局任务管理器、应用级执行器和自我学习器，通过三层分解实现高层意图到原子操作的转化。RGR引擎处理运行时交互，OCA架构确保可观测性，EMA支持持续学习，使系统鲁棒、可观测且可演化。该框架为构建下一代AgenticAI系统提供了有效蓝图。
综合评分： 88
文章分类： AI安全,移动安全,安全建设,解决方案

Fairy Mobile GUI Agent——RGR、OCA、EMA的综合落地

原创

CodeWisdom

CodeWisdom

2025年12月15日 20:45
甘肃

实践是检验真理的唯一标准。为了在真实世界场景中验证我们在前文中提出的框架（RGR, OCA, EMA）的有效性，我们设计并实现了一个移动GUI多智能体系统：Fairy 。

Q

为什么选择 Mobile GUI Agent？

Mobile GUI Agent是验证我们的框架的理想试验场，它集中体现了提示词软件危机带来的所有核心挑战：

▴ 指令模糊性：用户指令（如“帮我打车回家”）天然模糊且充满歧义。

▴ 任务复杂性：跨应用操作（如“订一张今晚的机票，再把行程和航班号加入我的日历”）逻辑链条极长。

▴ 环境动态性：App内容多样、UI布局复杂，系统必须具备自我学习能力。

A

Fairy：可演化、可观测交互式助手

   我们将Fairy设计成一个能自我进化的、交互式的多智能体手机助手。其架构（如图1所示）由三个核心模块构成：

图1

▴ Global Task Manager(全局任务管理器)：作为顶层的协调者，负责将用户的高层跨任务指令（如“帮我订票并加入日历”）进行拆解，变成一系列能够在单个任务上完成的子任务。

▴ App-Level Executor(应用级执行器)：由多智能体构成的核心执行单元。它依据长短期记忆将任务细化为子目标与原子操作，并通过动作环路和交互环路协同执行，实现高精度操作与实时的用户沟通。

▴ Self-Learner(自我学习器)：负责任务后的持续学习。它在任务结束后总结经验，将执行或试错中的经验固化为可复用的App Tricks（应用技巧）和App Map（应用地图）。

Fairy的宏观架构：OCA规约的落地

    Agentic软件工程的本质，是构建一个能遵循用户意图、自主执行复杂任务的系统。因此，规划-执行模型是所有设计的起点。像Fairy这样的Mobile GUI Agent领域，其核心任务就是将用户的高层指令（如：“帮我订个麦当劳汉堡”）转化为一系列可在设备上执行的原子操作（如：Tap(x,y),Input(…)）。然而，用户高层意图与设备原子操作之间，存在着一道巨大的语义鸿沟。一个单一的、端到端的单体式智能体，在试图一次性跨越这道鸿沟时，会因推理链过长与状态空间爆炸而不可避免地失败。因此，采用分解这一原则将这个巨大的鸿沟逐层精化就成了工程上的必然选择。在[规约 OCA-I]的指导下，Fairy的架构将这一分解过程演化为一个三层精化结构：

▴第一次分解(高层)：从用户意图到应用级任务

1. 分解原因：真实的用户意图往往是跨应用的（如“找附近好评餐馆并整理到备忘录”）。
2. 职责：Fairy的Global Task Manager（如图1）将单一高层意图，拆分为在不同应用上执行的子任务序列（如：[任务1:打开地图App搜索,任务2:打开备忘录App粘贴]）。

▴ 第二次分解(中层)：从应用级任务到子目标

1. 分解原因：应用级任务（如“在地图App搜索”）仍然具有高复杂性，与最终的原子操作有显著差异。
2. 职责：Fairy的App-Level Executor中的Re-Planner围绕App的核心功能点，将宏观任务分解为逻辑清晰的子目标序列（如：[SG1:搜索汉堡,SG2:选择套餐,SG3:确认支付]）。

▴ 第三次分解(底层)：从子目标到原子操作

1. 分解原因：即使已经进行了两次分解，子目标（如“搜索汉堡”）仍不是一个可直接执行的操作。
2. 职责：Fairy的App-Level Executor中的Action Decider将子目标分解为最终的原子操作序列（如：Tap(搜索框),Input(‘汉堡’),Tap(搜索按钮)）。

    综上，Fairy的全局-应用-原子三层架构，是解决语义鸿沟这一核心工程挑战的必要设计，它精确地实例化了[ 规约 OCA-I ]所定义的逻辑分层。

RGR-Ⅰ引擎：驱动三层架构的认知核心

    [规约 RGR-I]要求规划引擎必须显式地依赖任务知识、环境知识和运行时上下文，而不是仅仅依赖模型常识进行黑箱臆测。因此在Fairy的三层架构中，我们将每一个规划引擎组件都工程化为一个完备的认知单元，并实现了三个不同抽象层级的RGR引擎：

01

高层规划引擎(Global Task Manager)

▴ 核心职责：将用户指令分解为App级任务。

图2

▴ 组件实例：

1. Global Planner：这是高层规划引擎的核心，负责制定跨App战略。它接收用户指令的复杂指令（如“订机票并加入日历”），并拆解为多个能在用户的手机中已经安装的应用上执行的任务。如：[1.执行“订票”任务,2.执行“日历”任务]）。它的运行分为直接计划和调整两个阶段：直接计划通过用户指令和用户手机中的已安装应用制定全局计划，并确定执行的首个任务。调整阶段则检查此前任务的执行结果并根据执行结果更新任务进展，或调整此前的任务规划。
2. 环境感受器(App Metadata Manager)：这是环境知识的来源，它为Global Planner提供手机上已经装了哪些App、它们各有什么功能的列表。
3. 认知委派工具(Task Manager)：这是“调度员”，负责启动对应的App，并将第一个App级任务（如“订票”）及其所需上下文，正式委派给中层规划引擎。

02

中层规划引擎(Re-Planner)

▴ 核心职责：将App级任务分解为功能化子目标。

图3

▴ 组件实例：

1. Re-Planner：这是中层规划引擎的核心。它接收Global Planner委派的任务（如“订票”任务），并将其分解为一系列功能子目标（如：[SG1:搜索航班,SG2:选择乘客,SG3:确认支付]）。与Global Planner相似，它也有直接计划和调整两个阶段：直接计划阶段依据任务指令、屏幕感知信息和定制计划等确定执行的首个子目标。调整阶段则检查动作执行的结果并根据结果更新任务进展。仔细来说，动作结果分为ABCD四个枚举类，当结果为A时执行下一子目标，当连续三次为CD时则考虑修改整体计划并重新挑选子目标。Re-Planner还会判断何时需要用户交互（例如，遇到OR分支或信息缺失），并触发[规约 RGR-II]的交互流程（在后面我们会详细介绍）。
2. 上下文收集器（Key Context Collection）：负责在执行过程中，从屏幕上提取关键信息（如“航班号”、“订单金额”）并暂存，供后续步骤（如“支付”或“加入日历”）使用。

03

低层规划引擎(Action Decider)

▴ 核心职责：将功能化子目标分解为一系列可以在手机上直接执行的原子操作。

图4

▴ 组件实例：

1. Action Decider：这是底层规划引擎的核心。它接收Re-Planner的子目标（如“搜索航班”），并将其分解为可在手机上直接执行的原子操作序列（如：Tap(搜索框),Input(‘上海’),Tap(搜索按钮)）。

2. 环境感受器(Screen Perceptor)：这是环境知识的来源。它实时感知当前屏幕，告诉Action Decider屏幕上有什么、它们的坐标在哪里。Fairy支持通过UI Automator获取屏幕截图和可访问树，同时支持视觉与非视觉两种模式。

3. 视觉模式下，如图4所示，Screen Perceptor会提取Clickable与Scrollable的组件，并依据属性将他们投射在截图上，然后给他们一个编号。通过编号与中心坐标的映射进行手机的原子操作。

4. 非视觉模式下，则基于可访问树处理算法移除我用的节点与属性，通过MLLM模型补全图片节点的描述信息，最终输出一个类MD格式的感知信息。

5. 目标执行器(Action Executor)：这是物理执行者。它接收Action Decider的指令，并真正地在设备上执行Tap, Swipe, Input等原子操作。

Fairy的RGR-Ⅱ交互：运行时需求发现

    根据[规约RGR-Ⅱ]，规划引擎必须能够识别运行时需求与运行时期望，并通过与用户的交互来精化运行时期望。一个关键的工程决策就是我们如何在Fairy的多层规划架构中实现RGR-Ⅱ规约。交互的必要性和形式在不同的抽象层级上显然是截然不同的：

▴ 高层(Global Planner)的交互：我们认为，在Global Planner的层级几乎不会遇到OR分解或信息缺失，用户意图的模糊性通常是在应用内部次啊会发现的，因此当Global Planner无法找到合适的APP满足用户的需求时，系统直接向用户报告失败，而无需专门设计意图支架进行澄清。

▴ 中/低层（RePlanner/ActionDecider）的交互：与高层正相反，中层和低层时识别运行时期望的主要场所。然而根据软件工程的”Don’t Repeat Yourself”原则，我们没有给这两个引擎分别构建交互模块，我们只设计了一个统一的用户交互模块，它服务于中层和低层，只是激活它的方式不同。

图5

这种设计既确保了Fairy的架构完全遵循RGR-II规约，又保证了系统工程上的高可维护性。与行动循环相对应，这个由运行时需求发现和用户交互构成的协同闭环，在Fairy架构中被称为交互循环，其架构如图5所示。

    在Action Loop的过程中，当它判断当前的操作涉及以下四类特殊情况时，当前的行动循环将会立即挂起，系统切换进入Interaction Loop：

▴ 敏感或危险操作：需要用户显式授权；

▴ 不可逆操作：需用户确认后果；

▴ 多分支选择：需用户在不同选项中做出决策；

▴ 指令澄清：需用户对模糊指令做进一步解释。

为了避免规划器因为幻觉而自信地跳过必要的交互，我们引入了一个双保险机制：如果Action Decider发现当前必须交互而规划器未发出指令，它将强制抛出NeedInteraction信号。这种反向纠错机制使规划器在能够在下一个循环中反思错误，强制进入交互循环，从而极大提高了系统的鲁棒性。

    进入交互循环后，User Interactor即被激活。它不是简单的传话筒，而是负责根据子目标制定交互策略。它会综合考量原始任务指令、当前规划路径、屏幕感知信息以及历史对话记录。基于这些多维上下文，它动态生成当前最合适的用户提示词。在交互过程中，它始终维护着一个内部状态机：

▴ 持续交互：如果用户的回复仍然模糊或还未满足当前需求，它会继续生成新的追问；

▴ 交互终止：一旦用户做出了清晰的选择，它会立即结束对话，并生成一份用户回应总结。这份总结是连接自然语言对话与系统规划逻辑的关键桥梁。

我们还设计了User Dialoger作为执行工具，它负责具体的UI渲染或控制台输出，将提示展示给用户并捕获输入。这种工具化的设计使我们在系统评估阶段时可以轻松接入自动化测试脚本来模拟用户回复。

    当交互结束，控制权交还给Planner。此时的Planner不仅要感知屏幕信息，还要总结用户回应。它会检查交互结果是否填补了之前的信息缺失。根据反思结果，Planner将动态调整后续的整体计划或确定下一个具体的子任务，从而在人机协作后实现路径修正。

Fairy的EMA实现：摆脱永恒的新手

    我们已经有了骨架(OCA-I)和引擎(RGR)，但这些组件依赖的知识（任务知识、环境知识）从何而来？如果知识库是静态的，Fairy仍只是一个永恒的新手。而这正是EMA方法论的职责：让Fairy拥有演化的能力。Fairy精确地实例化了[规约 EMA]的两个严格的工程要求。

01

短期记忆与执行循环

短期记忆管理器 (Short-term Memory Manager)，是维护Fairy短期记忆的核心组件，负责管理智能体执行任务时的所有输入依赖与输出的全部上下文。为了高效处理不同生命周期的数据，我们将短期记忆设计成一个复合栈结构：

▴ 指令栈 (Instruction Stack)：

1. 初始化：在Task Manager完成任务分配后，原始任务指令被压入栈底，作为App-Level Executor的执行基准。
2. 动态更新：当Interaction Loop终止后，User Interactor生成的用户回应总结会被压入栈顶。这意味着后续的操作将基于原始指令+用户补充的最新上下文。

▴ 行动循环记忆栈 (Action Loop Memory Stack)：用于记录每一步操作的完整快照。每当完成一轮Action Loop，系统会将当前的计划、具体行动、屏幕感知以及反思结果打包压入栈中。构成智能体的行为日志。

▴ 交互循环记忆栈 (Interaction Loop Memory Stack)：这是一个临时性的栈结构。当Action Loop被挂起并进入交互状态时，该栈被创建。它负责记录每一轮对话的系统提示词与用户回复。

当交互结束并生成总结后，该栈的内容会缓存起来，在Interaction Loop 终止后，栈本身会被清空。

▴ 关键上下文栈 (Key Context Stack)：专门用于存储从屏幕中提取的结构化信息。每当一轮Action Loop成功执行且关键上下文收集器提取到数据时，这些高价值信息会压入栈中。

图6

如图6所示，在Action Loop阶段，Planner首先会从记忆管理器中获取第T轮的相关输入，然后做出该论的反思结果，并给出下一轮的计划。在给出反思结果后，记忆管理器就会新建新一轮的Action Loop记忆。接下来，Action Decider会获取第T+1轮的起始屏幕和计划，以及之前的执行轨迹（仅包括行动与行动结果），然后给出决策的原子动作。在Action Executor执行该动作后，Screen Perceptor将激活并给出本轮的屏幕感知信息。最后，Planner将重复前面的过程，使得循环进入又一轮。

    除上述智能体外，在Planner判断第T轮任务正常执行时，Context Extractor将与其他智能体并行，在T+1轮收集第T轮结束屏幕（也是第T+1轮起始屏幕）的关键信息，该关键信息将作为第T轮的关键上下文。在执行第T+1轮任务时，使用的是T-1轮关键上下文，这是因为第T轮的上下文信息还没有收集完。

图7

如图7所示，在第T轮时，如果Planner认为当前需要进行用户交互，Interaction Loop就会激活，然后与用户进行若干轮交互。User Interactor从记忆管理器中获取第T轮的起始屏幕和计划，以及用户交互的提示词和用户的回应，来判断是否还需要和用户进行交互。如果仍然没有满足交互的需要，则继续构建用户提示词并通过User Dialoguer将提示词向用户进行展示，用户回复后，则将提示词和用户的回复一并储存，并继续通过User Interactor进行下一轮的交互规划。

    一旦用户的回复已经满足了全部要求，User Interactor就会对用户的响应进行总结，并更新Task Instruction。此时Planner将获取第T轮的起始屏幕、计划和更新后的Task Instruction，并对第T轮的交互进行反思，然后依据用户补充的需求来做出T+1轮的规划。在得到反思结果后，记忆管理器会先清理本轮Action Loop中尚未补全的记忆内容，然后创建下一轮的Action Loop记忆，并把第T轮的起始屏幕直接沿用为第T+1轮的起始屏幕。

    接下来，如果Planner判断仍需要用户继续交互，就重复同样的流程；如果不再需要用户输入，那么Action Loop就会被激活，Action Decider开始正式决策原子动作。

02

长期记忆与演化循环

    长期记忆管理器 (Long-term Memory Manager)与短期记忆不同，长期记忆管理器用于知识的持久化与复用。它是Fairy的经验库，用来存储各个智能体沉淀下来的两类核心知识：

▴ App Tricks：这是针对特定App的操作经验集合，它的本质是一个自然语言描述的攻略本。它的来源包括历史执行与试错中自主吸取的教训，也包括人类专家预置的高级技巧。为了精准指导不同阶段的决策，它被细化为规划诀窍、动作决策诀窍和错误恢复诀窍

▴ App Map：这是针对App结构的知识图谱，相当于Fairy脑中的应用地图。它以图的形式进行存储，记录了所有在历史中见过的Activity、页面及其内部组件。每个节点不仅包含该组件的静态描述，还记录了它们之间的动态操作逻辑（例如：点击后是跳转新页面，还是仅触发局部刷新）。这让系统能够更深刻的理解App的拓扑结构，从而支持长距离导航。

Fairy的微观实现：白箱基石

    最后，Fairy的所有组件（RGR引擎、EMA记忆管理器）是如何协同工作但不沦为不可观测的黑箱的？这归功于我们实现了[规约 OCA-II：认知解耦与状态-控制分离]。Fairy并未采用点对点的混乱调用，而是实现了一个名为Citlali的简易通讯框架，精确地实例化了OCA-II的总线架构：

▴ 认知解耦：Fairy中所有的核心组件（如Re-Planner,Action Decider,Screen Perceptor）都实现为一个职责单一的Worker。

▴ 事件总线(EB)/控制流：组件间的控制完全通过发布-订阅模式进行。Action Decider不会直接调用Action Executor。而是Action Decider向动作主题发布一个原子动作（事件），Action Executor订阅该主题并执行。这实现了显式的、可观测的控制流。

▴ 记忆总线(MB)/数据流：Memory Manager为记忆总线，即数据流的唯一来源。Memory Manager订阅所有组件发布的事件，并将这些信息存入短期记忆。当Re-Planner等组件需要历史状态时，它们必须通过请求-响应模式向Memory Manager查询。

    这种发布事件和查询状态的严格分离，彻底杜绝了组件间的直接调用，确保了Fairy系统的白箱可观测性、可调试性与可维护性，精确地实现了[规约 OCA-II]。

迈向下一代Agentic软件工程

本系列文章针对Agentic AI系统在工程化实践中普遍存在的三大核心挑战——即非确定性导致的盲目臆测、黑箱特性导致的难以观测、以及无法学习导致的永恒新手设计并提出了一个系统性的软件工程框架。

该框架由三个相辅相成的方法论构成：运行时目标精化(RGR)；可观测认知架构(OCA)；演化式记忆架构(EMA)。

    为了实证检验该框架的有效性，我们将其完整地构建了一个名为Fairy的移动GUI智能体。Fairy的实证结果，清晰地展现了该框架相较于当前主流SOTA方法的全面优势：

▴ RGR规约使Fairy获得了鲁棒性：它能通过交互环路有效澄清用户的模糊指令，杜绝了盲目精化。

▴ OCA规约使Fairy获得了可观测性与健壮性：其逻辑分层架构成功分解了复杂的长链路跨应用任务；状态-控制分离的总线设计则显著提升了系统的可维护性。

▴ EMA规约使Fairy获得了可演化性：其执行-演化双环路模型，使智能体能够从经验中学习（生成App Tricks和App Map），持续优化其长期表现。

    尽管该框架在形式化定义与跨领域泛化上尚存局限，但本研究的结论证实了这套（RGR, OCA, EMA）框架作为一套完整的方法论，为构建鲁棒、可观测且可演化的Agentic AI系统，提供了一套行之有效的工程规约与实践蓝图。

作者简介

孙家正

复旦大学CodeWisdom团队博士生，主要研究方向是LLM Agent架构与技术研究，特别关注Agentic软件工程与GUI Agent研究

牛嘉阳

复旦大学CodeWisdom团队硕士生，主要研究方向是LLM Agent架构与技术研究，特别关注GUI Agent领域

李明轩

复旦大学CodeWisdom团队硕士生，主要研究方向是Mobile GUI Agent 架构与技术，特别关注Mobile GUI Agent测试领域

审核修改：

彭鑫，复旦大学计算与智能创新学院副院长、教授，CodeWisdom团队负责人，主要研究方向包括软件智能化开发与运维、人机物融合智能化系统、智能汽车及智能制造基础软件等。

排版丨牛嘉阳

欢迎关注CodeWisdom，Codewisdom平台由复旦大学软件工程实验室运营，提供智能化软件开发平台及线上沙龙相关资讯，关注可了解更多智能化软件开发的最新消息~

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：CodeWisdom CodeWisdom《Fairy Mobile GUI Agent——RGR、OCA、EMA的综合落地》