在使用 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. 跑一遍全量评测集2. 拿结果与基线版本进行对比
3. 输出一份清晰的差异报告
4. 标记出所有退化的样例
5. 根据数据做出决策：直接上线、小流量灰度，还是继续优化
关键不在于“得了多少分”，而在于“能否精准定位是哪一类场景出了问题”。
六、评估报告模板（可直接使用）
一份最小可用的报告，应包含以下几部分内容：
1. 总览指标：总体通过率、P95 时延、平均成本2. 分层指标：Basic、Edge、Real 三层各自的通过率
3. Top 退化样例：写明样例 ID、退化原因和修复建议
4. 上线建议：给出明确结论——直接上线 / 小流量灰度 / 暂缓上线
七、三类常见的退化根因
1) Prompt 漂移
最典型的场景：优化一个任务的同时，无意中破坏了另一个任务的能力。
2) 工具契约变化
接口的字段发生了变动，但编排逻辑没有同步更新，导致调用失败。
3) 上下文膨胀
输入越来越长，模型的核心注意力被稀释，使得关键任务的表现下降。
应对这些问题的策略也很明确：对 Prompt 进行版本化、做好工具契约测试、对上下文进行裁剪或摘要处理。
八、从零到一的最小执行清单
今天就行动起来：
1. 先收集 20 条样例，按 8/6/6 的比例分层2. 为每一条样例写清楚通过标准
3. 编写一个基础的回归脚本
4. 之后每一次改动，都强制运行一次评测
5. 每周复盘那些退化的样例，找出根因
理想很丰满，现实可以先简单些。先把这套机制搭建起来，再慢慢追求评测的精细度。
结语
评测集不是锦上添花的附属品，而是 Agent 工程化的基石。
当你能够稳定地回答这三个问题：哪些能力变强了？哪些场景退化了？这次改动值不值得上线？——恭喜你，你已经真正进入了可持续迭代的阶段。
