给 Agent 建评测/回归集
系列入口：如何使用 Agent。前置：如何验收产出。
一、为什么一次性验收还不够
上一篇讲的验收解决的是"这一次做对了吗"。但当你反复用 Agent、或团队多人协作、或你在调整提示词/Skill/模型时，会冒出新问题：改了一处配置，以前能做好的任务会不会悄悄退化？不同模型、不同版本，哪种在我们的真实任务上更稳？靠人每次肉眼回归既慢又不一致。
评测集要解决的是"可重复、可比较、可自动判定"： 把一组有代表性的任务和它们的标准答案固定下来，每次改动后自动跑一遍，质量是否保持、是否进步，一目了然。它把验收从一次性的人工动作，升级成长期运行的质量护栏。
二、第一步：挑选金标准样本
评测集的质量，首先取决于样本选得好不好。样本太少或太偏，跑出来的结论会误导你。
要有代表性。 样本应覆盖你真实业务中高频、且做错代价高的任务类型，而不是挑几个最简单好看的。一个实用的构成思路是按比例混合：典型的正常任务、容易出错的边界情况、以及——尤其宝贵的——历史上真实发生过的故障或返工案例。把曾经踩过的坑做成样本，等于让每次回归都自动确认"这个老问题没有再回来"。
样本数量不必贪多，初期十几到几十个高质量样本往往胜过几百个同质用例。关键是每个样本都对应一个你能清楚描述的"正确表现"。随着使用积累，再不断把新遇到的典型问题补进来，让评测集随真实风险一起生长。
三、第二步：定义可判定的标准答案
每个样本都需要一个"金标准"——什么叫做对了。这里要根据任务类型选择判定方式，因为不是所有产出都能简单地判等。
对确定性强的任务（数据转换、查询结果、结构化输出），用精确的自动断言：输出应等于什么、必须包含哪些字段、哪些约束不能破。机器一跑就给出通过与否，客观且零成本。对开放性较强的任务（一段方案、一份说明），精确判等不现实，这时可以用多维评分规则替代：是否满足需求要点、有无事实错误、结构是否符合约定，每维给出可操作的判定，必要时辅以模型互评加人工抽检。
无论哪种，标准都应来自需求和真实意图，而不是某次 Agent 的实际输出。最要避免的，是看到它这次产出什么，就把那个结果直接存成"标准答案"——那样实现错了、答案也跟着错，评测集会和实现一起腐化，彻底失去意义。
四、第三步：自动化并接入门禁
有了样本和标准，就要让它能被一键、反复运行，而不是靠人手动逐个比对。
把评测脚本化：给定样本，调用 Agent（或你要评估的提示词/模型/Skill），收集产出，按标准自动判定，最后汇总成一份清晰的通过率/得分报告。这样当你升级模型、调整 Skill、修改规则后，跑一遍就知道整体质量是升是降、哪一类任务退化了。
更进一步，把它接进 CI 当质量门禁：涉及 Agent 行为的改动，如果让评测集跌破基线就合不进来。这让"防止隐性退化"从靠记忆和运气，变成系统强制。需要注意评测通常比普通测试慢、可能涉及调用成本，因此可区分轻量的快速回归与完整评测，在不同时机运行。
五、评测集 vs 普通测试集
这两者常被混淆，理清边界有助于用对地方。
普通测试集检验的是确定代码的行为：给定输入，代码应产生固定输出，跑得快、判定精确，随代码一起运行。评测集检验的是Agent 在一类任务上的整体表现：输入可能是开放式需求，产出带有一定变化，判定可能包含评分而非纯判等，且常用来横向比较不同模型或配置。
可以这样理解：普通测试回答"这段代码对不对"，评测集回答"这套 Agent 配置在我们的真实任务上靠不靠谱"。两者互补——测试守住具体逻辑，评测集守住端到端的能力水位。
六、让评测集不腐化
- 标准独立于实现：金标准来自需求，绝不照某次输出抄。
- 持续补充真实故障：每出一次典型问题，评估是否值得固化为新样本。
- 定期复核：删去过时或不再代表业务的样本，更新随需求变化的标准。
- 追踪历史分数：让质量随时间的变化可见，而不是只看一次通过。
- 防止"应试"：保留部分不公开的样本用于验收，避免配置被调得只讨好公开集。
七、一个样本长什么样
把抽象要求落成具体例子更有指导性。一个样本通常由三部分组成：任务描述、输入材料、判定标准。
例如一个数据处理类样本，任务是"按给定规则清洗这批订单"，输入是一份含空值、重复行、非法日期的小型订单文件；判定则写成可自动检查的断言：输出行数应为多少、重复行被去除、非法日期行被隔离到错误清单、关键字段非空。Agent 跑完，脚本逐条比对，哪条不满足一目了然。
而一个方案类样本，任务是"为这个模块设计缓存方案并说明取舍"，输入是该模块的真实代码与访问特征；判定不是判等，而是一张评分表：是否命中"缓存键如何设计、失效策略、一致性风险"等必答要点（每点计分）、是否出现与代码事实不符的陈述（扣分项）、结构是否符合团队模板。这样即使措辞不同，只要要点和事实达标就能通过。关键在于：标准里的每一条都要可操作、可判定，不能是"写得好""思路清晰"这类无法落地的主观词。
八、评分规则怎么定才稳定
开放性产出最怕"同一结果这次给过、下次不给过"。稳定的评分需要把标准写细到不同评判者都能得出相近结论。
一个实用技巧是为每个评分维度给出分档锚点：明确什么情况算满分、什么算部分分、什么算零分，并配一两个正/反例。比如"命中要点且事实正确得满分；提到要点但表述模糊得半分；遗漏或事实错误不得分"。这样无论由人、由模型互评、还是隔几个月后由你自己复评，尺度都不会漂移。
硬性、客观的要求（必须包含的字段、绝不能违反的约束、规定的输出格式）应尽量交给机器自动检查，把宝贵的人工评判留给真正需要理解的部分。自动化能判定的越多，评测越便宜、越能高频运行，也就越能真正起到门禁作用。
九、运行节奏与成本控制
评测不是跑得越多越好，而要按改动风险和成本安排节奏。
可以分两层：核心快速集由十几个最高频、最关键的样本组成，跑得快、成本低，在每次改动提示词、Skill 或规则后立即运行，快速发现明显退化；完整评测集包含全部样本和更多边界情况，较慢、调用成本较高，放在合并前或定期（如每周、每次模型升级时）运行，给出全面的能力水位。
这样既不会因为评测太慢而让大家干脆不跑，也不会因为只测一小撮而漏掉长尾退化。调用外部模型产生费用时，还可以在快速集里多用本地可复现的确定性检查、只在必要处调用模型，进一步压低成本。
十、两个最容易踩的坑
一是金标准照抄某次输出。 这是评测集腐化最常见的入口：看到这次结果"看起来挺好"就存为答案，一旦实现本身有误，错误就被永久固化，之后任何正确的修改反而会"不通过"。务必让答案回到需求和真实意图独立确定。
二是只保留公开样本、反复据此调优。 如果所有样本都对调参者可见，配置很可能被调到只在这几十条上表现优异——类似"应试教育"，真实新任务却没改善。保留一部分不公开的隐藏样本专用于最终验收，两组分数一对比，虚高立刻现形。
十一、评测报告该包含什么
跑完评测，输出的报告质量决定了它能不能驱动改进。一份只写"通过率 80%"的报告几乎无法指导行动。
好的报告至少回答几件事：总体水位（通过率或平均得分）以及与上一次的对比是升是降；分类型表现，哪一类任务稳定、哪一类退化明显，而不是只有一个平均数；具体失败项，列出哪些样本没通过、差在哪个判定点，让人能直接定位问题；最好还有历史趋势，让"这次模型升级/提示词调整到底带来净收益还是净损失"一目了然。
当评测用于横向比较（不同模型、不同提示词版本）时，应保证对照公平：同一批样本、同样的判定标准、相近的运行条件，最好多跑几次以抵消模型输出的随机性。报告的价值在于把"我感觉这次好像差了点"变成"这三类任务各退化了多少、失败样本是哪些"，从而让改进有的放矢。
十二、什么时候值得扩充评测集
评测集不是一次建成、之后冻结的东西，它需要随业务和风险生长，但也不能无脑膨胀——同质样本堆得再多，只是增加成本、不增加信息量。
值得新增样本的信号很明确：线上或验收中出现了一类新的典型错误，把它固化下来能防止复发；业务新增了一类高频任务，现有样本未覆盖；某次模型升级在某类任务上表现异常，需要专门监控。反过来，长期稳定、从不失败且与其他样本高度同质的用例，或已随业务下线的场景，可以考虑精简，让评测集保持"每一条都在守护某种真实风险"的状态。
判断是否新增的一个好问题是："这个样本失败时，意味着一个我真正在乎的能力退化了吗？"答案为否，就不必加。用真实故障驱动扩充、用价值密度决定取舍，评测集才能在不臃肿的前提下，始终对准最要紧的质量。
十三、让团队真正用起来
再好的评测集，如果没人在改动后真的去跑，也只是仓库里的一堆文件。让它落地，关键是把运行成本降到足够低、并和现有工作流自然衔接。
最有效的方式是自动化优先：一条命令或一次提交就能触发，结果以清晰的红绿报告反馈，而不是要求人记得手动执行、人工比对。再把它嵌入已有的环节——提示词/Skill 变更后的快速回归、合并前的门禁——让评测成为"顺手就做"的事，而非额外负担。门槛也应合理：轻微波动可提示观察，只有真正跌破基线才阻断，避免评测因频繁误报而被团队厌烦、绕过。
同时让评测结果对团队可见、可讨论：每次模型升级或规则调整后的分数变化，本身就是共同决策"该不该升级、哪类问题要优先解决"的依据。当评测足够省事、结论足够有用，它就会从'被要求执行'变成大家主动依赖的质量共识，评测集才算真正活了起来。
十四、常见问题
Q：开放性产出没法精确判等，还能做评测吗？ 能。用多维、可操作的评分规则替代判等，配合自动检查硬性要求（结构、禁用项、要点覆盖）加少量人工/模型抽检，同样能形成稳定的质量信号。
Q：评测成本高、跑得慢怎么办？ 分层：用少量核心样本做每次必跑的快速回归，完整评测放在合并前或定期运行；样本也重质不重量。
Q：评测集能直接当训练/调优依据吗？ 它很适合用来比较不同配置，但要保留一部分隐藏样本，否则反复针对同一组样本调整，可能在这组上虚高、真实场景却没改善。
Q：什么时候该开始建评测集？ 当你开始反复依赖 Agent、或要在多个模型/配置间做选择、或已被"改一处退化一处"困扰时，就值得投入；越早积累真实故障样本，长期收益越大。
Q：评测集和线上监控是什么关系？ 互补。评测集是离线、可控、可反复比较的能力体检，适合在变更前后判断退化；线上监控看的是真实流量下的表现与漂移，覆盖面广但难以精确归因。成熟做法是两者结合——评测集守变更关口，线上监控发现分布变化，再把新的真实问题回流成评测样本。
八、检查清单
- 样本覆盖高频正常任务、关键边界和历史真实故障。
- 每个样本的金标准来自需求、判定方式明确可重复。
- 评测可一键运行并输出通过率/得分与退化项。
- 已接入 CI 或合并前流程作为质量门禁。
- 评测集与普通测试分工清晰，持续补充、定期复核。
- 保留隐藏样本，防止面向公开集"应试"。
总结
给 Agent 建评测集，就是把验收沉淀成可重复运行的资产：挑选覆盖正常、边界和历史故障的金标准样本，为每类任务定义独立于实现、可自动判定的断言或评分，脚本化运行并接入 CI 当质量门禁；它检验的是"整套 Agent 配置在真实任务上的水位"，和检验具体代码的普通测试互补；只要坚持标准不照抄产出、持续补充真实故障、保留隐藏样本，就能可靠地防止"改一处、退化一片"。