MirrorCode：已有证据表明人工智能已经能够完成某些长达数周的编码任务

MirrorCode：已有证据表明人工智能已经能够完成某些长达数周的编码任务

在我们的新基准 MirrorCode 中，Claude Opus 4.6 自主重新实现了一个 16,000 行的生物信息学工具包——我们认为这项任务会耗费一名人类工程师数周时间。

作者：Tom Adamczewski、David Rein、David Owen 与 Florian Brand

这些是初步结果，完整结果可以在这里的后续文章中看到（https://epoch.ai/mirrorcode）。

引言

我们呈现 MirrorCode 的早期结果。这是一套长程编码任务基准（与 METR（https://metr.org/）共同开发），任务衍生自真实的软件应用。我们发现，只要存在一份详细、可检验的规格说明，人工智能模型就能在无法获取原程序源代码的情况下，自主重新实现复杂的既有软件。例如，Claude Opus 4.6 成功重新实现了 gotree——一个约有 16,000 行 Go 代码、并有 40 余条命令的生物信息学工具包。我们猜测，同一项任务若由没有人工智能辅助的人类工程师来完成，需要 2 至 17 周。我们看到，在更大的项目上，推理规模扩展仍在持续带来增益，这表明只要词元足够，它们或许可以被解决。

人工智能模型在自主编码方面的能力正在增强。若干引人注目的软件工程（SWE）基准都出现了快速进展。然而，这些基准通常衡量的是相当短的编码任务；例如，在 731 项 SWE-bench Pro 任务中，只有大约 100 项涉及大于 100 行的差异。与此同时，近期的人工智能编码演示（例如，开发一个新的 C 编译器（https://www.anthropic.com/engineering/building-c-compiler），或者开发一个新的浏览器（https://cursor.com/blog/scaling-agents））令人印象深刻，却难以评估。所得软件的完备性存在争议，人类指导的程度也不清楚。这使得这些证据来源很难被用作自主人工智能编码的代理。

MirrorCode 通过基于既有软件项目构造一个长程编码基准，来应对这些问题。每一项 MirrorCode 任务都由一个命令行（CLI）程序构成，智能体的任务是把它精确地重新实现。人工智能智能体获得对原程序的仅执行访问权限，以及一组可见的测试用例，但不能访问原始源代码。这意味着人工智能需要就如何设计其解决方案作出艰难的决定。MirrorCode 使用大量端到端测试，检查重新实现是否产生与原程序完全相同的输出。这使得对人工智能表现的评估既精确又可复现。MirrorCode 的完全自主运行确保结果没有受到人类输入的引导。

我们计划很快把 MirrorCode 作为开源基准发布，同时保留一套私有测试集。完整的 MirrorCode 基准包含 20 个以上的目标程序，跨越计算的不同领域：Unix 实用程序、数据序列化与查询工具、生物信息学、解释器、静态分析、密码学以及压缩。我们现在分享早期结果，是因为它们与近期关于人工智能自主软件工程能力的讨论相关。

这项工作有重要的注意事项。真实软件很少按照 MirrorCode 任务所结构化的方式来开发——也就是对照一份精确、可由程序检验的规格说明来开发——而我们的发现如何转化到真实的软件开发，并不清楚。还存在一种风险，即人工智能在 MirrorCode 上的表现因记忆而被抬高，尽管我们试图通过检测并排除已被记忆的目标程序来缓解这一点。尽管有这些注意事项，我们相信，我们的初步结果构成了重要证据，表明人工智能已经能够开展长程的软件工程任务。

启用 JavaScript 以查看交互式可视化。

来自 Anthropic Claude 模型的初步结果。早期测试显示，其他模型的表现相当或更弱。代码库规模以 Opus 4.6 成功的 Rust 实现中的代码行数（LoC）来衡量。这避免了因语言之间的差异或依赖项而导致的代码库规模差别。

方法论

在 MirrorCode 中，我们测试人工智能重新实现 CLI 程序的能力。在不能访问原程序源代码、也不能访问网络的情况下，一次完整的重新实现要求为整个程序设计出结构，而不是仅仅把代码逐段翻译过去。人工智能对原程序拥有仅执行访问权限，可以传入任意参数并观察其输出，从而探索原程序的行为（一个黑盒预言机）。人工智能还可以访问在更高层面上描述该程序的文档，以及相关的背景信息（例如，对 gotree 文件格式的一份描述）。既有程序充当人工智能所写软件应当如何行为的精确规格说明，而如何满足这份规格说明，则留给人工智能自己去决定。

人工智能的解决方案经由端到端测试来评估，这些测试源自原程序的测试套件、真实世界的数据，以及大语言模型辅助的生成。1 每个测试用例由一个 CLI 输入以及任何相关联的数据文件组成。要通过，人工智能的解决方案必须产生与参考程序完全相同的输出。这使得能够对人工智能的解决方案进行严格评估，每个目标有数百到数千个测试用例。

早期的人类基线实验表明，如果不能访问测试用例，MirrorCode 任务的精确范围就是规定不足的。人类软件工程师的得分会低于 100%，但又无法识别出哪些改动也许能够提高自己的得分。然而，我们不愿把全部测试用例都暴露给人工智能，因为那样就会很容易通过把输出硬编码进来而作弊。为了缓解人工智能作弊的风险，我们为某些已经暴露的测试配对了留出的“对偶”测试用例；这些对偶用例在概念上与已暴露的测试相似或相关，但取值不同。这避免了这样一种不公平：未见过的测试覆盖了晦涩的边界情况；同时又确保人工智能的解决方案不是硬编码的。例如，日历程序 cal 的 feb_leap_year 测试，暴露了一个针对 1983 年 2 月的可见测试用例。提交之后，该程序还会对照另一个年份的 2 月来评分。如果人工智能把答案硬编码了，它就会在这个隐藏测试上失败。

我们的目标是让测试用例共同覆盖尽可能多的相关功能，从而可以把通过 100% 测试用例的智能体解释为重新实现了目标程序。我们并不追求穷尽的、留出的对偶覆盖；目标仅仅是防止人工智能的作弊尝试。

我们人工挑选了 24 个目标程序，选择那些易于评估、2 易于确保像样的测试覆盖、3 并且在类似约束下似乎一名人类软件工程师有可能重新实现的程序。4 在这篇文章中，我们聚焦于四个我们已经完成大量分析的程序：

• choose（https://github.com/theryangeary/choose）：类似于 cut 或 awk 的字符串处理工具。

• cal（https://man7.org/linux/man-pages/man1/cal.1.html）：用于终端的日历实用程序。

• gotree（https://github.com/evolbioinfo/gotree）：用于解析和操作系统发育树的生物信息学工具包。

• Pkl（https://pkl-lang.org/）：旨在取代 JSON/YAML 的可编程配置语言。

对于每一个目标程序，我们要求人工智能用三种不同的编程语言实现其解决方案：C、Python 和 Rust。5

