Agent Evals 相关的核心要点是什么？

本文围绕 Agent Evals、LangSmith、LangChain、LLM-as-a-Judge、Benchmark 展开，LangChain 团队回答了 Agent Evals 最常见的那些问题：从怎么起步、离线与在线评估、LLM 评审是否可信，到基准测试、成本控制与多轮对话评估。。详细解读见正文。

Agent Evals 常见问题全解：从起步到基准测试

2026-10-15T23:58:00+08:00

Agent EvalsLangSmithLangChainLLM-as-a-JudgeBenchmark

Agent 每次运行输出都可能不一样，正确答案也不止一个，甚至可能从"错误"的路径得出正确结果——传统单元测试在这里不够用。

要点速览

Evals 给 agent 的每次运行打分，用来确认它是否按你预期的方式行为。 起步时先挑一个行为，从真实 trace 建一个小数据集，跑一条基线。上线前用离线评估（offline evals），生产环境用在线评估（online evals），把新出现的失败转成数据集样本。
能用代码评估的地方就用代码，不能的地方用 LLM 评审，再用人工复核这两者。 对多步执行的 agent，要评估完整对话线程、执行轨迹和最终状态。
Terminal-Bench 这类 benchmark，是"任务更长、自带环境"的离线评估。 Harbor 负责运行它们，并把结果记录到 LangSmith experiment。

提纲

从哪里开始
离线评估和在线评估有什么区别
Agent 评估器有哪几类
LLM 评审可信吗
Eval 和 benchmark 是一回事吗
如何低成本评估生产流量
一定要自己从零写 eval 吗
怎么评估多轮对话
除了最终输出，还能评估 agent 的什么
不用 LangChain 构建的 agent 也能在 LangSmith 里评估吗
如何从现有 eval 体系迁移过来
结果怎么看、怎么汇报

在开发和上线一个 agent 的过程中，你都需要一种办法来确认它是否按你预期的方式行为——不光是在开发阶段，也包括真实用户开始依赖它之后。

在传统软件里，同样的输入产生同样的输出，所以一个单元测试就能检查出精确结果。Agent 更难测，原因有几条：

每次运行的输出都可能不同，哪怕请求完全一样
正确答案不止一个，所以检查精确匹配并不好使
步骤由 agent 自己决定，因此一个正确的输出也可能来自一条"错误"的路径。比如 agent 可能调用了一个它并不需要的工具，或者在没有用户许可的情况下执行了某个动作。

Agent evals 就是解法。它用能够容纳这些变化的检查，给你的 agent 运行打分。和它所评估的 agent 一样，这些测试不是一刀切的：最好的 eval 套件取决于团队、产品，以及你想优化的目标。

过去几年在做 LangSmith（LangChain 的 agent 工程平台）的过程中，我们团队遇到过非常多形形色色的 eval 问题。这篇文章梳理其中最常见的那些：如何上手 agent evals，以及你在工作流里可以用到的各类 eval。

从哪里开始

每一个 eval 都始于搞清楚你的 agent 到底在做什么。一条 trace 是你的 agent 一次运行的完整记录，包含它的输入、输出，以及中间每一次模型调用和工具调用。抽一批 trace 读一读，看它怎么处理请求、在哪里出错。你读到的结论，决定了先测什么。从小处开始。

挑一个你在意的行为。 比如对一个旅行助手，一个行为可以是：它是否按用户要求的日期和价格区间下单。
从 trace 里建一个小数据集。 数据集是一组样本的集合，每个样本是一条测试用例，包含一个输入，通常还有一个期望输出。一个行为有十到二十条样本就足够起步，在 LangSmith 里可以直接从 tracing 视图把 trace 加进数据集。如果 agent 还没上线，就让团队或一小群可信的设计伙伴先用起来（dogfooding），再从这些 trace 入手。
跑一条基线。 用当前版本的 agent 在数据集上跑一遍，把结果存为一个 experiment。一个 experiment 包含某个版本的 agent 在一个数据集上的运行结果，以及各个 evaluator 给出的分数。以后版本的性能就和这个 experiment 比。
发现新失败就补进去。 你在生产或测试里看到的每一次失败，都变成一条新样本。

价格是对的，但 agent 查错了日期。这条 trace 就会变成数据集里的一个新样本。

不断往数据集里补失败样本，你就有了一个改进循环：发现失败 → 加进数据集 → 改进 agent → 重跑。当你识别出更多需要评估的行为时，按同样的模式扩展 eval 套件即可。

离线评估和在线评估有什么区别

