个人 Agent 评测集设计：任务分层、黄金答案、人工评分与回归测试 —— 主题精读笔记 未开始

题记与说明

驱动问题：一个个人 Agent（没有真实用户流量、没有标注团队、没有 A/B 基础设施）怎么设计一套小而可信的评测集——任务怎么分层组织、黄金答案怎么定才站得住、LLM 评分要不要信以及怎么校准、怎么把评测变成改 prompt/换模型时的回归防线？
日期：2026-11-03 ｜ 类型：主题研究（网络检索挑选来源 + 逐一精读）
一句话回答：评测集是"活的人工制品"，可信度来自四个相互咬合的设计：①任务按难度×场景双轴分层（GAIA 用步骤数×工具数分 3 级并用模型表现验证层级有效性；工程侧按 feature×scenario 分区、分区各自设阈值）；②每条任务必须有经独立人工验证的唯一黄金答案或黄金终态（GAIA：出题者之外两名标注者独立作答一致才算合格，623 题只有 68% 一次通过；τ-bench：不比文本比数据库终态，标注"黄金写入动作"）；③LLM-as-judge 必须先经人工评分校准（Hamel：先用二元好/坏标签人工看数据，再用 25-50 例小批量对齐 judge，注意类别不均衡时看 precision/recall 而非裸一致率；Anthropic：让 judge 可以输出"Unknown"作为逃生门）；④回归靠分层节奏：高通过率的 capability 任务"毕业"为回归套件（Anthropic），PR 跑缓存冒烟集+夜间无缓存全量+安全类零容忍（promptfoo 实战：1400 案例、周 200 次变更、当年拦下 23 次回归）。

精读来源清单

检索过程说明：先用「AI agent evaluation benchmark design golden answers task difficulty levels regression testing」锁定全景来源（命中 Anthropic 指南、Daniel Kang 批评文、NVIDIA/Cameron Wolfe 综述等），再分别用「GAIA benchmark levels human verified answers」「tau-bench pass^k user simulator」「Hamel Husain your AI product needs evals」「promptfoo CI regression golden set」补齐四个子维度的原典与实操来源。5 个来源全部成功抓取并精读；Daniel Kang《AI agent benchmarks are broken》Medium 原文抓取连接超时，仅有搜索摘要级信息（其"agent 答案可能是代码/API 调用/长篇计划、不适配固定答案键"的批评），已并入局限部分但不计入精读来源。

一、逐源精读

来源 1：Anthropic《Demystifying evals for AI agents》（2026-01-09）

核心问题：agent 自主、多轮、改环境，导致"错一步错满盘"，怎么设计严谨又实用的评测？

方法/结构：先给术语体系，再给 grader 类型学，再按四类 agent（编码/对话/研究/计算机操作）给打法，最后给 0→1 路线图与评测之外的互补方法。

关键内容与数据：

1. 术语体系（这是设计评测集的地基词汇表）：task（单个测试，定义输入+成功标准）→ trial（一次尝试，因输出随机必须多 trial）→ grader（评分逻辑，一 task 可多 grader，grader 内含多个 assertion/check）→ transcript/trajectory（完整轨迹）→ outcome（trial 结束时环境的最终状态）——文中关键对比：订票 agent 说"已订好"，outcome 却是 SQL 库里到底有没有那条记录 → evaluation harness（跑评测的基础设施）vs agent harness（让模型成为 agent 的脚手架），"我们评'一个 agent'时，评的是 harness+模型的合体"。
2. Grader 三分法（各有适用面，评测设计="为活选对 grader"）：
   • 代码型（字符串匹配、fail-to-pass/pass-to-pass 二元测试、静态分析、outcome 验证、工具调用验证、轨迹分析）：快、便宜、客观、可复现、易调试；但对"不匹配预期模式的合法变体"脆弱、缺细腻度；
   • 模型型（rubric 打分、自然语言断言、成对比较、参照对比、多 judge 共识）：灵活可扩展、能抓开放任务的细腻度；但不确定、贵、必须与人类评分者校准；
   • 人类（SME 复核、众包、抽检、A/B、标注者间一致性）：金标准、用来校准模型 grader；但贵、慢。
