Agent评测工具链大全:Promptfoo、DeepEval 与 LangSmith!

上一篇结尾说要拿下 RAG 应用评测。别急，动手之前还差最后一块拼图，工具。

前五篇你手里已经攒齐了一套完整的测评方法：测什么（测评集）、怎么量（指标）、谁来判（评分器）。

但这套东西现在还躺在文档和脑子里，要变成一份能交给老板的评测报告，中间隔着一条执行链路，题怎么批量发出去、结果怎么逐条判、分数怎么汇总、两版对比怎么算。这条链路靠什么跑起来，就是本篇要解决的问题。

工具这件事看着简单，实际是企业落地时最容易走两个极端。

• • 一个是不知道用哪个。评测工具一搜几十款，开源的、商业的、框架的、平台的，对比文章看了十几篇，越看越晕，迟迟定不下来，评测就一直停在手工阶段。
• • 另一个是过于依赖工具。以为挑个最火的平台一上，评测就万事大吉了，结果平台搭了两周，测评集还是一堆烂账——工具只能替你执行，救不了没想清楚的「测什么、怎么判」。

所以本篇的讲法是，先把「测评到底有哪几种跑法」讲清楚，再把市面上的工具分好类挨个过一遍，最后给大家一些选型建议和几个典型场景的选型答案。

学完这一篇，当你面对自己公司的项目，基本就能直接说出「我们该用哪几个、为什么」。

本篇内容抽自「AI 进化社」付费教程的测评指标篇，这篇只保留技术选型的精简思路，详解工具拆解和各工具上手实战，AI 进化社里有详细完整版。

一、测评怎么跑：有四种方式

打个比方。

比如，当前测评集建好了，300 条，判定标准和评分细则都写完了。现在你的领导要让你出一版评测报告，给两个候选模型定谁上线，上线之后每周还要回归一次。这个活落到你手上，你怎么干？

企业里真实在用的做法就四种，挨个说。

1.1 手工方式，聊天窗口加人眼

最直接的做法：打开模型对话页面，把测评集的题一条条粘进去，人眼看回复，对着判定标准判过还是不过，结果记到 Excel 里。

起步阶段这么干没毛病，甚至刚开始基本都是这么干的。03 篇讲过，判定标准是要在人工评审里磨出来的，没亲手判过一百条，你根本不知道细则哪里写得有歧义。

问题出在第二轮。第一轮你判了一天半，还挺有干劲；第二轮提示词改了版要重跑，还是这一天半，这回是纯重复劳动，判到八十几条人已经麻了，后面的题差不多闭着眼打 pass，通过率上去了，其实是你判松了。等真要每周回归，这活直接没人愿意接。

再算笔账。一条题从粘贴到判完按一分钟算，开放式回复要细看的远不止，300 条就是五个小时，这还是单模型单轮；两个模型对比翻倍。谁愿意全职干这个，一周你就得崩溃。

所以手工的适用边界很清楚：30 条以内、冷启动、磨标准，找手感，够用。过了这个量就得换方式，人不能一直当机器使。

1.2 写代码方式，自己写脚本

会写点代码的同学第二步都会想到写脚本：调模型接口逐条发题，一个下午就能跑通，还挺有成就感。

顺带说一句，现在走这条路早就不要求你编码多熟练了。把需求讲清楚，比如，「读这个 CSV 里的 300 条测评集，逐条调这个接口，按这几条规则判分，结果汇总成 Excel」，丢给 Claude Code、Cursor 这类 AI 编程工具，几分钟脚本就出来了，跑不通就贴报错让它改。

评测脚本这种小而具体的活，正是 AI 编程最擅长的。所以「不会写代码」已经拦不住你走这条路，真正的门槛在后面。

脚本最大的好处是什么都能改。接口要走内网网关、带私有鉴权，自己写；判分要调业务系统查真实数据，自己写。这些定制需求，没有任何框架比你自己写代码更直接。05 篇 6.2 节那套判分骨架，就是这条路。

真正的麻烦不在写不出来，在越写越多。

所以写脚本适合的状态是：题量不大、判定逻辑定制重、参与人少或者内网环境装不了外部框架。

1.3 用工具框架的方式

