別再把 Agent 當成一段 Prompt：Microsoft Agent Framework 如何把多代理工作流推進生產環境

如果你最近在做 AI 應用，很容易把 Agent 理解成一個更會呼叫工具的 chatbot：收進一段 prompt，交給模型決定下一步，再把結果印出來。這個模型在 demo 階段很順，但一旦任務需要多步驟執行、跨服務協作、人工核准、失敗後恢復，問題就會從「模型答得好不好」變成「整個系統能不能被控制」。

這也是我這次挑 Microsoft Agent Framework 的原因。它不是只提供另一個聊天封裝，而是試圖把 Agent 與 workflow 放進同一個工程邊界：Agent 負責理解與行動，workflow 負責明確的執行路徑，狀態與 checkpoint 負責中斷後恢復，middleware 和 OpenTelemetry 負責治理與觀測。官方定位是用 Python 與 .NET 建構 production-grade AI agents 和 multi-agent workflows，另外也提供 Go SDK 的公開預覽版本。[1][2]

先講結論：我認為 Microsoft Agent Framework 適合已經跨過「做一個會聊天的原型」階段，開始在意可重跑、可觀測、可審核的團隊。它不適合拿來替每個簡單的問答 API 增加一層抽象，也不適合在還沒有清楚任務邊界時，先建立一個十幾個代理互相轉交工作的系統。

我為什麼現在注意它

截至 2026 年 8 月 28 日，microsoft/agent-framework 在 GitHub 約有 1.3 萬顆 stars，且 repository 在最近 180 天內持續更新。[3] 星數本身不是技術品質證明，但它至少代表這個專案已經有足夠的公開討論與實作材料可以檢驗。更重要的是，官方 repository 並不是只有一個 SDK 目錄，而是把 Python、.NET、Go、宣告式 Agent、workflow samples、hosting samples 和文件集中在同一個工程入口。[3]

我覺得它值得看的核心，不是「能不能叫模型」，而是它把以下幾個問題明確化：

一個 Agent 和一個 workflow 到底誰負責決策。
多個 Agent 的協作路徑是否能被程式碼重播與測試。
工具呼叫、人工介入和外部服務失敗時，系統如何停下來而不是繼續猜。
一次執行的上下文、狀態和觀測資料要放在哪裡。
原型要如何逐步接到本機、雲端或託管環境。

先分清楚四個層次：Agent、workflow、工具與部署

很多 multi-agent 文章會把所有東西都叫成「代理協作」，結果讀者只記得可以同時啟動很多模型，卻不知道每個模型的責任邊界。我的建議是先用四層來看 Microsoft Agent Framework。

Agent：處理需要語意判斷的單位

Agent 通常有模型 client、名稱、指令和工具。它適合做需要語意理解的工作，例如把使用者要求轉成查詢條件、判讀文件、提出下一步，或根據工具結果組織回覆。Agent 的強項是彈性，代價是決策路徑不一定穩定，所以不應該讓它單獨決定所有不可逆的副作用。

工具與 MCP：把能力接到系統邊界

工具是 Agent 可以呼叫的外部能力，MCP 則提供一種連接工具與 MCP server 的方式。這裡最重要的不是「工具越多越好」，而是權限、輸入驗證、逾時、重試和輸出格式都要被當成產品設計的一部分。官方文件也提醒，只能連接信任的 MCP server，因為它們可能在本機執行命令或暴露敏感資料。[3]

Workflow：把協調邏輯移到可重跑的程式碼

Workflow 的角色是把執行路徑寫清楚。官方文件列出的能力包含 sequential、concurrent、handoff、group collaboration，以及 checkpoint、streaming、human-in-the-loop 和 time-travel 等模式。[4] 這些名詞不應被當成勳章，而應該回到一個實際問題：這次任務失敗後，我能不能知道卡在哪個節點，修正輸入後再從合理位置繼續？

Hosting：把「能跑」變成「有人能用」

當 Agent 或 workflow 要被其他應用程式呼叫，就會碰到 Responses client、Telegram、A2A、MCP client 或其他通道。官方部落格近期也把 channels、agent harness 和 production readiness 當成主題，這說明問題已經從單純的 prompt 組合，移到介面、權限、狀態與營運。[5]

第一個可驗證入口：先跑一個單一 Agent

不要一開始就建立多代理團隊。先讓一個最小 Agent 在你的環境中成功回應，確認認證、模型部署、套件版本與網路都沒有問題，再把工具和 workflow 加進來。以下範例取自官方 repository 的 Python quickstart，使用 Microsoft Foundry 與 Azure CLI credential。[3]

import asyncio
from agent_framework import Agent
from agent_framework.foundry import FoundryChatClient
from azure.identity import AzureCliCredential


