Microsoft 以 AI 智能體將 Copilot runtime 移植至 Rust，模型 token 使用費約 $120K

支撐 GitHub Copilot 及愈來愈多 Microsoft 產品的軟件引擎，現已完全以 Rust 編寫，大部分移植工作由 AI 代理負責。

這次移植的 AI token 費用約為 $120,000，另耗費開發人員約三週時間。然而， 管理人員亦要處理最終程式碼中數十個回歸問題，反映 AI 在理解 Rust 方面仍面對挑戰。 

DEVCLASS 廣告

這項工作逐個模組更新執行階段，直至完成；歷時 14.5 週，期間發布超過 135 個版本。每天平均發出約 1.3 個移植拉取要求。

整體而言，代理將 430,000 行 TypeScript 轉換成 800,000 行用於正式環境的 Rust 程式碼。為了盡量簡化移植工作，團隊只按個別情況替換 TypeScript 模組，並無嘗試改善執行階段本身的結構。這將是下一步工作。 

以精簡高效見稱的 Rust，表現果然不負所望。

DEVCLASS 廣告

其中一項基準測試，使用共用用戶端和 100 條並行管道，測量執行階段完成 1,000 個單回合工作階段生命週期的速度。原有的 TypeScript 實作每秒完成 7.55 個生命週期；在同一程序內運行的 Rust 則每秒完成 120 個，在這項特定工作負載下，速度提升了 15.9 倍。

在記憶體用量方面，一批由 10 個用戶端組成的代理在使用 TypeScript 時耗用 1,383 MB；改寫成 Rust 後，為相同的代理羣提供服務只耗用 126 MB。在 Rust 中，工作一直在同一程序內完成，不像 TypeScript 那樣需要啟動外部背景程序來完成工作。

從 VS Code 到 Microsoft Office 的 Copilot

乍看之下，大多數用戶或許不知道 Copilot 執行階段的應用範圍有多廣。它支援GitHub Copilot 命令列介面（CLI）、Copilot 應用程式、SDK 及GitHub Copilot 雲端代理。它亦應用於 VS Code、Visual Studio、Excel、Outlook、PowerPoint，以及無數其他 Microsoft 雲端服務。

最初，執行階段以 TypeScript 編寫，並採用 Node.js 作為框架，以 V8 作為執行引擎。TypeScript 和 Node.js 非常適合快速開發，但在大規模應用時，難以提供快速啟動速度和高伺服器密度。 

Microsoft 傑出工程師 Stephen Toub 在一篇解釋整個過程的貼文中寫道：「這絕不是在宣稱每個大型 TypeScript 程式都應改用 Rust。我們的要求着重透過 C ABI 嵌入、低啟動及穩態開銷，以及可預測的資源使用量。Rust 讓這些目標得以實現。」

這個項目使用 Copilot 改寫 Copilot，而 Copilot 再運用多個 LLM 執行不同部分的工作，並按各個 LLM 的天生強項分配任務；文中點名了 GPT-5.6 Sol 和 Claude Opus 4.8。  博覽羣書但健談的代理

DEVCLASS 廣告

Toub 認為，代理的應用整體上相當成功。事實上，若由人手完成，這個項目需要數年時間，成本亦會達數百萬。 

Toub 指出，代理展現了幾種令人意外的湧現行為。其中之一是，代理花在蒐集資訊上的時間遠多於實際編寫程式碼的時間。  

「大眾對 AI 不斷噴出程式碼的印象幾乎完全相反；在這個規模下，工作看起來更像反覆調查：檢視目前狀態、形成假設、作出有針對性的修改，然後重複以上步驟。」他寫道。 

另一個令人意外之處是，工作階段之間經常互相互動，無論是與它們建立的其他工作階段，還是與其他完全不同的工作階段互動。 

其中最棘手的移植工作之一，是 session.ts 檔案。這個 TypeScript 檔案超過 30,000 行，涉及執行環境的各個方面。移植工作階段最終花了 25 小時完成；開始時先花 56 分鐘閲讀文件，並作出 122 次工具呼叫以釐清問題。接着，它建立了 15 個子工作階段，各自建立自己的 worktree 和 Agent。然後，它們開始互相溝通。

運用內置的編排技能，一個工作階段找出所有其他活躍工作階段，並向任務重疊的工作階段傳送訊息，要求協調。編譯器是老師，而非神諭 

考慮到效能優勢，Rust 已證明是重寫應用程式的熱門語言。例如，Bun 創作者 Jarred Sumner 最近幾乎完全依靠 Claude Agents，把 Anthropic 擁有的 JavaScript 執行環境及工具組移植至 Rust；該工具組包含約 535,000 行 Zig 程式碼，截至 7 月 30 日，實驗性的 Rust 移植版本在 Linux x64 glibc 上通過了 Bun 現有測試的 99.8 percent，而穩定版本仍以 Zig 程式碼庫發佈。

這項工作耗用了價值 $165,000 的 tokens。 

但正如 Toub 所發現，使用 Rust 也存在隱藏的危險。 

對 LLM 和懶惰的程式設計師而言，只要程式碼能成功編譯，它就是有效的 Rust 程式碼。

但在整個過程中，項目在程式碼中遇到了數十項回歸問題。回歸問題是指原本正常運作的功能，在更新後不再正常運作。 

例如，編譯器根本不知道函式的次序是否正確、工作能否以可接受的成本完成、是否符合開發人員未明言的要求，甚至整體上是否邏輯一致。

在上星期於 Montréal 舉行的 RustConf 上，顧問 Lisa Crossman 警告，不應把編譯器視為「神諭」，亦即判定某段 Rust 程式碼是否有效的最終依據。她説：「Rust 會阻止 Agent 編寫記憶體不安全的程式碼，但不會阻止 Agent 正確地編寫錯誤的程式。」 

明智的人類開發人員會把編譯器視為老師，透過解讀錯誤訊息，逐步加深對該語言領域的理解。另一方面，LLM 只會把編譯器當作黑箱，用粗糙、低效的權宜做法反覆折騰，直到某種做法過關為止（或許這就是 Zig 創作者 Andrew Kelley 稱 Bun 的 Rust 程式碼為「未經審查的垃圾程式碼」的意思）。 

以 Toub 的情況為例，他發現經編譯器認可的回歸問題，可能源於語義和行為含糊不清、分支漂移、未移植過來的功能，以及替代程式碼的行為差異。 

Toub 寫道：「這絕不是反對 Rust 編譯器的理由。但『只要能編譯，就代表正確』這句話只適合當笑話。」