不要再只盯着跑新的模型基准测试了，开始观察你的智能体尝试取消订阅的过程吧。这两项活动之间的差距，正是生产系统崩溃的地方。单轮测试可以告诉你回复听起来是否悦耳，但它无法告诉你智能体是否刚刚退款给了错误的客户，是否针对日历 API 循环了十四次，或者是否决定完全跳过欺诈检查。文本是智能体产生的最不危险的东西。真正的风险隐藏在它触碰的工具、它修改的数据，以及它本该寻求帮助却继续执行的时刻。

为什么文本基准测试在生产环境中会失效

标准基准测试的高分已成为一种具有误导性的慰藉。一个能写出优美散文的智能体，在操作层面可能仍是一个隐患。当你的系统预订预约、编辑数据库记录或提交支持工单时，生成的文本只是工作流中可见的表面。在底层，智能体正在就调用哪个端点、发送什么负载以及何时停止做出具体的决策。它可能在阅读理解排行榜上名列前茅，却因为重复预订资源、修改了错误的行或将敏感状态泄露到日志文件中而让你损失金钱。你需要验证工作的执行机制，而不仅仅是输出的润色程度。如果一个智能体在离线 QA 测试中得分很高，却仍因循环或误用工具而导致工作流失败，那么你的评估方向就错了。

映射五大依赖关系

Van Data Team 的团队在进行每次评估时，都会先映射五个特定的控制点。这彻底改变了问题的本质。你不再问一个模型是否比另一个更聪明，而是开始问智能体是否真的能在你的实际约束条件下完成生产任务。

业务结果。 定义以美元和客户影响衡量的“完成”含义。任务的完成不只是因为智能体生成了一个摘要。只有当库存记录准确、预约已确认且客户收到了有效的追踪号码时，任务才算完成。

可变状态。 准确了解智能体被允许更改的内容。哪些表、哪些状态、哪些账户标志？如果智能体可以执行退款、重新安排任务或更新账单地址，你需要盘点它触碰的每一个字段。

工具权限。 明确哪些 API 端点和函数在范围内。如果边界模糊，一个同时拥有搜索工具、写入工具和通知工具权限的智能体将会混淆它们。将每项权限映射到具体的业务需求。

故障恢复。 决定当日历 API 超时、返回 500 错误或返回格式错误的 JSON 时该怎么办。智能体不应惊慌、幻觉出一个成功消息或无限重试。它需要一条清晰的降级路径。

人工审核关卡。 确定智能体在继续执行之前必须由人工签准的时刻。这并不是自动化能力的弱点，而是针对高影响变更的安全阀，也是为你评估准则提供事实标准（ground-truth labels）的来源。

真实的评估计划是什么样的

一旦映射了这些依赖关系，你就需要一个能匹配生产环境复杂性的评估计划。幻灯片上的指标在这里帮不上忙。

基于真实的生产故障构建测试集，而不是基于合成的问题库。如果你的智能体上周二因为混淆了两个相似的 SKU 而失败，那么这种具体的混淆就应该成为一个永久的测试用例。你的评估套件应该随着每次事故带来的新经验而不断增长。

编写以操作术语定义成功完成的评估准则。像“有帮助”或“准确”这样模糊的标准是毫无用处的。一个实用的准则应该规定：只有在引用了原始支付 ID、金额与请求匹配、已排队发送确认邮件且已记录交易 ID 的情况下，退款任务才算成功。

为工具调用和重试定义追踪规范。你需要观察智能体计划了什么、实际调用了什么、重试了多少次，以及重试策略是否合适。缺乏工具级粒度的追踪仅仅是一个动听的故事。

设定何时提醒人工的策略。智能体应该了解自己的边界。如果请求超过了金额阈值、涉及 VIP 账户或遇到了从未见过的状态，它应该向上汇报而不是盲目猜测。

安装发布门控以阻止糟糕的模型升级。只有当新模型能改善你的特定结果时，它才算是一次升级。如果它更频繁地产生工具参数幻觉、增加延迟或引入新的安全风险，则不予发布。即使基础模型厂商发布了新版本，门控也能保持生产环境的稳定。

运行时评分：观察智能体的执行过程

Anthropic 一直在推动行业从离线测试转向运行时评分 (runtime grading)。运行时评分不是在事后对对话记录进行评判，而是让系统在任务执行过程中实时评判智能体的表现。这为在错误演变成实际问题之前将其拦截提供了机会。

添加评分器会消耗 Token 并增加延迟。你无法承担对每一个微小步骤都进行评分的成本。每个评分器的位置都是一个设计决策。应将它们放置在错误代价高昂的地方。最有价值的检查点位于：将状态变更提交到数据库之前、执行支付扣款之前，以及向客户发送消息之前。这些时刻，一个错误的决策就会变成不可逆转的行为。

注意一个特定的盲点。如果同一个模型既负责执行工作，又负责对工作进行评分，它可能会漏掉同样的错误。产生错误的推理逻辑在复核时很容易将其合理化。对于高影响力的任务，请保持人工介入 (human-in-the-loop)。让人员来验证评分器自身的判断，尤其是在涉及资金或客户信任的时候。

这里的目标是实现运营控制。将你的故障数据、任务评分标准 (rubrics) 和运行时追踪 (runtime traces) 连接成一个反馈闭环。评估整个路径：计划、工具使用、恢复行为以及最终结果。使用离线测试在发布前捕捉已知的、可复现的错误；使用运行时追踪来发现你未曾预料到的新故障；使用人工复核来发现你的评分标准在哪些地方过于天真并需要收紧。

所以问问你自己：你会把运行时评分器放在工作流的哪个位置？在工具调用之前、工具调用之后，还是仅在进行风险变更之前？大多数团队起步范围太广，试图对所有内容进行评分，结果在成本压力下停滞不前。从窄口径开始。挑选一个一旦出错代价最大的动作，首先在那里放置一个评分器。

从一个代价高昂的错误开始

运营评估不是一项研究练习。它是智能体上线后让你睡个好觉的一种方式。你不需要在第一天就拥有一个完美的框架。你需要的是一个定义明确的工作流、一套用通俗业务术语编写的评分标准，以及一个放置在错误变得代价高昂的精确时刻的评分器。做好了这些，你就拥有了一个真正可以信赖的基础。

如果你想与从业者社区一起深入探讨智能体评估和运行时评分，可以在 https://t.me/GyaanSetuAi 找到 GyaanSetu 学习社区。