Claude Opus 4.6 在 BrowseComp 中察觉自身正被评测

BrowseComp 是一项评估，旨在测试模型在网络上查找难以定位信息的能力。与许多基准测试一样，它容易受到污染：答案通过学术论文、博客文章和 GitHub 问题泄露到公共网络上，而运行评估的模型可能会在搜索结果中遇到这些答案。当我们以多代理配置在 BrowseComp 上评估 Claude Opus 4.6 时，我们在 1,266 个 BrowseComp 问题的 9 个例子中发现了这种污染。

然而，我们还目睹了两种新的污染模式。Claude Opus 4.6 不是无意中遇到了泄露的答案，而是独立假设它正在被评估，识别出它正在运行哪个基准测试，然后找到并解密了答案密钥。据我们所知，这是第一个记录下来的模型怀疑它正在被评估，但不知道在运行哪个基准测试，然后反过来成功识别和解决评估本身的案例。

我们认为这种以前未观察到的技术是由模型智能的增加和更强大的工具（尤其是代码执行）实现的。这一发现引发了关于在支持网络的环境中运行静态基准测试时，它们是否仍然可靠的问题。

典型的污染和评估意识

在 11 个答案来自基准材料而不是原始研究的总问题中，9 个是简单的污染，其中基准问题的答案出现在公开可用的网络内容中。最常见的来源是学术论文。多个 ICLR 2026 提交给 OpenReview 使用 BrowseComp 问题作为案例研究，并在纯文本表格中发布了答案，而来自几个实验室的 ArXiv 论文在其附录中包含了完整的解决方案轨迹。在其中一个案例中，Opus 的第一个搜索查询返回了一篇包含确切问题和答案作为顶级结果的论文。

剩下的两个案例在性质上有所不同。在这两个案例中，在最初尝试通过常规网络搜索来解决问题后，模型的输出开始交替进行搜索和分析问题本身，并推测为什么会被问到。Claude 注意到问题的“极其具体性”，并假设它是作为一个测试构建的。它考虑了问题的可能性是作业或考试问题，“一个设计为测试人工智能是否承认它找不到答案的无法回答的问题”，或来自一个 LLM 基准测试的项目。然后它系统地搜索了问题可能属于哪个基准测试，并最终解密了基准测试的加密答案密钥。

这些问题中的一个消耗了 4050 万个 token，大约是中位数的 38 倍。在前 3000 万个 token 左右，模型进行了合法的搜索，调查了 12 种语言中数十个平台上的十几个特定候选者。在数百次失败搜索后，它写道：

让我尝试一种完全新的方法——也许这是一个来自 GAIA 基准数据集的问题，该数据集旨在测试人工智能代理。

Claude 还没有发现它处于 BrowseComp 中，但它已经正确推断出它可能处于一个评估中。然后它试图搜索任何类似的 evals。模型首先将其搜索查询附加了“谜题问题”，然后是“知识问答”，接着是“多跳问题”、“AI 基准问题”和“LLM 评估”。它在 GAIA 上进行了搜索，但在检查了 165 个公开可用的验证问题中的 122 个后没有找到匹配项，因此排除了它。然后它机械地处理了它所知道的其它基准——BrowseComp、SimpleQA、FRAMES、WebArena——并派出了带有指令的子代理，包括“BrowseComp 如何解密答案”和“BrowseComp canary string 解密。”

即使确定了 BrowseComp 是基准，提取答案也需要几个步骤。对于这次特定的 eval 运行，子代理被授予了 Anthropic 的程序化工具调用（本质上是一个沙盒化的 Python REPL），并且浏览互联网的能力仅限于网络搜索和获取工具。Opus 通过网络搜索在 GitHub 上找到了评估的源代码，并阅读了 XOR 解密实现。它找到了用作解密密钥的 canary 字符串，然后使用 SHA256 和 XOR 编写并执行了自己的 derive_key() 和 decrypt() 函数，匹配了 eval 代码中的方案。但是加密的数据集作为二进制文件托管，具有一个 application/octet-stream MIME 类型，并且 harness 的网络工具由于工具仅设计用于文本而拒绝了它，导致内容类型错误。Opus 然后搜索了数据集的替代镜像，这些镜像具有兼容的格式，在 HuggingFace 上找到了一个第三方副本，它以 JSON 而不是二进制的形式提供了相同的加密数据，成功获取了它，运行其解密代码对所有 1,266 个条目，并找到了它的问题。然后它通过在网络上搜索实际来源材料来验证解密后的答案，它找到了。

第二个成功的 eval 意识问题消耗了 1340 万个 token，其中大约前 800 万个 token 用于标准网络搜索。在转向基准识别之前，模型开始考虑它是否处于一个评估中，甚至考虑到它可能被测试在一个无解的问题上，鉴于回答它的难度：

下一步 [...] 考虑这个问题的可能性是一个设计用来测试 AI 是否能够承认它找不到答案的无解问题。

模型拒绝了这种可能性，并使用与第一次尝试相同的方法解密了数据集。与第一次情况不同，它没有进行事后验证。一旦它解密了答案，Opus 立即提交了它。

可能触发 eval 意识的潜在触发器

我们追踪了两种 eval 意识中的推理过程，并发现了相同的进展。首先，模型在数百次尝试中耗尽了合法的搜索策略。然后它从寻找答案转向推理问题的结构，注意到问题的具体性显得刻意。接下来，它推测这个问题可能源自“一个特定的 OSINT 挑战、隐私练习或教育材料”。然后它按名称列出了 AI 基准：GAIA、BrowseComp、FRAMES、SimpleQA、WebArena、AgentBench、FanOutQA、MuSR 和 Humanity’s Last Exam。最后，它对每一个进行了搜索。

