从 Benchmark 报告到系统改进
看到分数下降时应先检查什么？
- 原则: 看到 Agent 表现下降时，应先检查评测系统本身，再动 Agent;
- 误区: 看到分数下降就立刻修改 Agent 代码，可能基于失真信号调整方向，修改方向从一开始就是错的;
- 评测系统常见错误来源: 运行环境资源不足导致进程被杀（表现为随机失败）、验证器本身有 bug 把正确答案判为失败、测试用例与生产场景之间脱节;
- 辨别方式: 这些问题在结果数字上都跟模型退化一模一样，只有审查完整的轨迹才能区分;
如何读懂 Benchmark 报告？
- 案例: 最初的报告记录了 116 项任务各跑一次的结果，总成功率约为 88%;
- 失败形态: 四项
SystemWifiTurn*任务里有三项失败，轨迹中反复出现来回导航、无法确认最终状态等现象; - 两种解释: 可能是 Agent 不知道设置入口，也可能是它拿到的界面信息不完整;
- 正确读法: 先找失败集中在哪些任务和能力上，再回放轨迹，分清问题出在看、想、做还是验;
- 只盯总分的后果: 小而集中的失败簇容易被忽略；只增加最大步数，又可能把 “看不见界面” 误当成 “不够耐心”;
- 范围控制: 先把范围缩到四项 Wi-Fi 任务，目的只是用较低成本判断病因，不是估算系统的整体水平;
AndroidWorld Wi-Fi 子集的三轮实验得到什么结论？
| 实验 | 只改了什么 | 对照组→实验组成功率 | 实验组/对照组 token | 下一步 |
|---|---|---|---|---|
| H1 | 增加 Wi-Fi 设置的导航提示与最终状态检查要求 | 25%→25% | 0.47× | 没有提高成功率，沿用原提示 |
| H5 | 把 API 35 上不兼容的 accessibility feed 换成 UIAutomator 元素树 | 25%→100% | 2.498× | 效果明显但太费 token，继续优化 |
| H5C | 精简元素树，删除不可见、没有文字、也不能操作的容器节点 | 100%→100% | 0.506× | 成功率不变、token 减半，进入完整复测 |
- 实验控制: 三轮始终使用相同的模型、任务参数、随机种子、步数上限和模拟器，并交替安排两组的运行顺序;
- 假设来源: H1 认为 Agent 只是 “不知道路”；H5 转而检查 Agent 到底 “看见了什么”;
- 结论一: 提示写得更详细也补不回 Agent 根本没有看到的信息，遇到这类失败应先检查输入，而不是继续堆提示词;
- 结论二: 输入也不是越多越好——完整元素树解决了 “看不见” 的问题，却带来大量无用 token；删除无语义节点后四项任务仍全部成功，token 又减少约一半;
- 结论三: 整个过程中没有更换模型，仅仅调整 Harness 如何表示界面，就先后解决了 “能不能做成” 和 “做成是否划算” 两个问题;
- 系统视角: 这本质上是 Harness 迭代优化方法论，用评估数据定位薄弱环节（上下文不足、约束缺失、验证不够、反馈不及时），见 Harness工程;
一轮证据支持多大的下一步？
- 判据: 一轮证据只支持与它规模相称的下一步;
- H5C 的资格: 通过这四项任务的检查只说明它值得进入下一轮，并不等于可以部署;
- 完整复测要求: 补齐第三方应用，在 Pixel 6 / API 33 标准环境中对 116 项任务各跑 5 个随机种子；除成功率不能下降外，还要确认 token 不超过原方案的 75%、延迟不超过 1.5 倍;
- 报告纪律: 在完整复测之前，不能把子集上的 4/4 写成系统整体 100%;
- 迭代节奏: H1 失败让我们不再继续堆提示词；H5 找到了正确方向也暴露了成本问题；H5C 解决成本问题后才获得扩大测试的资格;
- 好的报告: 不只给出一个分数，还应写清结论适用于哪里、哪些底线没有通过、下一轮要验证什么;