微軟通過Foundry押注企業AI戰場的關鍵在於可靠性而非能力
在微軟Build 2026大會上,微軟發佈了Microsoft Foundry的一系列更新,旨在使AI代理對企業用户更可靠、更可治理。新功能包括託管代理運行時、通過工具箱進行的工具治理、基於策略的評估(ASSERT)、開放代理控制規範(ACS)、多種記憶類型和知識集成。此舉表明微軟關注的是生產級代理基礎設施,而非原始能力。
在人工智能代理的浪潮中,演示環節從不缺乏令人印象深刻的作品。然而,真正能經受住生產環境考驗——面對真實負載、真實數據、真實合規要求——的代理卻寥寥無幾。在最近的微軟Build 2026大會上,微軟直接針對這一差距,發佈了Microsoft Foundry的一系列更新,這些更新共同構成了一套更接近企業級運行時的產品,而非簡單的開發者預覽版。
微軟發佈了一系列涵蓋託管代理基礎設施、評估工具、開放治理規範、記憶、知識檢索和擴展模型選項的更新。單獨來看,每一項都是合理的產品更新。但綜合起來,它們表明微軟已認定企業AI的下一個競爭前沿不是能力,而是可靠性和可治理性。
“在Build 2026上,Microsoft Foundry增加了開發者在生產環境中運行代理所需的更多平台組件:運行時、工具、記憶、基礎連接、模型、可觀測性和治理,”微軟高級項目經理Nick Brady在總結這些公告的博客文章中寫道。
無需重寫的運行時
基礎設施故事的核心是Foundry代理服務中的託管代理,微軟預計將在2026年7月初達到正式發佈(GA)狀態。該設置是一個託管運行時,其中每個會話都在自己的沙箱中運行,擁有專用的計算、內存和持久文件系統訪問權限。
值得關注的是其框架中立性。基於微軟代理框架、GitHub Copilot SDK、LangGraph或其他SDK構建的代理無需重寫即可部署。支持兩種協議:用於兼容OpenAI的有狀態交互的Responses API,以及用於直通場景的調用協議,開發者可以自行控制請求和響應格式。第二種選擇對於已經構建了自定義編排且不願廢棄的團隊來説至關重要。
託管運行時還支持例程(現為公開預覽),允許任何代理按定時或計劃運行——例如過夜問題分類、每日報告等。長時間運行的自主代理可獲得持久狀態。
與運行時一起,Foundry Toolkit for VS Code現已正式發佈。Brady將其描述為讓開發者“從模板或使用GitHub Copilot創建代理,通過跟蹤可視化本地調試運行,連接到工具箱,並從VS Code部署到Foundry代理服務”的工具。
工具箱與工具治理問題
隨着代理工具數量的增長,工具治理本身也成為一個工程問題。Foundry中的工具箱(現為公開預覽)為代理提供了一個單一的管理端點,用於所有工具類型。只需配置一次,讓任何MCP客户端指向一個URL,Foundry即可處理身份驗證、生命週期和治理。
技能(在項目級目錄中進行版本控制,並作為MCP資源可發現)現在在工具箱模型中成為一等公民。工具搜索功能(同樣處於預覽階段)有助於為每項任務選擇合適的工具,而不是將整個目錄轉儲給模型。這對於質量和防止上下文窗口膨脹都很重要。
工具箱還連接到微軟IQ——包括Work IQ、Fabric IQ(與Fabric數據代理)、Ontology和語義模型——因此代理可以訪問企業數據,而無需為每個來源自定義管道。
基於策略的評估,而非僅僅基準測試
兩項治理公告脱穎而出。第一項是ASSERT(自適應規範驅動的評估與迴歸測試),微軟的新的開源框架,用於策略驅動的代理評估,基於微軟研究院的工作。ASSERT不是針對靜態基準測試運行代理,而是將書面策略轉化為具體、可衡量的評估,並生成針對性場景,以在生產之前發現安全和質量缺陷。它支持LangChain、CrewAI、LightLLM、OpenAI等框架。
第二項是ACS(代理控制規範),一個開放的行業規範,用於在代理生命週期的五個檢查點(輸入、LLM、狀態、工具執行和輸出)設置確定性的安全和安全控制。ACS表示為可移植的YAML契約——可版本化、可審計且框架無關。發佈合作伙伴包括Infosys、KPMG、IBM、Aviatrix、BigSpin和CrewAI。
兩者的結合指向了一個真實問題。生產中的代理失敗往往不是隨機的——它們集中在可預測的輸入類型、工具濫用模式和輸出邊緣情況上。ASSERT使這些失敗模式可測試。ACS使控制可跨框架移植且跨組織可審計。
評估堆棧的其餘部分包括:Guided Guardrail Setup,一個基於問卷的嚮導(在Foundry代理構建器中),推薦PII過濾器、越獄保護和任務遵循控制,無需安全專業知識;以及Rubric評估器,可根據代理的定義和用例自動生成加權質量標準。
記憶與知識
Foundry代理服務中的記憶(公開預覽)現在涵蓋三種類型。Build新推出的程序性記憶幫助代理學習跨運行如何工作——而不僅僅是會話中説了什麼。Brady引用了早期的Tau-bench結果,顯示成功率絕對提升7-14%,成本近乎基線——這足夠具體,值得獨立復現。用户記憶跨會話保留偏好和事實。會話記憶在線程內維持上下文。
在知識方面,Foundry IQ獲得了公開預覽中的無服務器選項,新的知識源包括Work IQ、Fabric IQ、文件搜索、Azure SQL和MCP,以及知識庫(公測版,帶有SLA支持的檢索)。Brady的定位是:用‘Foundry代理背後專門的知識層’替代自定義RAG管道。Web IQ為需要實時外部上下文的代理提供了低於200毫秒的網絡基礎連接,零數據保留。
模型與計算
微軟宣佈四個第一方MAI模型進入公開預覽:用於聊天和推理的MAI-Thinking-1,用於圖像生成和編輯的MAI-Image-2.5,用於帶説話人分離的語音轉文本的MAI-Transcribe-2,以及用於多語言文本轉語音和語音克隆的MAI-Voice-2。
Fireworks AI on Foundry達到正式發佈,通過單個Azure端點提供開放模型推理,具有企業SLA、SOC 2就緒和PTU數據區域支持——無需單獨基礎設施或合同即可企業級訪問開放模型。
微軟還聲稱,對於生成技術微軟文檔等任務,Frontier Tuning的成本效率比GPT-5.5高10倍以上。這足夠具體以測試,也足夠籠統,在驗證之前值得懷疑。
更大的圖景
Brady的總結明確表明,Build 2026上的Foundry公告是設計來相互配合的。託管運行時處理部署。工具箱處理工具治理。ASSERT和ACS處理評估和控制。記憶處理狀態。Foundry IQ處理基礎連接。Rubric和Agent ROI將代理性能與業務成果聯繫起來。Rubric是Microsoft Foundry中一種新的評估器類型(目前公開預覽),可根據代理的具體上下文自動生成評估標準。
微軟認為,企業級代理AI需要平台級基礎設施——而該平台應該是Foundry。
這一論點能否成立,將不取決於Build上發佈了什麼,而取決於企業在嘗試將代理從演示遷移到部署時實際發現什麼。
微軟表示,他們正在彌合這一差距。