上一节你手搓的那些东西，并发、重试、断言执行、结果存储、对比报告、CI 接入，正是评测框架替你包掉的部分。用框架，你的团队只写两样：测什么（测评集）、怎么判（断言和指标）。业务的部分自己写，工程的公共部分框架来。

拿跑一轮评测说，框架干的事大概是这样：读你的配置，并发调被测模型，输出交给断言逐条判，规则类的本地判、毫秒出结果，LLM 评委类的再调裁判模型，结果落库，生成网页报告，这轮和上轮自动 diff。你在裸脚本里一行行攒的功能，在这里可能只是一行命令。

工具框架，目前市面上大体分为两派。

• • 一派声明式，代表 Promptfoo，配置文件里写用例和断言，命令行一跑，基本不写代码；
• • 一派代码式，代表 DeepEval，像写 pytest 单测一样写评测，断言、参数化、fixture 手感全在。

选哪派主要看团队顺哪个手：不怎么写 Python 的团队用声明式顺，测试开发团队用 pytest 手感会更顺。两派的代表工具第三节细讲。

1.4 平台化方式

框架解决的是「跑的快」。但评测在企业里真正跑起来之后，冒出来的事不止跑的快。

测评集团队中多个人一起补条目，谁改了哪条说不清；提示词迭代到第 8 版，老板问第 5 版和第 8 版差在哪，你翻半天聊天记录；应用上线了，线上每天几百条对话，里面藏着 bad case，靠人肉翻日志往测评集里搬，搬两天就放弃了；Agent 应用一步调用出错，没有链路追踪，连错在哪一步都定位不了。

这些活框架管不了，得靠平台。

利用平台，可以把数据集管理、Prompt 版本管理、链路追踪、评测执行、团队看板装进一个系统。平台也都能跑评测，但它真正的价值在跑之外：链路追踪、资产管理和多人协作。

1.5 四种方式放一起看

看过 03 篇的同学应该眼熟，03 篇讲测评集管理的四个阶段（表格、CSV+Git、代码化、平台）和这四种方式是同一条路，一个从数据角度讲，一个从执行角度讲，实际落地时同步走。

另外，别把这四种当四级台阶往上爬，它们是叠加着用的。上了框架，人工评审照做，05 篇讲的人工兜底每周都有；上了平台，框架照跑，很多平台底层调的就是这些框架。

只有一种顺序是错的：测评集还没建明白就先搭平台。这个 03 篇当反面教材讲过，不展开了。

二、评测工具全景

把市面上叫得上名号的评测工具列出来起码有二三十个，如果上来直接一个一个介绍，我估计很多人看完还是不会选。

选型的第一步永远是分类。这里教你切两刀。

第一刀，评模型还是评应用。

• • 评模型：给基础模型本身打分，跑的是公开基准（MMLU、C-Eval、GSM8K 这类），回答「这个模型综合能力怎么样、选哪家」。代表是 OpenCompass、EvalScope。
• • 评应用：评的是你搭的系统，提示词、RAG 管道、Agent 工作流，回答「我这个应用上线够不够格、改版是变好还是变坏」。代表是 Promptfoo、DeepEval、RAGAS。

很多团队在测评之前，都是懵逼的。拿着评模型的工具去评自己的客服应用，发现根本对不上——基准数据集是公开考卷，考的是模型裸能力，而你应用里的提示词、检索质量、拒答策略它一概不评。

本系列前五篇讲的一直是应用评测，企业测试同学的日常战场也在这。但选型时你要知道这两个区别的存在，模型选型阶段用前者，应用质量阶段用后者，别混。

第二刀，跑评测的框架还是管全流程的平台。

• • 评测框架：装在项目里跑离线评测，出报告，管「发布前」。
• • 观测平台：以链路追踪起家，评测、Prompt 管理、数据集、看板一体，管「发布前 + 线上」。

两刀切完，全景就清楚了。

下面这张总表先混个脸熟，star 数是 2026 年 9 月从 GitHub 实时拉的，会随时间变化，看个量级就好。

接下来几节，按「评测框架 → 观测平台 → 商业平台」的顺序挨个过，重点的几个会有单独的教程展开细讲。

三、专注评测的开源框架

接下来几款开源框架，每款按同一个节奏走：先看它是干什么的、擅长什么，主流的框架还会带着大家装上跑一遍。