3. Capability vs Regression 二分（本主题"回归测试"的核心机制）：capability eval 问"这个 agent 能做好什么"，应从低通过率起步（给团队一座可爬的坡）；regression eval 问"以前会的现在还会吗"，通过率应接近 100%。"capability eval 高通过率后可以'毕业'为回归套件持续运行拦截漂移——曾经度量'我们能不能做到'的任务，转而度量'我们是否还稳定做到'。"
4. pass@k 与 pass^k（任务分层之外的第二根测量轴：一致性）：pass@k 是 k 次里至少 1 次成功的概率（k 越大越高）；pass^k 是 k 次全部成功的概率（k 越大越低）。"单次成功率 75% 的 agent 跑 3 次，全过的概率是 (0.75)³ ≈ 42%。"选哪个取决于产品：一次性成功就够的用 pass@k，面向用户、要求每次都对的用 pass^k。
5. 0→1 路线图（Step 0-8）：
   • Step 0 别等："20-50 个从真实失败里来的简单任务就是很好的起点"，早期效应量大所以小样本就够；
   • Step 1 从手测清单/bug 追踪器/客服队列转任务；Step 2 写无歧义任务+参考解："好任务的标准是两位领域专家独立判卷会得到同样的 pass/fail 结论"；"frontier 模型在多次 trial 上 0% 通过率，多半是任务坏了，不是模型不行"；每个任务建 reference solution（已知能全过 grader 的输出），"证明任务可解且 grader 配置正确"；
   • Step 3 平衡正反例（只测"该搜索时搜了"会造出"什么都搜"的 agent——Claude.ai 网络搜索评测的真实教训）；
   • Step 4 harness 要稳定隔离：每次 trial 从干净环境起步，"某些内部评测里 Claude 靠翻前几次 trial 的 git 历史占了便宜"；
   • Step 5 grader 设计三原则："评 agent 产出的东西，而不是它走的路径"（僵化检查工具调用顺序会惩罚创造性解法）；多组件任务给部分分；LLM judge 与人类专家校准、给 judge"Unknown"逃生门、按维度拆分独立 judge；
   • 评测本身的 bug 触目惊心：Opus 4.5 在 CORE-Bench 初测 42%，修掉"期望 96.124991… 却把 96.12 判错"等评分 bug、放宽 scaffold 后跳到 95%；METR 的时间域基准要求 agent"达到阈值"但评分却要求"超过阈值"，守规矩的模型反被扣分；
   • Step 6 读 transcript（"失败应该看起来公平"）；Step 7 盯评测饱和（SWE-bench Verified 从 30% 到 >80% 接近饱和，"100% 的评测只防回归、不再给改进信号"）；Step 8 评测是活物件要有 owner，PM/客服可以用 PR 形式贡献评测任务，"practice eval-driven development：先建评测定义计划中的能力，再迭代到达标"。
6. 评测与其他五种方法拼瑞士奶酪：自动化评测（每 commit 可跑、可复现）→ 生产监控（真实分布）→ A/B（真实结果）→ 用户反馈（意外问题）→ 人工读轨迹 → 系统性人类研究（主观任务的金标准+校准 LLM grader 的参照系）。"没有单一评测层能拦住所有问题。"

来源 2：GAIA（Mialon et al., ICLR 2024, arXiv 2311.12983）

核心问题：LLM 不断打穿"对人类越来越难"的基准，评测何去何从？作者反其道：考"对人概念上简单、对 AI 难"的真实助理任务。

方法/结构：设计原则 → 评测协议 → 分层构成 → 出题与验证协议 → 实测。

关键内容与数据：

