Rust 语言设计者谈 Agent 对编程语言的影响

作为一个以编程语言设计为职业的人，我对 LLMs 的崛起确实有些存在主义式的恐惧时刻。我从五年级开始用 x86 编程¹它的运行频率是 5MHz，硬盘大约 5MB，内存 512K²。那时的计算机真的非常不同。但说实话，编程并没有。尽管 IDE 和编程语言等方面有了诸多进步，把代码输入文件的基本行为却惊人地保持不变³——直到几年前，一切突然天翻地覆。那有时令人兴奋、给人力量⁴但也令人恐惧和迷失方向。我的编程技能还重要吗？那我的编程语言设计技能呢（就我有的那些而言）？这篇博文就是我试图回答这些问题的尝试。

为了不让你悬着心，我直接给出结论。简而言之，是的，我相信人类在编程中仍会有角色。而且是的，我认为编程语言设计仍然相关。当然，我也恰好认为 Rust 是非常合适的选择用于智能体开发——但这并不是说我们不能让它成为更合适的选择。而这正是这篇文章最终要谈的：是什么让 Rust 和智能体开发配合良好，以及我们可以在哪些方面加倍强化这些优势。

这算是我本周在 REBASE 所做演讲的“博文配套版”，REBASE 是 SPLASH 的一部分。你可能也会喜欢我在 IWACO 所做演讲的幻灯片，IWACO 与 Rust：隐藏的联系揭晓，那更像是一次回顾（不过那些没有配乐）。无论如何，这次会议非常棒！Jack Huey 介绍了 Rust Vision Doc，而且出乎我意料的是，Steve Klabnik 和 Dorian Scheidt 介绍了“LLMs as Collaborators in Language Specification and Design”，谈论了他们构建Rue的过程。再次见到 Steve 很有趣。除此之外，尤其是 IWACO 上展示了大量出色的研究。我特别被关于Reachability Types和Information Borrowing的工作吸引。我也很喜欢了解Hylo LangHylo Lang，尤其是他们对投影的处理方式。巧妙又酷。

Rust 在智能体时代很受欢迎

Rust 现在很受欢迎。非常受欢迎：

在那些异军突起的语言中，TypeScript 一骑绝尘，从图表中被裁切出来，目前相较上一年增长了 +1200%。[..]

近期增长第二快的是 Rust。Meta 的工程师今年到目前为止编写的第一方 Rust 代码量，是过去 9 年总和的兩倍。

—— David Tolnay（着重号为笔者所加）

其中一部分原因是智能体让尝试新事物变得非常容易。还有一部分原因是 Rust 以高性能著称，而如果选择任何语言都一样容易，那为什么不选一个能带来更快执行速度的呢？

但我认为 Rust 受欢迎还有另一个原因：因为 Rust 恰好非常适合智能体编程⁶。当然，我会这么说的，对吧？这篇文章的目的是（1）论证为什么会这样，然后（2）讨论我们可以对 Rust 做哪些改变，让它表现得更好。

用智能体进行基础软件构建

在我看来，一个有效的“软件工厂”会有三大支柱：

• 设计：弄清楚并清晰地说明代码应该做什么。
• 构建：编写能实现其应有功能的代码。
• 优化：优化代码，使其高效运行。

这些支柱没有一个被完全解决，但有些比其他的进展更大。

Rust 与优化：默认就快，需要时又有调节旋钮

Rust 的设计目标是“默认就有良好性能”，让符合习惯的写法通常也是最快的写法。但 Rust 的另一个关键部分是，当你需要时，你有调节旋钮来榨取更好的性能。你可以控制某个东西是分配在栈上还是堆上，以及指针间接寻址发生在哪里。如果你愿意，你可以强制结构体的布局以特定方式进行，或者决定在异步栈帧中何处引入装箱。在极限情况下，你甚至可以嵌入内联汇编。

过去，学习如何“调节性能旋钮”可能有点像一门玄学：但智能体正让这件事变得容易得多。⁷事实证明，智能体非常出色在微调现有代码的性能方面。例如，从事超高性能加密算法的人过去通过手工调整汇编代码来实现。但那些人告诉我，他们现在正转向智能体来完成同样的工作。更平常地说，许多构建网络服务的人发现，使用像dial9这样的性能分析器，智能体可以相当有效地诊断异步性能陷阱，比如长轮询或阻塞。

因此，我认为 Rust 的任务很明确。我们继续坚持我们的目标：“低层到足以编写内核，高层到足以构建 GUI”。如果说有什么变化，我认为围绕智能体的转变意味着我们可以容忍更多以显式调用形式出现的“噪音”，比如调用clone()或share()——但不能太多，因为我们仍然希望代码的“快乐路径”清晰明了⁸，即使我们暴露出在特定场景中很重要的细节（比如精确追踪你拥有多少个通道端点的克隆）。结合性能分析器，你就得到了一个有效的反馈循环，让代码快速运行：

