手机端 Agent 评测：从方法论到工程实践

手机上的 Agent 跟聊天机器人最大的区别在哪？一句话：它真会动手操作你的手机。

用户说"帮我设个明早 7 点的闹钟"，Agent 不是回一句"好的已设置"就完事了——它得正确计算时间、调用系统接口、传入正确参数，最终手机上真的多出一个闹钟。而且，同样的 query 执行两次，每次的路径可能都不一样，这就给评测带来了不小的挑战。

过去三个月，在手机 Agent 上搭建了一套完整的评测体系。这篇文章就来聊聊踩过的坑、最终跑通的方案，以及用数据验证过的效果。

三个月评测下来，提升效果还是很明显的：

指标	半年前	现在
端到端完成率	56.5%	70.7%
平均响应耗时	25s+	10s+
工具命中率	17.7%	56.3%
评测结果波动	6%	0.2%

下面展开讲是怎么做到的。

一、我们在测什么：5 类能力 × 1000 条评测集

手机Agent的能力不是铁板一块。拆开来看，它需要：听懂用户意图、选对工具、传对参数、拿到结果、组织回复。不同场景考的能力环节完全不同。

基于这个链路，设计了评测集的构成：

经验：评测集设计的 5 个原则

• 覆盖率比数量重要
  。1000 条精心设计的 case 比 5000 条随机抽样有效得多。按"能力环节 × 难度梯度 × 边界条件"三维组合设计，确保每个工具的正常路径和异常路径都有覆盖。

• 高频场景多测稳定性，低频场景测覆盖度
  。闹钟/日历是用户每天用的，给了 100 条专门测各种日期表达（"后天""下周一""45分钟后""每天含周末"）；相册搜索用得少，但也要确保基本路径通。

• 评测集必须跟着代码演进
  。新增一个工具，评测集里就得加对应 case；下线一个工具，对应 case 也要清掉。

• 预制数据是隐形的评测基础设施
  。记忆类 case 依赖用户画像（"我喜欢美式咖啡不加糖""WiFi 密码是 xiaomi2024"），如果预制数据没写入手机，100 条记忆 case 全部会失败。把预制数据视为评测集的一部分一起维护。

• 不要用"通用 case"测所有版本
  。release 分支和 main 分支的工具集可能不同（比如 release 没有某个新工具），用同一套真值文件会产生大量失败。为不同分支维护独立的真值。

关键设计：评测环境隔离

手机 Agent 评测最容易踩的坑是"串扰"——前一条query的执行结果影响后一条的判断。

真实踩过的坑：最开始闹钟类的评测query采用先执行"新建闹钟"，再评测"删除闹钟"，结果发现由于新建闹钟失败，导致删除闹钟一律失败。为了解决这类评测case间的互相影响，尽量在评测前把query之间互相解耦，每个case统一预制标准化数据。

解决方案：

• 每条query可配置 clear_before 清除上下文
• 有依赖关系的多轮对话用 group 字段保证在同一设备顺序执行
• 评测前统一预制标准化数据（联系人、日历、笔记），确保环境一致

二、真值怎么标：结构化语法 + 8 字段体系

评测集有了，怎么判"对不对"？传统做法是写一句自然语言描述"期望Agent设一个 7 点的闹钟"，然后人工看。但版本每日有多个迭代，逐条人工评估根本看不过来。

方案就是

真值：把"期望行为"拆成机器可校验的字段，全部采用自动化评估。

每条query有 8 个真值字段：

字段	干什么用
tool_used	必须调这个工具
tool_used_any	调其中任一个就行
tool_not_used	不许调这个
tool_args	参数必须精确匹配
tool_args_any	参数匹配任一即可
tool_args_not	参数不许出现这个
任务描述	给 LLM Judge 的自然语言期望
分类	统计用

工具参数用统一的匹配语法：

source:field(matcher=value)

举几个例子：

