GitHub Copilot 运行时 AI 移植 Rust 实录：43 万行 TS 变 80 万行，性能快 15.9 倍、内存降九成

微软把 GitHub Copilot 的运行时从 TypeScript 整体搬到了 Rust，执行方不是外包团队，而是 AI 代理。微软杰出工程师 Stephen Toub 在长文中披露：这次移植产出 80 万行生产级 Rust，替换掉 43 万行 TypeScript，token 成本约 12 万美元，外加一名工程师三周的人工投入。性能收益同样硬——单轮会话生命周期处理量从每秒 7.55 次升到 120 次，特定负载下实现 15.9 倍加速，10 客户端 Agent 批的内存占用从 1383MB 降到 126MB。结论很直接：AI 大规模重写在成本上已经跑通，但验收标准必须严格越过「编译通过」这一层。

被替换掉的运行时，到底有多关键

这个运行时不像名字听起来那样边缘。它支撑着 GitHub Copilot CLI、Copilot App、SDK 以及 Copilot 云 Agent，同时还会出现在 VS Code、Visual Studio、Excel、Outlook、PowerPoint 以及一批微软云服务里。它原本用 TypeScript 搭配 Node.js 实现，优点是开发快、生态顺手；但规模化部署之后，两个瓶颈压不住了——启动速度，以及服务器部署密度。这也是为什么微软宁愿承担一次全量重写的风险，而不是继续在原有栈上做局部优化。

性能与成本：15.9 倍加速是怎么测出来的

Toub 给出的数据相当完整：整个移植跨越 135 个 release、耗时 14.5 周，平均每天开出 1.3 个移植专用 PR。成本大头是 token，约 12 万美元，另有开发者三周的人力。他的对照估算是，同样的活儿纯手工完成需要数年时间和数百万美元。

内存差距的成因值得单独说一句：Rust 版本全程在进程内完成工作，不需要像 TypeScript 那样为每次补全额外拉起后台子进程。这类架构级差异带来的收益，往往比单纯的语言性能对比更大。

「AI 疯狂吐代码」的画面几乎是反的

这次移植顺带给「AI 编程」祛了魅。Toub 观察到一个反直觉现象：代理花在收集信息上的时间，远超真正写代码的时间。大众印象里 AI 疯狂吐代码的画面几乎是反的；在这个规模上，工作看起来更像迭代式调查——检查当前状态、形成假设、做一处针对性修改，然后循环。

最棘手的文件：session.ts，3 万行耗掉 25 小时

session.ts 有 3 万多行 TypeScript，触及运行时的方方面面，是整个移植中最难啃的骨头。代理在它身上花了 25 小时，其中光读文档就占 56 分钟，做了 122 次工具调用来澄清需求，随后派生出 15 个子会话，每个都拥有自己的 worktree 和 agent 并开始互相通信；一个内置编排技能会找到所有活跃会话，向任务存在重叠的那些发消息请求协作。

编译通过不等于正确：AI 写 Rust 的真正风险

移植过程中出现了几十个回归——原本正常的东西，改完之后不工作了。Toub 对此的总结相当尖锐：如果编译通过就代表正确，那这句话只配当笑话听。编译器并不知道函数顺序对不对、任务的代价是否可接受。

来自 RustConf 的呼应

这一判断在社区侧也有印证。上周蒙特利尔 RustConf 上，顾问 Lisa Crossman 同样警告不要把编译器当成神谕：Rust 能阻止 agent 写出内存不安全的代码，但阻止不了它写出语义错误却完全合规的程序。对依赖 AI 重写的项目来说，这句话几乎就是验收规范的起点。

横向对照：Bun 的 Zig 到 Rust 移植

两个案例的量级与成本高度接近，说明「AI 大规模重写」已经形成一类可验证的工程现实：便宜、够快。但 Bun 这一侧也带着争议——Zig 创始人 Andrew Kelley 至今称这批代码是「没人审的垃圾」，质疑的正是人工审查缺位。

FAQ

12 万美元的 token 成本，对普通团队有参考价值吗？

有参考意义，但需要校准。这笔钱对应的是 43 万行到 80 万行量级、横跨 135 个 release 的工业级移植，且始终有一名资深工程师全程把关三周。小团队做几千行量级的重构，绝对成本会低两个数量级，但单位成本不会自动等比下降——因为信息收集与验证环节的工作量，并不随代码行数线性缩放。

为什么换成 Rust 能快这么多？

两个原因叠加。一是运行时本身去掉了 Node.js 的启动与解释开销；二是 Rust 版本全程在进程内完成工作，不必为每次补全额外拉起后台子进程，这直接解释了 1383MB 对 126MB 的差距。至于 15.9 倍，是特定负载下的实测值，不代表所有场景都能拿到同等倍数。

AI 重写出来的代码可以直接上生产吗？

可以，但验收口径必须换成语义正确性而非编译结果。微软这次出现了几十个回归，Bun 的移植被上游创始人质疑缺少人工审查。可落地的做法是：保留完整测试基线、分批 release、逐段人工复核，并把「原本正常的功能是否仍然正常」作为独立于编译结果的检查项。

小结

这次移植最值得记住的不是 15.9 倍，而是成本结构的变化：数年和数百万美元，被压缩成 12 万美元加三周。它把「大规模重写」从不可讨论的选项变成了可计算的工程决策。但 Toub 与 RustConf 给出的提醒同样清楚——AI 代理在这个规模上的主要工作是调查而非产出，而验证这件事，短期内仍然只能由人来完成。谁能在流程里把验证做扎实，谁才真正吃得到这波红利。