Agent 评测工程（01）：我们要测什么，又希望从结果中知道什么？

开发 Pickel-Agent 的过程中，我越来越需要回答一个问题：改完一段提示词、一种上下文策略，或者换一个模型之后，怎么知道 Agent 真的变好了？

最直接的办法是让它做几件事，看看效果。但一次顺利完成，能说明修改有效吗？遇到一次失败，又应该改模型、工具，还是驱动它们工作的代码？如果以后希望系统自己发现问题、提出修改，这些判断还能只靠人的印象吗？

这也是我开始学习 Agent 评测的原因。不过，故障归因与自进化是这个系列希望逐步走到的地方。在此之前，我需要先学会更基础的事情：怎样设计一个测试，怎样判定结果，以及怎样从结果中得出有分寸的结论。

我对软件测试的方法论也还在补课。因此，这个系列会从具体任务出发，结合传统测试方法、公开基准和小型实验，逐步建立理解。第一篇先说明我们要研究什么，以及后续问题之间的关系。

从一个任务开始：什么才算做对了？

假设我们给一个编码 Agent 这样的任务：

修复这个仓库中配置文件缺失时的报错问题。缺失时应使用默认配置，已有配置的读取行为保持不变。

Agent 阅读文件、执行命令、修改代码，最后回复：“已修复，测试通过。”

这时至少有几件事值得检查。目标仓库里是否真的产生了修改？配置缺失时是否使用默认值？已有配置是否仍能正常读取？它执行的是哪些测试，测试结果又是什么？

这些检查有不同的依据。用户要求确定了需要满足的行为；已有功能提供了需要保护的回归条件；实际文件和测试结果提供了判断证据。Agent 的回复可以说明它声称完成了什么，但不能单独证明补丁有效。

不过，我们也不应该要求它必须修改某一行，或者严格按照预想顺序调用工具。只要满足任务要求，不同实现都可能是合理答案。如果测试只接受作者心中的那一种写法，就可能把正确解判错。

这个例子已经包含了测试设计的基本问题：

• 测什么对象？ 是文件编辑工具，还是完成修复任务的整个 Agent？
• 依据什么判定？ 是明确的功能要求、已有行为，还是需要进一步澄清的预期？
• 怎样获得证据？ 检查文件、运行测试，还是审阅产物与执行记录？
• 结果支持什么结论？ 是这一次任务成功，还是某项修改确实提高了表现？

这些问题要先于“采用哪个 benchmark”和“计算什么分数”。否则，我们可能有一个精确的数字，却说不清它代表什么。

被测的是哪个系统？

对于本文讨论的工具型 Agent，可以用 Model + Harness 理解它的运行组成。模型根据输入产生回复或动作；Harness 负责组织上下文、提供工具、执行调用，以及管理运行循环等。具体项目怎样划分模块可以不同，评测时需要明确实际纳入了哪些部分。

例如，同样是研究工具调用，我们可能测试两个不同对象：

一种测试直接调用文件编辑函数，检查替换、报错和路径限制是否符合约定。另一种测试给真实模型一个修改任务，让它自行寻找文件、选择参数、调用工具，再检查是否完成目标。

前者通过，说明工具在所测条件下按约定工作；后者才把模型如何使用工具也纳入了测试。反过来，完整任务失败，也不能立即说明文件编辑函数出了问题。

这就是明确边界的意义：测试范围决定了哪些行为进入观察，也限制了我们能够解释什么。

还需要区分两个容易混淆的 Harness。Agent Harness 驱动模型工作；Evaluation Harness 则组织评测，负责准备任务、启动运行、记录过程、调用评分器和汇总结果。Anthropic 的评测指南明确区分了这两个概念。来源：Demystifying evals for AI agents

对于 Pickel-Agent，前者是我们正在开发的系统，后者是未来需要围绕它逐步建立的实验设施。评测设施自身也可能出错，例如没有清理上次运行留下的文件，或者把合法结果判为失败。因此，看到失败时，被检查的对象也应包括测试本身。

软件测试已经提供了什么？

Agent 是软件系统，软件测试自然是理解它的一个起点。有状态、会调用外部服务、有多条执行路径、需要端到端验证，这些现象也存在于其他软件中，不能仅凭这些现象就认定传统方法失效。

我准备先借助软件测试中的几个基本概念，建立分析问题的方式：

这里尤其需要理解测试替身的作用。用预设的模型响应驱动循环，可以检查工具调用是否被正确分发，却没有测试真实模型会不会产生合适的调用。固定依赖有助于缩小问题范围，同时也缩小了结论范围。

基础学习可以参考 ISTQB 的软件测试基础大纲，从测试基础、测试层级和用例设计读起。我们的目标是能把这些方法落实到案例中，并解释每项测试的用途。

