GitHub 以 Rust 重寫 Copilot：AI 代理遷移經驗

%s## 摘要：GitHub 用 Rust 重寫 Copilot 執行環境

GitHub 表示，它把支援 GitHub Copilot 的代理程式執行環境，從 TypeScript 與 Node.js 重寫成超過 80 萬行的正式 Rust 程式碼，而且大部分程式碼由 AI 代理完成。專案透過 128 個 pull request 在數月內逐步合併，同時仍持續交付 Copilot 功能。真正值得借鑑的不是所有 JavaScript 系統都應改用 Rust，而是 AI 協助的大型遷移需要清楚的邊界、強大的自動檢查、可回復的小步驟，以及由人類負責的架構與審查。

Copilot 執行環境改變了什麼

這個執行環境支援 Copilot CLI、Copilot 應用程式、SDK 整合、雲端代理、程式碼審查及其他產品。原本的設計把 TypeScript CLI 放在獨立程序中。SDK 用戶端必須啟動 Node.js 和 V8，透過 JSON-RPC 通訊，並承擔另一個執行環境的記憶體與啟動成本。這種架構容易快速推出，但嵌入許多宿主應用程式時代價很高。

GitHub 選擇 Rust，是因為它需要較低的啟動成本、可預測的記憶體使用、原生嵌入、良好的並行能力，以及可供 C#、TypeScript、Python、Go、Java 和 Rust SDK 使用的外部函式介面。新設計把代理執行環境與終端介面分離，產品可以選擇程序內或程序外的託管方式。

根據 GitHub 公布的測量，建立用戶端與工作階段、完成一次回合再拆除的流程，在程序內從 5.25 秒降至 55.3 毫秒；吞吐量由每秒 7.55 個工作階段升至 120 個；十個用戶端的記憶體則由 1,383 MB 降至 126 MB。這些是 GitHub 自己工作負載的數字，不是每次 Rust 重寫都能得到的保證。

AI 代理為何讓遷移變得可行

Copilot 負責重複性的實作，開發者則提供方向、審查修改、執行建置、分析回歸並作出設計決策。工作被拆成多個工作階段與子代理，建置資源成為閘門，避免並行工作超出驗證能力。

這個分工十分重要。代理可以快速翻譯程式碼模式，卻不會自動知道哪個行為是合約、哪個競態條件危險，或哪個相容性承諾對客戶最重要。人的角色轉向更高層：定義不變量、安排順序、檢查介面，以及拒絕看似合理但不完整的程式碼。

遷移也採用漸進式架構。臨時互通層在個別元件移植期間連接 Rust 與 TypeScript；pull request 保持可審查，版本持續發佈，回歸也能歸因於較小的修改。這比「AI 重寫 80 萬行」更有價值，因為它提供可重複的作業方式。

AI 輔助重寫的實用清單

1. 先畫出邊界。 在讓代理修改前，先辨識介面、執行環境、儲存、網路和 FFI 層。
2. 撰寫行為測試。 保存外部可見行為，而不只是型別簽名。
3. 分片移植。 每個階段都保留可工作的建置和回滾路徑。
4. 限制代理任務。 一次只處理一個模組、介面卡或測試家族。
5. 把驗證設為閘門。 編譯、執行單元與整合測試、檢查資源，再審查差異。
6. 追蹤臨時介面。 每個橋接層都要有負責人和移除條件。
7. 測量真實工作負載。 啟動、吞吐量、記憶體、崩潰行為和延遲比語言潮流重要。

想找整理編碼、測試和自動化流程的工具，也可以瀏覽 BTTC 軟體目錄。工具不能代替審查，但能加快回饋循環。

FAQ

GitHub 的 Rust 程式碼都是 AI 寫的嗎？

GitHub 表示大部分由 AI 代理完成，但開發者負責指揮、審查 pull request、執行驗證和修復回歸。AI 寫程式碼不代表 AI 擁有設計權。

為什麼選 Rust？

目標包括低開銷、可預測效能、原生嵌入、並行能力，以及多種 SDK 語言的互通性。這些要求讓 Rust 適合這個執行環境。

每個 TypeScript 專案都該改寫成 Rust 嗎？

不該。只有當資源、啟動、嵌入或可靠性收益足以抵消遷移成本時，重寫才合理。

最可移植的經驗是什麼？

讓代理處於小修改、自動測試、人類審查和接近生產環境的基準測試所組成的受控循環中。

結語

GitHub 的重寫示範了高能力編碼代理如何縮短大型遷移時間，同時不移除工程責任。可複製的模式是漸進式工作：先建立合約，再交給代理窄化任務，讓驗證貼近每次修改，並用真實工作負載測量成果。