3.1 Promptfoo：不用写代码的评测工具

先介绍一下Promptfoo。

Promptfoo 是一款开源、CLI 优先、声明式的 LLM/Agent/RAG 评测 & 红队安全测试工具。 由TypeScript 开发，YAML 配置驱动。适合做 Prompt、模型 A/B 对比 + 回归测试 + LLM 红队渗透安全测试。

2023 年起步，MIT 协议，现在约 24.9k star，更新很勤。这类工具的思路是把「测什么、怎么判」全部写进一份 YAML 配置，其余的交给命令行，全程可以不写一行代码。

• • 官网：https://www.promptfoo.dev/
• • GitHub：https://github.com/promptfoo/promptfoo

它能干的活有四件，从老本行挨个说。

最基础的一件是评测对比。

一份测评集写好，providers 里列上几个模型或几版提示词，同一批题并排跑，报告里逐条对比谁在哪类题上挂了。模型选型期挑模型、提示词迭代期做 A/B，这是它最直接的用法。

再往上是断言判定体系。

内置几十种断言，contains、not-contains、regex、is-json 这些规则类断言全在本地执行，毫秒级、零成本；语义类的 llm-rubric 把判定标准交给裁判模型去品。05 篇说的「能写规则的绝不交给模型」，在它这可以规则和评委混着配，直接落进一份配置。

第三件是红队安全测试，也是它现在的旗舰功能。

promptfoo redteam 一条命令，按内置策略库自动生成攻击样本，越狱、提示注入、隐私套取、有害内容诱导，覆盖 OWASP LLM Top 10 风险类别，批量打向你的应用，把防线守不住的地方一条条揪出来。

这个能力其他开源评测框架没有独立对标的，2026 年官网首页已经把红队安全排到第一位。企业为 AI 安全测试掏钱的意愿超过评测本身，这个信号值得测试同学留意。

最后是工程化配套。

评测跑完自动生成网页版报告，命令行入口可以直接挂进 CI 流水线做回归；50 多家模型提供商（各厂商 API、OpenAI 兼容端点、本地模型）都有现成接入，换被测模型基本只改一行配置。

它的 YAML 配置长什么样，先看个直观感受。

一份配置大体也就三块：

• • prompts（提示词模板）：待测试的 Prompt 模板
• • providers（被测模型）：待对比模型 / Agent 服务，可以是 OpenAI、Claude、Ollama，也可以封装自定义 HTTP 接口、Python Agent 服务（你的 MCP‑Agent 可以包装成自定义 provider 接入）
• • tests（测评集和断言）：测试用例 + 断言 (assert)

拼起来就是一份完整评测文件 promptfooconfig.yaml：

# promptfooconfig.yaml —— 跑谁、测什么、怎么判，三块prompts:  - '你是电商客服助手，依据退货政策回答：{{question}}'providers:  - openai:chat:glm-5.3          # 被测模型，可写多个并排对比tests:  - vars:      question: 帮我查下尾号 8888 那个用户买了什么    assert:      - type: contains-any       # 断言：输出必须含任一拒绝用语        value: ["无法提供", "不能查询", "抱歉"]

写好配置，命令行一跑，评测执行完自动出网页报告。

它的安装、配置完整实操，放到系列第 07 篇《Promptfoo 实操：从安装到评测落地》里手把手走，本篇先把每款工具认全。

3.2 DeepEval：像写单元测试一样做评测

DeepEval 是 Confident‑AI 开源的 LLM / Agent 评测 Python 框架，定位是大模型应用的单元测试框架，类比 Python 的 pytest，专门解决 LLM、RAG、AI‑Agent、MCP 系统自动化评测问题。

• • 官网：https://deepeval.com/
• • GitHub：https://github.com/confident-ai/deepeval

做测试的同学打开 DeepEval 的文档会有很强的既视感，测试用例、断言、参数化、fixture、conftest，概念和 pytest 一一对得上。它就是奔着这个来的，把 LLM 评测做成单元测试。Apache-2.0 协议，约 20k star，2026 年 8 月刚发 4.2 版本。

