PhoneHarness: 通过混合 GUI、CLI 和工具操作来驾驭手机使用代理

TL;DR PhoneHarness 引入混合 GUI、CLI 与工具动作的手机代理基准与执行框架，通过确定性动作路由和可审计跟踪，将可验证工作流通过率提升 12.9 个百分点，揭示可靠自动化不依赖纯视觉 GUI 控制。

问题

问题背景

当前手机使用代理的研究焦点，正从简单的单步动作预测转向面向真实设备的多步骤复杂工作流执行。业界期待代理能在智能助手、自动化测试、无障碍辅助等场景中，自主完成跨应用任务。

现有方法的局限

现有手机代理基准与框架存在三大技术局限：

• 动作空间单一：主流方法将代理视为 GUI控制器，仅关注屏幕截图上的点击、滑动等视觉操作，忽略了设备端命令行（CLI）、结构化工具调用等更高效、更可靠的交互方式。任务评估也仅依赖最终屏幕状态匹配，无法验证动作是否产生了预期的系统级副作用（如文件保存、设置更改或后台状态修改）。
• 路由策略缺失：当任务需要混合使用 GUI、CLI 和 API 工具时，现有方案缺乏统一的 动作路由机制，导致代理难以在不同交互界面间做出最优权衡。例如，在应用中输入长文本时，CLI 模拟输入比逐字 GUI 点击更可靠，但现有框架无法自动决策何时切换。
• 可审计性薄弱：由于缺少结构化的执行轨迹与副作用验证，调试代理行为或建立信任成本极高。模型可能在 GUI 操作中出现幻觉，声称“已成功发送消息”，但实际设备并未产生任何网络包或日志证据。

为什么这个问题既难又重要

手机自动化面临 可靠性 与 安全性 的双重挑战：

1. 动作路由权衡：代理需同时理解屏幕视觉上下文、设备状态和工具语义，并在动态任务中判定最优动作表面。这不仅要求模型具备多模态推理能力，还要求框架能提供确定性的路由边界，防止代理将高风险操作错误委托给 GUI。
2. 可验证执行：手机任务直接操作真实设备，涉及隐私数据和系统权限。仅靠最终答案评估远不够，需要可审计的 副作用证据链（如日志、状态快照），以确保任务“真正发生”且符合安全规范。这对于企业级自动化部署（如金融应用操作、设备批量管理）至关重要。
3. 安全治理：代理必须能识别并拒绝可能产生有害副作用的指令，而现有 GUI-only 评测未涵盖这一维度。

业界对 可靠手机代理 的需求日益迫切，但缺乏统一的基准来同时衡量任务完成度、动作路由合理性和副作用可验证性，这制约了从实验室原型到生产落地的跨越。

行业类比

如同在软件工程中，CI/CD 流水线不仅要求代码编译通过，还需验证部署后的服务状态与日志，手机代理同样需要从“看起来完成”转向“留下可验证执行痕迹”的工程化基准。

核心洞察

• 行动面路由与可验证副作用是手机智能体从 GUI 点击器演变为工作流执行者的关键。当前文献主要将手机智能体视为 GUI 控制器，优化屏幕交互预测，但真实工作流需要组合使用 GUI、CLI 和工具，并确保任务实际完成（如文件保存）。PhoneHarness 通过强制智能体决定行动面并记录可审计轨迹，将重点从“预测下一步动作”转向“完成可验证任务”，这在安全关键的自动化场景中至关重要。与先前仅评估最终答案准确性的基准相比，它衡量的是任务是否产生了预期的世界状态变化，推动了智能体评估向结果导向发展。
• 确定性行动路由与有界 GUI 委派的设计实现了高成功率与可控性的平衡，避免了模型在纯 GUI 探索中迷失。PhoneHarness 不依赖单一大模型在 GUI 空间中无限探索，而是将行动分为确定性的系统命令和需决策的 GUI 动作，并通过有界委派限制 GUI 工人的步骤数。实验表明增益集中在可选 CLI 任务上，说明智能体需要了解何时使用更高效的非 GUI 方法。这种设计模式可迁移到其他具身智能体领域，通过分解行动空间和显式路由提升可靠性，而不仅仅依赖端到端视觉策略。

