先这样答
Agent 的改动是牵一发动全身的：改一行系统提示词，可能修好了 A 类问题，悄悄弄坏了 B 类。所以答案的核心就一句话：把「回归评测」做成改动的强制关卡，评测不过线，改动不上线。
具体分四步。第一步，评测集平时就建好：从真实任务里采集的用例，按任务类型和难度分级，包含正常 case、边界 case、曾经出过事故的 case（每个线上问题修完都把对应场景加进评测集，事故用例库就是这么攒出来的）。第二步，改动前先跑基线：当前版本在评测集上的成绩存档。第三步，改动后全量对比：不只看总体成功率，要按类别拆开看：修 A 类问题的时候，B、C 类的分数是不是掉了。第四步，设门槛：关键指标不回退才能合入；小回退要有明确收益支撑并记录在案。
指标分三类看。任务级：成功率、关键步骤完成率。轨迹级：平均轮数、工具调用序列是否合理、有没有新出现的绕路。成本级：token 消耗、延迟分布。只看任务成功率会漏掉「结果对了但绕了三倍远」这类退化。
上线后还有两道网。灰度：新版本先放小流量，观察线上完成率、人工接管率、用户点踩率，稳定后再放量。回滚：版本和配置支持一键回退，回滚演练平时就要做，等出事时才发现回滚按钮是坏的，就晚了。
面试官会怎么追问
- 提示词改动也要走这么重的流程？ 要。提示词就是 Agent 的代码，而且没有编译器和类型检查帮兜底，评测集就是它的单元测试。轻流程的前提是有轻量的自动化关卡。
- 评测集多久更新一次？ 持续。两个入口：线上出问题的场景回流成新用例；分布变化（新功能上线、用户群体变化）时补新场景。但评测集版本要管理，跨版本对比要注明。
- LLM 输出不稳定，跑两次分数不一样怎么办？ 固定温度和随机种子能压一部分；剩余波动靠多次采样取统计量（跑三遍取平均），以及用足够大的用例量把随机性摊平。
回答的坑
- 只答「多测测」。要给出「基线存档、分类对比、门槛放行、灰度回滚」的完整流程感。
- 忽略轨迹和成本指标。只盯成功率的回归测试挡不住隐性退化。
—— 本题完 ——