flowchart LR
    Code -- Benchmark --> Profile
    Profile -- Analyzed by --> Agent
    Agent -- Propose --> PR
    PR -- Improve --> Code
  

可靠性始终为王

不过，一如既往，虽然良好的性能声誉是吸引人们使用 Rust 的原因，但让他们想要留下的，是一种使用 Rust“似乎就是运行得更好”的感觉。基本理论是，Rust 的类型系统和护栏有助于让智能体保持正轨：

rust 是智能体的完美语言，因为只要它能编译，就差不多是正确的

— Greg Brockman (@gdb)2026 年 1 月 2 日

我认为这话有道理：像 Rust、Ocaml 或 Haskell 这样的语言都有这种“只要能编译，就能工作”的感觉，我认为智能体会从中受益。

测试还不够，类型系统有帮助

测试可以显示 bug 的存在，但无法显示其不存在。

— Edsger W. Dijkstra，1970

编写测试从来都不足以证明你的程序是正确的——但有了智能体，这更是远远不够。这种情况经常发生：我最初的几个测试看起来很棒，然后下一个就完全离谱了。通常离谱到我甚至无法想象那个 bug 是怎么产生的。然后我深入调查，发现智能体完全误解了我试图表达的逻�辑。⁹

这正是类型系统真正大放异彩的地方——尤其是像 Rust 这样的高级类型系统。类型系统提供了一些护栏，让智能体保持在正轨上。在 Rust 中，这些护栏不仅限于“所有字段名是否正确”这类简单的东西，还延伸到诸如永远不必手动关闭套接字。

类型系统也不够

类型系统可以证明不存在 bug，但无法证明正确性。

——我，试图造一个同样精妙的句子却失败了¹⁰，2026

所以没错，类型系统很有用！但它们有固有的局限。类型系统是一套简单的规则，如果你遵守它们，就能确保你避免（某些类型的）错误。但它们不会告诉你你做的是对的事情——只会告诉你你没有做（某些类型的）错事。如果你想更进一步，你需要一个证明系统——某种能让你证明更丰富的性质确实成立的东西，而不仅仅是你避免了 bug。

碰巧的是，Rust 有很多有趣的证明工具，比如Verus、Creusot、Aeneas和Kani。作为起点，你可以证明你的代码不会 panic，这会消除很多 bug，尽管这从根本上仍然是一种“类似类型检查器”的性质（也就是说，你避免了做错事）。但你也可以更进一步，添加断言来证明你的代码计算出的结果符合预期。

强护栏带来更好的性能

部署证明不仅有利于让代码正确——它还有利于让代码快。这有点反直觉，但确实如此。前面我提到，优化的密码学算法现在正由智能体编写。之所以能做到这一点，部分原因是密码学算法有非常清晰的数学定义。这意味着你基本上可以告诉智能体“你想怎么做都行，只要你能证明代码仍然计算出正确的结果”。这些证明可以用Lean或Rocq这样的定理证明器来完成。博文“Why Lean is faster than Rust”很好地阐述了这一点。

对于 Rust 来说，一个很好的例子就是围绕 unsafe 代码。目前，人们有时不愿意部署 unsafe 代码，即使它可能让代码更快，因为一旦出错，风险不值得承担。我赞赏这种努力。但如果你能用证明器来证明你的 unsafe 代码实际上是安全的（即不会导致未定义行为），那会怎样？那么你就可以随心所欲地优化了。

如果我们要证明一些东西，我们还需要类型系统吗？

你可能会想：如果我们在代码上部署了证明系统，我们还需要类型系统吗？我认为答案绝对是肯定的。类型系统使用起来要简单得多，这也是它们更受欢迎的原因。使用类型系统可以排除各种烦人的 bug，这样你就可以把“证明精力”只集中在重要的事情上。

举个简单的例子，考虑以下 Java 代码：

voidsetFoo(Barbar){this。foo=bar;assertthis。foo==bar;}

在不看更多代码的情况下，不可能证明这个断言是否为真！这是因为可能有任意数量的其他线程在四处修改this。相比之下，以下 Rust 代码必须为真（至少，只要Eq运算符对Bar是自反的）：

fn set_foo(&mutself,bar:Bar){self。foo=bar;assert_eq!(self。foo,bar);}

我们知道这一点，是因为Rust 的类型系统保证了&mut self意味着一个唯一引用。

这实际上正是 Verus 的工作方式。通过信任 Rust 的借用检查器来跟踪唯一性等，它简化了 SMT 求解器的工作，使证明检查比原本更快、更可靠。