1. 反直觉基线：466 题上"人类受访者 92% vs 带 GPT-4 插件 15%"。分级别：GPT-4+插件 Level 1/2/3 = 30.3% / 9.7% / 0%；人类 = 93.9% / 91.8% / 87.3%（平均答题时间 6.8 / 10.5 / 17.7 分钟）。搜索引擎基线只有 L1 7.4%——答案在网上不存在明文。
2. 任务分层（本主题"任务分层"的原型设计）："问题按解题所需步骤数和所需不同工具数排成三级"——Level 1：不用或至多 1 个工具、≤5 步（146 题）；Level 2：约 5-10 步、需组合多工具（245 题）；Level 3：任意长动作序列、任意工具（75 题）。关键诚实声明：步数/工具数没有唯一定义，"我们依赖的代理指标是标注者出题时实际用的步骤数和工具数"；且"这些定义不是硬约束"，例外可上调级别。层级有效性靠实测背书："级别与当前模型表现相关，佐证其有效性。"
3. 黄金答案协议（本主题最值得抄的部分）：
   • 答案形态先决："答案必须是 factoid、简短、无歧义的（一个/几个词的字符串、数字、或逗号分隔列表）……只有一个正确答案"，评测用准精确匹配（按答案"类型"做归一化），评分函数随榜单公开；
   • 出题约束（附录 D 原文照录要点）：必须基于 source of truth（Wikipedia/arXiv 等）；"确保答案在网上不以明文存在"；"确保答案不随时间变化"；"确保答案无歧义"；
   • 双人独立验证："每题由两名新标注者独立作答。若原标注者与两名新标注者得到相同答案，题目通过验证"——不一致能修则修、不能修则删。623 道新题、1246 次验证标注，68% 直接合格，其余修正或删除；含验证与修复在内一道题约 2 个标注工时；
   • 防 data contamination 三件套：答案精度要求高、答案不在预训练明文里、可查推理轨迹；"静态基准就是正在坏掉的基准"（Static benchmarks are broken benchmarks in the making），每年删坏题加新题。
4. 作者自认的局限：不评推理轨迹（"不同路径都能到正确答案，没有简单办法给路径打分"）；无歧义性代价高；只有英语。

来源 3：τ-bench（Yao et al., ICLR 2025, arXiv 2406.12045）

核心问题：已有基准不测 agent 与真实用户的交互、也不测对领域规则（政策）的遵守，而这两点恰是真实部署的命门。

方法/结构：零售/航空两个领域 + LLM 用户模拟器 + 数据库终态评分 + pass^k。

关键内容与数据（摘要页直接精读 + ar5iv 全文提取，两处数字互相印证）：

1. 黄金答案=黄金终态（对"开放答案怎么定黄金标准"的关键回答）：每个 task 两个隐藏部分——用户模拟指令（对 agent 保密）+ "黄金数据库写入动作标注"（及可选的用户提问黄金输出）。"任务指令经过工程化设计，使得在领域政策下只有一种可能的结局。"评分 r = r_action × r_output ∈ {0,1}：r_action 比对"最终数据库是否与唯一黄金结果库一致"，r_output 检查"agent 对用户的回复包含所有必要信息"。作者自认 r=1 "可能是必要非充分条件"（比如未获用户确认就执行的违规操作可能碰巧把库改对）。
2. 任务分层与验证：115 题（retail）+ 50 题（airline）；任务三段式构建（人工设计 schema/API/政策 → LLM 生成数据 → 人工标注任务，每个 retail 任务用 >40 次 gpt-4-turbo 试跑迭代验证可解性——这就是 Anthropic 说的 reference solution 的学术版）。
3. pass^k 定义与"可靠性悬崖"："所有 k 次独立 trial 都成功的概率，对任务取平均"：pass^k = E_task[ C(c,k)/C(n,k) ]（n 次 trial 中成功 c 次）。实测（摘要原文）："即使最先进的函数调用 agent（如 gpt-4o）成功率也不到 50%，且相当不稳定（retail 上 pass^8 <25%）"——gpt-4o pass^1：retail 61.2%、airline 35.2%；政策消融：去掉领域政策文档，airline 从 33.2 暴跌到 10.8。
4. 用户模拟器（个人 agent 做多轮评测的可行模板）：gpt-4-0613 模拟用户（temp 1.0，agent temp 0.0）；用户只看得到自己指令+对话历史，看不到 agent 与 API 的交互；persona 含身份/意图/偏好甚至情绪（"你今天负债且沮丧，但话很少"）。失败归因里只有 4/40 的失败源于用户模拟器缺陷（指令错字/歧义），36 个归 agent——模拟器噪声可测可控。成本：gpt-4o 当 agent + gpt-4 当用户，retail 上约 $0.61/任务。
5. 失败分布（40 个失败案例）：~50% 参数错/数据库推理错（复杂 DB 推理）；25% 决策错/违反政策（如"一次通话只能换一件"规则前就下单）；19% 复合请求只解决一半。

