用 Copilot 把 Copilot 的运行时重写成 Rust 居然只用了几个月

把 GitHub Copilot 的 runtime 从 TypeScript/Node.js 迁移到 Rust，这次重写涉及 80 0,000 行生产代码，由一名开发者主导并在几个月内完成，期间通过 128 个 PR 渐进式合并到 main 分支。结论是性能提升了几个数量级，且大部分代码是由 AI Agent 编写的。

为什么要舍弃 TypeScript 换成 Rust

这次迁移的核心矛盾在于“共享运行时”与“运行环境约束”之间的冲突。Copilot agent runtime 不仅仅支撑 Copilot CLI，它实际上是很多产品的底层引擎，包括 VS Code、Visual Studio、CCA、Copilot Code Review (CCR)、Copilot Cowork、Copilot Studio，甚至包括 Excel、Outlook、PowerPoint 和 Word。

这些产品在架构上其实都是一个壳，内部套用了同一个 runtime 加上各自的定制化逻辑。之前很多产品自己实现 agent loop，后来统一换成了 GitHub Copilot SDK，目的是为了共享安全性和可靠性，让一个地方的修复能同步到所有产品。

但问题出在最初的选型上。Copilot CLI 最初是用 TypeScript 写的，跑在 Node.js 和 V8 引擎上，UI 则是 Ink 和 React。对于一个终端工具（TUI）来说，这种组合开发快且性能勉强够用。但当这个 runtime 需要被嵌入到其他对启动速度、内存开销和服务器密度要求极高的环境下时，Node.js 的弊端就显现出来了。

而且之前的架构设计比较仓促，TUI 层和 runtime 层耦合得太死。为了快速提供编程访问能力，当时采取了一个比较权宜的方案：直接在 CLI 之上叠了一层 SDK。这种缺乏清晰分层的设计在规模扩大后成了沉重的技术债。

具体的迁移路径与实操细节

这次重写没有采取传统的“闭门造车然后一次性切替换”的方案，而是选择了渐进式迁移。

• 代码规模与提交： 最终产出了超过 800,000 行的 Rust 代码。
• 交付方式： 整个过程分布在 128 个 pull requests 中，分批次合并到主分支并逐步上线。
• 人力成本： 在 AI Agent 的辅助下，原本需要一个开发团队花一两年时间才能完成的任务，现在由一名开发者在几个月内搞定。
• 风险控制： 在渐进式交付过程中确实出现了一些回归错误（regressions），但由于是小步快跑，发现和修复的速度都很快。

这种模式最关键的一点是，在一名开发者利用 AI 进行重写的同时，团队其他成员并没有停下来，而是继续在原有的 runtime 上扩展功能。这意味着重写过程没有阻塞业务迭代。

性能与架构的最终收益

从 TypeScript 迁移到 Rust 之后，最直观的感受就是性能实现了数量级的提升。对于一个被广泛嵌入到 IDE 和 Office 软件中的底层组件，内存占用率的降低和启动速度的加快直接决定了最终用户的体感。

通过这次重构，Copilot agent runtime 彻底脱离了对 Node.js 运行时的依赖，解决了之前 SDK 依赖于 CLI 这种不合理的层级关系，实现了真正的解耦。