Anthropic 给 Claude Code 加入第一方插件评测：六种评分器和一道 CI 关卡

Anthropic 于 9 月 11 日在 Claude Code v2.1.269 中推出了原生的插件评测系统，让插件开发者第一次拥有第一方工具，去衡量一个技能是否真的会被触发 —— 以及触发之后是否带来任何可测量的差别。这项功能的调用方式是 claude plugin eval，它针对一组测试提示词运行每个插件，给 Claude 产出的结果打分，再与一次完全不加载该插件的平行运行结果对比。这两个分数之差称为 Δ（Delta），是唯一能证明插件真正对结果有贡献、而不是像乘客一样搭了便车的数字。

这次发布补上了 Claude Code 插件生态里一个长期存在的缺口。在此之前，发布技能（skill）的开发者 —— 技能是由自然语言触发、把 Claude 引向特定工作流的组件 —— 没有任何第一方机制去验证：一个技能在用户自然会输入的提示词上是否真的会触发，或者它是否比 Claude 本来就会做的结果更好。现有的 claude plugin validate 命令检查的是清单语法和模式。它检查不了行为。

延伸阅读：Claude Code 的 SendFeedback 工具，让 AI 自己起草会话失败报告

评分如何运作：两组、多次运行，以及真正要紧的 Delta

这套评测系统围绕 Anthropic 所称的「双组设计」构建。每个测试用例跑两遍：一遍在「有插件组」里，加载插件；一遍在「无插件组」里，不加载任何插件。每一组默认把同一个提示词跑三次，以降低智能体行为本身的不确定性带来的噪声。智能体系统跑一次说明不了多少问题；跑三次得出的平均分，才稳定到值得信赖。

某个用例在某一组中的得分，是通过的评分器所占比例（可选加权），再对三次运行取平均。Delta 就是有插件组得分减去无插件组得分。Delta 为 +0.67 —— 这是Anthropic 官方文档中的示例，对应一个加载插件时得 1.00、不加载时得 0.33 的用例 —— 意味着在这类提示词上，插件把表现提高了 67 个百分点。Delta 接近零则意味着插件没有贡献：没有它，Claude 也会产出同等的结果。

这个设计比看上去更重要。AI 开发团队过去评估插件质量，靠的是检查 Claude 的输出看起来对不对，而这道门槛区分不了「插件带来的正确」和「模型本来就有的能力」。Delta 分数施加了更严格的标准：插件必须带来增量，而不只是在场。按 Anthropic 的明确说法，一个在两组中都得 1.00 的用例，就不是靠这个插件才通过的。据文档所述，开发者第一次跑评测时最常见的发现，是 Delta 接近零，同时 tool_used: Skill 评分器失败 —— 也就是说，面对自然的措辞，Claude 根本没有选择调用这个技能。

六种评分器：四种免费，两种计入你的账单

评测系统提供六种评分器，按成本清楚地分成两类。四种评分器 —— regex、tool_used、tool_order 和 file_exists —— 根据会话记录和磁盘上的文件计算，除了智能体运行本身之外不产生任何额外费用。另外两种 —— llm 和 baseline —— 会调用一个评审模型，费用计入 API 账单。

regex 对会话输出、完整会话记录，或 Claude 在运行中创建的某个特定文件应用一个 JavaScript 正则表达式。tool_used 检查某个工具是否被调用了指定次数，并可选地用正则匹配调用的输入。tool_order 验证某个工具是否在另一个工具之前被调用 —— 适用于顺序要紧的工作流。file_exists 确认 Claude 是否在会话中创建了一个匹配给定通配模式的文件（不包括只是被修改、或在初始化时就已存在的文件）。

llm 评分器让评审模型根据一份写成具体 PASS 与 FAIL 条件的文字评分标准，投票判断会话输出是否达标。Anthropic 的实现对三次评审调用取多数票，以降低单次调用的方差 —— 考虑到输出越长、评分标准越宽泛，LLM 评审的一致性就越差，这是一个合理的缓解措施。baseline 评分器接收一份参考会话记录，让评审判断本次运行达成标准的程度是否至少不逊于那份参考，提供的是一个比较锚点，而非绝对标准。

