评测驱动开发（EDD）系列前 8 篇把方法论讲完了：数据集怎么建、评估器怎么写、轨迹怎么比。但有个问题一直悬着：这些活儿到底用什么工具干？《AI Agent 开发》系列第 27 篇用 LangSmith 跑实验，《上下文工程》系列第 15 篇却用 promptfoo 跑批、门禁逻辑自己写——同一个作者给出两个答案，不是摇摆，是两个项目的栈、阶段、约束完全不同。本篇把工具版图摊开：先列需求清单，再逐家过 LangSmith、Braintrust、DeepEval、promptfoo，接着划清自研与采用的分界线，最后给出决策矩阵与真实团队的混合配置。工具会过时（事实核对到 2026 年 10 月），判断框架不会。
1、评测工具的需求清单
1.1、需求五件套
选型第一铁律：先列需求，再看工具。顺序反了，你会被各家 landing page 牵着走——每个平台都宣称端到端覆盖，但每一端的完成度天差地别。评测基础设施的真实需求是五件套：
| 需求 | 要回答的问题 |
|---|---|
| 数据集管理 | 用例存在哪、怎么版本化、怎么切片 |
| 评估器编写 | 断言与裁判怎么写、怎么单独调试 |
| 实验追踪 | 每次跑批的参数与代码版本留没留档 |
| 比较视图 | 两次实验的逐用例 diff 看得见吗 |
| 线上闭环 | 线上失败样本能否一键回流成用例 |
前三件是及格线，后两件拉开差距。比较视图最容易被低估：自己用 pandas 拼 diff，每次二十分钟，用平台一眼看完；线上闭环则决定评测集是活资产还是静态标本——线上样本不回流，工具再好，评测集三个月就与现实脱节。
1.2、工具版图一览
2026 年 10 月这个时点，主流选项六家：
| 工具 | 出品方 | 一句话定位 |
|---|---|---|
| LangSmith | LangChain | 商业平台，数据集+实验+追踪三合一 |
| Braintrust | Braintrust | 商业平台，EDD 理念原生实现 |
| DeepEval | Confident AI | 开源框架，pytest 风格指标库 |
| promptfoo | 开源社区 | 开源工具，YAML 声明式配置 |
| Langfuse | Langfuse | 开源平台，可自托管的可观测与评测 |
| OpenAI Evals | OpenAI | 托管版已宣布关停 |
最后一家不是凑数。OpenAI 在 2026 年 7 月宣布托管版 Evals 于 10 月 31 日转只读、11 月 30 日关停，官方迁移建议指向 promptfoo。这件事给所有选型者提了醒：评测工具会死，数据集和评估器不能陪葬——这句话是本文全部建议的底层假设。
2、LangSmith 三合一
《AI Agent 开发》系列第 27 篇的结论今天依然成立：应用跑在 LangChain/LangGraph 栈上，LangSmith 是阻力最小的路径。三合一指数据集、实验、追踪共用一套 ID 体系——每条实验记录自动挂完整 trace，点开失败用例能直接看 Agent 每一步调了什么工具。跑批代码保持第 27 篇口径：
# run_eval.py —— LangSmith 跑批三合一
from langsmith import evaluate
def cs_agent(inputs: dict) -> dict:
return {"answer": bot.run(inputs["question"])} # 被测应用
def judge_relevancy(outputs: dict, reference_outputs: dict) -> bool:
return relevancy(outputs["answer"],
reference_outputs["criteria"]) # 第 5 篇的裁判
results = evaluate(
cs_agent, # 被测目标
data="cs-agent-golden-1.2.0", # 第 3 篇建的黄金集
evaluators=[judge_relevancy],
experiment_prefix="prompt-v3", # 实验名前缀
)
跑完在网页端比较两次实验：逐用例 diff、按 metadata 切片、失败用例的 trace 三击可达；LangGraph 应用设 LANGSMITH_TRACING=true 即零埋点追踪。代价同样明确：按席位加用量计费、数据在别人云上、脱离 LangChain 栈后集成优势对折。我的判断：栈契合度是买入 LangSmith 的唯一理由，别为平台本身买单。
3、Braintrust 原生实现
系列第 1 篇提过，EDD 这个名字是 Braintrust 在 2026 年 2 月的博客里定的，同月它完成 ICONIQ 领投的 8000 万美元 B 轮。理念落到产品上的核心差异是 playground 与实验的闭环：在 playground 里改一版 prompt，立即在整个数据集上重跑，逐行 diff 立刻可见——迭代回路比"改代码、跑批、切网页"短一截。跑批用它的 Eval 辅助函数：
# eval_braintrust.py —— Braintrust 的 Eval 助手
from braintrust import Eval
from autoevals import Factuality # 官方裁判指标库
Eval(
"cs-agent", # 项目名
data=lambda: load_cases("golden.jsonl"), # 评测集
task=lambda inputs: bot.run(inputs["question"]), # 被测目标
scores=[Factuality], # 输出对比参考答案
)
data、task、scores 三个参数把评测集、被测目标、评估器拆得干净，autoevals 库的 Factuality 开箱即用。Braintrust 的强项是工程师体验：scorer 调试、实验对比、prompt 迭代都在一个界面里。弱项是开源生态薄（SDK 开源、平台闭源托管），数据出境合规要自己过。适合把 EDD 当核心工作流的团队，不适合只想挂个 CI 门禁的团队。
4、DeepEval 测试化路径
系列第 1 篇那条最小评测就是 DeepEval 写的，本篇补上它真正的杀手锏：@pytest.mark.deepeval 标记让评测直接寄生进现有测试体系：
# test_cs_agent.py —— 评测即 pytest
import pytest
from deepeval import assert_test
from deepeval.metrics import AnswerRelevancyMetric
from deepeval.test_case import LLMTestCase
@pytest.mark.deepeval
def test_refund_flow():
q = "退货流程是什么？"
case = LLMTestCase(input=q, actual_output=bot.answer(q),
expected_output="7 天无理由退货操作步骤")
assert_test(case, [AnswerRelevancyMetric(threshold=0.8)])
对测试工程师这条路径无可替代：不改 CI 配置、不改目录结构，pytest 一条命令应用测试与评测一起跑。指标库内置 50 多个研究背书的指标——GEval 用自然语言定义裁判标准、AnswerRelevancyMetric 管相关性、FaithfulnessMetric 管忠实度、HallucinationMetric 管幻觉，外加 RAG 三角，覆盖本系列第 4～6 篇讲过的大半评估器类型。短板在实验追踪与比较视图：它的重心是 CI 而非平台（Confident AI 有云版，但界面能力弱于前两家）。定位一句话：指标库加测试框架，不是观测平台。
5、promptfoo 声明式矩阵
《上下文工程》系列第 15 篇的 CI 门禁就是 promptfoo 跑的。它的形态与前几家都不同：YAML 声明式，prompts、providers、tests 三个维度自动展开成矩阵：
# promptfooconfig.yaml —— 提示词 × 模型矩阵
prompts:
- file://prompts/answer_v3.txt
- file://prompts/answer_v4.txt
providers:
- openai:gpt-4o
- anthropic:claude-sonnet-5
defaultTest:
assert:
- type: contains
value: "退货"
tests:
- vars: { q: "退货流程是什么？" }
- vars: { q: "订单 38291 什么时候到？" }
npx promptfoo@latest eval 一条命令，2 个 prompt 乘 2 个模型乘 2 条用例共 8 组结果进本地 Web 视图。矩阵形态天然匹配提示词工程阶段的三个高频动作：改 prompt、换模型、对拍。它如今还长出红队扫描能力，且被 OpenAI 点名为 Evals 关停后的迁移去向，社区活跃度有保障。边界也清楚：断言靠配置拼装，复杂裁判与多步 Agent 轨迹评测会顶到 YAML 的表达力上限——那时该换工具，不是硬凹配置。
6、自研与采用的分界
前五节都在讲"用谁的"，这一节讲"什么时候都不用"。三个信号同时成立，自研比任何平台都顺手：
- 数据集本来就在业务库或数仓，迁去平台是搬运税
- 评估器是业务逻辑，需要随代码同 review、同版本化
- 核心诉求是 CI 门禁，比较视图用 git diff 加报表就够
《上下文工程》系列第 15 篇的取舍是个好参照：门禁判定带 ±2 个百分点的容差、baseline 随版本显式更新，这类规则是纯业务逻辑，自研十来行；跑批则不重复造轮子，交给 promptfoo。真正全自研的场景是三个信号全中，骨架可以短到这样：
# eval_runner.py —— 自研跑批的骨架
from evals import db, run_case, aggregate # 各约 50 行
def run_suite(version: str) -> dict:
cases = db.load_golden() # 评测集是业务库视图
results = [run_case(c, version) for c in cases]
report = aggregate(results) # 按类别与难度切片
db.save_report(version, report) # 报告回库，天然可 diff
return report
def gate(report: dict, baseline: dict) -> bool:
return report["pass_rate"] + 0.02 >= baseline["pass_rate"]
但自研的真实成本从来不是这两百行，而是它背后没写的部分：数据集版本管理、评估器自身的回归、报告存储与权限。自研的下限是维护意愿，不是代码量——范围锁死（单一应用、一屏评估器、小团队共享）时它是最优解，范围一旦扩张，欠的账连本带利地还。
工具决定下限，资产决定上限：数据集与评估器是你的，执行器随时可换。
7、选型决策矩阵
把前六节压成打分表。四个维度：团队栈（现有代码离哪家最近）、预算（席位费与 token 费双计）、规模协作（用例数与协作人数）、开源可控（数据能否不出院）。1～5 分，越高越好：
| 工具 | 团队栈 | 预算 | 规模协作 | 开源可控 |
|---|---|---|---|---|
| LangSmith | 5（LangChain 栈）/ 3（其他） | 2 | 5 | 1 |
| Braintrust | 4 | 2 | 5 | 2 |
| DeepEval | 4（Python 测试团队） | 5 | 3 | 5 |
| promptfoo | 5（任意栈） | 5 | 3 | 5 |
| 自研 | 5 | 5 | 2 | 5 |
预算一列要说明：评测跑批的 token 开销无论选谁都要付，真正差的是席位费。自研在规模协作拿 2 分不是做不了，而是权限、通知、报表都要自己造。三档推荐如下：
| 档位 | 特征 | 推荐 |
|---|---|---|
| 起步档 | 个人或双人项目，先跑起来 | promptfoo 加 git 管数据集 |
| 栈绑定档 | LangChain/LangGraph 生产应用 | LangSmith 全家桶，评估器写纯函数 |
| 自主可控档 | 数据不可出院，有平台余力 | Langfuse 自托管加 DeepEval 指标 |
第三档里的 Langfuse 是唯一能自托管的平台级选项：追踪、数据集、实验、评测一个环，MIT 协议，Docker 与 Kubernetes 都能部署。它单独不足以覆盖开发期对拍，所以配 DeepEval 出指标。
8、混合方案配置
真实团队很少单选。最常见的组合是 promptfoo 开发期加 LangSmith 生产期：开发期改 prompt、换模型、矩阵对拍是高频动作，promptfoo 本地零成本；进入生产后重心切到线上追踪与失败样本回流，LangSmith 的闭环成熟。第二种常见组合是 DeepEval 出指标加 Langfuse 自托管做数据与界面——开源需求强、又要平台化界面的团队几乎只有这条路。《上下文工程》第 15 篇的"跑批用 promptfoo、门禁自研"其实是第三种最小混合。
组合能成立的前提只有一条：数据集与评估器独立于工具。这也是本系列第 3 篇坚持本地 jsonl 为事实源、评估器写成纯函数的原因——工具只是执行壳，壳可以换，资产不能动。OpenAI Evals 的关停就是压力测试：它的用户若把数据集与评估器沉淀在平台里，迁移是伤筋动骨；沉淀在 git 里，换壳只是一下午的事。
9、总结
本文先列需求五件套再看工具，因为选型失败的第一原因从来不是工具差，而是需求没想清楚。要点收拢成三句：LangSmith 买的是栈契合与追踪闭环，Braintrust 买的是 EDD 原生体验，DeepEval 与 promptfoo 买的是零成本起步与 CI 原生；自研的分界在维护意愿而非代码量；混合方案成立的前提是数据集与评估器资产化。对于刚起步的团队，建议先用 promptfoo 跑通第一个门禁，栈与规模明确后再决定要不要上平台；对于数据敏感型团队，Langfuse 自托管加 DeepEval 指标是这个时点最稳的开源组合。
留一个练习：挑你手头任意 20 条问答用例，分别用 promptfoo 与 DeepEval 各跑一遍——同模型、同断言语义，记录从安装到出报告的耗时、配置行数与结果呈现差异。做完这题再回头看第 7 节的矩阵，你会给自己的团队打出真实的分。