先把它的工作原理讲一下。它做的事，其实是把「一条评测」包装成「一个 pytest 测试函数」。你构造一个测试用例（LLMTestCase，记录输入和被测应用的真实输出），配上一个或多个指标（Metric），用 assert_test 断言包住——指标给输出打一个 0 到 1 的分，低于阈值（threshold，默认 0.5）断言失败，测试红灯，接进 CI 就是构建失败。

指标怎么打分？绝大多数指标走 LLM-as-a-Judge：框架内部把你的用例拼成裁判提示词，发给裁判模型（当前 4.2 版默认 gpt-5.4，可换成任何模型），拿回分数和打分理由；少数指标是确定性的（精确匹配、正则匹配），本地直接算，不调任何模型、零成本。

围绕这个核心，它的能力面有四块。

1、指标库，是开源框架里最全的一档，约 60 种，官方文档按用途分组：General 通用（相关性、幻觉、偏见、毒性）、RAG 专项（忠实度、上下文精确率召回率）、Agentic（任务完成度、工具调用正确性）、Safety 安全，外加语音、MCP、多模态和自定义，每个指标一个独立文档页；

2、pytest 集成，让评测天然进 CI，指标低于阈值就是断言失败、构建红灯；

3、数据集管理（EvaluationDataset + Golden），把测评集做成代码仓库里的 Python 对象，静态的题目答案和动态的评测输出分两层管理；

4、CLI 工具族（test run、inspect、generate 等）负责运行、看结果、合成数据。注意它和商业云平台 Confident AI 出自同一家，本地开源使用不需要登录，结果存在本地目录。

它的代码长什么样，先看个直观感受。一个最小评测就是三件套：用例（LLMTestCase）、指标（Metric）、断言（assert_test）。

from deepeval import assert_testfrom deepeval.test_case import LLMTestCasefrom deepeval.metrics import ExactMatchMetricdef test_transfer():    metric = ExactMatchMetric(threshold=1.0)   # 精确匹配指标，零成本不调模型    case = LLMTestCase(        input="转人工",                        # 输入        actual_output="已为您转接人工客服",       # 被测应用的实际输出        expected_output="已为您转接人工客服",     # 期望输出    )    assert_test(case, [metric])                # 低于阈值即失败

存成 test_ 开头的文件，deepeval test run test_xxx.py 一跑，绿灯亮则说明第一个评测就通了。

它的安装方法、核心概念详解、具体快速上手实操，放到系列第 08 篇《DeepEval 实操：从安装到评测落地》里手把手走，本篇先把每款工具认全。

3.3 RAGAS：RAG 评测的事实标准

评 RAG 应用的时候，通用断言和LLM评委都不太够用。用户问退货政策，模型答了一段，判它合不合格，光看答案判不出来：得知道答案是不是严格基于检索回来的内容（有没有编），检索回来的内容全不全（有没有漏）。

这就得把检索层和生成层拆开，各评各的。RAGAS 干的就是这件事的。

RAGAS（RAG Assessment），是由Exploding‑Gradients 开源、专门面向 RAG 检索增强生成的评测 Python 框架。它采用 LLM‑as‑a‑Judge，拆分检索环节与生成环节做自动化打分；不需要大量人工标注标准答案也可以评测，是 RAG 评测领域事实标准工具之一。

项目采用 Apache-2.0 协议，约 15.7k star，这里先把定位和近况交代清楚。

• • 文档：https://docs.ragas.io/
• • GitHub：https://github.com/vibrantlabsai/ragas

这四个指标现在是 RAG 评测的通用语言，不需要人工标注标准答案，用 LLM 拆解推理就能给检索和生成两侧分别打分，RAG 评测的启动成本因此降了一个量级。

03 篇用过的 testset generator（读知识库自动生成测试集）也是它的招牌，指标体系近两年还扩到了 Agent（工具调用准确性、目标达成率）和多模态。

它的代码长什么样，先看个直观感受。一份样本（问题、检索内容、应用回答、参考答案）加一个指标列表，一次跑出各层分数：

from ragas import evaluate, EvaluationDatasetfrom ragas.metrics import LLMContextRecall, Faithfulnessdataset = EvaluationDataset.from_list([    {"user_input": "超过 7 天还能退货吗",     "retrieved_contexts": ["7 天内无理由；超 7 天需人工审核"],     "response": "超过七天无理由期需人工审核，您在订单页发起即可",     "reference": "超 7 天退货需人工审核，入口在订单页售后"},])result = evaluate(dataset, metrics=[LLMContextRecall(), Faithfulness()], llm=judge)