评分器就是普通的 Markdown 文件，由前置元数据设定类型和选项。一个 arm 字段可以把评分器限定为只在有插件组中运行 —— 系统正是这样处理 tool_used: Skill 检查的：在无插件组里没有任何技能可以触发，这类检查不可能有意义地通过。Anthropic 把限定了组别的评分器从两组的比较得分中排除，只作为指标单独报告，防止它们人为压低无插件组的得分、扭曲 Delta。

CI 关卡：阈值、成本上限与退出码

对于想在质量不达标时阻止部署的团队，系统提供了一份写入文档的 CI 调用方式：

claude plugin eval . \
  --trust-plugin \
  --json results.json \
  --threshold 0.8 \
  --model claude-sonnet-5 \
  --judge-model claude-haiku-4-5 \
  --no-publish \
  --max-cost-usd 20

参数 --threshold 设定一个用例通过所需的有插件组最低得分；任何低于它的用例都会让命令以退出码 1 结束，从而阻断构建。参数 --max-cost-usd 设定按标价估算的成本上限 —— 不过 Anthropic 明确指出，达到上限时已经在跑的运行仍会跑完，可能因此超出上限，超出量就是这些运行的费用。当上限提前中止评测套件时，命令以退出码 2 结束，并把部分结果写入 JSON 输出文件，让 CI 脚本能区分质量失败（退出码 1）和预算失败（退出码 2）。

同时固定 --model 和 --judge-model 对 CI 的可复现性很重要。如果不固定，CI 流水线运行期间恰好发生一次模型更新，就可能产生看起来像插件退化、实际上是模型行为变化的分数波动。

成本随评测套件的复杂度增长。一个用例按默认每组三次运行，会产生总共六次智能体运行，外加每次运行中每个 llm 或 baseline 评分器各三次简短的评审调用。Anthropic 的文档给出了一个算例 —— 一个用例、六次运行、两个评分器 —— 估算成本 0.41 美元，耗时 74 秒。这些数字是公司提供的估算，会随所选模型、上下文长度和评审评分的数量而变化。

那些 claude plugin validate 看不到的东西

对比 claude plugin eval 和此前就有的 claude plugin validate 命令，就能看清这次发布之前缺了什么。claude plugin validate 做的是静态分析：检查插件清单是否符合模式、必填字段是否齐全、文件引用是否有效。这能在插件安装之前抓住编写错误和结构性问题。它无法让插件对着模型真跑一遍，也看不到模型实际做了什么。

这道缺口的后果不小。一个技能最重要的属性是它的 description 字段 —— Claude 正是读它来决定要不要针对某个用户提示词调用这个技能。一份语法有效、却与用户自然语言对不上的描述，会干净利落地通过 validate，然后在实际使用中触发不了 —— 插件发布了，开发者以为它能用，而这种失败模式一直隐形，直到某个用户注意到这个技能从来没触发过。claude plugin eval 通过运行贴近实际的提示词、检查技能是否真的被调用，在部署之前就把这个问题抓出来。

Smart Reports 与企业治理层

在评测系统之外，Anthropic 还面向企业版客户推出了 Smart Reports 测试版。Smart Reports 分析团队层面的 Claude Code 使用情况 —— 完成了哪些工作、花了多少钱、会话在哪里遇到阻力，以及哪些反复出现的模式值得打包成共享技能。这次发布让 Anthropic 的企业产品从面向单个开发者的工具，延伸到组织层面的可观测性：管理员可以衡量采用情况、识别高阻力工作流，并把阻力模式当作信号，判断该在哪里构建新的技能或插件。

插件评测与 Smart Reports 结合起来，为企业的 Claude Code 部署构成了一个完整的治理层。评测在插件层面提供部署前的质量保证；Smart Reports 在团队层面提供部署后的使用与成本可见性。两者合在一起，让企业买家拥有了把 Claude Code 当作受管基础设施、而非开发者便利工具来对待的度量手段 —— 这一转变对采购、合规和 IT 治理都很重要。

延伸阅读：Claude Code 桌面版加入 /resume，开发者不必再为丢失上下文交税

竞争背景：社区早已注意到的缺口

在这次发布之前的几个月里，第三方开发者就一直在为这个问题搭建局部的解决方案。bkper/claude-eval、sjnims/cc-plugin-eval 以及 PyPI 上的 coder-eval Python 包等库，各自解决了行为测试问题的某些方面 —— 检查技能是否触发、用 LLM 评审给输出打分、以质量指标作为 CI 关卡。同一种模式出现了多个独立实现，证明这个缺口是真实存在的，而且整个开发者社区都有需求。