我认为 Rust 在可靠性方面应该走向何方

所以我的看法是，Rust 应该加倍投入如果它能编译，它就能工作。尽管 Rust 的类型系统表达力很强，但仍有很多东西它无法捕捉。这包括相当常见的东西，比如这个方法只读取一个特定字段或内部引用，也包括一些花哨的东西，比如“不记录个人身份信息”。我们应该努力提升这些限制，给智能体留出空间来证明更复杂的属性。

我们还需要改进集成证明工具的体验，朝着一个可扩展的编译器尽管现有的基于 Rust 的证明工具很酷，但使用它们是一种糟糕的体验，涉及烦人的宏和被固定的编译器版本。我们可以做得更好。

一个北极星：不再有 unsafe 代码

我想为 Rust 提出一个北极星：不再有 unsafe 代码。我这么说并不是指我们永远不使用unsafe 关键字。相反，我的意思是我们有能力证明我们编写的所有 unsafe 代码都是正确的，并且不会导致未定义行为。别误会我的意思：确切知道哪些代码需要审查是一个巨大的进步，同样重要的是，让“库需要通过安全 API 边界来保护用户免受未定义行为影响”这一理念成为常态¹¹。但考虑到智能体发现漏洞的能力，我认为如果我们想阻止源源不断的 CVE，就需要提升我们的水平。¹²

设计是一个开放性问题

但在你着手证明或优化某些东西之前，你需要清楚地知道自己要构建什么。据我所知，目前这里的最先进水平基本上就是“markdown 驱动开发”的各种变体，即编写文档并希望智能体能够关注到。

我不知道 Rust 在这个领域能扮演多大的角色。我认为我们最终可能会采取一些可能有帮助的步骤——例如，有办法将接口与实现分离，这样就能更容易地单独审查接口，或者看出智能体何时在那里做了改动。¹³或者也许只是提供更好的工具来审查这些。

我还认为专门的“建模语言”也有空间，这类语言让你能够与智能体在高层次设计和不变式上快速迭代，而不必深入细节去阅读代码。我对此有更多想法，但这值得单独写很多篇博客文章。目前，我先请大家看看 Kari Wilhelm 的这篇文章，《Anchor Engineering 的原则》，我认为它很好地描述了提取设计的关键要素并由此驱动编码意味着什么。

结论

我们在这里涵盖了很多内容，所以让我把这一切整合起来。是什么让 Rust 成为使用智能体进行开发的好选择？

• 它提供了良好的默认性能（为什么要花更多钱？），并且与性能分析器结合使用时，可以根据需要任意调优。
• 类型系统提供了更强的护栏，如果你正确设置智能体，就可以通过新类型等技术来强化这些护栏。

从语言设计的角度来看，什么能让它变得更好？总体而言，我认为它与我们过去所做的非常相似，只是我们权衡取舍的方式有所调整，以考虑到智能体负责编写代码、而人类更专注于代码理解这一变化：

• 如果能编译通过，它就能工作——我们的类型系统是我们的一大优势，我们需要让它更具表现力和函数式特性，这样智能体就不会卡在试图绕过它上！
  • 作为补充，确立一个北极星目标：实现无安全风险的不安全代码通过支持证明，并让最广泛使用的 Rust 库被证明是健全的。
• 底层到足以编写内核，高层到足以构建 GUI——确保我们暴露出调优性能所需的旋钮，同时让代码的意图清晰明了（但不必费心把代码压缩到绝对最少的字符数）。
• 可扩展且多用途——Rust 的一大优势在于，借助宏和我们的类型系统，我们支持 DSL 和各种各样的目标平台。我们需要将这种可扩展性的精神带入编译器，以便能够面向更多开发风格（例如 GPU、深度语言互操作等），并集成定理证明器和其他需要的不只是 token 的工具。

最后，让我向你推荐 Marc Brooker 的这篇有趣的文章，“现在什么容易？现在什么困难？”。他提出，一项任务的成功标准越能被清晰地指定，它就越容易；我们可能会发现，传统上被认为是“困难”的任务（例如，构建一个高效的密码算法实现）可能很快就会自动化，而那些我们认为是“容易”的任务（例如，制作一个独特、引人注目的网站）可能会变得更有价值。

从编程语言的角度来看，我认为 Marc 的观点强化了我的感觉：最大的变革将来自设计语言，那些让你能够捕捉架构和预期行为从非常高的层面来看。目标是让人类能够直观地指定一个设计，然后将其转化为有效的护栏，无论是类型系统检查、lint 还是待证明的定理。智能体随后会承担将设计翻译成用 Rust 等传统编程语言编写的代码的任务，而人类只需很少地查看。这并不会让传统编程语言的设计变得不那么有趣，但它确实让权衡与以往大不相同。