同一個智能體任務，今天適合使用擅長編碼的模型，明天可能就需要換成更便宜或需要更多上下文信息的模型。真正麻煩的往往不是模型名稱的變更，而是模型周邊的整套執行系統：指令如何加载、上下文如何組織、工具如何調用、代碼在何處運行、失敗時如何恢復、權限如何管理。微軟在10月28日宣佈，將GitHub團隊打造並已在公司內部統一採用的Copilot harness，通過Microsoft Foundry提供給開發者和企業。

微軟將 harness 解釋為模型之外的編排層。模型提供推理能力，harness 負責將指令、上下文、執行環境和控制措施組合成一次可完成的任务。它支持 MCP、agent、skills 和插件，也負責智能體循環與沙箱。這個定義比「另一個模型路由器」更寬泛：路由只是選誰來做，harness 還要決定任務如何做、在什麼邊界內做，以及運行結果如何交回應用。

這套系統已經被應用於 Copilot Code、Copilot Studio、GitHub Copilot 應用、命令行以及 VS Code 等產品中。現在的變化是，微軟將內部共用的執行基礎轉變為 Foundry 中的托管能力。開發者可以下載 SDK，也可以在雲端運行，不必再為每個模型分別維護一套循環、工具接入和沙箱環境。

多模型並非只是將下拉框做得更长而已。

官方稱，這套 harness 支持20多種先進模型，也允許客戶自帶密鑰。看起來像是「模型選擇更多」，但企業真正獲得的是在切換時儘量保持上層流程不變。任務仍可沿用原有的指令、技能和工具，底層模型則根據質量、成本或工作類型進行調整。

這並不意味着不同的模型已經變得完全可互換。模型的輸出格式、工具使用習慣、延遲和失敗方式仍可能不同。微軟承擔的是持續評測、路由與執行層的優化，應用團隊仍需為自己的業務結果設定驗收條件。托管 harness 可以減少維護工作，但不能替代業務側對正確性和權限的判斷。

微軟還透露，運行時（runtime）最近已經移植到 Rust，目的是降低會話開銷（session overhead）和首個代幣等待時間（first token wait time）。這個變化發生在執行層（execution layer），而非模型本身（model itself）。對於長時間運行、頻繁調用工具的任務（tasks that run for long periods and frequently invoke tools），外圍開銷（peripheral overhead）會被重複放大；讓運行時變得更輕量（make the runtime lighter）可能比單次模型生成快幾十毫秒更能影響整體體驗（may have a greater impact on the overall experience than just making single model generation faster by a few tens of milliseconds）。不過，公告中沒有給出統一的延遲降低幅度，也不能由此推斷所有任務都會變得更快。

企業買到的是託管責任，而非結果保證

在 Foundry 中，微軟負責運行智能體循環和沙箱，並將治理與優化放在基礎層；客戶提供指令、技能、工具和模型選擇。這種分工非常重要。它將「誰來維護執行引擎」的責任交給了平台，但卻沒有將「工具能夠存取哪些數據」「一次寫入是否需要批准」「輸出是否符合業務事實」等問題也一併交給平台處理。

統一底座也帶來了新的集中風險。多個產品共享同一個 harness，改進可以同時擴散，缺陷也可能跨平臺影響更多任務。因此企業需要保存模型、harness 版本、工具權限和關鍵動作回執，不能只記錄最終使用了哪個模型。公告中所說的持續改進，是平台承諾的方向，不等於客戶無需進行回歸測試。

對於開發團隊而言，最實際的變化在於智能體架構開始從「圍繞某個模型搭建一套應用」轉向「先建立穩定的執行層，再接入不同的模型」。模型仍然決定著能力的上限，而harness則決定這些能力是否能在真實系統中被約束、觀察和重複使用。微軟所開放的並不是一個新的「大腦」，而是一套讓多個「大腦」能在同一工作臺上協作的「外骨骼」。

對於已經接入多個模型的團隊而言，這也改變了成本核算的單位：不再只是比較每百萬代幣的價格，還需要計算評測、路由、沙箱、會話恢復和工具維護的總成本。harness 可以將其中的一部分轉變為平台服務，但選擇權越多，記錄每次實際選擇與結果的要求反而越高。