研究背景

1. 研究问题:

这篇文章旨在解决现有图形用户界面（GUI）代理在执行任务时存在的高成本、高延迟和低准确性的问题。现有的GUI代理通常通过逐步调用视觉语言模型（MLLM）来完成任务，这种方式在每一步都需要进行推理和行动，导致计算成本高、延迟大，并且由于缺乏对之前访问页面的持久记忆，准确性也受到限制。

2. 研究难点:

• 高成本和高延迟: 现有的GUI代理在每一步都需要调用MLLM，导致模型调用次数与任务步骤数成线性关系，增加了计算成本和延迟。
• 低准确性: 由于缺乏对之前访问页面的持久记忆，代理在处理复杂任务时容易出现错误累积，影响任务的准确性。
• 短视理解: 现有代理对应用程序的理解仅限于当前任务，无法形成全局的页面关系模型，导致难以识别和复用可重用的组件。

3. 相关工作:

• 视觉基础代理: 如ScreenAgent和SeeClick，通过处理GUI的截图来决定下一步行动，虽然通用性强，但每一步都需要昂贵的MLLM调用，导致速度慢且资源密集。
• 文本基础代理: 如WebWISE和MindAct，通过解析网页的底层文本元数据（如HTML源代码或DOM树）来识别交互元素并制定行动计划，虽然可能比视觉方法更快，但对网站结构的变化较为敏感，泛化能力差。
• 多模态代理: 如WebVoyager，结合视觉和文本信息以做出更稳健的决策，但仍依赖于逐步推理。
• 记忆增强代理: 如Synapse和AutoDroid，尝试通过记忆来提高代理的准确性，但仍然采用逐步推理的方式。

研究方法

本文提出了一种名为ACTIONENGINE的框架，通过状态机记忆将GUI代理从反应式执行转变为程序化规划。具体来说，ACTIONENGINE采用了一个新颖的双代理架构：

1. 爬行代理（Crawling Agent）:

• 功能: 在离线阶段探索目标GUI应用程序，构建和维护一个可更新的状态机图（SMG）。
• 实现: 通过系统化的探索，捕获应用程序的内在结构和每个GUI元素的含义，并将这些知识组织为状态机图。状态机图是一个有向图，节点表示符号应用状态（如“主页”、“论坛列表”），边表示GUI操作（如点击按钮以转到另一页）。

2. 执行代理（Execution Agent）:

• 功能: 在在线阶段使用状态机图生成并执行完整的、可执行的Python程序。
• 实现: 给定用户任务和状态机图，执行代理通过提示代码生成的LLM合成一个完整的、可执行的Python程序。该程序通过图搜索和代码生成将高级任务描述转化为可执行程序。

实验设计

1. 实验设置:

• 数据集: 在WebArena基准测试的Reddit子集上进行评估，该子集代表了反应式代理的“长视推理”最坏情况场景。
• 对比基线: 与最先进的反应式基线AgentOccam进行比较，后者使用GPT-4-Turbo进行复杂的提示和基于视觉的交互，但仍依赖于逐步规划而没有结构化记忆。

2. 评估指标:

• 成功率: 任务完成率，由WebArena的评估框架测量。
• 查询延迟: 包括计算和API调用的端到端执行时间。
• 成本: 每个任务的总API成本，根据输入和输出令牌的使用量及模型定价计算。

结果与分析

1. 性能比较:

• 成功率: ACTIONENGINE在Reddit基准测试中达到了95%的任务成功率，显著优于AgentOccam的66%。
• 延迟: 平均任务完成时间减少了50%，从237秒减少到118秒。
• 成本: 平均每个任务的成本减少了11.8倍，从0.71美元减少到0.06美元。
• LLM调用次数: 平均每个任务的LLM调用次数减少了82%，从10.2次减少到1.8次。

2. 详细任务分析:

• 多步推理任务: ACTIONENGINE在需要多步推理和分支逻辑的任务中表现出色，如计算特定论坛中最新帖子的评论数。
• 不明确任务: 在任务描述不明确的情况下，ACTIONENGINE通过系统地遍历状态机图中编码的评论树结构，选择第二层评论，取得了50%的成功率。

总体结论

本文提出的ACTIONENGINE框架通过利用可更新的状态机图作为记忆，将GUI交互转变为确定性的图遍历，从而实现了程序化规划。该方法不仅显著提高了效率，还通过动态、自我修正的更新机制确保了长期鲁棒性。在WebArena基准测试中的实证评估表明，ACTIONENGINE在成功率、延迟和成本方面均优于现有的反应式基线，展示了其在实际应用中的潜力和优势。