谷歌的智能体团队表示，要测试具体行为，而不只是看基准测试分数。在更改提示词、工具或模型后，你如何发现智能体的表现是否变差了？

Google 开发者博客于 2026 年 9 月 9 日发表了一篇关于评估编程智能体运行框架的文章。其观点是：Terminal-Bench 和 DeepSWE 这类端到端基准测试的综合得分可能变动几分，却无法告诉你原因。行为评估则检查具体、可观察的独立行为，例如，智能体是否会在提示描述不充分时提出澄清问题，或者是否会在宣布构建文件修改完成前运行本地验证工具。他们表示，这套评估的主要任务是防止回归：确认提示的调整、工具模式的变更或模型的升级没有让智能体的整体表现变差。他们建议从小处入手：选取最近的一次失败，为其编写一项检查，并进行批量运行，因为单次运行的结果存在较大噪声。OpenAI 于 2026 年 2 月发表的框架工程文章则从构建的角度着手解决同一个问题。当智能体遇到困难时，他们将其视为能力缺失，并把修复方案以文档、护栏或工具的形式反馈到代码仓库中。两篇文章讨论的都是配备特定工具的编程智能体，所以我不确定这些做法在多大程度上适用于其他类型的智能体。想请教在生产环境中运行智能体的人：你们最先把哪一次失败转化成了可重复执行的检查？你们是针对工具调用和执行步骤进行断言，还是评判最终结果（使用大语言模型作为评判者）？你们如何处理不同运行之间的噪声？来源：Google 开发者博客，《框架工程剖析》（2026 年 9 月 9 日）；OpenAI，《框架工程：在以智能体为先的世界中利用 Codex》（2026 年 2 月 11 日）。