从零构建Agent评测集：能力不退化验证

迭代多版 Agent 后，你大概率会撞见这种局面：每次修改完，心里都没底——这次效果是提升了还是倒退了？

拆开来说，无非这几类：新版本在 A 场景表现亮眼，到了 B 场景却直接崩溃；Prompt 只微调了一行，成功率就像过山车忽高忽低；团队里谁都拍胸脯说“稳了”，结果一上线就被现实打脸。

问题的关键，不是参数没调到位，而是缺少一件核心工具——评测集（Evaluation Set）。

从零构建 Agent 评测集

一、为什么评测集不可或缺？

一句话讲透：没有评测集，就无法实现可控迭代。

评测集的核心价值，是把“我觉得还行”这种主观感受，转化为“数据一目了然”的客观依据。它能帮你精准回答几个关键问题：新版本到底进步了还是退步了？哪些原本能胜任的场景，现在反而失效了？成本和响应速度有何变化？最终，这些数据才是你决定“是否上线”的底气来源。

二、从零搭建评测集：先分层再填充

新手常犯一个错误——评测集里全是“完美样本”，这样的测试只能证明系统能跑通，却完全暴露不出真实水平。

建议至少拆成三层：

1) 基础样例（Basic）

用来验证核心链路是否畅通，好比确认火车没有脱轨。

2) 边界样例（Edge）

专门挑战极端场景：异常输入、脏数据、超长内容、工具调用超时……这些才是检验系统容错能力的试金石。

3) 真实样例（Real）

直接从线上高频任务里抽取，最贴近用户实际场景，最能评估真实价值。

经验上，一个可行的配比是：Basic 占 40%，Edge 和 Real 各占 30%。

三、每条样例都必须有“通过标准”

评测最怕“差不多就行”。每条样例至少得包含四要素：输入（Input）、预期输出（Expected）、判定规则（Judge Rule）和关键指标（成功率、时延、成本）。

举个例子：

输入是一个网页链接加“摘要需求”；预期输出是这份摘要必须包含 3 个核心要点和 1 个风险提示；判定规则是“字段完整”且“内容相关性达到指定阈值”。

标准定义得越清晰，后续评分才越有底气。

四、评分方式：先跑通规则，再追求精细

从“规则评分 + 抽样人工复核”起步，是最务实的路径。

1) 规则评分

最适合结构化任务，例如检查字段是否完整、格式是否合规、错误码是否正确。

2) 模型辅助评分

适合语义理解类任务，例如判断答案的相关性、覆盖度、逻辑一致性。

3) 人工复核

留给高风险任务，例如内容发布、金融医疗建议，或涉及真实世界动作的决策。

核心思路是：先把规则跑通跑稳，再让模型辅助提升效率，兼顾安全与速度。

五、回归流程怎么做才高效？

任何一次变更——无论是切换模型、调整 Prompt、修改工具还是重构流程，都应当触发回归测试。

标准流程如下：

关键不在于“得了多少分”，而在于“能否精准定位是哪类场景出了问题”。

六、评估报告模板（可直接套用）

一份最小可用的报告，应包含以下模块：

七、三类常见退化根因

1) Prompt 漂移

最典型场景：优化某个任务时，无意中破坏了另一个任务的能力。

2) 工具契约变化

接口字段变了，但编排逻辑未同步更新，导致调用失败。

3) 上下文膨胀

输入越来越长，模型的核心注意力被稀释，关键任务表现下滑。

应对策略很清晰：Prompt 版本化、进行工具契约测试、对上下文做裁剪或摘要。

八、从零到一的最小执行清单

今天就可以行动起来：

理想很丰满，现实可以先从简。先把这套机制建立起来，再逐步提升评测的精细度。

结语

评测集不是锦上添花的附属品，而是 Agent 工程化的基石。

当你能够稳定回答这三个问题：哪些能力变强了？哪些场景退化了？这次改动值不值得上线？——恭喜，你已真正进入可持续迭代的轨道。