09 评测

第一部分 速记页

第二部分 易混对照

第三部分 面试口述稿

3.1 “你怎么证明改动让效果变好了？”

我会做一个固定的评测集，改动前后用同样的题各跑几轮，比较结果。有几个要点。

一是评分不能看模型自己说的，要检查外部结果。我项目是交叉编译，模型说编译成功不算，程序会重新构建一遍，并检查产物是不是目标架构的 ELF 文件。

二是每个配置要跑多轮，因为同一个任务每次路径不同。我项目里同一个项目跑三次，步数标准差平均有两三步，单次对比得出的结论很可能是随机波动。

三是判断差异要看波动。我给自己定的规则是，差距不到一倍标准差就只能算趋势，不能算确认。

四是不能只看总分，要分类看，还要去读轨迹，确认分数变化的原因真的是改动带来的。

3.2 “评测集怎么建？”

我会从真实的失败案例开始，而不是凭空编题。先有二三十道就能开始用，之后不断把线上或测试中遇到的新失败加进去。

题目要覆盖不同难度和类型，并分组统计，不然总分会掩盖问题。每道题要写清楚成功标准，最好能用程序检查。

还有两件事容易被忽略。第一是防泄漏：用来调提示词、提炼知识库的题，不能再拿来证明效果，要留一部分完全没用过的题当留出集。我项目提炼知识库用了原来 10 个项目的运行记录，测知识库效果时就换了 5 个从没跑过的项目。第二是防饱和：所有配置都 100% 通过，评测集就失去区分度了，我项目的第三轮就是 60 次全部通过，需要加更难的项目。

3.3 “用大模型当裁判靠谱吗？”

能用，但要校准。有研究发现强模型当裁判和人类判断的一致率能超过 80%，和人与人之间的一致程度差不多，但同时存在几种偏差：换一下两个回答的顺序，判断可能就变了；倾向于给长回答高分；倾向于偏爱和自己风格相近的回答。

我的做法是先人工标注一批样本，拿裁判的判断和人工对比，除了看一致率，还要看 kappa，因为如果大部分样本都是通过的，裁判全判通过一致率也很高。更要看它对失败样本的识别率，这才是评测真正要抓的。评分标准尽量写成具体的是非判断，比如”回答是否引用了资料里没有的数字”，而不是”打 1 到 10 分”。能用代码检查的部分，就不用模型。

3.4 “Agent 结果有随机性，样本又少，怎么下结论？”

首先承认样本少时能说的有限。我会做几件事：每个配置跑多轮，报平均值和标准差，不只报一个数；比较两个配置时，用同一批题做配对比较，看每道题上的差值，因为不同题之间难度差异很大，混在一起波动会很大；算一个置信区间，区间跨过零就不能说有差异。

拿我项目的留出集举例：不开知识库平均 14.2 步，开混合检索 16.8 步，看起来多了两步多。但按项目算差值，五个项目里一个少了三步多、四个多了一到六步，按项目重抽样算出来的 95% 区间是负零点七到五点三，跨过了零，所以只能说”没有观察到可测量的收益”，不能说”知识库让步数变多了”。

3.5 “pass@k 和 pass^k 有什么区别？”

pass@k 是跑 k 次至少成功一次的概率，衡量模型有没有能力做到，适合有人会从多个结果里挑、或者能自动验证并重试的场景，比如代码生成可以跑测试挑出对的那个。

pass^k 是 k 次全部成功的概率，衡量稳定性。面向用户的产品更应该看这个，因为用户每次用都希望成功。两者差别很大：单次成功率 70% 的任务，pass@3 超过 99%，pass^3 只有 29% 左右。τ-bench 论文里就发现当时最强的模型在零售场景单次成功率不到一半，连续 8 次都成功的比例不到 25%。

3.6 “回归测试怎么做？”

把评测分成两类。回归集是已经能稳定做对的题，每次改提示词、换模型、改工具都要跑，通过率应该接近 100%，掉分就是改坏了，要拦住发布。能力集是还做不好的难题，用来看改进方向，通过率低是正常的。

流程上，改动先跑回归集，没掉分再跑能力集看有没有提升，再小流量上线看线上指标。评测很贵的话，回归集可以挑有代表性的子集，完整评测按天或按版本跑。我项目跑一轮完整评测要八分钟、上百万 token，所以像只改步数上限这种改动，我只重跑了受影响的困难档。

3.7 “你的评测过程中发现过什么问题？”

最有价值的发现是评分器自己错了两次，都是读轨迹才发现的。

第一次，验收只看 cmake --build 的退出码，结果有两次运行一个目标都没编译就判了通过。后来验收改成必须在构建目录里找到目标架构的 ELF 产物。

第二次是在留出集上，libarchive 九次里失败了八次。查下来不是 Agent 的问题：这个仓库自带一个叫 build 的源码目录，Agent 聪明地换了个名字做构建目录并且编译成功了，但验收写死去 build 目录检查。修复后第一次的四十五次结果全部作废重跑。

另外还发现过一次模型为了满足验收，自己往 CMakeLists 里加了一个示例目标。这些都说明分数本身不可信，要定期读轨迹检查评分器测的是不是你真正想要的东西。

第四部分 逐个详解

4.1 为什么 Agent 难评测

普通的模型评测是”一个输入、一个输出、和标准答案比”。Agent 不一样：

术语。Anthropic 在 2026 年 1 月的 Demystifying evals for AI agents 里给了一套清楚的术语，面试时用这些词会显得有体系：

