AI 科技資訊人工智慧的新知入口
首頁 / Microsoft Agent Framework（MAF）是什麼？把 AI Agent 從原型帶進正式環境的開源框架
生成式 AIAI 工具

Microsoft Agent Framework（MAF）是什麼？把 AI Agent 從原型帶進正式環境的開源框架

做出一個會回答問題的 AI 助手不算太難。真正困難的是讓它可靠地使用工具、記住工作進度、和其他 AI Agent 分工，並在出錯或中斷後繼續執行。

Microsoft Agent Framework，簡稱 MAF，就是微軟為這段「從展示原型走向正式系統」的距離所打造的開源框架。它支援 Python 與 .NET，可用來建立單一 AI Agent，也能安排多個 Agent 共同完成多步驟任務。

MAF 並不是新的大型語言模型，也不是打開網頁就能使用的聊天機器人。它比較像一套開發工具與執行架構，負責把模型、工具、記憶、流程、安全控管與監測能力組合起來。

如果大型語言模型是負責思考的腦，MAF 就像工作現場的管理系統：分派任務、規定流程、保留紀錄，並在關鍵步驟請人確認。

一句話重點

Microsoft Agent Framework 是一套採 MIT 授權的開源 AI Agent 框架，整合 AutoGen 的多代理協作經驗與 Semantic Kernel 的企業應用基礎，讓開發者能以 Python 或 .NET 建立可觀察、可中斷續跑、可人工介入的代理工作流程。

它解決什麼問題？

一般聊天機器人的工作方式很單純：收到問題、呼叫模型、回傳答案。但當 AI 必須查詢資料庫、呼叫外部 API、修改檔案，或連續執行數十分鐘以上，系統就需要處理更多問題。

  • 任務怎麼拆分：哪些步驟交給模型判斷，哪些步驟必須遵循固定規則？
  • 失敗怎麼恢復：流程中斷後，能不能從上次進度繼續，而不是全部重來？
  • 多個 Agent 怎麼合作：研究、撰稿、審核等角色要依序、同時，還是互相交接？
  • 人類何時介入：寄信、付款或修改正式資料前，如何等待人員核准？
  • 系統怎麼除錯：開發者能否看見模型呼叫、工具使用與流程判斷？

MAF 把這些常見需求整理成一致的程式介面與工作流程元件。團隊不必為每個專案重新打造一套代理執行引擎。

核心特色

1. 同時支援 Agent 與可控的工作流程

Agent 擅長處理需要判斷與彈性的工作，但結果可能不完全一致。傳統工作流程則按照預先設定的順序執行，較容易預測。

MAF 允許兩者混合。開發者可以讓 Agent 判讀一封客訴信，再由固定流程查詢訂單、檢查退款條件，最後交由人員核准。需要創意的地方保留彈性，需要合規的地方維持明確規則。

2. 內建多代理協作模式

當任務太複雜時，可以安排多個專門 Agent 分工。MAF 提供循序執行、同時執行、交接、群組對話等協調模式。

例如製作市場報告時，一個 Agent 蒐集資料，一個分析數字，另一個檢查引用。開發者負責設定角色、可使用的工具與流程邊界，而不是放任多個模型無限制地互相聊天。

3. 不綁定單一模型供應商

官方列出的第一方連接器涵蓋 Microsoft Foundry、Azure OpenAI、OpenAI、Anthropic Claude、Amazon Bedrock、Google Gemini 與本機 Ollama 等選項。

這不代表不同模型可以完全無痛替換。工具呼叫、輸入長度、價格與安全機制仍會不同，但統一的抽象層能降低日後更換模型或混合使用多個模型的改寫成本。

4. 為長時間任務保留狀態

MAF 的工作流程支援檢查點、暫停與恢復。簡單來說，系統會保存目前執行到哪裡。即使服務重新啟動，或流程正在等待人工核准，也不必從第一步重新開始。

這對客服升級、文件審核、研究分析等需要跨越較長時間的任務特別重要。

5. 把觀測與控管放進架構

MAF 整合 OpenTelemetry，可記錄代理執行、模型呼叫與工具使用情形。中介層（middleware）則能在不改寫核心提示詞的情況下加入日誌、內容檢查、例外處理與合規政策。

它也支援人類介入流程。當 Agent 準備執行高風險動作時，可以先暫停並等待核准，而不是只靠一句「請小心」的提示詞約束模型。

6. 支援 MCP 與 A2A 等開放協定

MCP（Model Context Protocol，模型情境協定）讓 Agent 能探索並使用外部工具；A2A（Agent-to-Agent）則讓不同系統或框架中的 Agent 以標準方式溝通。