来源 4：Hamel Husain《Your AI Product Needs Evals》（2024-03-29）

核心问题：LLM 产品卡在 demo 与产品之间的根因是"没建评测系统"——怎么从零建一套可持续迭代的？

方法/结构：案例（Rechat 的房产 AI 助手 Lucy）→ 评测三级成本分层 → 每级怎么做 → 评测系统反哺微调与调试。

关键内容与数据：

1. 评测本身分层（个人侧最实用的节奏设计）：Level 1 单元测试（断言）→ Level 2 人工+模型评测 → Level 3 A/B；"Level 3 成本 > Level 2 > Level 1。我通常每次代码变更跑 Level 1、按固定节奏跑 Level 2、只在重大产品变更后跑 Level 3。"Lucy 的教训：修一个失败模式冒出新的（打地鼠）、prompt 越堆越长、只剩 vibe check。
2. Level 1：断言+场景矩阵：按 feature×scenario 组织断言（如"只有 1 条房源匹配→len==1；多条→len>1；没有→len==0"），外加跨功能通用断言（正则检查输出不泄露 UUID）。"Rechat 有数百条这种单元测试，随新失败持续更新。"测试输入可让 LLM 合成生成。与传统单元测试的关键区别："不一定需要 100% 通过率。通过率是产品决策，取决于你愿意容忍哪些失败。"跑在 CI（GitHub Actions）里，结果进 Metabase 看板追踪趋势。
3. Level 2：人工评分的工作流（本主题"人工评分"最落地的一段）：
   • 前提是先记 trace，然后"把看数据的摩擦降到零"——自建领域专用标注工具（"用 Gradio/Streamlit/Panel/Shiny 不到一天就能搭"），一屏聚合 trace+CRM+过滤器，还把 LLM 最终输出做成可编辑（顺手攒微调数据）；
   • 标注从简："我最常从把样例标成好/坏开始。打分或更细的评级比二元标注更难管理。"
   • 看多少数据："起步时尽可能多看。我至少会读全部测试用例的 trace 和用户产生的 trace。你永远不能停止看数据——没有免费午餐。"之后逐步抽样（启发式：直到读不出新东西）。
4. LLM-as-judge 对齐（校准闭环）：让更强的模型写 critique+二元结论，人（如同事 Phillip）独立标 25-50 例/批，两边对照在电子表格里迭代 judge 的 prompt 直到与人对齐；"模型与人类一致率要持续追踪"——但重要警告："数据集大致均衡时才能用裸一致率；类别不均衡时一致率会误导，应分别测 precision 和 recall。" judge 三原则：用你能负担的最强模型；judge 自身是一个子问题、要维护迷你评测系统；对齐后仍要周期性复测一致率。
5. 反工具崇拜："别依赖通用评测框架来度量你的 AI 质量。要为你的问题建专用的评测系统。"评测系统的副产品几乎免费：微调数据池、调试用的 trace 库与断言集。

来源 5：Promptfoo 黄金集流水线实战（softechinfra，2026-05）