• cli:command(prefix=deskclock add) — 命令以 deskclock add 开头
• mcp:method(equals=maps_direction_driving) — MCP 方法名精确匹配
• call_tool:tool_name(contains=read_file) — 工具名包含 read_file

这套语法直接对接评测脚本的匹配引擎，消除了"真值描述方式"和"脚本判断逻辑"之间的翻译损耗。

经验：真值标注的 3 个教训

真值

曾把真值标注为AppFunction全称（如 deskclock_deskclock_add_alarm），但实际 Agent 走的是CLI桥接，日志里记录的是 cli。结果 400 条工具 case 命中率直接掉到 16.8%——排查后才发现不是 Agent 的问题，是真值格式对不上。

：标注真值时，先根据代码或跑 10 条相同类型的 case 看实际日志里工具名怎么记的，再按实际格式标注。

评测脚本的逻辑是：所有非空字段都必须匹配才算通过。如果 tool_used=cli 且 tool_args_any=cli:command(prefix=deskclock add)，那两个条件必须同时满足。但如果 Agent 有时候走AppFunction不走 CLI（都能完成任务），那 tool_used=cli 就会误判。正确做法：只填 tool_args_any，让它既约束了工具又约束了参数。

真值

Agent 的工具集在持续演进（工具新增、下线、改名、路径切换）。每次代码分支发生工具变更，对应的真值文件必须同步更新。最终把真值文件纳入和数据集zip一起的版本管理。

三、怎么打分：规则兜底+LLM判语义

评分是评测体系里最容易出问题的环节。纯用LLM判，同一份日志跑两遍分数能差 6%。纯用规则，又覆盖不了"回复是否自然""分析是否有深度"这类语义维度。

评测指标体系

在具体打分机制之前，先说度量什么。经过多轮迭代，最终固定了 8 个核心指标，分为"结果指标"和"过程指标"两组：

指标	含义	为什么重要
任务完成率	完成 / 部分完成 / 未完成的比例	最核心的端到端指标，直接反映用户体验
加权满足率	完成×1 + 部分完成×0.5 的加权分	比二值通过率更细腻，能区分"差一点"和"完全不对"
平均耗时	各轮云端调用耗时合计	超过 15 秒用户就会失去耐心
输入 / 输出 Token	平均 input token 和 output token	直接关联成本和延迟，prompt 膨胀的预警信号

指标	含义	为什么重要
工具选择准确率（L1）	是否调用了正确的工具	Agent 是否"选对路"——路都走错了结果必然错
工具参数正确率（L2）	工具参数是否传对	路选对了但参数错（如日期算错）同样失败
工具调用冗余率	是否有多余/不必要的调用	冗余调用浪费时间、消耗 Token、可能产生副作用
工具链正确性	综合判断整个工具调用链是否完整正确	有些任务需要多步调用（先查再改），漏了一步就算失败

质量分

如果 Agent 根本没完成任务（比如工具调用失败或拒绝执行），不去评价"回复质量好不好"。这个决策避免了一个常见陷阱：Agent 没帮用户做事但说了一通漂亮话，如果算质量分反而会拉高整体分数，掩盖了真正的问题。

完成率（最终结果）
  ├── 工具选择 L1（选对了吗）
  │     └── 工具参数 L2（参数对了吗）
  │           └── 工具链正确性（整个链路都对了吗）
  ├── 冗余率（有没有多干的）
  └── 耗时 / Token（效率如何）

当完成率下降时，按这个层次逐级排查：先看是不是工具选错了（L1 低），如果 L1 正常就看参数对不对（L2 低），如果 L2 也正常就看是不是多步调用漏了一环（工具链不完整）。这个排查顺序帮我们把"分数低"快速收敛到具体原因。

最终的方案是

：

：工具是否调用、参数是否匹配、是否违规——这些有明确对错，不该让LLM来判。

LLM

：回复是否准确、完整、实用——这些需要理解语义。让 Judge 先联网搜索获取参考信息，再对照评判，避免 Judge 自身知识不准。

