一句话：前四个是 Agent / LLM 测试里最常被一起点名的开源工具，各管一件事——改提示词时并排对比、进 CI 时做质量断言、评 RAG 时拆开检索和生成、联调时看见每一次调用。LangSmith 是云端平台，把「看见调用」和「拿数据集做实验」放在一起，和 Langfuse 同一层。
写给谁：听到这几个名字、想知道各自干什么、什么情况下该拿起来用。
指标名称按 DeepEval 4.1、promptfoo 0.121、RAGAS 0.4、Langfuse SDK 4.14，以及 LangSmith 公开文档核对。
1. 是不是 Agent 测试都会听到的那几个
是。中文工程讨论、开源评测教程里，这四个名字出现的频率最高，而且经常被当成一套来讲。原因很具体：它们都开源、都能本地跑、合在一起刚好盖住「改 Prompt → 写回归 → 评知识库 → 看线上」这条链路，又不绑定某一家模型厂商。
把范围说清楚，避免以后听到别的名字以为自己漏学了：
这四个是开源入门组合，不是 Agent 测试的全部名单。
- LangSmith
同样会被点名，而且频率不低。它不是这四个里某一个的开源替身，而是把调用链、数据集、实验放进同一个云端。第 8 节单独写，第 8.5 节和前四个对位。
同一层还会听到Arize Phoenix、Laminar、Braintrust、TruLens、Inspect AI。文末有对照。
它们解决的是「模型输出不稳定，普通assert ==不够用」之后的质量问题。接口通不通、权限对不对、工具有没有真的改到系统状态，仍然靠普通测试断言。四个工具都不替你准备题库，也不替你准备可执行的工具沙箱。
2. 各站哪一层
工具 | 站在哪一层 | 你交给它的东西 | 它交回来的东西 | 典型触发时机 |
|---|---|---|---|---|
| promptfoo | 改 Prompt / 选模型 | 一份 YAML：多条提示词 × 多个模型 × 一批题和断言 | 矩阵结果、通过/失败、本地对比页 | 提示词改了一句、要换模型、要做注入冒烟 |
| DeepEval | CI 里的质量断言 | pytest 用例：输入、实际输出、可选的上下文和期望工具 | 每条用例 PASS/FAIL，外加 0～1 分和理由 | 关键问答要卡在流水线里，不过线就红 |
| RAGAS | RAG 离线打分 | 一批样本：问题、回答、检索片段、标准答案 | 忠实度、答案相关性、上下文精度、上下文召回的均分 | 改了切片、topK、重排或生成模型，要知道差在检索还是生成 |
| Langfuse | 看见调用过程 | 应用里埋点，或把已有评测分写回去 | 调用树、token、耗时、成本、人工分、数据集 | 多步 Agent 答错了，要定位是哪一步 |
| LangSmith | 看见调用，并在云端做实验 | 埋点、数据集、评估器 | 调用树、实验对比、提示词版本、人工标注 | 已经在用 LangChain / LangGraph，希望链路和评测在一个网页里 |
可以记成五句话：
- promptfoo
回答「这版提示词和那版，谁在这批题上更好」。
- DeepEval
回答「这一条现在过不过门槛」。
- RAGAS
回答「这批知识库问答，分是掉在检索还是掉在生成」。
- Langfuse
回答「这一次真实请求里，每一步实际喂了什么、吐了什么」。
- LangSmith
回答的是第 4 句，另外把「换一版提示词，在同一批题上重跑」也放进同一个云端界面。
改提示词、比模型 promptfoo 矩阵对比，本地看表 ↓ 选定一版 写进回归、卡 CI DeepEval 单条用例过线 / 红灯 ↓ 如果带知识库 检索和生成拆开打分 RAGAS 四维均分，定位哪一段退步 ↓ 接到联调或线上 每一次调用留痕 Langfuse 调用树、成本、人工抽检 LangSmith 同一层；外加云端实验和 Playground旁边还有一层它们都不负责：服务是否活着、接口是否 200、权限是否越权。那是接口测试和监控（Prometheus / Grafana / Loki 一类）的事。
3. 先知道「裁判模型」
DeepEval、RAGAS、promptfoo 的llm-rubric，分数大多不是公式硬算出来的，而是再叫一个模型当裁判。
裁判做的事通常是：把回答拆成几条陈述，逐条问「这句话能不能从上下文推出来」，或者按你写的一段自然语言标准打分。所以：
绝对分会随裁判模型、温度、提示词变动。同一批题做版本对比时，裁判模型要固定。
裁判也会错。门禁上更稳的做法是：硬断言（工具名、参数、最终状态）决定过不过；裁判分作质量参考。裁判调不通就记跳过，不要当成产品通过。
裁判要花钱、要耗时。题量上去之后，每次全量评测都是一笔模型和时间开销。
Langfuse 本身不充当裁判。它负责把别的裁判打出来的分，挂到某一次真实调用上。
4. DeepEval：用 pytest 断言「答得好不好」
官方：https://github.com/confident-ai/deepeval
4.1 它是什么
Confident AI 出的开源评测库，用法长得像单元测试。一条用例是一个LLMTestCase：用户输入、模型实际输出，以及可选的检索上下文、期望输出、实际调用的工具、期望调用的工具。一条指标是一个Metric，算出 0～1 分，达到threshold才算过。assert_test把没过线的用例变成 pytest 失败。
它和普通 pytest 的差别只有断言对象：普通断言看字符串、状态码、JSON 字段；DeepEval 的断言看「是否忠于上下文、是否答到点上、工具叫得对不对」。两者可以写在同一个测试文件里。
库可以完全在本地跑。Confident AI 另外有可选的云端，用来存数据集和看回归趋势，不装云也能用核心指标。
4.2 一条指标实际在干什么
以最常用的Faithfulness（忠实度）为例，裁判大致做三步：
从回答里抽出若干条陈述。
逐条判断：这条能不能从
retrieval_context推出来。分数 = 能被上下文支持的陈述数 / 全部陈述数。
所以忠实度高，只说明「回答没有跳出给定材料」。材料本身是错的，回答可以又忠实又错误。
Answer Relevancy（答案相关性）看回答是否对着问题说，不看事实对错。答非所问分低；顺着问题胡编，这一项仍可能高。
GEval是自定义指标。你用自然语言写标准，例如「先给结论，再给依据，不能编造未提供的指标」，裁判按这个标准打分。适合业务口径，不适合当唯一的硬门禁，因为它不稳定。要规则稳定、可解释到每一条分支，DeepEval 提供DAGMetric，用有向图把判定步骤写死。
4.3 指标按场景记
场景 | 常用指标 | 需要你提供 |
|---|---|---|
知识库回答是否胡编 | Faithfulness、Hallucination | 回答 + 检索上下文 |
是否答到问题上 | Answer Relevancy | 问题 + 回答 |
检索片段是否有用、是否找全 | Contextual Relevancy / Precision / Recall | 问题、上下文，召回类还要标准答案 |
业务自己的好坏标准 | GEval、DAGMetric | 一段准则，或一张判定图 |
工具名、参数、顺序对不对 | ToolCorrectness、ArgumentCorrectness | 实际工具调用 + 期望工具调用 |
多步有没有做完、绕没绕远 | TaskCompletion、StepEfficiency、PlanAdherence、PlanQuality | 一整条执行轨迹，不只是最终一句话 |
后两行是 Agent 才用得上的。ToolCorrectness 默认比对工具名；可以要求参数一致、输出一致、顺序一致。没有tools_called和expected_tools，这项是空的，打不出「工具用对了」。TaskCompletion 一类要看完整轨迹（计划、模型调用、工具调用的顺序），只丢最终回答进去，它无从判断任务是否做完。
4.4 什么情况下用
已经有 pytest，希望关键问答和普通接口测试躺在同一条 CI 里。
每条用例要一个明确的过线阈值，例如忠实度 ≥ 0.8。
被测对象能交出工具轨迹，想卡「该调的工具调了、参数没错」。
标准答案不好写成一个字符串，但能写成一段评语（用 GEval）。
4.5 什么情况下换别的
同一批题要横比 5 个模型、3 版提示词：用 promptfoo，矩阵和对比页是现成的。
手里是一整张 RAG 黄金集，要的是四维均分报告：用 RAGAS，字段和指标定义更贴这篇任务。
线上某次请求答错，要看中间检索了什么：用 Langfuse 这类调用链平台。
对错可以由工具返回值、数据库状态直接判定：继续用普通 assert。裁判分只增加一道会波动的关。
5. promptfoo：同一批题，并排跑多种提示词和模型
官方：https://www.promptfoo.dev
5.1 它是什么
一个命令行评测工具（也带本地网页）。配置是 YAML，不是测试代码。核心是一张矩阵：
提示词 × 模型（provider）× 测试用例 = 每个格子跑一次
每个格子可以用断言判过或不过。promptfoo eval跑完，promptfoo view在本地打开对比页，一眼看到哪一版提示词在哪道题上退步。评测默认在本机执行，提示词不必上传到 promptfoo 的服务。
2026 年 promptfoo 并入 OpenAI，仓库仍是 MIT 开源，用法不变。文档里会看到它被 OpenAI、Anthropic 用来做评测，这只说明采用面广，不改变你本地怎么配。
Provider 不限于官方模型名。只要能发请求，就可以接：各家聊天接口、Ollama、一段 Python、一个 HTTP 接口。所以它也能打到你自己的 Agent 接口，但协议、登录、工具返回都要自己写成 provider。产品已经有一套接口测试时，不必为了「能打到 Agent」再包一层。
5.2 断言分两类
类型 | 例子 | 稳不稳定 | 适合卡什么 |
|---|---|---|---|
确定性 | contains、 | 稳，可复现 | 必须出现的状态词、JSON 结构、禁止出现的危险步骤 |
模型打分 | llm-rubric、相似度、事实性 | 随裁判波动 | 「拒绝危险操作」「先结论后依据」这类说得清、不好写成正则的要求 |
资源 | cost、 | 稳 | 这版提示词是否突然更贵、更慢 |
一道题可以叠多条断言。关键词用确定性断言，语气和拒绝策略用llm-rubric。能用正则判的，就不要交给裁判。
5.3 红队是它比较特别的一块
promptfoo redteam不是你手写 10 条注入题，而是：
- 插件
按漏洞类型生成攻击输入（越狱、提示注入、隐私套取、有害内容、RAG 投毒等）。
- 策略
决定这些输入怎么送进去（直接问、包装一层、多轮诱导等）。
生成攻击的模型，和被测的目标模型是分开的。目标永远在你本机配置里打。
适合上线前做一轮安全冒烟：人设会不会被带跑、会不会给出删除全部数据这类步骤。它覆盖的是「模型会不会被说动」，不是「接口有没有鉴权」。鉴权仍然要测 API。
5.4 什么情况下用
系统提示词改了措辞，想在固定题集上看退步，而不是手工贴到聊天窗口。
两个模型或两种温度，要并排看回答、成本和耗时。
输出必须是 JSON、必须包含某个字段，希望配置放在仓库里，CI 按退出码红灯。
要一份能打开给别人看的对比结果。
5.5 什么情况下换别的
要拆「检索差」和「生成差」：YAML 里的一条
llm-rubric给不出上下文精度和召回，换 RAGAS。断言要和现有 Python 测试、业务对象揉在一起：DeepEval 更顺。
要看某次线上请求的工具返回原文：promptfoo 不留生产调用链。
测的是整条产品链路通不通，题依赖登录态、Agent 配置和知识库：用产品自己的接口测试。promptfoo 留在改文案之前的本地对比。
6. RAGAS：把 RAG 拆成检索和生成再打分
官方：https://docs.ragas.io
6.1 它是什么
Exploding Gradients 做的 RAG 评测库。输入是一张表，每一行一道题，输出是各指标的均分。它回答的不是「这一条 pytest 过不过」，而是「这一版知识库管线，和上一版比，哪一项掉了」。
新版字段名是user_input、response、retrieved_contexts、reference。旧教程里常见的question、answer、contexts、ground_truth是同一组东西的旧名字。retrieved_contexts是「字符串列表的列表」：每道题对应多段检索文本。
6.2 四维分别怎么算、掉了说明什么
这是 RAGAS 真正好用的地方。四项一起看，才能把故障定位到管线的一段。
指标 | 现在文档里的名字 | 怎么来的 | 不需要标准答案？ | 分低通常说明 |
|---|---|---|---|---|
忠实度 | Faithfulness | 回答拆成陈述，数有多少条能从检索片段推出来 | 要上下文，不要标准答案 | 生成模型在材料之外胡编 |
答案相关性 | Response Relevancy（旧名 Answer Relevancy） | 让裁判根据回答反推几个问题，再和原问题做向量相似度 | 不要标准答案 | 答非所问、空泛、或夹了无关内容 |
上下文精度 | Context Precision | 检索回来的片段里，有用的是否排在前面。有标准答案时，片段和标准答案比；没有时，有一种用法是和模型自己的回答比（Context Utilization），更弱 | 看变体 | 检索太吵，无关片段排前面 |
上下文召回 | Context Recall | 标准答案拆成陈述，数有多少条能在检索片段里找到依据 | 要标准答案 | 该找到的证据没找回：切片、topK、嵌入或查询有问题 |
四项的组合怎么读：
现象 | 优先查哪里 |
|---|---|
召回低，忠实度正常 | 检索。切片太大或太碎、topK 太小、查询没改写、过滤条件把文档排掉了 |
精度低，召回正常 | 检索排序。无关片段挤进了前排，重排或过滤可以收 |
忠实度低，召回精度都正常 | 生成。模型没按材料答，提示词或温度的问题更多 |
相关性低，忠实度高 | 生成偏题。它很守材料，但没回答用户问的那句 |
四项都高，人仍然觉得错 | 材料或标准答案本身有问题，或者裁判模型和业务口径不一致 |
两个容易看反的点：
- 忠实度高 ≠ 答案正确。
检索到一份过期文档，模型如实转述，忠实度可以接近 1，业务上是错的。
- 相关性高 ≠ 答案正确。
这项只看「像不像在回答这个问题」。顺着问题编一个状态，相关性仍可能高，忠实度会低。
所以汇报时要报分项，不要只报四项平均。平均分会把「检索没找回」和「生成在胡编」抹成同一个数字。
换裁判模型，绝对分会漂。两个版本要比，就用同一个裁判、同一张黄金集。黄金集题量太少时，换任何打分器都稳不住排序。
6.3 它后来也覆盖了一部分 Agent 指标
RAGAS 不只有 RAG 四维。和工具型 Agent 相关的还有：
指标 | 测什么 |
|---|---|
Tool Call Accuracy | 工具调用的顺序和参数是否与期望完全一致，偏 0/1 |
Tool Call F1 | 工具名和参数的精度、召回，多调、少调时给一个软分数 |
Agent Goal Accuracy | 任务目标是否达成，有标准答案和没有标准答案两种 |
Topic Adherence | 回答是否留在允许的主题里 |
这些要你交出工具调用记录或目标描述。没有轨迹时，它们和 DeepEval 的工具指标一样空转。RAG 四维仍然是这个库最常被用、也最值得学的部分。
6.4 什么情况下用
被测链路里有「先检索、再生成」，而且你能拿到检索片段原文。
刚改了知识库：切片大小、重叠、topK、重排、嵌入模型、生成模型，想知道退步发生在哪一段。
测试报告需要一组可对比的数字，而不是「感觉回答还行」。
6.5 什么情况下换别的
没有检索的闲聊、纯提示词文案：四维里有三项失去意义，用 promptfoo。
只要卡死一条用例过不过 CI：DeepEval 的 pytest 集成更直接。指标定义相近，包装不同，不要两套裁判同时当门禁，否则失败时分不清是产品错了还是裁判不一致。
要看某一条线上请求当时检索了什么：先有调用链（Langfuse 一类），再决定要不要对那一次调用补打分。
7. Langfuse：把一次 Agent 运行展开成调用树
官方：https://langfuse.com
7.1 它是什么
开源的 LLM 工程平台，可以自建（Docker），也可以用云。Python / JavaScript SDK 基于 OpenTelemetry：应用里每一步成为一个 observation，同一次用户请求共享一个 trace id。
它和日志、监控的分工：
系统 | 你能看见的 |
|---|---|
应用日志 | 一行行文本 |
Prometheus / Grafana | QPS、错误率、CPU、延迟直方图 |
Langfuse | 这次问了什么、检索了哪几段、调了哪个工具、工具返回了什么、模型说了什么、花了多少 token |
同一层的公开产品还有 LangSmith、Arize Phoenix、Laminar。它们都能看调用树、会话、评分和数据集。已经有其中一套在收埋点，就沿用那一套，不必为了同一件事再部署第二个界面。
7.2 里面的对象
对象 | 是什么 | 用来干什么 |
|---|---|---|
Trace | 一次用户请求或一次 Agent 运行 | 按时间、用户、session、tag 把一次交互捞出来 |
Span | 树里的一步：检索、工具、子 Agent | 看输入输出和耗时，定位慢在哪、错在哪 |
Generation | 特指一次模型调用 | 看模型名、提示词、补全、token、费用 |
Score | 挂在 trace 或某一步上的分 | 人工打分，或把 RAGAS / DeepEval 的分写回来 |
Session | 多轮对话归组 | 看同一用户连续几轮把任务做成什么样 |
Dataset | 从线上 trace 抽出来的题，或手建的题 | 坏例子沉淀成回归集 |
Experiment（Dataset Run） | 用当前应用把数据集跑一遍 | 对比提示词版本或模型版本，分挂在同一次 run 上 |
Prompt | 带版本的提示词 | 某次 generation 链到具体版本，按版本看延迟、成本和分数 |
新版 SDK 里，创建 trace 的写法和两年前教程不同（更靠近 OpenTelemetry 的 span）。概念没变：一次运行一棵树，模型调用单独记 token。SDK 4.x 以当前官方文档为准，旧教程里的lf.trace()可能已经不是推荐入口。
7.3 它和前三个怎么接上
Langfuse 不替代打分器。常见接法是：
请求进来，SDK 记下检索 span 和模型 generation。
离线或异步用 RAGAS / DeepEval 算分。
用同一个 trace id 把分数写回去。
这样点开一次「答得离谱」的请求，左边是调用树，右边是忠实度 0.4 和理由，能看到是检索片段错了还是模型没照片段说。
另一条闭环：线上抽到坏 trace → 放进 Dataset → 下一次改提示词时，用 Experiment 把这批坏例子重跑。评测题从此不只来自手写，也来自真实失败。
7.4 什么情况下用
Agent 有多步（检索、多个工具、再生成），用户只说「答错了」，你需要中间产物。
要看哪一次模型调用贵、哪一步慢。
要人工抽检，并把抽检结果留在原请求旁边。
提示词有版本，想按版本看线上分数和成本，而不是只在本地矩阵里看。
7.5 什么情况下换别的
只想要 CI 红灯：用 DeepEval 或 promptfoo 的退出码。观测平台默认是给人看的，除非你自己把低分做成失败条件。
产品已经有别的观测平台，并且埋点已经在跑：沿用那一套。同一请求拆进两个界面，树对不齐，排障更慢。
没有埋点、也拿不到工具返回：平台是空的。先保证运行时把 span 打出来。
应用就是 LangChain / LangGraph，并且调用数据可以放在云端：看第 8 节的 LangSmith，它和这里是同一层，二选一。
8. LangSmith：调用链、数据集和实验放在同一个云端
官方：https://docs.langchain.com/langsmith
8.1 它是什么
LangChain 出的 LLM 工程平台，用托管服务为主。打开一个项目，通常同时能看见五块：
块 | 干什么 |
|---|---|
Tracing | 一次请求的调用树：输入、检索、工具、模型、耗时、token |
Dataset | 一组题。可以手建，也可以从某次 trace 里摘出来 |
Experiment | 用当前应用或当前提示词把数据集跑一遍，多次运行并排比分数、延迟、token |
Playground | 在网页上换提示词、换模型，直接对数据集开一轮实验，不必先写评测脚本 |
Prompt Hub | 提示词的版本。某次运行可以链到具体版本 |
另外还有标注队列：人在界面上给某次运行打分，这些分数和自动评估器的分数记在同一次运行上。
它和 Langfuse 是同一类产品。和 DeepEval、RAGAS、promptfoo 不是同一类：后三个是评测库或命令行，LangSmith 是承载调用和实验的平台。
和 Langfuse 比，公开资料里稳定的差别有三条：
- 和 LangChain、LangGraph 接得最紧。
用这两套框架时，埋点往往少写很多代码。其它框架用它的 SDK 也能记，只是没有「零配置」那么省事。
- 主体是云端。
完整自己部署不在开源发行里，公开说明放在企业方案。调用内容默认在 LangChain 的云上。
- 不自带 RAG 四维的固定算法。
它提供评估器的位置：一段 LLM 裁判提示，或一段自己的代码。官方预置过「正确性」这类通用裁判，那是在看答得像不像参考答案，不是 RAGAS 的忠实度、上下文精度、上下文召回。
8.2 一次实验实际怎么转
应用跑起来，trace 进项目。调用树里能展开工具和模型。
把典型的、答错的 trace 收进 dataset：留下输入，有标准答案就一并留下。
在 Playground 里改提示词或换模型，或者在代码里调用
evaluate()，对这个 dataset 跑一遍。每条结果交给评估器。界面上多次 experiment 并排：分数、延迟、token，以及这次用的模型、提示词、工具。
对象和 Langfuse 大致对齐，方便两边的文档对看：
LangSmith | 大约等于 Langfuse 的 |
|---|---|
Trace / 调用树 | Trace + Span / Generation |
Dataset | Dataset |
Experiment | Experiment（Dataset Run） |
Feedback / Evaluator | Score |
Prompt Hub | 带版本的 Prompt |
Annotation queue | 在界面上给某次运行打分 |
8.3 什么情况下用
应用已经是 LangChain 或 LangGraph，想少写埋点，直接在网页里看每一步。
希望「线上那次调用」和「拿这批题重跑」在同一个地方，接受数据放在云端。
改提示词时想在界面上对同一数据集重跑，暂时不想维护一份 YAML 或一套 pytest。
8.4 什么情况下不要用它代替另外四个
要的是忠实度、上下文精度、上下文召回这套固定定义：仍用 RAGAS。算完的分可以写回 LangSmith 的 feedback，算法本身不在 LangSmith 里。
要 pytest 里一条用例不过就挡合并：仍用 DeepEval。
要自动生成注入、越狱一类攻击再打分：仍用 promptfoo。
调用内容不能离开自己的机器：用可以自己部署的 Langfuse（或 Phoenix、Laminar）。不要为了同一棵调用树再加一个 LangSmith。
已经有 Langfuse 或别的观测平台在收埋点：沿用那一套。两个平台各记一半，排障时树对不齐。
8.5 和前四个怎么对位
| — | promptfoo | DeepEval | RAGAS | Langfuse | LangSmith |
|---|---|---|---|---|---|
主要形态 | 本地命令行，配置是 YAML | Python 库，接 pytest | Python 库，对一张表打分 | 开源平台，可自己部署 | 云端平台 |
并排比提示词、模型 | 主业 | 不是主业 | 不是主业 | 能做实验 | 主业之一，Playground 直接开 |
单条用例卡进 CI | 看退出码 | 主业 | 要自己包一层 | 要自己把低分接成失败 | 要自己把 experiment 接进 CI |
RAG 四维的固定算法 | 没有 | 有相近指标 | 主业 | 没有，可把 RAGAS 的分挂上 | 没有，自己写评估器，或外面用 RAGAS |
线上每一次调用树 | 不留 | 评测时可以看轨迹 | 不留 | 主业，可自己部署 | 主业，LangChain / LangGraph 最省事 |
注入、越狱扫描 | 主业之一 | 有安全类指标 | 没有 | 没有 | 不是主业 |
线上坏例子收成题 | 不收生产流量 | 可以建数据集 | 不收 | 可以 | 可以，从 trace 点进 dataset |
提示词版本 | 写在仓库配置里 | 不管 | 不管 | 有 | Prompt Hub |
绑不绑框架 | 不绑 | 不绑 | 不绑 | 弱，走 OpenTelemetry | LangChain / LangGraph 最顺 |
数据放哪 | 本机 | 本机（可选它的云） | 本机 | 自己的机器，或它的云 | 默认它的云 |
观测这一层可以收成一句：应用是 LangChain / LangGraph、数据可以上云，用 LangSmith；要开源、要自己部署、框架不限，用 Langfuse。只想比提示词、还没有线上流量，先用 promptfoo，两个平台都先不必上。
9. 同一件事，五个工具各看见什么
场景：客服 Agent 回答「退货期限是几天」。知识库里有一句「签收后 7 天内可无理由退货」。
你做的改动 | 先用谁 | 你会看到什么 |
|---|---|---|
系统提示词从「简明回答」改成「先结论后依据」 | promptfoo | 两列并排。新提示词更长、更慢；某道注入题是否仍然拒绝 |
把忠实度 ≥ 0.8 写进合并请求 | DeepEval | 这一条用例红或绿，附带裁判理由 |
切片从 512 改成 2000，或 topK 从 5 改成 2 | RAGAS | 召回掉了说明证据被切丢或没进前排；忠实度掉了说明模型开始凭空补天数 |
联调时这题答成了「30 天内可退」 | Langfuse 或 LangSmith | 展开后发现检索到的是另一份过期文档，或检索结果写的是 7 天但模型没采用 |
想在网页上换一版提示词，用同一批退货题重跑 | LangSmith 的 Playground，或 promptfoo | LangSmith 靠数据集和评估器；promptfoo 靠 YAML。RAG 四维仍然要另算 |
这些结果可以同时为真：promptfoo 里文案更好看，DeepEval 单条过线，RAGAS 召回下降，线上调用树显示检索错了文档。所以它们是叠起来用的。LangSmith 和 Langfuse 不要叠：调用树只记在一个平台里。
10. Agent 测试里，它们盖得住什么
Agent 比单轮问答多出来的失败，大致是下面这些。对得上的，已经写在「谁能帮忙」一列。
失败 | 谁能帮忙 | 要先有什么 |
|---|---|---|
回答胡编、答非所问 | DeepEval、RAGAS | 回答，胡编还要上下文 |
检索到错文档、该有的文档没到 | RAGAS 的精度和召回 | 检索片段；召回还要标准答案 |
提示词改坏了、模型 A 不如模型 B | promptfoo；已经在 LangSmith 里也可以用 Playground / Experiment | 固定题集 |
看不清多步里哪一步错 | Langfuse 或 LangSmith | 埋点，两个平台二选一 |
工具没调、调错、参数错 | DeepEval 的 ToolCorrectness / ArgumentCorrectness，RAGAS 的 Tool Call Accuracy / F1 | 实际工具调用记录 ，外加你认为正确的调用 |
多步任务最后没做完 | DeepEval 的 TaskCompletion，RAGAS 的 Agent Goal Accuracy | 完整轨迹，或一个可核对的最终状态 |
越权、真的删了资源、接口 500 | 都帮不上 | 产品状态和接口断言 |
题太少，换打分器分数乱跳 | 都帮不上 | 把黄金集补厚 |
没有可运行的工具环境，工具题只能空谈 | 都帮不上 | 沙箱或假工具服务 |
最后三行是 Agent 门禁里经常比「再接一个评测框架」更要紧的缺口。打分器换得再正宗，题还是那几道、轨迹还是空的，结论仍然不稳。
11. 听到别的名字时怎么对位
听到的名字 | 更接近谁 | 多出来的一点 |
|---|---|---|
LangSmith | Langfuse，外加一部分 promptfoo 的对比 | 详见第 8 节。云端为主，LangChain / LangGraph 最省事 |
Arize Phoenix | Langfuse，外加一部分评测 | 强调 OpenTelemetry，可自建 |
Laminar | Langfuse | 同一层的开源观测平台，看调用树、会话和评分 |
Helicone | Langfuse 里偏网关的那一块 | 更侧重请求日志、缓存和成本，调用树能力较轻 |
Braintrust | promptfoo + Langfuse 的商业一体 | 实验和线上分数放在一个产品里 |
TruLens | RAGAS / DeepEval 的 RAG 指标 | 早期以 RAG 三元组（有据、相关、上下文）出名 |
Inspect AI | DeepEval 这一层，偏研究和安全 | 英国 AISI 的评测框架，多用于模型与 Agent 行为评测 |
OpenAI Evals | DeepEval / promptfoo 的早期同类 | 现在讨论变少，新项目很少从它搭起 |
有人说「上 LangSmith」时，先对第 8.5 节那张表。它盖住的是调用树和云端实验，盖不住 RAG 四维的固定算法，也盖不住 pytest 红灯和注入扫描。
12. 遇到一件事时怎么选
按你手头的材料选，不要按工具名气选。
只有提示词和一批问题，还没有检索。
promptfoo。先把格式、拒绝策略、模型差异看清楚。有检索片段，要写进测试报告或回归。
RAGAS 四维。先看召回和精度，再看忠实度。没有标准答案时，召回先空着，不要用平均分掩盖。这条链路已经有 pytest，希望不过线就挡合并。
DeepEval，阈值写在用例里。能用工具名、JSON 字段、系统状态判的，仍然用普通断言，不要全部换成裁判。线上或联调已经答错，但你不知道中间发生了什么。
打开已经在用的观测平台。没有的话：LangChain / LangGraph 且数据可以上云，用 LangSmith；要自己部署，用 Langfuse。先看检索和工具那几步，再决定要不要补打分。应用是 LangChain / LangGraph，想在一个网页里改提示词并重跑。
LangSmith 的 Playground 和 Experiment。RAG 四维仍用 RAGAS，需要挡合并的用例仍用 DeepEval。几个一起用。
顺序是：promptfoo 或 LangSmith Playground 选定提示词和模型 → RAGAS 看知识库管线 → DeepEval 把少数关键题卡进 CI → 观测平台承接真实请求。裁判模型全程用同一个。Langfuse 和 LangSmith 只留一个。
