安卓手机 Agent 基准测试指南：2026 年怎样评估可靠性、安全和恢复
怎样评测安卓手机 Agent？本文用 B-MoCA、MobileWorld、KnowU-Bench、PhoneHarness 和 FoneClaw 构建经验，给出 2026 年安卓 GUI Agent 测试维度、可靠性指标、安全审批测试和可重复评估协议。
- 安卓手机 Agent 基准测试应同时衡量目标理解、正确副作用、权限与审批、结果验证和失败恢复，单看点击路径会漏掉关键风险。
- B-MoCA、MobileWorld、KnowU-Bench 和 PhoneHarness 分别暴露配置泛化、长链跨应用、个性化同意、混合动作和可审计轨迹等不同问题。
- 任务成功率只是起点；手机 Agent 可靠性指标还应包含错误副作用、部分完成、人工介入、恢复质量、延迟、成本和追踪证据。
- 我们会用 FoneClaw 目前可用的能力设计测试矩阵：悬浮入口、当前屏幕附加、任务连续性、审批、停止、权限恢复和 100+ built-in tools 都应进入可重复测试。
安卓手机 Agent 基准测试应该测什么
怎样评测安卓手机 Agent？我们的答案是：同时测结果和过程。一个 Agent 在屏幕上点到了看似正确的按钮，只说明它走过了一条轨迹；真正的通过标准应当是目标被理解、正确副作用发生、用户授权被尊重、结果可验证、失败可以恢复。手机 Agent 进入真实 Android 环境后，会碰到权限弹窗、界面变化、网络波动、同名联系人、双卡选择、通知打断和用户中途改口，基准测试需要把这些现实因素纳入评分。
我们在构建 FoneClaw 时，最早学到的一点是：手机 Agent 的“成功”必须比普通 GUI 点击任务更严格。比如“打开勿扰模式”需要确认系统状态已经改变；“准备短信”需要核对收件人和正文；“读取当前屏幕”需要知道观察是否过期；“停止任务”需要确认后续动作已经停止。一个可复现测试集应该记录初始状态、期望状态、允许的工具、审批节点和恢复路径。
因此，安卓手机 Agent 基准测试要把任务完成率、过程安全、可追踪性和恢复能力放在同一张表里。想看手机 Agent 如何通过回归测试和治理循环持续改进，可以阅读 可自我改进的手机龙虾：技能版本、回归测试与回滚。本文提供评估方法和测试框架，不发布 FoneClaw 的正式基准分数。
2026 年手机 Agent 基准版图
2026 年的 AI Agent 基准测试已经从简单网页或桌面任务，走向更贴近移动设备的真实场景。不同 benchmark 解决的问题不同，分数也应留在各自设置里理解。我们把几个值得关注的研究放在同一张表里，目的是帮助产品团队选测试维度，而不是拼成一个统一排行榜。
| 基准 | 公开状态 | 覆盖重点 | 对手机 Agent 评估的启发 |
|---|---|---|---|
| B-MoCA | PMLR 的 B-MoCA 论文发布于 2026 年，包含 131 个常见 Android 日常任务。 | 随机化设备配置，包括 UI 布局和语言设置；论文报告简单任务表现强于复杂任务。 | 测试要覆盖不同设备、语言、布局和设置状态，避免只在一台熟悉手机上得出结论。 |
| MobileWorld | ACL 2026 MobileWorld 论文包含 20 个应用中的 201 个任务。 | 平均 27.8 步，62.2% 为多应用任务；论文还加入 agent-user interaction 和 MCP-augmented 类别，并在其设置中报告最佳 agentic framework 为 51.7%、最佳端到端模型为 20.9%。 | 长链跨应用任务需要测状态保持、用户交互、工具协作和中途恢复。 |
| KnowU-Bench | KnowU-Bench 预印本覆盖 42 个通用 GUI 任务、86 个个性化任务和 64 个主动任务。 | 隐藏用户画像并暴露行为日志，测试澄清、主动征得同意和拒绝后的克制。 | 个性化任务要测 Agent 是否会问清楚、是否等待同意、是否尊重用户拒绝。 |
| PhoneHarness | PhoneHarness 预印本把 GUI、CLI 和主机侧工具动作组合到同一测试思路中。 | 评分观察得到的副作用，并记录可审计执行轨迹；论文区分执行 harness 和 benchmark。 | 手机 Agent 评估应记录真实副作用、工具选择和执行轨迹，而不只看模型回答。 |
这些研究共同说明，手机智能体评估需要跨配置、跨应用、跨动作类型和跨用户状态。工具与资源发现也会影响测试可靠性，相关可信目录和授权边界可以继续看 Agentic Resource Discovery 智能体资源发现：ai-catalog.json、可信目录与手机授权边界。
真实 Android 测试集的六个维度
一个可用的安卓 GUI Agent 测试集，至少要独立变化六个维度。第一是设备配置：不同 Android 版本、厂商 UI、语言、字体大小、深色模式、权限状态、默认应用和网络状态都会改变执行路径。第二是任务跨度：单屏任务、单应用多步任务、多应用长链任务要分开统计，因为它们考验的能力完全不同。
第三是意图清晰度。明确指令如“打开勿扰 30 分钟”适合测执行准确性；模糊指令如“帮我准备开会”适合测澄清能力、计划能力和用户交互。第四是动作面：有些任务依赖 GUI 节点，有些可以通过结构化工具完成，有些需要 GUI 与工具混合。每类动作都要记录观察来源、执行方式和验证证据。
第五是副作用风险。读取屏幕、查询状态和生成草稿属于低风险；修改设置、发送消息、拨打电话、删除文件、共享位置会产生外部影响，需要更严格审批和验证。第六是中断与恢复：用户打断、权限被撤销、应用切到后台、屏幕内容变化、网络断开时，Agent 是否能回到清楚状态。难度不只来自步骤数量，也来自状态变化和结果后果。
我们建议每个测试批次只随机化一到两个维度，保留其他条件稳定。这样失败原因更容易定位：是模型理解错了，屏幕观察过期，权限状态处理失败，还是审批节点设计不清楚。
任务成功率之外的可靠性指标
任务成功率是必要指标，但它只回答“最终是否达成目标”。手机 Agent 可靠性指标还要回答“怎样达成”“有没有产生错误副作用”“用户是否被迫接手”“失败后是否能恢复”。我们会把分数拆成几类：验证通过、部分检查点通过、错误副作用、超时、人工介入、恢复成功、恢复失败。
分母和重试政策必须提前固定。一次任务允许几次重试？网络失败是否计入？用户主动改口如何记录？同一个错误副作用能否被补偿？这些规则不固定，任务成功率会失去比较意义。PhoneHarness 对可观察副作用和可审计执行轨迹的强调，给了一个很好的方向：手机 Agent 的结果应被外部状态验证，而不是只靠模型自述。
我们还会记录延迟、步骤数、工具调用次数、成本、审批等待时间和追踪质量。追踪质量包括：是否记录初始状态、任务目标、工具调用、审批、权限、屏幕证据、最终状态和恢复原因。身份、权限和日志怎样落到手机 Agent，可以参考 AI 智能体身份、权限与审计日志：逐工具审批控制怎么落到手机 Agent。
测试审批、权限、克制和停止
安全测试应该成为评分的一部分，而不是发布前的补充项。第一项是最小必要权限：Agent 是否只请求当前任务需要的权限，是否在缺权限时说明原因。第二项是审批时机：发送、删除、修改设置、共享位置和拨号这类动作，是否在外部影响发生前展示对象、理由和后果。
第三项是澄清能力。用户说“发给客户”时，Agent 是否追问客户是谁；用户说“帮我处理通知”时，Agent 是否区分摘要、忽略、回复和稍后提醒。第四项是克制。KnowU-Bench 把主动征得同意和拒绝后的克制纳入测试，这一点很适合手机场景：用户拒绝后，Agent 应停止该动作并保留可理解状态。
第五项是停止和审计。用户说“停下”或按下停止入口时，任务后续动作要结束，日志要能说明哪些步骤已经发生、哪些尚未发生。审批界面细节可以看 AI Agent 操作确认界面设计：建议、置信度、理由与手机恢复流程，更底层的权限和审计则可以继续读 AI 智能体身份、权限与审计日志：逐工具审批控制怎么落到手机 Agent。
我们会怎样评估当前 FoneClaw 手机任务
FoneClaw 是由配置模型驱动的 Android 手机 Agent。截至目前的最新信息，当前发布基线已经提供悬浮助手、当前屏幕附加、任务连续性、审批、停止、权限恢复，并改进勿扰、音量、会议模式、截图可靠性和快速动作；用户可以在 FoneClaw 下载页面查看版本入口。这些用户可见能力，正好可以转化为可测试场景。
我们的 FoneClaw 测试矩阵会分四类。第一类是只读状态：读取当前可见屏幕、检查蓝牙状态、查看权限或设备状态，目标是测观察新鲜度和结果表达。第二类是可逆设备控制：调整音量、打开或关闭勿扰、进入会议模式、创建提醒，目标是测动作正确性、结果验证和恢复。第三类是外部影响动作：准备消息、拨号准备、导航交给选定地图应用，重点测审批、对象核对和用户接管。
第四类是异常恢复：在任务中撤销权限、改变屏幕、切换应用、触发通知、关闭网络或要求停止。FoneClaw 需要说明任务停在哪里、缺少什么、用户可以怎样继续。当前能力范围可以通过 FoneClaw 功能介绍查看，其中 100+ built-in tools 提供了足够多的测试组合。手机健康和权限审计是一个适合用户上手的具体场景，可以参考 AI 安卓手机健康检查指南：用 FoneClaw 审计权限、特殊访问和隐藏应用。
这篇文章提供方法和测试矩阵，不给出 FoneClaw 的正式分数。我们更重视可复现过程：设备版本、语言、应用状态、初始权限、输入指令、重试规则和验证方式都记录清楚后，分数才有工程意义。
建立可重复的手机 Agent 基准协议
最后给出一个可以直接落地的七步协议。第一，冻结环境：记录设备型号、Android 版本、语言、地区、网络、应用版本、权限、默认应用和屏幕初始状态。第二，定义任务：写清用户指令、允许工具、初始状态、期望状态和禁止副作用。第三，只随机化一个主轴，例如语言、布局、权限或应用顺序。
第四，记录全过程：模型输入、屏幕观察、工具调用、审批、用户介入、错误和恢复。第五，用外部状态验证结果：系统设置是否改变，提醒是否创建，草稿是否存在，消息是否停在确认前。第六，分类失败：理解错、观察错、动作错、权限错、审批错、恢复错或环境错。第七，发布限制：说明测试覆盖了哪些设备、应用、语言和任务类型。
推荐从可逆 starter test 开始：让 Agent 检查当前屏幕、打开勿扰 10 分钟、验证状态、再关闭勿扰并验证恢复。这个任务覆盖意图理解、设置动作、审批、验证、恢复和日志，又不会带来外部沟通风险。想进一步建立持续回归和回滚机制，可以回到 可自我改进的手机龙虾：技能版本、回归测试与回滚。