Eval 既应该在发布改动前跑，也应该在 agent 上线后跑。发布前，eval 告诉你这次改动让 agent 变好了还是变差了；上线后，eval 告诉你 agent 在真实用户面前表现如何。

离线评估（offline evals） 在发布改动之前，让你的 agent 跑一个数据集。样本输入由你选定，你也可以带上期望输出（也叫参考输出）。用数据集，你可以在不同 agent 版本之间比较 experiment 结果。它最适合测新的 prompt、模型或工具，并在问题到达用户之前拦住回退。

Terminal-Bench 这类 benchmark 也是离线评估，它建立在一组固定任务上，方便你比较 agent、模型或版本。Harbor 负责运行它们，并把结果记录到 LangSmith experiment，下文会细讲。

在线评估（online evals） 在真实生产 trace 进来时就给它们打分。这时通常没有参考输出可比对，所以它依赖代码检查和能独立给一次运行打分的 LLM 评审。它最适合监控质量，找出数据集漏掉的问题。

两者都需要，而且互相喂养。在线评估标出的失败，会变成离线数据集里的新样本。

旅行助手的离线评估与在线评估示例。

在 LangSmith 里为离线评估构建数据集有几种方式：你可以从零写样本，从已有 trace 里加运行，把团队在 annotation queue 里审过的运行送进来，上传 CSV 或 JSONL 文件，或者基于已有的少量样本生成合成样本。

随着 eval 套件变大，你要决定是把样本加进已有数据集，还是新建一个。经验法则是：

当样本用同一批 evaluator 测同一个行为时，留在同一个数据集里，这样 experiment 随时间仍可比较。
当输入形态不同（比如单次请求 vs 完整对话）、需要不同的 evaluator，或者数据集服务于不同目的时，就新建数据集——例如一个每次 pull request 都跑的小集合，对比发布前才跑的更大集合。

在单个数据集内部，你还可以用 split 只跑其中一部分样本。

Agent 评估器有哪几类

Evaluator 就是给一次运行打分的逻辑。常见的有四类，多数团队从一两类起步，再逐步补齐。

代码评估器（Code evaluators） 用确定性的方式检查，比如成交价是否在用户预算内。它快、便宜、一致，但因为要求输入输出可确定，适用面受限。
LLM-as-a-judge（LLM 评审） 用一个模型去评判代码判不了的东西，比如助手的回复是否清楚确认了航班信息。
人工评审（Human review） 让你的团队或领域专家直接给运行打分。它更慢，但对主观质量、以及校验其他 evaluator 来说是最好的信号。通常只在较小样本上做，再用它来指导 LLM 评估器的判断。
成对评估器（Pairwise evaluators） 把两个输出并排放，挑更好的那个。在两条 prompt 或两个模型之间抉择时很有用。

不同 evaluator 选择下，你可能会问不同的问题。

上面这些 evaluator 都可以指向 agent 运行的不同部位。一次 eval 可以评估：

单个步骤。 例如 search_flights 是否用了正确的日期调用。
最终回复。 例如回复是否确认了 agent 实际下单的那个航班。
完整对话。 例如最终订单是否反映了用户在多轮中提出的每一次修改。
环境的最终状态。 例如 agent 在自己的容器里跑完后，模拟订票系统里的订票记录。benchmark 常用这种设置，你有时也会听到它被叫作容器化 eval（containerized evals）。

LLM 评审可信吗

LLM 评审用模型给那些代码难以检查的输出打分，比如答案是否有检索到的文档支撑。评审很灵活，但可能不一致，也可能偏离你团队的判断。有几个习惯能让它可靠：

拿评审结果和人工打分对比。 让团队里某人给一批运行打分，看评审在哪里不一致，调整评审的 prompt 或示例直到两者对齐。LangSmith 的 annotation queue 让这件事很容易，我们的 LLM-as-a-judge 文档也给了完整步骤。
问窄问题。 在上面旅行助手的例子里，"回复是否提到了每一次中转"比"这是一个好回复吗"好判得多。
定义精确的评分刻度。 二元的通过/不通过，或一小组带标签的类别，比 1–10 分制可复现得多。评审往往分不清 6 分和 7 分的区别。

对比：一个 1–10 分制的评估器（描述含糊、波动大）与一组二元评估器。

Eval 和 benchmark 是一回事吗

Benchmark 是一种由一组任务组成的离线评估。一个 task 是 benchmark 里的一条测试用例，包含说明、一个容器里的环境，以及一个给结果打分的测试脚本。随着 agent 能力变强，单靠一个 LLM 评审或基于代码的 eval 常常不够。agent 现在能执行代码、编辑文件、对接服务。为了刻画这种多步行为，benchmark 会拉起容器里的隔离基础设施，让开发者能像在生产里那样、离线地测试 agent 行为。

