支撑 GitHub Copilot 以及越来越多微软产品的软件引擎现在完全是用 Rust 语言编写的，其中大部分迁移工作是由人工智能（AI）程序完成的。这次迁移的成本约为 12 万美元（以 AI 计算单元的形式支付），同时还需要开发人员花费大约三周的时间来进行代码的调整与优化。然而，开发团队也遇到了代码中出现的几十处问题（即“回归错误”），这表明 AI 在理解 Rust 语言方面仍存在挑战。整个迁移过程分模块逐步进行，共经历了 14.5 周的时间，期间发布了 135 个版本。平均每天有大约 1.3 个代码迁移请求被提交。最终，AI 程序将 43 万行的 TypeScript 代码转换成了 80 万行的 Rust 代码。为了保持迁移工作的简洁性，迁移过程仅针对具体的模块进行了替换，而没有对 Rust 运行时本身的结构进行优化；这部分工作将留待后续进行。Rust 语言以其高效的性能而闻名——在一次基准测试中，研究人员测量了 Rust 运行时完成 1,000 个任务周期的速度：使用共享客户端和 100 个并发任务流时，Rust 运行时每秒可以完成 120 个任务周期，相比 TypeScript 实现的速度提升了 15.9 倍。在内存使用方面，使用 TypeScript 语言时，10 个客户端同时运行需要消耗 1,383 MB 的内存；而使用 Rust 语言后，同样的任务量仅消耗 126 MB 的内存。在 Rust 语言中，所有任务都在同一进程中完成，无需启动额外的后台进程（这是 TypeScript 语言所必需的）。

从 VS Code 到 Microsoft Office 的 Copilot乍一看，大多数用户可能不会意识到 Copilot 运行时的应用范围有多广泛：它不仅支持 GitHub Copilot 的命令行界面和 Copilot 应用程序，还涵盖了 SDK 以及 GitHub Copilot 的云服务。Copilot 还存在于 VS Code、Visual Studio、Excel、Outlook、PowerPoint 以及众多其他微软云服务中。

最初，运行时是用TypeScript编写的，并使用Node.js作为框架、V8作为执行引擎。TypeScript和Node非常适合快速开发，但在大规模使用时，它们在提供快速启动和服务器密度方面表现不佳。“这绝不是声称每个大型TypeScript程序都应该变成Rust。我们的需求强调通过C ABI进行嵌入、低启动和稳态开销，以及可预测的资源使用。Rust让这些目标成为可能，”微软杰出工程师Stephen Toub在一篇解释整个过程的文章中写道。该项目使用Copilot重写Copilot，而后者又使用了多个LLM——GPT-5.6 Sol和Claude Opus 4.8都被点名——根据每个LLM的天然优势来执行任务的不同部分。博览群书但话多的智能体Toub评估认为，智能体的使用总体上是成功的。事实上，如果手工完成，这个项目将耗时数年、耗资数百万美元。Toub指出，智能体表现出几种令人惊讶的涌现行为。其一，它们花在收集信息上的时间远远多于实际编写代码的时间。“AI疯狂输出代码的流行形象几乎完全反了；在这种规模下，工作看起来更像是迭代式调查，检查当前状态、形成假设、进行有针对性的更改、反复冲洗和重复，”他写道。另一个令人惊讶之处是，会话与其他会话交互的频率之高，无论是它们生成的会话还是完全其他的会话。最棘手的转换之一是session.ts文件，它有超过30,000行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万美元（以代币形式支付），但使用Rust也存在潜在的风险。Toub指出：对于大型语言模型（LLM）和懒惰的程序员来说，只要代码能够成功编译，就被视为“有效的Rust代码”；然而在整个开发过程中，该项目还是遇到了许多代码质量问题（即所谓的“代码回归”现象）——有些功能在更新后不再能够正常工作。编译器本身无法判断函数的执行顺序是否正确、程序是否能够在可接受的时间内完成、是否满足开发者的隐含要求，甚至无法确认代码在逻辑上是否连贯一致。在上周于蒙特利尔举行的RustConf会议上，咨询专家Lisa Crossman警告开发者不要将编译器视为判断Rust代码是否有效的“权威”：她表示：“Rust确实可以阻止程序员编写不安全的内存操作代码，但它无法阻止程序员编写错误的程序。”明智的开发者应该将编译器视为一种“教学工具”，通过分析编译错误来更深入地理解Rust语言的规则与特性。

另一方面，LLM只是将编译器当作一个黑箱，用笨拙、低效的变通方法反复冲击它，直到某一种方法勉强通过为止（也许这正是Zig创始人Andrew Kelley称Bun的Rust代码为“未经审查的垃圾”时的意思）。在Toub的案例中，他发现编译器认可的回归可能来自模糊的语义和行为、分支漂移、未移植的缺失功能，以及替换代码的不同行为。“这绝不是反对Rust编译器的论据，”Toub写道。“但‘如果能编译，就是正确的’这句话只有当作玩笑才有用。”®