核心问题：每周 200+ 次 prompt 变更的产品，怎么用黄金集+CI 保证"不弄坏东西"？

关键内容与数据（经 WebFetch 全文提取精读）：

1. 黄金集规模与分区：1400 个测试用例，按场景分 9 区（雅思口语评分 220、发音反馈 180、商务角色扮演 160、HR 面试 140、闲聊 200、词汇练习 120、语法 160、安全拒答 120、对抗红队 100）。增长节奏：起步 30 例（小产品）或 200 例（生产中），"每周加 5 例是可持续的"。
2. 断言分层省钱：确定性断言（is-json schema、JS 数值带宽校验）先行，LLM rubric 只给主观质量——"确定性断言先跑；挂了就不浪费一次模型调用去做 rubric 评分"。rubric 写法："写成'必须出现的关键短语或证据'清单，而不是凭感觉。"
3. CI/回归门禁（本主题最具体的回归协议）：GitHub Action 监听触及 prompts/ 与 prompt_evals/ 的 PR；9 个场景配置并行跑（matrix）+缓存；阈值按场景设（雅思通过率 ≥92%、跌 3 分告警；安全与对抗场景零容忍——"一例失败就挡 merge"）；PR 上贴与 main 的分数 diff 评论；凌晨 2 点全量无缓存跑两家模型（--no-cache "抓静默的供应商漂移——同版本号下的隐秘模型变更只能靠这条路发现"），用 --compare baseline.json --fail-on-regression；任一场景指标漂移 >5% 发 Slack 告警；上线前再对部署产物（而非仅 PR diff）跑一次评测。
4. 抗抖动：温度 0.0；对话类场景给更宽容忍（"主观反馈本来就逐轮变化"）；RAG/状态用 fixtures 固定（音频特征 JSON 存一次回放），"需要活网络调用的东西不该进评测套件"。LLM judge 自己也会病：曾把"反馈很周到"当通过而反馈内容其实是错的。
5. 战果与边界：当年拦下 23 次回归（7 次用户可感知、3 次"灾难级"分数虚高）；PR 路径 0 漏网（唯一一次漏网走的是直推 main）；中位 PR 评测 7 分钟、夜间全量 90 分钟。每次事故长出一个用例："生产里撞到的每个 prompt 相关 bug 都变成新测试用例。"作者也给了"何时不值得"：生产 prompt 不到 10 条、温度常开 >0.5、单一冻结自托管模型。

二、四子维度横向综合

三、七维提取

1. 核心问题

个人 Agent 的输出是非确定的、多轮的、会改环境的，"手动点一点没坏"不可持续；需要一套小规模评测集同时回答两个问题：agent 能做什么（capability）、改完之后还稳不稳（regression）。难点在：开放任务怎么定唯一答案、LLM 评分凭什么可信、没有用户流量时怎么防倒退。

2. 主要主张

• 评测集是活的人工制品（living artifact），要像维护单元测试一样维护它：有 owner、随事故生长、按年淘汰坏题。
• 可信度来自四个咬合设计：任务按难度×场景分层；每题有经独立验证的黄金答案/黄金终态；LLM judge 经人工校准并持续测一致；评测按PR 冒烟/夜间全量的节奏分层跑，高通过率任务"毕业"进回归套件。
• 一致性是一等公民指标：单次 pass^1 高不等于可靠（gpt-4o retail 61.2% → pass^8 <25%）。

3. 方法

• 分层：GAIA 用"步骤数×工具数"做难度代理指标并靠模型表现验证；工程侧按 feature×scenario 分区、按成本分三级节奏（每次变更/固定节奏/重大变更）。
• 黄金答案：三条路——factoid 唯一答案+类型归一化准精确匹配（GAIA）；黄金数据库终态+黄金写入动作（τ-bench）；reference solution+确定性断言+证据清单式 rubric（Anthropic/promptfoo）。验证统一靠"出题者之外的人独立复核"。
• 人工评分：二元好/坏起步 → 自建零摩擦标注工具 → LLM judge 小批量对齐（precision/recall 优先于裸一致率）→ 周期性复测；judge 要有"Unknown"逃生门。
• 回归：确定性断言先跑省 judge 调用；PR 缓存冒烟+夜间无缓存全量抓供应商漂移；安全类零容忍；--fail-on-regression 对基线比分；事故自动转用例。

