建立能发现退步的 Agent 评测

先评结果，再看过程

Repo 助手回答“超时已经确认”，并不代表它读过正确配置。一个问答任务的结果可以要求数值正确、环境正确、来源支持结论，以及资料不足时明确弃答。代码任务则检查最终文件状态与相关测试。优先评估可观察结果，再用工具轨迹解释为什么成功或失败。

把任务写成固定输入、初始环境和验收规则。评估一个 Agent 实际上同时评了模型、提示词、工具和 harness。更换任何一项都可能改变结果，所以实验报告要记录各自版本。CS2680 的评测专题可用于理解任务级衡量与基准选择。

小而有区分度的数据集比随手提问更有用

先做二十个自己能够人工核验的任务，覆盖直接答案、多文件覆盖、同名变量、缺失资料、过期记忆和工具错误。这个规模适合发现工程缺陷，不能证明系统在所有仓库都可靠。每个失败任务写明首次偏离点，例如检索遗漏、读取错误、答案无证据或预算用尽。

划分开发集与留出测试集。提示词调试只看开发集，阶段性比较才运行留出集。若同一个仓库的近乎相同问题同时出现在两边，评测容易高估泛化；可以按仓库、任务族或时间切分。公开基准也可能进入模型训练资料，分数应结合新建任务和实际工作样本一起解读。

创建一个简短的运行清单，固定代码提交、模型标识、提示词版本、采样配置、工具版本和预算。温度为零也不等于跨服务版本绝对可复现，因此仍需重复运行。若任务涉及外部网页或远程服务，尽量保存允许保存的响应快照，或在报告中标明外部状态变化，避免把资料更新误判为模型退步。

超时、解析失败和执行错误都应留在结果分母内。只删除失败运行会让成功率和成本看起来更好。确实属于评测设施故障的情况应单独标记，说明排除标准，再重新运行，而不是在看见分数后临时改变规则。

选择能验证目标的评分器

优先用程序检查确定性条件，例如返回值、文件内容和来源是否存在。自由文本不能只靠字符串完全相等，不同表述也可能正确。可先让答案返回 value、environment、evidence 等结构化字段，再验证这些字段之间是否一致。测试只覆盖显式条件，全部通过也不代表任务完全没有其他问题。

解释是否充分等开放问题可以用人工或模型评分。模型评分器需要明确量表、盲化候选名称，并抽样与人工结果校准。让写答案的同一模型直接判断“我做得好吗”可能存在偏差。程序、人工和模型评分各有适用范围，避免为了自动化把容易验证的事实交给模糊判断。

动手：计算重复试验的可靠性

以下代码无需 API。predictions 是人工设定的模拟输出，仅演示评分逻辑与统计口径，不是任何真实模型的成绩。每题运行三次，同时看平均单次成功率、三次至少一次成功比例、三次全部成功比例。

cases = [
    {"id": "prod", "expected": ("answer", 30, "prod.cfg:2")},
    {"id": "test", "expected": ("answer", 5, "test.cfg:2")},
    {"id": "missing", "expected": ("abstain", None, None)},
    {"id": "conflict", "expected": ("abstain", None, None)},
]
predictions = {
    "prod": [("answer", 30, "prod.cfg:2"), ("answer", 30, "prod.cfg:2"),
             ("answer", 30, "README:1")],
    "test": [("answer", 5, "test.cfg:2")] * 3,
    "missing": [("abstain", None, None), ("abstain", None, None),
                ("answer", 30, None)],
    "conflict": [("answer", 30, "prod.cfg:2"), ("abstain", None, None),
                 ("answer", 45, "old.cfg:2")],
}

scores = []
for case in cases:
    # 小型受控数据使用精确字段匹配；真实来源还需检查是否支持答案。
    row = [result == case["expected"] for result in predictions[case["id"]]]
    scores.append(row)
    print(case["id"], row)

single = sum(sum(row) for row in scores) / sum(map(len, scores))
any_success = sum(any(row) for row in scores) / len(scores)
all_success = sum(all(row) for row in scores) / len(scores)
print(f"单次平均: {single:.1%}")
print(f"三次至少一次: {any_success:.1%}")
print(f"三次全部成功: {all_success:.1%}")

结果分别为 66.7%、100.0% 和 25.0%。如果只展示最好的一次，会掩盖大部分任务无法稳定完成的问题。conflict 的预期弃答来自题目约定“覆盖规则缺失”，并非所有冲突都应弃答；若有明确优先级，应该继续核验并得出结论。

把质量、稳定性和成本一起报告

通常用 pass@k 表达在 k 次尝试内至少一次成功，用 pass^k 讨论连续 k 次都成功的可靠性。上述代码计算的是每题固定三次试验的经验比例，不是从更大样本估计 pass@k 的组合公式。若尝试独立且单次成功概率为 p，至少一次成功概率是 1−(1−p)^k，全部成功是 p^k；真实尝试未必独立。

同时记录每题总时长、输入与输出 token、工具次数和总成本。计算成功成本时先明确统计单位。若每次独立试验视为一次任务运行，就用所有试验总成本除以成功运行次数，失败产生的开销也计入总成本。若按原始任务聚合三次尝试，则先把每题的三次尝试成本合并，再用所有题的总成本除以最终成功的原始任务数；此时成功规则应明确为“三次至少一次成功”或其他预先约定的规则。两种口径的分母不同，不可混用。对比新旧方案时固定任务、预算和运行条件，并报告重复次数；少量样本中的一两题波动不宜被解释成稳定改进。

让留出集真的留在系统外面

评测目录里的标准答案、评分说明和隐藏测试不能被 Agent 搜索到，也不要放进持久记忆或检索索引。运行前建立干净环境，运行后清理状态，防止前一题的答案进入下一题。调试时已经看过的测试题应转入开发集，并补充新的留出样本。

每次修改先跑覆盖已知能力的回归集，再用留出任务判断有没有泛化收益。查看失败轨迹后写出可验证的改进假设，例如“来源错误来自检索未区分环境”，然后只修改相关环节。评测最终服务于工程决策，漂亮的总分不能替代对具体失败的理解。

合上书，检查一下

先作答，再看解释。答错的地方，正好是值得再读一遍的地方。

配合本章看视频

下面按本站章节主题选配。为什么没有采用原课录播 →

继续读原始资料

• CS2680：Agent evaluation and benchmarks ↗
• Anthropic：Demystifying evals for agents ↗
• τ-bench 原论文 ↗