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

一、评测概述

近期，某模型团队在某社区平台发布了约90亿参数规模、采用宽松开源许可证的手机操作智能体，声称能够以一句自然语言指令自治完成从点外卖到订机票等多步任务，支持本地或云端部署、多模态屏幕理解，并通过远程设备调试通道实现跨设备操作。这类”能真正操作手机”的智能体，正在从对话式问答走向端到端任务自动化。

本文要评测的对象，正是这一类具备图形界面理解与操作能力的智能体（GUI Agent）。评测不是简单判断”好不好用”，而是帮助读者理解：这类智能体在真实业务中是否可靠、是否可控、是否值得引入。

本文适合以下读者：

• 希望评估是否引入智能体自动化能力的开发者与架构师；
• 负责选型决策的技术负责人；
• 关注数据安全与合规的运维及安全团队；
• 计划在移动端业务中落地自动化流程的企业技术团队。

二、评测目标

本次评测重点回答以下问题：

1. 能力边界：该智能体到底能完成哪些任务，不能完成哪些任务？
2. 可靠性：多步任务的成功率、稳定性与容错表现如何？
3. 安全性：在需要账号、密码、联系人等敏感信息时，数据是否可控？
4. 可运维性：部署方式、观测能力、故障排查是否满足工程化要求？
5. 成本结构：本地与云端两种模式的资源、人力与长期维护成本如何权衡？

三、评测对象说明

手机操作智能体的核心工作链路通常包括：理解自然语言指令 → 截屏并解析界面 → 规划操作序列 → 执行点击/输入/滑动 → 观察结果并判断是否完成。

与传统脚本自动化（依赖固定坐标或控件ID）不同，这类智能体依赖多模态模型”看懂屏幕”，因此在界面改版、动态内容、弹窗干扰等情况下具备一定鲁棒性，但也引入了不确定性。理解这一点，是设计评测方法的前提。

四、评测维度设计

建议从以下维度构建评测框架，每个维度都应可观察、可验证、可解释：

评测维度	关注点	验证方式
功能完整性	是否覆盖典型任务流程	逐条走通预设业务用例
指令理解准确性	自然语言意图识别是否准确	用歧义/口语化指令测试
屏幕理解准确性	是否能正确识别界面元素	注入改版/异常界面验证
任务闭环能力	多步任务能否端到端完成	记录步骤完成率与中断点
稳定性	长时间/重复运行表现	循环执行同一任务观察漂移
异常容错	网络波动、弹窗、加载失败时表现	主动注入异常场景
安全性	敏感数据处理与权限控制	审查数据流与凭证管理
可观测性	日志、轨迹、可回溯能力	检查操作轨迹是否可审计
易用性	接入与配置复杂度	记录从部署到首个任务的成本
成本结构	本地/云端资源与运维成本	分别核算两种模式

五、评测环境与前提

设计评测前需明确以下条件，否则结论不可比：

• 设备与系统：明确测试终端型号、系统版本、分辨率与屏幕尺寸，因为界面解析结果对分辨率敏感；
• 部署模式：区分”完全本地运行”与”云端调用”，两者的延迟、数据边界、资源占用差异显著；
• 网络条件：固定网络带宽与延迟基线，避免把网络波动误判为模型能力问题；
• 账号与数据：使用测试账号与脱敏数据，切勿在评测中使用真实凭证；
• 测试边界：限定可访问的应用范围，防止智能体执行越权或危险操作。

六、评测方法

6.1 建立基线

先在稳定网络、干净环境下记录基础表现（如简单单步任务成功率、响应时间），作为后续对比的参照。

6.2 分维度验证

• 功能验证：设计覆盖”单步—多步—条件分支”的任务集，例如打开某应用、搜索、加入购物车、提交；
• 压力与稳定性：对同一任务重复执行多次，观察是否出现步骤漂移、误点击、循环卡死；
• 异常测试：主动注入加载失败、弹窗广告、网络中断，观察恢复能力；
• 安全检查：审查智能体是否需要明文读取凭证、是否将屏幕内容外传、操作轨迹是否可审计。

