做过 Agent 的人迟早会遇到这个尴尬：调 Prompt 时按下葫芦浮起瓢——为了修好 A 类问题改了指令，结果 B 类问题悄悄退化了，上线才被用户发现。

这本质是个缺回归测试的问题。传统软件改完跑测试套件就知道有没有破坏存量功能，Agent 也该有这么一道门。这篇讲讲我怎么用平台的"效果测评"功能给 Agent 搭回归测试，给同样要对 Agent 质量负责的测试/后端同学参考。

为什么 Agent 特别需要回归测试

Agent 的输出是概率性的、对 Prompt 敏感的：你改一个字，行为可能就变。而且它是多环节串联的，端到端答错时很难一眼定位是哪一环退化了。靠人工每次上线前手点几条样例，覆盖不全、也不可复现。 所以需要一套固定的测试集 + 可量化的评分。

做法：把"效果测评"当回归套件用

我用的平台（讯飞星辰，自带效果测评，别的平台有类似的也行）思路是这样：

1. 攒一个测试集：把历史上出过问题的、各类典型的用户问法收集成一批用例，连同期望表现一起存下来。这步是核心资产，得自己积累。

2. 每次改完跑一遍：改了 Prompt / 换了模型 / 调了知识库后，用这批用例批量跑，看每条的实际输出和评分。

3. 对比基线：和上一版的得分比，哪条退化了一眼看出来，定位到是哪个环节的问题，再决定要不要回滚这次改动。

几个实践要点

• 测试集质量 = 这道门的质量。用例覆盖得越全、越贴近真实问法，回归才越有意义。空有工具、没有好用例，等于没门。

• 评分别全靠自动。有些维度（语气、是否得体）自动打分不准，关键用例我会人工复核，自动分只作初筛。

• 把"出过的事故"沉淀进测试集。每次线上发现一个 bad case，就补进用例库，让同样的错不再犯第二次——这是回归测试最大的价值。

一句实话

这套不是免费的：测试集得你自己一点点攒，工具只给了"批量跑 + 量化打分"的能力，攒用例、定期维护仍是人的活。但一旦建起来，你改 Agent 就从"凭感觉、提心吊胆"变成"有数据兜底、敢改敢上"。

对要把 Agent 真正当生产系统来维护的团队，这道质量门挺值得搭。