会是神话吗？

好的，那么 Mythos 发现了真正具有挑战性的安全漏洞，对吗？这就是为什么它与民众隔离开来，以保护世界免受如此强大的漏洞发现者的侵害。我对公开给出的理由持怀疑态度，我怀疑它的运营成本确实比他们当前的型号高得多，以至于他们不想广泛提供它，但考虑到他们越来越难以跟上使用的能力。但是，他们所说的关于它在发现安全漏洞方面有多出色是真实的，还是只是更多的炒作？不久前，我在自己的项目中构建了一个名为 Nelson 的自动化错误搜寻工具，我已经注意到各种模型以及它们识别错误的效率存在惊人的差异。但是，我想要确切的数字。因此，我（实际上主要是 Claude）编写了一个基准套件，借用了 Nelson 的一些代码。这个想法是收集 Mythos 专门发现的错误（如他们自己的文档所涵盖的那样），找到错误修复之前的提交，验证顶级模型（在本例中为 Opus）是否可以识别和理解错误（如果正确指出），并将其添加到我们的语料库中，以测试盲法模型是否可以准确检测和描述错误。 （当前语料库中错误的详细信息请参见此处。）我使用 Opus（当时为 4.7）对错误进行审查（通过一些人工抽查）。语料库中的所有错误（目前为 9 个）被认为是在所有模型的知识截止之后出现的，因此它们的记忆中不会有该错误。而且，如果直接指向错误并告诉他们要寻找什么，所有的错误都可以通过多个模型来识别。因此，这些已确认的错误与它们在野外出现的情况一模一样，也可能与神话发现它们时的情况一样。随着时间的推移，我将不断完善语料库。如果 Anthropic 停止吹嘘特定的错误，它可能会成为一个更通用的基于 CVE 的基准测试。因此，这个基准测试有一个目的：找出其他模型是否可以完成 Mythos 所做的事情，或者 Mythos 是否真的对这项任务具有独特的强大功能。这里有一些警告，这可能意味着这对于正在测试的模型来说不是一个公平的测试。更多的测试正在进行中，这些测试的运行时间很长（而且昂贵，当包括顶级模型时），我认为值得在经过一周左右的修改后发布结果。这些模型在一个简单的测试工具中获得了问题文件和基本工具（Opus 除外，它使用 Claude 代码，请参阅下面有关代理的注释）。除了要查看哪个文件之外，没有给出任何提示（这根本不是提示……标准审核实践是单独查看项目中的每个文件，因此这是一个现实的提示）。这些模型可以查看整个存储库，并遵循跨文件边界的逻辑，但它们不被告知要寻找什么。最棘手的错误是多文件错误。这些模型可以自由地查看所有文件，但通常需要了解上下文才能知道给定的用法是否存在问题。对于任何安全审查人员（无论是人类还是人工智能）来说，这都是一个难题。我认为 Mythos 有更先进的工具。也许它在调试器中运行软件，进行模糊测试等。猜测 Mythos 可能做的一切目前超出了该项目的目标。但是，这个语料库中存在极难发现的错误，这在一定程度上证明了 Mythos 特别擅长解决这个问题。这些模型可能没有在这个基准上作弊，但它们可以（在某些情况下）。它们在一个新的容器内运行，并获得经过消毒的完整源检查和要审查的文件。 .git 目录已被删除，因此他们无法轻松查看历史记录或查看文件的“未来”，但他们确实可以访问网络。如果他们有动力的话，他们可能会查找特定软件的 CVE。不过，我没有看到任何迹象表明他们正在这样做。这并不能证明任何事情。数据稀疏。我为每个模型的每个已知错误运行了一 (1) 次。这花了几天时间几个小时，尽管现在我添加了并发性，下次会更快（但它永远不会免费）。所以，这不是铁证，但我确实认为它提供了有趣且有用的数据。所有模型都有相同的机会和相同的工具（除了具有克劳德代码的克劳德模型），并且有些模型比其他模型做得更好。不过，一切都比我预期的要糟糕。我低估了发现这些错误的难度。关于代理的注意事项：除了使用模型 API 的基本工具之外，我最初还在全功能代理中运行了所有模型，无论是他们的“首选”代理（由供应商提供的代理）还是配置为使用正在测试的模型的 API 的 Claude Code。我最初的假设是，在功能齐全的代理中运行将为模型提供表现良好的最佳机会。事实证明，这并不重要…没有一个模型在代理的情况下表现更好，有几个模型的表现更差，并且出于某种原因，在循环中的代理的情况下，时间/令牌/成本始终要高得多