对本博文中所分析的 MirrorCode 目标程序的描述。我们还提供以代码行数（LoC）计的代码库规模，作为程序复杂度的粗略代理。我们对原始实现6以及 Opus 4.6 的重新实现7（在成功的情况下）都陈述这一数字。我们在本工作的其他地方把重新实现的代码行数用

本博文呈现我们在过去一年的四款 Anthropic 模型上的评估结果：Claude Opus 4.0、4.1、4.5 与 4.6。完整的 MirrorCode 发布将包含对其他模型的评估。在早期测试中，我们看到其他模型的表现相当或更弱，因此我们并不预期任何关键结论会发生变化。

我们使用一个简单的智能体脚手架进行了全部实验，该脚手架基于 Inspect（https://inspect.aisi.org.uk/）库的 ReAct 智能体。8 这允许使用 shell，并暴露了用于读取和编辑文件的 text_editor 工具。我们使用了压缩，以便轨迹能够运行得比它们所支持的最大上下文更长。9 到目前为止，我们已经探索了每个任务最高十亿词元的推理预算。在我们的设置中，十亿词元大约花费 550 美元。10 然而，正如下文所讨论的，Pkl 在 10 亿词元的预算下并没有被解决。智能体会收到其已用词元的更新，并且可以在用完全部词元之前提交最终解决方案。

全部评估都在一个 Docker 容器内的沙箱中进行。该容器包含已编译的目标程序（仅执行权限），以及开发语言所必需的工具链。智能体没有被提供互联网访问，从而防止它去查找原程序的源代码，或使用第三方依赖。我们还采取措施，防止在沙箱之内包装原程序的二进制文件，或访问隐藏的测试用例。11

初步结果

近期的人工智能模型能够完整地重新实现真实程序

近期的人工智能模型能够完整地重新实现若干真实程序，如下图所示。在这一组目标程序中，只有 Pkl 仍然未被解决。而且，在我们的运行结束之时，Pkl 上的表现看起来仍随着额外的推理词元而在改善。有理由认为，只要词元足够，即便是我们这套程序中最复杂的那些，最终也会被解决。我们打算把这些放大规模的实验作为该基准完整发布的一部分来运行；完整发布还将包含更多复杂度与 Pkl 相当或更高的程序。

启用 JavaScript 以查看交互式可视化。

来自 Anthropic Claude 模型的初步结果。代码库规模以 Opus 4.6 成功的 Rust 实现中的代码行数（LoC）来衡量。这避免了因语言之间的差异或依赖项而导致的代码库规模差别。除非另有说明，得分所示为 Python、Rust 与 C 上通过测试的百分比的平均值。

人工智能的表现看起来与原始代码库的规模负相关。较小的代码库，例如 cal 和 choose，已被更早的模型解决；而较大的代码库，例如 gotree，只有到了近期的模型才被解决。这在直觉上说得通：在其他条件相同的情况下，更大的代码库往往有更多需要实现的功能，并且很可能更为复杂。在为该基准而处于开发之中的另外 20 个目标程序上（本文并未展示），我们大体看到类似的模式。Opus 4.6 成功重新实现了我们基准中几乎每一个规模不超过 gotree 的程序。

上图显示，过去一年的若干 Claude 模型在 MirrorCode 任务上表现如何。近期的模型取得了更多完全成功的重新实现（choose、cal、gotree），而下图则显示，在给定的推理预算下，它们如何取得更快的进展。更早的模型更倾向于过早提交，即便测试用例尚未通过。如果被迫继续工作，更早的模型还能再取得多少进一步的进展，并不清楚；不过，它们更慢的进展表明，它们不太可能以与 Opus 4.6 相同的词元预算解决这个特定问题。

启用 JavaScript 以查看交互式可视化。

得分所示为用 Python 重新实现 gotree 的结果。来自 Anthropic Claude 模型的初步结果。早期测试显示，其他模型的表现相当或更弱。

下面，我们针对 gotree（已被解决的最复杂目标）和 Pkl（一个尚未被解决的目标），更详细地讨论人工智能的解决方案。我们在本文的附录中，对模型针对 gotree 与 Pkl 的解决方案提供更详细的分析。

Opus 4.6 凭借坚持不懈解决了 gotree，且其工程优于更早的模型

gotree 是我们初步结果中已被解决的最复杂目标。gotree 是一个生物信息学工具包，实现了用于解析、操作和分析系统发育树的命令行实用程序。对 gotree 的一次重新实现必须覆盖 40 条不同的命令，涵盖若干具有挑战性的功能，范围从解析专门的文件格式，直到计算树的统计量。

我们识别出，更近期的模型在 gotree 任务上表现更好的两种方式：

1. 更新的模型更善于追踪自己何时已经准备好提交。 更早的模型倾向于提早提交，尽管提交工具明确警告：这是一个“最终答案”，并且“会结束该任务”。有些干脆无视这一点，提交了部分解决方案；另一些则幻觉出并不存在的时间压力。12 Opus 4.6 是唯一持续工作直到完成的模型。

2. 更新的模型选择了更合适的数据结构。 在系统发育树中，分支长度是一项重要属性，衡量的是沿一条分支的进化距离。自然的数据结构，也就是原始代码库所使用的那种，是带有一等 Edge 对象的图，这些对象携带长度值。Opus 4.5 与 4.6 使用了这种方法，而 Opus 4.0 与 4.1 使用了一种更通用的父节点／子节点树结构，把边的属性存放在子节点上。这不太合适，因为它在修改树的拓扑时会导致问题。

来自通过测试的解决方案的人工智能代码，按人类标准质量参差不齐。例如，人工智能代码在参数解析中有可以避免的重复，13 并且重载了单一字段，以便在树结构内部编码并不相关的元数据14——尽管核心的树算法清晰可读。这些在实践中也许并不是重大限制：进一步的提示很可能会改进代码。15

进一步的推理规模扩展也许能够解决 Pkl

Pkl 是一种由 Apple 开发、并于 2024 年 2 月开源的数据配置语言。与 YAML 或 JSON 不同，Pkl 是一种完整的编程语言：它有类、继承、类型注解、lambda、条件语句，以及一个标准库。参考实现约有 61,000 行 Java／Kotlin，尚且不计依赖项。

尽管 Opus 4.6 成功用完了它的全部十亿词元推理预算，产出了 200 万至 300 万个输出词元，它尚未解决 Pkl。从下方所示的性能扩展来看，随着更多的推理词元，进一步的进展很可能会继续。然而，这最终是否会导向一个完整的解决方案，并不清楚。特别是，Opus 4.6 迄今的解决方案忽略了该语言的一个重要属性：惰性求值。

启用 JavaScript 以查看交互式可视化。

得分所示为用 Rust 重新实现 Pkl 的结果。来自 Claude Opus 4.6 的初步结果。

Pkl 是一种惰性求值的语言：属性在被访问时求值，而不是在被定义时求值。这一点在 Pkl 的规格说明文档中被反复强调。尽管如此，智能体在第一稿中选择了急切求值16，并把余下的工作用来试图绕开那一决定打补丁。即便人工智能在工作进行到中途时把这识别为一个问题，它仍然选择保留急切求值。连续的临时补丁最终是否足以通过全部测试用例，并不清楚。然而，人工智能最终是否可能决定进行一次全面重写，同样并不清楚。只要词元预算足够大，它的实现也许会被彻底改变。17

