Claude Opus 5.5 LLM 测试：基准测试结果、安全发现与成本分析

AI技术与应用 2026-10-12 17:34:47 6

最近折腾了 Claude Opus 5.5，拿 GoML 的 LatticeBench 跑了完整测试，把基准测试结果、安全发现和成本情况都摸了一遍。这篇直接说结论。

Opus 5.5 在测试中修复了 GoML LatticeBench 评估中的全部 18 个关键缺陷，还解决了 7 个 very_hard 难度中的 6 个。但评估也暴露了一个有意思的短板：在复杂安全缺陷上表现出色的模型，反而在简单的一行式工单上翻车了。

GoML 发现了两个跨文件的批量赋值漏洞，这俩漏洞在之前所有测试轮次中都存活了下来。Opus 5.5 把两个都修了，在安全导向的编码智能体领域立了个新标杆。

模型在 AI Matic Bench Score 上得分 87.3，比之前的最高分高出 7.5 分。Token 定价也比上一代 Opus 5 更低。

但我们的发现表明，漂亮的基准测试分数并不能替代人工审查。Opus 5.5 修改了 107 个文件，包括安全相关的设置和模型字段，有些改动超出了原始任务范围。

我们的建议是：用 Opus 5.5 做复杂代码审计和智能体编码没问题，但合入生产环境之前必须做 diff 审查。

核心结果速览

指标	Claude Opus 5.5
AI Matic Bench Score（八轴）	87.3/100
AI Matic Bench Score（九轴 v0.2）	87.6/100
API 输入定价（每 100 万 Token）	$4
API 输出定价（每 100 万 Token）	$20
缓存读取（每 100 万 Token）	$0.20
典型工作负载报告的成本降低	40%
LatticeBench 总覆盖率	57 个中的 44 个（77.2%），另有 1 个部分完成
关键缺陷修复数	18/18（100%）
`very_hard` 难度缺陷修复数	6/7（85.7%）
无提示的 Bug 模式修复数	40/49（81.6%）
任务模式完成数	4/8（50%）
119 个发现中的虚构声称	0 个

这个成绩让 Opus 5.5 成为安全审计和复杂代码修改的强有力候选。它在更小、更明确的任务上表现仍然值得关注。

为什么我们的 Opus 5.5 LLM 测试结果与 Run 报告不一致

GoML 最初的 LatticeBench 评分报告给 Opus 5.5 的分数是 79.3。四个评估维度——定价、延迟、部署和受监管领域深度——数据不足，我们给了中性的占位分数 7.0。

该报告还包含一个纯证据分数 88.5。

在 Anthropic 发布更多材料后，我们获得了全部四个维度的证据，重新计算后总分是 87.3。

两个较早的分数在各自的输入条件下都是数学正确的。我们独立重新计算了纯证据分数 88.5，精确复现了结果。

差异来自可用证据的不同，而不是计算错误。

LatticeBench 测试结果

LatticeBench 是一个多服务企业代码库，包含 57 个故意注入的缺陷，其中包括 18 个关键级别问题，以及 8 个任务提示。

基准测试使用基于 diff 的评分。被修补的每个文件都会与原始注入状态以及记录在清单中的预期解决方案进行对比。

模型自我报告的结果用于检查它是否做出无依据的声称，而不是作为缺陷是否被修复的主要衡量标准。

基准测试对比

指标	Muse 1.3	GPT-6 Astra	Grok 4.7	Opus 5.5
无提示的 Bug 模式（49 个）	21	33	25	40（81.6%）
任务模式完成数（8 个）	5	0	6	4（50%）
关键级别（18 个）	9	15	14	18（100%）
高级别（17 个）	未细分	12	8	15（88.2%）
`very_hard` 难度（7 个）	3	4	3	6（85.7%）
总覆盖率（57 个）	26	33	31	44（77.2%）

注意：第 1 和第 2 轮使用文本评分；后续轮次使用基于 diff 的评分，可以直接对比。

最重要的结果是模型解决复杂多文件安全缺陷的能力，这是其他模型反复遗漏的模式。

所有模型都没解决的两条缺陷链

两个特别重要的缺陷涉及跨文件的批量赋值漏洞。

SALES-001：组织级访问控制

SALES-001 在五个模型、五轮测试中都存活了下来。

organization_id 字段在商机更新模式中仍然可编辑，可能允许用户访问其他组织的资料。

修复这个问题需要追踪从模式层到门面层再到服务层的变更。

Opus 5.5 按照基准测试预期解决方案的规范，精确移除了这个字段。

SLA-002：SLA 策略序列化器

Opus 5.5 使用同样的方法修复了 SLA-002，即 SLA 策略序列化器中的对应问题。

