热门观点：评测（evals）是阻碍公司成为 AI 原生企业的头号因素。

如果你想理解评测，推荐阅读这篇关于评测驱动开发的指南。

感谢 @jake_klaris 推荐这篇精彩文章。https://t.co/U36qDmIss6

你的 AI Agent 真的能用吗？评测驱动开发指南

你可以靠 vibe-code 凑出一个能力尚可的应用，但不能靠 vibe-test 就草草了事。微调提示词、手动试几个输入，只能走到这一步；评测才是让 Agent 准备好上线、并保证上线后持续可用的关键。

团队经常问该用哪个评测工具，好用的确实不少：Langfuse、Braintrust、LangSmith 等等。但没有任何工具能告诉你 Agent 应该做什么——这需要你自己来定义。

这就是评测驱动开发：先定义什么是好的行为，然后用 Agent 对照测试，不断改进直到通过。每一次重要失败都应该变成一个回归测试：每次改动后都重跑一遍的用例，这样你就知道那个问题有没有再出现。

下面我们会梳理所有评测工具共有的四个核心构件，然后把它们组织成一个五步流程，供你在开发新功能或修复线上发现的问题时使用。

刚接触评测，或者自己不负责构建 Agent？先看我们的实战指南：《尽职调查：你的第一次 Agent 评测》。

什么是评测？

评测就是对一条 trace 施加的评分器。

评分器（也叫 evaluator 或 scorer）是任何能给 Agent 表现打分的东西，从简单的代码检查到充当裁判的 LLM 都算。trace 是一次 Agent 运行的完整记录：输入、它执行的每一步，以及输出。

例如，一位客户问：“我的退款到哪了？“Agent 调用 search_orders，然后调用 issue_refund，并回复“退款已发出，3–5 天到账”。这次运行的 trace 如下：

一条 trace 的构成：客户的输入、Agent 的 search_orders 和 issue_refund 工具调用，以及它的最终回复

没有 trace 就很难做评测，所以如果你还没搭建可观测性系统，就从这里开始。

其余一切都是为把 trace 送到评分器面前、并对分数做有用处理而服务的管道：

用例（也叫 dataset item、example 或 test case）。它包含一个你想测试的输入，加上对该输入“好“的定义。用例存放在数据集里。有些用例带有参考答案，有些则只指明用例运行后应应用哪些评分器。

示例：来自客户“我的退款到哪了？“的输入，该客户的订单 #4821 有一笔待处理退款，期望回复为“您订单 #4821 的退款已发起，将在 3–5 个工作日内到账”。

运行（也叫实验）。数据集中的每一个用例，都对你的某个特定版本的提示词或 Agent 执行一遍。每个用例产生一条 trace，每条 trace 都会被评分。一次运行就是一个快照：“版本 X 在数据集 Z 上得了 Y 分。“对比不同运行，就能知道对 Agent 的改动是否真的有帮助。

示例：你的退款数据集中全部 40 个用例，对当前 Agent 执行一遍。如果 v3 通过了 40 个中的 36 个，而一次提示词改动让 v4 通过了 39 个，那就说明改动有效，而且你能精确看到还有哪个用例没通过。

给 Agent 评分的四种方式

评分器分为几类，大多数真实场景会在同一条 trace 上运行多种评分器。以下是如何用它们为上面那条退款 trace 打分：

• **确定性检查。**纯代码，不涉及模型。Agent 是否恰好调用了一次 issue_refund，订单 ID 是否和它查询的一致？重复退款或退错订单会立刻失败。它们成本低、速度快、结果明确，能用就尽量用。

• **参考答案评分器。**将输出与用例上存储的参考答案进行比对，可以精确匹配，也可以由 LLM 裁判检查含义是否一致。用例中存储了“您订单 #4821 的退款已发起，将在 3–5 个工作日内到账“，裁判则检查“退款已发出，3–5 天“是否表达了同样的意思。这类评分器需要预先写好参考答案，而真实流量不会自带答案，所以它们主要用于你编写的测试用例。

• **评分标准评分器（风格、语气、诊断）。**由 LLM 裁判按照标准给输出打分，无需参考答案。回复是否简洁？是否确认了发生了什么？是否告诉用户退款没到账时该怎么做？最后这一条其实会指出我们示例中的问题——这正是要点：评分标准能捕捉参考答案遗漏的问题。由于不需要参考答案，它们适用于任何 trace，包括生产环境的 trace。