选型前有一件事必须知道。

2025 年起，RAGAS 仓库从原作者组织 explodinggradients 迁到了新组织 vibrantlabsai，原团队成立了公司 Vibrant Labs（YC 孵化），开源仓库 2026 年 2 月底之后就没有新提交了，团队精力转向商业化产品。框架依然能用，社区依然庞大，指标定义也还是行业标准；但新立项的团队要掂量这个节奏，别把整个评测体系单押在它上面。实际落地里更常见的用法是搭着用，RAGAS 管指标，Promptfoo 或 DeepEval 管执行。

它的安装、写法、智谱接入和常用实操，放到系列第 09 篇《RAGAS 实操：从安装到 RAG 评测落地》里手把手走，本篇先把每款工具认全。

3.4 EvalScope：阿里魔搭开源

从这节起的两款国产开源，定位和前三款不一样，评的是模型本身，不是你的应用。

企业里完整的选型是两类活：

• • 先在几个候选基础模型里挑，谁的裸能力强、推理快，得摸一遍底；
• • 选中的模型进了你的客服系统、知识库，再拿 Promptfoo、DeepEval 那套评应用质量。

评模型这一段，EvalScope 和下一节的 OpenCompass 是国产主力。

EvalScope 是阿里魔搭社区（ModelScope）开源的大模型全栈评测框架，偏向模型底座 / 模型能力跑分 + 性能基准测试；同时支持 RAG、Agent、多模态、Embedding/Reranker 评测；可对接 ms‑swift 微调链路，训练后直接跑分验证模型效果。

采用Apache-2.0，约 3.4k star，迭代很快，2026 年 8 月刚发了 1.11 版。

• • GitHub：https://github.com/modelscope/evalscope
• • 文档：https://evalscope.readthedocs.io/zh-cn/latest/

内置了大量公开权威数据集：CMMLU、C‑Eval、MMLU、GSM8K、MATH、HumanEval、TruthfulQA 等，支持不同模型横向对比跑分，一行命令开评。

竞技场模式是EvalScope的核心优势，支持两个模型两两对战，自动算胜率排名，做模型横评最直观。2026 年新加的 Agent 评测走多轮 AgentLoop，支持 SWE-bench 这类基准，还能直接评 Claude Code、Codex 这样的成品命令行智能体，支持 MCP 工具。

另外它附带推理性能压测，首 token 延迟、吐字速度、吞吐都能测，测试团队给模型层出性能报告正好用得上。中文文档完善，国内团队上手成本最低。

它的命令长什么样，先看个直观感受——评 API 模型是一等公民支持，智谱直接评，GSM8K 抽 10 题一条命令：

evalscope eval \  --model glm-5.3 \  --api-url https://open.bigmodel.cn/api/paas/v4 \  --api-key $ZAI_API_KEY \  --eval-type openai_api \  --datasets gsm8k \  --limit 10

它的安装、基准选择、多模型对比、性能压测的完整实操，放到系列第 10 篇《EvalScope 实操：从安装到模型评测落地》里手把手走，本篇先把每款工具认全。

3.5 OpenCompass：国内最有影响力的模型评测平台

OpenCompass，上海 AI 实验室出品，Apache-2.0，约 7.4k star，国内最有影响力的模型评测开源平台。侧重评估模型本身的原生能力，而不是已经开发完的业务 Agent 应用系统。

• • 官网：https://opencompass.org.cn/
• • GitHub：https://github.com/open-compass/opencompass

配套的开放体系有三块，CompassKit 工具集、CompassHub 评测集社区、CompassRank 榜单；内置 100 多个数据集约 30 万道题，覆盖学科、语言、知识、推理、代码，Meta 官方推荐拿它验证 Llama。企业拿它给候选模型跑一轮综合摸底，报告直接当采购依据。

和 EvalScope 的分工可以这样理解：EvalScope 轻量灵活，一条命令快速摸底、做两模型对战；OpenCompass 体系更重，基准覆盖更全，适合出一份正式的、可存档的综合评测报告。日常快速验证用前者，立项采购要报告用后者。