flowchart LR
    S[(评测集<br/>一组任务)] --> H[评测框架]
    H --> T1[任务 A 试验 1]
    H --> T2[任务 A 试验 2]
    H --> T3[任务 B 试验 1]
    T1 --> AG[被测的 Agent<br/>提示词 / 工具 / 模型]
    AG --> TR[轨迹<br/>每一步做了什么]
    AG --> OUT[结果<br/>环境最终状态]
    OUT --> G[评分器<br/>代码 / 模型 / 人工]
    TR -.也可以评过程.-> G
    G --> AGG[汇总<br/>通过率 / 步数 / 成本 / 分类统计]
    TR --> READ[人读轨迹<br/>找原因、查评分器 bug]

4.2 评什么：分层评测

一个 Agent 应用可以在四个层次上评测，越往下越接近真实，也越贵：

flowchart TB
    L1["单元层：单个组件<br/>工具是否正确、检索 Recall@k、结构化输出能否解析<br/>快、便宜、可以每次提交都跑"]
    L2["单步层：给定上下文，模型这一步<br/>选对工具没有、参数对不对、该停时停没停"]
    L3["端到端层：完整任务<br/>最终结果对不对、用了多少步和 token"]
    L4["线上层：真实用户<br/>任务完成率、用户反馈、人工抽检"]
    L1 --> L2 --> L3 --> L4

分层的意义在于定位。08 篇的例子：检索层分数很高，端到端没有收益，两层结果放在一起才能说出”瓶颈不在检索算法”。

能力评测和回归评测是另一种划分，按用途分：

一道题在能力集里被稳定做对之后，就可以移进回归集。

4.3 评测集怎么建

从哪来：

公开基准在 2026 年的几个坑。 公开基准适合横向比较模型，但这一年暴露的问题说明分数要打折看：

Anthropic 那篇文章的建议是：先从 20 到 50 个来自真实失败的任务开始，不要等攒够几百道才开始评测；每个任务写清楚无歧义的成功标准，最好附参考解；正例和反例要平衡，比如既有”应该调工具”的，也有”不该调工具”的，否则 Agent 会被优化成只会一种行为。

题目要分类、分难度。 我项目 10 个项目按依赖复杂度分三档：简单（cJSON、fmt、json、Catch2）、中等（spdlog、googletest、zlib、benchmark）、困难（libpng、re2）。统计时分档看，因为困难档的步数动辄二三十，混进平均值会把简单档的变化淹没。

防泄漏。 泄漏（leakage）指测试数据以某种形式进入了被测系统：

• 用测试题调提示词，然后用同样的题证明提示词变好了
• 从测试题的运行记录里提炼知识库，然后用同样的题测知识库
• 把测试题的答案写进了 few-shot 示例

我项目的做法：知识库新增的 5 条经验来自原来 10 个项目的运行记录，所以测知识库的端到端效果时，另选 5 个 Agent 从没跑过的项目（libuv、curl、libjpeg-turbo、freetype、libarchive）作为留出集。而且在留出集上发现的问题（libarchive 的链接错误），不能补进知识库后再用这 5 个项目测。

防饱和。 评测集太简单，所有配置都满分，就无法区分好坏。我项目经历了这个过程：

通过率饱和之后，只能退而看步数和 token，而步数的波动又很大。评测集要跟着 Agent 的能力一起变难：依赖链更深的项目、非 CMake 构建系统、需要在目标平台运行测试的项目。

记录环境版本。 被测对象会变：开源项目每天都有新提交。我项目评测时在一小时内克隆所有项目，并把每次运行拿到的 commit 记在结果文件里，确认 60 次运行的 commit 一致，对比才有意义。模型服务也可能悄悄更新，要记录模型名和日期。

4.4 评分器：三种方式和它们的坑

优先检查最终状态。 能用环境状态判断的，就不要去评模型说了什么：

评分器本身也会错，而且错得很隐蔽。 我项目的验收函数改了三次，每次都是读轨迹或分析异常结果才发现的：

flowchart TD
    V1["验收 v1：cmake --build 退出码为 0"] --> B1["问题：json 有两次运行一个目标都没编译<br/>复验输出为空，却判通过"]
    B1 --> V2["验收 v2：退出码为 0<br/>且 build 目录里有目标架构 ELF 产物<br/>（排除 CMake 自己的探测程序）"]
    V2 --> B2["问题：libarchive 自带 build/ 源码目录<br/>Agent 改用 out、_build 等目录并成功编译<br/>验收写死去 build/ 检查，9 次失败 8 次"]
    B2 --> V3["验收 v3：读 CMakeCache.txt<br/>找 CMAKE_HOME_DIRECTORY 等于项目根目录的构建目录<br/>排除依赖项的构建目录，有多个取最近修改的"]
    V3 --> R["补回归测试；第一次的 45 次结果作废重跑"]

第一个是假阳性（没做成判成功），会让你以为效果很好；第二个是假阴性（做成了判失败），会让你以为 Agent 有问题去改错地方。两种都只有看具体轨迹才能发现。

Agent 可能钻评分标准的空子。 v2 验收要求”至少有目标架构的产物”。json 是一个只有头文件的库，本身不产生编译产物。run 44 里 Agent 修改了项目的 CMakeLists.txt，自己加了一个示例目标来满足验收。这算不算成功？按任务要求（交叉编译这个项目）有点牵强。系统提示词里后来明确写了”header-only 项目至少保留一个会被编译的测试或示例”，把期望说清楚。这类情况要在任务定义里写明允许和不允许的做法。

4.5 动手实验 1：一个最小的评测框架

用假 Agent 演示评测框架的结构：多个任务、每个任务多次试验、状态检查评分、同时统计”谎报完成”、和基线比较。只用标准库，保存为 eval_harness.py。

import json
import random

TASKS = [
    {"id": "cjson", "tier": "简单", "difficulty": 0.1},
    {"id": "zlib", "tier": "中等", "difficulty": 0.3},
    {"id": "libpng", "tier": "困难", "difficulty": 0.6},
]


