Rust 核心开发者发出“存在主义焦虑”：Agent 写代码的时代，语言设计者还有饭碗吗？

本文永久链接 – https://tonybai.com/2026/10/18/rust-in-the-agentic-era-guardrails-proofs-and-design-languages

大家好，我是Tony Bai。

【导读】

当 AI Agent 开始接管敲代码的工作，一辈子研究编程语言设计的人，会怎么想？Rust 核心团队成员 Niko Matsakis 在博客里坦白，LLM 让他产生了“存在主义焦虑”。不过他也给出了自己的回答：人类依然有位置，语言设计依然重要，而 Rust 恰好是 Agent 时代的“天选语言”。更值得关注的是，他认为 Rust 还能更适合 Agent，并提出了一个大胆的北极星目标：不再有 unsafe 代码。

【文章要点】

• Rust 在 Agent 时代的热度，以及背后的两个原因（性能默认值、类型护栏）。
• “软件工厂”三支柱：设计、构造、优化。Rust 在后两者上有优势，设计仍是开放问题。
• 测试不够，类型系统也不够：需要证明系统（Verus、Kani、Lean 等）。
• 反直觉结论：护栏越强，Agent 优化得越激进，性能反而越好（lean-zip 实验）。
• 类型系统与证明系统不是替代关系，而是分工关系（借用检查器简化 SMT 求解）。
• Rust 该往哪走：更强的表达力、可扩展编译器、“不再有 unsafe 代码”的北极星。
• 终局猜想：人类写“设计”，Agent 写“代码”，设计语言成为新战场。

一个语言设计者的焦虑

Niko Matsakis 是 Rust 语言的核心设计者之一。他从小学五年级开始写代码，那时的电脑只有 5MHz 主频、512K 内存。

他说，几十年来电脑天翻地覆，但“往文件里敲代码”这件事，本质上几乎没变过。直到几年前，一切被掀了个底朝天。

这让他陷入了真实的焦虑：我的编程技能还有用吗？我的语言设计技能呢？

他的结论分三层：

• 人类在编程中依然有角色；
• 编程语言设计依然有意义；
• Rust 是 Agent 开发的“很好的契合”，但还能“更好”。

这篇文章，是他在 SPLASH 大会 REBASE 研讨会演讲的博客版。下面我们拆开来看，并补充几份关键证据。

Rust 在 Agent 时代，真的火了

先看一组数据。Niko 在文中引用了 David Tolnay 的观察：Meta 工程师今年写的第一方 Rust 代码，是此前 9 年总和的两倍。

这个增速，在近期的语言增长中仅次于 TypeScript。

为什么？Niko 认为有两层原因。

第一层是“试错成本变低了”。Agent 让尝试新语言变得很容易。既然选哪种语言都一样轻松，为什么不选运行更快的？

第二层才是关键：Rust 本身就适合 Agent 写。OpenAI 联合创始人 Greg Brockman 今年 1 月也发过一条类似观点：Rust 是 Agent 的完美语言，因为“能编译就大致正确”。

Niko 谨慎地补充了一句：这不是说只有 Rust 适合，像 Go 这样的语言在“让 Agent 快速迭代”上也有独特优势，只是他怀疑 Agent 会放过一些 Rust 能拦住的数据竞争和隐蔽 bug。

软件工厂的三根支柱

Niko 把“Agent 软件工厂”拆成三根支柱：

• 设计（Design）：说清楚代码到底要做什么；
• 构造（Construction）：写出符合设计的代码；
• 优化（Optimization）：让代码跑得高效。

三者都没有被“完全解决”，但进展不一。Rust 的主战场在后两者。

优化：Rust 默认就快，还给你一堆“旋钮”

Rust 的设计哲学是“默认高性能”：惯用写法通常也是最快的写法。

同时，它又给了你足够多的“旋钮”：

• 栈分配还是堆分配；
• 指针间接层放在哪里；
• 结构体内存布局怎么排；
• 极端情况下，直接内联汇编。

