AIREITER模型可以更換，但 agent 的協調流程不該因此整套重寫；偏偏這類返工，往往正是拖慢專案時程的元兇。Microsoft Copilot harness 進駐 Microsoft Foundry 後，提供了一個由 Microsoft 管理的解法：它沿用 Copilot Code、Copilot Studio、GitHub Copilot app、CLI 和 Visual Studio Code 背後的同一套執行層，目前已開放公眾預覽，且在 2026 年 12 月 1 日前免收執行環境費用（blogs.microsoft.com）。現在可以拿來做實驗，但在下方列出的預覽限制解決前，正式環境仍建議留在目前的技術棧。
Microsoft Copilot harness 到底負責什麼？
Microsoft Copilot harness 是包在模型外層的託管式協調層，負責把模型的推理轉化為真正完成的工作。Microsoft 管理 agent loop、沙盒、治理與最佳化；開發者則提供指令、技能、工具，以及模型選擇。
Microsoft 的說法很直接：「如果模型提供的是智慧，那麼 harness 就是模型周圍的一切」（blogs.microsoft.com）。實際上，harness 會隨任務進展管理工作情境、協調模型呼叫與工具呼叫，在沙盒中執行檔案和程式碼，將受限的子任務交給內建 subagent，並落實你設定的限制與政策邊界（devblogs.microsoft.com）。
| 負責項目 | Microsoft Foundry 管理 | 你需要提供 |
|---|---|---|
| Agent loop 與沙盒執行 | 是 | 否 |
| 治理、核准與最佳化 | 是 | 設定 |
| 指令與技能 | 否 | 是 |
| 工具、MCP 伺服器與知識 | 否 | 是，並設定驗證 |
| 模型選擇 | 支援清單 | 由你選擇部署 |
多模型路由：支援 20 多個前沿模型，也能 BYOK
Microsoft Copilot harness 支援跨模型家族的 20 多個前沿模型，也支援自帶金鑰（BYOK）設定，並會根據任務將工作路由到合適的一個或多個模型（blogs.microsoft.com）。不過，Microsoft 並未在公告中列出完整的 20 多個模型清單，因此若要規劃多模型架構，仍應先確認你的 Foundry 區域實際可用的模型。它主打的價值在於，客戶不必再自行維護 router：「你只需要帶來指令、技能、工具，以及模型選擇。」
早期一位建置者如此概括它的吸引力：每次模型更換時，都不用重寫整個協調層——@ai_fengshou。
Rust 執行環境，以及它已經支援的產品
Microsoft Copilot harness 的執行環境最近已移植至 Rust。Microsoft 表示，這降低了工作階段開銷與首次產生 token 所需的時間（blogs.microsoft.com）。目前沒有公布百分比改善幅度或延遲表格，因此這項說法應視為方向性資訊。
Microsoft 表示，同一套 harness 已支援 Copilot Code、Copilot Studio、GitHub Copilot app、GitHub Copilot CLI、Visual Studio Code，以及其他 Microsoft 和 GitHub Copilot 產品介面（blogs.microsoft.com）。Microsoft 形容這個共用基礎已在數百萬名使用者與數百種真實世界使用情境中接受測試（blogs.microsoft.com）。
這套 harness 也透過 Model Context Protocol（MCP）、agent skills 和 agent plugins 提供開放式擴充能力（blogs.microsoft.com）。
2026 年 10 月 28 日，Foundry 發生了什麼變化？
Microsoft 在 2026 年 10 月 28 日同步推出兩項相關更新：Microsoft Copilot harness 在 Foundry Agent Service 進入公眾預覽；而託管 agent 的長時間執行韌性則正式全面推出（devblogs.microsoft.com）。
產品術語也正在改名：Copilot Studio 文件目前仍有部分頁面稱它為 GitHub Copilot harness，但在整體產品命名上，現在改稱 Microsoft Copilot harness；不同頁面的更新時間並不一致（microsoft.com）。
Foundry Agent Service 現在提供三個抽象層級：不使用 harness 的 prompt agent、預覽中的 Microsoft Copilot harness prompt agent，以及由開發者自行控制框架的 hosted agent（devblogs.microsoft.com）。長時間執行韌性是目前已正式推出的部分：hosted agent 能在持續數小時或數天的工作流程中，從中斷狀態恢復執行。
如何在 Foundry 建立 harness agent
Foundry harness agent 採宣告式定義，並與應用程式程式碼一起儲存（devblogs.microsoft.com）。開發者可以在 Foundry 建立並測試 agent，將定義納入原始碼控制，再透過 Azure Developer CLI（azd）或 Foundry 入口網站部署（devblogs.microsoft.com）。
用可重用技能封裝工作方法
可重用技能會把指令、腳本、支援資源與操作流程打包，讓 agent 能在不同任務中反覆套用。文件中的範例使用 skills/research-brief/SKILL.md 裡的 research-brief skill，要求 agent 先確認問題、受眾、範圍與時間區間，再用核准的工具蒐集證據、標註來源和日期、區分事實與解讀，並指出互相衝突的證據。
連接工具，同時保留治理控制
連接工具讓 agent 能使用 Microsoft Foundry 工具與 MCP 工具，並搭配明確設定的驗證方式與核准流程。這個核准步驟本身就是治理控制；但從下方的 Reddit 回報也能看出，當終端使用者反覆遇到同意對話框時，它同樣可能成為正式環境的摩擦來源。
執行程式、處理檔案與委派子任務
Agent 可以處理檔案、執行程式碼，也能把受限任務交給內建 subagent，再由主 agent 統整結果。Copilot Studio 的 harness 比較文件另外指出，這套源自 GitHub 的 harness 原生支援建立與編輯 Word、Excel、PowerPoint 和 PDF 檔案，也支援 skills 與 memory（learn.microsoft.com）。
定義與程式碼一起控管，只需一行開啟 harness
Agent 定義會放在程式碼旁邊。Foundry 範例在 azure.yaml 中宣告 harness（devblogs.microsoft.com）：
harness:
type: microsoft_copilot_preview這個範例將 research-brief prompt agent 接上 research-brief-skill skill，並搭配網頁搜尋（public-research）和 Code Interpreter（research-analysis），使用 FOUNDRY_PROJECT_ENDPOINT 與 MODEL_DEPLOYMENT_NAME 作為環境輸入（devblogs.microsoft.com）。部署與呼叫則使用預覽版 CLI：
azd deploy --all
azd ai agent invoke research-brief \
"Compare publicly announced approaches to agent interoperability. Produce a concise brief with sources, tradeoffs, and open questions."其他建立方式還包括 Foundry 入口網站、Visual Studio Code 的 Foundry Toolkit，以及 GitHub Copilot app 的 Foundry plugin（devblogs.microsoft.com）。
你的任務適合哪一種 Foundry agent 路徑？
沒有哪個抽象層級適合所有情境；Microsoft 自己的建議是，在能滿足應用需求的前提下，選擇需要自行負責最少基礎設施的方案（devblogs.microsoft.com）。預覽期間，建立 agent 時就會鎖定這項選擇，因此按下建立之前就要先決定。
| 方案 | 適用時機 | 你得到什麼 | 你放棄什麼 |
|---|---|---|---|
| 不使用 harness 的 Prompt agent | 指令加上支援的工具已經足夠 | 最簡單、需要自行負責的部分最少 | 沒有 skills、託管檔案、subagent 或複雜協調能力 |
| 使用 Microsoft Copilot harness 的 Prompt agent（預覽） | 需要 skills、託管式執行、檔案、subagent 或複雜工具協調 | 託管的 loop 與沙盒、可重用 skills，以及更完整的執行能力 | 受預覽限制影響；執行環境由 Microsoft 掌控較多；同時受支援的模型、工具與區域限制 |
| Hosted agent | 必須自行帶入或修改框架、loop、中介軟體或相依項目 | 在 Foundry 託管下取得最大控制權 | 你要自行負責 checkpoint、恢復邏輯與避免重複動作 |
Microsoft 提到的早期客戶訊號包括：Confluence Technologies 將重心放在設計而非基礎設施，因此不到一週就交付了解決方案；Fashable 則把 harness 用於受治理的採購流程，同時讓具有商業約束力的決策保留在人員手中（devblogs.microsoft.com）。
2026 年 12 月 1 日之後要花多少錢？
Microsoft Copilot harness 執行環境會從 2026 年 12 月 1 日開始採用按用量計費。在此日期之前，執行環境使用免費；但模型推論、另行計費的工具，以及連接的服務，在整個期間都會另外收費。
| 沙盒資源 | 2026 年 12 月 1 日起的價格 |
|---|---|
| 沙盒運算 | $0.0994／vCPU-小時 |
| 沙盒記憶體 | $0.0118／GiB-小時 |
價格可能因區域與客戶協議而異（devblogs.microsoft.com）。在預覽期間，Foundry 會管理執行環境的 CPU、記憶體與閒置設定（devblogs.microsoft.com），並將支援的區域、模型、工具和預覽限制交由獨立文件說明。
在 Copilot Studio 中，使用 GitHub 系列 harness 的 agent 會透過 Copilot Credits 按用量計費；這與 Foundry 的沙盒計量是兩套不同的計費機制（learn.microsoft.com）。若要估算試行成本，可以將實際觀察到的沙盒 vCPU-小時與 GiB-小時分別乘以上述費率，再加上模型 token 與工具費用。
開始建置前，先確認這些預覽限制
預覽功能能否撐過正式環境考驗，往往取決於細節。以下限制來自 Microsoft 的 Foundry 文章，除非另有註明為使用者觀察。
- Harness 目前一旦選定就不能回頭。建立 agent 時就要選定 harness；既有 agent 不會改變，建立後目前也不能切換 harness。一位早期讀者正好指出這點：「建立 agent 時就要選 Copilot harness。既有 agent 不會改變，建立後目前還不支援切換 harness」——@navaneethan_es。
- 區域與模型都有邊界。Foundry 將完整清單交由支援區域、模型、工具與預覽限制文件說明。一位使用者整理後表示，大約有九個區域，沒有中東地區支援，也還沒有完整的自帶模型功能——@HeshamSaadZaki。這是使用者對文件的解讀，並非官方區域表，實際情況仍應自行查證。
- 長時間工作如何恢復，要靠你的程式碼。Foundry 會重新啟動中斷的 hosted work，並重新提供原始輸入；但應用程式必須儲存進度、從 checkpoint 繼續執行，還要防止重複動作，例如同一份外部報告被建立兩次。只有對話歷史，無法還原進行中的工作。
- 發布時沒有 benchmark 或 SLA 數字。你可能會看到「業界領先效能」這類定性說法，但目前沒有延遲、吞吐量或準確率表格可供比較。
早期 Copilot harness 使用者在正式環境遇到什麼？
使用 GitHub 系列 harness 的 Copilot Studio 使用者，反覆提到預覽與正式環境之間的差距。這些回報描述的是 Foundry 預覽推出前的 Copilot Studio GitHub harness 體驗；以下內容是根據 Microsoft 所描述的共用產品血統所作的推論（blogs.microsoft.com），並不是 Foundry 的實測結果。
這些該死的 connector 在正式環境甚至撐不到一天。——u/roberts2727，發表於 r/copilotstudio
有時候 flow 會正常運作；但其他時候，agent 完全不會把任何東西傳給它們。——u/donstazz，發表於 r/copilotstudio
業務使用者沒辦法處理這些 app reg 之類的事情，必須由 IT 管理員來做，而且每個 agent 都要分開處理。——u/Teemu_St，發表於 r/copilotstudio
這些討論串提到的問題包括：
- 以 SharePoint 為知識來源的 agent 回答較慢；r/copilotstudio 中有使用者形容速度明顯慢於其他方案。
- Agent 在 Studio 測試窗格中運作正常，但部署到 Teams 或 M365 Copilot 後失敗，只顯示一般性的錯誤訊息；見 r/copilotstudio。
- Connector 與 flow 不穩定，另外還有反覆驗證，以及 MCP 同意流程造成的摩擦；見 r/copilotstudio。
- 使用者不清楚 M365 Copilot 授權是否涵蓋 harness 執行環境，或是否仍需支付 Copilot Credits；見 r/microsoft_365_copilot。
這些回報並不代表 Foundry 預覽沒有價值，但它們確實說明了試行時的檢查清單：用真實的知識來源、真實的使用管道，以及真實的終端使用者同意流程來測試，再承諾交付時程。
常見問題
Microsoft Copilot harness 和 GitHub Copilot harness 是同一套東西嗎？
是，同樣源自 GitHub 打造的技術血統，只是改用了 Microsoft 這個新名稱；部分 Copilot Studio 文件仍在過渡期間沿用舊名稱。
Foundry harness 支援哪些模型？
支援 20 多個前沿模型，也支援 BYOK，並依任務進行路由；Microsoft 沒有公布完整清單，因此請查閱適用於你所在區域的 Foundry 文件（詳見上方的多模型章節）。
可以把現有的 Foundry agent 搬到 harness 嗎？
預覽期間不能直接切換。建議平行進行評估：先盤點 prompt、工具、驗證方式與狀態需求，再在預覽專案中使用 microsoft_copilot_preview 重新建立 agent，最後比較相同任務下的品質、延遲、沙盒用量與恢復能力，再決定是否切換。
M365 Copilot 授權會涵蓋 harness 使用量嗎？
不會自動涵蓋。Foundry 會將沙盒運算與記憶體和模型推論分開計量；Copilot Studio 則透過 Copilot Credits 為這個 harness 系列計費。請確認你所使用產品介面的實際計費項目。
應該使用 harness，還是 hosted agent？
如果你希望使用託管的 loop、沙盒、skills 與 subagent，又不想自行負責協調流程，就選 harness。如果必須控制框架或執行環境，並且能自行處理 checkpoint 與冪等性，則選 hosted agent。
可以先在預覽中採用 research-brief skill 模式，將同一任務下的沙盒與 token 成本，和不使用 harness 的 prompt agent 比較；在你的租戶確認遷移方式、支援區域與同意流程行為都有文件說明前，正式環境仍建議沿用已驗證的方案。