微软用AI花12万将Copilot转Rust，运行速度提升数倍，TS开发者必看

微软方面投入了三个礼拜的时间, 并且花费了十二万美元的token额度, 这一举措让AI代理去完成四十三万行TypeScript代码到Rust语言的全量移植工作, 虽然使得性能实现了十五倍的飙升, 可是这同样的情况也直接撕开了机器自动编写代码过程之中所隐藏的盲区。

43万行代码135个PR的搬家工程

这次移植由微软杰出工程师Toub来主导, 把支撑CLI、App、SDK和云Agent的运行时从TypeScript加Node.js换成了纯Rust。整个过程横跨135个模块, 历时14.5周。平均每天开1.3个移植PR。最终产出了80万行生产级Rust代码。

在成本方面, token 的消耗金额大约为十二万美元, 同时工程师本人还投入了三周的时间。据 Toub 进行估算, 如果纯粹依靠手工来完成了同等的工作量情况，是需要花费数年的时间以及数百万美元预算的。

正是因为有着这笔具体的投入, 这才换来了该运行时系统在微软旗下的 VS Code、Excel 产品以及多个云服务中实现了全面的替换工作。。

每秒处理量从7.55跳到120

根据基准测试的结果来看, 原来的那种由TypeScript所实现的方法, 它在一个秒的时间段里面能够去处理的、属于单轮会话的生命周期的任务的数量为7.55个, 而使用了Rust版本并且是在进程内进行运行的这种情况下, 它能够达到的数量是120个, 在特定的负载条件下, 这种改变能够实现15.9倍的加速效果, 从上述的这个对比以及分析当中就可以得出这样的一个结论, 即在需要大规模去部署的场景下, 如果服务器配置是相同的话, 那么使用优化的版本可以让该设备同时承载的并发量的数量要多出十几倍。

内存方面的差距表现得更加突出。

在处理十个客户端请求这样一个场景下, TypeScript这个版本需要额外地去拉起后台的子进程来做补全的操作, 这就导致了内存占用率出现了大幅度的飙升, 而在Rust这个版本的全过程中都是直接完成在进程内部的, 仅仅消耗了126MB的内存, 下降的幅度接近百分之九十, 也因此使得服务器的密度得到了非常明显的提升。

AI花的时间不是写代码而是查资料

优采云注意到, 人工智能代理在收集信息这一环节上所花费的时间, 远远超出了它们实际编写代码所花的时间。他提到, 大众印象中人工智能会飞快地吐出大量代码的那种情景, 基本上与真实情况是相反的。

他指出, 在处理多达43万行规模的移植项目时, 整个过程更像是一种迭代式的调查工作。这种工作需要人们去检查当前的状况、形成各种假设、仅仅在一处进行修改以及进行反复的循环操作。

最让人犯难的那个模块, 是一个超过了3万行之多的大核心文件, 它牵连到了在运行时候出现的所有关键路径。AI用了25小时去进行移植作业, 在这当中, 花了56分钟去阅读相关的文档说明。

另外, 为了把这些需求搞得更清楚明白, 使用了122次工具调用, 并且还开启了15个不同的子会话来彼此沟通和一起协作完成这个任务。

几十个回归暴露编译器盲区

在整个移植过程里, 发生了非常多的回归问题, 一些原本没有问题的功能, 在修改之后立刻就坏了。Toub这个人说的很清楚, 编译能够通过这一件事肯定不代表代码就是正确的。

编译器虽然有办法挡住那些不安全的内存使用情况, 但是它的判断能力是有限的, 它没有办法去判定函数的调用顺序对不对, 也没有办法去了解任务所要付出的代价是不是合理的。

在上周举行的蒙特利尔Rust大会期间, 顾问Lisa也向 team 发出了警告, 提醒大家千万不要把编译器视作“神谕”, 因为Rust虽然具备阻止 agent 编写内存不安全代码的功能，但它却完全无法防止 agent 生成那些能够通过编译检查却在逻辑上存在错误的程序, 至于语义是否真正正确, 依然需要依靠人工来进行把关和审核。

Bun也走AI重写路线争议未消

把它作为一种对比的情况来看, 那个名叫Bun的项目的主要作者, 几乎完全借助于人工智能的技术手段, 把原本有53.5万行代码的Zig语言版本的JS运行时环境, 迁移为了Rust语言版本, 在这一过程中总共花费了16.5万美元的相关token费用。

现在这个更新后的版本, 在Linux x64且采用glibc架构的系统平台上, 已经顺利的通过了对于该Bun项目之前存在的所有测试结果中占比达到99.8%的大部分测试项目, 由此来证明其质量保障的一系列步骤和链条是非常完整, 且具有相当高的可信度的。

可是, Zig这个项目的创建者到现在为止都在公开场合说那个由AI生成的代码是“没有人检查过的垃圾”。这个表现给整个行业提了个醒, 说明AI大規模地重写代码正在变成一个可以验证的工程事实。

这种方案虽然便宜而且足够快, 但是接受和验收的标准不能仅仅停留在能够编译通过这一层面, 必须由人来亲自关注并确认语义层面的正确性。

规模化瓶颈才是换语言的真原因

微软当初选Rust, 这个事儿的出发点, 其实真不是要去搞什么性能方面的炫技行为。真正的原因在于, TypeScript配上Node.js这个组合, 在规模变得特别大的情况下进行部署的话, 那启动速度以及服务器的密度问题就直接变成了特别难解决的硬性瓶颈。

因为这个运行时它涵盖了VS Code、Excel啊还有好几朵云计算服务, 所以哪怕只是出现极其微小的比如毫秒级别的那种损耗情况, 它都会被大幅度地放大, 最终能够影响到高达亿次那种级别的调用操作。

Toub把整个过程的详细情况, 全部写成了一篇公开发布的长篇文章, 这篇文章不仅记录下了AI代理在实际工作中的处理步骤和流程, 还坦诚地说明了最终出现的一些问题缺陷, 对于此刻正在综合评估是否要让工作人员利用人工智能技术来辅助进行代码迁移工作的各个团队来说, 这篇包含了一百三十五个拉取请求实战内容的真实记录, 其实际参考和使用价值, 远高于任何一份学术性论文所能够提供的帮助。

你所在的这个团队, 是不是曾经试过利用人工智能技术去开展规模庞大的代码迁移工作呢? 关于这件事的实际效果如何, 以及在过程中所遭遇的那些让人头疼的坑以及积累的教训, 都热烈欢迎到评论区内来共同交流分享一下。