核心要点
- 做 agent eval 之前，先人工读 trace、定义成功标准、识别失败原因。
- 评测体系要分清 capability eval 与 regression eval。
- 不要一上来就搞复杂基础设施，先从最小但有信号的 eval 开始。
- 评测需要明确 owner，并先排除数据/基础设施问题，别把一切都怪到 agent 身上。
原文链接 English Original — LangChain Blog, by Victor Moreira
这篇文章是一个非常实用的“开工前清单”。作者的核心态度很明确：Agent eval 不该从搭基础设施开始，而该从理解真实失败开始。 如果团队还没手动读过 20 到 50 条真实 trace，就急着搭数据集、grader 和仪表盘，往往会把复杂度堆在错误的位置。 文中给出的第一批检查项很值得直接抄作业：先人工阅读真实执行轨迹；为某个具体任务定义无歧义的成功标准；把 capability eval（能力评估）和 regression eval（回归评估）分开；确保每个失败都能说清楚为什么失败；给 eval 指定明确 owner；并且在怪罪 agent 前，先排除基础设施和数据链路问题。 这背后体现的是一种“由浅入深”的评测观。作者反复强调，最好的起点是最简单、但确实能提供信号的 eval。几条端到端任务评测，往往比一套宏大的复杂系统更快地暴露核心问题。如果简单方案已经足够说明失败模式，就没必要过早引入更复杂的 grader 或数据管线。 对 agent 团队来说，这篇文章最大的价值在于把 eval 从“测试附属品”提升为“产品工程的判断系统”。没有清晰标准、没有 owner、没有失败归因能力，再多评测也只是热闹。真正有效的 eval 体系，应当服务于定位问题、推动改进和判断能否上线。 所以它不是教你“怎么把 eval 做大”，而是在提醒你：先把 eval 做对。