过去，调这些旋钮是一门“黑魔法”。现在，Agent 正在把它变成日常。

Niko 提到两个例子：

• 做高性能密码学算法的人，原本靠手写汇编调优，现在也开始让 Agent 来做；
• 做网络服务的开发者，可以借助 dial9 这样的性能分析器，让 Agent 有效定位异步代码里的长时间 poll 和阻塞问题。

于是，一个高效的优化闭环出现了：

Niko 还有一个有意思的判断：既然写代码的主力换成了 Agent，Rust 可以容忍多一点显式的 clone() 噪音，毕竟 Agent 不嫌烦。但“主干逻辑”仍要清晰，因为人类现在更多是在读代码，而不是写代码。

可靠性：测试不够，类型系统也不够

比起性能，让人留下来的是可靠性。

Dijkstra 早就说过：测试只能证明 bug 存在，不能证明 bug 不存在。

用 Agent 写代码时，这个问题更严重。Niko 说，常常是前几个测试看着漂亮，下一个测试就“离谱到不可思议”。一查才发现，Agent 完全误解了他想表达的逻辑。

这时类型系统的价值就显现了。Rust 的护栏不止是“字段名对不对”，还包括“永远不用手动关 socket”这类资源管理保证。

但 Niko 马上泼了一盆冷水，并仿 Dijkstra 造了一句：

类型系统能证明某类 bug 不存在，却无法证明程序是正确的。

要证明“做对了”，而不只是“没做错”，就需要证明系统。Rust 生态里已经有 Verus、Creusot、Aeneas、Kani 等工具。最基本的用法是证明代码不会 panic，更进一步，可以断言代码确实算出了你想要的结果。

反直觉：护栏越强，跑得越快

这是全文最有意思的一点：证明不只让代码更对，还能让代码更快。

逻辑很简单：如果你能向 Agent 下达“随便怎么改，只要你能证明结果仍然正确”的指令，Agent 就可以放开手脚做激进优化。

Niko 引用了 Lean 社区 Kim Morrison 的实验。

他们用 Lean 写了一个 DEFLATE 压缩库 lean-zip，并证明了“压缩后再解压，必然还原原始数据”。然后放手让 Claude 和 Codex 等 Agent 自主优化，条件只有一个：改了实现就必须更新证明。

在 212MB 的 silesia 标准语料上，对比纯 Rust、无 unsafe 的 miniz_oxide：

据作者统计：

• 最快档位：吞吐高约 15%，输出小约 8.8%；
• 默认的 L6：快约 30%；
• L9：快约一倍。

不过，这个实验不能被过度解读。作者本人也明确说了：

• 他并不是在宣称“Lean 比 Rust 快”，在 Rust 里写出高性能实现依然容易得多；
• 没有人用同样的方式去优化 miniz_oxide，对比并不完全对等；
• Lean 版本内存占用更高，解压反而慢约 1.45 倍；
• 精心调优过的 libdeflate 仍然远远领先。

它真正证明的，是另一件事：当你能写出刻画算法的定理时，就可以放心地把优化外包给 AI，而不必逐行人工审查。

这正是“护栏越强，自由度越高”的最佳注脚。

有了证明系统，还要类型系统吗？

答案是：当然要。

Niko 举了个小例子。同样一句“赋值后断言相等”：

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

在 Java 里，你无法证明这个断言一定成立，因为可能有别的线程正在修改 this。

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

在 Rust 里，断言必然成立（前提是 Bar 的相等比较满足自反性）。因为 &mut self 保证了唯一引用。

这正是 Verus 的工作方式：它信任 Rust 借用检查器对唯一性的追踪，从而大幅简化 SMT 求解器的工作，让证明更快、更稳。

所以，两者是分工关系：

Rust 该往哪走？

Niko 给出了三条路线：

1. 能编译，就能跑（If it compiles, it works）

类型系统要更强。有些性质目前表达不了，比如“这个方法只读某一个字段”（视图类型）、内部引用，甚至“日志里不得出现个人敏感信息”这类高级约束。把这些限制解除，Agent 才有空间去证明更复杂的性质。

