手机智能体评测指南：维度、方法与适用边界

一、评测概述

近期一类新的技术形态受到开发者关注：以多模态模型为核心、能够”看懂屏幕再动手”的手机智能体。它接收一句自然语言指令，自主完成界面感知、动作决策与执行反馈的闭环，从而端到端地做完点外卖、订机票这类多步任务；部分方案还开放了宽松许可的十亿级参数模型（如 9B 量级），并支持本地或云端部署，以及通过远程真机调试通道实现跨设备的界面操作。

这类演示很容易让人产生”能力已经完成”的印象，但评测要回答的并不是演示是否惊艳，而是它能否在你自己的设备矩阵、业务流程和合规约束下稳定交付。

• 评测对象：能自主操作移动设备界面的端到端智能体（业界常称 GUI Agent / 手机智能体）。
• 适用读者：做能力验证与方案选型的开发者；关注总体架构与集成成本的架构师；负责稳定性、监控与权限治理的运维与 SRE；负责投入产出与合规边界的技术负责人。
• 评测性质：本文不判断”好与不好”，而是给出一套可执行的验证流程、指标定义和结论边界。

二、评测目标：这份评测要回答哪几个问题

1. 功能完整性：常见任务类型是否被覆盖，指令解析到执行完成的链路是否闭合。
2. 有效性：在真实界面上完成任务的成功率如何，失败集中在哪一步。
3. 效率：完成同一任务需要多少步、多少 Token、多长时间。
4. 稳定性：界面改版、加载缓慢、弹窗打断、网络抖动时的容错表现。
5. 安全性：当智能体掌握账号密码、通讯录与操作习惯时，权限边界是否可控。
6. 可运维性：日志、追踪、失败归因、版本升级是否够用。
7. 成本结构：算力、人力、迁移与长期维护的综合代价。

三、评测对象拆解：能力链路由哪几段构成

把智能体拆成可独立观察的环节，是后续所有指标的前提：

环节	做什么	常见失败模式
界面感知	截屏、识别控件与文本、建立可点击元素集合	图标误识别、相似控件混淆、长列表漏元素
指令理解	把自然语言映射为可执行目标与子目标	指代不明、隐含前提缺失、多目标优先级错乱
动作规划	决定下一步点击/滑动/输入/返回	路径冗余、死循环、跳过必要前置步骤
动作执行	通过调试通道或注入层真实操作设备	坐标漂移、点击未生效、时序竞态
状态校验	判断上一步是否成功、页面是否到达预期	误判成功、把加载中当完成
异常恢复	处理弹窗、广告、验证码、登录失效、超时	无兜底策略、放弃后状态残留
结束判定	判断是否达成目标并提交结果	过早结束或无限延续

四、评测维度设计

维度	关键指标（示意）	为什么重要
功能完整性	覆盖任务类型数、支持的设备/系统版本数、是否支持长链路任务	决定能否进入业务流程
有效性	端到端任务成功率、关键步骤命中率、误操作率	决定业务可否接受
效率	平均步数、平均耗时、Token 与截图消耗	直接换算成成本
稳定性	连续运行时长、重试成功率、界面改版扰动下的成功率衰减	决定长期可用性
安全性	凭据暴露面、权限最小化程度、敏感数据是否落盘、审计可追溯性	决定合规能否通过
兼容性	与现有自动化脚本、账号体系、日志与监控体系的对接成本	决定集成周期
可观测性	是否可按步骤回溯、能否定位到具体截图与决策依据	决定故障排查效率
可维护性	模型/提示词/动作空间的升级方式、回归测试手段	决定长期维护成本
成本结构	推理算力、设备资源、人力运维、迁移成本	决定总拥有成本

五、评测环境与前提

评测前必须把变量固定下来，否则结论无法复现：

• 设备矩阵：至少覆盖高/中/低端各一类机型、两类主流系统版本、两种屏幕尺寸与分辨率，记录系统版本与厂商定制层差异。
• 网络条件：分别在高带宽、弱网、高延迟场景下执行同一任务集。
• 账号与数据：使用专用测试账号与脱敏数据；所有涉及支付、下单、发送消息的步骤，在评测阶段应替换为可回滚的沙箱流程或人工确认模式。
• 推理位置：本地推理与云端推理必须分别跑一轮，因为二者的时延、成本与数据边界完全不同；云端形态可结合百度智能云上的云服务器、容器平台、对象存储、日志服务、监控告警等通用产品能力搭建可复现的评测环境。
• 对照基线：与”人工手工操作耗时/步数””传统脚本自动化（固定坐标或控件树方案）”两条基线对比，否则无法说明智能体的增益来自哪里。
• 测试边界：明确写清哪些能力不在本轮评测范围内（如验证码、支付确认、涉及第三方协议的行为），避免结论被过度外推。

六、评测方法

6.1 任务集设计

任务集是分层的，建议按”冒烟 → 核心 → 长链路 → 扰动”四级构造，每级固定样本量并冻结版本：

层级	示例任务	成功判据
冒烟	打开某类应用并搜索指定关键词	结果页出现目标条目
单应用	在列表应用中筛选、排序、翻页	筛选条件与结果一致
跨应用	从消息中复制地址 → 在地图类应用查询路线	目的地正确、路线已生成
长链路	完成一次下单前的全流程（止于支付确认前）	订单页金额与配置正确
扰动	中途插入权限弹窗、弱网、前后台切换、界面改版	是否恢复并继续，是否误操作

成功判据必须是机器可判定的（页面文本、状态字段、订单号），而不是”看起来对了”，否则不同评测者会得出不同结论。

6.2 通用评测驱动（示意伪代码）