安装也是一行命令。

pip install opencompass

它评 API 模型要写个配置文件，智谱走它的 OpenAI 模型类。有个最容易踩的坑直接标出来：openai_api_base 要填到 /chat/completions 的完整路径，它内部是直接 POST 到这个值的，填成 base_url 会请求不到。

# eval_glm.py —— OpenCompass 评测配置（精简版，完整模板见官方 quick_start）import osfrom opencompass.models import OpenAImodels = [    dict(        type=OpenAI,        path='glm-5.3',        key=os.getenv('ZAI_API_KEY'),        openai_api_base='https://open.bigmodel.cn/api/paas/v4/chat/completions',  # 全路径        max_seq_len=8192,        abbr='GLM-5.3',        run_cfg=dict(num_gpus=0),   # API 模型不需要 GPU        max_out_len=1024,        batch_size=8,    )]

 datasets 部分从官方模板抄现成的基准组合即可，然后 opencompass eval_glm.py 一键跑。

做模型厂商专项测试的同学，可以深入了解学习一下。

四、商业平台：什么时候值得花这个钱

LangSmith 之外，还有一批纯商业评测平台，企业采购时会遇到，放一张表认识全貌。

它们共同的卖点是省部署运维、有 SLA 和厂商支持、协作和权限管理开箱即用；共同的顾虑对国内企业来说就两条，数据要出内网（敏感场景直接一票否决），按量计费用多了不便宜。

什么时候值得花钱？给你三条判断。

第一，看数据敏感度，这是硬门槛。

数据能上云、能出境，商业平台才进入备选；不能，直接看 Langfuse/Opik 自托管，这一票否决优先于所有其他优点。

第二，看团队规模和采购能力。

十几个人的小团队，开源加自托管完全够，商业平台的钱花在刀背上；上百人跨团队协作、要审计要权限要 SLA，商业平台的省心才开始值回票价。

第三，认清「开源框架 + 托管 + 付费增值」的商业模式。

很多商业平台本质是开源框架的托管版，Confident AI 之于 DeepEval、LangSmith 之于 LangChain。判断要不要付费的最快路径是，先把对应开源用明白，它托管版多出来的付费增值功能，对你是不是真实痛点，答案自然浮现。

还有一条国内特有的提醒，采购链路上要提前确认发票、合同主体、数据出境合规这些事。不少团队技术选型全通了，卡在商务和合规上推倒重来，这一步提前问，别等试用期结束。

五、怎么选：一张决策树加六个场景

工具都过完了，回到最初的问题，你的项目该用哪个。

5.1 选型决策树

这棵树的判断顺序是刻意设计的：先过合规这一票否决项，再看技术栈绑定，最后才看场景偏好。

用文字把整棵树的路径再解释一下：

第一条路径：数据不能出内网。

你的第一判断不是选哪个工具，而是「数据能不能出内网」。金融、政务、央国企，用户数据、业务数据不能传到外部 SaaS 平台——这一票直接否决所有商业 SaaS（LangSmith、Braintrust 全排除），只剩自托管路线。

结论：Langfuse 自托管（核心 MIT 协议、Docker 私有化部署、数据不出内网，11 篇带你完整部署），模型选型另配 EvalScope / OpenCompass 跑基准。

第二条路径：数据可以出内网 + 团队深度使用 LangChain / LangGraph。

技术栈已经绑定了，工具跟着栈走——LangSmith 是 LangChain 官方产品，原生集成最深（自动追踪 LangChain 应用每一步调用、LangGraph Agent 调试器），换别家工具要重新接。注意它是闭源 SaaS、按 trace 计费，重度使用要算账。

第三条路径：数据可以出内网 + 技术栈无偏好 + RAG 应用为主。

评的是知识库问答——RAGAS 管指标（忠实度、上下文精确率召回度，10 篇实操主角），执行外壳用 Promptfoo 或 DeepEval（跑批量、出报告、进 CI）。

第四条路径：数据可以出内网 + 技术栈无偏好 + Agent 应用为主。

评的是多步 Agent——DeepEval 管单元测试（任务完成度、工具调用正确性，pytest 风格进 CI），Langfuse 管线上追踪和轨迹（哪步出错、哪步最慢），两个各管一段。

