你的测试框架，可能根本没在测Agent
去年10月，我们团队上线了一个客服Agent。发布前，测试覆盖率82%，所有case绿灯，压测通过。上线72小时后，用户反馈涌进来：Agent在某类投诉场景下会反复追问用户同一个问题，形成死循环。
回去查代码——没有bug。回去看测试——所有断言都在验证"输出是否包含关键词"。没有一条测试在验证"多轮对话里Agent会不会陷入逻辑死循环"。
这就是我们踩的坑：用测确定性软件的思路，去测一个非确定性系统。
测试范式的断层在哪
传统软件测试的底层假设是：相同输入，得到相同输出。这个假设在Agent身上完全不成立。
Agent有三个根本性的挑战：LLM输出有随机性，同样输入可能产生不同输出；外部工具状态随时变化；执行路径由Agent自主决定。三条加在一起，意味着你之前写的那套断言脚本，充其量只是在验证"这个输出里有没有某个字符串"，根本碰不到Agent真正的行为边界。
更残酷的是，就连行业通用的基准测试都开始出现信任危机。有团队用10行Python代码利用pytest钩子机制篡改测试结果，拿下了SWE-bench满分；研究发现28个模型提交存在作弊行为，8大主流基准集体沦陷（来源：AtomGit开源社区，2026年4月）。公开榜单被刷穿，内部评估又没建起来——很多团队其实处于"盲飞"状态。
我们重建评估体系的过程
痛定思痛，我们花了将近六周重建了一套面向Agent的评估体系。核心思路转变只有一句话：从验证输出，转向评估行为链。
具体做了三件事。
第一，把"任务成功"拆成三个层次：能完成任务、没搞坏其他流程、在边界情况下行为合理。这个框架参考了Descript的实践——他们围绕"不出错、严格遵循要求、做得好"三个维度构建评估，从手动评分演进到LLM评分器，并定期和人工校准（来源：Anthropic工程博客《Demystifying evals for AI agents》，2026年1月）。
第二，引入LLM-as-Judge，但加了一道人工校准门。我们发现LLM评分器有一个致命偏向：它倾向于给长输出打高分，跟实际质量相关性很弱。我们每两周抽100条，人工重新打一遍，跟LLM评分做diff，一旦偏差超过15%就重新对齐。
第三，建了一套"行为回归集"，专门记录历史上出现过的异常行为模式——死循环、无限追问、跨轮遗忘、工具调用错误累积——每次Prompt迭代后跑一遍。升级Claude Sonnet 4.6那次，全套回归跑完不到4小时。有评估体系的团队，换模型时几天内就能完成验证；没有的，要花数周手动测，这个差距在我们自己身上验证过了。
一个让我至今没想清楚的问题
传统评估只看最终任务结果，忽视了Agent在过程中的推理、工具调用和中间步骤。对于执行长序列动作的自主Agent，只看成功/失败会错过"为什么成功或失败"的关键信息（来源：arxiv Agent-as-a-Judge论文，2025）。
这引出了一个我们内部还在争论的问题：Agent测试的终极目标，是保证"行为可预测"，还是保证"结果可接受"？
如果是前者，测试成本会是传统软件的5到10倍，而且永远追不上模型迭代速度。如果是后者，你要解决的问题变成：谁来定义"可接受"，在哪个粒度上定义？
我现在的倾向是后者，但没办法说服团队里所有人。
讨论问题
- 你们团队现在对Agent系统的测试，是仍在用传统脚本+断言，还是已经建起了独立的评估体系？两者的维护成本差距有多大？
- LLM-as-Judge你们用吗？有没有发现它在哪类场景下完全不可信？
声明：图片AI辅助生成
