Agent 评估最常见的问题，LangChain 给出了系统性解答

Agent 评估的本质是为 Agent 的每次运行打分，以验证其行为是否符合预期。传统软件测试依赖确定性输入输出，单元测试可以精确比对结果。但 Agent 面临三重挑战：同一请求的输出可能因运行而异；多个答案都可能正确，精确匹配失去意义；Agent 自主决定执行步骤，正确的最终输出也可能来自错误的路径，例如调用了不必要的工具或未经用户授权就执行了某项操作。评估体系需要针对这些变化设计相应的评分机制。

入门的关键是从小处着手。首先通读一批 Agent 运行的 Trace 记录，了解它在哪些场景下出错。然后选定一个具体行为作为评估目标，例如旅行助手是否按用户要求预订了正确的日期和价格区间。基于 Trace 构建一个包含 10 到 20 个样本的小型数据集，在 LangSmith 中可以直接从 Trace 视图将记录添加到数据集。随后对当前版本的 Agent 运行基线实验，保存结果作为后续版本对比的参照。每发现一个新的失败案例，就将其加入数据集，形成「发现失败—加入数据集—改进 Agent—重新运行」的持续改进闭环。

离线评估与在线评估各有侧重，两者需要协同运作。离线评估在发布变更前运行，使用预先准备好的数据集（可包含参考输出），用于测试新提示词、新模型或新工具，并在变更上线前捕获回归问题。Terminal-Bench 等基准测试本质上也是离线评估，基于固定任务集对不同 Agent 版本进行横向比较，Harbor 负责运行这些基准并将结果记录到 LangSmith 实验中。在线评估则对生产环境中的真实 Trace 实时打分，通常没有参考输出可供比对，主要依赖代码检查和 LLM 评判器。两者形成闭环：在线评估发现的失败案例会补充进离线数据集。

评估器的选择直接影响评估质量与成本。代码评估器以确定性方式检查可量化的指标，例如预订价格是否在用户预算内，速度快、成本低、结果一致，但只适用于输出可结构化判断的场景。LLM 评判器（LLM-as-a-judge）用模型来评分代码无法处理的内容，例如助手的回复是否清晰确认了航班细节，适合主观性较强的质量判断。人工审核由团队成员或领域专家直接对运行结果评分，速度最慢但信号最可靠，通常用于小样本抽查，同时也用于校准 LLM 评判器的判断标准。成对比较评估器则将两个输出并排对比，适合在模型或提示词版本之间做相对优劣判断。

对于需要多步骤执行的复杂 Agent，评估维度需要从单次输出扩展到完整的执行轨迹。完整对话线程的评估关注多轮交互的整体连贯性；轨迹评估检查 Agent 是否按合理路径执行，例如是否调用了不必要的工具；最终状态评估则验证任务完成后系统状态是否符合预期。随着评估套件的扩展，数据集的管理策略同样重要：测试相同行为、使用相同评估器的样本应保留在同一数据集中以保证实验可比性；输入形式不同、评估器不同或服务于不同目的的场景则应创建独立数据集，并可在单一数据集内使用分片机制运行部分样本子集。

要点

• 从单一行为和 10 到 20 个样本的小型数据集起步，运行基线实验后持续将生产失败案例转化为新测试样本，形成闭环改进机制
• 离线评估用于发布前的回归检测，在线评估用于生产环境的质量监控，两者相互补充且在线发现的失败案例应持续回流至离线数据集
• 优先使用代码评估器处理可量化指标，对主观质量使用 LLM 评判器，并用人工审核对两者进行校准和抽查
• 多步骤 Agent 需同时评估完整对话线程、执行轨迹和最终状态，而非仅关注单次输出结果
• Terminal-Bench 等基准测试可通过 Harbor 运行并将结果同步至 LangSmith，为不同 Agent 版本提供标准化的横向比较基准