方法

整体架构与设计理念

PhoneHarness 是一个面向手机使用智能体的混合动作执行框架，其核心理念是：真实手机任务的自动化不能仅依赖 GUI 操作，还需灵活调用设备命令（CLI）和结构化工具，并通过可验证的副作用证明任务完成。框架采用 Host-Device 架构：设备端运行智能体循环，直接操控手机；主机端提供工具服务，如数据库查询或文件处理。

关键模块与执行流程

1. 混合动作空间（Mixed Action Space）

智能体可发出的动作分为三类：

• GUI 动作：屏幕点击、滑动、输入等，用于与应用程序界面交互。
• CLI 动作：通过 Android Debug Bridge (adb) 执行 shell 命令，控制系统级行为（如开关网络、修改设置）。
• 主机端工具动作：调用主机上的 API 或脚本，完成跨设备数据操作等复杂功能。

2. 确定性动作路由（Deterministic Action Routing）

框架不依赖模型凭空选择动作类型，而是通过预定义的策略决定每一步该用哪种动作表面。路由规则综合考虑任务意图、当前屏幕状态和历史动作，将大部分 GUI 操作限制在有界委派（bounded delegation）内，避免陷入无限循环。

3. 渐进式技能披露（Progressive Skill Disclosure）

为避免庞大动作空间对模型的干扰，PhoneHarness 逐步向智能体展示可用工具和 CLI 命令。初期仅暴露基础 GUI 动词，只有在任务涉及特定子系统时才解锁相应技能，从而降低决策难度。

4. 可审计执行跟踪（Auditable Execution Traces）

每一步动作、屏幕截图、CLI 输出和工具返回值均被详细记录，形成完整跟踪链。验证器（verifier）基于这些跟踪检查任务是否产生了可观察的副作用（例如文件是否创建、网络是否关闭），而非仅仅核对最终答案字符串。

与同类方法的差异

传统手机智能体基准（如 AndroidEnv、WebShop）将智能体视为纯 GUI 控制器，评估亦依赖目标应用状态；而 PhoneHarness 首次将 GUI、CLI 与工具动作统一在同一执行回路中，并强调可验证的执行与动作表面路由，使评估更贴近真实工作流，且显著提升了可靠性（75.0% 通过率 vs 最强非混合基线 62.1%）。

实验

实验设计

PhoneHarness 的评估围绕 PhoneHarness Bench 展开，这是一个混合动作基准，涵盖真实手机工作流中的 GUI、CLI 与工具调用。任务要求智能体产生可验证的副作用，而非仅输出合理答案。实验比较了 PhoneHarness 全配置(确定性动作路由 + 有界 GUI 委托 + 可审计轨迹)与多种消融或纯 GUI 控制器的基线，评估在标注的评估分割上的任务完成率。

关键发现

• 混合动作路由显著提升成功率：PhoneHarness 达到 75.0% 通过率，比最强非 PhoneHarness 基线高 12.9 个百分点。
• 增益集中于可选 CLI 任务：需要设备端命令行或工具调用的任务上表现突出，纯视觉 GUI 控制难以完成此类验证型工作流。
• 安全可审计性：框架内置的轨迹日志确保每个动作的副作用可追溯，这在真实设备自动化中至关重要，而纯 GUI 黑盒方案缺乏这一保证。

与基线深度对比

