手机上的 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 的执行结果影响后一条的判断。

真实踩过的坑：最初闹钟类的评测流程是先执行“新建闹钟”，再评测“删除闹钟”，结果由于新建闹钟失败，导致删除闹钟全部失败。为了解决这类 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 个教训

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

曾将真值标注为 AppFunction 全称（如 deskclock_deskclock_add_alarm），但实际 Agent 走的是 CLI 桥接，日志里记录的是 cli。结果 400 条工具 case 命中率直接跌至 16.8%——排查后发现并非 Agent 问题，而是真值格式不匹配。

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

教训 2：tool_used 和 tool_args_any 不要同时填写，除非确定需要 AND 语义。

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

教训 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 自身知识不准确。

经验：LLM Judge 的 6 条铁律

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

铁律 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% 时就需要调整 Judge prompt。

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

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

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

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

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

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

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

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

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

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

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

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

统计发现，70% 以上的 Badcase 根因在 prompt 配置和工具描述上，而非模型本身。例如“工具没调用”的问题，大多数时候不是模型不会调，而是 tool_selection_rules.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，缩短反馈周期。