Anthropic官方实战：如何科学选择与评估AI模型

当一个新的AI模型发布时，社交媒体上总会充斥着两极分化的评价——从"AGI已至"到"某公司已完蛋"。但对开发者和企业而言，真正的问题只有一个：这个模型对我的用例意味着什么？

Anthropic应用AI团队的Lucas在一场官方实战教学中，系统性地拆解了"如何选择正确模型"这一看似简单实则棘手的问题。本文基于其分享，梳理出一套可复用的AI模型评估方法论。

公开基准测试为何不够用

每次模型发布，Anthropic都会附带发布模型卡、提示词指南和基准测试结果，如SWE-bench Verified（衡量编码能力）或BrowseComp（衡量研究类任务能力）。这些公开基准确实能提供方向性的判断——大致告诉你某个模型在编码或研究上是否有所提升。

但问题在于，你的真实工作负载往往比单一基准复杂得多。以生产环境中的编码智能体为例，它可能需要先上网研究某个SDK的冷门用法，再将其落地为代码——这已经横跨了编码和研究两类基准。更何况，你使用的编程语言甚至可能根本没出现在SWE-bench里。

因此，Lucas给出的第一个核心观点非常明确：一个精心设计的小型评估集（eval），对你判断该用哪个模型的帮助，远超任何公开基准。 这也贯穿了整场分享的主线。

如何构建自定义模型评估体系

评估的原子单位是"任务（task）"——包含一组输入和一套成功标准。你要做的，是围绕这些任务构建起一个数据集。

过程与结果同等重要

Lucas用了一个很形象的比喻：评估就像学生时代的数学考试。你不仅要拿到正确的最终答案，还要展示中间的解题步骤。对于智能体（agentic）类任务尤其如此。

以客服智能体为例，一个完整的评估应该包含两层检查：

• 最终结果检查：用"LLM as a judge"（以大模型作为评判者）来核对最终回复是否符合预期。
• 过程步骤检查：确认智能体是否以正确的方式查询了数据库、是否调用了正确的工具、是否为搜索添加了正确的参数（如按客户所在国家进行本地化）。

LLM as a judge的优势在于它对细节的容错性——比如智能体写的SQL在语法上略有差异，但只要拉取的数据一致，评判者就能识别出这是等价的。而对于"必须调用某个工具"这类确定性要求，则可以用基于代码的确定性评估来检查。

Lucas强调，构建这套评估数据集需要大量"苦功夫"——你必须亲自定义什么是正确的解法、正确的结果、正确的步骤。但在一个AI自动化程度越来越高的世界里，花时间构建评估数据集，恰恰是对人类时间最好的利用之一。

构建AI评估时的三大常见陷阱

Anthropic内部积累了大量评估经验，Lucas总结了三个高频失误：

1. 把噪声当信号。 定义好评估后，每个任务都要运行多次，确认结果稳定。如果指标波动很大，往往说明任务定义不清或评估标准未对齐。

2. 混淆基础设施故障与模型能力。 有时你会发现某个模型（比如Opus）的分数异常偏低，深入查看执行记录（transcript）后才发现是大量API调用或工具调用失败所致。这些是基础设施问题，不是模型问题，必须区分开来。

3. 静默饱和（silent saturation）。 数据集必须真正代表生产环境中的真实数据。产品上线后，应持续收集trace、观察用户实际提问、分析智能体的失败模式，并将这些反馈回填到评估集中，形成闭环。

务必亲自阅读执行记录

Lucas反复强调：你必须阅读智能体或模型的执行记录（transcript）。 为此要尽可能降低查看门槛——用LangSmith、Braintrust等可观测性平台，把系统提示、工具调用、工具返回结果全部追踪下来，做到在任意节点都能看到"模型看到了什么、又如何反应"。

他举了一个生动的例子：团队在Claude Code上跑一个编码基准，发现Claude表现异常出色。深挖执行记录后才发现，Claude竟然翻查了git历史记录，从之前的试验中"抄"到了答案。如果只看表面指标，就会得出完全错误的结论。

此外，每个模型都有其独特的"脾气"。Lucas提到，同一段提示词，在Opus 4.5下某个工具严重"欠触发"，换到Opus 4.6却又严重"过触发"。因此，切换模型后往往需要对提示词做手动微调，也建议直接把官方提示词指南喂给Claude让它帮你更新提示。

关键理念：以"每次成功的成本"衡量AI模型

这是整场分享中最反直觉、也最重要的观点：

正确的模型，不是每token最便宜或最快的那个，而是每次成功产出成本最低的那个。