Benchmark 与更简单的 LLM 评审、代码 eval 的区别：

任务包含更多步骤。 完成单个任务，agent 可能要装包、改文件、跑命令，横跨几十次工具调用。
每个任务自带环境。 agent 现在能在沙箱这类带有代码仓库、文件和工具的环境里行动。每个任务都配一套自己的隔离环境供 agent 工作。
评分检查的是 agent 做了什么。 测试脚本会检查运行后环境的状态，比如测试是否通过、目标文件是否存在。你仍然可以看 trace，但分数来自 agent 采取的动作和它留下的状态。

对我们那个旅行助手，一个 benchmark 任务可能是：给它一个模拟订票系统，外加一句请求——"一场风暴取消了旅客飞往丹佛的航班。为他改签，并把酒店一起挪过去。" agent 完成后，测试脚本会去数据库里检查订票记录。

每个 benchmark 任务自带环境。测试脚本检查 agent 留下的状态，Harbor 把所有任务的结果记到一个 LangSmith experiment。

Harbor 是一个开源 eval harness，为这类长任务测试提供脚手架。它也是支撑 Terminal-Bench 的框架，你可以用同一套任务格式给自己的 agent 建 benchmark。借助 LangSmith 集成，每次 Harbor 运行都会记为一个 LangSmith experiment。Harbor 为每个任务构建一个容器，你也可以用 LangSmith trace 让每个环境更接近 agent 在生产里看到的样子。benchmark 结果会和其余 eval 并列在一起，你可以打开任意一次运行，在旁边看到完整 trace 和它的分数。

我们正是用这套设定在 Terminal-Bench 2.0 上改进 Deep Agents：通过审阅 trace 找出失败模式，再改 harness。我们也用它构建了 IssueBench，一个面向 LangSmith Engine 的 benchmark。IssueBench 的每个任务给 Engine 一批 trace，评估它是否把正确的那些归到对的 issue 簇里。

给自己的 agent 建 benchmark，步骤和上面的 eval 一样，只有几处不同：

从 trace 里收集任务。 在 LangSmith trace 里找到失败，把每一个变成一个带自己环境的 Harbor 任务，比如一个填好某用户预订信息的模拟订票系统。
定义什么算"好"。 按你的评分标准，写 LLM 评审或基于代码的 eval。
在分数上爬山。 跑 agent，用分数来 A/B 测试改动。你可以搭一个 agent 循环替你跑这个流程：它修改你的 agent、重跑 benchmark，保留或回退每一次改动——类似 Andrej Karpathy 几个月前的 autoresearch 循环。

如何低成本评估生产流量

离线评估跑在固定数据集上，成本可预测。在线评估跑在实时流量上，如果 LLM 评审给每条 trace 都打分，eval 成本会随每个新用户增长。让它保持可负担：

采样和过滤。 LangSmith 里的在线评估器可以只给一定比例的流量打分，或只给命中某种过滤条件的 trace 打分，比如用户给了负面反馈的。
能上代码检查就上。 检查订票日期是否符合请求、agent 是否先搜索再下单，几乎不花钱。
用更便宜的评审。 在我们的 Jev-as-a-Judge 实验里，TypeSafe AI 的 Jev 在每一个通过/不通过判断上都和人工标签一致，总共只花了 0.34 美元，而 Claude Sonnet 4.6 是 28.17 美元。

在线评估的成本会随时间保存在 LangSmith 中，团队可以监控自己的开销。

按评估器拆分的在线评估成本随时间变化。

一定要自己从零写 eval 吗

不必，尤其是当你评估的是常见的 agent 问题时。一个不错的起点是 LangSmith 里预置的 LLM evaluator 模板，覆盖幻觉、PII 泄露这类典型检查。把它加到数据集或 tracing 项目里，改一改 prompt 让它贴合你的 agent——比如告诉评审，我们的旅行助手绝不能在用户预算之外下单。

我们的开源 agentevals 包也有针对 agent 消息和工具调用的预置评估器。它们可以把 agent 调用过的工具和一个参考列表对比，或者让 LLM 评审判断这些步骤是否合理。

你也可以把一个离线评估器跨数据集复用，并把它当作在线评估器跑在生产 trace 上（前提是该评估器不需要参考输出）。

