LangChain 团队以 Q&A 形式分享 Agent Evals 常见问题实践指南

Agent Evals 最常见的问题都有什么？

@LangChain 团队 @divyasan0 以 Q&A 形式分享了 Agent Evals 实践指南，把常见问题一次性回答了。她给出的可落地工程流程：从真实 trace 起步、小数据集建立基线、失败案例回流迭代、离线/在线分层评估、代码优先于 LLM 裁判、benchmark 用容器化环境验证最终状态。

QA 博客地址：
https://www.langchain.com/blog/common-questions-about-agent-evals

为什么 Agent 难以测试 ？
· 输出不确定性：同一输入，多次运行结果不同；
· 答案非唯一：多个不同回答都可能是正确的，无法做字符串精确匹配；
· 路径自选：Agent 自己决定执行步骤，即使最终答案正确，路径也可能是“错的”（调用了不必要的工具、未经授权就行动）。

起点：从 trace 开始的最小闭环
一条清晰路径值得直接采纳：
读一批真实 trace → 选定一个行为 → 建 10–20 条小数据集 → 跑基线实验 → 之后所有改动都与基线对比。

其中最有价值的工程习惯是失败回流机制：发现一次失败 → 作为新样本加入数据集 → 改进 agent → 重跑全量。这让数据集随系统演化而增长，评估从“一次性验证”变成“持续改进的飞轮”。未上线的团队可以用内部 dogfooding 产生 trace。

离线 vs 在线：两道互补的闸门
· 离线评估（Offline）：发生在发布前、对数据集、用来测新 prompt/模型/工具防回归
· 在线评估（Online）：发生在生产环境、对真实流量 trace、用来持续监控线上质量

两者形成闭环：线上标出的失败，转化为线下的新样本。数据集组织原则也很实用，同一行为、同一组评估器的样本放一起；输入、评估器或目的不同就另建数据集，避免一个大盘子什么都装。

评估器的优先级：代码 > LLM 裁判 > 人工
· 代码评估器：确定性检查（如“价格是否低于预算”），快、便宜、零歧义，能用则必用；
· LLM-as-a-judge：处理代码判不了的主观维度（如“回复是否清晰确认了航班信息”）；
· 人工审核：最贵但最可靠的信号，用于抽样校准前两者；
· Pairwise（成对比较）：让裁判二选一，比绝对打分更稳定。

评估对象的颗粒度也分层：单步 → 最终回复 → 完整对话 → 环境终态（如容器内记录、文件、测试是否通过）。

LLM 裁判能否信任：三条可操作建议
1. 用人工标注对照校准，调整裁判 prompt 直到两者对齐；
2. 问窄问题，“回复是否提到了每一个中转站？”远好于“这是个好回复吗？”；
3. 用二元判定或分类标签，避免 1–10 打分（数值打分的跨 run 一致性很差）。

Eval ≠ Benchmark：一个重要的概念澄清
Benchmark 本质是 “重型离线 eval”，其特殊性在于：
· 任务长链路，涉及数十次工具调用；
· 每个任务自带独立的容器化隔离环境；
· 评分方式是检查运行后的环境状态（订票记录是否存在、代码测试是否通过），而非比对文本。

文中介绍了开源评估 harness Harbor（Terminal-Bench 的底层引擎），每个任务构建一个容器，结果记录到 LangSmith 实验。自建 benchmark 的路径：从 trace 收集任务 → 定义评分规则 → 对分数做 hill climbing（爬山式迭代优化），甚至可以做成 Karpathy 式的自动化研究循环。

线上评估的成本控制
生产流量全量打分不现实，博客给出三层降本：
1. 采样与过滤：只评估有负反馈的 trace；
2. 代码检查优先：几乎零成本；
3. 换更便宜的裁判模型：小模型裁判在 pass/fail 判定上与人类标注一致，总成本 $0.34 vs Claude Sonnet 4.6 的 $28.17（约 1/83）。对二元判定类任务，裁判模型确实不必用旗舰模型。

不必从零自建
生态已提供相当多现成件：针对幻觉、PII 泄露等常见问题的预置 LLM 评估器模板、开源 agentevals 包（针对消息和工具调用）、可从代码仓库和 trace 直接生成可运行评估的 Eval Engineering Skill、从 issue 聚类自动生成数据集和断言的 LangSmith Engine。且整个体系框架无关；支持 OpenAI Agents SDK、Claude Agent SDK，或用 @ traceable 装饰器裸接。

迁移也不必推倒重来：数据集以 CSV/JSONL 导入，pytest/Vitest 集成保留现有测试体系，已有裁判 prompt 直接粘贴复用。

两个进阶难题
多轮对话：每一轮都看似正常、整体却失败的“累积性失败”是单点评估的盲区。解法是给 trace 附上 thread ID 将各轮聚合，再挂载面向整段对话的在线评估器（如“用户是否被迫重复了自己的需求”）；离线侧则把完整对话存为样本，或用 LLM 模拟用户。

超越最终输出：复杂 agent 需要检查轨迹（消息/工具调用序列）与终态（仓库变更、测试结果）。例如编码 agent 跑完后直接在其工作环境里执行该 repo 的测试套件；这正是 Harbor + 容器化沙箱的设计动机。