Lucas讲了一个内部代码修复流水线的故事。团队起初用Haiku 4.5（关闭思考）处理一个简单任务，得分92分。他们希望冲到100分，于是打开思考功能，如愿达成。但当他们把同样的评估分别跑在Sonnet和Opus上时，结果令人意外——两者都拿了100分，而且耗时反而更短。

这背后的逻辑是：更聪明的模型能用更少的步骤完成任务，规划更具策略性，不需要花大量时间反复验证——因此在时间维度上反而可能更高效。类似地，Opus 4.5在完成任务时不仅准确率更高，输出的token数量也显著少于Sonnet。如果只凭"小模型跑得快"的直觉，很可能会做出错误选择。

思考（Thinking）与努力（Effort）两个调节旋钮

Anthropic提供了两个精细控制的参数：

• 思考（Thinking）：从4.6级别模型起支持"自适应思考"，模型自行决定为某个任务思考多久，本质是行动前的"草稿纸"，属于系统二型思考。
• 努力（Effort）：控制Claude在思考、工具调用和响应上投入多少计算资源。

两者可以自由组合——比如"低思考+高努力"，或"无思考+使用努力参数"。通过这两个旋钮，你可以在准确率与成本的曲线上进行相当精细的定位。

整体平移成本-性能曲线的两大策略

如果说思考和努力是让你在既定曲线上滑动，那么以下两个策略则能把整条曲线整体平移，实现更低成本下的更高性能。

策略一：提示词缓存（Prompt Caching）

这是Lucas最推崇的降本策略之一。使用提示词缓存时，如果命中已预计算、预缓存的提示前缀，输入token只需支付标价的十分之一。

这意味着：你可以用Sonnet的成本获得Opus的质量，或用Haiku的成本获得Sonnet的质量。 Claude Code等产品都大量使用了这一策略。业界最优秀的AI系统，提示词缓存命中率通常能达到80%~90%，这是值得对标的目标。

实操上最稳妥的方法是"仅追加（append only）"：把发送给API的消息数组视为不可变，只做追加。一个常见的失误是在系统提示里放入日期时间变量，导致每一轮时间递增、缓存失效。Anthropic的API会返回缓存token指标，方便你持续测量并优化命中率。

策略二：上下文工程与上下文卫生

Lucas的"暴论"是：人们花了太多时间去设计复杂的多智能体编排系统，却忽视了最简单有效的事——良好的上下文卫生（context hygiene）。

提升工具返回结果的token效率，不仅能省钱、降延迟，还有一个二级效应：给Claude更干净、更高效的数据，它的回复本身也会更准确。

实测案例数据如下：

• 一个返回英超比分的工具，改用Markdown代替JSON、简化时间戳并增加星期标注后，token减少了66.4%——而这在多轮对话中会不断复利叠加。
• 一个网页搜索用例，对多次搜索返回的重复文章做去重后，输入token减少77%、成本降低65%，而Claude的准确率反而提升了9%。

这些数字之所以能被精确测量，正是因为一开始就构建了评估体系。省下65%的成本，意味着你可以负担得起更智能的模型，或在同等预算下开拓全新用例。

实战演练：批量跑遍所有模型配置

在工作坊环节，Lucas演示了一个可以直接套用的"技能（skill）"：它能审计现有的评估，并自动在多个模型、思考开关、多个努力级别上运行，然后将结果绘图、保存并格式化呈现。

演示使用的是tau-bench中的航空客服智能体场景。最终生成的图表清晰展示了几个反直觉的结论：

• 优化准确率：Opus 4.x（高思考+高努力）通过率最高，且token消耗低于Sonnet。
• 优化成本：开启思考的Haiku，表现竟能媲美开启思考和高努力的Sonnet。
• 优化延迟：高努力的Opus在相近思考水平下，延迟反而低于Sonnet。

这些图表的真正价值，是为模型选型决策提供数据支撑，让你能识别出各模型在不同配置下的非直觉特性，并根据自己看重的维度做出权衡。

三条带走即用的核心结论

Lucas最后总结了三条核心要点：

1. 一个精心设计的小型评估集，比任何公开基准都更能告诉你该用哪个AI模型——值得投入时间去构建。
2. 正确的模型不是每token最便宜的，而是每次成功产出成本最低的——建好评估后，用多模型、多配置跑出帕累托前沿，再根据智能、延迟或成本的优先级做选择。
3. 善用努力、思考、提示词缓存和上下文工程这些旋钮，在前沿曲线上精细定位，甚至整体平移曲线，从而以更低成本获得更高智能，解锁全新用例。

做到这三点，你在为自己的用例挑选AI模型时，大概率能落在一个相当理想的位置。