def fake_agent(task, version, rng):
    skill = 0.75 if version == "v2" else 0.6
    passed = rng.random() > task["difficulty"] * (1 - skill) * 2.5
    artifact = "aarch64" if passed else None
    claimed = passed or rng.random() < 0.5
    return {"claimed_success": claimed, "artifact_arch": artifact, "steps": rng.randint(6, 30)}


def grade(outcome):
    return {
        "artifact_ok": outcome["artifact_arch"] == "aarch64",
        "false_claim": outcome["claimed_success"] and outcome["artifact_arch"] != "aarch64",
    }


def run_suite(version, trials=5, seed=0):
    rng = random.Random(seed)
    results = {}
    for task in TASKS:
        grades = [grade(fake_agent(task, version, rng)) for _ in range(trials)]
        results[task["id"]] = {
            "pass": sum(g["artifact_ok"] for g in grades),
            "false_claims": sum(g["false_claim"] for g in grades),
            "trials": trials,
        }
    return results


baseline = run_suite("v1", seed=1)
candidate = run_suite("v2", seed=2)
print(json.dumps({"baseline": baseline, "candidate": candidate}, ensure_ascii=False))
for task_id in baseline:
    b, c = baseline[task_id]["pass"], candidate[task_id]["pass"]
    flag = "回归" if c < b else ("提升" if c > b else "持平")
    print(f"{task_id:<8} 基线 {b}/5  新版 {c}/5  {flag}  新版谎报完成 {candidate[task_id]['false_claims']} 次")

实际输出：

{"baseline": {"cjson": {"pass": 3, "false_claims": 2, "trials": 5}, "zlib": {"pass": 5, "false_claims": 0, "trials": 5}, "libpng": {"pass": 0, "false_claims": 3, "trials": 5}}, "candidate": {"cjson": {"pass": 5, "false_claims": 0, "trials": 5}, "zlib": {"pass": 5, "false_claims": 0, "trials": 5}, "libpng": {"pass": 2, "false_claims": 2, "trials": 5}}}
cjson    基线 3/5  新版 5/5  提升  新版谎报完成 0 次
zlib     基线 5/5  新版 5/5  持平  新版谎报完成 0 次
libpng   基线 0/5  新版 2/5  提升  新版谎报完成 2 次

逐段讲。

① random.Random(seed)。 创建一个独立的随机数生成器，seed（种子）固定时，每次运行产生的随机数序列完全相同。评测框架里固定种子是为了让实验可复现。rng.random() 返回 0 到 1 之间的随机小数，rng.randint(6, 30) 返回 6 到 30 之间的随机整数（包括两端）。

注意：真实的模型 API 即使设了温度为 0 也不保证完全可复现，所以真实评测要靠多次试验而不是固定种子。

② 假 Agent。 skill 越高、任务越简单，passed 为真的概率越大。claimed = passed or rng.random() < 0.5：成功时一定声称成功；失败时也有一半概率谎称成功。这是在模拟”模型说完成但其实没完成”。

③ 评分器 grade。 只看结果状态 artifact_arch，完全不看 claimed_success。同时额外统计 false_claim：声称成功但状态不对。这个指标在真实项目里很有用，它反映 Agent 的”自我认知”是否可靠。

④ run_suite。

• [grade(fake_agent(...)) for _ in range(trials)]：每个任务跑 trials 次。_ 是一个约定俗成的变量名，表示”这个循环变量用不到”
• sum(g["artifact_ok"] for g in grades)：括号里是生成器表达式（和列表推导式类似，但不先生成列表），True 当 1 加起来就是通过次数

⑤ 对比。 逐个任务比较通过次数，分成回归、提升、持平。

这个输出里藏着一个值得思考的问题：cjson 是最简单的任务，基线版本 5 次里只过了 3 次。按设定的参数，基线在 cjson 上每次成功概率是 90%，5 次里只过 3 次纯粹是随机波动。如果只跑一轮、每题只试一次，你可能因为这种波动得出完全错误的结论。 下一节讲怎么处理。

自己改一改：

• 把 seed=1 和 seed=2 换成别的数，看结论会不会变
• 把 trials 改成 50，看”提升”是否仍然成立

4.6 模型当裁判：怎么用、怎么校准

先说为什么会用模型当裁判。 自然语言生成以前主要靠两种自动指标：机器翻译用的 BLEU（IBM 的 Papineni 等人 2002 年提出，论文）和摘要用的 ROUGE（Chin-Yew Lin 2004 年提出，论文）。它们的做法都是数模型输出和人写的参考答案之间有多少相同的词和词组。翻译、摘要的答案大致有个范围，这么数还算管用。到了聊天模型，同一个问题可以有很多种都对的回答，措辞和参考答案完全不同也可能更好，数重合词就不灵了；请人来打分又贵又慢。2023 年 GPT-4 这类强模型出来以后，研究者开始试着让它来判断两个回答哪个好。下面这篇论文开头就是这么交代动机的：聊天助手能力太广，现有的评测基准衡量不了人的偏好。

官方说明：Zheng 等人 2023 年的 Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena 系统研究了用大模型评判回答质量。结论是强模型当裁判和人类偏好的一致率能超过 80%，与人类之间的一致程度相当；同时指出了几种偏差：

写裁判提示词的建议：

是非判断比打分稳定得多：让模型区分 7 分和 8 分，每次结果都可能不同；让它判断”有没有引用资料外的数字”，结果一致得多。

怎么校准：先人工标注一批，再对比。

动手实验 2：假设人工标注了 20 条样本，模型裁判也判了一遍，计算一致性。数据是为演示编的。保存为 judge_agreement.py。

from collections import Counter

human = ["pass", "pass", "fail", "pass", "fail", "pass", "pass", "fail", "pass", "pass",
         "fail", "pass", "pass", "pass", "fail", "pass", "fail", "pass", "pass", "pass"]