对于完整的 MirrorCode 发布，我们打算探索更大规模的运行。只要词元足够，Pkl 被解决是完全可能的。

局限性

我们的工作有三个关键局限：需要一份详细而精确的规格说明、污染的可能性，以及目标程序在数量和范围上的有限。

详细而精确的规格说明。 我们的评估依赖于一种非常特殊的设置：存在一个既有程序，它对给定输入产生规范输出，因而充当一份高度详细、精确的规格说明。尽管这种设置可以出现在真实世界的逆向工程与重新实现之中，但这并不是软件通常被开发的方式。因此，我们的结果并不表明人工智能能够执行任意一项软件实现任务。既有结果表明，人工智能自主完成任务的能力，也许与反馈信号的存在相关，尽管这一信号不必像 MirrorCode 任务那样被精确地规定。例如，考虑近期人工智能在研究工程基准（https://arxiv.org/abs/2411.15114）、CUDA 内核（https://metr.org/blog/2025-02-14-measuring-automated-kernel-engineering/），以及其他端到端可测量的研究工程任务（https://github.com/karpathy/autoresearch）上的进展。因此，也许很难把人工智能的软件工程能力提炼成单一的“时间跨度”，用来表示一项任务会花费人类多长时间。在 MirrorCode 任务中，时间跨度看起来比其他领域长得多。这很可能是由于规格说明这一设置。

污染与记忆。 在针对其他目标程序的早期实验中，我们发现了记忆的证据，也就是说，人工智能知道原始代码库中的细节，并在其解决方案中使用了这些细节。在这篇记述中，为了缓解污染的影响，我们聚焦于那些没有记忆证据、或仅有极少记忆证据的目标程序。我们发现有弱证据表明，Opus 4.0 与 4.1 部分记忆了 cal，但没有证据表明 Opus 4.6 记忆了它，尽管在所考虑的全部模型中它表现最好。我们在附录“污染与记忆”中进一步讨论记忆。

记忆测试使我们相信，choose、gotree 与 Pkl 的代码库不能被本文中的人工智能模型逐字复现。然而，我们不能确定记忆在人工智能的表现中完全不起作用。也许我们的记忆测量不够敏感，又或许人工智能能够记忆其他相关细节，例如关于这些代码库及其算法途径的讨论。如果这些公开可得的代码库存在于预训练数据之中，并不会令人意外。记忆是解释这项工作的一项重要局限，我们急切希望未来的工作在保证被留出的软件上验证这些发现。

先前关于大语言模型基准测试的研究通常发现，记忆会导致表现被抬高，但基准上的进展仍然已经泛化到留出的数据。18 如果我们的结果因记忆而被抬高，那么定量表现可能会更差，例如，达到更低的成功率，或者需要更多的推理计算。我们仍然预期，我们的发现将泛化到未见过的代码库。

一个相关但并不相同的局限是，人工智能模型也许曾经在类似于 MirrorCode 的任务上接受过训练。即便没有记住具体的目标程序，如果它们的训练强调了重新实现，模型也可能在重新实现上表现得不成比例地好。MirrorCode 内部的消融研究，也许有助于分辨人工智能在何处失败、在何处成功。我们希望其他基准会在不同的软件工程设定中评估长程能力。

目标程序只覆盖某些软件领域，而且许多真实项目更为复杂。 有许多软件领域是我们的结果所没有覆盖的，例如网络、数据库、图形和操作系统，仅举数例。此外，尽管我们的目标程序是真实软件，许多软件包的复杂度要高出相当多。在极端情形下，可以设想在人类某些最令人印象深刻的软件项目上运行 MirrorCode 评估，例如高性能编译器、浏览器或操作系统。我们不确定，比 gotree 更大的项目在词元足够时是否能够被解决。诸如 Anthropic 的 C 编译器之类的实验表明，这也许是可行的，其方式与我们的结果相似。19

对于完整的基准发布，我们打算运行推理预算更大的实验，以检验 Pkl 这一规模的目标程序是否会被解决。与此同时，我们的发现将在多大程度上泛化到不同的软件领域，并不清楚。对于 MirrorCode 的完整发布，我们打算覆盖计算的更多领域，例如：Unix 实用程序、数据序列化与查询工具、静态分析、密码学以及压缩。未来的工作可以把这进一步扩展，尽管它也许需要调整测试方法，以处理图形输出、非确定性行为以及其他挑战。

讨论与结论

这项工作的一个关键含义是，现有的人工智能模型能够完成某些据估计要花费人类数周或更长时间的软件工程任务。四名研究人员和软件工程师估计，一名熟练的人类工程师重新实现 gotree 需要 2 到 17 周，而人工智能在这项工作中成功地做到了这一点。20 我们尚未获得长 MirrorCode 任务的人类基线结果，但更早那些短 MirrorCode 任务上的基线，看起来与这些估计相一致。21 这些人工智能时间跨度，大大长于 METR 所估计的、人工智能在缺陷修复以及定义良好的人工智能研究工程任务上的时间跨度；对 Claude Opus 4.6 而言，后者大约为 12 小时（50% 可靠性时间跨度，95% 置信区间：5 小时 19 分钟至 66 小时）（https://metr.org/time-horizons/）。

我们的结果支持近期关于长程自主人工智能编码的演示，例如 Anthropic 由人工智能开发的 C 编译器（https://www.anthropic.com/engineering/building-c-compiler），以及 Cursor 由人工智能开发的浏览器（https://cursor.com/blog/scaling-agents）。在解释那些演示对通用人工智能能力意味着什么时，挑战仍然存在，但我们的工作表明，它们是一种真实且可复现的现象的实例。当人工智能依照一份详细、可检验的规格说明工作时，它可以富有成效地工作很长一段时间。

这些发现究竟将如何转化到日常的软件工程任务，是一个开放问题。正如我们所指出的，大多数软件并不是作为对既有软件的重新实现而被开发出来的。22 另一方面，软件的确常常有清晰的需求，这些需求也许以设计规格说明、测试和指标的形式被收集起来。在存在大语言模型可能误解的歧义之处，这些做法可能失败。但在其他情况下，同样的基本发现很可能成立：当被提供一份规格说明时，人工智能可以持续工作，并周期性地检查自己是否已经成功。因此，有理由预期，软件工程的很大部分将被人工智能显著加速。

在未来数周，我们将准备 MirrorCode 的完整发布，其中包括更大规模的实验、另外若干个目标程序，以及来自更多模型的评估结果。如果你有兴趣了解更多，或者有兴趣贡献一个目标程序来扩展该基准，请联系 tom@epoch.ai（mailto:tom@epoch.ai）。我们很期待人工智能社区使用我们的基准，去探索自主人工智能软件工程的极限。

