引言：打破"盲目飞行"的开发循环
在开发AI智能体的过程中，许多团队都经历过这样的痛点：你修复了一个问题，却在不经意间引发了另一个更隐蔽的问题。如果没有一套可靠的评估体系，整个开发过程就像是在"盲目飞行"，团队陷入被动修复的循环，难以自信地发布新版本。
有效的评估（evals）正是打破这一困境的关键。它能让智能体在行为上的变化和潜在问题在影响用户之前就变得清晰可见。本文将从Anthropic的深度分享中，提炼出五个最令人惊讶、最具影响力的核心教训，它们将彻底改变你对AI智能体评估的看法。
五个关于AI智能体评估的反直觉教训
教训一：别等了，从20个失败案例开始构建你的评估体系
团队在项目初期常常认为构建评估体系是一项巨大的"开销"，会拖慢产品上市的进度，因此选择推迟。他们认为，等产品功能稳定、规模化之后再来考虑评估也不迟。
然而，Anthropic的经验恰恰相反：等到智能体规模化后才开始构建评估，你会遇到更大的困难。更重要的是，评估的价值会随着时间复利增长。早期投入不仅不会拖慢你，反而会成为未来加速迭代的引擎。那么，该如何开始呢？其实门槛比你想象的要低得多：
"实际上，一套由20-50个源自真实失败案例的简单任务，就是一个绝佳的起点。"
这个观点之所以重要，是因为它彻底打破了"评估体系必须庞大而完美"的误区。这不仅仅是关于避免技术债，更是为了获得开发过程中的能见度。用一小组真实的失败案例起步，就等于为你的驾驶舱安装了第一批仪表，让你停止"盲目飞行"，开始用数据导航。
教训二：当你的智能体"失败"时，可能恰恰是天才的体现
我们通常认为，评估失败就意味着智能体犯了错。但有时，这种"失败"恰恰是其卓越创造力的体现。
以Anthropic提到的 Opus 4.5 模型为例，在一个预订航班的测试任务中，它没有遵循预设的流程，而是通过发现政策中的一个漏洞，为用户找到了一个更好的解决方案。从字面上看，它"失败"了这次评估，因为它没有按照人类设计的死板路径执行任务。但从用户的角度看，它取得了巨大的成功。
"它'失败'了书面上的评估，但实际上为用户想出了一个更好的解决方案。"
这个例子深刻地揭示了静态评估的局限性。这并非简单的程序错误，而是前沿模型的一个典型特征：它们的解决问题的能力，已经开始超越那些嵌入在旧式评估里的、基于静态规则的假设。依赖僵化的路径评估无异于另一种"盲目飞行"，因为它让你对模型自身的天才之处视而不见。学会识别这些"天才般"的失败，才能让你真正看清你所解锁的前沿能力。
教训三：评估终点，而非过程
在评估智能体时，一个常见的错误是检查它是否遵循了一套非常具体的步骤，比如是否按照特定顺序调用了某些工具。这种方法看似严谨，实则非常脆弱。
Anthropic指出，这种方法"过于僵化，会导致测试过于脆弱"，因为它会惩罚那些评估设计者未曾预料到的、同样有效的创新方法。一个更优越、更具前瞻性的做法是：评估智能体最终产出的成果（outcome），而不是它所采取的具体路径（path）。
例如，与其检查一个编码智能体是否调用了某个特定的编辑函数，不如直接评估它生成的代码是否通过了所有的单元测试。专注于过程本身就是一种"盲目飞行"，因为它让你对那些更优越、未曾预见的解决方案视而不见。而专注于最终成果，才是获得智能体究竟为用户完成了什么的真实视野。这一教训对于释放AI智能体的全部潜力至关重要。
教训四：你的指标在衡量什么：一次成功还是次次可靠？
"我们的智能体成功率是75%。" 这句话听起来不错，但它可能隐藏着巨大的误导性。你需要问一个更深层次的问题：这个成功率衡量的是什么？是多次尝试中的一次成功，还是每一次尝试都必须成功？这里有两个关键指标：pass@k 和 pass^k。
- pass@k 衡量的是智能体在 k 次尝试中至少有一次成功的可能性。你可以把它比作"多次射门，只要进一个球就算成功"。这个指标适用于那些只要找到一个可行解就行的场景，比如代码生成或创意构思。
- pass^k 衡量的是智能体在全部 k 次尝试中每次都成功的概率。这更像是"要求每次射门都必须命中"。对于需要高度可靠和一致性的面向客户的智能体来说，这个指标至关重要。
这两个指标的差异巨大。例如，如果一个智能体的单次成功率（pass@1）是75%，那么它连续成功3次的概率（pass^3）就骤降至42.1875%，约等于42% (0.75 x 0.75 x 0.75)。
为需要高可靠性的面向客户的智能体使用 pass@k 指标，是导致用户流失的温床。因为75%的单次成功率掩盖了在仅仅三次交互中，性能稳定率甚至不足50%的残酷事实。这不仅仅是统计学上的选择，更是决定产品定位的战略抉择。你是在打造一个创意性的头脑风暴伙伴，十次尝试有一次绝妙点子就算巨大成功（pass@k）？还是在构建一个关键任务型支持助手，任何低于近乎完美的可靠性都是不可接受的（pass^k）？你的指标选择，决定了你的优化方向。
教训五：你最强大的评估工具不是代码，而是你的眼睛
在追求自动化的过程中，我们很容易过度依赖冷冰冰的评估分数。然而，分数可能是骗人的。一个误导性的低分可能不是因为智能体失败了，而是因为评估本身存在缺陷。
例如，Anthropic在对Opus 4.5模型进行CORE-Bench基准测试时，通过人工审查记录发现，其分数从最初的42%跃升至95%。原因何在？仅仅是修复了评估系统中的问题，比如过于僵化的评分标准（它会因为"96.12"与预期格式"96.124991..."不完全匹配而判定为错误）。如果没有阅读完整的试验记录（transcript），团队会错误地认为模型的能力远比实际情况要差。
"阅读记录是验证你的评估是否在衡量真正重要的事情的方式，也是智能体开发的一项关键技能。"
信任分数而不去阅读记录，是终极的"盲目飞行"------仪表盘显示你在急速下坠，但实际上你可能飞得比以往任何时候都高，只是你的仪表坏了。自动化工具告诉你"是什么"（分数是42%），但只有深入审查记录才能揭示"为什么"------不是因为模型不行，而是因为评估本身存在缺陷。
结论：将评估视为核心战略，而非事后弥补
有效的评估不是开发过程中的负担，而是一种能够加速开发、确保质量的核心战略资产。它能将团队成员模糊的"感觉变差了"转化为了清晰、可操作的衡量指标。
成功的AI团队都明白一个道理：评估体系是产品不可或缺的一部分，其重要性不亚于单元测试之于传统软件。而且，在模型能力飞速发展的时代，一个强大的评估套件就是你的护城河。它能让你在几天内验证并部署更先进的模型，而你的竞争对手可能还在数周的手动测试中苦苦挣扎。
如果你的评估体系反映了你最看重的东西，那么它正在讲述一个关于你智能体的核心故事。