這些整合降低工具與 Agent 被單一平台綁住的風險。不過，接上協定不等於自動安全。權限、傳輸資料與第三方服務的保存政策，仍需要由開發團隊逐一檢查。

MAF 和 AutoGen、Semantic Kernel 有什麼不同？

MAF 的重要背景，是微軟將 AutoGen 與 Semantic Kernel 累積的能力整合到同一條產品路線。它不是單純替其中一個專案改名。

工具 原本較強的方向 現在適合怎麼看
AutoGen 多個 Agent 對話、分工與實驗性協調模式 既有專案仍可使用；新專案可優先評估 MAF，官方也提供移轉指南
Semantic Kernel 企業連接器、模型抽象、記憶與應用整合 不只用於 Agent；若要建立完整代理系統，可評估移轉至 MAF
Microsoft Agent Framework 統一單一 Agent、多代理工作流程、狀態保存、觀測與佈署 微軟目前主推的程式碼優先 Agent 框架
Copilot Studio 視覺化、低程式碼建立企業 Copilot 與自動化 適合希望少寫程式、快速連接 Microsoft 服務的團隊

簡單說，MAF 主要服務需要高度客製化、願意用程式碼掌握流程的開發團隊。它和偏低程式碼的 Copilot Studio 並不是完全相同的產品類型。

非工程背景的人需要知道什麼？

MAF 值得注意的地方，不是讓 AI 突然變得更聰明，而是讓企業更容易管理 AI 怎麼工作。

許多 Agent 展示看起來很流暢，但正式上線後會遇到權限、成本、錯誤恢復、稽核與責任歸屬。MAF 提供的是工程層面的積木，幫助團隊把這些控制點放進系統。

不過，框架無法替企業決定哪些資料可以交給模型，也不會自動保證答案正確。微軟在專案說明中也提醒，開發者必須自行評估第三方系統、資料流向、內容過濾、安全與可靠性。

適合誰使用？

  • 使用 Python 或 .NET 的 AI 開發團隊：希望以同一套概念建立單一或多個 Agent。
  • 準備把 Agent 原型正式上線的企業：需要狀態保存、監測、人工核准與治理能力。
  • 既有 AutoGen 或 Semantic Kernel 專案團隊：想跟進微軟整合後的主要框架路線。
  • 需要混用不同模型的系統：希望降低模型供應商被寫死在應用架構中的程度。

可能不適合誰？

  • 只想快速做一個簡單問答機器人：直接使用模型 API，可能比導入完整框架更省事。
  • 完全不寫程式的使用者：Copilot Studio 等視覺化工具會更容易入門。
  • 只需要固定規則自動化的流程：若每一步都能由傳統程式清楚定義，不一定需要加入大型語言模型與 Agent。
  • 缺乏資安與維運能力的小型團隊：Agent 能呼叫工具並採取行動，也代表必須投入權限隔離、測試、成本限制與監測。

目前可以怎麼開始？

MAF 採 MIT 授權，原始碼公開於 GitHub。Python 與 .NET 的核心套件可用以下指令安裝：

# Python
pip install agent-framework

# .NET
dotnet add package Microsoft.Agents.AI

安裝框架後，仍需設定所選模型服務的端點、憑證或 API 金鑰。若要使用 Microsoft Foundry，也要準備對應的 Azure 專案與身分驗證。

建議先從單一 Agent、單一工具開始，確認權限與輸出，再逐步加入記憶、工作流程和多代理協作。多一個 Agent 不一定會讓結果更好，卻一定會增加模型呼叫成本與除錯難度。

[!NOTE] MAF 核心框架已在 2026 年 4 月進入 1.0，但 DevUI、部分代管整合與新功能可能仍有不同成熟度。正式採用前，應逐項確認官方文件與套件版本，而不是只看框架整體的 1.0 標示。

我們的觀察

MAF 最重要的意義，是微軟終於替 AutoGen 與 Semantic Kernel 的 Agent 能力整理出較清楚的共同方向。過去團隊可能要在「容易實驗多代理」與「適合企業系統整合」之間選擇；現在微軟希望以一個框架涵蓋這兩端。

它的優勢也正是可能的門檻。MAF 涵蓋模型、工具、記憶、流程、協定、觀測與雲端代管，適合複雜系統，卻可能讓小型專案承擔不必要的架構成本。選用前應先問：任務是否真的需要長時間執行、多角色協作或中斷續跑？

更務實的判斷方式，是把 MAF 當成「Agent 應用的後端工程框架」，而不是一個自動產生可靠 AI 員工的按鈕。它能提供護欄與控制點，但真正的可靠性仍來自清楚的權限設計、測試資料、人工審核與持續監測。

來源