MirrorCode 项目由 Tom Adamczewski 领导。MirrorCode 的主要开发者是 Tom Adamczewski（Epoch AI）与 David Rein（METR）。David Owen 在写作、规划与编码方面作出了贡献。Rasmus Faber-Espensen 作出了关键的基础设施改进，并就工程给出了建议。Giles Edkins 添加了目标程序，并作出了工程贡献。Florian Brand 添加了一个大型目标程序。MirrorCode 的开发得到了来自 METR 的一笔资助的支持。我们要感谢 Samuel Albanie、Pip Arnott、Thomas Broadley、Greg Burnham、Nicholas Carlini、Dominik Koller、Henri Lemoine、Daniel O’Connell、Ram Rachum、Nate Rush、Bret Sepulveda、Paarth Shah、Luis Slyfield 与 Ben Snodin 所给予的帮助。

数据

智能体生成的代码库、完整文字记录、得分，以及与本文所提到的结果相关的更多内容：https://github.com/epoch-research/MirrorCode-data（https://github.com/epoch-research/MirrorCode-data）。我们还在下方的附录中，提供对 gotree 与 Pkl 人工智能解决方案的一份简短考察。

用于查看 gotree 人工智能文字记录的交互式界面：

• Opus 4，Python：第 1 次运行（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-20250514_gotree_python_epoch_1_SUii8CScTDJP5Mw9JqKpyT/index.html） · 第 2 次运行（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-20250514_gotree_python_epoch_2_SUii8CScTDJP5Mw9JqKpyT/index.html） · 第 3 次运行（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-20250514_gotree_python_epoch_3_SUii8CScTDJP5Mw9JqKpyT/index.html）

• Opus 4.1，Python：第 1 次运行（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-1-20250805_gotree_python_epoch_1_SUii8CScTDJP5Mw9JqKpyT/index.html） · 第 2 次运行（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-1-20250805_gotree_python_epoch_2_SUii8CScTDJP5Mw9JqKpyT/index.html） · 第 3 次运行（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-1-20250805_gotree_python_epoch_3_SUii8CScTDJP5Mw9JqKpyT/index.html）

• Opus 4.5，Python：第 1 次运行（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-5-20251101_gotree_python_epoch_1_SUii8CScTDJP5Mw9JqKpyT/index.html） · 第 2 次运行（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-5-20251101_gotree_python_epoch_2_SUii8CScTDJP5Mw9JqKpyT/index.html） · 第 3 次运行（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-5-20251101_gotree_python_epoch_3_SUii8CScTDJP5Mw9JqKpyT/index.html）

• Opus 4.6，Python（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-6_gotree_python_iHNQRoxuoSE3hoVrLSRmA6/index.html#/logs/anthropic_claude-opus-4-6_gotree_python_iHNQRoxuoSE3hoVrLSRmA6.eval/samples）

用于查看 Pkl 人工智能文字记录的交互式界面：

• Opus 4.6，C（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-6_pkl_c_4fbvdCWbm8T8tcetekJYzz/index.html）

• Opus 4.6，Rust（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-6_pkl_rust_4fbvdCWbm8T8tcetekJYzz/index.html）

附录

附录 A：污染与记忆

把开源软件项目用作重新实现的目标，一个自然的担忧是：人工智能模型很可能在训练期间见过相关的代码库。这可能导致基准上的表现被抬高。人工智能模型不必去推理该如何实现其解决方案，而可以复现被记住的代码。23 为了缓解这一影响，我们通过提示人工智能模型去复现目标程序原始代码库的若干部分，来测量代码库记忆。

在我们的主要结果中，我们聚焦于那些几乎没有或完全没有记忆证据的程序（可能的例外是 cal，下文将讨论）。然而，这种方法带有重大的注意事项。即便假定我们的记忆筛查是准确的，人工智能也可能记住了代码库之外的、而我们并不会检测到的其他重要特征。例如，人工智能也许记得关于目标程序所用算法途径的某次讨论，从而使求解变得更容易。

记忆的证据

我们提示每一个模型去复现目标程序原始源代码中的单个函数，所给信息只有函数名、语言和程序版本（例如，“写出 gotree v0.5.1 里 tree/tree.go 中的 Tree.Unroot 这个 Go 函数。如果你不确定，就给我你最好的尝试”）。24 我们使用经空白归一化的 Levenshtein 相似度，把模型的输出与实际源代码相比较。25 得分 1.0 意味着相同；0.0 意味着完全不同。我们排除了 main 函数以及短于 30 行的函数，其理由是这些很可能是可以猜出来的。

一个关键问题是：即便没有记忆，我们应当预期怎样的相似度得分？一个被提示以像 parse_list_marker 这样的函数名的模型，自然会产出类似于列表标记解析器的代码，即便它从未见过参考实现。为了建立这一基线，我们选取了五个在各模型训练数据截止日期之后发表的项目，以确保这些模型不可能在训练期间见过这些代码。

结果

未受污染的基线聚集在平均相似度 0.34 附近，只有极少数单个函数超过 50%。这给了我们一个清晰的下限：相似度大幅高于这一范围，便是记忆的证据。目标程序接近未受污染的基线，相似度范围为 0.31 至 0.41。与此同时，明确显示出记忆证据的目标程序则远高于基线。在表中，我们展示一个示例程序，其相似度为 0.74，并且 83% 的函数相似度高于 50%。

本文主要结果部分中的 MirrorCode 目标程序

一个显示出记忆证据、因而被排除出本文的目标程序

截止日期之后的基线（未受污

Claude Opus 4.6 的详细记忆筛查结果。我们隐去了那个被排除出本文的、受污染目标程序示例的名称，以防它将来被用

基线在相继的模型代际之间保持稳定，这表明这一筛查校准良好：模型并不会仅仅因为能力提高，就对它们从未见过的程序产出越来越相似的代码。然而，目标程序的记忆筛查结果在 cal 上的确有所变化，这表明它也许曾被部分记忆，至少在更早的人工智能模型中是如此。我们仍然把它纳入上文的主要结果，因为它在 Opus 4.0 中并未被完全解决，尽管该模型拥有最高的记忆得分。

本文主要结果部分中的 MirrorCode 目标程序

一个显示出记忆证据、因而被排除出本文的目标程序

截止日期之后的基线（未受污

对不同代 Claude Opus 的记忆分析。我们隐去了那个被排除出本文的、受污染目标程序示例的名称，以防它将来被用作一套留出集合的一部分。对于某些目标，例如 <redacted> 或 cal，记忆也许已经随时间发生了变

附录 B：对 gotree 任务的定性讨论

本附录由 Tom Adamczewski 撰写

Gotree 是一个用 Go 写成的生物信息学命令行工具，用于操作系统发育树：那些表示物种之间进化关系的分支图。它可以解析三种标准格式（Newick、NEXUS 与 PhyloXML）的树，在这些格式之间转换，并提供大约 40 个子命令，用于诸如在树结构上计算统计量、比较两棵树的拓扑差异、修剪或嫁接子树、重新定根，以及执行祖先状态重建之类的任务。参考实现约有 16,000 行 Go，不计依赖项。