judge = ["pass", "pass", "pass", "pass", "fail", "pass", "pass", "pass", "pass", "pass",
         "fail", "pass", "pass", "pass", "pass", "pass", "fail", "pass", "pass", "pass"]

pairs = Counter(zip(human, judge))
n = len(human)
agree = sum(v for (h, j), v in pairs.items() if h == j) / n

labels = ["pass", "fail"]
expected = sum((human.count(l) / n) * (judge.count(l) / n) for l in labels)
kappa = (agree - expected) / (1 - expected)

print("人工 \\ 裁判   pass  fail")
for h in labels:
    print(f"{h:<12}{pairs[(h, 'pass')]:>5}{pairs[(h, 'fail')]:>6}")
print(f"一致率 {agree:.2f}  随机也能达到 {expected:.2f}  Cohen's kappa {kappa:.2f}")
caught = pairs[("fail", "fail")] / human.count("fail")
print(f"人工判失败的 {human.count('fail')} 条里，裁判抓到 {pairs[('fail', 'fail')]} 条（{caught:.0%}）")

实际输出：

人工 \ 裁判   pass  fail
pass           14     0
fail            3     3
一致率 0.85  随机也能达到 0.64  Cohen's kappa 0.58
人工判失败的 6 条里，裁判抓到 3 条（50%）

逐段讲。

• zip(human, judge) 把两个列表按位置配成对，比如 ("fail", "pass") 表示人工判失败、裁判判通过
• Counter(...) 统计每种组合出现几次，得到一个混淆矩阵（confusion matrix）：行是人工判断，列是裁判判断
• for (h, j), v in pairs.items()：items() 每次给出 ((人工, 裁判), 次数)，前面的括号直接把键拆成两个变量
• human.count(l)：列表里 l 出现几次
• expected：如果裁判完全随机、只是和人工有相同的判 pass 比例，碰巧一致的概率。人工 70% 判 pass，裁判 85% 判 pass，碰巧都判 pass 的概率 0.7×0.85，碰巧都判 fail 的概率 0.3×0.15，加起来约 0.64
• Cohen’s kappa = (实际一致率 - 随机一致率) / (1 - 随机一致率)。1 表示完全一致，0 表示和随机猜差不多。经验上 0.6 以上算较好，0.4 到 0.6 一般
• f"{caught:.0%}"：% 格式把小数显示成百分比，.0 表示不保留小数

这个结果说明什么？ 一致率 85% 看起来不错，但：

1. 大部分样本是 pass，裁判”倾向于判 pass”就能拿到很高的一致率，kappa 只有 0.58
2. 人工判失败的 6 条，裁判只抓到 3 条。评测最想发现的就是失败，这个裁判漏掉一半

所以校准时要专门看裁判对失败样本的识别率，不能只看总一致率。发现漏判，就去看漏掉的那几条，改评分标准或换更强的模型当裁判，再重新对比。

4.7 统计：样本少、有波动时怎么下结论

先建立直觉：同一个 Agent 跑同一个项目三次，步数可能是 28、11、39（这是我项目 libarchive 的真实数据）。这时候拿”配置 A 跑一次 28 步、配置 B 跑一次 16 步”得出”B 更好”，毫无意义。

几个基本概念：

比较两个配置时，配对比较比直接比平均值好。 不同题之间的差异往往远大于配置带来的差异：困难项目几十步，简单项目几步。把所有题混在一起比平均值，配置的影响会被题目差异淹没。配对比较是在每道题上算”配置 B 减配置 A”的差值，再看这些差值。

Evan Miller 2024 年的 Adding Error Bars to Evals 专门讲了这件事，核心建议是：评测就是实验，要报告标准误；同一道题有多次试验或题目之间有关联时，用聚类（clustered）标准误；两个模型在同一批题上比较时用配对差值；评测之前先估算需要多少样本。

动手实验 3：用我项目留出集的真实步数数据。只用标准库，保存为 eval_stats.py。

import random
import statistics

STEPS = {
    "libuv":         {"base": [16, 14, 11], "hybrid": [10, 7, 14]},
    "curl":          {"base": [13, 11, 13], "hybrid": [23, 17, 16]},
    "libjpeg-turbo": {"base": [9, 9, 13],   "hybrid": [9, 13, 13]},
    "freetype":      {"base": [9, 9, 8],    "hybrid": [13, 15, 9]},
    "libarchive":    {"base": [28, 11, 39], "hybrid": [33, 28, 32]},
}


def describe(name, values):
    mean = statistics.mean(values)
    sd = statistics.stdev(values)
    se = sd / len(values) ** 0.5
    print(f"{name:<8} n={len(values)} 平均 {mean:5.2f}  标准差 {sd:5.2f}  95%区间约 [{mean - 1.96 * se:5.2f}, {mean + 1.96 * se:5.2f}]")


base = [s for p in STEPS.values() for s in p["base"]]
hybrid = [s for p in STEPS.values() for s in p["hybrid"]]
describe("不开库", base)
describe("混合", hybrid)

diffs = [statistics.mean(p["hybrid"]) - statistics.mean(p["base"]) for p in STEPS.values()]
print("逐项目差值（混合 - 不开库）:", [round(d, 1) for d in diffs])

random.seed(0)
projects = list(STEPS)
boot = []
for _ in range(10000):
    sample = [random.choice(projects) for _ in projects]
    boot.append(statistics.mean(statistics.mean(STEPS[p]["hybrid"]) - statistics.mean(STEPS[p]["base"]) for p in sample))
boot.sort()
print(f"按项目重抽样的差值 95% 区间: [{boot[250]:.2f}, {boot[9750]:.2f}]")

实际输出：

不开库      n=15 平均 14.20  标准差  8.41  95%区间约 [ 9.94, 18.46]
混合       n=15 平均 16.80  标准差  8.35  95%区间约 [12.57, 21.03]
逐项目差值（混合 - 不开库）: [-3.3, 6.3, 1.3, 3.7, 5]
按项目重抽样的差值 95% 区间: [-0.73, 5.27]

