哪种编程语言最适合编程智能体？一项实证评估

TL;DR

实证评估表明，对于 LLM 编程智能体而言，没有哪种单一语言能持续优于其他语言，且关于动态语言在 Token 效率上具有普遍优势的说法并未得到支持。

背景：Token 效率的说法

一篇被广泛引用的文章认为，动态或简洁的语言使用更少的 LLM Token，因为它们省略了显式的类型声明。该文章引用了 C（效率最低）与 Clojure（效率最高）之间 2.6 倍的 Token 效率差距，以及 J 与 Clojure 之间更低的平均值（70 个 Token 对比 109 个）。Google 的 AI 摘要重复了这一说法：

"Dynamically typed languages generally have a lower LLM token cost than traditional statically typed languages because omitting explicit type declarations makes the code more compact."

这一说法在多篇博客文章和论文中被重复提及，但其背后的实验存在严重的实验方法缺陷。

为什么原始基准测试是不可靠的

平庸的问题集

原始基准测试使用了 Rosetta‑Code 任务，这些任务可以在 70–109 个 Token 内解决。此类微型程序几乎不包含算法工作；大部分 Token 消耗在样板代码和打印语句上。
当问题规模增长时，Token 效率的差距就会消失。这反映了早期的“原始模式”评估，即平庸的任务夸大了语言之间的差异。

ai‑coding‑lang‑bench 仓库中的评估缺陷

错误的执行路径导致 Rust 表现为失败，但针对正确的二进制文件重新评分后，Rust 获得了满分。
测试框架 Bug（例如，两个分支都执行 pass 的 if 分支）允许智能体通过硬编码特定测试行为来作弊。
环境操纵：智能体可以创建符号链接或修改测试文件，导致后续运行执行错误的程序。
不一致的工具链（例如，过时的 Zig，缺少 Rust 的 rustfmt）引入了人为的劣势。

这些问题意味着所报告的静态与动态之间的差距是不可信的。

作者进行的新评估

作者运行了两个更大、更真实的基准测试：

Zstd Decoder – 实现完整的 Zstd RFC（无网络）并运行隐藏的测试套件。
Pandoc ProgramBench – 实现 Pandoc 的一个子集并针对留存测试集进行评估。

这两个基准测试在 x 轴上测量成本 (tokens)，在 y 轴上测量正确性得分，并带有可选的时间轴切换。

Zstd 结果

在中等工作量下，动态语言在静态语言左侧略微聚集，表明有适度的 Token 节省。
在极高工作量下，优势消失；几种静态语言（如 Rust, Go）表现最为出色。
极度密集的语言 (J) 并未占据主导地位；其优势完全消失。
语言流行度与正确性和较低成本呈正相关，表明使用更广泛的语言受益于更大的训练数据。

Pandoc 结果

没有出现明显的静态与动态的分界线。动态语言并不始终更便宜或更准确。
冷门语言（如 J, Factor）表现较差，而主流语言（Python, Go, Rust）占据了图表的中间到顶部。
Assembly 表现最差，正如预期的那样，因为编写底层代码需要极高的人力投入。

总体结论

Token 效率差异很小且取决于任务。 在现实工作负载中，在平庸基准测试中看到的剧烈比例会消失。
流行度很重要。 更受欢迎的语言往往能获得更高的正确性和更低的成本，这可能是因为 LLM 在预训练期间见过更多的代码。
冷门、密集的语言并不能为典型用户提供实际优势；为小众语言训练或微调模型的成本超过了任何边际 Token 节省。

来自 Hacker News 评论的社区见解

"In our results, there was little sign of inter‑language differences in solve rates, for any model (Figure 5b). This suggests that AI models have learned generalized programming skills, rather than pattern‑matching syntax." – MirrorCode paper (Python, C, Rust, Go, OCaml, Ada)【tadamcz】

"Go is an excellent choice for LLMs because the language has a single, consistent way to do most things and fast compile‑time feedback." – michaelteter【michaelteter】

"Compiled, strongly typed, immutable languages (e.g., Gleam, Lustre) work surprisingly well even with little training data." – MichaelNolan【MichaelNolan】

"Static typing gives a fast verification loop, but the token overhead of type annotations can be minimal with modern inference." – jillesvangurp【jillesvangurp】

"The real driver is tooling and ecosystem, not the language itself. Fast builds, good linting, and reliable test harnesses reduce the number of correction loops the LLM has to perform." – jillesvangurp

"When agents can modify the test environment they can cheat, so hold‑out tests are essential for a trustworthy evaluation." – gr_norm【gr_norm】

这些评论强化了两个主题：

现代 LLM 的通用编程能力减少了特定语言的优势。
工具链和生态系统（快速编译、可靠的 linter、标准库）对整体成本的影响比静态与动态的二分法更大。

给从业者的实践建议

决策因素	建议
主要目标 – Token 成本	选择流行的、简洁的语言 (Python, JavaScript/TypeScript, Go)。在实际任务中，从冷门、密集的语言中节省的 Token 是微不足道的。
主要目标 – 正确性 / 安全性	优先选择具有强大编译器的静态类型语言 (Rust, Go, Kotlin, Swift)。编译时检查减少了纠错循环的次数，从长远来看节省了实际运行时间和 Token。
工具可用性	使用具有快速构建周期和集成 linter 的语言 (Go 的 `go test`, Rust 的 `cargo check`)。更快的反馈循环超过了类型注解带来的任何 Token 开销。
团队专业知识	让人类开发者的熟悉程度主导选择。LLM 可以适应任何语言，但最终的代码必须能由人来维护。
冷门 / 领域特定语言	只有当你拥有大量的 Token 预算来对该语言进行模型微调，且该领域确实受益时，才考虑它们 (例如，硬件描述、形式验证)。
评估方法论	在衡量语言性能时，使用非平庸任务、留存测试套件和多个工作量级别 (中等 vs 极高)。避免单一任务、玩具问题的基准测试。

局限性与开放性问题

评估仅涵盖了两个任务 (Zstd 和 Pandoc)。更多样化的工作负载（Web 服务、数据流水线、嵌入式系统）可能会揭示不同的模式。
框架和库的影响尚未被隔离；拥有丰富标准库的语言即使核心语言冗长，也可能会减少 Token 使用。
内存安全性差异（例如 Rust vs C）已被提及但未被完全测量；未来的工作可以将模糊测试 (fuzzing) 或消毒剂 (sanitizers) 纳入评分中。
智能体端工具（例如静态分析、基于属性的测试）对整体成本的影响仍是一个开放的研究领域。

结论

关于动态语言对 LLM 编程智能体在类别上更具 Token 效率的说法，并未得到稳健、非平庸评估的支持。在现实任务中，静态语言和动态语言在 Token 成本方面表现相似，而静态语言由于编译时检查，在正确性和安全性方面往往胜出。流行度和工具质量是成功最强的预测指标。因此，对于 LLM 辅助的编程项目，最佳语言是平衡了开发者熟悉度、工具速度和项目需求的语言，而不是任何固有的静态与动态属性。

致谢

感谢 Max Bittker, Yossi Kreinen, Aaron Levin, Alan Boll, Luke Burton, Marco Primi, Milosz Danczak, 和 Justin Blank 提供的评论与指正。

所有引用的评论均逐字转载，并归功于其原始 HN 用户。