Microsoft Agent Framework 加入 …

Microsoft 的 Agent Framework 最近補了一塊很實用的拼圖。它開始把 Model Context Protocol 當成正式的工具接法。支援 stdio、HTTP、WebSocket 三種路線，這件事比你想的更接地氣。

講白了，這不是在玩概念。你今天要接 GitHub MCP server，明天要串 docs 搜尋，後天要吃即時資料流，這套框架都想讓你用同一種思路處理。對做 agent 的人來說，這種一致性很重要。

但我先潑一點冷水。Microsoft 也直接提醒，第三方 MCP server 可能看到 prompt 內容和你送出的資料。這句話很硬，但很合理。agent 不是魔法箱，它只是把資料送得更遠而已。

Microsoft 這次到底加了什麼

這次更新的重點，是讓 MCP 變成 Microsoft Agent Framework 裡的正式工具層。不是額外插件，也不是旁支功能。它就是讓 agent 能直接列出工具，然後在執行時呼叫。

在 .NET 這邊，流程很直白。框架先連到 MCP server，再抓工具清單，最後把工具轉成 agent function。模型在 run 的時候，就能自己挑要不要呼叫。這種設計很像把外部 API 變成 agent 的手腳。

Python 這邊也有對應的工具類別。Microsoft 把不同 transport 分開處理，讓你不用自己硬拆 protocol 細節。這對團隊開發很有感，因為你不用每次都從 socket、headers、stream 這些底層細節重寫一遍。

• stdio：適合本機啟動的工具程式
• HTTP/SSE：適合部署在伺服器上的服務
• WebSocket：適合雙向、即時資料
• runtime headers：可在執行時帶入，不必寫死在 client

這組選項很務實。你可以把本機腳本、雲端服務、即時串流都放進同一個 agent 架構裡。問題只剩一個：你敢不敢把它上線。

官方文件也提到，Python 如果要用 WebSocket，可能得裝 mcp[ws] --pre。如果只用 stdio 或 streamable HTTP，預設的 pre-release 套件就夠了。這種安裝差異不算大，但對 CI/CD 很重要，因為套件版本會直接影響部署穩定性。

安全提醒才是重點

很多人看到工具範例，第一反應是「哇，好方便」。我覺得這種反應太快了。真正該看的，是 Microsoft 怎麼處理安全與憑證。因為 MCP 一旦接上外部系統，資料流向就不是你一個人說了算。

文件寫得很清楚。headers 要在每次 run 的 tool_resources 裡帶入。這代表 API key、OAuth token 這類資訊，不必長期放在共用 client。對多 agent、多租戶、或多人共用服務的環境，這種做法比較乾淨。

Microsoft 也特別點名 DefaultAzureCredential。開發時它很方便，會自己試很多登入方式。但到了 production，官方建議改用明確的 credential，例如 ManagedIdentityCredential。原因很簡單，少一點探測流程，就少一點延遲和意外。

“You are responsible for your use of non-Microsoft services and data, along with any charges associated with that use.”

這句話很直白，也很像雲端時代的真心話。你把 agent 接出去之後，責任就不是只有模型準不準。你還要管資料去哪裡、誰能看、會不會留存、費用怎麼算。

Microsoft 也把安全文件連在一起，包含 Model Context Protocol 自己的安全說明，以及相關風險討論。這很像在提醒大家：MCP 不是玩具。它是 production dependency。

三種 transport 差在哪

這次最有價值的地方，就是 transport 分得很清楚。很多框架都愛把工具接法包成一坨，結果大家最後還是得自己猜。Microsoft 這次至少把路線講明白了。

MCPStdioTool 適合本機 process。你可以把工具當成子程序啟動，像是本機腳本、CLI、或內部小工具。這種方式最簡單，也最適合開發階段。

MCPStreamableHTTPTool 則對應 HTTP 和 server-sent events。這比較像正式服務的玩法。你有一個 endpoint，agent 透過 HTTP 去拿工具資訊和回傳結果，部署上也比較容易跟現有基礎設施整合。

MCPWebsocketTool 則是另一條路。它比較適合即時資料、雙向互動、或需要長連線的場景。像行情、監控、協作編輯，這種情境就很吃 WebSocket。