逐段讲。

• statistics 是 Python 自带的统计模块
• len(values) ** 0.5：** 是乘方，0.5 次方就是开平方根
• [s for p in STEPS.values() for s in p["base"]]：把 5 个项目各 3 次的步数摊平成 15 个数
• round(d, 1)：保留 1 位小数

先说为什么会有重抽样。 上面表里的 “平均值 ± 1.96 × 标准误” 是教科书公式，它背后有前提：样本够多，或者数据大致服从正态分布。只有 5 个项目，这个前提很难说成立；而且要算的量一复杂（比如配对差值的中位数、两个比例之比），往往根本没有现成的公式。1979 年斯坦福的统计学家 Bradley Efron 在《统计年鉴》（Annals of Statistics）上发表了 Bootstrap Methods: Another Look at the Jackknife，思路是不推公式，直接拿手上的样本当”总体”，从里面有放回地反复抽，看算出来的量波动多大。它全靠反复计算，所以是随着计算机普及才流行起来的，下面的实验几行 Python 就抽了 1 万次。名字 bootstrap 来自”拽着自己的鞋带把自己提起来”这句俗话，意思是只靠手里这点数据自己估计自己的不确定性。

重抽样（bootstrap） 这一段是新方法，重点讲：

• 思路：我们只有 5 个项目的数据，不知道”真实世界所有项目”上的差值分布。那就从这 5 个项目里有放回地随机抽 5 次，组成一个”假想的评测集”，算一次平均差值。重复 1 万次，得到 1 万个平均差值
• random.choice(projects)：从列表里随机选一个，可能重复选到同一个（有放回）
• 把 1 万个结果排序，第 250 个和第 9750 个之间就是中间 95% 的范围
• 为什么按项目抽而不是按单次运行抽？ 同一个项目的 3 次运行彼此相关（难度相同），它们不是 15 个独立样本。按项目整体抽样，就是聚类标准误的思路

结果解读：

1. 两个配置的 95% 区间 [9.94, 18.46] 和 [12.57, 21.03] 大幅重叠
2. 逐项目看，5 个项目里 1 个变少、4 个变多
3. 配对差值的 95% 区间是 [-0.73, 5.27]，跨过了 0

结论：不能说开混合检索让步数变多了，也不能说变少了，只能说没有观察到可测量的差异。 这和 REPORT 里”步数差异在一倍标准差以内”的结论一致。样本只有 5 个项目，重抽样的区间本身也很粗糙，但足以说明不能下强结论。

关于标准差的数字：这里用样本标准差算出 8.41，REPORT 表格里写的是 8.1，因为报告里用的是总体标准差（pstdev，结果 8.13）。样本少时两者差别明显，报告里要写清楚用的是哪种。

环境本身也会带来波动。 上面统计的都是”模型每次走的路不同”带来的随机性。Agent 评测还多一层：机器负载、API 延迟、容器资源限制、网络都会影响结果。Anthropic 建议每个任务写明保证分配的资源和强制上限、分多天多次跑取平均。我项目每次评测都在同一台机器上跑，资源没设限，但编译速度受机器负载影响，命令超时的判定可能因此不稳定，这一点 REPORT 里没写。

“一倍标准差”规则：我项目 REPORT 里给自己定了一个简单规则：“差距小于一倍标准差，不算确认，只算趋势”。这不是严格的统计检验，但比只看平均值谨慎得多，适合样本很少、跑一轮成本很高的情况。面试时说出这个规则和它的局限，比说”效果提升了 X%“可信得多。

4.8 pass@k 和 pass^k

先说为什么会有 pass@k。 代码生成早期也是借用翻译的评法，拿 BLEU 这类指标比生成的代码和参考代码有多少字符、词相同。问题是两段代码可以长得很像，一段对一段错；也可以写法完全不同，却都能跑通。Codex 论文专门做了对比，发现同一道题正确和错误答案的 BLEU 分数分布明显重叠，BLEU 高不代表代码对。于是评测改成看功能是否正确：直接跑单元测试，过了就是对。模型每次生成结果不同，自然就有了”给它 k 次机会，至少一次跑通”的算法。Codex 论文里也写明，这个 pass@k 的评法之前 Kulal 等人 2019 年在伪代码转代码的研究里已经用过，Codex 论文的贡献是下面那个无偏估计的算法，以及 HumanEval 这套 164 道手写题。

pass@k：出自 Chen 等人 2021 年的 Codex 论文 Evaluating Large Language Models Trained on Code。每道题生成 k 个结果，至少一个通过就算这道题通过。论文里 Codex 单次生成能解决 HumanEval 28.8% 的题，生成 100 次取任一通过则达到 70.2%。

直接用 k 个样本算方差很大，论文给了一个无偏估计：每道题生成 n 个（n ≥ k），其中 c 个正确：

pass@k = 1 - C(n-c, k) / C(n, k)

C(a, b) 是组合数，从 a 个里选 b 个的方法数。C(n-c, k) / C(n, k) 是”随机选 k 个全都是错的”的概率，1 减去它就是”至少一个对”。

pass^k：出自 τ-bench（2024），衡量 k 次全部成功的概率。τ-bench 模拟客服场景里 Agent 和用户、工具的多轮交互，发现当时最强的 GPT-4o 在零售场景单次成功率不到 50%，pass^8 更是不到 25%。

动手实验 4：保存为 pass_k.py。

from math import comb


def pass_at_k(n, c, k):
    if n - c < k:
        return 1.0
    return 1 - comb(n - c, k) / comb(n, k)


def pass_hat_k(n, c, k):
    return comb(c, k) / comb(n, k)