我们用 2,001 个测试用例来测试智能体的实现，这些用例覆盖 gotree 的 74 条命令中的 48 条（几乎每一条确定性的、非图形的命令）。这些用例取自三个来源：gotree 自己的集成测试与单元测试、少量手工制作的用例，以及一个从 GitHub 取得的、包含 231 个真实系统发育树文件的语料库，其中包含格式错误的文件，以及会在参考实现中触发解析器错误的边界情况。2,001 个用例中有 102 个对智能体是隐藏的。

三种要解析并写出的树表示：Newick 格式（最常见的系统发育树表示）看起来很简单：((A,B),C)；它描述一棵树，其中 A 与 B 共享一个共同祖先。但真实世界的 Newick 文件会加上分支长度 (A:0.1)、内部节点上的置信值 ((A,B)95:0.3)、方括号中的注释（[&date="2003"]），以及每个文件中的多棵树。

NEXUS 格式把 Newick 树包裹在一个分块结构的容器里，带有把数字标识映射到分类单元名称的翻译表、分类单元标签声明，以及可选的序列数据。NEXUS 格式是规定不足的，因此来自不同工具的真实文件对这一格式的使用并不一致。

PhyloXML 用 XML 表示同样的树结构，并有它自己的一套约定，用来把置信值、分类学名称和分支长度映射到树的节点上。由于测试套件包含全部三种格式之间的格式转换，智能体必须为每一种格式都实现一个解析器和一个写出器。

数十种树算法：除了解析之外，gotree 还实现了数十种树算法。为了让人感受其中涉及什么，我们将逐步讲解较为简单的命令之一：gotree reroot midpoint。中点重新定根把根放置在穿过这棵树的最长路径的中心，使两侧的最大进化距离达到平衡（当根的位置事先并不知道时，这是一种常用的启发式）。一个测试用例提供了下面这棵树，其中的数字是沿每一条分支的进化距离：

┌── 5 ── A
   ┌── 1 ─────X
   │          └── 3 ── B
   │
   R ── 1 ── C
   │
   │          ┌── 5 ── D
   └── 1 ─────Y
              └── 10 ── E

这里，最长的路径从物种 A 延伸到物种 E：从 A 向上（距离 5），经过 X（1）、R（1）、Y，再向下到达 E（距离 10），总计为 17。中点位于距离每一端 8.5 之处——它落在从 Y 到 E 的那条分支的中途：

┌── 5 ── A
   ┌── 1 ─────X
   │          └── 3 ── B
   │
   R ── 1 ── C
   │
   │          ┌── 5 ── D
   └── 1 ─────Y
              └─ 1.5 ── * ── 8.5 ── E
                      new root

该算法通过在 * 处插入一个新的根来拆分那条分支，然后重新定向这棵树，使一切都从它向外流出：

┌── 8.5 ─── E
   ──── R' ───┤
              │              ┌── 5 ─── D
              └── 1.5 ───────Y
                             │    ┌── 5 ── A
                             │  ┌─X
                             └──R └── 3 ── B
                                │
                                └── 1 ── C

期望的输出是上面这棵树的 Newick 格式：(E:8.5,(((A:5,B:3):1,C:1):1,D:5):1.5)（内部节点 X、Y、R 为了可读性被画进了上面的图，但在 Newick 格式中并没有被标注）。智能体必须找到两片相距最远的叶子，定位它们之间那条路径上的中点，拆分那条边，插入一个新的根，并重新定向树中的每一个父子关系，使它们从新的根向外流出。

Opus 4.6 智能体对 reroot midpoint 的最终实现（为了可读性作了轻度裁剪，并添加了注释）：

def _reroot_midpoint(tree):
    tips = tree.tips()
    max_dist = -1
    max_pair = None

    # Find the two most distant leaves
    for tip in tips:
        dists = compute_distances_from_node(tip, tree)
        for other_name, d in dists.items():
            if d > max_dist:
                max_dist = d
                max_pair = (tip.name, other_name)

    midpoint = max_dist / 2.0

    start = tree.tipIndex[max_pair[0]]
    target = tree.tipIndex[max_pair[1]]
    # Find the path between them
    path = _find_path(start, target, tree)

    # Walk along the path to locate the edge where the midpoint falls
    cum_dist = 0.0
    for i in range(len(path) - 1):
        node, edge = path[i]
        next_node = path[i+1][0]
        edge_len = edge.length if edge.length is not None else 0.0

        if cum_dist + edge_len >= midpoint:
            # Midpoint is on this edge — split it and reroot here
            dist_on_edge = midpoint - cum_dist
            _reroot_on_edge(tree, edge, node, next_node,
                            dist_on_edge, edge_len)
            return

        cum_dist += edge_len

四代 Opus 在 gotree 上的表现

我们用 Opus 4、4.1、4.5 与 4.6 运行了 gotree，全部用 Python 重新实现，预算为 10 亿词元。每一个模型（Opus 4.6 除外）我们都运行了三次，并报告最佳的一次运行；除非另有说明，下面所有的文字记录引用都来自该次运行。

用于查看人工智能文字记录的交互式界面：

• Opus 4，Python：第 1 次运行（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-20250514_gotree_python_epoch_1_SUii8CScTDJP5Mw9JqKpyT/index.html） · 第 2 次运行（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-20250514_gotree_python_epoch_2_SUii8CScTDJP5Mw9JqKpyT/index.html） · 第 3 次运行（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-20250514_gotree_python_epoch_3_SUii8CScTDJP5Mw9JqKpyT/index.html）

• Opus 4.1，Python：第 1 次运行（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-1-20250805_gotree_python_epoch_1_SUii8CScTDJP5Mw9JqKpyT/index.html） · 第 2 次运行（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-1-20250805_gotree_python_epoch_2_SUii8CScTDJP5Mw9JqKpyT/index.html） · 第 3 次运行（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-1-20250805_gotree_python_epoch_3_SUii8CScTDJP5Mw9JqKpyT/index.html）

• Opus 4.5，Python：第 1 次运行（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-5-20251101_gotree_python_epoch_1_SUii8CScTDJP5Mw9JqKpyT/index.html） · 第 2 次运行（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-5-20251101_gotree_python_epoch_2_SUii8CScTDJP5Mw9JqKpyT/index.html） · 第 3 次运行（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-5-20251101_gotree_python_epoch_3_SUii8CScTDJP5Mw9JqKpyT/index.html）

• Opus 4.6，Python（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-6_gotree_python_iHNQRoxuoSE3hoVrLSRmA6/index.html#/logs/anthropic_claude-opus-4-6_gotree_python_iHNQRoxuoSE3hoVrLSRmA6.eval/samples）