async def main():
    agent = Agent(
        client=FoundryChatClient(
            credential=AzureCliCredential(),
        ),
        name="HaikuAgent",
        instructions="You are an upbeat assistant that writes beautifully.",
    )

    print(await agent.run("Write a haiku about Microsoft Agent Framework."))


if __name__ == "__main__":
    asyncio.run(main())

上手前的前置條件

官方 README 的安裝入口是：

pip install agent-framework
az login

在正式專案裡，我會改用專案隔離的環境管理方式，例如 uv add agent-framework azure-identity，避免把依賴直接灑在全域 Python。接著確認 Foundry project endpoint、模型部署名稱和 Azure 身分都已經準備好；如果你的團隊不是使用 Foundry，應該依官方 provider samples 改用相容的 model client，而不是把 Foundry credential 硬塞進所有環境。

第一個驗證任務不要用複雜 prompt。只要能穩定印出一段回應，就代表四件事已經通了：Python 套件可載入、Azure credential 可取得、模型部署可連線、Agent 的基本執行迴圈正常。若失敗，先分辨是套件安裝、az login、endpoint、deployment name 或模型權限問題，不要立刻把錯誤歸因給 workflow。

下一步可以沿著 repository 的 python/samples/01-get-started、python/samples/02-agents 和 python/samples/03-workflows 前進；這比直接複製一段網路上的 multi-agent prompt 更容易保持 API 與版本一致。[3]

從單一 Agent 走到 workflow 的實作順序

我會按照下面五步擴充，而不是同時引入所有能力。

第一步：把任務輸出變成結構化資料

先定義 Agent 要交付什麼，不要只要求「請完成任務」。例如客服分類可以輸出意圖、優先級、需要查詢的資料與是否需要人工接手。結構化輸出讓下一個節點不必從自然語言猜測上一個節點的意思，也讓測試可以比較欄位而不是比較整段文字。

第二步：只加入一個真實工具

選一個能證明價值的工具，例如查詢訂單或讀取內部文件。為工具加上明確 schema、權限和逾時；先記錄模型提出的參數，再執行副作用。若工具會修改資料、寄信或交易，先插入人工核准，不要因為模型在測試中表現穩定就跳過這一層。

第三步：把固定順序寫成 workflow

如果任務永遠是「分類 → 查資料 → 產生草稿 → 審核」，就不要把這個順序藏在一個超長 system prompt 裡。用 workflow 的節點和邊表達它，讓每個節點都能獨立測試，讓執行紀錄能回答「哪一步花了多久」與「哪一步失敗」。

第四步：只在必要時加入平行與 handoff

平行適合互相獨立的查詢，例如同時查產品資料與政策文件；handoff 適合責任真的從一個專業角色轉給另一個角色。若兩個 Agent 只是交換同一份上下文，平行化未必會提高品質，反而會增加 token、整合和除錯成本。

第五步：補上 checkpoint、人工介入與 observability

當任務可能超過一次請求的生命週期，就要保存狀態。checkpoint 不是單純把 prompt 寫進資料庫，而是要能辨認目前執行到哪個節點、哪些輸入已經消費、哪些副作用已經完成。人工介入也要有明確的 pause 和 resume 邊界。官方 workflow 文件將 checkpoint、恢復執行、human-in-the-loop、OpenTelemetry 和 topology visualization 都列為工作流能力的一部分。[4]

什麼時候該用子代理、skills、代理團隊或 workflow

這四個概念很容易混在一起，我會用「是否需要獨立生命週期」來分辨。

子代理：主 Agent 臨時委派一個窄任務，結果回來後通常不需要獨立營運。
Skills：可重用的領域知識或操作能力，重點是如何被發現與套用，不等於另一個具有完整責任的 Agent。
代理團隊：多個 Agent 各自扮演角色，適合需要不同專長或明確交接的任務。
Workflow：把節點、執行順序、事件、狀態和恢復規則固定下來，適合要測試、審計和重跑的流程。

如果只是讓模型查一份資料，我會用單一 Agent 加一個工具。如果需要研究與審稿兩種角色，我才會考慮代理團隊。如果流程還要支援重試、核准、恢復和觀測，最後一定要把協調邏輯提升成 workflow。不要因為「multi-agent」聽起來比較先進，就把所有問題都拆成代理。

我會特別留意的限制

1. 官方定位很廣，但雲端依賴仍然真實存在

README 同時涵蓋 Python、.NET、Go、Foundry、Azure OpenAI、OpenAI、GitHub Copilot SDK 與 hosting patterns，選擇很多，但這不代表每條路徑都具有相同成熟度。Go SDK 目前是 public preview，官方 overview 也明確說明部分能力尚未提供。[2][3] 評估時要針對你要用的語言、provider 和部署方式做小型 proof of concept。