经验：LLMJudge 的 6 条铁律

经过 3 个月迭代，总结出LLMJudge 可靠运行的核心原则：

"工具是否调用"这件事，日志里有就是有、没有就是没有——让LLM判只会引入随机性。统计发现，把 60% 的判断项从 Judge 移到规则层后，整体波动立刻从 6% 降到 2%。

早期让 Judge 直接判"回复是否准确"，但 Judge 自己的知识也可能过时或不准。比如"河北辛集市阶梯水价"，Judge 不联网就判了个"正确"，实际价格早就调过了。改为每条query先联网搜索，把搜索结果作为参考材料一起给 Judge，误判率降了一半。

"请给回复打 1-10 分"这种prompt基本不可用——不同LLM、不同时间跑出来的分数分布完全不同。

每个评测query需要跑3次，分别计算3次全部通过（pass^3）和3次中至少有一次通过的次数（pass@3）。

发现用同系列模型当 Judge 时，它会对自己风格的回复"手下留情"。最终用Claude系列做 Judge、被测端用mimo系列，消除了这种偏好。

抽 200 条让人工先标注，然后对比 Judge 的输出。一致率低于 85% 就要调 Judge prompt。

四、问题定位：从"分数低"到"改哪行代码"

评测出分只是起点。真正有价值的是：

。

建立了三层归因链路：

从...	到...	举例
问题现象	责任模块	"日期算错" → cli.txt 的 prompt
责任模块	修复动作	在 Quick Decision 增加位掩码示例
修复动作	验证方式	回归跑 100 条定时任务

方法论：问题归因的"收敛漏斗"

面对 1000 条评测结果，不可能逐条分析。策略是

：

把所有失败 case 按（类型, 失败现象）二维分组。比如"定时任务 × 工具参数错误"有 35 条、"闲聊 × 编造信息"有 12 条、"记忆 × 信息缺失"有 55 条。

按数量排序，取 Top3 问题簇。优先解决覆盖面最广的问题——修一个根因能带动一片 case 通过。

不是泛泛说"模型能力不足"，而是具体到"哪个文件的哪段prompt导致模型犯了什么错"。

改完代码后，只回归相关类型的 case（不用跑全量），确认修复有效且没有副作用。

经验：代码归因中的常见陷阱

统计发现，70% 以上的 Badcase 根因在prompt配置和工具描述上，而不是模型本身。比如"工具没调用"的问题，大多数时候不是模型不会调，而是 tool_selection_rules.md 里没有覆盖这个场景的路由规则。

有一次发现工具命中率突然从 53% 暴跌到 16.8%。排查前以为是 Agent 退化，最后发现是真值文件用错了分支——B 分支的真值里用的是AppFunction全称，但对应的 Agent 实际走CLI执行。

，必须对评测基础设施本身建立"元评测"机制。

有些 case 最终回复看起来正确，但执行路径不对。比如用户问"帮我设个闹钟"，Agent 回复"好的已设置"但实际并没有调用任何工具——它只是用语言"声称"设置了。纯看最终回复的 Judge 判会通过，只有检查 Trace 日志才能发现问题。这也是为什么规则层先判工具调用的原因。

两个真实修复案例

用户说"每天早上8点的闹钟周末也要"，Agent用了工作日的位掩码 31 而不是每天的 127。根因：cli.txt 里位掩码说明藏得太深，模型读不到。修复：在 Quick Decision 段加显式示例。修复后定时任务完成率 44% → 55%。

6 月中旬完成率从 61% 暴跌到 56.5%。排查发现是一个"自适应 thinking"功能在首轮关闭了模型推理（本意是省token），导致第一次工具选择没有推理空间，全靠直觉。恢复首轮 thinking 后，闲聊 80→96%、通用问答 67→76%、文本创作 52→70%，整体直接回到 70.7%。

五、工程化：每天自动跑、自动报、自动追

把上面所有东西串成自动化流水线：