传统移动智能体评测将智能体视为 单一 GUI 控制器，依赖屏幕状态判断成败，忽略了许多现实任务需混合操作面的特性。PhoneHarness 将动作空间扩展至 CLI 与主机端工具，并通过 确定性路由将简单、可程序化操作从语言模型委托中剥离，仅将复杂 GUI 决策留给模型。这种设计不仅提高了可靠性(避免模型在简单 CLI 调用上犯错)，还降低了端到端延迟。同时，有界 GUI 委托防止智能体在不可验证的 GUI 探索中无限循环，而可审计轨迹则使工程师能事后诊断安全性问题。这些机制共同解释了比纯 GUI 方案更高的通过率，揭示了可靠手机自动化的核心不在更强的视觉理解，而在动作面路由与可验证执行的工程化设计。

行业影响

落地场景

PhoneHarness 框架直接瞄准移动端自动化执行与评测，可嵌入以下产品/业务：

• 智能助手与RPA：在手机端完成多步骤工作流（如跨App数据搬运、定时设置），混合GUI点击、CLI命令与Tool调用，确保任务最终状态可验证。
• 自动化测试平台：对移动应用进行回归测试时，不仅验证界面跳转，还能通过CLI检查系统状态、Tool模拟后端交互，覆盖更真实的用户路径。
• 企业移动办公：集成到移动MDM或工作协同工具中，通过可审计的执行轨迹满足安全合规要求，如自动报销、表单审批。

商业价值

• 降本：混合动作路由与可验证执行大幅减少人工介入——一次编写、多次重放的自动化任务可替代重复性人工操作，降低交付与维护成本。
• 增收/体验提升：更高的任务完成率（75.0% pass rate，超过基线12.9个百分点）直接提升用户对语音助手/自动化功能的信任，减少因执行不可靠导致的流失。
• 合规与风控：Auditable Execution Traces 提供了审计依据，对金融、医疗等需留存操作日志的行业意义重大。

与现有产品/工作流的接口

• 对接测试框架：PhoneHarness 可替代或增强 Appium、UI Automator 的执行层，提供统一的 GUI/CLI/Tool 动作派发与验证器。
• 融入AI Agent生态：作为评测基准和运行时，可与 MCP（Model Context Protocol）等工具增强框架结合，为手机Agent提供标准化的工具调用接口与能力分级。
• CI/CD集成：以命令行工具形式嵌入CI管道，自动执行端到端移动工作流并产出结构化报告。

具体落地用例

1. 电商平台大促自动化测试：模拟“搜索商品→加购→领券→提交订单”流程，同时用CLI检查优惠券是否核销、库存扣减是否准确，Tool查询订单状态，PhoneHarness验证最终订单生成与金额正确，避免因UI层假成功而遗漏后端错误。
2. 企业移动差旅助手：员工说“帮我报销上周的Uber行程”，Agent通过GUI打开报销APP，CLI获取行程截图时间戳，Tool调取公司费控API，混合填写并提交表单；PhoneHarness记录每一步的屏幕与系统状态，确保审核时可回溯。

局限

• **任务覆盖范围有限**：PhoneHarness Bench 主要关注可验证副作用的移动工作流，侧重于需要 GUI、CLI 和工具动作组合的任务。这虽然能精确评估代理的执行能力，但可能忽略了那些没有明确可测量副作用的开放式任务（如内容创作、偏好设置），与更通用的 GUI 代理基准（如 Android-in-the-Wild）相比覆盖面较窄，限制了框架在更广泛场景中的适用性。
• **动作空间预定义约束**：PhoneHarness 的混合动作空间依赖预先定义的 CLI 命令和主机端工具，这要求为每个新应用或功能人工定义动作接口。尽管这种确定性路由提高了可靠性，但相对纯 GUI 预测的方法来说，扩展性较差，且难以适应未预见的交互需求，可能需要额外的工程投入来维护动作目录。
• **安全审计的局限性**：虽然 PhoneHarness 通过可审计的执行跟踪和模型配对的拒绝机制增强了安全性，但它并不能完全防止代理产生有害副作用。跟踪记录仅反映已执行的动作序列，而安全策略主要依赖两个模型协同的决策，当模型错误对齐或对抗时仍存在风险，且基准中安全协议的严格程度可能不足以捕获所有真实世界的安全隐患。