微軟開源的 Microsoft Agent Framework 在 GitHub 累積 14,326 顆星標，採 MIT 授權。它整合語意核心與 AutoGen，提供代理建立、多代理編排與托管部署，支援 Python、.NET 與 Go。專案始於二零二五年四月，十月下旬更新 Python 1.23.0 與 .NET 1.26.0。
Microsoft Agent Framework 是什麼？
Microsoft Agent Framework 是微軟開源的代理框架，支援 Python、.NET 與 Go。它整合語意核心與 AutoGen，提供編排與檢查點能力。
官方定位寫得明確：這是給準備把代理推進到生產環境的團隊使用，而非停留在單次提示詞的實驗。框架把代理視為有狀態的執行單元，工作流則是代理之間的合作契約。
這種定位反映微軟在代理領域兩年多的反覆嘗試。早期的語意核心解決企業系統整合，AutoGen 解決多代理對話，兩者各有活躍社群，卻也讓採用者面對選擇困難。
為何微軟要在 AutoGen 與 Semantic Kernel 之外再推一個框架？
AutoGen 偏重研究與多代理對話，語意核心偏重企業系統整合。新框架把兩者的編排模型收斂成單一基礎，官方同時提供兩份遷移指南，讓既有專案可以逐步轉移。
兩個舊專案並未停止維護。語意核心仍有 28,697 顆星標，AutoGen 則有 61,574 顆星標，兩者在查詢當日仍有提交紀錄。微軟的做法是新增第三個倉庫，再把遷移路徑寫成文件，而非直接宣告舊專案退役。
對既有使用者而言，這種安排降低被迫中斷的壓力。對新採用者而言，選擇題反而變成三個：留在舊專案、遷移到新框架，或者採用其他廠商的方案。
真正的訊號在遷移指南的份量。官方為語意核心與 AutoGen 各寫一份遷移文件，逐項對照概念與 API，這種規格通常只在長期收斂計畫中出現。
它的編排能力與工作流設計有什麼特點？
框架以圖形化工作流描述代理協作，內建循序、並行、交接與群組四種模式。檢查點、串流、人為介入與時間回溯都在同一層處理，代理與工作流可以互相嵌套。
四種模式覆蓋常見的合作型態。循序處理有先後依賴的步驟，並行處理可分割的子任務，交接處理同一個對話在不同專責代理之間轉手，群組則處理需要多方討論後收斂的場景。
檢查點與時間回溯是當中最實用的部分。代理執行到一半失敗時，系統可以從最近的檢查點重跑，而不必重放整條流程。這對長時間執行的任務尤其關鍵，因為重跑成本往往高於首次執行。
工作流本身也可以視為代理被呼叫，這種遞迴結構讓複雜系統得以分層拆解。開發者不必把所有邏輯塞進單一代理的指令裡。
Python、.NET 與 Go 三語言支援有何實際差異？
Python 與 .NET 提供一致的 API 形狀，Go 由獨立倉庫維護。三者套件分開發布，版本節奏不完全同步，跨語言團隊需要各自鎖定版本並分開測試。
語言統計顯示重心所在。倉庫內 Python 程式碼約 2,587 萬位元組，C# 約 1,698 萬位元組，TypeScript 約 83 萬位元組，Go 的實作則放在另一個倉庫，該倉庫目前 654 顆星標。
Python 套件以 pip install agent-framework 安裝，.NET 套件則透過 NuGet 加入 Microsoft.Agents.AI 與對應的整合套件。Go 版本的貢獻指南、範例與問題追蹤都在獨立倉庫處理，成熟度與前兩者仍有差距。
版本號也不同步。Python 側最新為 1.23.0，.NET 側為 1.26.0，兩者發布日期相差一日。跨語言團隊若共用同一份設計文件，需要明確標注各語言目前的對應版本。
從原型到生產需要哪些部署與可觀測性能力？
框架內建 OpenTelemetry 追蹤，可把代理部署到托管環境，官方稱只需兩行程式碼。DevUI 提供本機測試介面，宣告式代理可用 YAML 定義。
可觀測性以 OpenTelemetry 為基礎，分散式追蹤涵蓋代理呼叫、工具執行與工作流節點。對已經使用相容後端的團隊而言，接入成本主要落在設定而非改寫程式。
托管路徑分兩條。一條是自架，透過 A2A 與自帶的協定輔助層對外提供服務；另一條是部署到微軟的托管環境，官方在說明文件把它標為新功能。
DevUI 值得單獨一提。它提供互動介面，讓開發者在本機檢視代理的推理片段、工具呼叫與回應內容，減少靠日誌猜測的時間。
專案數據與社群活躍度呈現什麼訊號？
專案累積 14,326 顆星標、2,517 個分支與 312 位貢獻者。近三個月每週提交量維持在百次以上，198 個版本標籤與 72 個分支反映以高頻小步方式推進。
星標對分支比約為 5.7 比 1，低於工具型專案常見的十倍區間。這個比例通常出現在企業主導的框架類專案，因為採用者傾向直接使用而非自行複製。
貢獻者 312 位對 14,326 顆星標，密度屬於中等偏高。相對於多數微軟開源專案以核心團隊為主，此專案的外部貢獻比例明顯較高，也側面反映框架的整合面很廣。
提交節奏則相當密集。貢獻者頁顯示近三個月的每週提交量多數維持在百次以上，並在十月中出現明顯高峰，對應多個破壞性變更的合併。
導入前要注意哪些風險與遷移成本？
1.23.0 版把模型上下文協定升級到 2.x 相容基礎，屬於破壞性變更。AG-UI 端點註冊改為必須宣告授權範圍，Docker 執行參數亦已改名，既有整合需要重測。
破壞性變更集中在協定層。版本紀錄把多個套件的模型上下文協定傳輸、錯誤處理與生命週期管理一併改寫，並明確標注為破壞性變更。依賴舊行為的整合在升級後可能直接失敗。
授權範圍的調整同樣需要留意。AG-UI 端點註冊原本可以隱含單一使用者假設，新版要求明確宣告授權範圍或單使用者模式，這種改動會影響既有部署的啟動流程。
安全相關的命名也變得更直白。Docker 工具的執行參數由 extra_run_args 改為 unsafe_extra_run_args，把信任要求寫進名稱。這種改動雖小，卻會令舊設定在升級後失效。
授權條款為 MIT，商用限制相對寬鬆。官方在說明文件另外列出第三方系統的責任聲明，提醒採用者自行處理資料跨境與合規問題。
出處連結有哪些？
本文資訊整理自微軟官方倉庫的說明文件、版本紀錄與貢獻者統計，原始碼、範例與問題追蹤都在 GitHub 公開，讀者可自行核對細節與最新版本。
專案原始碼與文件位於 https://github.com/microsoft/agent-framework，Go 版本則在 https://github.com/microsoft/agent-framework-go。官方另設微軟學習平台的教學頁面，內容與倉庫文件互補。
總結：哪些團隊適合採用 Microsoft Agent Framework？
已在使用 Azure 或 .NET 生態、且需要把代理推進到生產環境的團隊最適合。若需求只是單次提示詞或簡單自動化，輕量框架或現成工具的維護成本更低。
框架的價值在於把代理從示範推進到可維運的系統。檢查點、追蹤與托管部署這三項能力，正好對應多數團隊在試點之後卡住的環節。
代價是抽象層的重量。四種編排模式、三種語言與多層套件結構，對小規模專案而言都是額外負擔。評估時值得先問一個問題：目前的需求是否真的需要長時間執行與多代理協作。
微軟把兩個舊框架的經驗收束成一個新倉庫，這件事本身的訊號強於星標數字。對正在選型的團隊來說，接下來幾季的版本節奏與破壞性變更頻率，會比當前的功能清單更具參考價值。
