智能体时代对 Rust 意味着什么（以及 Rust 对智能体的意义）

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

为了不让你悬着心，我直接给出结论。简而言之，是的，我相信人类在编程中仍将有一席之地。而且是的，我认为编程语言设计仍然相关。当然，我也恰好认为Rust非常适合代理式开发——但这并不是说我们不能让它更适合。而这正是本文最终要讨论的：是什么让Rust和代理式开发配合良好，以及我们可以在哪些方面加倍强化这些优势。

这算是我本周在REBASE（SPLASH的一部分）所做演讲的“博文配套版”。你可能也会喜欢我在IWACO演讲的幻灯片，IWACO与Rust：隐藏的联系揭秘，那更像是一次回顾（不过那些没有配乐）。无论如何，这届会议非常棒！Jack Huey介绍了Rust愿景文档，而且出乎我意料的是，Steve Klabnik和Dorian Scheidt介绍了“LLMs作为语言规范与设计中的协作者”，讲述了他们构建Rue的过程。再次见到Steve很有趣。此外，尤其是在IWACO上，有大量出色的研究展示。我特别被可达性类型和信息借用的工作所吸引。我也很喜欢了解Hylo 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) January 2, 2026

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

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

测试可以显示 bug 的存在，但不能显示它们的不存在。

—— Edsger W. Dijkstra，1970

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

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

类型系统也不够

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

——我，未能造出一句同样精妙的话¹⁰，2026

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

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

强护栏带来更好的性能

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

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

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

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

作为这方面的一个简单例子，考虑以下 Java 代码：

void setFoo(Bar bar) {
    this.foo = bar;
    assert this.foo == bar;
}

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

fn set_foo(&mut self, 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 的这篇文章，“锚定工程的原则”，我认为它很好地描述了提取设计关键要素并以此驱动编码意味着什么。

结论

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

• 它提供了良好的默认性能（何必多花钱？），并且配合性能分析器，可以按需进行任意调优。
• 类型系统提供了更强的护栏，如果你正确设置智能体，还可以通过新类型等技术来强化这些护栏。

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

• If it compiles, it works – our type system is our big advantage, we need to make it more expressive and more functional so that agents don’t get stuck trying to work around it!
  • 作为补充，确立一个北极星：通过支持证明来实现无不安全性的不安全代码，并让最广泛使用的 Rust 库被证明是可靠的。
• 低层到足以支撑内核，高层到足以构建 GUI——确保我们暴露了性能调优所需的旋钮，同时让代码意图清晰（但不必费心把代码压缩到绝对最少的字符数）。
• 可扩展且多用途——Rust 的一大优势在于，借助宏和我们的类型系统，我们支持 DSL 和各种各样的目标。我们需要把这种可扩展的精神带入编译器，以便面向更多开发风格（例如 GPU、深度语言互操作等），并集成定理证明器和其他需要超越 token 的工具。

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

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

1. 私下里我一直很羡慕那些用打孔卡编程、把东西存到巨大的磁带卷上之类的人。我就是特别想变得饱经沧桑！我有点高兴自己终于到了可以这样说“我记得当年我们得先编辑 CONFIG.SYS 才能玩电脑游戏！”的年纪，而年轻的程序员们会惊恐地倒吸一口气。⁵ 但在那些“当年”就在场的人面前，我还是觉得自己听起来像个傻小孩。 ↩︎

2. 我还记得我爸告诉我他给我买了一块 10MB 的硬盘，而私下里他其实买了一块 40MB 的硬盘想给我个惊喜。那看起来大得离谱。“我再也不需要新硬盘了！” ↩︎

3. 我的天，我们甚至又在用 vi 了！我的第一个编辑器！ ↩︎

4. 我构建了一个 electron 应用！而且做起来太容易了！现在读那些奇怪的论文之类的东西也容易多了，因为我可以让 LLM 帮我把所有数学术语翻译出来。 ↩︎

5. 我记得有一次我试着告诉 Alex Crichton，我以前是怎么“通过把支票寄到邮局，从纸质目录上订购共享软件”的，而他的反应是“那句话里的名词我一个都听不懂”。这是我人生的高光时刻，仅次于 Rust 1.0。哦，也许还有我孩子的出生和结婚。大概吧。 ↩︎

6. 我不是说 Rust 是唯一合适的语言。我甚至不是说 Rust 合适的方式是唯一合适的方式。比如我听说 Go 非常适合智能体编程，而且我相信这一点：我认为它命中了另一个甜点区，一个能帮助智能体快速迭代的甜点区（尽管我确实怀疑智能体会让数据竞争和细微 bug 溜过去，而 Rust 本可以防止这些）。 ↩︎

7. 智能体开发为调优旋钮留出了更多空间，这对 Rust 的性能是好事，但它很可能更适合其他语言的性能调优。传统上，调优 GC 是一项真正需要 GC 专家的工作，但如今智能体很可能能很好地胜任这个角色。 ↩︎

8. 在这一点上，如今和智能体一起工作后，我更加确信符合人体工程学的 RC 的重要性。智能体很擅长引入处理异步任务捕获所需的额外 clone 之类的东西，但由此产生的代码读起来太烦人了，它真的掩盖了正在发生的事情。 ↩︎

9. “Claude，这不是我们讨论过的东西！”——我，太经常这样了。 ↩︎

10. 不过就差那么一点，对吧？我就是……没法把飞机降落下来。 ↩︎

11. 很多时候，C++ 库认为告诉用户“你拿的方式不对”就足够了——也就是说，用户要为滥用 API 导致未定义行为负责。Rust 则明确表态：安全的 API 必须保护其用户，无论他们滥用得多厉害。 ↩︎

12. 平心而论，如果 Rust 遇到一连串 CVE，那么像 C++ 和 Java 这样的其他语言遇到的简直是洪水，因为它们缺少 Rust 类型系统的保护。 st 明确表态：安全的 API 必须保护其用户，无论他们滥用得多厉害。 ↩︎

13. .h 文件的复仇？ ↩︎