6.3 结果记录

建议用结构化方式记录每次运行，便于复盘：

# 通用评测记录框架（示意，非特定产品接口）
def run_task(agent, task, env):
    result = {
        "task": task.name,
        "success": False,
        "steps_total": 0,
        "steps_done": 0,
        "interrupted_at": None,
        "error": None,
    }
    try:
        trace = agent.execute(task.instruction, env)
        result["steps_total"] = len(trace)
        result["steps_done"] = sum(1 for s in trace if s.completed)
        result["success"] = trace.final_state == task.expected_state
        result["interrupted_at"] = trace.first_failed_step
    except Exception as e:          # 记录异常而非直接崩溃
        result["error"] = str(e)
    return result                   # 汇总后再做统计与解读

6.4 控制变量

每次只改变一个变量（如仅改网络、仅改屏幕分辨率），保证结果可归因。

七、结果解读

评测结论必须结合条件表达，避免绝对化判断：

• 任务成功率高，说明在已覆盖的场景内能力较强，但需注明”仅限测试样本范围”，样本外的界面与流程不保证同等表现；
• 步骤完成率低于最终成功率，通常意味着存在冗余或纠错步骤，需结合轨迹分析原因；
• 响应时间差异可能来自部署模式、网络链路、界面复杂度或模型资源占用，不能直接归因于”模型好坏”；
• 若智能体在异常注入下频繁中断且无法恢复，说明其在真实波动环境中稳定性不足，需谨慎用于生产。

八、适用场景分析

场景	重点评测指标	说明
个人效率自动化	指令理解、易用性	追求”说一句话就完成”
企业批量流程	稳定性、可观测性	需可回溯、可审计
敏感数据场景	安全性、数据隔离	凭证与联系人处理是关键
跨设备运维	兼容性、权限控制	远程调试通道需严格鉴权

正如原始讨论中所提出的担忧：若智能体需要接触账号密码、联系人、操作习惯等敏感信息，安全性就无法回避。因此，在数据安全要求高的场景中，应优先验证”是否支持完全本地运行””操作数据是否外传””是否具备权限隔离与日志审计”等能力——这些往往比任务成功率更能决定能否落地。

九、风险与限制

• 样本偏差：测试任务集无法覆盖真实世界的全部界面与流程；
• 环境差异：不同设备、系统版本、分辨率会显著影响屏幕理解结果；
• 数据质量：界面元素模糊、动态内容、反自动化机制都会干扰判断；
• 长期不确定性：应用改版、系统更新可能使原本可用的流程失效；
• 安全风险：智能体一旦获得过高权限，误操作或凭证泄露的后果被放大。

十、选型与使用建议

基于通用评测逻辑，给出如下中立建议：

1. 先小范围验证再扩展：从低风险、非敏感任务开始，逐步放宽权限；
2. 本地优先评估敏感场景：对涉及凭证与隐私的任务，优先验证完全本地运行方案；
3. 建立操作审计：无论采用何种方案，都应保留可追溯的操作轨迹；
4. 持续回归测试：将任务集固化为回归用例，在版本升级后重复评测；
5. 成本双维度核算：同时评估云端调用成本与本地部署的算力、运维投入。

十一、总结

手机操作智能体代表了从”对话”走向”执行”的重要方向。对其评测，不能停留在”能做什么”的功能演示，而应围绕指令理解准确性、屏幕理解鲁棒性、任务闭环能力、稳定性、安全性与可观测性建立可验证的框架，并通过控制变量、结构化记录和条件化解读得出结论。最终是否引入，取决于业务场景对成功率、数据安全与长期维护成本的综合权衡——没有普适的最优解，只有与场景匹配的合适解。