前阵子聊到一个团队，他们两年前选了 deepeval 做整套评测，红队、RAG、agent 全往里塞。到今年脚本堆了三百多个文件，CI 里跑一轮要四十分钟，指标报告每周产一次，没人真看。老大说想换，一盘点发现撤不动：所有历史分数都绑在 deepeval 的口径上，换框架意味着旧基线全废。
由此可见框架选型别挑功能最多的，要挑和你的被测对象最贴的，选错方向后面全在还债。
一、评测框架要解决的是工程化，不是算法
说白了，框架把「我自己写个 py 跑准确率」变成「声明式定义指标、批量跑、出报告、能进流水线」。没有框架，评测是一次性的脚本；有了框架，评测才变成可复用、可对比、可回归的资产。
但框架不是越全能越好。同样一套指标，有人用 ragas 二十行 YAML 跑完，有人用 deepeval 写两百行还跑不顺。选型错配，后面每个迭代都在为这个决定补坑。
二、四类能力，没有全能选手
四款主流工具从五个维度对比如下
重点关注：被测对象侧重决定你用不用得上，CI 友好度决定你能不能天天跑，维护状态决定你三年后是自己养这套东西，还是等着上游更新。
deepeval 的指标仓库最全，LLM 裁判生态也最成熟，但它的重是实打实的，CI 里一轮四十分钟，逼得团队后期只敢周末跑。它适合「深」，不适合「频」。
ragas 走的是另一条路，RAG 场景开箱即用，上下文精确率、上下文召回率、噪声敏感度几条线直接给分，非 RAG 任务它基本帮不上，所以它只在 RAG 链路这一侧有用。它真正的分量在那套指标口径，那是目前最清楚的一份 RAG 定义，省下多少行代码是次要的。这笔账要加一个变量：版本停在 2026 年 1 月的 0.4.3，主分支最后一次提交是 2026 年 2 月，创始团队已经转去做 agent 仿真环境，多模态链路上还有一个未修补的已知漏洞。所以用法跟着变：抄口径、锁版本、当成自己团队的资产，别再指望上游替你适配新模型的 prompt。
promptfoo 是 YAML 声明用例加红队扫描加 CI 原生，对抗注入、越狱、敏感词开箱就有，深度语义指标得自己接。它和 ragas 是互补关系，各自管一段。这里也要提一句归属变化：它在 2026 年 3 月并入 OpenAI，开源和 MIT 许可都保留，OpenAI 自家云端 Evals 同期宣布年底关停、官方把用户导到 promptfoo。押注它换来的是长期维护，代价是选型时要接受一家厂商的倾向性。
inspect 在 agent 评测和科研复现上最干净，实验可重复性高，但工程文档薄，CI 接入要自己造轮子，适合要发论文或做严谨对照实验的团队。
对照着看更清楚：deepeval 重而全，inspect 轻而专，这是一组反差；ragas 盯 RAG，promptfoo 盯红队，这是另一组反差。没有谁覆盖全部，组合才是常态。
常见错误是一上来就冲阶段四想自研平台，结果连单框架都没跑顺，插件化更是空中楼阁。阶段二把主力框架跑通，就能拦掉大部分「换框架返工」的冤枉工时。
三、落地实践：分步落地，兼容现有体系
按被测对象定主力：RAG 链路可用 ragas 起手，锁住版本、不长期押注；红队和通用对抗用 promptfoo；深度裁判补 deepeval；科研复现留 inspect。框架之间用统一的评测集和指标定义衔接，别让每家各说各话。
与既有四件套（评测集、评分卡、裁判、难负）亦可衔接。框架替代的是「手写跑批脚本」那一层，评测集还是你的三元组，评分卡是你的维度表，裁判只是从「自己写规则」变成「调框架的 LLM 裁判」，难负照常造。
前面地基能归成三件事：测什么，检索、生成、工具调用、模态各有各的失效形态；拿什么测，集子怎么造、六类来源怎么配、难负怎么补；谁打分，评分卡怎么从总分拆成扣分项、裁判怎么校准才不偏心。三件事定下来，分数才算可信。
可信之后还悬着一个问题没人答：谁来跑、多久跑一次、跑完谁来拦。这一步交给人硬扛的结果，就是开头那个团队的处境，脚本越积越多，报告报出去没人看。界线要留清，框架不会替你把口径想清楚，前面没定清的东西进了框架，只是把模糊放大成每周一次的模糊，最后还是回到开头那支团队。
四、全景附录：4 款之外的评测工具谱系
本文选这 4 款，切的是形态：pytest 式代码库、RAG 指标库、YAML 命令行、实验沙盒。全网叫得出名的评测工具早已破 60，其中活跃、能直接落地的应用层框架在 20 个上下。多出来的那些大半不在同一层，硬塞进一张横向对比表比不给表更误导人，所以单独列在附录。先按层看：
| | | |
|---|
| | deepeval、promptfoo、Opik、TruLens、Giskard、Evidently、pydantic-evals、evalite、MLflow Evaluate、ragas | |
| | lm-evaluation-harness、HELM、OpenCompass、lighteval、simple-evals、Inspect | |
| | LangSmith、Langfuse、Arize Phoenix、Braintrust、W&B Weave、Helicone、Galileo | |
| | garak、PyRIT、DeepTeam、promptfoo redteam | |
| | AgentBench、tau-bench、GAIA、SWE-bench、WebArena、Terminal-Bench | |
4 款全落在第一层，它们回答的是系统测得对不对，线上真实流量里出了什么问题管不到。后者属于第三层，是看板的活儿，两层混着谈最容易白买一套平台。另有第二类要提醒：Inspect 在不同榜单里被归到 harness 层，本文按应用层叙述，是因为它的实验沙盒形态更适合当评测底座用。
功能对比之外还有一项更该看，就是维护状态。它比 star 数和功能清单更能决定你三年后是否被迫重写：
| | |
|---|
| v4.3.1 发布在 2026 年 10 月，月下载 258 万，背后有商业版 Confident AI | 免费层每周 5 次跑批，商业版按组织收费，团队规模大要先算账 |
| 停在 0.4.3，主分支最后提交 2026 年 2 月，原团队转做 agent 仿真 | |
| 2026 年 3 月并入 OpenAI，MIT 保留，OpenAI 云端 Evals 年底关停并导流至此 | |
| 活跃，英国 AI 安全研究院主线项目，科研与红队用得多 | |
| v3.0.0 于 2026 年 8 月全量重写，需 Python 3.12，RAGET 改名 quality_scan | |
| | |
4 款横评解决的是「我该用哪个」，全景解决的是「我有没有漏掉一层」。选型最常见的失误只顾挑框架，忘了线上流量没人标答案，结果手里只有一套离线集。
本文建议：框架迭代快，本文口径截至 2026 年；具体 API 以各框架最新文档为准，未做逐一验证。维护状态与商业条款变动更频繁，建议按季度复看一次，尤其是自建门禁依赖的那几款。一句话收尾
你那套评测，现在是声明式能进流水线的资产，还是散在各人电脑里的一次性脚本？