tasks = load_task_set("smoke_v1")        # 冻结的任务集版本
results = []
for task in tasks:
    reset_device(task.precondition)      # 清理后台、回到已知首页状态
    reset_account_state(task.account)    # 使用专用测试账号
    trace = run_agent(
        goal=task.instruction,
        max_steps=task.budget,           # 步数预算，防止无限循环
        hitl=task.require_confirm,       # 高风险动作是否需人工确认
    )
    ok, evidence = judge(task.success_criteria, trace)
    results.append({
        "task_id":      task.id,
        "success":      ok,
        "steps":        trace.step_count,
        "invalid_acts": count_invalid_actions(trace),   # 无效点击、回退、重复
        "recoveries":   trace.recovery_count,           # 弹窗/超时自恢复次数
        "interventions": trace.human_interventions,     # 人工介入次数
        "latency":      trace.total_latency,
        "cost_units":   trace.tokens + trace.screenshots,
        "ui_variant":   task.ui_version,                # 是否命中改版扰动
    })
report(results, baseline={"human": HUMAN_BASELINE, "script": SCRIPT_BASELINE})

6.3 评测执行纪律

1. 控制变量：同一轮只改一个因素（模型版本 / 推理位置 / 动作空间 / 提示策略）。
2. 多次重复：同一任务重复多次，观察成功率方差；单次成功不能算能力证明。
3. 过程留存：每一步保留截图、控件集合、模型决策与执行结果，这是失败归因的唯一依据。
4. 安全与稳定性专项：注入异常（弹窗、加载失败、账号失效、断网恢复），观察是否需要人工兜底。
5. 回归机制：界面改版后重跑同一任务集，度量能力衰减幅度。

七、结果解读：什么样的结果才算”能力较强”

• 成功率要看分布，不看均值。若核心任务成功率稳定、方差小，说明能力可用；若均值尚可但方差大，说明依赖偶然因素，不适合无人值守。
• 步数比耗时更能说明规划质量。步数显著高于人工或脚本基线，通常意味着规划器在做无效探索，而非”更谨慎”。
• 无效动作率与恢复次数是关键诊断量。它们直接指向感知层误识别、状态校验缺失或超时策略不合理。
• 失败要归因到环节。把失败样本按第一节的七个环节归类，才能判断是模型问题、感知问题还是执行通道问题——这三者的解决路径完全不同。
• 性能差异通常来自工程因素：截图分辨率与压缩策略、视觉编码开销、推理位置与网络链路、等待策略是否引入固定延迟、设备渲染速度、并发模型是否排队。评测时应把这些因素与”模型本身能力”分开记录。
• 条件化结论：任务集中在单一应用内时，脚本方案往往更划算；跨应用、界面多变、需要理解自然语言的场景，才更能体现智能体的价值。

八、安全性专项评测（决定能否交出账号）

这是该类技术能否普及的核心，也是必须单独设计评测的部分：

检查项	验证方法	期望结果
推理数据边界	断网/抓包观察截图与文本是否离开设备	本地模式下屏幕数据不出端
凭据处理	观察账号密码在日志、缓存、内存转储中的留存	不落明文、不进日志
权限最小化	审查其可被调用的动作集合与系统权限	高风险动作可禁用/需二次确认
动作白名单	尝试触发支付、删除、发送类动作	被拦截或要求人工确认
审计可追溯	复盘一次失败任务	可还原每一步决策与执行
沙箱隔离	在测试容器/测试账号中运行	影响面限于测试环境
会话与密钥管理	检查凭据轮换与失效机制	可轮换、可即时吊销

“黑箱本地运行、不开放任何外部访问”是评测中应重点验证的假设，而不是默认前提——必须通过断网与流量观测加以证实。在评测未通过前，建议以测试账号、专用设备、可回滚流程为运行边界。

九、适用场景与关注重点

场景	优先关注的指标
内部效率工具、个人助理	效率、易用性、失败恢复体验
测试与验收（界面回归、兼容性验证）	可重复性、任务集覆盖、可观测性
无障碍辅助	感知准确性、误操作率、可解释性
客服与业务流程辅助	稳定性、审计、权限控制
高敏感业务（金融、账号类操作）	安全隔离、人工确认、合规审计

十、风险与限制

• 样本偏差：任务集若来自少数开发者习惯，结论无法外推到真实用户分布。
• 界面漂移：应用改版会持续削弱基于视觉感知的方案，评测结论有保质期。
• 评测污染：真实环境中的推荐流、活动弹窗会影响可重复性，需在可控环境中评估。
• 长期不确定性：长周期运行下的资源泄漏、状态残留、累积误操作，短测难以暴露。
• 合规差异：不同业务的账号协议与数据合规要求不同，结论不可跨场景照搬。

十一、选型与使用建议

1. 先用小规模任务集做能力探测，再决定是否投入完整评测。
2. 把”是否支持本地推理””是否有动作白名单与人工确认””是否有步骤级日志”作为硬性准入项。
3. 明确人机分工：低风险只读任务可自动执行，写操作与资金相关动作保留人工确认。
4. 建立回归任务集，将界面改版纳入常态化验证。
5. 成本与收益按总拥有成本核算，包含算力、设备、运维与失败返工的人力。

十二、总结

手机智能体的价值在于把”自然语言意图”翻译成”真实界面操作”，其能力由感知、规划、执行、校验、恢复五段链路共同决定。评测这类技术，应从任务成功率、步骤效率、稳定性、安全性、可观测性、可维护性与成本结构出发，通过分层任务集、固定环境、控制变量与步骤级留痕来获得可复现结论。判断标准不是演示中的一次成功，而是在你的设备、你的数据边界与你的合规要求下，它能否长期、可审计、可回滚地完成工作——这既是能力评估的落点，也是该类技术能否真正普及的前提。