针对你自己 agent 的 eval，Eval Engineering Skill 能在 Claude Code 或 Codex 这类编码 agent 里运行，读你的仓库和 trace，和你一起写出可运行的 eval。LangSmith Engine 也能自动从生产 trace 里为你写 eval：当它识别出一个 issue 簇，就把失败的 trace 变成数据集样本，并写出对应的参考输出作为 assertion，比如"按用户要求的日期订机票"。

怎么评估多轮对话

很多 agent 要跨多轮工作。比如用户先向旅行助手问航班，改了日期，又加了酒店。单独看每一轮可能都正常，整段对话却出了错。

在 LangSmith 里评估对话，要在 trace metadata 里带上 thread ID，让每一轮归入同一个 thread。thread 是同一段对话里一系列 trace 的序列。这样你可以挂上在线评估器，在对话结束后给整个 thread 打分，问题比如"最终订单是否反映了用户提出的每一次修改""用户是否不得不重复自己"。LangSmith 还会把每个 thread 显示为一条 trajectory，把每条消息和工具调用按顺序列一次。

对离线评估，你可以把完整对话作为样本存进数据集，或者用 LLM 模拟用户，从头到尾测试 agent 如何应对一段对话。

每一轮单看都合理，问题只在整条 thread 上才显现。

除了最终输出，还能评估 agent 的什么

Agent 要走上很多步，所以最终答案只反映了发生的事的一部分。除了最终回复，你可能还想检查：

路径，即 agent 产生的消息与工具调用的序列。
最终状态，比如旅行助手创建的订票记录、它写下的文件，或它对仓库做的一次改动。

随着生产环境里的 agent 越来越复杂，你可能需要一个专门的 eval harness——尤其是当 agent 的"工作成果"就是它对环境做出的改动时。比如一个编码 agent 被要求修一个 bug。LLM 评审能读它的回复，但可靠的检查是在它完成后跑仓库的测试。要做到这一点，每次测试运行都需要一份干净的仓库副本，避免互相影响。Harbor 会替你搭好这套东西。你可以在 LangSmith Sandboxes 里运行用 Deep Agents 构建的 agent，并把每次运行连同它的 trace 记录到 LangSmith experiment，细节见 Harbor x LangChain。

不用 LangChain 构建的 agent 也能在 LangSmith 里评估吗

可以。LangSmith 与框架无关，用任何框架、甚至不用框架构建的 agent 都能 tracing 和评估。发送 trace 有几种方式：

框架集成。 LangSmith 对主流 agent 框架有集成，比如 OpenAI Agents SDK、Claude Agent SDK 等。
模型供应商包装器。 如果你直接调用模型供应商，包一层 OpenAI 或 Anthropic 的客户端，每次模型调用都会被 tracing。
@traceable 装饰器。 加到你自己的函数上，比如旅行助手的航班搜索工具，就能 tracing agent 的任意一步。

一旦 trace 进了 LangSmith，无论是哪个框架，eval 的用法都一样。你可以把 trace 加进数据集，把 agent 传给 SDK 的 evaluate() 函数跑离线实验，也给生产流量挂上在线评估器。

如何从现有 eval 体系迁移过来

你不必从头来过。你已经搭好的大部分东西都能带到 LangSmith：

数据集。 把已有测试用例以 CSV 或 JSONL 上传，或用 SDK 创建。
代码评估器。 已有的打分函数通常只需小改就能作为 LangSmith evaluator 运行。如果你的 eval 本来就以测试形式运行，pytest 和 Vitest 集成让你保留原有设置。
LLM 评审。 把现有评审 prompt 粘进 UI 里的 LLM-as-a-judge evaluator，或留在代码里。
Tracing。 LangSmith 与任何框架兼容，所以你不用重写现有 agent 就能发 trace。

结果怎么看、怎么汇报

离线实验显示每个版本是否变得更好了。在线评估看板显示性能在生产里随时间如何保持。在 LangSmith 里，你可以直接比较 experiment 结果，并针对 token 成本、延迟、评估器分数随时间变化这类指标建自定义看板。Benchmark 给你一个稳定的分数，用来跨版本比较模型或 agent。

延伸阅读

想深入下去，可以读 LangChain 的《How We Build Evals for Deep Agents》，试试 LangSmith 的评估快速上手，或者看 LangChain Academy 上的 LangSmith Essentials 课程。想听真人讲的话，作者会在 2026 年 10 月 28 日主持一场关于 agent evals 的线上工作坊，报名入口见原文。

参考链接

作者: itech001 来源: 公众号：AI人工智能时代(the-ai-era) 网站: https://www.theaiera.top/ 关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top

本文首发于 AI人工智能时代，转载请注明出处。