让 Agent 的评测可回放：从一份小样例集开始

一段演示跑通，能说明某次任务完成了。修改提示词、替换模型或增加工具后，它是否仍然有效，需要另一种检查：把同一批任务重新运行，比较结果和失败方式。

这篇笔记讨论如何设计一份小型 Agent 评测集。文中的任务与数据均为虚构示例，没有连接模型服务，也没有测量任何模型的性能。

先写成功条件，再挑样例

OpenAI 的评测最佳实践将评测目标、数据、指标和持续比较放在同一个流程里。这个顺序很有用：如果还说不清“完成了什么”，先收集大量题目也很难得到有意义的结论。

对于一个从会议纪要中提取任务的 Agent，可以先问三个具体问题：负责人是否有原文依据？未提供的截止日期是否保持为空？输出是否符合约定结构？这些条件比“回答看起来不错”更容易检查。

一条样例可以包含输入、可固定的工具响应、预期结果和判定规则：

{
  "id": "missing-deadline",
  "task": "提取纪要中的负责人和截止日期",
  "fixture": "任务：补齐接口文档。负责人：示例团队。",
  "expected": {
    "owner": "示例团队",
    "deadline": null
  },
  "requirements": [
    "没有原文依据的日期不填写",
    "以约定字段返回"
  ]
}

这是评测数据的设计草图，不是某个框架的固定格式。实际系统可以使用 JSON、JSONL 或测试代码保存样例；关键是让输入和判定规则都能被找到、审查和复用。

分开看最终结果与执行记录

Anthropic 关于 Agent 评测的工程文章区分了执行记录与环境中的最终结果。Agent 说“任务完成了”，并不能代替对真实结果的检查。

对文档提取任务，结果检查可以读取结构化输出，核对字段。执行记录则帮助解释错误来自哪里：是否读取了正确文档，工具返回了什么，是否在缺少信息时继续推测。

我的建议是先保留一份简洁的可观察记录，包括样例 ID、工具名称、经过脱敏的输入与响应、判定结果和错误类别。不要把完整私人文档或访问令牌默认写进日志，也不需要保存模型内部推理才能完成这些检查。

固定工具响应，但说明评测范围

外部文档会更新，搜索结果会变化，服务也可能暂时不可用。如果每次回归都依赖这些变化，就很难判断一次退步究竟来自代码修改还是外部环境。

可以为回归样例固定工具响应，再单独保留少量实际集成检查。Python unittest 文档介绍的测试 fixture，以及每次测试前的 setUp()，提供了一个简单的组织思路：每个任务从已知状态开始。

固定响应可以帮助隔离变量，却不能证明真实接口、最新文档或权限配置一定正常。评测报告应分别说明“固定样例检查”和“实际集成检查”的范围，避免用前者的通过代替后者的验收。

让评分器适合问题

字段是否存在、日期是否为空、工具是否被调用，可以优先用代码检查。表述是否清楚、摘要是否遗漏关键含义，则可能需要明确的评分说明和人工抽查。

Anthropic 的文章讨论了代码、模型和人工这几类评分方式。模型评分器也需要校准，不能因为它返回一个数字，就把这个数字当成客观事实。

小项目可以先采用两类记录：一类是关键要求的通过或失败，另一类是供人工复核的质量备注。明确的结构错误不应被“文风不错”抵消；合理的同义表达，也不应该仅因字符串不同就被判错。

保存一个基线，比较同一批任务

修改前保存样例集、评分规则、提示词、模型配置和工具版本，再使用同一批任务比较修改后的表现。如果需要重复运行，应提前确定次数和汇总方式，保留失败记录，不挑选最好的一次展示。

样例数量少时，结果只能描述这批任务。把它写成整个真实使用场景的成功率，会超出证据范围。评测集应逐步加入已经发现的失败案例，同时保留独立检查样例，减少反复针对同一份题目调优造成的错觉。

一份小而可回放的评测集，最先提供的价值是让变化有迹可循：什么仍然有效，什么退步了，以及下一步应该检查哪里。它不是对 Agent 可靠性的全面保证，但比只记住一次成功演示更便于持续改进。

参考资料

资料核对日期：2026-10-12。本文由 AI 辅助撰写，属于基础工程设计笔记；未调用模型 API，未报告实测性能。