Terminal-Bench-LILT：基于语言、地区和文化的多语言代理编码基准

# Terminal-Bench-LILT：基于语言、地区与文化的多语言智能编码基准测试

来源：https://arxiv.org/html/2608.28641  
\\IfFontExistsTF

NotoSerifCJK\-subset\.otf\\IfFontExistsTFHaranoAjiMincho\-Regular\.otf\\IfFontExistsTFNoto Serif CJK KR\\IfFontExistsTFNoto Serif KR\\IfFontExistsTFNotoSerifDevanagari\-subset\.otf\\IfFontExistsTFNewCM10Devanagari\-Regular\.otf\\IfFontExistsTFNoto Serif Devanagari\\IfFontExistsTFNoto Sans Devanagari

Yunsu Kim Kaden Uhlig Ashwin Purohit Milind Agarwal Patrick Simianer Anil Arslan Kiarash Mokhtari Thomas Zenkel Johannes Mosig Gabriel Bretschner Shamik Bose Joern Wuebker John DeNero LILT, Inc\. contact@lilt\.com

###### 摘要

目前大多数编码智能体的评估仅在英语环境中进行，无法反映现实世界的多语言部署需求。我们推出 Terminal-Bench-LILT，一套包含300个真实编码任务的多语言基准测试，涵盖阿拉伯语、捷克语、德语、西班牙语、印地语、日语、韩语、塞尔维亚语、土耳其语和中文共10种语言。每个任务针对非英语软件开发中特有的、英语中无直接对应的问题，例如国际化、编码、文本规范化以及文化惯例。所有任务均由母语程序员编写，并通过多阶段质量控制流程验证。对六个前沿模型的评估显示，即使是最强的模型通过率也仅为63.1%，许多任务无法被任何模型解决。性能因语言差异显著波动，且与通用编码基准排名不一致，这突显了多语言编码能力是一个独特且尚未充分探索的评估维度。示例任务可在 https://github.com/lilt/terminal-bench-lilt 获取。

## 1 引言

