AI Agent生产级评估实战：从追踪到自动化闭环

为什么你的Agent上线后总是「翻车」？

很多团队发布AI功能的方式令人心惊：构建、跑几个查询、问一句「这看起来对吗？」、然后上线。问题在于，你只测了三次，而三次不构成测试套件。当Agent面对没见过的输入时，失败必然发生。

更麻烦的是，Agent比普通LLM应用更难评估。单次调用是「输入→输出」，而Agent会进行一系列工具调用和决策，链条中每一步都可能出错，还必须判断中间步骤是否正确。多智能体系统更甚，任务交接、路由、专家处理，每一层都新增出错方式。

这就是评估（Evals）存在的意义：它是给AI做的「单元测试」，而追踪（Tracing）是AI的「日志」。追踪告诉你发生了什么，评估告诉你效果好不好。没有这套基础设施，你就是在凭感觉飞行。实践者总结出一条路径：先靠感觉发布，发现无法规模化，然后才开始建立评估。

评估体系的两大支柱：代码评估与LLM评判

代码评估是确定性函数，不调用模型、不花钱、瞬间完成。检查输出是否为合法JSON、是否少于500 token、是否包含指定股票代码——这些不需要LLM。它的优势是快速、廉价、完全可重复；缺点是灵活性有限，两个措辞不同但都正确的答案可能被误判。因此需要调整对「单元测试」的预期。

LLM作为评判者则灵活得多，能理解语义：回答是否忠实于原文？语气对吗？但运行需要花钱，且本身是非确定性的，可能出错，需要用人工判断来校准。

人工评估是质量的金标准，但慢且昂贵。一个不太好玩的冷知识：人工标注员因疲劳可能漏掉高达50%的缺陷。三种方法互补，大多数实际应用采用组合策略。

选择原则很清晰：答案是确定性的（格式、长度、禁用词）用代码评估；需要语义理解（准确性、忠实度）用LLM评判；从未见过的故障模式保留人工介入，并用人工标注验证LLM评判是否可靠。

先读追踪，再写评估：错误分析是最被低估的步骤

在写任何评估器之前，先阅读十几条追踪。这是整个工作流中价值最高的活动，却常被教程跳过。Anthropic专门投资了查看追踪的工具，团队每天花大量时间阅读这些记录——它能区分「Agent真犯错」和「评分者误杀了正确方案」。

阅读采用定性研究方法：开放式编码，逐条记录你看到的问题，用自然语言描述，不要提前归类。汇总后再进行归类（axial coding），把相似问题归入类别，并追问根因：是检索失败？推理错误？幻觉？范围违规？每个根因指向不同的修复方案。

最终得到一张根因频率表。优先修复什么？用严重程度乘以频率来决定——如果百分之一的概率是给出危险指令，那就先修它。

同时要提前定义「好」的标准。一份好的财务报告应引用正确股票代码、包含真实近期数据、区分前瞻性分析与历史总结。写下来时这些标准看似显而易见，但很多团队从未做过，直接跳到应对用户投诉。而好的定义往往掌握在产品、客服等「非技术人员」手中，他们最清楚失败长什么样。

开放式编码（open coding） 与 轴向编码（axial coding） 源自扎根理论（Grounded Theory）这套质性研究方法。开放式编码要求研究者悬置预设分类，逐行阅读原始材料并为每个现象贴上描述性标签，例如「Agent 调用了错误的 API」「回答引用了过期财报」。此阶段只记录、不归类，目的是保留现象的原始丰富性。轴向编码则是在开放式编码产出的标签基础上寻找关联，将相似现象聚合成范畴，并围绕「条件—行动—结果」梳理范畴间的关系，从而提炼出根因。在 Agent 错误分析中套用这套流程的好处是：先让失败模式自己浮现，而不是用预先想好的分类去套，能发现设计者从未预料到的故障类型。

三类评估器的建立与校准

第一道防线：代码评估。 最简单的例子是检查报告中是否出现目标股票代码。一个易被忽略的原则：评估Agent产出的结果，而非它走过的路径。人们常想检查工具调用顺序，但Agent经常找到设计者未预料的有效路径，评判路径会惩罚创造力。

内置LLM评估。 平台通常自带准确性、忠实度、工具选择等模板。但要注意应用场景：在实时网络搜索的Agent里，准确性评估可能全军覆没——裁判模型的知识截止时间早于Agent获取的最新数据，它会抱怨「来自未来的信息」。此时忠实度评估更合适，因为裁判拿到与Agent相同的上下文，能判断报告是否基于原始材料。两个评估给出不同信号，差别不在优劣，而在你真正要问的问题。

