当所有人用 Python 写 Agent 时，他却说：Rust 才是 vibe coding 的终点

在 AI 圈的共识里，vibe coding 等于 Python、TypeScript、JavaScript。但 Sentry 的 Rust SDK 维护者 Daniel Szoke 却抛出一个反直觉结论：真正适合 AI Agent 写代码的，其实是 Rust。这场分享不讲情怀，只谈一个被严重低估的变量——如何系统性地对抗 LLM 的错误。

反直觉开场：最不“好写”的语言，反而最适合 AI 写？

如果你问任何一个 AI 工程师，哪种语言最适合 vibe coding，答案几乎是统一的：Python、TypeScript、JavaScript。理由也很直接——语法简单、约束少，模型第一次就能吐出“能跑”的代码。

Daniel Szoke 一上来就承认这个共识存在，但紧接着来了一个转折：这套判断标准，本身就是为“人”设计的，而不是为“AI Agent”设计的。他直言，Rust 之所以不在候选名单里，很大一部分原因不是它不适合，而是“大家默认它对模型不友好”。

问题在于：我们是不是把“模型能不能轻松写出来”这件事，看得太重了？

真正的瓶颈不是生成代码，而是防止 AI 一路写错

Daniel 的核心论点只有一句话，却足够扎心：“模型是否容易写对一门语言，这件事被严重高估了。”

在 vibe coding 或 agentic coding 的世界里，真正的风险不是“写得慢”，而是“错得悄无声息”。Python 和 JavaScript 的自由度，让 LLM 看起来很聪明：代码能跑、逻辑看似合理。但一旦模型在边界条件、并发、状态管理上犯错，你往往是最后一个知道的。

业界常见的补救方式，是引入更多检查：测试、静态分析、review agent、甚至再套一层 AI 来审 AI。但 Daniel 指出，这些都不是确定性的防线。如果你没有一个“绝对的、确定性的 guard”，系统规模一旦放大，失败只是时间问题。

Rust 登场：把“纠错”这件事，前移到编译期

这正是 Rust 出现的时刻。Daniel 不是在夸 Rust 快或者优雅，而是强调它在 AI 场景下一个被忽略的优势：错误暴露得足够早，而且足够具体。

当 AI Agent 编译 Rust 代码时，编译器本身就像一个极其严格、但完全确定性的 reviewer。它不会“差不多就行”，而是明确告诉你：哪里违反了所有权规则、哪里存在潜在的数据竞争、哪里线程不安全。

更关键的是，这种反馈是模型可以直接消费的。AI 不需要理解抽象的“最佳实践”，它只需要根据编译错误一步步修正，直到通过。这让“写—错—改”形成一个闭环，而不是在运行时埋雷。

“无畏并发”不是口号，而是给 AI 用的护栏

Daniel 特别点出了 Rust 的一个经典特性：fearless concurrency。他给了一个简单示例——当代码在并发场景下不安全时，Rust 会直接拒绝编译，并迫使你使用线程安全的类型。

对人类开发者来说，这可能是学习曲线；对 AI Agent 来说，这却是清晰的行动指令。模型不需要“理解并发哲学”，它只需要把不合法的类型，替换成编译器允许的那一个。

当然，代价也很明确：更多约束、更多失败的第一次编译。但 Daniel 的态度很直接——这些约束换来的，是系统级别的安全感，而不是祈祷式的正确性。

总结

这场分享真正颠覆的，不是“用不用 Rust”，而是我们评判 vibe coding 语言的标准。Daniel 的信息很清晰：当 AI 成为主要写代码的主体时，语言是否“好糊”，远不如是否“好纠错”重要。

对 AI 从业者来说，这意味着两件事：第一，不要只为模型的舒适区选工具，而要为系统的失败模式选工具；第二，未来的 Agent 架构，很可能会越来越偏向“强约束 + 自动修复”的组合。

也许短期内，Python 依然是最快的路。但如果你在构建的是一个不能悄悄出错的 AI 系统，Rust 提供的，可能正是那条更长远的安全边界。

关键词： Rust， vibe coding， AI Agent， 大语言模型， 代码生成

事实核查备注： 需要核查：演讲者姓名拼写（Daniel Szoke）、其身份（Sentry 的 Rust SDK 维护者）、视频发布时间（2026-05-27）、演讲是否为赞助内容的明确声明