Google工程师Hugo Selbie提出AI智能体系统评测框架，告别凭感觉检查

当团队开始构建AI智能体时，测试方式通常如出一辙：接上模型，给几个工具，在终端里跑三四个提示词，然后凭肉眼看看输出。如果答案看起来还算合理，就直接发布了。然而，Google客户与合作伙伴解决方案工程师Hugo Selbie指出，这种做法在实践中很快就会崩溃。智能体的失败方式与标准软件不同，它可能卡在重试循环中，触发多次工具调用，却仍然返回一个礼貌、听起来合理的最终答案。这种隐藏的失败在生产环境中代价高昂，会悄无声息地推高云账单和token用量，耗尽下游API速率限制，甚至让用户盯着加载转圈干等。

为了超越简单的主观检查，Selbie提出了一套基于两大核心支柱——人工监督和针对性工具——的评估框架。第一步是用关键用户旅程（CUJ）定义成功，而不是抽象的基准测试。CUJ将测试锚定在用户期望系统实现的目标上，围绕角色、目标、约束条件和验证条件来构建。例如，“作为一名运营分析师，我希望智能体能够接收交易对手的交易差异邮件……并在无需人工干预的情况下起草一封回复”。该声明中的每一条款都成为一个评估点，促使产品相关方、下游用户和工程师就如何衡量“成功”达成一致。

第二步是从模拟用户开始，逐步过渡到真实流量。开发者不需要六个月的线上日志来构建初始的黄金数据集，而是可以将每个CUJ拆解为具体场景，输入到用户模拟器LLM中。通过设定人物角色和行为约束，模拟器可以模仿真实用户混乱的措辞和多轮对话的复杂性。第三步是在全栈范围内进行衡量，设置单元测试、确定性指标、LLM作为评判者的评分标准以及集成测试这四层检查，以定位根本原因。

Selbie特别强调了需要避免的四个常见陷阱。首先是丢弃测试并破坏基线，每次添加或删除测试都会使分数变化变得不可解释；其次是依赖模糊的1到5分评判分数，他建议尽可能将评判标准转化为布尔（通过/失败）问题，因为LLM在定性评分上出了名地不一致；第三是只评估文字表述而忽略运营成本，一个通过了所有质量检查但耗时40秒、进行了十二次冗余工具调用的回答仍然是生产环境中的失败；第四是为不同的智能体框架构建不同的评估流水线，他建议围绕OpenInference等开放规范标准化追踪，以解耦评估与编排框架。

在实际操作层面，文章提供了一个从Day 0到Day 2的实用上线流程。Day 0侧重于场景、模拟和“红笔”打分，即手动阅读执行追踪，标记出智能体每一次犹豫、幻觉出参数或选错工具的地方，从而得到一份高信号清单。Day 1则利用agent-eval等工具将这些红笔批注转化为自动化检查，建立规律的运行节奏，并用手工评分的trace验证自动judge。Day 2是将信任后的评估流水线变成永久的回归安全网，集成到CI/CD拉取请求门禁中，强制执行全局通过阈值和核心评估指标零回归规则。