按 GitHub star 数、或按"它内置多少个指标"来挑一个开源评测框架，你会采用一个为断言某一类东西而造的工具，然后花一个季度把它掰去断言另一类。DeepEval、Promptfoo、Ragas 与 Inspect 不是同一个产品的四次尝试——它们坐在四个不同的高度上，各自精通一种不同的正确性单位。在比较功能之前先定下你需要称之为"正确"的对象是什么，选择就会自己浮现；反过来搞，这个类别里最火的工具，对你的活儿仍然会是错的那一个。
一览
四个都是开源、且以 Python 为先（Promptfoo 从一个 Node CLI 加 YAML 运行），四个只要肯下够功夫，都能产出一个在 CI 里变红的数字。把它们分开的，是它们生来要打分的那个对象的形状。
| 框架 | 许可证 | 核心抽象 | 生来要断言 |
|---|---|---|---|
| DeepEval | Apache-2.0 | 测试用例上的 pytest 式指标 | 某个组件表现正确 |
| Ragas | Apache-2.0 | 无参考的 RAG 指标 | 检索与依据是好的 |
| Promptfoo | MIT | 一个声明式的配置矩阵 | 这套配置胜过那套 |
| Inspect | MIT | Task = 数据集 + solver + scorer | 一个智能体完成了任务 |
把这张矩阵当作意图的地图来读，而不是一张记分卡。这里每一个都在自己那一列的亮格上出色、在其余列上仅仅够用，而"在你手头这份活儿上仅仅够用"的那个工具，正是会花掉你一个季度的那个。
那些高度，以及它们为何不能互相替代
这些工具之所以不能干净地互相替代，是因为它们回答的是系统不同层次上的问题，而一个在错误层次上算出来的数字，并不表示你想要它表示的意思。一个组件指标说不了一个智能体有没有完成任务；一个任务分数说不了两个重排器里哪个更好。这四个落到三层楼上——输出、比较、轨迹——而每往上爬一步，算力就更贵。
DeepEval——对一个组件的断言
DeepEval 的前提是：一次 LLM 评测应当像一个单元测试。你写一个测试用例、挂上一个或多个指标，它就像 pytest 那样通过或失败——这恰恰是开发者在 CI 里想要的。它的差异化在于指标库的广度：除了 RAG 与对话指标，它还内置一等的智能体指标——任务完成、工具正确性、参数正确性、步骤效率、计划遵循——于是你能断言"关于某一具体步骤的某一具体主张"，而不只是"对整次运行的一种感觉"。
它适合哪里
当你需要护住的是一个组件的行为——"检索器仍然返回对的分块"、"智能体仍然用对的参数调退款工具"——并且你想把这份保护接进跑你其他测试的同一个 CI 里。它是 评测驱动开发里那套回归评测纪律的天然归宿。
它在哪里吃力
DeepEval 给你递过去的输出打分；它不是一个"在隔离环境里让一个用工具的智能体跑完一个任务"的测试台。你可以通过捕获智能体的轨迹、再把各片段喂进去来评它，但如果你的核心问题是"这个智能体能不能安全地、用真实工具、在二十步里完成这个任务"，那你就在重造 Inspect 给你的东西。
Ragas——一个守在自己车道里的专才
Ragas 只做一件事，也不假装别的：它用无参考的指标——忠实度、答案相关性、上下文精确率与上下文召回率——给检索增强生成打分，把一个 RAG 答案拆成它的检索器与生成器两半。因为这些指标不需要标准答案，你可以对着生产流量跑它们，而那正是 RAG 质量真正漂移的地方。
它适合哪里
当 RAG 就是那个系统、或就是你正在加固的那个子系统，而你想要有原理、被充分理解的分数，而不是一个通用的大杂烩。对 evaluating RAG 里描述的那份具体活儿，它是这一页上最锋利的器械——而且它乐于在一个更大的测试台里当那个 RAG 打分器，而不是充当整个测试台。
它在哪里吃力
一切不是检索的东西。Ragas 长出了一些对话方面的覆盖，但智能体轨迹、工具调用正确性、跨提供方对决与沙箱执行，在设计上就不在它的范围内。在 RAG 之外去够它，是拿手术刀去做木工。
Promptfoo——比较本身就是那个单位
Promptfoo 把抽象反了过来。它原生的对象不是"这是一个输出、给它打分"，而是一个矩阵：提示词 × 模型 × 提供方 × 测试用例，用 YAML 声明、渲染成一张并排的比较表。它的第二个强项是一套成熟的红队与安全扫描面——针对提示词注入与越狱的对抗性测试生成——这契合它"把整张网格都跑一遍、看什么会坏"的形状。
它适合哪里
提供方与模型选型、提示词 A/B 测试与对抗性扫描——任何答案是比较性的、你又想把它做成一张整个团队都读得懂的表的场景。当问题是"更便宜的模型撑不撑得住"或"哪个提示词变体赢"，Promptfoo 就是为这个而造的，而且它还兼任 prompt injection 加固里的那个安全对决。
它在哪里吃力
对单个组件做深入、定制、以代码定义的指标，以及在受控环境里跑长周期的智能体轨迹。矩阵模型对比较很强，而当你需要的是"对一个步骤的一次丰富断言"或"一次带真实工具与副作用的有状态智能体运行"时，它就别扭了。
Inspect——被测的是智能体本身
Inspect，来自英国 AI 安全研究所（UK AI Security Institute），是为重活那一端造的。它的单位是一个 Task = 一个样本数据集、一个产出答案的 solver、以及一个给它打分的 scorer——而那个 solver 可以是一个完整的、用工具的智能体，而不只是单次的一次 generate 调用。它内置沙箱化执行（内建 Docker）、一套统一接口罩住一长串提供方、一个庞大的内建评测库，以及一个专为读轨迹而造的日志查看器。它是前沿实验室在"要测的是智能体的整体行为（安全也算在内）"时会去够的那个框架。
它适合哪里
把一个智能体当作智能体来评：多步使用工具、在隔离中、被端到端地打分、跨提供方，且规模与严谨程度经得起公众与安全关键场景的审视。这是 轨迹与过程评估的家，也是 安全红队所要求的那种跨提供方、沙箱化的严谨。
它在哪里吃力
做到轻量。Inspect 的力量伴随着比"一个只想在 CI 里对一个输出要个红绿断言的开发者"所寻求的更多的概念与搭建。对一次快速的组件回归来说，它是超出这份活儿所需的机器——而这恰恰是为什么这些工具是彼此配合、而非彼此竞争。
真正的选择器——以及你为何会跑不止一个
别再问哪个框架最好，改问：在这个 pull request 上，你需要断言"正确"的对象是什么。正确性的单位几乎一对一地映射到工具上：
而这正是藏在第一点后面的第二点：一个严肃的系统会在好几个层次上断言正确性，所以成熟的答案通常是一套栈、而不是一个赢家。一种常见形态是：Promptfoo 或 DeepEval 在每次提交上跑快速的组件与比较检查、当作一道 CI 闸门，Ragas 对着生产流量给 RAG 子系统打分，而 Inspect 承担那些跑得不那么频繁、却决定一个新模型能否靠近用户的重量级智能体与安全评测。它们更多是互相读对方的 trace，而不是互相替代。把这个选择当作互斥来对待的团队，会在半年后悄悄把第二个工具拴到第一个上——而它花了钱才学到这一段免费兜售的教训。
什么时候选哪个
| 你的处境 | 从这个起步 | 因为 |
|---|---|---|
| CI 里的组件回归（智能体或 RAG） | DeepEval | pytest 式断言与一等的智能体指标 |
| 在生产流量上加固一条 RAG 管道 | Ragas | 无参考的检索与依据分数 |
| 选模型或提示词，或做红队 | Promptfoo | 一个比较矩阵与对抗性扫描 |
| 端到端地给一个用工具的智能体打分 | Inspect | 沙箱化任务测试台、与提供方无关、可规模化 |
| 以上全部（多数真实系统） | 一套栈 | 各自断言一个不同的正确性单位 |
FAQ
这几个里，专门评智能体哪个最好？
看你指的是哪个智能体问题。要断言某一具体步骤——智能体用对的参数调了对的工具——DeepEval 的智能体指标是那个契合。要给一个在沙箱里用工具的智能体的整条轨迹打分，Inspect 正是为此而造。"智能体评测"是两份不同的活，它们落在两个不同的工具上。
我能不能只用一个框架搞定一切？
能，而且你会在边缘处感觉到。每个工具都原生属于一个正确性单位、在其余单位上仅仅够用；逼一个去干全部四件，就意味着在其中三件上跟它的抽象较劲。多数成熟的栈会在 CI 里跑一个轻量工具，再用一个更重的测试台去跑智能体与安全评测。
既然 DeepEval 也做 RAG 指标，Ragas 是不是过时了？
没有。DeepEval 把 RAG 作为一个宽广库的一部分来覆盖；Ragas 是一个 RAG 专才，拥有被充分理解、无参考、可对着生产流量跑的指标。如果 RAG 就是你的系统，专才往往是更锋利、也更站得住脚的器械；如果 RAG 只是众多组件之一，DeepEval 的广度也许更要紧。
如果我 CI 里已经有 DeepEval，Promptfoo 放哪儿？
Promptfoo 回答 DeepEval 别扭的那些比较性问题——哪个模型、哪个提示词、以及一个对手能打破什么——做成一张整个团队都读的矩阵。很多团队用 DeepEval 跑组件回归、用 Promptfoo 做模型与提示词选型外加红队，二者并不冲突。
我不是安全实验室，需要 Inspect 吗？
只有当你的正确性单位是一整条智能体轨迹时才需要。如果你构建真正用工具的智能体、并需要评它们能否在隔离中跨多步完成任务，那么不管你的职称里有没有"安全"二字，Inspect 的测试台都值它的分量。如果你只给输出打分，它就是超出你所需的机器。
延伸阅读
本站相关：
- 大白话讲评测——四个工具底下共用的词汇。
- 轨迹与过程评估——给"智能体是怎么走到那里的"打分，而不只是答案。
- 评估 RAG——Ragas 为之而造的那份活。
- 评测驱动开发与 CI——轻量工具住的地方。
- 面向智能体的 LLM 裁判——这些工具大多倚赖的那个打分器，及其失败模式。