2. 低层够用，高层也好用

继续保留性能旋钮，同时让代码意图清晰。在 Agent 写代码的世界里，不必再为“少打几个字符”而过度纠结。

3. 可扩展、多用途的编译器

今天用 Verus 等证明工具，需要宏和锁定编译器版本，体验很“野路子”。Rust 应该把可扩展性带进编译器，以便支持 GPU、深度语言互操作，以及接入定理证明器这类需要“不止 token”的工具。

在这三条路线之上，Niko 提出了一个北极星目标：

不再有 unsafe 代码。

注意，他不是要取消 unsafe 关键字，而是要让开发者有能力证明自己写的所有 unsafe 代码都是正确的、不会引发未定义行为。

他的理由是：既然 Agent 越来越擅长挖漏洞，单靠“把风险圈出来”已经不够，要想遏制源源不断的 CVE，必须升级到“可证明”。

他的愿景是：看到使用最广泛的那批 Rust 库，都被证明是 sound 的。

真正的战场：设计

三根支柱里，“设计”是最开放的问题。

Niko 观察到，目前业界的最佳实践，基本是“Markdown 驱动开发”：写一堆文档，然后祈祷 Agent 认真读。

他认为 Rust 在这里可做的事，包括把“接口”与“实现”分离，便于单独审查接口，或发现 Agent 悄悄改动了接口。（他自嘲：这是不是 .h 头文件的复仇？）

更大胆的想法是专用的“建模语言”：让你和 Agent 在高层快速迭代设计与不变量，而不必陷进代码细节。

这与 AWS 工程师 Marc Brooker 的观点不谋而合。Brooker 提出了一个“反馈回路假说”：

• Agent 本质上是“带反馈回路的 LLM”；
• 能提供有效、精确反馈的任务，对 Agent 而言就是“容易”的；
• 因此，写一个正确的高性能存储引擎，长期看可能比做一个讨喜的修图网站更容易，因为前者的规格明确、可自动验证，而后者需要人类这种“又慢又不稳定”的反馈者。

这意味着，直觉里“难”的系统软件可能变容易，而“容易”的产品设计反而更珍贵。

Niko 由此给出了终局猜想：

这并不会让传统语言设计失去意义，只是权衡的天平变了：

• 过去：语言要对“人类作者”友好；
• 未来：语言要对“人类读者 + Agent 作者 + 证明工具”同时友好。

小结：焦虑，也许正是新起点

回到开头的问题：语言设计者还有饭碗吗？

Niko 的回答是：有，只是工作重心要变。少关心“怎么让人少敲几个字”，多关心“怎么让机器可验证、让人容易理解”。

对每一个开发者来说，这篇文章也有几点启发：

• 别只盯着 Agent 能生成什么，要盯着它的反馈回路是什么。回路越精确，Agent 越可靠。
• 用类型和证明给 Agent 划边界，而不是靠 Review 兜底。边界越清晰，授权越大胆。
• 设计与规格的能力，会越来越值钱。当“写出来”不再稀缺，“想清楚”才是稀缺品。

当然，也需要保持清醒：证明工具的使用门槛依然很高，lean-zip 之类的实验有明显局限，Go 等语言也各有 Agent 适配优势。Rust 是否会成为 Agent 时代的“最优解”，还远没有定论。

但至少有一点是确定的：当机器开始写代码，“能被验证”就成了最硬的通货。

参考资料：

• Niko Matsakis：《What agents mean for Rust (and vice versa)》- https://smallcultfollowing.com/babysteps/blog/2026/10/14/agentic-dev-and-rust/
• Kim Morrison：《Why Lean is faster than Rust》- https://kim-em.github.io/blog/2026-7-24-why-lean-is-faster-than-rust/
• Marc Brooker：《What’s Easy Now? What’s Hard Now?》- https://brooker.co.za/blog/2026/05/18/whats-easy-whats-hard.html

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。