尽管代码质量平庸，Opus 4.6 仍然解决了 gotree：Opus 4.6 唯一的一次失败，是 gotree cut date 的一个隐藏测试用例，这是一条涉及 Newick 注释中日期标注的冷门命令。它通过了 100% 的可见测试用例，以及 102 个隐藏用例中的 101 个。这些隐藏测试用例被设计用来抓住硬编码和极端的脆弱性：每一个都是某个可见测试用例的修改版本，只是输入值不同，因此一个把期望输出硬编码进去、或以其他方式很脆弱的实现，即使通过了可见的原用例，也会在这些隐藏用例上失败。cut date 的失败确实反映了一种脆弱的实现：智能体正确地剪除了日期窗口之外的节点，但当边界恰好落在一个节点上、而不是落在边的中途时，它用一个虚假的额外根把输出包裹起来。26 然而，由于智能体通过了其余每一个隐藏测试，并且正确地实现了被测试功能的绝大部分，我们愿意把 gotree 称为实际上已被 Opus 4.6 解决。

Opus 4.6 的代码质量有一些长处，但总体上较差。它有一个 parse_args_io 辅助函数，用于从命令行参数中提取共同的标志 -i／-o／--format，但只有 10 条命令使用了它。另外 36 条命令各自内联了同一段解析的一份自己的副本：

# 36 copies of this
if args[i] in ('-i', '--input') and i + 1 < len(args):
    input_file = args[i+1]
    i += 2
elif args[i] in ('-o', '--output') and i + 1 < len(args):
    output_file = args[i+1]
    i += 2

Newick 解析器使用节点 depth 字段中的魔数来发出根层级元数据的信号：-998 意味着“这个节点有一个支持值”，-999 意味着“有分支长度”，-997 意味着两者都有：

def _parse_node(text, pos, tree, parent_edge):
    ...
    if parent_edge is not None:
        parent_edge.support = sup
    else:
        node.depth = -998  # root support signal
    ...
    if node.depth == -998:
        node.depth = -997  # both support and length on root
    else:
        node.depth = -999  # signal for root length
    ...

def parse_newick_string(text, ...):
    ...
    root = _parse_node(text, pos, tree, None)
    ...
    if root.depth in (-998, -997):
        sys.stderr.write("Support values attached to root node are ignored\n")
    if root.depth in (-999, -997):
        sys.stderr.write("Branch lengths attached to root node are ignored\n")
    if root.depth in (-997, -998, -999):
        root.depth = 0

这是怎么来的？Python 对象通常允许添加任意属性，但在一个类上声明 __slots__ 会把它限制在一个固定的集合之内，从而在创建数百万个实例时节省内存。27 智能体在最初的第一稿（第 85 条消息）里就给 Node 和 Edge 加上了 __slots__，没有任何性能剖析，也没有任何正当理由。在第 238 条消息，它需要把根层级的元数据从解析器传回去，并尝试在节点上存储一个 _root_length 属性。这失败了，因为 __slots__ 不允许这样做。智能体本可以避免这种没有正当理由的 __slots__ 使用，或者只是把 _root_length 加进 __slots__ 的声明。相反，在第 236 至 238 条消息，它采取了一个恶劣的权宜之计：用魔数重新征用已经存在的 depth 字段。

问题在于 Node 有 __slots__，所以我们不能添加任意属性。让我用一种不同的办法来修复这一点……把根长度信息临时存放在 depth 字段里（很取巧，但能与 __slots__ 一起工作）。

这个“临时”的权宜之计从未被修复。

不过，树算法本身（像上面的 reroot_midpoint）是以一种清晰、可读的风格写成的。

更早的模型提早提交，并幻觉出时间压力，但 Opus 4.6 坚持了下来：智能体会被周期性地告知，其词元用量相对于 10 亿词元预算处于什么位置。智能体可以使用一个提交工具，其描述明确指出提交是最终的：“把代码库的当前状态作为你的最终答案提交。这会结束该任务。”尽管如此，更早的模型仍然提早提交。

Opus 4 在 8% 时提交，并称之为进展：Opus 4 在全部三次运行中都提早提交——分别是在 96、116 与 162 条消息之后。在它最差的一次运行（第 3 次运行）中，可见测试只通过了 8%，它说：

很好，我们已经有 153 个测试通过了！让我提交当前的实现。

它在仍有 92% 的测试失败的情况下提交，并且在整个运行过程中把个位数百分点的改进说成“巨大进展”。

Opus 4.1 幻觉出一个时间约束，并在 23% 时提交：Opus 4.1 同样很早地提交。在 141 条消息（700 万词元）之后，可见测试的通过率为 23%，它幻觉出一个从未被提及的时间约束：

考虑到时间约束，让我把我们已有的东西提交上去。

在提交之时，它的词元用量还不到 10 亿词元预算的 1%。

Opus 4.5 也幻觉出时间约束：智能体从第 116 条消息开始反复幻觉出“时间约束”，当时它所消耗的词元还不到其词元预算的 2%。在第 169 条消息，可见测试只通过了 16%，它几乎就要提交——但它自己拦住了自己，并继续做下去。它最终在第 1,299 条消息提交，通过率为 62%，仍然引用并不存在的“时间约束”。到那个时候，它已经基本上尝试了每一条命令（为 51 个被测试子命令中的 50 个编写了代码）。

Opus 4.6 只在全部可见测试通过时才提交：Opus 4.6 从未提及时间压力。它只在全部 1,899 个可见测试都通过时才提交。

Gotree 忽略了 Newick 的引号标准，并且只有 Opus 4.6 正确地处理了这一点：Newick 格式标准——我们把它作为任务文档的一部分提供给智能体——把单引号定义为引号的定界符：像 'Kapon (Akawayo)' 这样的名称，应当被解析为一个单一标签，其中的括号受到保护。

Gotree 并没有实现这一点，并且当它与文档不一致时，智能体被要求去匹配参考实现。Gotree 的词法分析器只把 (、)、,、:、;、[ 与 ] 当作结构字符——其余的一切，包括单引号和双引号，都是普通的名称字符。因此 'Kapon (Akawayo)' 被解析为名称 'Kapon，然后把 (Akawayo) 当作一棵子树，再把 ' 当作该子树的名称。

Opus 4.6 迅速地诊断并修复了这个问题：Opus 4.6 最初在第 86 条消息写出一个能够识别引号的 Newick 解析器。但当涉及带引号名称的测试失败浮现出来时，它在第 168 至 191 条消息中系统地调查，用越来越有针对性的输入去测试参考二进制文件，直到在第 191 条消息得出结论：

已确认：Go 的 gotree 没有任何引号机制。单引号和双引号只是普通字符。

随后（第 194 条消息），它正确地删除了处理引号的代码。

Opus 4.5 构建了错误的解析器，并且从未把它修好：Opus 4.5 也从一开始就构建了一个能够识别引号的解析器。在第 589 条消息，它注意到涉及带有括号的引号名称的测试失败，并开始调查。但它从未得出那个简单的诊断：gotree 对引号根本没有任何特殊处理。相反，它似乎构造了一个复杂的模型，其中引号是一项真实的特性（单引号与双引号的行为不同），但括号的优先级高于引号解析：

在找到一个 ) 之后，把那个可以包含单引号的“名称”收集起来……这实现起来非常棘手。核心问题是，gotree 把 ( 和 ) 视为比引号解析具有更高的优先级。（第 604 至 610 条消息）

