分类标签归档：评测
最近学习了一套 Agent 评测体系的完整框架，从思维导图整理成这篇笔记。它回答了一个很现实的问题：当 Agent 从 Demo 走向生产，我们拿什么保证它"既聪明又稳定"？
传统测试那一套在这里几乎失效——Agent 不是"输入 A 必然输出 B"的函数，而是一条概率性、多步、依赖上下文的执行轨迹。这篇笔记沿着"为什么要评 → 怎么可观测 → 离线怎么保 → 线上怎么兜"的主线，把这些年做质量保障的经验和这套体系对照着梳理一遍。
在 LLM 质量保障的日常里，最常被问到的问题之一是："这个模型到底行不行？"
但"行不行"从来不是一个数字能回答的。同样是"MMLU 78 分"，few-shot 设成几？prompt 模板用什么？是不是 chat 格式？温度多少？有没有踩到测试集污染？——任何一项没对齐，跨团队、跨模型、跨版本的数字都不可比。
lm-evaluation-harness 就是为消灭这种"不可比"而生的。它是 EleutherAI 维护的 LLM 评测框架，也是 HuggingFace Open LLM Leaderboard 背后的评测引擎。这篇文章是我把它真正用进质量体系的实战笔记，不堆概念，只讲怎么跑、
导读：一篇用 4 条 trace 逐条证伪平台结论的方法复盘：某纯编排型 Agent 技能被打成健康度 41/100「不健康」，但拉明细后发现 P99 长尾（149.4s、最长 317.6s）来自跨业务定时任务混入采样的噪音，83.8%（150/179）的「中断」大多是业务写成功后收尾轮被平台切掉、并非用户流失。核心结论是分数失真源于采样口径污染 + 中断语义错位，真正可动的是把 read_file 从 4-5 次/trace 压到 ≤1、成功后立即终止这类纯编排优化，零业务改动。适合做 Agent 评测、健康度指标治理的工程师
导读：本文复盘一个 Agent 评测失败案例：用户只问"我接的订单在哪里看，给我链接"，Agent 却走了 109 步、调用 82 次工具（其中 44 次盲猜 API 路径），最终仍没查出订单数据，而正常路径只需 5～10 步、10～30 秒。归因得出五层系统性叠加的问题——技能路由失败致订单查询技能从未进入主路径、身份与技能可见范围配置错误（服务者身份下暴露的是员工端技能）、RAG 泛化替代（20 次知识库检索兜底）、会话旧记忆干扰（翻历史会话"考古"旧技能名）、无约束的暴力盲探（44 次猜 URL），