软件开发是一个全球性领域，英语作为通用工作语言：开源项目以英语协调（Kocetkov et al., 2023 (https://arxiv.org/html/2608.28641#bib.bib3)；Lozhkov et al., 2024 (https://arxiv.org/html/2608.28641#bib.bib4)；Bhuiyan et al., 2026 (https://arxiv.org/html/2608.28641#bib.bib1)），社区资源如 Stack Overflow 也主要以英语编写和回答（Stack Overflow, 2024 (https://arxiv.org/html/2608.28641#bib.bib21)）。因此，大多数程序员用英语读写和讨论代码，基于此生态构建的模型和工具主要为英语训练和优化，并在英语环境中表现最佳（GitHub, 2025a (https://arxiv.org/html/2608.28641#bib.bib22)）。用于评估这些智能体的基准测试遵循同样模式：除了几乎完全用英语编写外，它们还隐式编码了英语开发环境的数据、区域设置和惯例（Chen et al., 2021 (https://arxiv.org/html/2608.28641#bib.bib5)；Jimenez et al., 2024 (https://arxiv.org/html/2608.28641#bib.bib6)；Jain et al., 2025 (https://arxiv.org/html/2608.28641#bib.bib7)；Merrill et al., 2026 (https://arxiv.org/html/2608.28641#bib.bib8)）。

然而，许多开发者并非英语母语者（SlashData, 2025 (https://arxiv.org/html/2608.28641#bib.bib23)；GitHub, 2025b (https://arxiv.org/html/2608.28641#bib.bib24)），并在非英语环境中解决问题。特别是在本地市场，开发者使用本地语言数据、配置特定区域设置，并构建符合本地惯例和文化的服务。这些是英语环境中很少出现的真实工程挑战，直接影响了非英语开发者对编码智能体的体验。理想的编码智能体应主动识别和解决隐含的技术和文化假设。这在以英语为中心的任务中被视为理所当然，而在非英语环境中，智能体需要明确指导才能避免母语者认为显而易见的陷阱（Shen et al., 2024 (https://arxiv.org/html/2608.28641#bib.bib27)；Naous et al., 2024 (https://arxiv.org/html/2608.28641#bib.bib28)；Myung et al., 2024 (https://arxiv.org/html/2608.28641#bib.bib29)）。这增加了用户的技能要求，并使智能体使用起来繁琐。

现有编码基准测试均未在这一维度上评估智能体，因此我们构建了 Terminal-Bench-LILT，一套包含10种语言、三个难度级别的300个基于终端的编码任务。母语程序员根据自身实际遇到的问题设计每个任务，然后通过结合自动化检查和人工审查的多层质量控制流程进行验证。

我是东京 NOC（网络运营中心）团队的一员，需要将我们的每日状态日志行整齐地放入固定的40列监控终端中打印。
...
- 去除 ANSI 转义序列。它们占用0个显示列，不得出现在输出中。
- 将半角片假名转换为其全角等效形式。半角浊音和半浊音标记与前面的假名合并。长音标记变为全角。
...
（a）指令  
参考说明（b）示例输入/输出。

图1：Terminal-Bench-LILT 中的 ja-terminal-width 任务。（a）中的指令为清晰起见已简化。在（b）中，每个网格单元代表终端的一个显示列。

图1 (https://arxiv.org/html/2608.28641#S1.F1) 展示了 Terminal-Bench-LILT 中的一个任务。智能体被要求将日文日志行适配到固定的40列终端。每行混合了日文字符、ASCII、表情符号和终端颜色转义序列，它们占用不同的列数。此外，日文文本本身也会自然产生边界情况，例如：

1. Unicode 变体选择符通常用于名称中以强制特定视觉变体，不显示且必须从宽度计算中排除。计算代码点（如 Python 的 len()）会为每个变体符分配一个列。
2. 汉字存在兼容表形文字，它们外观相同但字节不同，例如，\cjkfont神 = U+FA19 与 \cjkfont神 = U+795E。不加注意地应用 Unicode NFKC 会将它们合并为更常见的形式，从而改变了任务仅要求重新格式化的文本。

这些问题对于处理日文终端输出的开发者来说很常见，详细说明起来也很繁琐。因此，指令仅隐式地提出要求，而测试则精确检查这些点。该任务因此准确衡量了日语母语开发者在使用时的流畅体验。

本文其余部分组织如下：第2节 (https://arxiv.org/html/2608.28641#S2) 回顾先前的编码基准测试及相关工作。第3节 (https://arxiv.org/html/2608.28641#S3) 描述 Terminal-Bench-LILT 的设计、构建和质量控制。第4节 (https://arxiv.org/html/2608.28641#S4) 在基准测试上评估前沿模型并分析结果。第5节 (https://arxiv.org/html/2608.28641#S5) 结论，随后是列出示例任务的附录。

## 2 相关工作

#### 智能编码基准测试

代码生成的评估已从单函数合成（Chen et al., 2021 (https://arxiv.org/html/2608.28641#bib.bib5)）转向仓库级和智能体环境：SWE-bench（Jimenez et al., 2024 (https://arxiv.org/html/2608.28641#bib.bib6)）提出真实的 GitHub 问题，LiveCodeBench（Jain et al., 2025 (https://arxiv.org/html/2608.28641#bib.bib7)）提供无污染的竞赛问题，Terminal-Bench（Merrill et al., 2026 (https://arxiv.org/html/2608.28641#bib.bib8)）评估智能体在命令行任务上的表现。这些基准测试均仅限英语；我们在 Terminal-Bench 的基础上，将其任务格式扩展到十种非英语语言。

#### 多语言编码基准测试

许多自称“多语言”的编码基准测试改变的是代码的*编程语言*，而指令保持英语（Cassano et al., 2023 (https://arxiv.org/html/2608.28641#bib.bib30)；Athiwaratkun et al., 2023 (https://arxiv.org/html/2608.28641#bib.bib31)；Zan et al., 2025 (https://arxiv.org/html/2608.28641#bib.bib32)）。其他基准测试则改变了人类语言，但仅限于指令部分，将英语编码任务翻译成其他自然语言（Raihan et al., 2025 (https://arxiv.org/html/2608.28641#bib.bib2)；Peng et al., 2024 (https://arxiv.org/html/2608.28641#bib.bib33)；Wang et al., 2023 (https://arxiv.org/html/2608.28641#bib.bib34)；2024 (https://arxiv.org/html/2608.28641#bib.bib35)；Hofman et al., 2025 (https://arxiv.org/html/2608.28641#bib.bib15)）。它们主要评估模型对翻译提示的理解能力，而非模型在非英语环境中对开发者的实用性。

在编码中，理解这一维度似乎是一个不一致的难度驱动因素。例如，Hofman et al.（2025 (https://arxiv.org/html/2608.28641#bib.bib15)）将 SWE-bench（Jimenez et al., 2024 (https://arxiv.org/html/2608.28641#bib.bib6)）翻译成十种语言，但平均非英语性能相比英语仅下降了 1.3%。与此同时，Wang et al.（2024 (https://arxiv.org/html/2608.28641#bib.bib35)）报告，HumanEval-X（Zheng et al., 2023 (https://arxiv.org/html/2608.28641#bib.bib36)）任务翻译成中文后，通过率相对下降至少 13%。在这些案例中，很难区分翻译引入的错误和模型能力的真正限制；此外，所有任务都源自英语环境。

我们的基准测试与这两条研究路线正交：编程语言是附带的，我们同时改变人类语言及其区域和文化背景。我们的任务由母语者直接使用给定语言编写，避免了翻译伪影，并且我们只保留真正具有语言和文化特异性的任务，从而能够针对模型对非英语开发者的有用性进行定向评估。

#### 推理语言

一个假设是，翻译的指令不会改变底层问题：模型可以阅读非英语提示，但仍用英语进行推理（Schut et al., 2025 (https://arxiv.org/html/2608.28641#bib.bib39)）。Barua et al.（2026 (https://arxiv.org/html/2608.28641#bib.bib38)）发现用英语推理比用目标语言推理表现更好，并且差距在多步任务上会扩大。对于代码生成，Nishigata et al.（2025 (https://arxiv.org/html/2608.28641#bib.bib37)）直接利用了这一点，调整模型以在非英语指令后附加英语思维链。因此，来自指令语言的难度是有限的，并且这种调整可以进一步缓解它。相反，我们的任务依赖于指令隐含的特定区域知识——仅靠推理无法弥合这一差距（第4.3节 (https://arxiv.org/html/2608.28641#S4.SS3.SSS0.Px2)）。

#### 文化和区域知识

日常文化知识基准测试揭示了代表性充分与不足的文化之间的巨大差异：Myung et al.（2024 (https://arxiv.org/html/2608.28641#bib.bib29)）报告称，在简答题上，GPT-4 的最佳与最差文化之间的差距高达 57 个百分点，相关工作记录了大语言模型中的文化偏见（Naous et al., 2024 (https://arxiv.org/html/2608.28641#bib.bib28)）以及文化常识的局限性（Shen et al., 2024 (https://arxiv.org/html/2608.28641#bib.bib27)）。然而，这些基准测试是在简单的问答中探测此类知识，而不是在模型实际用于的工作中。我们的基准测试在智能编码中测试相同的知识，智能体只有在其代码正确处理本地惯例时才能通过。

## 3 Terminal-Bench-LILT

Terminal-Bench-LILT 包含 300 个任务，涵盖 10 种语言，每种语言 30 个任务。每个任务在 Harbor（Harbor Framework Team, 2026 (https://arxiv.org/html/2608.28641#bib.bib20)）的隔离环境中运行，并进行确定性验证。它遵循原始的 Terminal-Bench 任务结构（Merrill et al., 2026 (https://arxiv.org/html/2608.28641#bib.bib8)），并为多语言挑战增加了额外的字段和文档：

- • 指令描述一个需要智能体编写解决方案脚本的真实编码问题。它提供原生语言和英语两种版本。
- • 环境（Docker 配置）以及任务所需的任何原生语言数据资产。
- • 验证器，包含确定性测试。
- • 被验证器接受的预言机解决方案。
- • 元数据，包含任务、解决方案和验证器的简要描述，以及 ISO 639-1 语言代码、挑战类别和子类别、难度和基础设施配置。
- • 说明解释任务设计背后的动机、其真实性，以及其语言和技术挑战的详细说明。

指令首先*直接使用原生目标语言*编写。许多任务基于特定区域数据，例如使用旧版编码的文件和地区日期格式，因此最自然地使用数据产生的语言进行描述。这种方法也反映了用户如何使用母语向编码智能体下达指令，使用口语化表达和领域特定词汇。像先前工作中常见的那样（第2节 (https://arxiv.org/html/2608.28641#S2)），先用英语编写指令然后进行翻译，可能会引入翻译伪影，并使生成的任务在代表性上偏离现实世界使用。

原生指令的英语翻译也一并提供，使其对非母语者可访问，并支持将指令语言的影响从任务难度中隔离出来的受控实验（第4.3节 (https://arxiv.org/html/2608.28641#S4.SS3)）。

### 3.1 任务设计

| 类别 | 子类别 | 范围/示例 |
| :--- | :--- | :--- |
| 国际化 | 基于区域的模板化 | 复数、数字、后缀、日期格式、韩语*万*计数法 |
| | 字符渲染 | RTL、阿拉伯文成型、简体与繁体中文、西里尔字母 |
| | 与环境交互 | 编码 | 非 Unicode/旧版文件编码、转换 |
| | 系统配置 | CJK 输入法调试、RTL shell 工具、区域正确的排序 |
| | 文本转换 | 规范化 | NFC/NFKC 规范化、乱码修正 |
| | ML 与数据处理 | 大小写增强、分词器训练、拼写错误模拟 |
| 变体转换 | 脚本转换、德语拼写改革 |
| | 文本处理 | 文档搜索 | 词干提取、黏着语种的停用词移除 |
| | | Unicode 混淆列表 | 以西里尔字母为首的反垃圾邮件字符混淆 |
| | | 用户认证 | 规范化的用户名/密码比较、数据库迁移 |
| 文化与其他 | 日历/日期转换 | 农历、回历、乌姆古拉历、节日计算 |
| | 其他 | 无法归入现有子类别的文化/区域特定问题 |

表1：Terminal-Bench-LILT 任务的挑战分类体系。

每个任务包含一个或多个针对其目标语言、地区或文化的特有挑战。我们根据表1 (https://arxiv.org/html/2608.28641#S3.T1) 中的挑战分类体系为每个任务分配一个主要类别和子类别；表2 (https://arxiv.org/html/2608.28641#S3.T2) 显示了按类别和语言分布的任务情况。示例任务的描述见附录A (https://arxiv.org/html/2608.28641#A1)。

无论类别如何，每个任务都遵循三个设计原则：

1. 1. 任务应反映目标地区的程序员可能遇到的问题。其数据、格式和工作流应与*实际使用的实践*匹配。
2. 2. 任务的难度应源于*特定区域元素*，而非一般的工程复杂性。仅仅用另一种语言复述普通编程问题的任务不符合条件。
3. 3. 特定区域的挑战应*隐式嵌入*在工程问题中，而非直接陈述。这测试智能体能否提供母语开发者认为理所当然的本地知识，而无需用户明确说明。

第三条原则对于文化……