Agent版本对比测试要回答两个问题：新版本是否引入了不可接受的行为退化，以及声称的改进是否在可控范围内真实发生。单看最终答案只能覆盖最表层的变化，无法解释为什么有的用例成功率上升而另一些用例延迟翻倍。更可靠的做法是把每一次运行当作一条完整轨迹来记录，包括工具调用列表、参数选择、重试次数、中间错误和最终输出，再在不同版本之间做结构化对比。
对于工具调用型Agent来说，最终答案正确并不代表执行路径健康。假设一个客服Agent旧版本处理退款咨询时需要2次工具调用，新版本在相同用例上要执行5次，其中3次是因为权限校验失败后的重试。最终用户依然收到了退款申请已提交的回复，表面上看没有回归，但实际延迟从800毫秒增加到2400毫秒，token消耗也翻了一倍。这类问题只有把轨迹记录下来才能发现。因此在版本对比测试中，必须同时采集结果指标和过程指标，否则测试报告会给出虚假的安全感。
为什么Agent版本对比不能只看最终答案
Agent与普通文本生成模型最大的区别在于它会与环境交互。一个稍微复杂的任务可能经历查询工具、解析返回、调整计划、再次调用工具、汇总答案等多个步骤。版本升级时，提示词、工具描述、规划策略、上下文截断长度等任何一项变化，都可能改变中间行为。中间行为变化又可能带来三类风险：一是路径漂移，比如从先查订单再查用户变成先查用户再查订单，单次结果虽然一致，但并发下可能触发外部接口限流；二是资源膨胀，例如新版本为了更高的成功率反复重试，导致平均调用次数上升；三是边界异常，旧版本在工具返回空数据时会走兜底策略，新版本却直接结束任务。
只看最终答案还会被非确定性干扰。同一个Agent版本对同一提示词运行两次，答案措辞可能不同，甚至成功率也有波动。如果只比较一次运行结果，很容易把随机波动误判为回归或改进。更合理的做法是对每条用例运行多次，记录成功率分布和轨迹稳定性。对于工具调用轨迹，可以用工具名称序列的哈希值来判断路径是否一致，但哈希一致只是强约束，很多时候哈希不同也未必是回归，需要结合指标进一步分析。
因此，版本对比测试应当从最终答案扩展到四个维度：结果正确性、过程一致性、资源消耗、异常鲁棒性。结果正确性回答用户任务是否完成，过程一致性回答做事方式是否稳定，资源消耗衡量延迟与成本，异常鲁棒性关注工具失败、超时、权限不足等场景下是否仍能优雅降级。缺少任何一个维度，测试结论都不可靠。
构建可复用的Agent评测集
评测集的质量直接决定版本对比测试的价值。临时手写几十条提示词会让测试结果波动很大，也不利于长期追踪。一个可复用的评测集应当按业务场景分层组织，每个用例都包含明确的前置状态、输入、期望结果约束和执行限制。下面是一个客服Agent退款场景的用例结构：
{
"case_id": "refund_023",
"category": "refund",
"prompt": "用户要求退还最近一笔订单中的一件商品",
"pre_state": {
"user_id": "u_8821",
"orders": ["order_104"]
},
"expected": {
"contains": ["退款申请已提交"],
"forbidden": ["直接退款成功"]
},
"max_steps": 6,
"allowed_tools": ["query_order", "query_user", "create_refund"]
}
这个结构不只是记录输入输出，还限制了允许使用的工具和最大步数。限制工具范围可以防止新版本走捷径，例如跳过必要的校验直接调用创建退款接口。最大步数可以避免Agent陷入无意义的循环。前置状态则让测试可以在隔离环境中重复执行，不至于因为数据库残留数据导致结果不稳定。评测集应当按场景比例分布，例如查询类占40%、修改类占30%、投诉类占20%、异常类占10%，这样报告的指标才能代表真实流量。
构建完评测集后，还需要管理用例版本。建议把评测集放入版本控制系统，每条用例增加修改记录和评审流程。回归锚点尤其重要：那些曾经导致过线上事故的用例，应标记为高优先级，每次版本对比都必须执行。对于新功能，可以先从少量探索性用例开始，等行为稳定后再固化成回归用例。这样可以避免评测集无限膨胀，同时让测试重点始终覆盖高风险区域。
回归判定的关键指标与统计方法
有了轨迹数据后，如何判断新版本是否出现回归？最常见的方式是设置固定阈值。比如任务成功率下降超过2个百分点、轨迹一致率下降超过10个百分点、P95延迟增加超过25%、平均工具调用数增加超过2次，满足任一条件就标记为疑似回归。下面是一个简单的对比脚本框架：
def compare_traces(baseline, candidate, cases):
regressions = []
for case in cases:
base = run_trace(baseline, case)
cand = run_trace(candidate, case)
if cand.success and not base.success:
continue # 改进，不标记回归
if cand.latency_ms > base.latency_ms * 1.25:
regressions.append((case.id, "latency"))
if cand.tool_calls > base.tool_calls + 2:
regressions.append((case.id, "tool_calls"))
if cand.path_hash != base.path_hash:
regressions.append((case.id, "path"))
return regressions
固定阈值实现简单，但容易受样本量影响。如果只运行30条用例，成功率下降2个百分点可能只是两条用例的波动。为了减少误报，可以引入统计检验。常见做法是对每条用例运行多次，使用Bootstrap方法估计成功率差值的不确定区间；或者用贝叶斯方法计算新版本优于旧版本的后验概率。对于延迟和调用次数，可以比较中位数而非平均值，因为Agent运行时间经常出现长尾。实际项目中，建议在CI中同时运行一组快速冒烟用例和一组完整回归用例，快速用例用于阻断明显灾难性问题，完整用例用于更细致的版本评估。
下表给出一些常用指标和回归参考阈值：
| 指标 | 回归参考阈值 | 说明 |
|---|---|---|
| 任务成功率 | 相对下降超过2个百分点 | 按任务类型分层统计 |
| 轨迹一致率 | 下降超过10个百分点 | 路径哈希不一致的用例占比 |
| P95延迟 | 相对增加超过25% | 关注长尾而非平均值 |
| 平均工具调用数 | 增加超过2次 | 可能反映重试或规划退化 |
| 重试率 | 增加超过5个百分点 | 外部接口异常和权限错误占比 |
阈值需要根据业务容忍度调整。对金融或医疗类Agent，成功率下降1个百分点也可能不可接受；对内容生成类Agent，延迟和调用次数的权重则可以降低。关键是每次对比测试都使用同一套阈值，并把阈值与线上监控指标对齐。
改进闭环：从差异报告到灰度发布
对比测试的真正价值不在于生成长长的失败列表，而在于把差异转化为可执行的改进动作。测试完成后，需要自动生成一份差异报告，将每个变化用例分类为有意改进、中性变化和疑似回归。有意改进通常表现为成功率提升、调用步骤减少或延迟下降；中性变化可能是路径顺序调整但资源消耗持平；疑似回归则是触发阈值且无法用功能变更解释的用例。报告中应列出具体用例ID、变更前后的指标快照和轨迹差异摘要，方便开发人员快速定位是提示词修改、工具描述变化还是规划器策略调整导致的。
对于疑似回归，优先执行局部回退。如果新版本引入了多个优化点，可以通过开关逐个关闭来隔离变量，定位真正导致退化的改动。改进动作验证后，需要将该用例从回归列表移除，并更新新的基线快照。每次发布版本都应保存一份完整的轨迹快照，这样即使上线后才发现问题，也能与上一个稳定版本做细粒度对比。灰度发布可以进一步降低风险：新版本先覆盖5%的真实流量，观察任务成功率、延迟、错误率和用户反馈，确认没有异常后再逐步扩大到20%、50%直至全量。
把版本对比测试接入持续集成后，每次提交都会自动运行评测集。为了控制运行成本，可以按时间预算分层执行：快速冒烟集在PR阶段运行，完整集在合并前运行，线上灰度阶段再采集真实数据作为最终验证。这样一来，Agent的每次升级就不再是凭感觉评估，而是有轨迹数据、统计阈值和灰度验证支撑的工程流程。回归测试负责拦住退化，改进闭环负责把优化真正落地，两者结合才能让Agent版本迭代保持稳定。