这些工具都不是第一方的，也都没有那种让 Delta 有意义的「有 / 无插件」消融设计。第三方评测框架可以检查插件是否产出正确的输出；但如果不做额外工程，它分不清「插件带来的正确」和「零样本就有的正确」。Delta 分数，正是第一方集成才得以实现的那项方法论补充。

与之竞争的 AI 编程平台还没有推出同等的系统。根据目前公开的文档，无论是 GitHub Copilot 的扩展生态，还是 Cursor 的工具链，都没有写入文档的、针对扩展的第一方行为评测框架。微软的 Copilot Studio 在 Azure DevOps 流水线中提供了一个用于智能体质量测试的服务端评测 API，但架构差别很大 —— 它是在服务端针对草稿智能体做评测，而不是在本地对照行为基线执行 —— 而且面向的是企业智能体部署，而不是开发者编写的 CLI 技能。

局限，以及开发者该检查什么

在把它集成进 CI 流水线之前，这套系统的几个特点值得注意。

LLM 评分器的分数在多次运行之间并不完全稳定。Anthropic 的文档指出，llm 评分器的判定可能在不同运行之间不一致，而且输出越长、评分标准越宽泛，方差越大。三票多数制能降低、但无法消除这种方差。团队应把 llm 评分器的通过率当作概率性估计，而不是确定性的质量信号，并应该用具体的 PASS 与 FAIL 条件、而不是开放式标准来校准评分标准。

速率限制可能造成虚假的失败。Anthropic 明确警告：如果账户在评测套件运行中途达到套餐用量上限或 API 速率限制，后续运行会失败、得零分，产出看起来像插件退化的结果。输出中的 NOTES 列，以及 JSON 输出里的 cases[].arms.with[].error 字段，能把限额错误与真正的失败区分开 —— 团队在根据一次失败的 CI 运行采取行动之前，应先检查这些字段。

参数 --max-cost-usd 设定的是一个估算上限，而不是硬性封顶。达到上限时已在进行的运行仍会跑完。构建成本受控 CI 流水线的团队，应该把这个上限设得低于实际预算，为进行中的运行留出余量。

这套系统需要在 CI 环境中配置 ANTHROPIC_API_KEY 凭据。每一次评测运行、每一次评审评分调用，都会计入对应的套餐或 API 账户。对于大型评测套件，费用可能迅速累积；--ablation none 标志会跳过无插件组，适用于不需要 Delta 的运行，可把成本减半。

在 Windows 上，授予 Bash 权限的评测套件在没有 WSL2 的情况下不受支持，因为用来约束 shell 命令的操作系统级沙箱（在 Linux 上是 bubblewrap）在 Windows 上没有原生后端。

Delta 分数改变了插件开发的什么

Delta 分数 —— 插件的表现与没有它时 Claude 的表现之差 —— 在机器学习评测中并不是新概念。移除某个组件来衡量其贡献的消融研究，是标准的研究方法。新的地方在于：把这种方法论做成面向开发者的第一方质量关卡，用于 AI 平台扩展，并直接集成进带成本控制和退出码的 CI 流水线。

实际的后果，是「发布一个 Claude Code 插件」这件事的含义变了。在 v2.1.269 之前，发布插件意味着确认清单有效、技能在交互会话中对几个测试提示词能触发。在 v2.1.269 之后，它意味着产出一个 Delta 分数 —— 衡量插件相对完全不加载插件时，把 Claude 的行为改善了多少 —— 并以这个分数达到既定阈值作为部署的前提。

这个标准更严格，也理应如此。Claude Code 插件生态如今已有数百个社区编写的扩展，覆盖从 PR 审查到财务分析再到数据分析等类别。随着生态增长，能够验证插件带来可测量的价值 —— 而不只是看起来能用 —— 对选择采用哪些插件的开发者、决定批准哪些插件用于企业部署的机构，以及维护一个挂着自己名字的目录的 Anthropic 来说，都变得重要。评分器和 CI 关卡是机制。Delta 分数是主张：这个插件带来了可以被测量的差别。