60分钟搭建AI智能体评测流水线：超越“感觉还行”

一个AI智能体可以陷入循环、烧掉大量token、给出完全编造的答案，但表面上看起来一切正常。靠肉眼扫一眼输出，根本发现不了这些。

这是AI Agent Clinic一期节目《How to Actually Evaluate (Any) AI Agent: Beyond the Vibe Check》背后的操作手册，其中用60分钟为一个LangGraph智能体搭建了一套评测流水线。

为什么“看着还行”会出事

团队刚开始做智能体时，测试方式几乎都一样：接上一个模型，给它几个工具，在终端里跑三四个提示词，然后盯着输出看。答案看起来合理，就上线了。

这种做法很快就会崩。你为了修复某个工作流里的边缘情况，调整了一下系统提示词，结果智能体在另一个工作流里突然不再调用某个必需的工具了。

更麻烦的是，智能体的失败方式和传统软件不一样。它可能卡在重试循环里，可能发起多次工具调用，但最终仍然返回一个礼貌、听起来合理的答案。这种隐藏的失败在生产环境里代价很高。

把可靠的评测套件整合进开发流程，在原型阶段看起来像是额外的负担——直到你改一次系统提示词，引发了意料之外的破坏性变更。

评测是一条渐进的路

关键在于认识到：评测是一个渐进的过程。任何可重复的评测系统，无论多简单，都比依赖临时的抽查或者完全没有系统要好。

你不需要在第0天就搭出一套精巧的自动评分架构。从简单、可重复的检查开始，随着智能体能力和生产需求增长，再逐步演化成更复杂的自动化框架。

要让评测系统可重复，有两个核心支柱：人工监督和有针对性的工具。把人工审查的执行轨迹和自动化验证结合起来，有助于在开发早期发现那些悄无声息的退化，并且能随着智能体走向生产而平滑扩展。

先定义什么叫“好结果”

在写测试代码之前，你需要对“好结果”长什么样有共识。测试应该锚定在关键用户旅程上，而不是抽象基准。

一个关键用户旅程定义了用户期望系统达成什么，围绕用户画像、目标、约束和验证条件来组织。这句话里的每一个分句都会变成一个评测点：智能体有没有找到正确的事务ID？它在起草之前有没有检查账本？它有没有把内部ID映射回外部命名？

提前定义这些期望，会迫使产品相关方、下游用户和工程师就“成功”如何衡量达成一致。

你不需要六个月的线上日志才能构建初始的黄金数据集。把每个关键用户旅程拆成具体场景，包括正常路径和边缘情况，然后喂给一个用户模拟器大模型。给模拟器设定好用户画像和行为约束——比如一个不耐烦、给出的工单号不完整的分析师，或者一个提出多部分调试问题的开发者——它就能模仿真实用户混乱的措辞、错别字和多轮复杂度。

用合成用户和真实场景测试智能体，你可以在用户真正交互之前就记录下完整的执行轨迹，包括工具日志。这样就能对照发布标准，定位并解决性能差距。当真实流量开始进来，再逐步用真实生产轨迹替换这些合成设置。

四层检查，定位根因

一个顶层的总分永远无法告诉你智能体为什么失败。要隔离根因，需要叠加四种检查：

• 单元测试
• 确定性指标
• 大模型作为裁判的评分标准
• 集成测试

搭建评测指标的过程充满试错。你很容易想删掉一个噪音大的测试，或者在两次运行之间换掉样本查询。但每次增删测试，你都会让基线失效：你分不清分数变化是因为智能体变好了，还是因为测试集变了。在调优某个功能时，保持黄金数据集冻结，一次只改一个变量，只有当你确定底层需求变了，才退役某个测试。

大模型在给1到5分的定性评分时出了名地不一致，“3分”和“4分”之间的边界很模糊，而且经常每次运行都在变。

只要可能，就把裁判评分标准变成布尔式的通过/失败问题，而不是开放式评分。不要问“这个答案从1到5有多有帮助”，而要问“智能体在调用退款工具之前有没有验证账户ID？是/否”。

别只看最终文本

一个通过了所有质量检查的回答，如果花了40秒、做了12次冗余工具调用、每次查询成本60美分，在生产环境里仍然是失败的。

始终评测整个系统，而不只是最终文本。把延迟、token消耗（提示词、推理和补全token）、API成本和工具调用次数，与答案质量放在一起追踪。

切换编排框架往往迫使团队废弃并重写整个测试套件。虽然大多数框架都会发出OpenTelemetry追踪，但它们在工具调用、步骤和token上并不使用相同的语义约定。围绕OpenInference这样的开放规范来标准化你的追踪，可以把评测与编排框架解耦。像agent-eval toolkit这样的工具原生支持这一点，只需极少的设置。

你不需要从零搭建一个可观测性平台。你可以用agent-eval toolkit这样的开源工具，在几个小时内搭起评测流水线，它把OpenTelemetry追踪捕获与Agent Evaluation服务配对使用。