GitHub 于 2026 年 9 月 16 日在官方部落格发表技术文章（9 月 23 日更新），由 Stephen Toub 撰述，讲述如何用 GitHub Copilot 把 Copilot agent runtime 由 TypeScript/Node.js 重写为 Rust。官方指出，这个 runtime 支持 Copilot CLI、Copilot app 与 Copilot SDK。它现在已被完全重写为超过 80 万行生产级 Rust，而大部分程式码由 AI 代理撰写，跨越 128 个合并请求，并且是逐步出货而非等到最后一次切换。[1]
规模与成本
官方在文中披露关键数字：截至 8 月 21 日，runtime 已是 100% 生产 Rust——832,378 行生产 Rust、468,689 行 Rust 单元测试，另立的 GitHub Copilot SDK 缓存库另有约 13 万行 E2E 测试程式码，涵盖 Node.js、Python、Go、C#、Rust 与 Java。时间线由 5 月 12 日至 8 月 21 日，涉及 128 个移植 PR 与 135 次公开 CLI 版本发布。[1]
官方估算，移植工作的成本约为 12 万美元的 token 支出，加上约三周开发者时间——因为移植 PR 在阶段时间只佔作者所有 PR 约 20%，官方以此粗略推算实际投入。官方也澄清，整个迁移并非 100% 由单一开发者完成，而是图灵协作：例如 napi-oop（触时跨进程互通层）的设计与实作由 @stevesandersonms 提供。[1]
为何要移植
官方指出，这个 runtime 不只支援 Copilot CLI，也是 VS Code、Visual Studio、Copilot cloud agent、Copilot Code Review、Copilot Cowork、Copilot Studio，以至 Excel、Outlook、PowerPoint、Word 等产品的共同底座；这些产品大多经由自行实作 agent loop，后来改用 Copilot SDK 作为进入 runtime 的入口，以便一致修正、缺缺受惠。[1]
问题在于原本的技术选型：整套压哑以 TypeScript 迁成，Node.js 作框架架、V8 作执行引擎，介面用 Ink 与 React。官方承认这对终端机用是合理选择——TypeScript/Node.js 易用、开发快，对console 用在唤动、回应、吞吐与记录上的代价仍可接受；但当同一实作要用于其他环境、面对快速唤动与因低记忆体佔用而要求高伺服器密度的需求时，就变得不合理。[1]
架构也加深了问题：Copilot CLI 当初为求快速出货，TUI 与 runtime 相互耦合而非分层；后来需要 SDK 程式化存取时，做法是把 SDK 嵌在 CLI 之上，而非按道理以 runtime 为底。CLI 因而加入 headless 模式，以 JSON-RPC 把外部程式的函式呼叫转给 CLI；SDK 被嵌入任意程式时，会 spawn 一个 CLI 程式在进程外托管 agent loop——快、鹹活，但对唤动、记忆体、吞吐与可靠性都不理想。[1]
如何做到
官方指出，移植采取逐步进行的方式，让每个 PR 都能独立出货，令回报的问题更容易与近期改动对应、更容易定位与快速修正；官方形容，把移植拉长且逐步进行反而是优先而非阻碍（「更快不一定更好」）。[1]
技术上，官方透过 napi-rs 专栏的 napi Rust crate 建立 Node 原生 addon：以 #[napi] 标记函式，napi-rs 自动会生成 N-API 绑定胶水码，令函式可从 JavaScript 呼叫，并生成对应的 TypeScript 宣告；同步 Rust 函数变成普通 JavaScript 函数，async fn 变成回传 promise 的 JavaScript 函数，标记 #[napi(object)] 的结构体在另一端变成普通物件。[1]