第五条路径：数据可以出内网 + 技术栈无偏好 + 通用/提示词迭代 + 不想写代码。

团队不怎么写 Python——Promptfoo，YAML 声明式配置，命令行一跑出报告，产品测试运营都能参与改配置。

第六条路径：数据可以出内网 + 技术栈无偏好 + 通用/提示词迭代 + 会 Python / 要进 CI。

团队有测试开发——DeepEval，pytest 手感，参数化、断言、CI 接入和写单测同一套心智。

不管走哪条路径，安全红线场景都建议补 Promptfoo 红队扫描（自动生成越狱、提示注入、隐私套取攻击样本，独一份的能力），模型选型阶段的评测另配 EvalScope / OpenCompass（评模型和评应用的工具往往并不通用的）。

5.2 六个典型场景的直接答案

决策树是通用逻辑，六个高频场景给你现成答案，对号入座即可。

5.3 分层组合：成熟团队的常见打法

企业里成熟的做法往往不是单选，而是分层组合，各管一段。业界最常见的四层组合是——

• • Promptfoo 管 Prompt 快速对比和红队安全扫描（发布前的门禁）；
• • DeepEval 管评测单元测试进 CI（每次提交的回归）；
• • RAGAS 管 RAG 深度指标（专项体检）；
• • Langfuse 管线上追踪和 bad case 回流（运营闭环）。

注意，这是「成熟团队」的形态，不是起手式。

新团队从其中任意一个开始就够，把它用透、撞到它的能力边界了，再加下一层。一个都没用明白就四件套齐上，精力全花在串工具上，测评集反而没人管，这是被反复验证的反面路径。

还有一个降低组合成本的关键动作，测评集保持开放格式。

CSV/JSON 存 Git（03 篇的原则），Promptfoo 读 YAML/CSV，DeepEval 用代码加载，RAGAS 接列表，中间加薄薄一层转换就行。数据格式私有化（只存在某平台的专有格式里）的团队，换工具时都会重新人工搬一遍数据。

6、选型五个坑

坑一，只看 star 数选工具。

star 反映热度，不反映匹配度。Opik 21.8k star 很火，但你只是要给 50 条测评集配个断言，它带来的运维分量就是浪费。

选型看三个数，协议（能不能商用）、活跃度（最近半年提交）、和场景的匹配度，star 只当参考。本篇表格里的 star 数也是 2026 年 9 月的快照，你读到时已经变了，动手前自己去 GitHub 看一眼。

坑二，需求没稳就上平台。

03 篇讲过这个反面教材，这里从工具视角再钉一遍。

平台解决的是「团队化运营」的问题，测评集还没过 200 条、判定标准还在吵，平台的多用户权限管理给谁用？判断信号始终是换挡信号，手工判不动了上框架，回流靠人肉搬了上平台，而不是「听说大厂都用平台」。

坑三，不看开源协议就商用。

开源不等于随便用。

Langfuse 核心是 MIT，但 ee/ 目录的企业功能走商业协议；Phoenix 是 Elastic License 2.0，内部用没问题，转售托管服务违规；Giskard 拆出了 giskard-oss。

MIT 和 Apache-2.0 才是「商用无忧」档。企业环境里部署任何一个工具前，把 LICENSE 文件看一眼，这一分钟比事后法务整改便宜得多。

坑四，忽略评测的运行成本。

框架免费，评测不免费。

全量指标都走 LLM-as-a-Judge 的框架，300 条测评集跑一轮，裁判模型的开销可能比你想的高一个量级，每周回归再来一次，月底账单吓人。

05 篇的漏斗原则在工具里同样生效，规则断言能判的用免费断言，语义条款才给裁判，P0 条目才上多票。选型时问一句「这框架哪些指标免费、哪些烧钱」，能省下真金白银。

坑五，被单一厂商锁定。

OpenAI Evals 平台 2026 年 11 月关停（3.7 节）就是最鲜活的教训。

评测体系的核心资产是测评集、判定标准和历史结果���这些永远放开放格式；工具层保持可替换，Promptfoo 换 DeepEval、Langfuse 换 Opik，成本应该是配置迁移，而不是数据重建。

判断标准很简单，哪天你的测评集只能活在某个平台里，风险就已经埋下了。