那么，接入模型之后，还需要关注什么？

在这个修复任务里，工具可以正确执行命令，但选择读什么、如何解释报错、怎样修改代码，包含了模型参与的判断。我们需要用具体任务检验这些行为，也需要观察它们在不同输入和重复运行中的表现。

行为由模型产生，并不意味着只能用另一个模型评分。 修复是否有效，仍然可以通过执行测试来检查。对于报告是否论证充分这样的要求，则可能需要明确的评分规约和人工判断。判断方式取决于要验证的性质，不能仅由组件是否使用 LLM 决定。

同样，“局部测试通过不能保证整体成功”是继续做系统测试的理由，但这也是普通软件测试一直面对的问题。后续文章会具体讨论已有方法怎样应用、哪里需要补充证据，避免先给所有困难贴上“Agent 特有”的标签。

Benchmark 的分数回答了什么？

学习 Agent 评测，很容易先遇到排行榜。但阅读一个分数之前，需要知道它背后的任务、运行条件和判定方式。

例如，τ-bench 构造了包含模拟用户、领域工具和政策的交互任务，并通过对话结束后的数据库状态检查目标是否达成。它已经包含具体业务规则，而非仅仅考察模型知道多少领域知识。来源：τ-bench 论文

GDPval 则研究职业知识工作中的交付物质量，原始研究使用专家盲评比较模型与人类产物。这样的判定方式与执行代码测试不同，因为它要评价的工作成果不同。来源：GDPval 原始说明

因此，公开 benchmark 可以作为评测设计的教材：它怎样选择任务，怎样准备环境，又怎样把“做好了”落实成可执行或可审阅的标准？

但它的任务和标准不一定代表我们的产品。一个模型在某套基准中表现更好，是值得进一步测试的线索；接入 Pickel-Agent 后是否更适合我们的任务，还需要验证。即使固定 Harness 比较模型，结果也仍然带着这套 Harness 和运行条件的限制。

公开或私有说明的是评测材料的可访问性；能力比较、功能验收、故障调查说明的是评测用途。两者不能直接画等号。我们可以借鉴公开基准的方法，再根据自己的任务建立测试，而不必在“打榜”和“产品测试”之间二选一。

从一次成功，到解释一次失败

回到配置修复任务。假设改完提示词后，Agent 成功了。这是一条观察，但它还不足以证明提示词改进有效：旧版本也可能成功，新版本也可能在再次运行时失败。

不同问题需要不同的证据：

例如，Agent 忘记了“已有配置行为保持不变”，可能是相关信息没有进入实际请求，也可能是信息仍在却未被正确使用。仅凭最终失败，无法区分这两种情况。我们需要观察模型实际收到的内容，再设计进一步检查。

记录轨迹有助于提出假设，但看见某一步异常，不等于已经证明它导致最终失败。模型有时能够恢复；多个组件也可能共同影响结果。更有力的判断，需要在可比较条件下改变相关因素，观察结果如何变化，并说明实验的限制。

这解释了为什么本系列会把故障归因放在后面：先能信任测试结果，再学习如何解释结果。将来让系统自动提出修改，也需要沿用这条证据链，检查修改是否有效、是否造成回归，以及收益是否仅限于反复调试的那些案例。

这个系列准备怎样展开？

后续学习会沿着下面的顺序推进，具体篇幅随实验结果调整：

1. 构造第一个测试。 学习测试用例、规格、判定依据与测试层级，用同一个任务比较工具测试和完整 Agent 测试。
2. 建立可信的验收。 检查结果、必要的过程约束与副作用，并用正确解、错误解和不同的合法解检查评分器。
3. 组织评测实验。 准备可重置环境，记录版本、输入、预算和执行过程，区分任务失败与基础设施异常。
4. 设计任务集并比较版本。 学习案例覆盖、任务采样、重复试验、统计不确定性，以及成功率与成本的共同解读。
5. 调查失败并验证改进。 从实际案例出发，学习复现、组件替换和干预实验，再逐步探索持续改进的自动化。

每篇尽量留下一个可以检查的小产物：一份用例、一个验收器、一组运行记录，或者一次有边界说明的比较。文章中的结论也会区分资料介绍、实验观察和仍待验证的推测。

Pickel-Agent 会是贯穿这些学习的实践对象。它提供了真实的工具、上下文和运行循环问题；具体实验则尽量保持足够小，使失败能够被看懂，判断能够被检查。

下一篇先从最基本的一步开始：选定一个小任务，写清输入、环境和成功条件，分别测试它的工具与完整 Agent。完成以后，我们应该能解释这几个测试各自验证了什么，以及还有什么没有被验证。