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

手机端 Agent 和聊天机器人最大的区别是：它会真的操作你的手机。

用户说"帮我设个明早 7 点的闹钟"，Agent不是回一句"好的已设置"就完了——它需要正确计算时间、调用系统接口、传入正确参数，最终手机上真的多了一个闹钟。同时多次执行同一query，每次执行路径均不完全相同。

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

三个月评测提升的效果提升很明显：

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

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

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

• 覆盖率比数量重要
  。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 字段保证在同一设备顺序执行
• 评测前统一预制标准化数据（联系人、日历、笔记），确保环境一致

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

我们的方案是结构化真值：把"期望行为"拆成机器可校验的字段全部采用自动化评估。

每条query有 8 个真值字段：

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

source:field(matcher=value)

举几个例子：

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

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

教训 1：真值必须对齐执行层，不是设计层。

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

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

教训 2：toolused 和 toolargs_any 不要同时填，除非你确定要 AND 语义。

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

教训 3：真值需要版本化管理。

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

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

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

结果指标（衡量最终效果）

过程指标（衡量执行路径）

关键设计决策：质量分仅在任务完成时计算。

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

指标之间的层次关系：

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

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

我们最终的方案是分层打分：

规则层（零成本，确定性）：工具是否调用、参数是否匹配、是否违规——这些有明确对错，不该让LLM来判。

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

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

铁律 1：能用规则判的，绝不交给LLM。

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

铁律 2：Judge 必须先拿到外部参考信息再判。

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

铁律 3：评分标准要具体到"什么情况给几分"。

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

铁律 4：每个评测query跑3次。

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

铁律 5：Judge 模型和被测模型不要用同系列。

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

铁律 6：定期用人工标注校准 Judge。

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

评测出分只是起点。真正有价值的是：这个分为什么低，改哪里能提上去。

我们建立了三层归因链路：

面对 1000 条评测结果，不可能逐条分析。我们的策略是先聚类再深挖：

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

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

第三步：对头部问题做代码归因。不是泛泛说"模型能力不足"，而是具体到"哪个文件的哪段prompt导致模型犯了什么错"。

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

陷阱 1：不要把所有问题都归到"模型能力不足"。

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

陷阱 2：注意区分"Agent的问题"和"评测的问题"。

我们有一次发现工具命中率突然从 53% 暴跌到 16.8%。排查前以为是 Agent 退化，最后发现是真值文件用错了分支——B 分支的真值里用的是AppFunction全称，但对应的 Agent 实际走CLI执行。评测系统自身的 bug 会伪装成 Agent 的退化，必须对评测基础设施本身建立"元评测"机制。

陷阱 3：关注"幻觉"——通过了但路径有问题的 case。

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

案例 1：定时任务参数错误（头部问题，35%）

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

案例 2：完成率一周内 +14pp的关键修复

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

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

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

决策 1：报告结论放最前面。

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

决策 2：每条 case 的原始数据不能截断。

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

决策 3：Token统计从 raw.log 提取，不用汇总日志。

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

决策 4：评测脚本不改、真值和Agent改。

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

决策 5：每轮评测后写"经验切片"。

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

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

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

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

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

1. 评测是工程问题，不是AI问题。

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

2. "能改什么"比"分数多少"重要 10 倍。

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

3. 评测系统自身也需要"被评测"。

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

4. 稳定性比精度重要。

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

5. 让评测"长在"研发流程里，而不是"挂在"旁边。

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

三件事在路上：

• Prompt 自迭代
  ：Badcase 自动生成修复建议 → 模拟重跑验证 → 灰度合入。把"人看报告 → 人改 Prompt → 人验证"的周期从天级压到小时级。
• 线上评测
  ：离线评测永远覆盖不了线上的长尾分布。接入线上真实流量采样，补充评测集盲区。
• 工具级回归
  ：目前是端到端大盘看，下一步每个工具建立独立回归集，改一个工具只跑相关 case，缩短反馈周期。