一个团队开发了一个AI Agent，在测试聊天里给它几个代表性提问，看着它给出有用的答案。有人试着用稍微难一点的提示词，也成功了。团队录下演示，批准改动，然后发布上线。

几周后，检索配置变了，模型也升级了。Agent还能回答最初那些问题，但在某个任务上漏掉了必需的引用，在另一个任务上选错了客户查询工具。这个问题可能直到用户反馈或监控系统发现时才暴露出来。

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

一次成功的演示只能证明Agent在你恰好给定的条件下工作过一次，并不能充分说明下一个版本能否持续保持用户和运营方需要的行为。要做到这一点，评测必须成为交付流程的一部分。

评测系统要能复现运行

可重复的评测系统沿着产品的执行路径运行固定场景，并记录足够的证据来判断某个版本是否应该发布。它应该覆盖组装上下文的代码、Agent可以调用的工具，以及运行时强制执行的权限。如果无法在高风险工作流中复现一次运行或一次实质性回退，产品就不具备通过发布门禁的条件。

评测不是录个演示视频就完事。它需要一套能反复执行的机制，每次改动后都能跑一遍同样的场景，留下可核查的记录。这样团队才能判断：这次改动到底有没有破坏什么。

先定义"正确行为"，再写测试

"答案不错"不是任何人都能测试两次的需求。在选择评测工具之前，先写下Agent执行的各项工作、每项工作的边界，以及超出产品可接受运营范围的结果。

以支持类Agent为例，一项有用的工作可能是：使用正确账户的记录回答计费问题，并引用当前有效的政策。它的边界可能禁止更改套餐或暴露其他客户的数据。当找不到政策时，Agent应该承认这个缺口，而不是把没有依据的答案当作事实呈现。它可能还需要在继续之前请求账号，或者把异常转给有相应权限的人。

把结果和过程分开看

Agent可能在检索到错误文档后给出正确答案，也可能在调用不必要的工具或搜索超出客户范围后完成任务。它甚至可能把一个本该自己处理的常规请求升级出去。这些运行在记录里看起来是成功的，却掩盖了在不同请求下可能暴露的弱点。

评测要关注的不只是最终答案对不对，还要看过程是否合规。检索路径、工具调用、权限边界，每一步都值得单独检查。

从可观察的需求开始

先从每项工作的几个可观察需求入手。必需的事实必须有具名来源支持，写入操作必须等待确认。数据缺失时，Agent应该提问而不是猜测。高风险规则用精确断言，措辞上可以容忍一些变化。场景从这些需求出发构建，评测才有意义。