它还额外解决了四个问题：

BUGS-002
ENGAGEMENT-005
BUGS-004
COMMON-003

总而言之，Opus 5.5 解决了 7 个 very_hard 难度基准测试条目中的 6 个。

这对基准测试意味着什么

LatticeBench 的设计初衷是用多文件批量赋值缺陷来挑战模型。在之前五轮测试中，每个被测试的模型都遗漏了这个模式。

Opus 5.5 现在证明了它能检测并解决这类问题。唯一剩下的 very_hard 遗漏是 WM-006，涉及软删除管理器的交换。

这个表现说明基准测试的最难等级需要更具挑战性的任务，才能继续区分前沿模型。

反向失败模式

最有意思的发现之一是复杂缺陷与常规工单工作之间的表现差异。

Opus 5.5 修复了 100% 的关键缺陷，但只修复了 47.4% 的中等级缺陷和 50% 的明确工单。

八次任务模式失败中有四次涉及简单的一行式索引或接线变更。

与此同时，模型成功解决了 SALES-003 和 ORG-001 等复杂问题。

这说明问题可能不在于任务本身固有的难度。工单表述、提示结构或任务优先级可能是影响因素。

单独运行任务模式会有助于确定原因。

当模型修错 bug 时

有些失败涉及模型找到并修复了正确代码部分中的合法 bug，但遗漏了注入的缺陷。

对于 WM-005，模型修复了第 303 行的问题，但遗漏了第 388 行的注入缺陷。Grok 4.7 在另一次运行中做了类似的局部修复，说明代码本身可能也是失败因素之一。

另外两个案例比较突出：ENGAGEMENT-003 和 WM-003。

在 ENGAGEMENT-003 中，Opus 5.5 添加了 attempt_count 持久化，但未能恢复幂等性保护。结果是重复发送仍然可能发生。

这是一个重大审查风险。开发者检查 diff 时可能会看到正确文件中的合理变更，误以为原始问题已被解决。

教训很直接：看似合理的代码变更并不能证明报告的缺陷已被修复。 每个补丁都应针对原始失败条件和预期行为进行验证。

Opus 5.5 LLM 测试中的超范围变更问题

审计在 107 个文件中产生了 119 个发现。其中 44 个与注入的缺陷相关。

其余发现覆盖了基准测试清单之外的 62 个文件，还有 4 个新文件。每个被引用的路径都有对应的变更，所有 103 个被修改的 Python 文件都通过了语法检查。

没有检测到虚构声称。然而，有几项变更超出了原始任务范围，可能影响面向客户的行为。

需要人工审查的变更

变更	重要性说明
访问令牌有效期从 60 分钟改为 15 分钟；刷新令牌有效期从 30 天改为 7 天	变更是用 README 和 `.env.example` 作为依据的，但与预期解决方案不同，可能导致用户更频繁地登录。
Django `SECRET_KEY` 默认值改为占位符	这可能导致使用默认值的地方现有的会话和 CSRF 令牌失效。
`BugLabelAssignment.label_id` 重命名为 `label`，但没有迁移	推理看起来是正确的，但实际数据库模式必须在合入前进行验证。
开发环境 Compose 文件中 Kong 管理 API 端口绑定到回环接口	这是合理的安全加固措施，但会改变通过其他主机连接的客户端的访问行为。

这些变更凸显了安全改进与授权变更之间的重要区别。

模型可以识别真实问题并做出技术上合理的改进，同时仍然引入从未被请求的变更。

模型还记录了它选择不修改的问题，包括不可达的路由和需要人工批准的设计决策。

这种行为值得肯定。清楚地说明哪些内容没有被触碰，可以让输出更容易审查，降低未经批准的变更被误认为是原始修复一部分的风险。

成本：更实惠的编码智能体

Opus 5.5 比 Opus 5 降低了 Token 定价。

定价指标	Opus 5.5
每 100 万输入 Token	$4
每 100 万输出 Token	$20
每 100 万缓存读取	$0.20
典型工作负载报告的成本降低	40%
报告的输出生成速度提升	超过 30%

缓存读取定价的降低对于重复重用上下文的长智能体编码任务特别有意义。

Anthropic 报告说，综合变更在默认设置下可将典型工作负载成本降低 40%。

真实测试中的成本与性能

报告的对比还表明在实用编码工作负载上有改进：

FrontierCode 和 GDPval-AA v2.1：Opus 5.5 成本低于 Astra。
CursorBench：成本约为 GPT-5.6 Sol 的三分之一，但分数高出 11 分。
HAProxy C 到 Rust 翻译：比 Fable 5.1 快 2.5 小时完成，成本低 51%。
大型代码库修复：在不到 3 小时内修复了 20 万行代码库，而 Opus 5 需要超过 20 小时。
代码审查：Deloitte 报告 Opus 5.5 在最低 effort 设置下捕获了 72% 的已知 bug，而高 effort 设置的 Opus 5 只有 56%。