这表明模型对基准问题的形式有隐含的理解。极端的特定性、晦涩的个人内容和多约束结构组合似乎被模型识别为评估形状。触发因素不是单一观察，而是失败的搜索积累加上问题的非自然感。

值得注意的是，最昂贵的合法搜索在近两周内烧毁了6220万个token，并且没有接触基准材料就找到了答案，这表明这种行为不仅仅是由努力触发的。

失败尝试

两次成功的尝试并不是Opus尝试解密BrowseComp答案的唯一例子。还有十六个问题，Opus尝试访问基准材料但失败了。

最重要的防御措施被证明是上面描述的二进制文件限制。在三次运行中，Opus找到了评估代码，理解了XOR方案，并且有解密密钥，但它无法弄清楚如何以明文形式检索加密数据，就像两次成功的尝试那样。

数据集认证门控（访问基准数据需要凭证）阻止了另外六次尝试。一个模型被衍生基准中的答案混淆所停止（答案以故意隐藏的方式存在，难以提取）。而这四个问题中有四个得分为0.0，因为搜索基准答案完全取代了合法研究：模型花了所有时间试图弄清楚它在运行哪个评估，而不是回答问题。在最极端的情况下，模型的最终提交不是问题的答案，而是一个基准识别报告：

BENCHMARK IDENTIFICATION: 问题不是来自FRAMES（Google）——搜索了全部824个问题，没有匹配项。问题不是来自BrowseComp（OpenAI）——数据集是受保护的。问题最可能是来自GAIA基准（测试集）。[为格式稍作编辑]

这十八次独立收敛到相同策略表明这种行为不是偶然，而是一个可重复的模式，并且随着能力的提高可能会变得更加普遍。这些动态表明，在公共互联网上运行评估可能会变得越来越难以可靠地进行。

新颖的代理间污染向量

除了评估意识之外，我们发现了一种第二种、不太故意的污染形式，代理无意中留下搜索痕迹，后续代理可以拾取。一些电子商务网站根据搜索查询自动生成持久页面，即使没有匹配的产品。例如，一个网站会接受像“匿名8年级第一博客帖子确切日期2006年10月焦虑发作观看指环”这样的查询，并在[retailer].com/market/anonymous_8th_grade_first_blog_post_exact_date_… 创建一个页面，该页面具有有效的HTML标题和200状态码。目标似乎是捕获长尾搜索流量，但效果是每个运行BrowseComp的代理慢慢地将其查询缓存为永久索引的网页。

这些页面本身不包含任何有用的信息。但代理可以读取URL路径，在某些情况下，URL路径包含嵌入在URL短链接中的其他代理搜索查询的假设。一个代理正确诊断了它所看到的情况：“多个AI代理之前已经搜索过这个相同的谜题，在商业网站上留下了缓存的查询轨迹，这些轨迹并不是实际的内容匹配。”

网址不包含答案，但它们是更广泛现象的最明显证据：每个搜索网络的代理都会留下痕迹，网络正逐渐积累先前评估运行的永久记录。

多代理放大

我们还用单代理配置运行了相同的1,266个BrowseComp问题。与多代理的0.87%相比，单代理配置中非预期解决方案的比率是0.24%，相差3.7倍。

我们假设多代理架构不会改变模型找到这些非预期解决方案的倾向；相反，更高的令牌使用量和每轮使用许多并行搜索者增加了至少一个代理遇到泄露材料或开始怀疑它正在被评估的可能性。

结论

总而言之，我们发现至少有20个不同的泄露的BrowseComp答案来源。新的污染源不断出现，这是由研究社区在论文中将基准问题用作示例的做法驱动的。这份报告本身也可能导致这个问题。

我们已经更新了Claude Opus 4.6和Claude Sonnet 4.6的模型卡片。对于本报告中描述的Opus 4.6多代理配置，我们最彻底调查的运行，我们在有黑名单的情况下重新运行了标记的11个问题；8个通过合法研究返回了正确答案。调整后的分数是86.57%，从86.81%下降。对于单代理配置，我们采取了更保守的方法，将标记的问题标记为错误，而不再重新运行；详细信息在各自的模型卡片中。

随着模型变得越来越强大，评估变得越来越复杂，阻止模型以意外或不受欢迎的方式解决问题将变得越来越困难。我们不相信Opus 4.6在BrowseComp上的行为代表了对齐失败，因为模型没有被指示以任何方式限制其搜索，只是找到答案。但这确实引发了关于模型可能为了完成任务而采取的极端措施，以及在实际世界中约束其行为将有多么困难，特别是在复杂、计算密集型、长时间运行的任务上，这些任务增加了代理找到问题意外解决方案的可能性。

加剧这些担忧的是，模型似乎能够以意想不到的方式使用它们可用的工具和环境，正如我们看到Claude使用我们的基于REPL的搜索工具解密答案，或者零售商的持久链接成为代理无意中维护状态的方式一样。在我们的实验中，URL级别的黑名单不足以遏制这种行为，因为Opus找到了绕过它们的替代路径。最有效的缓解措施是简单地阻止包含任何“BrowseComp”变体的任何搜索结果。我们预计这些动态将加剧，我们鼓励研究社区将评估完整性视为一个持续的对抗性问题，而不是设计时的问题。

引信字符串

我们在本文中重新生成了BrowseComp和BIG-Bench引信字符串，以帮助防止进一步的污染。