print("每道题跑 n=10 次，成功 c 次")
print(f"{'c':>3} {'单次成功率':>8} {'pass@3':>8} {'pass^3':>8}")
for c in [10, 9, 7, 5, 3]:
    print(f"{c:>3} {c / 10:>10.2f} {pass_at_k(10, c, 3):>8.3f} {pass_hat_k(10, c, 3):>8.3f}")

实际输出：

每道题跑 n=10 次，成功 c 次
  c    单次成功率   pass@3   pass^3
 10       1.00    1.000    1.000
  9       0.90    1.000    0.700
  7       0.70    0.992    0.292
  5       0.50    0.917    0.083
  3       0.30    0.708    0.008

逐段讲。

• from math import comb：comb(a, b) 计算组合数 C(a, b)，Python 3.8 起自带
• pass_at_k：错误的数量少于 k 个时，选 k 个必然至少有一个对，直接返回 1。否则按公式算
• pass_hat_k：从 c 个成功里选 k 个的方法数 / 从 n 个里选 k 个的方法数，就是”随机选 k 次全是成功的”的概率
• f"{'c':>3}"：花括号里直接写字符串常量 'c' 并右对齐，用来打印表头

看这张表： 单次成功率 70% 时，pass@3 高达 99%，pass^3 只有 29%。同一个 Agent，按 pass@k 看”几乎总能做到”，按 pass^k 看”十次里七次不能连续三次都成功”。

我项目每个配置跑 3 轮，留出集三种配置都是 15/15，pass^3 在这个评测集上都是 100%，这又回到了”评测集饱和”的问题。

4.9 读轨迹：分数之外的信息

Anthropic 那篇文章把”定期读轨迹”列为关键实践：确认评分器测的是真正重要的东西，找出误判的失败。分数告诉你结果，轨迹告诉你原因。

我项目从轨迹里发现的问题，没有一个是看总分能发现的：

怎么系统地读轨迹：

1. 先统计再抽样：按失败类型、工具失败率、步数分布统计，找出异常的运行，再重点读
2. 给失败分类：我项目 errors.py 把报错分成 8 类，REPORT 的”下一步”里也写了 compile_error 这一类太粗，需要更细的分类
3. 对照改动看：改了什么，就去看和这个改动相关的轨迹里对应的行为有没有变。v2 到 v3 只改了 toolchain 的传递方式，“子目录找不到 toolchain”从 8 次降到 0、误拦消失，这两项在轨迹里能直接对应到改动，因果清楚；而困难档平均步数的下降，没法在轨迹里直接对应，只能算趋势

4.10 回归测试接进发布流程

回归测试（regression test）：拿以前已经能做对的题再跑一遍，确认这次改动没有把原来好的地方改坏。它不是用来证明”变好了”，而是用来拦住”变坏了”。

对 Agent 来说，下面这些改动都要跑回归，哪怕看起来只是一句话的事：

一条分层把关的流程：

flowchart LR
    C[改动] --> U[单元测试<br/>秒级、不调模型]
    U -->|过| R[回归集<br/>已经稳定能做对的题]
    R -->|不掉分| A[能力集<br/>难题，看有没有提升]
    A --> G[小流量上线]
    G --> M[线上监控]
    U -->|失败| X[拦住]
    R -->|掉分| X
    M -->|指标变差| B[回滚]

从左往右，越往后越慢、越贵、越接近真实情况。便宜的检查放前面，先把明显的问题拦住，就不用为它花贵的评测钱。

• 单元测试：不调模型，只测确定性的代码。我项目的 tests/test_regressions.py 就是这一层：路径越界检查、退出码不被截断、read_file 翻页、验收能识别非 build 名字的构建目录、主机构建和空项目必须判失败。里面甚至用写死剧本的假模型（FakeClient）测了 Agent 循环的计数逻辑。每一个在真实评测里踩到的 bug，修完都补一条这样的测试，下次就不用靠跑几十分钟的评测才发现
• 回归集：通过率应该接近 100%，所以判断规则可以写得很死：原来能过的，现在过不了就拦住
• 能力集：通过率本来就不高，看的是提升，不作为拦截条件

动手实验 5：一个最小的回归关卡。保存为 gate.py。

import sys

BASELINE = {
    "cJSON": [True, True, True],
    "fmt": [True, True, True],
    "zlib": [True, True, True],
    "libpng": [True, True, False],
}

CANDIDATE = {
    "cJSON": [True, True, True],
    "fmt": [True, False, True],
    "zlib": [True, True, True],
    "libpng": [True, True, True],
}


def check(baseline, candidate, allowed_drop=0):
    problems = []
    for name, before in baseline.items():
        after = candidate.get(name)
        if after is None:
            problems.append(f"{name}: 候选版本没有跑")
            continue
        drop = sum(before) - sum(after)
        if drop > allowed_drop:
            problems.append(f"{name}: 通过 {sum(before)}/{len(before)} -> {sum(after)}/{len(after)}")
    return problems


problems = check(BASELINE, CANDIDATE)
for p in problems:
    print("退化", p)
print("结论:", "拦住发布" if problems else "可以继续")
sys.exit(1 if problems else 0)

实际输出（Python 3.14，只用标准库）：

退化 fmt: 通过 3/3 -> 2/3
结论: 拦住发布

进程退出码是 1。

逐段讲。