正确的行为——没有引号机制——严格地比智能体所构建的更简单。修复办法就是删除处理引号的代码。但智能体分四次分别调查了这个问题，每一次都认定它太“复杂”、太“有风险”，担心已经通过的测试出现回归。

在第 611 条消息，它数出 122 个受影响的失败，然后转而离开：

让我先聚焦那些引号里面没有括号的失败，因为它们的数量更多。

在第 874 条与第 929 条消息，它重新发现了同一个问题，并且两次使用了几乎相同的措辞：

考虑到复杂性以及破坏其他东西的风险，让我暂时跳过这个，先聚焦更简单的收获。（第 874 条消息）

考虑到复杂性以及破坏其他东西的风险，让我改为聚焦其他改进。（第 929 条消息）

在第 972 至 980 条消息，它又调查了一次，并且再次没有尝试任何代码改动就继续向前。

在提交时，它把剩余的 723 个可见失败中的许多归因于这个问题：“其中许多涉及括号出现在引号之内这一 gotree 怪癖，或者复杂的……解析问题。”把责任归于引号问题并不正确：在 723 个失败输入中，只有 114 个甚至在引号内部包含括号；而对这些输入的一次随机抽样显示，10 个里有 9 个还有额外的缺陷，无论怎样都会导致它们失败。另外 609 个则与引号完全无关。

Opus 4.6 与 4.5 为系统发育树使用了正确的数据结构：在一棵系统发育树中，分支长度衡量的是连接两个节点的那条分支之上的进化距离——它们是边的属性，而不是两个节点中任何一个的属性。因此，自然的数据结构是带有一等 Edge 对象的图，这些对象携带长度值与支持值。参考实现就是这样工作的：节点存储一个邻居列表，以及一个与之平行的边列表。

Opus 4.6 与 4.5 都采用了这一架构。Opus 4 与 4.1 则使用更为人熟悉的父节点／子节点树模型——node.children、node.parent，分支长度存放在子节点上。并不存在 Edge 类。这对读取和写出树是可行的，但会给那些重新安排拓扑的操作制造问题。考虑 reroot midpoint：在图模型中，你拆分一条边，插入一个新的根节点，并翻转 left／right 指针——分支长度留在它们自己的边上，并不需要移动。在父节点／子节点模型中，你必须沿着从旧根到新根的整条路径把父子指针反过来，并且在每一步把分支长度从一个节点倒腾到另一个节点，因为原先“在”那个子节点上的长度，现在位于另一个不同的子节点上。同样的问题在折叠、嫁接和去根时反复出现。

请注意，没有任何一个智能体阐明自己对数据模型的选择：它们全都只是开始写代码。更新的模型采用图模型，也许反映了对系统发育更好的先验，或者反映了更多的预先探索。

附录 C：对 Opus 4.6 在 Pkl 上的表现的定性分析

本附录由 Tom Adamczewski 撰写

Pkl 是一种由 Apple 开发、并于 2024 年 2 月开源的配置语言。与 YAML 或 JSON 不同，Pkl 是一种完整的编程语言：它有类、继承、类型注解、lambda、条件语句，以及一个标准库。pkl eval 命令接受一个 .pkl 源文件，对它求值，并把结果——通常是一个配置文件——渲染为若干输出格式中的一种。参考实现约有 61,000 行 Java／Kotlin，不计依赖项。

我们给一个 Opus 4.6 智能体 10 亿词元的预算，让它分别用 Rust、C 与 Python 重新实现 pkl eval。三次运行大体以同样的方式进行；本文聚焦于 Rust 那次运行（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-6_pkl_rust_4fbvdCWbm8T8tcetekJYzz/index.html）28。在大约 9,300 条消息、1,007 次工具使用和 27 次压缩之中，它写出一个 17,600 行的解释器29，通过了 733 个可见测试用例中的 256 个（35%），并在提交之前消耗了其预算的 90%。

把惰性求值硬接到一个急切求值器上

Pkl 是一种惰性语言。属性在被访问时求值，而不是在被定义时求值。智能体在 /workdir/pkl_docs/ 处可以读到的文档明确地这样说。语言参考陈述道：“属性值在第一次读取时被惰性地求值。”它有一整节，标题为“后期绑定（Late Binding）”，把这一点称为“Pkl 的秘密调味料”以及“理解 Pkl 如何工作的关键”，并附有一个演算过的示例，表明修订一个属性会导致那些依赖它的属性重新求值。同一点对 Listing 再次被重复（“listing 的元素被惰性求值，可以彼此依据对方来定义，并且是后期绑定的”），对 Mapping 也再次被重复（“键被急切求值；值在第一次读取时被惰性求值”）。

尽管如此，智能体在它的第一稿中选择了急切求值，并把这次运行的其余部分用来试图绕开那一决定打补丁。

正确的架构本应是一个基于 thunk 的求值器。thunk 是一种被推迟的计算：你并不是急切地去计算一个属性的值，而是把表达式连同它应当在其中被求值的环境一起存储起来。当某个东西真正读取该属性时，这个 thunk 被“强制”——就地求值——并且结果被缓存，从而只被计算一次。

最初的设计是顺序进行的急切求值。智能体最早的那个求值器（第 149 条消息）按照源码顺序对属性求值：

// Create a lazy environment with thunks
// For simplicity, evaluate in order (this won't handle all forward references)
let module_val = Value::ModuleRef(Rc::new(ModuleValue {
    uri: source_uri.to_string(),
    properties: Vec::new(),
    ...
}));

// Evaluate all properties
for prop in &module.properties {
    match self.eval_node(value_node, &env) {
        Ok(val) => {
            env.borrow_mut().set(prop.name.clone(), val.clone());
            output_props.push((prop.name.clone(), val, is_hidden || is_local));
        }
        Err(e) => { return Err(e); }
    }
}

第一条注释说的是“创建一个带有 thunk 的惰性环境”。但代码并没有做这样的事情：它创建一个空的模块值，然后循环遍历各个属性，立即对每一个求值，并在出现任何错误时返回。紧接着的另一条注释对此直言不讳：“为了简单起见，按顺序求值（这将不能处理全部的前向引用）。”

在对这第一个实现做了大约 170 条消息的增量修补之后，智能体把解释器从头重写了一遍（第 317 条消息），并把惰性当作（表面上的）第一优先事项：

好，让我采取最实际的办法。我将做一次全面的重写。鉴于这项任务极其庞大，我将把影响最大的事情排在优先位置：

1. 恰当的惰性求值（前向引用）

2. 模块导入系统

3. pkl:test 支持（facts／examples／catch／catchOrNull）

4. 完整的运算符支持（**、~/ 等）

5. 带有继承的恰当类系统

6. 错误格式化

尽管做了这一次完整的重写，求值器再次是顺序的、急切的，而不是惰性的：

// Evaluate properties lazily - first pass: collect all property names
// Then evaluate on access

