EVA：从测试 Harness 到工程验证架构

之前我为团队搭建了一个基于 pytest 的 LLM 性能测试框架（内部代号 ClawPerf），完工后在考虑给它起正式名字。第一轮候选都是“LLM Performance Benchmark”式的名字——直白、贴切，但总觉得哪里不对。直到把整个体系的层次摊开审视，我才意识到问题所在：这套东西的分层、闭环与复用逻辑，和“LLM”“性能”“Benchmark”没有任何绑定关系。把一个通用体系装进领域化的名字，就像给通用机床贴上“螺丝刀”的标签，将来扩展到其他领域时必然“自我打脸”。

于是有了本文的标题——EVA（Engineering Validation Architecture，工程验证架构）。它的定位不是“一个更强的测试 Harness”，而是一套把工程问题转化为可定义、可复现、可执行、可测量、可分析、可验证实验的通用工程体系。

为什么不是“更强的测试 Harness”

Harness 这个词本身没错，但它描述的是体系里的一个组件，而不是体系本身。测试 Harness 的职责是部署环境、执行用例、采集数据，回答的是“怎么跑”；而真正困扰我的问题从来不在“怎么跑”，而在“为什么跑”“跑到什么程度算通过”“跑完能证明什么”。

这个定位经历了一路演进：最初叫 EES（Engineering Evaluation System，工程评测体系），又在 EVP（Engineering Validation Platform，工程验证平台）与 EEP（Engineering Experiment Platform，工程实验平台）之间权衡——评测强调系统化，平台强调工程味道，实验平台强调可重复性——最终收敛为 EVA：

从“测试 Harness”到“工程验证体系”：定位不断放宽，最终收敛为五层架构的 EVA

名字会反过来塑造系统。如果叫“测试框架”，团队会用用例数量和覆盖率来评判它；如果叫“验证架构”，评判标准就变成“能否用标准化、可重复的实验证明一个工程假设”。命名不是包装，而是一次架构决策。

EVA 五层架构

EVA 把整个验证体系分成五层。第一层是问题定义层，由三部分组成：Objective（目标定义，为什么验证）、Specification（标准定义，什么是通过）、Environment（环境定义，在哪里验证）。三者把模糊的工程问题翻译成一份可执行的问题陈述。其后依次是 Execution（执行引擎）、Measurement（测量体系）、Analysis（分析体系）、Validation（验证结论）：执行引擎把实验真正跑起来，测量体系采集数据，分析体系解释数据，验证层给出结论。

五层架构：问题定义、执行、测量、分析、验证；Harness 只是执行层里的一个组件

这个架构里最容易被误解的是 Harness 的位置：它只是 Execution 层里的一个组件，负责自动化部署、运行用例、采集原始数据；执行引擎还包括任务调度、资源分配、失败重试和环境回收这些与具体被测对象无关的机制。同理，测量、分析、验证每一层都与“测什么”解耦。这意味着扩展到新领域时，只需要重写第一层，后面的机制可以原样复用。

七步闭环：让验证成为循环

五层架构是 EVA 的骨架，七步闭环则是血液循环。一次完整的验证经历七步：Goal（为什么验证）→ Standard（验证什么）→ Environment（在哪验证）→ Harness（怎么验证）→ Measurement（得到什么）→ Analysis（说明什么）→ Validation（是否成立），然后回到新的 Goal。

七步闭环：每一步回答一个明确的问题，验证结论又催生新的目标

闭环的关键在于验证不是终点。一次实验的结论总是引出新问题：性能回退了，为什么？结论换到新环境还成立吗？于是产生新目标，进入下一轮循环。工程验证由此成为持续进化的过程，而不是一次性交付。

实践：vLLM TTFT 回归的一次验证

用一个真实场景展示闭环如何运转。生产环境反馈 vLLM 新版本首 token 延迟（TTFT）明显变差，这构成一个需要验证的工程假设——“新版本引入了性能回归”。

• Goal：确认升级后 TTFT 是否恶化，并定位原因；
• Standard：TTFT 相对旧版本恶化超过阈值，即判定回归；
• Environment：固定模型、硬件和工作负载，只改变 runtime 版本；
• Harness：自动部署新旧版本、执行请求、采集指标；
• Measurement：TTFT、TPOT、GPU 利用率等指标；
• Analysis：对照版本 A 与版本 B 的指标分布，锁定改动点——比如怀疑是 Attention kernel 的变化；
• Validation：结论是假设成立还是不成立，并决定后续行动。

vLLM TTFT 回归排查：控制一切变量、只改 runtime 版本，才能干净地验证假设

这个例子能成立的前提是控制变量：除目标变量外，一切条件保持一致。而这正是基于 pytest 的框架的用武之地——把环境准备、指标采集、报告生成沉淀为可复用的 pytest fixture 和工具（ClawPerf 就是这么做的），每次验证只是在写新用例。同样的流程稍加调整，就能覆盖 72 小时稳定性压测、量化后的精度回退、新 runtime 兼容性验证等场景：七步不变，变的只是第一层的内容。

领域扩展：验证是一条横跨工程的线

正因第一层与其余四层解耦，EVA 的适用领域几乎是开放的：LLM 评测、性能测试、功能测试、兼容性测试、精度评测、可靠性测试、存储基准、网络基准、数据库测试、编译器测试……它们共享同一套执行、测量、分析与验证机制，差异只在目标、标准与环境的语义。

回到开头的命名问题：如果叫“LLM Performance Benchmark”，每次扩展到存储、网络或编译器，都需要向团队解释“为什么这个 Benchmark 框架还能测这些”。而 EVA 从第一天起就声明了自己的本质——验证是横跨所有工程领域的第一性活动。

总结

从测试 Harness 到工程验证架构，是一次视角升级：测试关心“跑没跑通”，验证关心“结论成不成立”。EVA 用五层架构定义体系结构，用七步闭环定义运转方式，用领域无关的设计保证扩展性。pytest 只是实现细节，EVA 提供的是一套方法论：把工程问题变成可定义、可复现、可执行、可测量、可分析、可验证的实验。下次再给系统命名，值得多问一句：我搭的到底是一个测试框架，还是一套验证架构？