前沿编程智能体利用元编程适应陌生编程语言

# 前沿编码代理使用元编程适应不熟悉的编程语言

来源：https://arxiv.org/html/2606.10933

![[Uncaptioned image]](https://arxiv.org/html/2606.10933v1/lossfunk.png)

Aman Sharma Lossfunk aman\.sharma@lossfunk\.com & Sushrut Thorat Lossfunk sushrut\.thorat@lossfunk\.com & Paras Chopra³³footnotemark:3 Lossfunk paras@lossfunk\.com

###### 摘要

基于大语言模型的编码代理通常在熟悉的软件设置下进行评估：主流语言、常用库和公开仓库。这些基准测试仍然很重要，但它们可能掩盖代理在语言本身不熟悉时的行为表现。我们使用顺序设置（包括文件编辑、本地执行和隐藏测试评分），在四种深奥编程语言上评估了六个当代编码代理。我们的协议揭示了这些代理之间的能力差异，而主流编码和代理基准测试（如 SWE-Bench Verified 和 Terminal-Bench 2.0）将这些差异压缩到更窄的区间内。我们观察到，最强的代理（Claude Opus 4.6 和 GPT-5.4 xhigh）通常避免直接编写目标语言。在 Brainfuck 和 Befunge-98 上，它们编写 Python 程序来生成目标语言代码，并在本地调试这些生成器。禁止这种元编程策略会导致性能大幅下降。从该策略中提炼出的文本指导并不能实质性地改善较弱的代理。相比之下，来自 Opus 的、用于构建生成器的 Python 辅助代码（不包含任何已解决的基准测试程序或隐藏测试答案）在相同问题上显著提高了 Sonnet 4.6 和 GPT-5.4 mini 的性能，而 Haiku 4.5 仍然表现不佳。更多的解释器调用和输出标记有助于提升较强的代理，但使较弱的代理保持在接近原始性能的水平，这表明这些资源放大而非创造了有用的策略。这些结果共同表明，强大的编码代理通过使用工具、反馈和工作区状态来构建目标语言的可行模型，从而适应不熟悉的语言。元编程是最明显的例子，但更广泛的差距在于构建和调试一种在目标语言规则下有效的策略。

## 1 引言

编码是大语言模型代理的核心应用之一。大多数著名的编码代理基准测试都是在熟悉的软件生态系统中进行评估：主流语言、常用库和公共开源仓库。SWE-Bench Verified [Jimenez et al., 2024 (https://arxiv.org/html/2606.10933#bib.bib10)] 是一个典型例子，它测试代理处理广泛使用的 Python 项目中的真实 GitHub 问题。这些基准测试衡量了在现实软件工程任务上的重要进展，但它们也测试了前沿模型已大量接触相关语法、API、库、编码模式和仓库结构的场景。一个互补的问题是，当编程语言本身不熟悉时，这些代理的行为如何：当代理必须弄清楚如何编写、运行、调试和修改一种语法和执行规则尚不熟悉的语言的代码时。尽管这一设置具有实际相关性，但在代理编码评估中受到的关注相对较少。生产系统通常要求模型处理内部领域特定语言、专有配置文件、生成的 API 以及本地工具约定，这些内容要么在公共语料库中缺失，要么与标准编程环境不同。在这种情况下，成功更多取决于在会话期间构建对目标接口的有效理解，而非回忆熟悉的代码模式。

参考说明

图 1：任务基座和代理运行时。(a) Python、Brainfuck 和 Befunge-98 中同一个简单的输入和打印任务，展示了深奥语言代码与普通代码的差异。(b) 每个模型在编码框架（Claude Code、Codex 或 OpenCode）中运行，具有文件编辑、Shell 访问、基准测试命令以及用于本地执行和隐藏测试提交的持久工作区。

为了研究当代基于大语言模型的编码代理在编程语言本身不熟悉时的行为，我们使用了来自 EsoLang-Bench [Sharma and Chopra, 2026 (https://arxiv.org/html/2606.10933#bib.bib48)] 的语言。这些深奥语言并非现实的生产目标；它们是用于不熟悉可执行接口的受控代理。例如，Brainfuck 是一种最小的指针机器语言，而 Befunge-98 在基于栈的网格上引入了二维控制流（图 1 (https://arxiv.org/html/2606.10933#S1.F1)a）。这使得它们对于测试代理是否能在会话期间足够好地学习一种不熟悉的语言，以编写、运行、调试和改进工作程序非常有用。因此，我们围绕 EsoLang-Bench 构建了一个代理评估管线，并用它来比较六个当代基于大语言模型的编码代理在通用工具使用协议下的能力阶梯：Claude Opus 4.6、Sonnet 4.6 和 Haiku 4.5；GPT-5.4 xhigh 和 GPT-5.4 mini（分别使用 xhigh 和 medium 推理努力）；以及 Kimi K2.5（图 1 (https://arxiv.org/html/2606.10933#S1.F1)）。每个代理在一个持久工作区中工作，可以编辑文件、本地运行代码，并将最终答案提交到隐藏测试。因此，评估测试的是一个交互式问题解决过程，而不是单一的代码补全。我们分析了最终通过率以及代理日志和定向干预，从而能够询问哪些代理成功以及它们如何适应。

##### 核心观察结果：

1. 1. 不熟悉语言的评估能够将主流程编码基准测试中看起来相似的代理区分开来。在我们的 EsoLang-Bench 协议下，目标语言必须在会话中摸索出来，这些代理的得分范围比主流程编码基准测试（如 SWE-Bench Verified 和 Terminal-Bench 2.0）宽得多，暴露了这些基准测试压缩到较窄区间内的能力差异（表 2 (https://arxiv.org/html/2606.10933#S3.T2)）。
2. 2. 最强的代理使用元编程。它们编写 Python 生成器，生成目标深奥语言程序，跨问题重用辅助函数，并在提交前进行本地测试。这在没有特定语言提示的情况下出现。在 Brainfuck 和 Befunge-98 上禁止元编程会导致性能下降几十个百分点。
3. 3. 策略转移通过可执行脚手架有效，但通过提炼的书面策略无效。策略的文本描述无法缩小差距，但提供该策略的实现作为工作 Python 生成器的参考库，显著提高了 Sonnet 4.6 和 GPT-5.4 mini 的性能。Haiku 4.5 仍然较低，表明有些代理仍然无法将提供的机制组合成可行的解决方案。
4. 4. 额外的推理时资源仅在代理能够使用时才有帮助。更多的解释器调用和输出标记有助于提升较强的代理，但使较弱的代理保持在接近原始性能的水平，这表明资源放大而非创造了有用的策略。

## 2 实验设置

##### 任务基座。

我们在 EsoLang-Bench [Sharma and Chopra, 2026 (https://arxiv.org/html/2606.10933#bib.bib48)] 上进行评估，使用原始 80 问题序列，涵盖 Brainfuck、Befunge-98、Whitespace 和 Shakespeare。EsoLang-Bench 包含第五种语言 Unlambda，我们排除了它，因为其解释器在我们的代理设置中使本地执行显著变慢；包括它会使得挂钟运行时间严重依赖解释器延迟而非适应行为。问题本身是简短的标准编程任务（回显输入、整数排序、GCD/LCM 以及类似列表和数字操作任务，分为四个难度层级；完整的按层级任务列表见附录 A.2 (https://arxiv.org/html/2606.10933#A1.SS2)）。原始 EsoLang-Bench 评估报告称，当模型用 Python 或 JavaScript 回答时，在相同的问题陈述上接近天花板性能，因此这里的难度主要在于在不熟悉的目标语言中表达、实现和调试解决方案。

##### 代理协议。

我们使用与 EsoLang-Bench 相同的四种语言任务基座，但将每个模型作为交互式编码代理进行评估，而不是一次性生成器。每个模型×语言运行是在该语言所有 80 个问题上的一个顺序会话。问题按固定前向顺序获取。对于每个问题，代理接收陈述，在隔离的工作区中编辑文件，本地运行候选程序，并且最多可以进行三次隐藏提交。当一次提交通过了所有六个隐藏测试，或者三次提交耗尽时，该问题即被最终确定；最终确定的问题不会重新访问。本地解释器调用暴露普通的执行反馈，如 stdout、stderr 和运行时错误。隐藏提交仅返回通过的私有测试总数，而不返回私有输入、预期输出或每个测试的诊断信息。图 2 (https://arxiv.org/html/2606.10933#S2.F2) 总结了状态机。主要协议使用每种语言 80 个问题、每个问题六个隐藏测试、最多三次隐藏提交、无限制的本地解释器调用、每次助手轮次 32k 标记的输出预算以及隔离的工作区；所有参数总结在附录表 4 (https://arxiv.org/html/2606.10933#A1.T4) 中。

参考说明

图 2：主要协议下的每个问题状态机。每个模型-语言运行是一个固定前向的会话，包含 80 个问题。对于每个问题，代理获取规范，本地编辑和执行候选程序，并进行最多三次隐藏提交。隐藏提交仅返回聚合的隐藏测试反馈；最终确定的问题不会重新访问。

##### 模型和框架。

我们评估的是部署的编码代理，而不是裸模型。Claude Opus 4.6、Claude Sonnet 4.6 和 Claude Haiku 4.5 在 Claude Code [Anthropic, 2026 (https://arxiv.org/html/2606.10933#bib.bib57)] 下运行；GPT-5.4 xhigh 和 GPT-5.4 mini 在 Codex [OpenAI, 2026a (https://arxiv.org/html/2606.10933#bib.bib58), b (https://arxiv.org/html/2606.10933#bib.bib59)] 下运行；Kimi K2.5 在 OpenCode [Moonshot AI, 2026 (https://arxiv.org/html/2606.10933#bib.bib60)] 下运行。这个模型×框架配对是我们评估的一部分，因为工具中介、文件编辑、Shell 访问和工作区管理是部署的编码代理系统的一部分。每个代理的 API 端点、模型标识符、采样设置和框架调用在附录 A (https://arxiv.org/html/2606.10933#A1) 中记录。每个代理都收到相同的基准测试操作和相同的每种语言系统提示（一个用于基准测试的简单任务提示，没有特定问题的指导、没有已解决的例子、也没有隐藏测试材料）；系统提示以及与此主要提示的条件偏差在附录 A.12 (https://arxiv.org/html/2606.10933#A1.SS12) 中。作为跨框架检查，我们在 OpenCode 下重新运行了 Opus 4.6 和 GPT-5.4 xhigh 在 Brainfuck 和 Befunge-98 上；我们观察到类似的性能，且定性排序不变（附录 B.4 (https://arxiv.org/html/2606.10933#A2.SS4)）。

##### 日志记录和行为测量。

对于每次运行，我们记录问题获取、Shell 命令、本地解释器调用、隐藏提交、文件编辑、生成的文件、命令输出和最终工作区状态。我们使用*元编程*来表示代理编写一种熟悉的主语言（如 Python、JavaScript 或 Rust）程序，其输出是目标深奥语言的源代码。这与直接创作不同，后者是代理直接编辑目标深奥语言源代码本身。如果一个辅助文件在工作区中持久存在，并且在同一个会话中跨多个问题被调用、导入、复制或修改，则它是可重用的。这些标签仅描述行为；评分仅取决于隐藏测试的成功。

##### 评分和报告。

当且仅当代理的一次提交通过了该问题的所有六个私有隐藏测试时，该问题才被视为已解决；仅通过部分隐藏测试的提交计为该提交失败，不给部分分数，并且我们不跨每个问题允许的最多三次提交聚合隐藏测试通过情况。主要分数是每个模型×语言运行中 80 个问题中已解决的数量。对于每个模型×语言单元格，我们在相同的任务顺序和协议下运行三个独立的会话。我们在表 1 (https://arxiv.org/html/2606.10933#S2.T1) 和表 2 (https://arxiv.org/html/2606.10933#S3.T2) 中报告第一个会话的已解决计数作为主要值，并附上在其 80 个每个问题结果（每个语言 k/80 和合并后 k/320）上计算的 Wilson 95% 二项式置信区间 [Wilson, 1927 (https://arxiv.org/html/2606.10933#bib.bib63)]。其余两个会话用作会话间合理性检查；三个会话的每个会话计数在附录 B.7 (https://arxiv.org/html/2606.10933#A2.SS7) 中制表。完整的报告和置信区间细节在附录 A.6 (https://arxiv.org/html/2606.10933#A1.SS6)、A.7 (https://arxiv.org/html/2606.10933#A1.SS7) 和 B.6 (https://arxiv.org/html/2606.10933#A2.SS6) 中。

##### 诊断协议变体。

所有主要结果都使用上述主要协议。我们仅将协议变体用于有针对性的诊断实验。在第 3.3 节 (https://arxiv.org/html/2606.10933#S3.SS3) 中，我们通过要求代理直接编写 Brainfuck 和 Befunge-98（不使用主语言生成器）来限制元编程。在第 3.4 节 (https://arxiv.org/html/2606.10933#S3.SS4) 中，我们通过给较弱的代理提供从 Claude Opus 4.6 的跟踪中提炼的文本指导，或一个包含工作生成器代码的小型参考库（不包括任何已解决的基准测试问题或隐藏测试答案）来测试策略转移。在第 3.5 节 (https://arxiv.org/html/2606.10933#S3.SS5) 中，我们在保持任务基座固定的情况下改变本地解释器调用预算和输出标记预算。这些变体用于解释在主要协议下观察到的性能差距，而不是定义主要得分。除非另有明确说明，模型提示、任务顺序、隐藏测试、提交限制和评分规则与主要协议保持不变。

表 1：主要协议下的主要 EsoLang-Bench 结果。EsoLang 单元格报告会话 1 的解决百分比（主要会话；每个单元格的另外两个会话在附录 B.7 (https://arxiv.org/html/2606.10933#A2.SS7) 中报告），并附有 Wilson 95% 二项式置信区间作为下标。Mean 列平均了四个深奥语言的分数。BF = Brainfuck, B98 = Befunge-98, WS = Whitespace, Sh = Shakespeare。下标表示 Wilson 95% 区间：对于天花板单元格为 −x，对于接近地板单元格为 +x，对于内部单元格为 ±x。原始计数在附录 B.2 (https://arxiv.org/html/2606.10933#A2.SS2) 中，每个会话计数在附录 B.7 (https://arxiv.org/html/2606.10933#A2.SS7) 中，完整的不对称区间在附录 B.6 (https://arxiv.org/html/2606.10933#A2.SS6) 中。

## 3 结果

### 3.1 不熟悉语言的评估显著区分了当代编码代理

我们首先询问当代代理模型在不熟悉语言评估下表现如何。表 1 (https://arxiv.org/html/2606.10933#S2.T1) 报告了在主要协议下，六个评估代理按语言的 EsoLang-Bench 分数，并附有 Wilson 95% 二项式置信区间（第 2 节 (https://arxiv.org/html/2606.10933#S2)，附录 B.6 (https://arxiv.org/html/2606.10933#A2.SS6)）。我们观察到代理之间较大的性能差异。这种差异并非由单一统一困难的语言驱动。按语言范围