• Filesystem MCP server：適合檔案操作
• SQLite MCP server：適合本機資料查詢
• GitHub MCP server：適合 repo、issue、PR 工作流
• Microsoft Learn MCP endpoint：適合 docs 類查詢

如果你問我哪個最實際，我會說 stdio 最適合快速落地。HTTP 最適合團隊協作。WebSocket 最適合即時系統，但也最容易踩坑。因為長連線一多，除錯成本就會飆上去。

從資料安全角度看，transport 不是只有技術選擇。它也決定你的 auth 模型、觀測方式、以及故障排除方法。這就是為什麼同樣是 MCP，不同 transport 的維運感受差很多。

和其他 agent 工具層比起來

把這件事放到整個 agent 生態看，Microsoft 的做法算是很務實。它沒有硬推單一封閉格式，而是直接接上 MCP。這點對開發者很友善，因為 MCP 已經有不少工具伺服器可以用。

如果你拿它跟 OpenAI Agents SDK 比，思路就不太一樣。OpenAI 那邊比較偏向自家工具與 workflow 整合。Microsoft 這邊則是把 protocol 擺前面，讓你先選 transport，再接服務。

再看 Claude Code 或各種 MCP client，差別也很明顯。很多工具都能接 MCP，但不是每個框架都把 transport、headers、credential 這些細節處理得這麼明。這次更新的價值，就在於它把這些細節拉到檯面上。

下面這組比較，能看出差異：

• Microsoft Agent Framework：重視 .NET、Python 與企業整合
• MCP：重視工具協定與跨服務互通
• OpenAI Agents SDK：偏向自家 agent 工作流
• Claude Code：偏向開發者工作流與本地工具

還有一個現實問題。很多團隊不是缺 LLM，而是缺工具接法。你有 GitHub、資料庫、內部文件、監控系統，但每個都要自己寫 glue code。MCP 的價值，就是把這些接法標準化一點。

當然，標準化不代表沒風險。你接的 server 越多，攻擊面就越大。這也是為什麼 Microsoft 一直提醒要審核 server，還要記錄共享了哪些資料。這種提醒看起來很老派，但真的有用。

這背後的產業脈絡

agent 熱潮起來之後，大家很快發現一件事。真正難的不是聊天，而是連資料、連工具、連權限。LLM 會講話，不代表它會做事。要讓它真的能做事，你就得幫它接外部系統。

這也是 MCP 會紅的原因。它想解的不是模型能力，而是整合成本。你不用每次都為某個工具重寫一套專屬 adapter。只要 server 跟 client 都講同一套 protocol，開發速度就會快很多。

Microsoft 把這套東西放進 Agent Framework，其實很符合它一貫的路線。它不一定要做最潮的 demo，但它很在意 enterprise 會不會真的用。對台灣很多做內部系統、SaaS、或顧問專案的團隊來說，這比炫技更重要。

你也可以把它看成一種訊號。未來 agent 專案的重點，可能不會只是 prompt 寫得多漂亮，而是你能不能把權限、資料流、和工具介面管好。這才是上線後會被問的事。

我會怎麼看這次更新

我覺得這次更新最實際的地方，是它沒有只講理想。它把 stdio、HTTP、WebSocket 都列出來，還把 runtime headers 和 credential 管理講清楚。這代表它不是在賣概念，而是在處理部署。

如果你已經在做 agent，我會建議先挑一個最小場景試。比如先接 Filesystem MCP server，或先串一個 docs endpoint。先把權限、headers、錯誤處理跑順，再考慮 WebSocket 這種比較重的路線。

我自己的預測很簡單。接下來 6 到 12 個月，會有更多團隊把 MCP 當成 agent 的標準工具層。不是因為它很潮，而是因為它夠實用。你如果現在就把資料邊界、憑證策略、和 server 審核流程想清楚，後面會少掉很多補洞時間。

所以問題不是「要不要做 agent」。問題是「你要讓 agent 接哪些工具」。這一步想清楚，後面才不會一路亂接，最後把資料和權限搞成一團。