GitHub 於 2026 年 9 月 16 日發表技術文章，交代把 Copilot 代理執行時（agent runtime）由 TypeScript 重寫為 Rust 的完整過程：執行時已於 8 月 21 日達到百分之百生產用 Rust，共 832,378 行生產程式碼，另加 468,689 行 Rust 單元測試與 174,675 行端對端 TypeScript 測試，而大部分程式碼由 AI 代理撰寫。[1]
為何要重寫
Copilot 代理執行時不只用於 Copilot CLI，亦是 GitHub Copilot app、GitHub Copilot SDK，以及 VS Code、Visual Studio、Copilot Code Review 等產品的共同底層。執行時最初以 TypeScript 撰寫，運行於 Node.js 與 V8 之上，介面則使用 Ink 與 React。[1]
文章指出，原本架構的問題在於 CLI 與執行時未有清晰分層，以致後來需要 SDK 時，SDK 反而層疊在 CLI 之上：SDK 建立客戶端時會啟動一個 CLI 子程序，透過 JSON-RPC 通訊。這令每個 SDK 使用者的 C#、Python、Go、Java 與 Rust 程式都要額外背負第二個語言執行時（最少約 100MB 工作集），每次事件、訊息及檔案讀寫都要跨程序邊界，Node 程序崩潰亦會帶走整個 session。[1]
GitHub 因此希望得到一個不包含終端介面、可獨立分層的執行時，並以依賴與額外開銷最少的語言實作。文章強調這並非主張所有大型 TypeScript 程式都應改寫為 Rust，而是該專案的需求（以 C ABI 嵌入、低啟動與穩定狀態開銷、可預測資源使用）適合 Rust。[1]
移植節奏
移植以增量方式進行，避免一次過切換：跨越約 14.5 週的移植期內，主分支合共發布 135 個版本（100 個預覽版與 35 個穩定版），平均每日約 1.3 個版本與 1.3 個移植 pull request。作者指出，增量方式令每個版本只包含少量可預期的元件，問題較易與近期改動對應、亦較易追查根源。[1]
提示快取與成本
文章披露移植期間的提示快取命中率為 96.22%，快取寫入佔 3.07%、全新輸入佔 0.71%。作者解釋，供應商通常對快取讀取提供約九成折扣，因此維持良好快取可令帳單相差一個數量級；GitHub Copilot 特意設計代理循環以保留長而穩定的前綴（系統提示、工具定義、累積對話），令昂貴的上下文只付一次、往後以低一個數量級的成本重讀。文章指出，這正是長時間自主 session 在經濟上可行的原因。[1]
回歸問題與審查把關
文章明言移植容易、正確才難。截至 2026 年 9 月 14 日，團隊已追蹤到數十個已知移植回歸並全部修好，多數屬正確性問題，小部分屬效能回歸。作者把回歸歸納為幾類：新程式碼實作了不同的行為契約、狀態與生命周期行為改變、部分移植遺漏或未完整套用，以及測試本身驗證了錯誤行為。[1]
具體例子包括：TypeScript 只有一種 number 型別，而 Rust 需要選擇型別，代理誤把概念上屬整數的欄位宣告為 f64，序列化出 42.0 而非 42，令 Go 與 C# 等強型別 SDK 無法把 repo ID 反序列化為 int64；亦有代理把串流路徑的時間數值宣告為 i64，卻實際輸出小數，導致 session 無法讀取及續跑。另一個例子是 JavaScript 的 event.error || "Unknown error" 被改寫為 Rust 的 .unwrap_or("Unknown error")：前者會以空字串取代，後者保留空字串，行為並不相同。[1]
文章亦提到代理曾試圖以 schema-break-ok 標籤繞過 schema 兼容性檢查，作者在合併前質問後，代理在 21 秒內撤回豁免並以原生 Rust 補回缺失函式。[1]
結果與取用
重寫後執行時在多項效能指標改善，作者形容效能提升達數個數量級、由單一開發者於數月內主要完成，團隊其餘成員則繼續擴充執行時的能力。Copilot CLI、Copilot app 與 Copilot SDK 均建基於此執行時。[1][2]
至於重寫的實際金錢成本，官方文章未有列出；媒體報道（The Register）指 AI token 用量約為 12 萬美元，另加約三週人力。[1]
參考資料
[1] GitHub Blog — Migrating the GitHub Copilot runtime to Rust, using Copilot