• **轨迹评分器。**这类评分器评判 Agent 走过的步骤，而不只是最终答案。它是否在发起退款前先查询了订单？一个不先查订单就调用 issue_refund、或者调用 search_orders 十二次的运行，即使最终回复看起来完美也会失败。它们运行更慢、成本更高，评分器本身也更容易出错。

LLM 裁判本身也需要校验。裁判就是另一个提示词，它也会出错。在信任上面那个评分标准裁判之前，请让一位同事给几十条退款回复标注“通过“或“失败“，然后统计裁判的一致率。如果一致率低，就在它的分数驱动任何决策之前修好评分标准，并且每次修改裁判后重新校验。

订阅 Ultrathink。

互联网上排名第一的应用型 AI 通讯。每周二，40,000 多位高管和构建者会收到一个实战案例拆解，外加本周最优秀的工具、链接和想法。

点击此处订阅。

在线评测和离线评测有什么区别？

主要区别在于被评分的 trace 来自哪里。

• 在线：真实用户或系统已经在生产环境中使用了你的 Agent，所以 trace 已经存在，你只需要给它打分。

• 离线：还没有任何人运行过这个场景，你需要一个测试用例来触发一次运行、产生 trace，然后再给它打分。

无论哪种情况，trace 的外观是一样的。大多数其他差异——比如你能用哪些评分器、你能控制多少——都取决于它的来源。

在线评测监控生产环境。评分器自动对真实 trace 运行，通常会对样本进行抽样以控制 LLM 裁判的成本，它们的职责是暴露糟糕的行为。生产环境通常没有参考答案，所以在线评分依赖确定性检查、评分标准、轨迹评分器，以及用户信号（如点踩或重试）。

离线评测在你的实验室里运行：按需或在 CI 中，在任何东西发布之前。它们的职责是测试预期行为，让你能安全地迭代修复。作为编写用例的领域专家，你可以附加参考答案。

两种评测都需要。只有在线没有离线，你能看到问题却无法安全修复；只有离线没有在线，你测试的是你想象中的场景，而不是用户实际产生的场景。

把两者连接起来的是提升（promotion）：把一条糟糕的生产 trace 转化为一个离线用例。

什么是评测驱动开发？

评测驱动开发就是 Agent 行为的测试驱动开发。在你改动提示词、指令或技能定义之前，先写下什么是“正确“，然后运行 Agent，不断迭代，直到 Agent 表现正确。

用例和“正确“的定义来自以下两个来源之一：

• 主动式：在构建之前就定义好行为。这也是在还没有生产流量时开始的方法：为你想要的行为编写用例，也为那些你认为已经存在的行为编写用例。

示例：当客户询问待处理的退款时，Agent 应该查询订单、发起退款，并告知客户预计到账时间。

• 被动式：在线评分器或用户标记了生产环境中的一条糟糕 trace，你把它提升为一个用例。

示例：一位真实客户询问退款进度，Agent 却说帮不了。你把这条 trace 提升为一个相同输入的用例，并定义正确行为：查询订单、发起退款，并告知客户预计到账时间。

无论哪种方式，你最终都要定义一个行为。之后的循环流程是一样的。

• 定义用例及其通过标准。写入输入并附加评分器。参考答案评分器需要参考答案；评分标准评分器只需要它的评判标准。

• 运行它，看着它失败。如果你还没做任何改动它就通过了，那要么这个行为本来就有效，要么这个用例测的不是你以为的东西。对于提升的 trace，这一步还能确认你能在线下复现这个失败。

• 修改 Agent。提示词、模型、指令、工具描述、技能。

• 再次运行。重复第 3、4 步，直到通过。

• 运行整个数据集，而不只是这个用例，以防出现回归。

提前决定什么算通过。同一个输入可能这次通过、下次失败（谢谢了，非确定性的 LLM！），所以一次绿色勾号证明不了什么。把每个用例运行多次（k 次），并明确设定标准：对于一次失败都不可接受的高风险行为，用“全部通过“标准——比如给别人的订单发起退款（通过 k 次中的 k 次不能证明它不会发生，但失败一次就证明了它可能会发生）；对于可接受一定波动的情况，用“n 次通过“标准，比如 3 次通过 2 次。

把一次生产失败转化为用例

提升是在线与离线评测之间的桥梁。调出被标记的 trace（如果没有 trace 和在线评测，你很难发现这些问题！），把它输入复制到一个新用例中。然后写下什么算好的输出。那个糟糕的输出显然不能当你的参考答案，所以必须有人提供正确的答案。

