Anthropic Simon 搜索者遇见 smevals：一项更轻量的 AI 评估尝试

Simon Willison 在多年 eval 实验后发布了 smevals，这与 Anthropic 针对 AI 智能体测试的更正式指导形成了新的对照。anthropic simon 这一关联之所以重要，是因为双方如今都在强调同一个问题：除非团队同时测试提示词、工具、系统指令以及围绕模型构建的框架，否则模型分数本身说明不了太多问题。

Willison 与 Jesse Vincent 的 Prime Radiant 应用 AI 研究实验室共同开发了 smevals。该项目可在多种配置下运行小型评估套件，对输出进行评分，并生成报告以便进一步审查。

这一发布挑战了人们对 AI 评估的一个常见假设：团队并不总是需要先搭建大型基准测试平台，才能提出一个有价值的问题。他们需要的是一个聚焦的任务、可重复的配置、明确的检查标准，以及足够的可见性来理解失败原因。

因此，核心较量比 Anthropic 与另一家模型提供商之间的竞争更小、更务实。这是聚焦的本地评估与重量级、通用评估基础设施之间的取舍。前者更有利于速度和可检查性，后者则支持更广泛的实验和更复杂的环境。

smevals 为小型 AI 评估带来了什么变化

smevals 将一个具体的产品问题转化为可移植的任务、配置和评分规则目录。

Willison 于 2026 年 7 月 31 日宣布推出 smevals。他的 smevals 概览 将其描述为一种工具，可在不同模型配置下运行小型 eval 套件，并对生成的输出进行评分。

基本工作流从 uvx smevals docs 开始。该命令会向编程智能体提供项目文档，让智能体在构建评估套件前先研究其格式。

这种方法将文档视为运行上下文。项目并不要求用户记住每一个配置字段，而是希望编程智能体阅读说明并协助创建文件。

一次评估位于一个包含 YAML 文件的目录中。YAML 是一种常用于配置的人类可读数据格式。这些文件描述问题、任务、模型配置和评分行为。

用户可以针对多个模型运行同一套件。Willison 的示例通过重复使用 -m 参数，对指定的 GPT 和 Claude 配置进行比较。

这种命令结构很重要。它将模型选择定位为更大实验中的一个变量，而不是把模型视为整个产品。

smevals 还将运行与评分分开。run 命令记录某个配置尝试完成任务时发生的情况；随后，grade 命令会对这些已记录的结果应用预先定义的检查。

这种分离形成了一个有用的审计边界。团队可以保留原始行为，修改评分逻辑，并检视不同评分标准如何改变结果解读。

该工具提供两种报告路径。serve 命令启动本地网页界面，而 build 则生成可托管在其他地方的静态 HTML。

Willison 用一项俳句评估演示了该工作流。报告检查模型是否恰好生成三行非空文本，并利用所得评分对各项配置进行排序。

俳句基准测试刻意保持简单。但它依然说明了一项严肃的评估原则：定义明确的狭窄要求，往往能揭示广泛偏好分数无法解释的差异。

此次发布还引入了一套一致的术语。一个 eval 包含多个任务，而一个配置则定义了正在接受检验的模型及其他变量。

一次运行记录一个配置对一个任务的尝试。评分器通过应用检查来生成评分，其中包括确定性检查或自定义检查脚本。

这些自定义检查可以检视字符串、验证 XML 等格式，或调用另一个模型进行判断。这种范围让同一套件能够结合客观约束与更主观的质量评估。

这一工作流中的任何内容都不意味着 smevals 是 Anthropic 的产品。anthropic simon 的关联来自双方对智能体评估和 Claude 配置的共同关注，而非企业所有权关系。

因此，最直接的变化是可及性。开发者如今可以封装一个小型评估问题，而无需先采用庞大的评估服务或搭建自定义仪表板。

为什么 Anthropic Simon 的关注点如今集中在框架上

模型已不再是唯一有意义的比较单元，因为周边的智能体框架可能改变结果。

Anthropic 将智能体框架定义为处理输入、协调工具调用并返回结果的系统。其 智能体 eval 指导 将这一层与用于运行和评分实验的评估框架区分开来。

这种区分有助于解释为何 smevals 支持模型名称之外的配置。一个配置还可以包括不同的系统提示词、模型参数或智能体框架。

假设两个编程产品使用同一个底层模型。其中一个为模型提供了更好的代码仓库上下文，另一个则提供了更强的工具和更明确的完成检查。

只看模型的基准测试会将这些系统视为等同。配置级评估则可以显示，它们的实际行为存在差异。