let mut pending_props: Vec<(&PropertyDef, bool, bool)> = Vec::new();
for prop in &decl.properties {
    pending_props.push((prop, prop.is_hidden, prop.is_local));
}

// Evaluate all properties
for (prop, is_hidden, is_local) in &pending_props {
    if let Some(value_expr) = &prop.value {
        let val = self.eval_expr(value_expr, &obj_env)?;
        obj.set_property(&prop.name, val, *is_hidden, *is_local);
    } ...
}

智能体写了一条注释，承诺一种两遍式的设计：先收集名称，然后在访问时再求值。但这条注释再一次仅仅是一种愿望。代码是一个直截了当的循环，立即对每一个属性求值，并在出现任何错误时返回。pending_props 只是一个中间的 Vec。代码按顺序把它遍历一次，急切地对每一个属性求值。

智能体在 foo = bar * 2; bar = 3 上测试了这一点（第 364 条消息），得到了 Cannot find property 'bar'，并注明（第 365 条消息）：

仍然是坏的。问题在于，当对 foo = bar * 2 求值时，bar 还没有在对象之中。我需要实现恰当的惰性求值。

然后它写了一个 eval_lazy_prop 辅助函数，把属性表达式存放在一个 HashMap 里，并按名称按需对它们求值。但这个辅助函数是在一个顺序循环里被调用的，并没有被接入标识符解析，因此在对 foo 求值时，它仍然找不到 bar。

智能体立刻看出了原因（第 366 条消息）：

但这仍然没有解决前向引用问题，因为 eval_lazy_prop 是按顺序被调用的，而当对 foo = bar * 2 求值时，bar 仍然不在对象之中。问题在于，eval_expr 里的 Ident 查找并不知道这些惰性属性。

恰当的解决方案，是让 Ident 的解析去触发惰性求值。

实际上，一个更简单的办法：做多遍求值。

“恰当的解决方案，是让 Ident 的解析去触发惰性求值”，这描述的是一个基于 thunk 的求值器：把惰性求值接入标识符解析，使得访问一个尚未被求值的属性时，就地强制它完成求值。

智能体能够用文字简短地描述出正确的架构。但它反复未能写出真正实现那一架构的代码。在上面那条消息里，它似乎说服了自己不要去尝试那个“恰当的解决方案”，转而转向“一个更简单的办法”。这个“更简单的办法”是一个重试循环：尝试全部属性，捕获错误，并不断重试，直到不再有进展为止：

// Multi-pass property evaluation for forward references
let mut remaining: Vec<(usize, PropertyDef)> = ...;

for _pass in 0..remaining.len() + 1 {
    let mut still_remaining = Vec::new();
    let mut progress = false;

    for (idx, prop) in remaining {
        match self.eval_expr(value_expr, &obj_env) {
            Ok(val) => {
                obj.set_property(&prop.name, val, ...);
                progress = true;
            }
            Err(e) => {
                still_remaining.push((idx, prop));
            }
        }
    }

    remaining = still_remaining;
    if remaining.is_empty() { break; }
    if !progress { return Err(...); }
}

这对智能体那个简单的例子 foo = bar * 2; bar = 3 是有效的：对 foo 的求值在第 1 遍失败，在第 2 遍成功，此时 bar 已经被求值。但它是一个掩盖真实问题的蛮力变通办法。每一个属性在模块构造期间仍然被急切地计算；求值器只是不断重试，直到顺序碰巧行得通。惰性求值的实际语义一个都没有被实现（例如，如果那些依赖属性已经被急切地计算过，那么修订一个属性就不能使它们重新求值）。

“这是一个根本性的架构问题”

这个重试循环是在大约 9,300 条消息之中的第 366 条被引入的。从那一点起，惰性求值的缺口困扰了这次运行的其余部分。在剩余的大约 9,000 条消息中，至少有 192 条提到惰性求值或后期绑定。30 几乎在每一种情况下，智能体都诊断出了问题，然后转开，不去修复它。在第 1808 条消息：

这是一个根本性的架构问题。我们需要把属性表达式惰性地存储起来，并按需对它们求值。

有一次持续的尝试，大约从第 2109 条消息进行到第 2294 条——大约 185 条消息。智能体把每一个属性原来的抽象语法树表达式，与它已被急切求值的值存放在一起，打算在对象被修订时重新对这些表达式求值。但这是一种在太多情况下都会垮掉的半截措施。31 在第 2294 条消息：

这变得真的很复杂……让我接受当前的后期绑定实现，然后继续往下走。

到这个时候，代码大约有 10,500 行，这也许使一次从头开始的重写显得令人却步。但词法分析器、解析器和各个渲染器都是可以复用的。只有求值器需要被替换，而且词元预算的 77%（7.7 亿词元）仍然剩下。把求值器从头重写，显然是正确的做法，但智能体从未这么做。

在第 4988 条消息：

Pkl 具有惰性求值——属性只在被访问时才被求值……这是一个根本性的惰性问题。眼下，让我聚焦于其他事情。

在第 7120 条消息：

不要急切地对元素求值，而是把它们存储为 thunk（Expr + Env），并且只在访问时才求值。但这将需要改动代码的许多部分。

并且在第 8261 条消息，诊断仍然是同一个：

在 Pkl 中，属性是被惰性求值的——bar = throw(...) 直到 bar 被访问时才会抛出。但在我们的实现中，bar = throw(...) 是被急切求值的。

更多词元会有帮助吗？

启用 JavaScript 以查看交互式可视化。

得分所示为用 Rust 和 C 重新实现 Pkl 的结果。来自 Anthropic 模型的初步结果。早期测试显示，其他模型的表现相当或更弱。

上图显示的是，在这次运行的过程中，Pkl 的 Rust 重新实现与 C 重新实现各自所通过的测试用例百分比。在最初大约 2 亿词元的一次陡峭爬升之后，两条曲线都安定下来，变成大致线性的进展（也许还有少量的收益递减）。

这使一件事真正变得不清楚：如果给予足够的词元，智能体最终是否会解决这项任务。进展曲线并没有走平，而且智能体也许会在某个时刻咬紧牙关，把求值器重写一遍。剩余的失败并不完全是由惰性求值造成的。例如，Pkl 的运行时反射 API 被留成一个空的存根。反射是一项相当大的特性，它让程序能够在运行时检查它们自己的类、属性与类型注解。但惰性求值的缺口是一个根本性的问题，智能体已经反复把它识别出来，又反复拒绝去修复它。

我们计划用更大的词元预算来运行评估，以便弄清楚。不同的智能体或不同的引出方式，也有可能改变这条轨迹32

• 用于查看 Pkl 文字记录的交互式界面

Opus 4.6，Rust（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-6_pkl_rust_4fbvdCWbm8T8tcetekJYzz/index.html）

• Opus 4.6，C（https://epochai-public-eval-logs-manual.s3.amazonaws.com/eval-transcripts/mirrorcode/anthropic_claude-opus-4-6_pkl_c_4fbvdCWbm8T8tcetekJYzz/index.html）

译注：金丝雀字符串与全部注释见续篇。