提升的 trace 是真实的用户数据，所以在它进入全团队可读的数据集之前，务必脱敏处理。

让用例易于编写

每个评测系统或服务商创建用例和数据集的方式都不同：JSON、CSV、通过 UI 等等。帮自己和团队一个忙，创建一个能基于自然语言轻松为你生成用例的技能。你应该能对 Claude 或 Codex 说以下任意一句话，然后拿到对应服务商格式的数据集：

• “创建一个用例：客户要求对超过 90 天的订单退款。Agent 应该解释退款时限，并且不应该调用 issue_refund。”（主动式用例）

• “根据生产 trace 创建用例：{flagged_trace_id}。Agent 说帮不了；它本应该查询订单、发起退款，并告知客户预计到账时间。”（被动式用例）

构建回归测试集

评测驱动开发循环的第 5 步是运行整个数据集，因为一次修复某个用例的提示词改动可能会悄悄破坏其他用例。如果你只重跑你正在修复的那个用例，是看不到的。

每一次有实质意义的改动都运行整个数据集，最好在 CI 中进行，并与上一次运行结果对比。随着时间推移，你提升的每一个生产事故都会变成一个永久性测试。你的数据集会变成一份记录——记录 Agent 曾经失败过的所有方式——并成为一道防止这些问题卷土重来的检查。

综合起来：在线评测发现问题，提升把问题变成用例，循环在线下修复它，不断增长的数据集确保它一直被修复。

刚起步的团队需要了解的事

• 定义什么是好的行为才是真正的核心工作。先在构建之前写下预期行为，包括那些你认为已经有效的行为。这样做的时候，你通常会发现其中一些并没有你以为的那样有效。

• 让创建用例变得几乎毫不费力。如果把生产失败转化为用例需要点好几个页面、手写 JSON，人们就会跳过这一步，数据集也就不会继续增长。给你的团队提供：一键提升 trace、一个输入框写预期行为，以及上面提到的那样一个用例编写技能。

• 从一开始就对执行路径打分。一个 Agent 花 30 轮对话才能完成一次精心选择的工具调用就能搞定的事，可能依然给出完美的答案，而只看输出的评分器永远不会标记它。至少添加一条轨迹检查。

四大平台速览

有了这个模型，各大平台看起来就相似多了。它们在不同的名字下构建同样的构件：

• LangSmith：用例是 examples，评分器是 evaluators，运行是 experiments。在线 evaluators 通过规则对生产 trace 运行，失败的 trace 可以直接添加到数据集。

• Langfuse：用例是 dataset items，评分器结果是 scores，运行是 experiments（原 dataset runs）。LLM-as-a-judge evaluators 可以对实时 trace 打分，生产 trace 可以直接添加到数据集。

• Braintrust：用例是 records，评分器是 scorers，运行是 experiments，生产 trace 是 logs。在线评分规则通过抽样和过滤器对 logs 打分，已记录的 trace 可以直接提升到数据集。

• Arize（AX 和开源 Phoenix）：用例是 examples，评分器是 evaluators，运行是 experiments。生产 spans 可以直接添加到数据集。

所有平台都以某种形式支持提升，因为从生产环境回到你的数据集的路径是任何评测体系的核心。

这个领域的命名变化很快，在采用之前请先查看每个工具的最新文档。

下期预告：当无法复现 trace 时

整个模型都假设你可以在线下复现 trace。对于简单的提示词，你可以：把输入复制到用例中运行即可。但对于需要读写真实系统的 Agent，你往往做不到。这就是真实世界 Agent 的评测体系变难的地方，也是本系列接下来两篇的内容。

**第二篇：重放世界的状态。**你的 Agent 的行为取决于它的工具在那一刻返回了什么。当那条退款 trace 运行时，search_orders 返回订单 #4821 的退款处理中。一周后重跑同样的输入，退款已经完成了，所以 Agent 会走另一条路径，你提升的那条 trace 就无法复现了。

**第三篇：在离线运行中拦截写操作。**issue_refund 涉及真实的资金。你希望离线评估 Agent 处理退款的能力，而不是每次 CI 运行时都给真实订单退款。

**阅读我们的完整评测指南：**https://www.tenex.co/blog/eval-driven-development?utm_source=x&utm_medium=social&utm_campaign=evalguide