压力落在那些仍仅凭公开排行榜选择模型的 AI 产品团队身上。这些排名有助于缩小候选范围，但很少能复现一个产品的确切提示词、工具、权限和数据。

智能体行为还会跨多个步骤展开。一个系统可能调用工具、修改状态、解读结果，然后决定是否继续。

一次早期错误可能影响之后的每一步操作。这使得智能体评估不同于检查聊天机器人是否正确回答了一个问题。

Anthropic 的指导指出，团队在评估智能体时，应将模型和智能体框架一并评估。这一观点与 smevals 采用的配置模型高度一致。

这才是 anthropic simon 的真正故事。两种方法都将关注点从孤立的模型智能转向用户实际体验到的完整系统。

这一时机也反映出一个日益突出的运营问题。模型、提示词和框架可以彼此独立地变化，但产品团队仍需识别究竟是什么造成了性能回退。

新模型可能提升推理能力，同时改变输出风格。修改后的系统提示词可能减少冗长表达，却削弱指令遵循能力。框架更新可能带来更好的工具，同时引入状态错误。

没有受控配置，这些变化就会纠缠在一起。团队会发现产品“感觉不同了”，却无法有把握地归因。

Anthropic 将这种情况描述为在缺乏足够可见性的条件下运作。团队等待用户投诉、手动复现失败、修补一个问题，同时又冒着引入另一次回退的风险。

smevals 为同一问题提供了一个更轻量的应对方式。它并不试图复现所有生产环境条件，而是让团队在扩展实验前，以结构化方式隔离一个问题。

这对知识密集型工作尤为重要。一个工程团队可能会测试，助手是否能在生成代码之前找到正确的内部规范。

该测试可以比较两种检索提示词、两个模型版本或两项工具策略。维护可搜索知识库的团队，在文档访问方式发生变化时也会面临类似问题。

由此得出的比较，比询问哪个模型最好更有用。它问的是：在明确条件下，哪个完整配置能完成一项定义清晰的任务。

关键机制是分离，而不是更聪明的分数

smevals 的清晰性来自于将任务、执行、评分和报告充分分离，使它们可以被独立检查。

许多评估产品承诺用一个单一分数简化比较。这种便利可能掩盖产生该分数的决策。

smevals 采取了更具分解性的路径。eval 阐明更大的问题，每个任务则提出一项具体挑战。

随后，配置描述尝试完成这些任务的系统。一次运行捕获尝试过程，评分器则通过一项或多项检查来评估保存的结果。

这种架构听起来像常规测试，因为它在很大程度上遵循常规测试的逻辑。输入、条件、输出、断言和报告仍是容易理解的概念。

语言模型的行为使每个部分都变得更复杂。相同的提示词可能产生不同答案，而多个不同答案都可能满足用户需求。

因此，有用的检查必须匹配具体要求。精确字符串匹配适合固定 token，但在多种表述都有效时表现很差。

结构性检查提供了另一种选择。团队可以验证 JSON、XML、行数、必需章节，或在智能体环境中创建的文件。

基于模型的评分器则处理确定性较低的质量维度。另一个模型可以评估答案是否遵循评分标准、包含必要推理，或满足风格要求。

不过，AI 裁判并不会将主观问题变成客观真理。它会将另一个模型、提示词和一组假设引入评估过程。

将评分与执行分开，使这一局限更容易被研究。团队可以保留相同的运行结果，比较多种评分方法，而不必为每个任务重新付费。

它还可以检查分歧。如果格式检查通过而 AI 裁判未通过，报告会揭示两个不同维度，而不是立即将它们平均起来。

报告层出于同样的原因也很重要。汇总分数帮助读者快速浏览结果，而单次运行则揭示某个配置为何成功或失败。

Willison 的俳句示例说明了这种平衡。排行榜提供摘要，而近期运行、任务详情、标签和评分器信息则呈现底层证据。

静态 HTML 还带来另一项实际好处：团队无需维护实时评估服务，也可以发布结果。

uvx 入口同样降低了部署摩擦。根据官方 uv 工具指南，uvx 会在临时隔离环境中运行已打包的工具。

这种设计适合短期调查。开发者可以先试用命令，而不必将持久化的全局安装作为首要前提。

编程智能体工作流还降低了另一项设置成本。智能体可以阅读项目文档、提出 YAML 文件建议，并协助完善测试。

人工审查仍不可或缺。由智能体生成的套件可能会编码模糊预期、遗漏困难案例，或创建只奖励其自身假设的检查。