自定义评估。 内置模板无法覆盖每一个用例。好的评分标准包含：定义裁判角色与上下文；明确列出通过/失败的具体、可观测标准；用XML标签分离指令与数据；提供优秀与糟糕的示例（示例对一致性提升最大，但要注意过拟合风险）。保持二元选项（通过/失败）通常优于1-5分制，因为LLM处理细粒度区分很差。要求裁判先推理再评分，能显著提升准确率。

校准裁判（元评估）。 把LLM裁判当作分类器：用人工标注的黄金数据集对比它的预测。实践中常见一致率仅五成左右——此时要读分歧案例的解释，判断是评分标准模糊还是人工标注错了。迭代评分标准，再用留出集验证，避免对黄金数据集过拟合。评估提示词也要像代码一样版本控制。

常见反模式：把评估提示词当代码随意改词（对措辞极其敏感）；构建一个检查所有维度的「全能评判者」（无法校准、无法定位失败）；混淆护栏指标（必须拦住发布的硬条件）与北极星指标（追求的目标）。

元评估（meta-evaluation） 指对评估器本身进行评估，即把 LLM 裁判视为一个二分类器，用人工标注的黄金数据集测量其准确率、召回率与一致率。实践中最常用的指标是简单一致率（裁判判定与人工标注相同的比例），更严谨的做法是计算 Cohen's kappa，它扣除了随机一致的基线，能反映真实一致性。一致率仅五成意味着裁判的表现接近抛硬币，此时不能直接采信其分数。诊断路径是抽取分歧样本、阅读裁判给出的推理，区分两类误差：评分标准本身有歧义（需修订 rubric），还是人工标注出错（需修正黄金标签）。校准后的裁判仍需在留出集上验证，以防针对黄金集过拟合。

从失败到修复：数据集、实验与编程Agent闭环

把所有失败追踪筛出来，建成失败数据集，针对性地运行新提示词，更快更省。同时保留一个回归数据集，确保修改没有破坏原本正常的功能。真实流量到来后，用生产失败案例替换合成数据，失败与通过的并集就是黄金数据集。

实验的核心抽象是一个Python函数：从数据集取样本，运行任务，返回输出。受控对比意味着相同输入、相同评估器，唯一变量是提示词——分数差异可归因于你的改动。

更进一步：让编程Agent拉取失败追踪和裁判解释，把解释转化为对代码库的具体修改。每一次改动都能追溯到具体失败，这是数据驱动的提示词工程。两个护栏必不可少：明确告知目标（否则Agent会为通过评估而作弊，把测试数据纳入自己的评估）；要求它寻找共性问题，而非追逐单条失败记录。

至于样本量：工作坊规模的12-20条能提供方向性信号；正式发布决策需要约200-400个样本，仍在人类可处理的范围内。样本量翻四倍才能显著降低误差范围，收益递减明显。

受控实验 在评估语境下对应软件工程中的 A/B 测试思想：固定数据集、评估器、模型与采样参数，仅改变一个变量（通常是提示词），从而把分数差异归因于该变量。这要求评估流程本身足够确定——LLM 裁判的非确定性会引入噪声，因此同一配置常需重复运行取均值，或对裁判设置温度为零。样本量方面，12-20 条只能给出方向性信号，统计功效不足以支撑发布决策；200-400 条能将置信区间收窄到可操作范围。样本量翻四倍误差范围才减半，这一平方根关系解释了为何盲目扩大数据集收益递减，不如优先提升单条样本的质量与代表性。

生产闭环：在线评估与持续迭代

上线不是终点。在线评估自动运行在真实流量上，可在跨度级或追踪级触发，并按比例采样（1%-10%）控制成本。失败案例被保存为回归数据集，反馈给编程Agent，经实验验证后发布修复，再次进入循环。

每次失败都会变成新的测试用例，久而久之形成独属于你应用的数据库——针对你的失败模式、你的用户、你的质量标准。没人拥有这些数据，而它随Agent每运行一次而增长，这正是竞争优势。

优先级上，修复数据质量影响最大（搜错数据源时，再优化提示词也没用），其次是提示词优化，再次是模型选择，超参数调优应放在最后。一个值得掌握的理念是评估驱动开发：动手构建功能前先写评估，直到评估通过为止。最了解产品需求的人——产品经理、客服、销售——能用自然语言描述什么算好，他们应该参与评估的编写。

从阅读追踪开始，添加那两行埋点代码，写一个代码评估，跑起来看结果。15分钟阅读真实输出，比一小时构建仪表板更能让你了解你的应用。评估是基础设施，不是事后考虑，它的价值随时间累积。