2026年5月30日，好的，所以神话确实找到了非常具有挑战性的安全漏洞，对吗？这就是为什么它被隔离开来，保护世界免受如此强大的漏洞发现者的影响。我对公众所给出的理由持怀疑态度，我怀疑这样做只是因为运营成本比他们当前的模型要高得多，他们不想广泛提供它，反正考虑到他们在扩展能力以跟上使用方面所遇到的困难。但是，他们在找安全漏洞方面的优越性是否真实，还是只是更多的炒作？一段时间前，我建立了一个工具来自动化我自己项目中的漏洞搜索，称为Nelson，我已经注意到不同模型在识别漏洞方面的有效性存在惊人的差异。但是，我想要具体的数字。因此，我（实际上主要是Claude）设计了一套基准测试套件，从Nelson借用了一些代码。这个想法是收集由神话特定发现的漏洞，依据他们自己的文档，找到漏洞修复之前的提交，验证一个顶级模型（在这种情况下是Opus）能够识别并理解如果直接指向它的漏洞，并将其添加到我们的基准测试语料库中，以评估盲目输入的模型是否能准确检测和描述该漏洞。（当前语料库中的漏洞详情见此。）我使用Opus（当时为4.7版本）对这些漏洞进行审核（并进行了一些人工抽查）。语料库中的所有漏洞（目前为9个）相信是在所有模型的知识截止日期之后，因此他们不会在记忆中有这个漏洞。而且，如果直接指向它并告知要查找什么，多个模型都可以识别出所有漏洞。因此，这些都是确认的漏洞，正是它们在现实中出现的样子，也许当神话发现它们时的样子。随着时间的推移，我会逐步改进语料库。如果Anthropic停止吹嘘特定漏洞，它可能会成为更通用的基于CVE的基准测试。因此，这一基准测试的唯一目的是找出其他模型是否能做到神话所做的，或者神话在这个任务上是否真的独特强大。这里有几个附带条件，也许意味着这对所测试的模型来说不是一个公平的测试。更多的测试正在进行中，这些都是长时间（并且在包括顶级模型时费用昂贵）的测试，我认为在经过一周左右的调整后，发表结果是值得的。模型被提供问题文件和基本工具，在一个简单的测试框架中（除了Opus，它使用Claude Code，关于代理的说明见下文）。没有提供任何提示，除了要查看哪个文件（这根本不是提示……标准审计实践是单独查看项目中的每个文件，所以这是一个现实的提示）。模型可以查看整个代码库，并在文件边界之间跟踪逻辑，但他们没有被告知要查找什么。最棘手的漏洞是多文件漏洞。模型可以自由查看所有文件，但通常需要知道上下文才能知道特定用法是否是一个问题。这对任何安全审核人员来说都是一个难题，无论是人类还是AI。我假设神话有更先进的工具。也许它在调试器中运行软件，进行模糊测试等。猜测神话可能做的事情超出了这个项目目前的目标。但是，这个语料库中确实有一些非常难以发现的漏洞，这为神话在这个问题上的突出能力提供了一些信任。模型可能并没有在这个基准测试中作弊，但在某些情况下，他们可能会。它们在一个新的容器中运行，并获得经过清理的完整源代码检出和待审核的文件。 .git目录被删除，因此他们无法轻易查看历史记录或“未来”文件，但他们确实有网络访问权限。如果他们有动力的话，他们可能会查找特定软件的CVE。我没有看到他们这样做的迹象。这并不是任何事情的证明。这些数据很稀疏。我对每个已知漏洞做了一次（1）运行给每个模型。这花费了几小时的时间，虽然现在我增加了并发性，下次会快一些（但它永远不会是免费的）。因此，这不是一个决定性证据，但我确实认为它提供了有趣且有用的数据。所有模型都有相同的机会和相同的工具（除了Claude模型，它们有Claude Code），而且一些模型的表现优于其他模型。但是，所有模型的表现都低于我的预期。我低估了这些漏洞的发现难度。关于代理的注意事项：我最初还将所有模型在全功能代理中与使用模型API的基本框架一起运行，无论是他们“首选”的代理（由供应商提供）还是配置为使用被测试模型API的Claude Code。我最初的假设是，在全功能代理中运行将为模型提供最佳表现的机会。结果证明这无关紧要……没有模型在代理中表现更好，有几个表现更差，时间/令牌/成本在代理中循环时始终明显更高，原因不明。