因此，该工具并没有消除评估设计。它只是缩短了从一个问题到该问题第一个可执行版本之间的距离。

这种差异很重要。团队往往会推迟评估，因为他们设想的第一步包括数据库、仪表板、追踪系统和大型黄金数据集。

smevals 提出了一个更聚焦的第一步：编码一个真实的不确定性，并在少量受控配置中运行它。

小型 eval 套件挑战重量级框架

smevals 最有力的理由不在于功能广度，而在于能够从一个边界明确的问题开始，并保留相关证据。

评估市场已经包含覆盖范围更广的开放框架。英国 AI Security Institute 的 Inspect 平台支持数据集、求解器、评分器、智能体、沙箱、模型提供商以及详细的执行记录。

其 Inspect 文档 将一项任务定义为数据集、求解器和评分器的组合。求解器可以进行一次模型调用，也可以运行配备工具的多轮智能体。

Inspect 还支持复杂的安全评估和隔离执行环境。这些能力适合运行正式基准测试，或测试会修改外部状态的智能体的组织。

Promptfoo 从提示词和应用测试的角度切入这一问题。其配置格式涵盖提供商、提示词、测试用例、断言和变量。

官方的 evaluation workspace 展示了 YAML 如何定义提供商、提示词和预期行为。这使 Promptfoo 成为已将提示词视为可测试代码的团队的相关比较对象。

smevals 以更小的声明范围进入这一领域。它的优势取决于：随着用户提出更多功能需求，这一小范围能否保持内在一致。

聚焦的测试套件更容易审查。每项任务都能直接对应某项产品决策，每份配置都能代表团队实际可能发布的一项变更。

这种聚焦也能改善失败分析。围绕具体用户需求命名的测试，能比抽象的能力类别向开发者传递更多信息。

以一个编写每周产品更新的助手为例。一个小型套件可以测试它是否引用了正确的会议记录、能否区分决策与提案，以及是否避免提出没有依据的说法。

配置可以改变检索提示词、模型和文档选择工具。评分器可以检查是否存在引用、来源是否正确以及事实是否一致。

公开基准无法回答这一产品问题。它缺少团队自己的文档、预期工作流，以及对“有用更新”的定义。

当环境本身需要模拟时，重量级框架仍然很有价值。浏览器智能体、编程智能体和客服系统通常需要带状态的任务，以及可复现的数据库或沙箱。

小型 YAML 套件并不会自动重建这些条件。它们需要兼容的运行器、脚本、测试夹具或其他测试框架组件。

因此，主要的对手并不是某一家具体公司，而是一种路径。选择在于：从一个狭窄的本地问题开始，还是从通用的评估基础设施开始。

没有哪条路径在所有情况下都更胜一筹。当搭建成本让团队根本无法开展测试时，较小的路径更具优势。

当测试必须控制复杂状态、捕获完整轨迹、强制隔离，或在部署流水线中持续运行时，较宽广的路径更具优势。

最有价值的推进方式或许是连接两者。团队可以通过 smevals 发现有价值的案例，再将成熟测试迁移到更大的回归系统中。

这一推进只有在工件保持清晰易读时才可行。任务、配置、输出和评分规则必须足够明确，让另一位工程师能够复现。

smevals 似乎正是围绕这种可移植性设计的，但是否被采用将决定这一约定能否成立。一旦自定义评分器和运行器不断累积，工具就会变得更难替换。

因此，该项目的小规模既是卖点，也是考验。它必须为真实智能体增添足够能力，同时又不能重建每一个复杂的评估平台。

分数仍无法解决的问题

可重复的测试套件能够暴露行为，但无法保证其任务、评分器和样本代表真实的生产环境。

第一个不确定性是覆盖范围。紧凑的套件可以很好地回答一个狭窄问题，却可能忽略罕见但比平均分更重要的失败。

团队也可能围绕已知的成功案例编写任务。被要求生成评估的编程智能体可以产生看似合理的变体，却未必能发现真实用户遇到的意外边界情况。

因此，生产事故应当反馈到套件中。投诉、失败轨迹、支持工单和人工审查，都可以揭示合成任务生成遗漏的场景。

第二个不确定性是不确定性。即使配置看起来没有变化，模型在重复尝试中也可能产生不同结果。

每个任务只运行一次，无法区分可靠的配置和碰巧成功的配置。当输出方差会影响决策时，重复试验就变得至关重要。

Anthropic 的评估指南建议考察多次试验中的成功率。它也警告，模型可能找到评估者未曾预料到的有效解决方案。