4. 数据与证据

• GAIA：466 题、人类 92% vs GPT-4+插件 15%（L1 30.3%/L2 9.7%/L3 0%）；623 题双标注者验证仅 68% 一次合格；约 2 工时/题。
• τ-bench：gpt-4o pass^1 retail 61.2%/airline 35.2%，pass^8 <25%；去掉政策文档 airline 掉 22.4 分；40 个失败中仅 4 个源于模拟器。
• promptfoo 实战：1400 例 9 分区、周 200+ 变更、当年拦 23 次回归、PR 路径 0 漏网、中位 PR 评测 7 分钟。
• Anthropic 案例：CORE-Bench 评分 bug 修复后 Opus 4.5 从 42% 跳 95%；SWE-bench Verified 一年 40%→>80% 接近饱和。
• Hamel/Rechat：数百条断言级单元测试 + Metabase 趋势看板支撑持续迭代。

证据强度：五个来源覆盖学术原典（2）、一线厂商方法论（1）、工程实战复盘（2），在四个子维度上相互独立又相互印证（如 pass^k 在 τ-bench 原典与 Anthropic 指南中定义一致；"出题者外独立验证"在 GAIA 与 Anthropic reference solution 建议中同构）。τ-bench 细节经全文提取获得、与官方摘要直接精读结果一致，交叉验证充分。

5. 结论与效果

• 个人/小团队的正确路径：20-50 个来自真实失败的任务起步（Anthropic），按 feature×scenario 分区（Hamel/promptfoo），先写确定性断言再加 LLM rubric，judge 用人工校准。
• 黄金答案优先选可程序验证的终态（数据库/文件系统/结构化输出），文本型黄金答案必须走"双标独立验证"。
• 回归防线=分层节奏：高通过率任务毕业进回归套件，PR 冒烟+夜间全量+零容忍安全层，夜间必须无缓存以抓静默模型漂移。
• 该设计已在工业界量级（周 200 变更、千级案例）验证可行，个人规模（几十案例、几条场景线）是它的严格子集。

6. 局限

• 作者承认的：GAIA 不评推理轨迹、无歧义代价高（每题 2 工时）、仅英语且答案会随网页演化衰减；τ-bench 承认 r=1 必要非充分、模拟器有隐含偏差（用 gpt-4-turbo 调过用户 prompt）、报告指出 pass^k 会把环境随机性误记为 agent 不稳定；Anthropic 承认自动化评测"若不匹配真实使用模式会制造虚假信心"。
• 我推断的：三份学术/厂商材料都面向有标注预算的团队，个人场景下"双标注者独立验证"退化为"隔一天自己重做一遍"时，黄金答案质量保障大打折扣；promptfoo 实战文为单产品经验，阈值数字（≥92% 等）不可直接迁移；Daniel Kang《AI agent benchmarks are broken》原文抓取超时（连接超时），其"agent 答案可能是代码/长篇计划、不适配固定答案键"的批评仅基于搜索摘要，未能核对全文论证。
• LLM judge 的校准在个人场景是持续税：模型一换、judge 就要重校（Hamel 的周期性复测要求在此放大为成本）。

7. 对我的启发

