GitHub 重建了支撑 GitHub Copilot CLI、Copilot 应用和 Copilot SDK 的 Runtime。此前，该 Runtime 依赖 TypeScript、Node.js 和 V8 引擎。根据 GitHub 博客发布的文章，迁移后的结果是超过 800,000 行专用于生产环境的 Rust 代码，其中大部分借助人工智能智能体完成，并通过 128 个拉取请求逐步合并到主分支。
作者表示，这项工作在几个月内完成，主要由一名开发者参与，同时团队其他成员继续开发 Runtime 的能力并扩大其使用范围。GitHub 表示，迁移后性能提升了“大量级别”，但文章可见部分没有提供用于衡量这一提升的详细数据。
问题并不只在命令行界面
Copilot Runtime 并不只负责运行 CLI。它是多个版本和产品共用的层，包括 GitHub Copilot CLI、Copilot 应用和 Copilot SDK，以及 VS Code、Visual Studio、Cloud Agent、Copilot Code Review、Copilot Cowork、Copilot Studio，还有 Excel、Outlook、PowerPoint 和 Word 应用。
在此前的设计中，Runtime 与 CLI 高度交织。当产品需要以编程方式访问时，SDK 实际上构建在 CLI 之上，需要运行一个单独的 Node.js 进程，并通过 JSON-RPC 与其通信。这种方式快速且灵活，但给每个使用方应用带来了运行成本。
创建新的 CopilotClient 意味着要启动一个额外的进程来托管 Node.js 和 V8，解析由 TypeScript 生成的 JavaScript 代码，并承担与引擎相关的内存开销。此外，Node.js 中的崩溃事件可能终止会话，而应用至少需要监控两个进程。根据文章，使用 C#、TypeScript、Python、Rust、Go 和 Java 编写的 SDK 包，即使不需要 Node.js 执行其他任务，也至少要为额外的 Runtime 承担约 100 MB 的工作集内存。
为什么选择 Rust？
GitHub 为新层设定了明确目标：将 Runtime 与 TUI 分离，降低依赖和运行成本，支持在同一进程内集成，并提升可扩展性和可靠性。此外，GitHub 还需要一个 C ABI，使六个 SDK 版本能够通过不同的 FFI 机制使用 Runtime。
文章称，Rust 有助于满足这些要求，同时提供支持更先进安全模式的工具链、降低供应链风险，并通过设计提升代码正确性的保障。但文章同时强调，这并不是把所有大型 TypeScript 项目都转换为 Rust 的建议；这一选择源于与启动速度、内存、嵌入以及资源消耗可预测性相关的具体要求。
渐进式替换，而不是全面重写
GitHub 没有通过长期存在的分支，或在终点一次性完成转换来执行该项目。它选择在主分支内进行替换：每次将一个 TypeScript 组件替换为 Rust 组件。每个拉取请求都会添加一个调用 Rust 的薄封装层，并在同一改动中删除旧实现，使分支始终保持可发布状态，并让新代码直接在系统内接受测试。
- 其他开发者的日常工作得以继续，项目无需暂停。
- 每项改动都比全面重写更小，也更容易审查。
- 每一步都会运行 CLI 和 SDK 的端到端测试。
- 回归问题在迁移过程中被发现并修复，而不是推迟到最终转换时处理。
GitHub 还拒绝让每个组件的两个版本长期并行存在。该代码库每周会产生数百个拉取请求，而维护两种语言的实现和两套依赖会增加复杂性。对于管理可变状态的组件，例如会话编排器，对两个版本进行比较会更加困难，因为这些组件需要处理回调并连接系统的大范围部分。
这些数字揭示了什么？
最初的估算于 2026 年 5 月开始，当时约有 130,000 行 TypeScript，但这一数字没有反映实际工作量。原本计入 TUI 层的组件后来被迁移到 Runtime 中，同时迁移进行期间仍不断有新的 TypeScript 代码加入。因此，实际约有 430,000 行 TypeScript 经历了迁移过程。
同期，项目新增了约 300,000 行生产环境 TypeScript 代码，并删除了约 430,000 行；同时新增约 1,200,000 行 Rust，删除约 365,000 行。这些数字表明，代码库中 TypeScript 表面规模保持不变，并不意味着没有进展，而是掩盖了大量新增、删除以及职责重新分配。
为什么这则消息重要？
这次实践的实际价值不只在于使用 Rust，更在于如何管理一个由大量产品共享的基础层重写。对每个组件进行原子式替换，同时保持分支可发布并持续运行测试，可以降低“大转换”的风险，并让回滚或定位故障更加清晰。
另一方面，文章并不能证明这种方式适合每个组织，也不能证明人工智能智能体单独就能保证如此大规模重写的质量。此外，文章可见部分没有提供迁移前后的公开资源消耗测量，也没有说明审查、测试或处理回归问题所需的人力成本细节。因此，最明确的经验仍然与渐进式工程实践和层次分离有关，而不应将 Rust 或智能体视为适用于所有迁移工作的通用解决方案。