Microsoft 在 2026 年 8 月 4 日宣布，GitHub Copilot Agent 已經在 Microsoft Agent Framework 的 .NET 和 Python provider 進入 stable。重點不是再推出一個聊天模型，而是把一個已經能夠讀寫程式碼、執行 shell 和使用 MCP 的 coding harness，接到一個較通用的 agent 開發框架。
這個整合把兩層能力分開。GitHub Copilot CLI 和 SDK 負責 agent loop，包括模型呼叫、工具執行、規劃和 session state；Agent Framework 則提供統一的 instructions、tools、streaming、middleware、observability，以及 human-in-the-loop approval 介面。開發者因此可以保留 Copilot 的 repository-aware 能力，同時用熟悉的 Agent Framework 方式把它放進更大的系統。
實際可用的能力包括 shell execution、檔案讀寫、URL fetching 和 MCP server。Microsoft 強調，這些系統能力不是預設無限制開放，而是要經過 permission handler。每次敏感操作都可以由應用程式決定 approve、deny 或要求人工確認；需要審批的 function tool 亦可以沿用同一套控制。
Observability 是另一個重要層次。Copilot Agent 可以參與 Agent Framework 的 OpenTelemetry tracing，令模型呼叫、工具使用和代理流程更容易接入現有監控系統。對 production agent 來說，知道代理完成了甚麼不夠，還要能夠追蹤它在甚麼時間、用甚麼工具、因何作出某個動作，以及在哪一步被人拒絕。
不過，stable 不代表零設定部署。官方說明要求使用者有已驗證的 GitHub Copilot runtime 和有效訂閱，實際執行亦要處理 CLI 路徑、工作目錄、模型和 timeout 等配置。若代理獲得 shell 或檔案權限，Microsoft 的文件亦建議在 container 或 Dev Container 內運行，以縮小程式碼和系統資料的暴露範圍。
這次更新的訊號，是 coding agent 的競爭正由單一產品功能轉向可組合的 runtime。企業未必想把所有自動化都綁在一個聊天介面；它們可能需要把 repository agent、內部工具、審批服務、遙測和既有流程接在一起。把 Copilot harness 變成 Agent Framework 的一個 provider，正好提供了這種接駁點，但權限邊界、審批策略和執行隔離仍要由部署團隊自行設計。
