PhoneHarness：通过混合 GUI、CLI 和工具操作来驾驭手机使用代理 PhoneHarness: Harnessing Phone-Use Agents through Mixed GUI, CLI, and Tool Actions
提出混合动作空间框架和基准，评估手机代理在真实可验证工作流中的能力
前置知识
MCP (Model Context Protocol)
模型上下文协议是一种标准化的工具调用接口协议，让语言模型能够以统一的方式访问各种外部服务和工具。类似于 API 网关，MCP 定义了工具注册、调用和返回结果的标准格式，使模型可以通过结构化的方式调用搜索、邮件、文档处理等功能，而不需要了解底层实现细节。在 PhoneHarness 中，MCP 代理暴露主机端的工具给设备端的代理使用，这样既保持了手机作为执行环境的核心地位，又能利用主机端更强大的计算能力和服务。
读懂本文需要理解 MCP，因为 PhoneHarness 的核心设计之一就是通过 MCP 风格的工具调用，将主机端的能力暴露给设备端的手机代理，这是实现混合动作空间的关键技术基础。
ADB (Android Debug Bridge)
Android 调试桥接工具是 Android 开发工具包中的一个命令行工具，允许开发者通过命令行与 Android 设备或模拟器进行通信。ADB 支持多种操作，包括安装和卸载应用、传输文件、执行 shell 命令、获取设备日志、截图、模拟触摸和滑动等。在 PhoneHarness 中，GUI 代理将高层次的 GUI 操作（如点击、滑动、文本输入）翻译成 ADB 命令，通过 ADB 与真实 Android 设备交互，实现自动化的手机控制。
理解 ADB 很重要，因为 PhoneHarness 的 GUI 代理是通过 ADB 命令来控制真实 Android 设备的，这是实现真实手机环境交互的技术基础。
Action Surface Routing
动作表面路由是指手机代理在面对一个子任务时，决定使用哪种动作类型来完成的过程。在 PhoneHarness 的混合动作空间中，代理可以在三种动作表面之间做选择：CLI 命令行操作（确定性高，如通过 adb shell 修改设置）、GUI 交互（视觉定位，如点击屏幕按钮）、MCP 工具调用（主机端服务，如发送邮件）。动作路由的核心原则是：如果存在可靠的 CLI 命令或结构化工具调用，优先选择确定性路径；只有在需要应用特定的视觉导航时，才委托 GUI 子任务。这不是简单的选择，而是代理必须具备的核心能力之一。
动作表面路由是 PhoneHarness 的核心创新点和研究问题之一，理解这个概念才能明白为什么混合动作空间比纯 GUI 控制更可靠，以及论文的实验结果为什么显示 PhoneHarness 在某些任务类型上表现更好。
Side-effect Verification
副作用验证是指不仅检查代理是否产生了看似正确的最终答案，而是验证动作是否产生了预期的、可观察的状态改变。例如，在任务要求发送邮件时，验证器会检查是否真的向正确的收件人发送了邮件，而不仅仅是代理声称已完成；在修改系统设置时，验证器会读取实际的设置值，而不是信任代理的输出。PhoneHarness 使用基于追踪的验证器，包括工具调用检查、制品检查（如文件是否存在）、系统设置检查、发送消息检查以及安全检查（如是否有意外的数据泄露）。这种验证方式类似于 OSWorld 等基于执行奖励的基准测试的评估理念。
副作用验证是 PhoneHarness Bench 的核心设计原则，理解这个概念才能明白为什么论文强调评估目标从'模型能否描述解决方案'转向'模型能否完成可验证的闭环任务'，以及为什么 PhoneHarness 与纯 GUI 基准有本质区别。
研究动机
现有手机代理研究主要将手机使用视为屏幕导航问题，代理观察截图或无障碍树，选择点击、滑动或输入操作，并通过最终的 UI 状态来评估。然而，许多真实任务不符合这种形状。例如，'在应用中查找电影，获取额外上映信息，总结结果，并通过电子邮件发送'这个任务跨越了应用导航、外部检索、文本处理和状态改变通信操作。现有方法如 AndroidWorld、AppAgent、Mobile-Agent-v2、MobileAgentBench、Android in the Wild 等虽然在移动 GUI 控制方面取得了显著进展，但它们主要评估的是代理的视觉定位能力，而不是完成真实手机工作流的能力。更重要的是，这些基准只评估最终 UI 状态，不评估实际副作用是否发生——代理可能声称已发送邮件，但实际上邮件从未发送。
本文的目标是本文的目标是提出一个混合动作空间的手机代理执行框架和基准测试，评估代理在真实可验证手机工作流中的能力。具体来说，PhoneHarness 作为执行框架，统一了设备端 CLI 执行、高层次 GUI 委托和主机端 MCP 风格工具调用；PhoneHarness Bench 作为基准测试，构建在 PhoneHarness 之上，评估代理是否能够使用这些动作表面完成带有可观察副作用的工作流，并基于追踪的验证器来验证成功与否。中心研究问题从'模型能否点击下一个按钮'转变为'代理能否在 CLI、GUI 和工具之间路由真实手机工作流，我们能否验证其正确执行'。
与已有工作不同的是，本文的独特切入角度是将手机代理评估框架与基准测试作为两个互补但相互依赖的工件来设计。与纯 GUI 基准（如 Android in the Wild）不同，PhoneHarness 不假设所有手机任务都应该通过点击应用来解决；与通用工具使用基准（如 API-Bank）不同，PhoneHarness 保持手机作为执行环境，将设备状态、应用 UI 和移动副作用作为一等证据。这种双重框架的核心洞察是：手机代理基准只有在底层执行框架能够执行现实的混合工作流时才有意义，而手机代理执行框架只有在基准能够测量其执行是否真正成功时才有用。论文通过实验证明，可靠的手机自动化取决于动作表面路由和可验证执行，而不仅仅是视觉 GUI 控制。
核心方法
PhoneHarness 采用主机-设备分离架构。设备端运行手机代理服务器、代理循环和工具注册表；主机端提供三个代理服务：模型代理将请求路由到选定的语言模型，同时向设备端代理展示 OpenAI 兼容的接口；GUI 代理将高层次的 GUI 操作翻译成 Android Debug Bridge 命令，如截图、点击、滑动、文本输入、应用启动和 UI 树检索；MCP 代理向设备端代理暴露主机端工具，如搜索、邮件、文档和文件处理实用程序。这种架构保持代理锚定在手机环境中，同时避免脆弱的全设备依赖堆栈。与纯 GUI 控制器相比，执行框架在三个方面升级了手机代理循环：通过 CLI 工具保持确定性设备操作可用，仅在需要时委托视觉定位导航，暴露主机端 MCP 工具用于自然涉及外部服务的工作流。
核心创新点是混合动作空间设计和确定性优先路由原则。PhoneHarness 暴露三种混合动作可达模式：GUI 或 CLI 替代任务可以通过视觉应用交互或确定性 shell/Python/ADB 命令完成，让框架在视觉和确定性路径都存在时选择更可靠的路线；GUI 主导 + 可选 CLI 任务保持锚定在 GUI 应用交互，但可以使用 CLI 或 MCP 风格主机工具进行辅助状态检索、制品准备或减少脆弱导航；GUI 仅回退覆盖没有可靠结构化路径的视觉定位子任务，有界 GUI 委托是适当的路径。确定性优先路由原则意味着如果任务可以通过可靠的 CLI 命令或结构化工具调用完成，代理应该优先选择该路径而不是脆弱的 GUI 交互。这不仅是实现细节，而是手机代理的核心研究问题：一个有能力的手机代理不仅需要知道做什么，还需要知道哪个动作表面适合当前子任务。
方法步骤详情
PhoneHarness 的完整执行流程包括以下步骤。首先，任务提交到设备端服务器，每个任务指定自然语言用户请求、目标环境、可选设置信息和一个或多个验证规则。代理没有被告诉使用哪个动作表面，必须决定使用 CLI 命令、GUI 委托、主机工具或组合。在执行过程中，设备端代理循环开始运行，使用渐进式技能披露机制：系统提示包含技能家族的紧凑索引，如设备操作、环境实用程序、邮件、文件处理、网络搜索、地图、社交和文档工作流；当代理需要特定能力时，调用技能加载工具检索相关的使用说明和示例。代理根据确定性优先路由原则，为每个子任务选择动作表面。如果选择 CLI，直接执行确定性命令；如果选择 MCP 工具，调用主机端工具；如果需要 GUI 交互，委托给 GUI 控制器执行有界的视觉子任务。整个执行过程产生外层追踪（记录设备端代理循环的工具调用和结果）和内层追踪（当使用 GUI 委托时，记录截图、操作和 GUI 结果）。基准运行器流式记录执行事件，收集相关制品，应用任务特定的验证器。验证器检查工具调用是否正确、邮件是否发送到正确收件人、设备设置是否达到预期值、生成的制品是否存在并满足大小或内容约束、日历事件是否创建、最终答案是否包含所需信息，以及是否有意外的副作用。
技术新颖性
技术新颖性体现在四个方面。首先是统一的混合动作空间设计，将 CLI 执行、GUI 委托和 MCP 工具调用整合到单个手机代理循环中，这是对现有纯 GUI 手机代理框架的本质扩展。其次是主机-设备分离架构，保持手机作为执行环境的核心地位，同时避免将所有依赖项强制运行在移动环境中。第三是渐进式技能披露机制，解决完整工具表面过大的问题，让代理根据需要动态加载特定技能，这是对现有工具使用代理设计的适应。第四是基于追踪的验证器设计，将追踪和环境作为一等评分证据，这是对基于执行奖励的评估理念在移动工作流中的适配。这些技术贡献共同支持论文的核心研究问题：可靠的手机自动化取决于动作表面路由和可验证执行，而不仅仅是视觉 GUI 控制。
实验结果
在标注的评估分割上，PhoneHarness 达到 75.0% 的通过率，比 MobileClaw 和 Seed2.0-Pro 高 12.9 个百分点，比 AutoGLM-Phone 高 37.9 个百分点。任务类型分解显示收益集中在哪里：PhoneHarness 在设备/系统操作上达到 96.7%，在工具辅助工作流上达到 74.3%，其中确定性 CLI、MCP 工具和验证器支持的副作用是核心；它在视觉定位的单应用 GUI 任务上不是最强：Seed2.0-Pro 在此切片上达到 76.7%，而 PhoneHarness 达到 63.3%；Seed2.0-Pro 和 PhoneHarness 在跨应用工作流上以 65.5% 打平。动作类型分解进一步解释了收益：当 GUI 和 CLI 可以作为替代路线时，PhoneHarness 达到 97.0%；在 GUI 主导任务中 CLI 操作提供可选支持时，PhoneHarness 达到 67.6%。这表明收益来自在暴露确定性替代路线或有用辅助命令行路径的任务上的动作表面路由，而不是来自统一更强的 GUI 控制器。步数计数图片与路由假设一致：PhoneHarness 不是简单地花费更多操作来赢得更多任务；其四舍五入平均是每次尝试任务 23 个执行步，略低于 Seed2.0-Pro 的 24，低于 MobileClaw 和 AutoGLM-Phone。优势在设备/系统操作和工具辅助工作流上最明显，PhoneHarness 使用确定性路径避免长的 GUI 探索。平均运行时间上，PhoneHarness 为每次任务 155 秒（2.6 分钟），每次成功任务 131 秒（2.2 分钟），低于 GUI-only 基线的 202 秒和 MobileClaw 的 172 秒。模型组合评估显示，DeepSeek V4 flash 作为控制器、Seed2.0-Pro 作为 GUI 工作者的组合达到最高整体通过率 74.8%，在 GUI 或 CLI 替代任务上达到 66.7%，在 GUI 主导加可选 CLI 任务上达到 79.1%。安全行为评估显示，HY3-preview 与任一 GUI 模型的配对达到 90.0% 的危险动作拒绝率，而 DeepSeek V4 配对在 80.0% 到 86.7% 之间，表明安全行为对外部编排器和 GUI 控制器都敏感。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Overall Pass Rate (124 tasks) | Pass Rate (%) | 75.0% | MobileClaw: 62.1%, Seed2.0-Pro: 62.1%, AutoGLM-Phone: 37.1% | +12.9% over MobileClaw/Seed2.0-Pro, +37.9% over AutoGLM-Phone |
| Device/System Operations (30 tasks) | Pass Rate (%) | 96.7% | MobileClaw: 93.3%, Seed2.0-Pro: 83.3%, AutoGLM-Phone: 43.3% | +3.4% over MobileClaw, +13.4% over Seed2.0-Pro, +53.4% over AutoGLM-Phone |
| Tool-assisted Workflows (35 tasks) | Pass Rate (%) | 74.3% | MobileClaw: 48.6%, Seed2.0-Pro: 28.6%, AutoGLM-Phone: 20.0% | +25.7% over MobileClaw, +45.7% over Seed2.0-Pro, +54.3% over AutoGLM-Phone |
| GUI or CLI Alternative Tasks | Pass Rate (%) | 97.0% | MobileClaw: 87.9%, Seed2.0-Pro: 81.8%, AutoGLM-Phone: 42.4% | +9.1% over MobileClaw, +15.2% over Seed2.0-Pro, +54.6% over AutoGLM-Phone |
| GUI-primary + Optional CLI Tasks | Pass Rate (%) | 67.6% | MobileClaw: 43.2%, Seed2.0-Pro: 24.3%, AutoGLM-Phone: 16.2% | +24.4% over MobileClaw, +43.3% over Seed2.0-Pro, +51.4% over AutoGLM-Phone |
| Average Runtime | Seconds per Task | 155s | MobileClaw: 172s, GUI-only: 202s | -17s over MobileClaw (-9.9%), -47s over GUI-only (-23.3%) |
| Model Combination (DeepSeek V4 + Seed2.0-Pro) | Pass Rate (%) | 74.8% | DeepSeek V4 + AutoGLM-Phone: 68.7%, HY3-preview + Seed2.0-Pro: 57.3%, HY3-preview + AutoGLM-Phone: 56.5% | +6.1% over DeepSeek V4 + AutoGLM-Phone, +17.5% over HY3-preview + Seed2.0-Pro |
| Dangerous Action Refusal (Safety Tasks) | Refusal Rate (%) | HY3-preview + Seed2.0-Pro: 90.0% | DeepSeek V4 + Seed2.0-Pro: 86.7%, DeepSeek V4 + AutoGLM-Phone: 80.0% | HY3-preview achieves highest safety refusal rate |
局限与改进
作者承认了几个局限性。首先，当前稳定子集比完整候选池小，因为每个任务需要验证器对齐和人工验证。从 181 个任务候选池中，当前报告的稳定子集只有 124 个标注任务。其次，真实应用评估本质上比模拟应用评估更脆弱，因为应用会变化、网络条件会变化、登录或权限状态会影响任务可行性。第三，主机代理使工具访问实用，但也意味着一些能力不是纯粹在设备上。第四，探索性安全子集应该被解释为早期协议测试，而不是最终安全认证。此外，可以观察到论文没有讨论资源使用情况（如电池消耗、内存占用），这对于真实手机部署很重要；也没有讨论框架在不同 Android 版本和设备上的兼容性；安全评估主要基于拒绝率，没有深入分析误报和漏报的具体情况；实验主要关注通过率，但没有分析失败模式在不同任务类型上的分布细节。
独立分析的弱点
在工具辅助工作流上，PhoneHarness 虽然达到 74.3%，但仍有 25.7% 的失败率，这些失败集中在脆弱的 GUI 重场景中：长的单应用导航、跨应用复制粘贴、登录或权限门、广告、超时，以及调用了工具但手机端副作用未被验证的情况。改进方向可以包括更好的 GUI 导航策略（如使用视觉语义理解而不是纯坐标点击）、更强的权限处理能力、广告检测和跳过机制、超时重试和恢复策略。在跨应用工作流上，PhoneHarness 达到 65.5%，与 Seed2.0-Pro 打平，表明某些 GUI 重多应用任务仍然有利于专门的手机使用模型。改进方向可以包括更好的跨应用状态管理、剪贴板操作优化、应用切换效率提升。在安全评估方面，虽然 HY3-preview 达到 90% 的拒绝率，但其他模型组合只有 80-87%，且论文没有详细分析误拒绝（拒绝安全操作）和误接受（执行危险操作）的具体情况。改进方向可以包括更精细的安全分类、上下文感知的安全决策、用户偏好学习。此外，框架目前没有考虑资源约束（电池、内存、网络），这在真实手机部署中是关键问题，可以引入资源感知的动作调度和任务优先级管理。框架也没有讨论并发任务处理，未来可以支持后台虚拟显示，让代理在不抢占用户前台屏幕的情况下工作，这需要更复杂的资源调度和冲突处理机制。
未来方向
作者提出的未来工作方向包括扩展验证任务集、加强验证器覆盖、改进安全协议以及研究替代框架设计如何影响手机代理准确性和效率。基于论文成果，可以延伸出多个研究方向。首先，虚拟显示支持指向产品形式，其中手机代理在独立的背景显示器上工作而不占用用户的前台屏幕。如果变得稳健，这将把手机代理从演示风格屏幕控制转向并发移动辅助。然后，基准可以评估代理不仅能否完成任务，还能否在不干扰用户活动手机会话的情况下完成任务。其次，可以研究更复杂的动作表面路由策略，如学习型路由器，根据任务特征和当前环境状态动态选择最优动作表面。第三，可以扩展任务类型和领域，如引入更多真实应用、更多跨应用工作流场景、更多安全敏感任务。第四，可以研究多用户和隐私保护场景下的手机代理行为，如多人共享设备时的代理行为约束、隐私敏感操作的细粒度控制。第五，可以探索手机代理与桌面代理的协同工作，如在手机和桌面之间无缝切换的工作流。第六，可以研究更细粒度的验证器设计，如基于语义理解的验证、基于用户反馈的验证、基于历史行为的验证。第七，可以引入长期记忆和学习机制，让代理能够从过去的执行中学习，提高后续任务的效率。第八，可以研究自适应的渐进式技能披露，根据代理的能力和任务复杂度动态调整技能加载策略。
复现评估
论文在复现性方面提供了项目网站（https://phoneharness.github.io/），但没有在论文正文中明确说明开源情况。从方法描述来看，PhoneHarness 使用主机-设备架构，需要 Android 设备或模拟器、主机端服务器、模型代理、GUI 代理和 MCP 代理，这意味着复现需要一定的硬件和软件环境配置。算力需求取决于所选的语言模型，论文使用了 Seed2.0-Pro、DeepSeek V4 flash、HY3-preview、AutoGLM-Phone 等模型，这些都是需要 GPU 资源的大型语言模型。数据方面，PhoneHarness Bench 从 181 个任务候选池中构建，当前报告 124 个标注任务，包括 14 个模拟应用任务、45 个真实应用任务、30 个探索性安全任务。论文没有明确说明数据集是否公开，但提到了基于注释表的任务分类和验证器对齐。复现难度中等，主要挑战在于搭建主机-设备环境、配置各种代理服务、集成不同的语言模型、以及真实应用评估的脆弱性（应用变化、网络条件、登录状态等）。如果项目网站提供完整的代码、配置文件和任务数据，复现应该是可行的，但需要投入一定的环境配置时间。
论文图表