传统测试都通过了，怎么证明 Agent 真的变好了

做普通软件时，测试要回答的问题往往很清楚。

余额够不够，接口返回什么，一个函数收到固定输入以后应当得到什么结果。边界写进代码，预期写进断言。实现改了，只要单元测试、集成测试和端到端测试仍然通过，我们至少知道原来的行为没有被破坏。

这套方法依然重要。问题出现在 Agent 开始替用户连续做事以后。

让一个 Coding Agent 修复 Bug，它可能读完相关代码就动手，也可能继续搜索几个文件，改完以后再根据测试结果调整。有时它发现信息不足，停下来向用户确认。三条路径都可能完成任务，也都可能在中途走偏。

如果测试提前规定它必须调用哪些工具、必须修改哪几行代码、必须走完几个步骤，测试反而会把可行路径写死。最后测到的只是 Agent 有没有照着预设剧本行动。任务有没有做好，仍然没有答案。

Pass 和 Fail 开始不够用了

传统测试擅长判断确定的结果。接口返回 200，测试通过。接口返回 500，测试失败。

Agent 的结果常常需要比较。

同一个重构任务，一个版本改了十个文件，一个版本改了五个文件，还有一个版本只改了核心文件。三个版本都可能运行正常，原有测试也都可能通过。接下来还要看代码是否容易维护，改动范围是否合理，有没有引入新的风险。

传统测试可以继续检查语法、类型、接口和回归，却很难只靠断言完成这些比较。

执行过程也变长了。一个 Agent 可能先分析项目，再设计方案，随后修改代码、运行测试、处理失败，整个任务持续很多轮。同一个输入多跑几次，步骤和工具选择也可能不同。只检查某一次运行是否走过固定路径，很难说明它的整体能力。

代码没坏，能力也可能退了

假设一次 Prompt 修改之前，任务成功率是百分之七十，平均成本是零点一美元。修改以后，成功率升到百分之七十五，平均成本也涨到零点三美元。

单看成功率，它进步了五个百分点。把成本算进去，结论就没那么简单。任务价值高时，这笔成本也许可以接受。任务本身很轻，三倍成本可能直接抵消成功率的提升。

传统测试在两次修改前后都可能全部通过。它能说明代码仍然按照预期运行，却回答不了 Agent 有没有变强，更回答不了这次提升是否值得。

Agent 的改动经常落在 Prompt、模型、工具选择和执行规则上。代码没有报错，系统的行为仍然可能发生明显变化。没有一套稳定的评价办法，发布就容易退回到手工试几个案例，然后凭感觉决定。

Eval 把整个任务放进评价范围

这里说的 Eval，可以理解为一套固定任务、评分规则和重复运行的方法。它评价的对象从某段代码扩展到了整个任务。

以 Coding Agent 为例，可以给它一个项目和一项待修复的问题，让它完成修改。评估时再看任务有没有解决，代码质量如何，有没有造成回归，工具使用是否合理，消耗了多少 Token，花了多长时间。

这些维度不一定合成一个总分。成功率、成本和耗时放在一起，已经能让一次改动的得失清楚很多。

Eval 也不需要规定 Agent 只能走哪条路径。只要最后完成了任务，满足必要约束，并且没有引入新的问题，不同的搜索和修改顺序都可以被接受。

这正好适合 Agent。路径会变，结果仍然可以评价。一次运行会有偶然性，同一批任务反复执行以后，版本之间就有了可以比较的记录。

两套体系各自守一段

Unit Test、Integration Test 和 End-to-End Test 仍然要保留。函数逻辑、接口行为、权限判断、数据读写和工具执行，都需要明确的测试。

Eval 负责另一部分。它关心 Agent 有没有完成工作，完成质量是否稳定，成本是否可以接受，改动以后能力是上升还是下降。

拿 Eval 代替传统测试，会漏掉基础代码错误。只做传统测试，又看不见 Agent 的能力变化。

一个更完整的发布过程会多一道检查。代码先通过传统测试，Agent 再运行固定的 Eval Suite。结果达到预设门槛以后，版本才进入发布。

没有 Eval，优化很容易变成感觉

缺少 Eval 时，开发过程通常很熟悉。改一版 Prompt，挑几个案例试试，结果看起来不错，然后上线。

半年后再回头，很难说清哪个版本最好，哪次修改带来了提升，又是哪次修改让某类任务退化了。演示成功过几次，不能替代长期记录。

有了固定任务集，流程会朴素很多。每次改 Agent，都跑同一批任务，用同一套规则评分，再比较成功率、回归、成本和耗时。改动有没有价值，至少有了一份可以复查的依据。

这套方法也有自己的要求。任务集太小，评分规则反复变化，或者测试任务离真实使用太远，Eval 一样会给出误导性的结果。它需要持续维护，和单元测试一样，不能写完一次就放着不管。

Agent 团队发布一个版本时，需要同时回答两件事。代码有没有通过测试，系统有没有在固定任务里表现得更好。

代码通过，只能说明它还能运行。要不要发布，还得看它能不能在同一批真实任务里，稳定地把事做成。