2. Agent 的彈性不能取代系統邊界

Agent 可以自己決定下一個工具，但不應自己決定所有權限。生產環境至少要把工具白名單、參數驗證、敏感資料遮罩、逾時、重試上限和人工核准分開設計。尤其是 MCP，便利性越高，越需要清楚知道 server 會做什麼。

3. 可觀測性不是最後才加的 dashboard

如果沒有記錄 workflow run、節點輸入輸出摘要、模型呼叫延遲、工具錯誤和 token 成本，你很難分辨是 prompt、模型、工具還是協調邏輯造成失敗。OpenTelemetry 應該在第一個可重跑的流程就接入，至少先讓每次執行有 correlation id 和節點級別的時間線。

4. 多代理的成本可能比收益更快上升

每增加一個 Agent，就增加上下文傳遞、模型呼叫、失敗組合和結果整合。並行也不等於免費：它可能縮短牆上時間，卻提高同時請求量和 provider 成本。先量測單一 Agent 的基線，再以任務品質、延遲、可恢復性和總成本判斷要不要拆分。

5. 從 AutoGen 遷移不是改幾個 import 就完成

Microsoft 提供 AutoGen 到 Agent Framework 的官方 migration guide，內容涵蓋 model client、AgentSession、tool、MCP、Agent-as-a-Tool、middleware、multi-agent workflow、human-in-the-loop、checkpoint 和 observability。[6] 這代表遷移真正需要重新檢查的是執行模型與責任邊界，不只是把類別名稱換掉。

如果你已有 AutoGen 應用，我會先挑一條最小但完整的流程遷移：一個 Agent、一個工具、一次人工核准和一個可恢復的失敗案例。等行為、日誌和成本都對得上，再處理更複雜的 group chat 或多代理編排。

適合哪些團隊先試

我會把第一批試用者分成三類。

第一類是已經有明確流程的產品團隊，例如客服分流、研究報告、內部營運或文件審核。這些流程通常有節點、權限和人工作業，最能驗證 workflow、checkpoint 和 human-in-the-loop 的價值。

第二類是需要同時支援 Python 與 .NET 的企業團隊。Microsoft Agent Framework 的跨語言定位，可以讓團隊在相近的概念下分別整合既有服務；但仍應以實際 SDK 功能和 provider 支援矩陣做驗證，不要把「跨語言」當成 API 完全相同。

第三類是已經遇到 Agent 原型治理問題的開發團隊：工具越加越多、錯誤難以重現、長任務常常中斷，或產品開始要求審核與稽核。這時候框架的價值不是讓 demo 更快，而是讓系統的失敗方式更可預期。

反過來說，如果你的需求只是一個 FAQ endpoint、一個固定的 RAG 查詢，或一個沒有外部副作用的文字生成器，我會先使用更小的 SDK 組合。框架越完整，學習與維運成本也越高；不要為了貼上 Agent 標籤而引入 workflow。

我的導入檢查表

在真正接資料與權限之前，我會要求團隊回答以下問題：

任務的成功條件能不能寫成可測試的欄位或事件？
哪些步驟必須固定，哪些步驟才值得交給模型決策？
哪些工具是 read-only，哪些工具會造成不可逆副作用？
Agent 失敗、工具逾時或人工拒絕時，流程要停在哪裡？
重新執行會不會重複寄信、扣款、寫入或發布？
每一次 run 是否都有狀態、trace、成本和版本資訊？
目前真的需要多代理，還是單一 Agent 加 workflow 已經足夠？

這份清單看起來不像 AI demo，但它才是把 demo 變成產品時最常缺的部分。

結語：先把路徑寫清楚，再讓模型保持彈性

我對 Microsoft Agent Framework 的判斷是：它最有價值的地方，不是替你自動生成一個很會聊天的 Agent，而是提供一條從 Agent、工具到 workflow 和 hosting 的連續工程路徑。你可以先用幾行 Python 驗證模型呼叫，再逐步加入結構化輸出、工具、人工核准、checkpoint、observability 和部署通道。

這條路徑也提醒我們，multi-agent 不是產品目標，可靠的任務完成才是。能用固定程式碼表達的協調邏輯，就不要藏進 prompt；需要模型判斷的地方才保留彈性；會造成副作用的地方，一定要有權限與人工邊界。

如果你正在評估它，我建議的第一個實驗很小：選一個有清楚輸入與輸出的任務，建立單一 Agent，接一個 read-only 工具，記錄完整 trace，再故意注入一次工具失敗。只有當團隊能回答「失敗發生在哪裡、如何恢復、成本是多少」，才值得把它擴成多代理 workflow。

參考資料