当你盯着周五下午那串微微上扬的基准测试分数，觉得智能体又聪明了一点时，真实流量的错误日志里，它可能正在重复犯同一个愚蠢错误。关于AI智能体测试该怎么搞，LangChain最近用一项新技能给出了明确方向：别再围着benchmark打转，把注意力转向真实运行的失败痕迹。

LangChain 推出的 Eval Engineering Skill，工作流不再是跑一跑评分、拍个排行榜。它会直接读仓库代码，检查智能体的输出，解析记录下来的完整追踪链，还会“采访”当时执行任务的人类操作者，最后生成的不是一个对质量的“意见”，而是一个系统能直接执行的任务——所谓的 Harbor evals。整个过程，智能体不再只是干活的，它开始帮忙改进下一次运行要用到的引擎。

打开网易新闻 查看精彩图片

这意味着测试用例的形态在变。团队想要的不再是截图、仪表板页面或者Slack里一群人赞同“咱们盯着看”的聊天记录。他们需要的是：把真实流量中那条搞砸的追踪记录，原封不动地转成一个可复现的测试用例。一个测试用例，仅此而已。

作者在几个月前就写过，从智能体在线行为里收集到的追踪，只有在某个具体的人完成“从观察到失败到修改测试套件”的闭环之后，才能真正成为改写测试框架的基础。这跟单纯的追踪存储完全是两回事——后者像一个精美的博物馆，陈列着智能体各种古怪行为，做巡展挺好，但拿来做测试套件就很糟糕。

智能体评估长期背负了过重的“情感分量”。模型评分和人工评分（行话里叫“裁判”）天然会给出一个简单数字，在此基础上，再用基准测试集跑出几个点几的差异，所有人就假装这个分数能以一种简单直接的方式对应智能体在真实流量下的实际行为。实际情况却完全不是这样。

真实流量里的失败有名有姓：智能体选错了工具。检索器把过时的政策文本传给了智能体。子智能体把误差算错了。工作流没能按设计拉入必须参与的人类审批环节。智能体在超时后还尝试写入，结果产生了重复操作的副作用。这些问题，基准测试分数一个都说不清楚，但追踪记录可以——它会告诉你什么环节挂了，为什么挂。

这个区别之所以关键，在于故障的“归属权”从故障模式本身开始。LangChain的IssueBench在介绍中就描述了这样的流程：Engine会批量处理追踪记录，把干净运行和有问题的运行分开，然后将有问题的运行按类别归类，把对应追踪附加到已有的工程问题卡片上，或者为新发现的故障创建新的卡片。这样一来，追踪记录这堆初始素材就被转化成了一条可执行的工程工作流。

这对智能体工程来说，是个更健康的方向。产物必须能被路由：一次幻觉、一次无声的工具调用错误、一个缺失的功能、一条糟糕的恢复路径，它们应该分属不同的负责人。如果评估系统不能保留下这种归属关系，整个团队面对的就不再是明确的工程任务，而是一堆毫无头绪的噪音。

当智能体的性能指标在基准测试里蹿升，而线上流量依然混乱时，那个提升的分数没有任何意义。反过来，分数也不会告诉你到底是什么坏了。但追踪记录会。改进的方向，就藏在这些真实失败里。