手机端 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，缩短反馈周期。
