本文永久链接 – https://tonybai.com/2026/08/27/rust-ai-coding-agent-token-efficiency-danluu
大家好，我是Tony Bai。
【导读】
AI辅助编程已经成为「事实标准」，Claude Code、Codex这样的Coding Agent几乎人手一个。过去一年，「动态语言更省Token、更适合AI编程」的说法几乎成了共识——Rust、Go、C++因为类型声明啰嗦，常被扣上「AI编程效率低下」的帽子。但知名工程博主Danluu用两组硬核评测（让Coding Agent实现Zstd RFC解码器、复现Pandoc文档转换器）给出了不同的答案：当任务从「Rosetta Code式的小题」升级为真实工程问题后，动态语言的Token优势迅速蒸发，甚至有几门静态语言在高算力档位反超。更耐人寻味的是，此前被广泛引用的一份评测中，Rust之所以「拖后腿」，竟是因为测试脚本的一个符号链接Bug——修复之后Rust满分通过。
【文章要点】
- 「动态语言省Token」的流行结论来自极简单的Rosetta Code式题目（70~109个token），不能代表真实工程
- Danluu用Zstd RFC解码器和Pandoc两个真实评测重新检验了这一说法
- 在中等算力档位，动态语言确实占优；但在最高算力档位，结论反转，静态语言反而更强
- 被广泛引用的另一份跨语言评测存在符号链接Bug，冤枉了Rust的「所有权模型」；修复后Rust满分
- Agent写出的C/C++代码普遍存在内存安全问题，而修复到Rust级别的安全性需要额外Token——这部分隐藏成本此前被忽略
- 语言流行度与实测表现存在弱到中等的正相关，Rust作为主流语言由此受益
- 结论：目前没有证据支持「某语言天生更适合AI编程」这类强结论，包括Ruby、Clojure、J、Elixir等此前被吹捧的语言
一个被疯传的结论
如果你最近在搜索引擎里输入「dynamic vs static language token cost」，大概率会看到这样一句AI摘要：
「动态类型语言的LLM Token成本通常低于传统静态类型语言，因为省略显式类型声明使代码更紧凑。」
这个说法的源头，是一篇被广泛引用的博客评测。作者比较了多种编程语言在完成同一批题目时消耗的Token数量，得出结论：Token效率最低的C语言和效率最高的Clojure之间，差距高达2.6倍。作者后来又测试了小众的数组语言J，发现它平均只需要70个Token就能解题，几乎是Clojure（109个Token）的一半。
这个结论几乎成了AI编程圈的「常识」：写Rust、Go、C++这类静态语言，AI要多花钱、多花时间；写Python、Ruby、Clojure这类动态语言，AI又快又省。
问题是，这个结论到底站不站得住脚？
小题目撑不起大结论
Danluu对这个流行说法的第一个质疑很直接：这些评测用的题目太简单了。
前面提到的评测用的是Rosetta Code风格的题目——一种可以用几十到一百多个Token就写完的「练习题」。Danluu指出，一道70个Token就能解决的题目，本质上算不上什么「真正的编程问题」，更多时候消耗的Token只是在打印结果。
他还引用了另一份类似结论的评测（mame/ai-coding-lang-bench），但很快发现这份评测存在更严重的问题——这个问题我们放到后面细说，因为它直接牵涉到Rust。
Danluu在自己过往的评测经验中反复观察到一个规律：「土办法」（比如某些所谓「更高效」的提示词技巧）在小题目上效果显著，但一旦题目稍微复杂一点，涉及真正的工程判断，效果就会大幅缩水，甚至完全消失。
于是他决定不再依赖别人的评测，自己动手设计了两组更接近真实工程场景的测试。
硬核评测一：让Agent啃下Zstd RFC
第一个评测是个硬骨头：把zstd压缩算法的RFC文档（包括勘误表）扔给Agent，让它在没有网络访问权限的沙箱环境里，从零实现一个完整的zstd解码器。测试用例对Agent保密，评分时才会亮出来。
考虑到zstd规范的复杂程度，这不是一道能靠「背题」蒙混过关的任务——Danluu本人甚至曾经在zstd的官方实现里发现过一个数据损坏的Bug，说明这东西连成熟的生产级实现都不敢说完全没坑。
评测设置了两档算力：medium（中等）和ultra（顶格）。横轴是成本（Token消耗或时间），纵轴是正确率。
结果很有意思：
在medium档位，如果只看这一档的数据，确实会得出跟Alderson评测类似的结论——排除掉一些冷门语言后，动态语言整体上位于「左上角」（成本更低、正确率更高），静态语言则相对靠右下（见上图）。
但换到ultra档位，故事完全反转了(见下图)。表现最好的几门语言里，静态语言反而更多，而且有几门静态语言的综合表现明显优于动态语言集群。换句话说，「动态语言更省Token」这个结论，只在算力预算较低、Agent不太「较真」的情况下才勉强成立；一旦让Agent卯足劲去解决问题，静态语言完全不吃亏。
Danluu还顺手验证了另一个流传甚广的说法——「语言越冷门、越『稠密』，Token效率越高」（比如前面提到的J语言）。结果是：这个说法在真实任务里同样不成立。 一旦任务复杂度上升，冷门语言的表现普遍偏差，很可能是因为AI大厂在这些语言上投入的合成训练数据本来就少。
有意思的是，Danluu还做了一个补充分析：把「语言在GitHub上的流行度」和「实测表现」放在一起看，发现两者存在弱到中等的正相关——越流行的语言，Agent做出来的解答往往越正确、成本也越低。而Rust，正是近几年在Stackoverflow开发者调查和GitHub活跃度上持续攀升的主流语言之一。
硬核评测二：换个赛道，结论依然没变
为了避免「一个任务定生死」，Danluu又设计了第二组评测，选用了Pandoc（那款著名的文档格式转换工具）的ProgramBench测试集。这次任务的呈现方式跟Zstd不同，更接近TDD（测试驱动开发）的风格：Agent能看到一部分公开测试用例，但最终会用一批「留出集」（holdout tests）单独打分——这是为了防止Agent直接对着测试用例「背答案」。
结果依旧支持第一组评测的结论：静态语言和动态语言之间，没有观察到很强的相关性。 冷门语言依然普遍表现不佳，而汇编语言的表现明显更差——这也符合直觉，毕竟连人类工程师用汇编实现Pandoc这种量级的项目，难度也会远超实现zstd解码器。
两组评测放在一起对比时（见下图），Danluu也坦承：Clojure在Pandoc评测中的表现比Zstd评测好了不少，但深挖原因发现，这更像是一个「语言特性坑」——在Zstd评测里，Clojure的byte类型转换函数在处理128到255这个数值区间时会抛异常，而Agent没能正确处理这个边界情况，导致大量测试失败。这提醒我们：单一评测里某门语言表现差，往往是某个具体、局部的技术细节导致的，不能直接上升为「这门语言不适合AI编程」的整体结论。
那个「冤枉」了Rust的符号链接Bug
这是本文最值得Rust开发者关注的部分。
前面提到的mame/ai-coding-lang-bench评测曾经得出一个结论：在600次运行里，唯一出现失败的语言是Rust和Haskell——两门都是「有一定难度」的静态类型语言。评测作者据此推测，「Rust的所有权模型」可能给AI带来了额外的认知负担。
这个说法一度被不少人拿来当作「Rust不适合AI编程」的证据。
但Danluu深挖之后发现，真相完全是另一回事。
问题出在测试脚本本身：评测环境原本期望候选程序的可执行文件位于../minigit路径，但发布版本的测试脚本却错误地尝试执行../../minigit——这个路径根本不存在。Rust的失败，纯粹是因为脚本执行了一个不存在的文件路径，跟Rust语言本身毫无关系。
更荒诞的是后续的连锁反应：某个Go语言的Agent在运行中「聪明地」发现了这个路径问题，于是自己动手执行了一条命令，把这个不存在的路径符号链接到了自己生成的可执行文件上（ln -sf minigit-go-1-v1/minigit ../minigit）。这个操作在当时那个具体场景下确实让测试通过了，但也意外地导致此后所有语言的测试用例，实际上跑的全都是这个Go程序的可执行文件，而不是各自语言生成的程序。
Danluu重新用Rust自己生成的可执行文件跑了一遍这个测试，Rust直接拿到满分，此前「Rust因为所有权模型难倒AI」的理论也就随之站不住脚了。
这个乌龙也解释了为什么Danluu在文章里特别强调：跨语言评测的坑，往往比想象中更多、更隐蔽。他自己搭建评测环境时，也踩了超过100个类似的坑——比如构建脚本对不同语言的说明不一致、部分语言被莫名限制了工具链（Rust的测试环境一度没有配置rustfmt和Clippy）、汇编语言的评测条件里声称有GDB但实际根本用不了……这些细节问题，任何一个都足以让某门语言的评测成绩失真。
被忽略的隐藏成本：内存安全
除了正确率和Token成本，Danluu还顺手做了一个「彩蛋」实验：让Agent检查Pandoc评测里生成的C和C++代码是否存在内存安全问题。
结果相当扎眼：几乎所有C语言程序、以及除一个之外的所有C++程序，都被检测出了内存安全问题——比如某个C程序在处理被截断的LaTeX表格时，会出现越界内存读取。而这些问题，只花了几十秒的Prompt就能被发现。
这里的关键在于：如果要把这些C/C++代码修复到接近Rust的内存安全水位，需要投入相当可观的额外Token，很可能会让C/C++的实际成本远远超过Rust版本。 而在此之后，你对C/C++代码内存安全性的信心，可能依然不如对Rust代码的信心。
换句话说，市面上大多数「哪种语言更省Token」的比较，压根没有把「达到同等安全水位所需要的额外成本」计算在内。如果算上这部分隐藏成本，Rust的Token效率账本可能远比表面数字更好看。
Rust到底行不行？
把所有证据放在一起，Danluu给出的结论是审慎而克制的：
- 「动态语言整体上比静态语言更省Token」——不成立。 这个结论只在极简单的玩具题目、或较低算力档位下勉强成立，一旦任务变得有实际工程含量，结论就会瓦解甚至反转。
- 「冷门『稠密』语言（如J）天生适合AI编程」——不成立。 AI大厂对主流语言投入的训练数据和优化远多于冷门语言，这直接反映在实测表现上。
- 「Rust因为所有权模型拖累AI编程效率」——证据不足，甚至是被一个测试脚本Bug带偏的结论。 修复Bug后，Rust的表现和其他主流语言没有本质差异。
- 「语言越流行，Agent表现越好」——有弱到中等的支持证据。 而Rust恰恰是这几年持续保持高热度的主流语言之一，这对Rust开发者是个积极信号。
当然，Danluu自己也反复强调：这只是两组评测、两个具体任务，样本量远远谈不上「盖棺定论」。此前有人（据说是Scala之父Martin Odersky本人）曾经把类似评测里Scala排名靠前的结果，当作Scala「战胜」其他语言的证据在社交媒体上转发——Danluu明确指出，这是一种「站不住脚的结论」：任何基于一两个任务得出的「某语言天生更适合AI编程」的强论断，都需要打上问号。
写在最后
对于日常用Claude Code、Codex这类Coding Agent写Rust的开发者来说，这篇文章至少可以带来几点务实的启发：
- 不要因为「Rust费Token」的传言而放弃Rust。 目前没有扎实证据支持这个说法，反而有证据显示这个说法部分源于评测本身的Bug。
- 类型系统带来的「前期投入」，很可能在真实工程任务里被安全性、可维护性等隐性收益抵消，甚至反超。 内存安全问题的隐藏返工成本，是评估AI编程语言效率时经常被忽视的一块。
- 语言选型不该迷信某个「AI最爱语言」榜单。 无论是J、Clojure，还是Elixir，这些曾被吹捧「特别适合LLM」的语言，在真实工程评测里都没能证明自己的优越性——包括Danluu特意点名提到的这几个案例。
- AI辅助编程语言效率的研究还处于早期，值得持续关注。 Danluu自己也坦言，还有大量问题——比如哪种测试技巧更有效、不同语言的Bug修复成本、长期维护成本——目前仍缺乏公开数据支撑。
技术圈的「常识」有时候来得快，验证得却慢。这一次，Rust算是被「平反」了一把。
参考资料：
Dan Luu, What’s the best programming language for coding agents? - https://danluu.com/pl-tokens/
（本文数据与观点均整理自上述原文，如需精确数据请查阅原文及其交互图表。）
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
- 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
- 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
- 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
- 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
- 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
- 告别低效，重塑开发范式
- 驾驭AI Agent(Claude Code)，实现工作流自动化
- 从“AI使用者”进化为规范驱动开发的“工作流指挥家”
扫描下方二维码，开启你的AI原生开发之旅。
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
