eval-improvement

name	eval-improvement
description	当你要把评估结果转化为系统改进（从 Benchmark 报告定位问题、构建改进假设、做消融/AB 测试、部署决策）或搭建生产级内部评估基础设施（特性开关、提示词敏感性、隐私感知分析）时使用；当需要"观察→假设→实验→决策→迭代"的科学迭代闭环时使用。不适用于评估指标/数据集设计（见 eval-metrics / eval-dataset）。

评估驱动改进（Evaluation-Driven Improvement）

角色与读者

面向需要从评估结果持续改进 Agent 的开发者。本 Skill 服务的目标：把评估从"偶尔做一次的考试"变成"嵌入每一次产品决策的基础设施"。核心认识：好的 Benchmark 报告不只给出分数，还写清结论适用于哪里、哪些底线没通过、下一轮要验证什么。

核心原则（配正例/反例）

1. 从 Benchmark 报告到系统改进：观察→假设→实验→决策→迭代

   • 先检查评测系统本身再动 Agent（分数下降可能是资源不足/评分器 bug/测试用例脱节，跟模型退化一模一样）。
   • 读报告先找失败集中在哪些任务和能力，再回放轨迹，分清问题出在看/想/做/验。
   • 正例（AndroidWorld Wi-Fi 案例）：H1 增加导航提示（成功率不变，说明不是提示词问题）→ H5 换 UIAutomator 元素树（25%→100% 但 token 2.5 倍）→ H5C 精简元素树（成功率不变 token 减半）。三轮只改一个变量，逐轮缩小问题范围。
   • 结论：提示写再详细补不回 Agent 根本没看到的信息；输入也不是越多越好。

2. 消融基础设施：每个特性可独立关闭

   • 总开关同时禁用多个特性（思考/压缩/自动记忆/后台任务）创造"裸模型"基线，回答"某特性是真改善还是感觉有用"。
   • 消融开关必须在启动路径极早期注入（在任何模块级常量捕获配置前）；定期运行发现"特性债务"（曾经有效但随模型进化不再必要）。

3. AB 测试方法论：区分机制指标与目标指标

   • 多臂而非二元（多个渐进变体揭示剂量-效应关系）；区分机制指标（你直接改变的）和目标指标（你真正关心的），以目标为准；设置护栏指标（不能变差的底线）。
   • 反例：测试"缩短计划文件长度"，计划长度是机制指标，真正目标是"降低会话级成本"——缩短计划可能因计划不够详细反而增加编辑循环。

4. 双层特性开关系统（一等架构组件）

   • 编译时开关：构建阶段物理移除代码（逆向工程不可见，干净消融）；运行时开关：服务端下发+本地缓存（宁可读旧缓存不阻塞启动），曝光事件每会话最多记录一次。
   • 特性开关同时服务：实验、渐进发布、紧急熔断。

5. 提示词敏感性评估 + 隐私感知分析

   • 系统提示是 Agent 行为的"代码"，需版本控制和回归测试：确定性渲染（同配置同输出）+ 版本化快照 + 每次变更跑评估集回归（像代码跑 CI）。
   • 隐私感知：分析接口只接受特殊类型包装值（类型名是审计线索），把隐私约束从文档规范变成编译时强制。隐私和评估不对立，隐私感知设计催生更精准指标。

执行流程（SOP 检查清单）

1. 从 Benchmark 报告定位问题（先查评测系统，再找失败集中点，回放轨迹）。
2. 构建假设（三层：表层/中层/深层），每轮只改一个变量。
3. 分阶段实验（记录成功率 + token + 延迟 + 是否回退）。
4. 数据驱动决策（低成本高收益优先部署，高成本限定关键场景）。
5. 建内部基础设施（消融开关、AB 测试、特性开关、提示词敏感性、隐私感知）。

禁止清单（写清合法例外）

• 禁止看到分数下降就改 Agent 代码（先查评测系统本身）。例外：审查完整轨迹确认是 Agent 问题后再动。
• 禁止把机制指标当目标指标（你改变的≠你关心的，以目标为准）。例外：明确区分两者。
• 禁止同时堆上许多改动（无法说清因果）。例外：一轮只改一个变量，上一轮暴露的问题成为下一轮唯一验证的改动。
• 禁止子集 4/4 写成系统整体 100%（一轮证据只支持与规模相称的下一步）。例外：标准环境完整复测后才能讨论部署。
• 禁止把特性开关当调试工具（是一等架构组件）。例外：服务实验/渐进发布/紧急熔断。

参考资料

• 本书第 7.9 节《从 Benchmark 报告到系统改进》+ 第 7.10 节《从外部评估到内部评估》。
• 笔记 07-Agent的评估.md 第 7.8-7.9 节。
• AndroidWorld 调优案例；GrowthBook 特性开关。