21CTO导读：Rust 编译器并未受到 LLM 的各种怪异行为的影响。

这次迁移据称耗费了约 12 万美元的 AI 代币，外加开发人员团队大约三周的时间。然而，管理人员还不得不应对最终代码中存在的几十个回归错误，这表明 AI 在理解 Rust 语言方面仍然面临挑战。 

这项工作逐个模块地更新运行时环境，直至完成，历时 14.5 周，发布了超过 135 个版本。平均每天大约有 1.3 个端口合并请求被提交。

总体而言，代理将 43 万行 TypeScript 代码转换为 80 万行生产环境 Rust 代码。为了尽可能简化移植过程，移植工作仅逐个替换 TypeScript 模块，并未着手优化运行时本身的结构。这项工作将在下一步进行。 

而以性能精简著称的 Rust 也没有让人失望。

一项基准测试测量了运行时在共享客户端和 100 个并发流水线的情况下完成 1000 个单回合会话生命周期的速度。原始 TypeScript 实现每秒完成 7.55 个生命周期，而进程内运行的 Rust 每秒完成 120 个生命周期——在该特定工作负载下速度提升了 15.9 倍。

在内存方面，使用 TypeScript 重写版本运行 10 个客户端代理的批次消耗了 1383 MB 内存，而 Rust 重写版本运行相同的代理集群仅消耗了 126 MB 内存。此外，Rust 版本中所有工作都在进程内完成，无需像 TypeScript 那样启动外部后台进程。

从 VS Code 到 Microsoft Office 的 Copilot

乍一看，大多数用户可能并不一定了解 Copilot 运行时的普及程度。它为GitHub Copilot命令行界面 (CLI)、Copilot 应用、SDK和GitHub Copilot 云代理提供支持。它还出现在 VS Code、Visual Studio、Excel、Outlook、PowerPoint 以及无数其他 Microsoft 云服务中。

最初，运行时环境是用 TypeScript 编写的，框架是Node.js，执行引擎是JavaScript V8。TypeScript 和 Node 非常适合快速开发，但大规模应用时，它们在启动速度和服务器密度方面表现不佳。 

“这绝不是说每个大型 TypeScript 程序都应该改成 Rust。我们的需求强调的是通过 C ABI 进行嵌入、低启动开销和稳定运行开销，以及可预测的资源使用。Rust 使这些目标成为可能，”微软的杰出工程师Stephen Toub在一篇解释整个过程的文章中如此写道。

该项目使用 Copilot 重写了 Copilot，而 Copilot 又使用了几个 LLM（GPT-5.6 Sol 和 Claude Opus 4.8 都被用到）来执行工作的不同部分，具体取决于每个 LLM 的自然优势。  

博览群书但爱说话的代理人

Toub指出，人工智能体表现出几种令人惊讶的涌现行为。例如，它们花费在收集信息上的时间远远超过实际编写代码的时间。  

他写道：“人们普遍认为人工智能会生成代码，这种印象几乎是本末倒置的；在这个规模下，这项工作看起来更像是迭代调查，检查当前状态，形成假设，进行有针对性的更改，然后反复进行。” 

另一个令人惊讶的发现是，会话之间互动非常频繁，无论是它们生成的会话还是完全不同的会话。 

最棘手的转换之一是一称为session.ts文件，它包含超过 3 万行的 TypeScript 代码，涉及运行时的方方面面。移植工作最终耗时 25 小时，首先花了 56 分钟阅读文档，并调用了 122 次工具进行澄清。然后，它生成了 15 个子会话，每个子会话都创建了自己的工作树和代理。之后，它们开始相互通信。

利用内置的协调技能，一个会话找到了所有其他活跃会话，并向任务重叠的会话发送消息，请求协调。

编译器是老师，而不是神谕。 

鉴于其性能优势，Rust 已成为应用程序重写的热门语言。例如，Bun 的创建者 Jarred Sumner 最近将 Anthropic 旗下的 JavaScript 运行时和工具包（包含约 53.5 万行 Zig 代码）移植到了 Rust，几乎完全使用了 Claude 代理。截至 7 月 30 日，该实验性的 Rust 移植版本在 Linux x64 glibc 上通过了Bun 现有测试的99.8%，而稳定版本仍然基于 Zig 代码库发布。

这项工作花费了价值 16.5 万美元的Token。 

但正如 Toub 所发现的那样，使用 Rust 也存在一些隐含的危险。 

对于精通 Rust 的程序员或懒惰的程序员来说，只要代码能够编译，那么它就是有效的 Rust 代码。

但在整个过程中，该项目的代码中出现了数十个回归错误。回归错误指的是原本运行正常的功能，在更新后却无法正常运行。 

例如，编译器根本不知道函数的顺序是否正确，作业是否以可接受的成本完成，是否满足开发人员未写明的要求，或者它内部是否连贯一致。

在上周于蒙特利尔举行的 RustConf 大会上，顾问Lisa Crossman发出警告说，不应将编译器视为“神谕”，即对 Rust 代码是否有效拥有最终决定权。“Rust 阻止的是程序编写内存不安全的代码；但它并不能阻止程序正确地编写错误的程序，”她如此说道。 

如果开发者足够智慧，他们会将编译器视为老师，通过解码错误来更好地理解语言的领域。但是LLM则恰恰相反，他们只是把编译器当作一个黑盒子，用粗暴低效的变通方法反复尝试，直到找到一个合格的方案（也许这就是 Zig 的创建者 Andrew Kelley 称 Bun 的 Rust 代码为“未经审查的垃圾”时的意思）。 

Toub 还发现，编译器认可的回归可能源于语义和行为的歧义、分支漂移、未移植的缺失功能以及与替换代码不同的行为。 

“这绝不是在反对 Rust 的编译器，”Toub 写道。“但‘如果能编译，就一定正确’这种说法只能当个笑话用。”

作者：场长