• BASELINE、CANDIDATE：两个字典（dict），键是项目名，值是列表（list），记录每轮是否通过。前者是改动前的结果，后者是改动后的。这里数据是写死的，实际使用时从 result_*.json 读
• def check(baseline, candidate, allowed_drop=0)：allowed_drop=0 是默认参数，调用时不传就用 0，意思是”通过次数一次都不许少”
• baseline.items()：同时取出字典的键和值，for name, before in ... 把每一对拆成两个变量
• candidate.get(name)：按键取值，键不存在时返回 None，不会报错；后面 if after is None 专门处理”候选版本漏跑了这个项目”，漏跑也要当问题报出来，不然少跑几道题分数反而更好看
• sum(before)：Python 里 True 当作 1、False 当作 0，所以对布尔列表求和就是通过次数
• continue：跳过本次循环剩下的代码，直接处理下一个项目
• sys.exit(1 if problems else 0)：让程序以退出码 1 结束。problems 是空列表时在条件判断里当作假。退出码是接进自动化流程的关键：CI（持续集成，代码提交后自动跑检查的系统）看到非 0 退出码，就会把这次提交标红，不让合并

注意看结果：libpng 从 2/3 变成 3/3，是”变好”；fmt 从 3/3 变成 2/3，是”变坏”。关卡只关心有没有变坏，一个项目的提升不能抵消另一个项目的退化，所以不看总数（改动前后都是 11/12），逐项比。

自己改一改：

1. 把 check(BASELINE, CANDIDATE) 改成 check(BASELINE, CANDIDATE, allowed_drop=1)，看结论变成什么。想一想：Agent 有随机性，3 轮里偶尔失败一次，该不该拦？
2. 从 CANDIDATE 里删掉 "zlib" 这一行，看输出
3. 改成只把 BASELINE 里 3 轮全过的项目当回归集，libpng 这种不稳定的项目不参与拦截

第 1 题没有标准答案。容忍度设成 0，随机失败会频繁误拦；设得太宽，真退化会漏过去。常见的折中是：先拦住，再对掉分的题多跑几轮确认，确认是真退化再算失败。

评测成本怎么控制。 我项目跑一轮 10 个项目的完整评测要 8 到 10 分钟、一百多万输入 token，每个配置跑 3 轮就翻三倍。几种做法：

最后一条容易被忽略。开源项目每天都在更新，今天克隆的和三天前克隆的可能不是同一份代码，两次评测的差异可能根本不是 Agent 改动带来的。我项目的第一版评测结果里没有记 commit，是在修复提交 1941ce9 里才补上的。

4.11 线上评测简述

离线评测集再好，也只是真实使用的一个小样本。上线之后还要看真实数据。这里只列要点，怎么记录、怎么搭看板放在 10 可观测与线上运维。

线上发现的失败要回流到离线评测集，这是评测集持续变好的主要来源：

flowchart LR
    ON[线上运行] --> SIG[重试 / 放弃 / 点踩 / 抽检]
    SIG --> FAIL[确认是失败案例]
    FAIL --> CASE[写成评测任务<br/>带成功标准]
    CASE --> SET[(离线评测集)]
    SET --> DEV[改提示词 / 工具 / 模型]
    DEV --> ON

我项目没有线上用户，这一层完全没做。能对应上的只有 runs.db：每次运行的工具调用和结果都存下来了，从里面统计失败命令、提炼知识库经验，和”从线上日志找失败案例”是同一个思路。

4.12 我项目评测全过程

把前面零散提到的事按时间串起来。所有数字都来自项目的 eval/REPORT.md。

flowchart TD
    V1["第一版 09-11<br/>10 个项目、25 步、每配置 1 轮<br/>baseline 9/10，rag 10/10"] --> H40["只改步数上限 25→40<br/>libpng 29 步、re2 32 步通过"]
    H40 --> BUG1["读轨迹发现验收 bug<br/>json 没编译任何目标也判通过"]
    BUG1 --> V2["v2 09-13<br/>验收加 ELF 检查、修工具缺陷、每配置 3 轮<br/>baseline 30/30，rag 29/30"]
    V2 --> V3["v3<br/>toolchain 改环境变量<br/>60/60 全过"]
    V3 --> KB["知识库扩到 15 条<br/>检索测试集 48 条"]
    KB --> HO["留出集<br/>5 个新项目 × 3 配置 × 3 轮"]
    HO --> BUG2["验收 bug<br/>libarchive 构建目录不叫 build"]
    BUG2 --> HO2["修复后重跑 45 次<br/>全部 15/15"]
    V3 --> LG["LangGraph 重写对比<br/>手写 30/30，LangGraph 29/29"]

第一版（2026-09-11）

v2：修正验收和工具之后（2026-09-13）

复查 runs.db 发现 json 有两次一个目标都没编译就判了通过，旧数字不能再用。同时改了：验收要求目标架构 ELF 产物、read_file 从开头翻页、截断后退出码不丢、路径检查按层级判断、写文件后重复计数清零。每个配置改成跑 3 轮，步数上限 40。

结果 baseline 30/30，rag 29/30。rag 失败的那次（libpng，run 80）读轨迹发现是自己加的相对路径检查误拦了 ../.xbuild/zig.cmake。

v3：toolchain 改环境变量

唯一改动是用 CMAKE_TOOLCHAIN_FILE 环境变量传 toolchain。结果 60/60；“子目录找不到 toolchain”从 8 次降到 0；被路径检查拦下的 5 次全是真越界，没有误拦。通过率从这里开始完全没有区分度。

知识库扩充与检索评测：从运行记录提炼到 15 条，检索测试集扩到 48 条、分四类统计，混合检索 R@1 45/48 最高。详见 08 RAG 全链路。

留出集：为了防泄漏换 5 个没跑过的项目，3 种配置各 3 轮。第一次跑出 libarchive 9 次失败 8 次，查出是验收写死 build/ 目录，修复后 45 次作废重跑。结果全部 15/15，平均步数 14.2 / 15.7 / 16.8，差异在一倍标准差以内，重抽样区间跨过 0（见 4.7 节实验）。

LangGraph 对比：同样的提示词、工具、验收，只换循环写法。手写 30/30，LangGraph 29/29（有 1 次因为 DeepSeek 余额不足返回 402 崩溃，不计入）。步数、token 看不出差别。详见 12 框架与协议。

