揭秘手机端 Agent 评测的实战经验，从评测体系搭建到工程化落地，带你深入了解如何量化与提升 Agent 的真实操作能力。核心内容：1. 手机端 Agent 评测的五大核心能力与评测集设计原则2. 保障评测准确性的关键技术：环境隔离与数据标准化3. 基于结构化语法的真值标注方法与实际效果提升数据
背景：手机上的 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=mapsdirectiondriving) — MCP 方法名精确匹配calltool:toolname(contains=readfile) — 工具名包含 readfile这套语法直接对接评测脚本的匹配引擎，消除了"真值描述方式"和"脚本判断逻辑"之间的翻译损耗。经验：真值标注的 3 个教训教训 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判语义评分是评测体系里最容易出问题的环节。纯用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来判。LLMJudge（语义层）：回复是否准确、完整、实用——这些需要理解语义。我们让 Judge 先联网搜索获取参考信息，再对照评判，避免 Judge 自身知识不准。经验：LLMJudge 的 6 条铁律经过 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。四、问题定位：从"分数低"到"改哪行代码"评测出分只是起点。真正有价值的是：这个分为什么低，改哪里能提上去。我们建立了三层归因链路：| 从... | 到... | 举例 |
|---|
| 问题现象 | 责任模块 | "日期算错" → cli.txt 的 prompt |
| 责任模块 | 修复动作 | 在 Quick Decision 增加位掩码示例 |
| 修复动作 | 验证方式 | 回归跑 100 条定时任务 |
方法论：问题归因的"收敛漏斗"面对 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 列表版本对比配显著性检验——差异不显著的不下结论经验：评测工程化的 5 个关键决策决策 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评测实践重大架构改动用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，缩短反馈周期。
登录查看剩余 70% 内容
郑重声明：本站发布内容宗旨在传播更多信息，仅提供查阅，与本站立场无关，不拥有所有权，不承担相关法律责任。不具有任何效益，仅供参考。如果需要专业知识建议，请咨询相关专业人士。如有侵权请联系邮箱。一经查实，立即删除！