日常节奏

• 每天 00:00 自动触发，1.5 小时跑完，凌晨出报告
• 报告模板固定 4 个模块：基本信息 → 整体结论（含Token成本分析） → 问题分类代码级分析 → BadCase 列表
• 版本对比配显著性检验——差异不显著的不下结论

经验：评测工程化的 5 个关键决策

飞书报告第一屏必须是结论（完成率、比昨天涨跌多少、头部问题是什么）。领导和PM只看第一屏。细节放后面给研发看。

早期为了报告美观，截断了 Agent 的完整回复（只展示前 200 字）。结果根因分析时发现关键信息在被截断的部分。后来规定：评测原始数据（Agent 回复、工具参数、Trace 日志）一律完整保存，报告里可以折叠但不能删。

发现汇总日志里的token数和实际消耗差了 50 倍（因为汇总层做了压缩统计）。最终规定 token 统计只信 raw.log 里 SvcHttp 的 usage 字段。

评测脚本是"尺子"，频繁改动会导致历史数据不可比。规定评测脚本的评分维度和匹配逻辑冻结，如果发现不适配，调整的是真值格式或Agent的输出格式。

每次跑完评测、分析完根因，都会追加一份 lessons_learned 记录：这轮发现了什么新问题、用了什么新的分析方法、有哪些判断被证实或推翻。半年下来积累了 30+ 条经验切片，新人看完就能上手。

A/B评测实践

重大架构改动用A/B对比：

• 同一数据集、同一设备池、同时跑新旧两版
• 配套统计检验（配对 t 检验 + Wilcoxon + Cohen's d）
• 报告明确给出"提升/持平/下降 + 置信度"，不搞模糊结论

一个真实场景：B 分支引入 ToolRecallService（工具预召回），评测显示工具类 +10%、闲聊耗时 -50%，但定时任务 -3%。A/B报告帮团队决策"合入但需要修复定时任务回退"，而不是纠结"到底该不该合"。

六、复盘

回头看，沉淀出的核心方法论可以总结为 5 条：

很多团队把评测当成"用AI评 AI"的研究课题。但实际上 90% 的工作是工程活：数据集维护、环境隔离、流水线搭建、报告自动化、版本管理。评测体系好不好用，取决于工程基建做得扎不扎实，不取决于 Judge 模型有多强。

一份只有分数的报告是没用的。团队需要的是"这个分因为什么低、改哪里能提上去、改完怎么验证"。每份报告的核心不是分数表格，而是"头部问题 + 代码归因+ 修复建议"三件套。

真值标错、脚本有 bug、环境不隔离、日志截断——这些评测基础设施的问题会伪装成 Agent 的退化，浪费大量排查时间。在每次出现"分数异常但 Agent 没改"的情况时，会优先检查评测系统本身。

一个波动 6% 的评分系统，即使平均精度高也没用——分不清分数变化是 Agent 真的变了还是评测本身的噪声。宁愿牺牲一些语义判断的"精度"（用规则粗判），也要保证系统整体波动 < 1%。稳定的尺子比精确的尺子更有工程价值。

评测不应该是一个独立的阶段（"开发完了去跑评测"），而应该是每次代码提交后的自动反馈。日包自动评测让团队形成了习惯：每天早上看昨天的评测报告，如果某个类型掉了就去查对应的 commit。问题发现周期从"发版后用户反馈"缩短到"次日凌晨报告"。

下一步

三件事在路上：

• Prompt 自迭代
  ：Badcase 自动生成修复建议 → 模拟重跑验证 → 灰度合入。把"人看报告 → 人改 Prompt → 人验证"的周期从天级压到小时级。

• 线上评测
  ：离线评测永远覆盖不了线上的长尾分布。接入线上真实流量采样，补充评测集盲区。

• 工具级回归
  ：目前是端到端大盘看，下一步每个工具建立独立回归集，改一个工具只跑相关 case，缩短反馈周期。