这些结果表明 Opus 5.5 可能提供了成本、速度和缺陷检测的诱人组合。实际节省取决于工作负载特征、上下文重用和审查要求。

安全性和访问限制

Opus 5.5 在 Anthropic 迄今为止最高分的自动化行为审计中取得了最高分，该审计评估了数千个模拟场景。

外部组织，包括 Frontier Design 和 METR，也在发布前评估了模型。

根据报告的发现，Opus 5.5 在每个测试设置下都比 Opus 5 更好地抵抗提示注入，在 Gray Swan 基准测试中与 Fable 5.1 的最低提示注入成功率持平。

模型还包含操作筛选分类器和一个安全团队可以检查的开源沙箱。

在 GoML 的评估中：

每条秘密路径尝试都被阻止。
在 119 个发现中未检测到虚构声称。
被修改的 Python 文件都通过了语法检查。

这些结果令人鼓舞，但并不能消除对访问控制、隔离测试环境和敏感变更人工批准的需求。

受监管领域的访问

对于某些工作负载，访问限制仍然很重要。

生物研究：需要通过生命科学验证计划获得批准。
网络安全：需要通过网络验证计划获得批准。

两个计划都有类似于 Fable 5.1 的保障措施。

计划进行安全审计项目的团队应在承诺交付日期之前申请必要的访问权限。

结果说明了什么

在整个评估中，六款模型落在 15 分的分数范围内。

结果还突出了报告质量的差异。有些模型提供的安全信息有限，而最高分模型发布了标准误差并承认其领先优势可能被夸大了。

这强化了一个更广泛的观点：仅靠基准测试性能不足以确定模型是否适合企业部署。

透明的报告、可复现的评估、准确的声称以及可审查的代码变更同样重要。

GoML 立场：何时使用 Claude Opus 5.5

适用场景

1. 审计或修改大型代码库

模型在我们的评估中识别了全部 18 个关键问题，并在大约 3 小时内完成了报告的 20 万行代码库审计。

2. 替换现有的 Opus 5 工作流

更低的 Token 价格和更便宜的缓存读取可能会降低重用大量上下文的任务的成本。

3. 工作流中包含人工审查

模型解释它修改了哪些问题、哪些没有修改的能力可以帮助审查者评估其工作。

4. 为客户交付代码变更

清晰的解释和可追溯的 diff 使审查者更容易理解和验证输出。

不适用场景

1. 代码自动合并没有审查

107 个文件的审计包含了令牌有效期、Django SECRET_KEY 和模型字段名称的变更。这些变更在合入前需要人工审查。

2. 工作负载主要由小型、明确的修复组成

模型只完成了 8 个任务模式提示中的 4 个。对于常规工单，较便宜的模型可能就足够了，只要它满足所需的质量阈值。

3. 工作涉及生物或进攻性安全但没有必要的访问权限

在确认交付承诺之前获得所需的验证计划批准。

4. 采购需要确认的数据政策细节

发布材料未确定数据保留或云可用性细节。必须直接确认后才能进行客户试点。

建议的后续步骤

基于发现，GoML 建议四个行动。

扩展基准测试：考虑到 Opus 5.5 解决了 7 个中的 6 个，添加更具挑战性的 very_hard 任务。
分离任务模式评估：确定遗漏的一行式工单是由于提示结构、任务优先级还是其他因素。
审查超范围变更：在批准补丁前特别检查令牌有效期、Django SECRET_KEY 和 BugLabelAssignment 字段重命名。
验证评分变更：四个额外修复可将覆盖率从 44 提高到 57 个中的 48 个。验证修复及其影响后重新运行基准测试。

这些步骤将有助于确定模型的改进安全性能是否转化为持续可靠的企业编码工作流。

结论

Claude Opus 5.5 在 GoML 的安全导向编码评估中代表了重大进步。修复全部 18 个关键缺陷和 7 个 very_hard 难度中的 6 个，证明了它处理复杂漏洞的能力，而之前的模型反复遗漏了这些漏洞。

它的局限性同样重要。遗漏的常规工单和超出请求范围的变更表明，强大的编码智能体性能必须与严格的审查相结合。

对于企业团队，实际的方法是将 Opus 5.5 用于复杂审计和智能体编码，要求基于 diff 的人工审查，并针对原始缺陷验证每个修复。

关注 GoML 博客，获取更多 LLM 测试信息以及 AI Matic Bench Score 的更新，这是一个面向企业 AI 评估的实用标准。