回头看这一路，几件事值得记住：

1. 评分器被修了两次，每次都让之前的结果作废。 评测里最该怀疑的不是 Agent，是评分器
2. 能说清因果的只有单变量改动：步数上限、toolchain 传递方式。同时改几处的那一轮，只能当参考
3. 通过率一路从有区分度走到饱和，后面的比较只能看步数和 token，而这些指标波动大，样本又少，大多只能算趋势
4. 结论写成”未能证明有效”，而不是”有效”或”无效”，这是样本量允许说的最多的话

第五部分 对照项目

对照开源实现：pi

pi（05 篇第五部分介绍过）有一个很小的评测包 packages/evals，源码一千多行，建在开源的 vitest-evals 上。规模撑不起一整套方法论，但有几处做法和本篇、和我项目的评测可以直接对照。源码以 commit 7b4cfd6 为准。

怎么跑一道题。 每次运行在系统临时目录里新建一个独立目录，放进项目和 Agent 配置，起一个真实的 Agent 会话跑完；结束后先把整份会话记录（07 篇讲的 JSONL 轨迹）存成评测附件，再删掉临时目录（pi-harness.ts L216-L234）。所有运行的索引写进 runs.jsonl，轨迹放在 sessions/ 下。

怎么比较两个配置。 把”基线”和”候选”定义成两套配置，可以差在提示词、工具、技能、模型任意一项，同一批题各跑若干轮（README 的例子是 6 轮）。报告里：

另外一个细节：对比评测里把”分数低”当成观察结果，不让测试失败（judgeThreshold: null）；只有”评测本身能不能正常跑”这类前提才用会失败的断言。

怎么打分。 仓库里的文档审查评测是个好例子（docs.eval.ts）：让 Agent 逐页检查官方文档和源码是否一致。它没有让 Agent 用文字回答再去解析，而是专门给了一个 submit_documentation_audit 工具，参数 Schema 固定为”结论（一致 / 不一致）、说明、文档证据、代码证据”，调用后直接结束运行。评分就是检查”这个工具恰好被调用了一次、结论是一致”。

和本篇、和我的项目对比：

值得讲的点：

1. 用一个”提交结论”工具把开放式答案变成可以程序判断的结果。 本篇 4.4 节说能用代码判断就别用模型当裁判。文档审查本来是开放式任务，pi 的办法是把输出格式交给工具的参数 Schema 约束，评分只看结构化字段。这和 02 篇”强制调用某个工具来拿结构化输出”是同一个技巧，用在了评测上。

2. 低分不算测试失败，这是评测和单元测试的区别。 单元测试是”必须对”，对比评测是”测量有多好”。如果分数低就让整个测试挂掉，一次候选配置表现差就会中断整批对比，拿不到完整数据。

3. 它也没做统计检验。 pi 的报告只给配对差值，没有置信区间。README 把方法论交给外部的指南。所以面试时说”开源项目都这么做”不能当成结论正确的理由，4.7 节讲的标准误、配对差值的置信区间仍然是更严谨的做法。

第六部分 追问清单

第七部分 闭卷自测

1. 说出评测里的五个基本术语，并对应到我项目。

2. 能力评测和回归评测的通过率分别应该是什么样？各自用来做什么？

3. 模型当裁判有哪几种常见偏差？为什么只看它和人工的一致率不够？

4. 实验 3 里，留出集配对差值的 95% 区间是 [-0.73, 5.27]，能得出什么结论？为什么按项目重抽样？

5. 单次成功率 70%，pass@3 和 pass^3 大约是多少？客服 Agent 该看哪个？

6. 我项目第一版 baseline 9/10、rag 10/10，为什么不能说知识库有效？

7. 我项目的验收出过哪两次 bug？分别是怎么发现的、怎么修的？

8. v2 到 v3 只改了 toolchain 的传递方式。哪些变化可以归因于这个改动，哪些不行？

9. 实验 5 的回归关卡里，改动前后总通过数都是 11/12，为什么还是拦住了？

10. 为什么评测结果里要记录被测项目的 commit？

11. 跑一轮完整评测很贵，列出至少四种控制成本的办法。

12. 所有配置都 100% 通过，说明什么？该怎么办？

13. 线上发现的失败案例应该怎么处理？

14. pi 的文档审查评测要判断”文档和代码是否一致”，这是开放式问题。它是怎么做到不用模型当裁判、直接用程序打分的？

延伸阅读

1. Anthropic：Demystifying evals for AI agents（2026-01）— 术语、三类评分器、pass@k 与 pass^k、能力与回归评测、读轨迹
2. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena（2023）— 模型当裁判的一致率和几种偏差
3. Adding Error Bars to Evals（Evan Miller，2024）— 给评测结果算置信区间、配对比较、聚类标准误
4. τ-bench（2024）— 工具和用户交互场景的 Agent 评测，提出 pass^k
5. Evaluating Large Language Models Trained on Code（2021）— Codex 论文，pass@k 无偏估计
6. RAGAS（2023）— RAG 的自动评测指标
7. BFCL 伯克利工具调用排行榜 — 工具调用能力的公开评测
8. pi：evals 包（commit 7b4cfd6）— 一个编程 Agent 的端到端评测：隔离目录、保存轨迹、基线和候选配对对比
9. Anthropic：Quantifying infrastructure noise in agentic coding evals（2026-02）— 容器资源配置对分数的影响和报告建议
10. Anthropic：Eval awareness in Claude Opus 4.6’s BrowseComp performance（2026-03）— 模型识破评测、找到答案文件的真实案例
11. SWE-Bench Pro（Scale AI，2025）— OpenAI 停报 SWE-bench Verified 后推荐的编程基准

下一篇：10 可观测与线上运维——评测管发布前，可观测管发布后，Agent 在线上每一步做了什么要能查到。