• 立刻可做：给我的个人 agent 工作流（如 nightshift 的精读管线）建一个 20-50 题的真实失败-derived 评测集：每个失败过的 case 固化为一条"任务+黄金终态"（结构化输出 schema 校验、引用链接可解析、字段齐全），按 feature×scenario 分区（精读/检索/写作/工具调用），确定性断言先行。
• 借 GAIA 的三问质检每条任务：答案唯一吗？出题者之外能独立得出同一答案吗（隔天自测）？答案会随时间变吗？
• judge 纪律：凡用 LLM 评分的维度，先攒 25-50 条人工二元标注再上线 judge，记录 precision/recall；rubric 写成"必须出现的关键证据"清单；给 judge"证据不足请答 Unknown"的出口。
• 回归节奏：改 prompt/换模型必跑冒烟集；每周一次无缓存全量抓模型供应商静默漂移；安全/数据损失类任务零容忍；每次事故当晚新增一条用例。
• 测量哲学：pass^1 之外报告 pass^k（哪怕 k=3），一致性悬崖对个人 agent 的"可信度"比单次成功率更诚实；评测分数不直接信，先读 transcript 确认"失败看起来公平"。

原文引述备查

"20-50 simple tasks drawn from real failures is a great start." —— Anthropic
"A good task is one where two domain experts would independently reach the same pass/fail verdict." —— Anthropic
"…a 0% pass rate across many trials (i.e. 0% pass@100) is most often a signal of a broken task, not an incapable agent." —— Anthropic
"It's often better to grade what the agent produced, not the path it took." —— Anthropic
"If your agent has a 75% per-trial success rate and you run 3 trials, the probability of passing all three is (0.75)³ ≈ 42%." —— Anthropic
"the answers to our questions are factoid, concise and unambiguous. These properties allow simple, fast and factual evaluation." —— GAIA
"We therefore asked two new annotators to independently answer each question. If the original annotator and the two new annotators arrived at the same answer, the question was validated." —— GAIA
"68% of the questions were good as is, while the rest had to be corrected or removed." —— GAIA
"Static benchmarks are broken benchmarks in the making…" —— GAIA
"We employ an efficient and faithful evaluation process that compares the database state at the end of a conversation with the annotated goal state." —— τ-bench（摘要）
"even state-of-the-art function calling agents (like gpt-4o) succeed on <50% of the tasks, and are quite inconsistent (pass^8 <25% in retail)." —— τ-bench（摘要）
"Remove ALL friction from looking at data." / "You are doing it wrong if you aren't looking at lots of data." —— Hamel Husain
"I often start by labeling examples as good or bad… assigning scores or more granular ratings is more onerous to manage than binary ratings." —— Hamel Husain
"using raw agreement is generally not recommended and can be misleading when classes are imbalanced. Instead, you should typically measure precision and recall separately." —— Hamel Husain
"The deterministic ones run first; if they fail, we don't waste a model call on rubric grading." —— promptfoo 实战
"Every prompt-related bug you hit in production becomes a new test case." —— promptfoo 实战

来源链接汇总

• Anthropic, *Demystifying evals for AI agents*: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
• Mialon et al., *GAIA: a Benchmark for General AI Assistants* (ICLR 2024): https://arxiv.org/abs/2311.12983 （全文: https://ar5iv.labs.arxiv.org/html/2311.12983 ；HAL 榜单: https://hal.cs.princeton.edu/gaia ）
• Yao et al., *τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains* (ICLR 2025): https://arxiv.org/abs/2406.12045 （全文: https://ar5iv.labs.arxiv.org/html/2406.12045 ）
• Hamel Husain, *Your AI Product Needs Evals* (2024-03-29): https://hamel.dev/blog/posts/evals/index.html （进阶: https://hamel.dev/blog/posts/llm-judge/index.html ）
• softechinfra, *Prompt Eval Pipelines: 200 Changes a Week Without Breaking Things* (2026-05): https://www.softechinfra.com/blog/promptfoo-prompt-eval-pipeline-200-changes-week-talkdrill
• 补充（未精读，仅检索摘要级）: Daniel Kang, *AI agent benchmarks are broken*: https://medium.com/@danieldkang/ai-agent-benchmarks-are-broken-c1fedc9ea071 ；NVIDIA, *How to Evaluate AI Agents*: https://developer.nvidia.com/blog/how-to-evaluate-ai-agents-from-tool-calls-to-task-completion