这会形成一种棘手的失败模式。即使某个创造性的结果更好地服务了用户，僵化的评分器也可能对其判负。

相反的问题会出现在模型评分器上。过于宽松的 AI 裁判可能接受语言流畅、却违反重要隐性要求的输出。

人工校准有助于识别这些错误。审查者应检查通过和失败案例、比较评分器的判定，并在裁判奖励了错误行为时修订评分标准。

第三个不确定性涉及系统与评估器之间的污染。当编程智能体帮助编写任务、提示词和检查项时，它们的偏好可能会塑造基准。

使用相关模型作为评分器会加深这一影响。测试可能偏好熟悉的措辞或推理模式，而没有衡量实际效用。

这并不意味着模型评分无效。它意味着评分应当始终能够追溯到评分标准、裁判配置和审查流程。

第四个问题是统计置信度。一个只有三项任务的套件可以发现明显的格式回归，却无法支持关于模型质量的广泛主张。

smevals 自称为小型评估套件，读者也应保留这一边界。其报告比较的是实际运行过的任务，而不是涉及模型的每一种能力。

团队应避免将局部结果转化为普遍排名。“配置 A 通过了八个产品案例”是可以成立的说法；“模型 A 更好”通常不是。

成本和延迟也需要同样谨慎对待。得分更高的配置可能使用更长的提示词、更多工具调用，或更慢的推理模式。

如果这些因素对产品很重要，套件就需要记录并比较它们。仅凭质量分数无法决定最佳的上线选择。

安全性也会改变评估设计。拥有 shell、浏览器或数据库访问权限的智能体，需要隔离环境和对最终状态的检查。

执行记录可能显示智能体声称成功。实际结果取决于它是否创建了正确的文件、修改了目标记录，或避免了被禁止的操作。

这些限制并不是反对小型评估的理由。它们界定了小型套件仍然值得信赖的范围。

anthropic simon 的趋同之处恰恰在于，两种方法都没有将一个汇总数字视为终点。运行、轨迹、结果和评分器行为都值得检视。

三个信号将表明 Anthropic Simon 的重叠是否持续

如果团队使用 smevals 来比较真实的测试框架决策、校准评分器并保留可重复的证据，它的意义将超越发布之初。

第一个信号是已发布评估套件的范围。Haiku 格式证明了工作流，但智能体开发者需要涉及工具、状态和多步骤完成的示例。

只比较提示词的套件，会让 smevals 更接近既有的提示词测试工具。比较编程或研究测试框架的套件，则会支撑其更广泛的定位。

如果用户发布具备可见运行记录和检查项、可复现的智能体案例，这一判断会更有力。如果示例仍局限于简短的文本格式化任务，它就会减弱。

第二个信号是评分器校准。该项目支持确定性检查和更复杂的检查脚本，包括基于模型的评估。

用户现在需要能够将这些评分与人工判断进行比较的方法。有用的报告应公开分歧，而不是将其隐藏在单一分数之中。

如果团队能够重新运行评分、检查评分标准并记录评分器为何发生变化，smevals 的理由会更充分。如果排行榜与底层证据脱节，这一理由就会削弱。

第三个信号是与日常开发的集成。本地实验只能一次性带来洞见，而回归套件可以保护未来的变更。

关注团队是否会在模型更新、提示词修改、工具变更和测试框架发布后运行 smevals。反复使用将表明，小型套件可以成为持久的工程资产。

集成并不要求每个团队都搭建复杂的平台。共享代码仓库、经过审查的 YAML、保存的运行记录和一致的发布检查，或许已经足够。

如果套件在最初比较后就变得陈旧，这一信号就会减弱。过时的基准可能带来信心，却无法反映当前产品。

对开发者和企业买家而言，实际行动很简单：找出一个目前仍凭直觉做出的决策，然后定义能够质疑它的最小测试。

这个决策可能涉及 Claude 与 GPT 的比较，也可能涉及两种系统提示词或两种检索策略。配置应反映用户实际体验到的内容。

将第一个结果视为证据，而非判决。检查失败案例，质疑评分器，从真实工作中加入案例，并在行为存在变化时重复试验。

持久的 anthropic simon 教训并不是某个小工具能解决 AI 评估问题，而是模型选择、提示词设计和测试框架行为必须一起接受测试。

你的团队仍在依据演示、排行榜还是直觉做出哪项产品决策？把这种不确定性转化为一个聚焦的套件，保留运行记录，并看看证据是否会改变答案。