建设微信网站要多少钱网站平台 生态建设

建设微信网站要多少钱,网站平台 生态建设,周村网站建设yx718,门户网站seo前期实践是检验真理的唯一标准。为了在真实世界场景中验证我们在前文中提出的框架#xff08;RGR, OCA, EMA#xff09;的有效性#xff0c;我们设计并实现了一个移动GUI多智能体系统#xff1a;Fairy 。Q为什么选择 Mobile GUI Agent#xff1f;Mobile GUI Agent是验证我们的…实践是检验真理的唯一标准。为了在真实世界场景中验证我们在前文中提出的框架RGR, OCA, EMA的有效性我们设计并实现了一个移动GUI多智能体系统Fairy 。Q为什么选择 Mobile GUI AgentMobile GUI Agent是验证我们的框架的理想试验场它集中体现了提示词软件危机带来的所有核心挑战▴指令模糊性用户指令如“帮我打车回家”天然模糊且充满歧义。▴任务复杂性跨应用操作如“订一张今晚的机票再把行程和航班号加入我的日历”逻辑链条极长。▴环境动态性App内容多样、UI布局复杂系统必须具备自我学习能力。AFairy可演化、可观测交互式助手我们将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的架构将这一分解过程演化为一个三层精化结构▴第一次分解(高层)从用户意图到应用级任务分解原因真实的用户意图往往是跨应用的如“找附近好评餐馆并整理到备忘录”。职责Fairy的Global Task Manager如图1将单一高层意图拆分为在不同应用上执行的子任务序列如[任务1:打开地图App搜索,任务2:打开备忘录App粘贴]。▴第二次分解(中层)从应用级任务到子目标分解原因应用级任务如“在地图App搜索”仍然具有高复杂性与最终的原子操作有显著差异。职责Fairy的App-Level Executor中的Re-Planner围绕App的核心功能点将宏观任务分解为逻辑清晰的子目标序列如[SG1:搜索汉堡,SG2:选择套餐,SG3:确认支付]。▴第三次分解(底层)从子目标到原子操作分解原因即使已经进行了两次分解子目标如“搜索汉堡”仍不是一个可直接执行的操作。职责Fairy的App-Level Executor中的Action Decider将子目标分解为最终的原子操作序列如Tap(搜索框),Input(汉堡),Tap(搜索按钮)。综上Fairy的全局-应用-原子三层架构是解决语义鸿沟这一核心工程挑战的必要设计它精确地实例化了[ 规约 OCA-I ]所定义的逻辑分层。RGR-Ⅰ引擎驱动三层架构的认知核心[规约 RGR-I]要求规划引擎必须显式地依赖任务知识、环境知识和运行时上下文而不是仅仅依赖模型常识进行黑箱臆测。因此在Fairy的三层架构中我们将每一个规划引擎组件都工程化为一个完备的认知单元并实现了三个不同抽象层级的RGR引擎01高层规划引擎(Global Task Manager)▴核心职责将用户指令分解为App级任务。图2▴组件实例Global Planner这是高层规划引擎的核心负责制定跨App战略。它接收用户指令的复杂指令如“订机票并加入日历”并拆解为多个能在用户的手机中已经安装的应用上执行的任务。如[1.执行“订票”任务,2.执行“日历”任务]。它的运行分为直接计划和调整两个阶段直接计划通过用户指令和用户手机中的已安装应用制定全局计划并确定执行的首个任务。调整阶段则检查此前任务的执行结果并根据执行结果更新任务进展或调整此前的任务规划。环境感受器(App Metadata Manager)这是环境知识的来源它为Global Planner提供手机上已经装了哪些App、它们各有什么功能的列表。认知委派工具(Task Manager)这是“调度员”负责启动对应的App并将第一个App级任务如“订票”及其所需上下文正式委派给中层规划引擎。02中层规划引擎(Re-Planner)▴核心职责将App级任务分解为功能化子目标。图3▴组件实例Re-Planner这是中层规划引擎的核心。它接收Global Planner委派的任务如“订票”任务并将其分解为一系列功能子目标如[SG1:搜索航班,SG2:选择乘客,SG3:确认支付]。与Global Planner相似它也有直接计划和调整两个阶段直接计划阶段依据任务指令、屏幕感知信息和定制计划等确定执行的首个子目标。调整阶段则检查动作执行的结果并根据结果更新任务进展。仔细来说动作结果分为ABCD四个枚举类当结果为A时执行下一子目标当连续三次为CD时则考虑修改整体计划并重新挑选子目标。Re-Planner还会判断何时需要用户交互例如遇到OR分支或信息缺失并触发[规约 RGR-II]的交互流程在后面我们会详细介绍。上下文收集器Key Context Collection负责在执行过程中从屏幕上提取关键信息如“航班号”、“订单金额”并暂存供后续步骤如“支付”或“加入日历”使用。03低层规划引擎(Action Decider)▴核心职责将功能化子目标分解为一系列可以在手机上直接执行的原子操作。图4▴组件实例Action Decider这是底层规划引擎的核心。它接收Re-Planner的子目标如“搜索航班”并将其分解为可在手机上直接执行的原子操作序列如Tap(搜索框),Input(上海),Tap(搜索按钮)。环境感受器(Screen Perceptor)这是环境知识的来源。它实时感知当前屏幕告诉Action Decider屏幕上有什么、它们的坐标在哪里。Fairy支持通过UI Automator获取屏幕截图和可访问树同时支持视觉与非视觉两种模式。视觉模式下如图4所示Screen Perceptor会提取Clickable与Scrollable的组件并依据属性将他们投射在截图上然后给他们一个编号。通过编号与中心坐标的映射进行手机的原子操作。非视觉模式下则基于可访问树处理算法移除我用的节点与属性通过MLLM模型补全图片节点的描述信息最终输出一个类MD格式的感知信息。目标执行器(Action Executor)这是物理执行者。它接收Action Decider的指令并真正地在设备上执行Tap, Swipe, Input等原子操作。Fairy的RGR-Ⅱ交互运行时需求发现根据[规约RGR-Ⅱ]规划引擎必须能够识别运行时需求与运行时期望并通过与用户的交互来精化运行时期望。一个关键的工程决策就是我们如何在Fairy的多层规划架构中实现RGR-Ⅱ规约。交互的必要性和形式在不同的抽象层级上显然是截然不同的▴高层(Global Planner)的交互我们认为在Global Planner的层级几乎不会遇到OR分解或信息缺失用户意图的模糊性通常是在应用内部次啊会发现的因此当Global Planner无法找到合适的APP满足用户的需求时系统直接向用户报告失败而无需专门设计意图支架进行澄清。▴中/低层RePlanner/ActionDecider的交互与高层正相反中层和低层时识别运行时期望的主要场所。然而根据软件工程的Dont 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)初始化在Task Manager完成任务分配后原始任务指令被压入栈底作为App-Level Executor的执行基准。动态更新当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会获取第T1轮的起始屏幕和计划以及之前的执行轨迹仅包括行动与行动结果然后给出决策的原子动作。在Action Executor执行该动作后Screen Perceptor将激活并给出本轮的屏幕感知信息。最后Planner将重复前面的过程使得循环进入又一轮。除上述智能体外在Planner判断第T轮任务正常执行时Context Extractor将与其他智能体并行在T1轮收集第T轮结束屏幕也是第T1轮起始屏幕的关键信息该关键信息将作为第T轮的关键上下文。在执行第T1轮任务时使用的是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轮的交互进行反思然后依据用户补充的需求来做出T1轮的规划。在得到反思结果后记忆管理器会先清理本轮Action Loop中尚未补全的记忆内容然后创建下一轮的Action Loop记忆并把第T轮的起始屏幕直接沿用为第T1轮的起始屏幕。接下来如果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团队负责人主要研究方向包括软件智能化开发与运维、人机物融合智能化系统、智能汽车及智能制造基础软件等。排版丨牛嘉阳欢迎关注CodeWisdomCodewisdom平台由复旦大学软件工程实验室运营提供智能化软件开发平台及线上沙龙相关资讯关注可了解更多智能化软件开发的最新消息~