學習使用 Azure AI Foundry 建構 Agentic 應用程式

對一位解決方案架構師來說，使用 Azure AI Foundry 來建構 agentic 應用程式，就像踏入一個全新的世界。這是一個龐大的承諾——一整套可用於建立、部署與管理 AI 代理的生態系統，能在企業規模下運作，但同時也需要我們重新思考如何設計架構、規劃採用方式，以及整合安全與治理。來自傳統解決方案設計背景的我，很快就發現，用正確的框架來面對這個領域會帶來完全不同的效果。

我從微軟的雲端採用框架開始，它將這段旅程拆解為熟悉的階段。首先是定義策略，幫助我釐清企業為何要導入 agentic AI，以及我們期望獲得的價值。接著是規劃，將這些動機轉化為可執行的步驟；準備環境則是利用 Azure 登陸區，讓我對基礎建設有了信心。當進入採用階段時，代表真正開始建構與部署工作負載；最後的安全階段提醒我，AI 系統必須遵循與任何企業平台相同的嚴格治理標準。

接下來的學習曲線是理解 AI 登陸區。它們是 AI 採用在企業規模下的基礎，可以選擇有或沒有更廣泛的平台登陸區來部署。有了平台登陸區，像是網路與身分服務會集中化，能帶來可擴展性與合規性；沒有的話，雖然能更快開始，但一致性會受到影響。對我而言，登陸區就像是 AI 代理的資料中心，成為其他一切元件的基礎。

當基礎設施清楚之後，我需要決定實際如何建構代理。Azure AI Foundry 提供了多種嘗試方式：低程式碼或免程式碼工具可以快速原型設計，而專業程式碼環境則透過 VS Code 擴充套件、REST API 或 Semantic Kernel SDK 提供完全自訂的能力。一開始我依靠低程式碼工具來獲得實作經驗，隨著整合需求和複雜度提升，逐漸轉向專業程式碼的場景。最重要的教訓是從簡單開始，隨時間加深，並謹慎挑選模型、在成本與效能之間取得平衡，同時決定代理需要整合的工具，例如 Azure AI Search、Bing grounding 或 Logic Apps。

另一個關鍵的設計抉擇是要依賴單一代理，還是採用多代理系統。單一代理可預測且容易除錯，是很好的起點。然而在動態或可分解的工作負載中，多代理更能發揮優勢，不同專業的代理可以協作，例如在人員入職過程中結合 HR、IT 與合規代理。Semantic Kernel 提供了這種協作所需的協調層，讓工作流程能隨著複雜度增加而擴展。對我來說，最有效的方法是先從單一代理開始，只有在需求出現時才轉向多代理協調。

其中一個最大的思維轉變，是意識到可觀測性與評估並非選項，而是必須。不同於傳統應用程式的指標相對直觀，若沒有設計可視性，代理就像黑盒子。Azure AI Foundry 的追蹤功能能記錄工具呼叫與代理互動，其評估指標則檢查回應的依據性、流暢度與相關性。結合 AI 安全工具，這些能力能確保輸出安全、可靠，並符合組織目標。對我來說，這就像傳統系統的應用程式效能監控：缺乏可見性，就不可能改善。

當然，如果系統不安全，其他一切都沒有意義。Foundry 在整個堆疊中加入治理與安全控制。受控身分與登入保護使用者，提示與內容篩選確保負責任的 AI 實踐。虛擬網路、NSG 與 VPN 閘道提供網路安全，而 Defender for Cloud 則新增威脅防護。Purview 進一步強化資料治理與合規性。我意識到，雖然代理看似未來感十足的 AI 實體，但在架構上，它們必須被視為微服務，遵循任何其他企業系統相同的安全原則。

回顧我在 Azure AI Foundry 的早期探索，有幾個教訓特別清晰。根據使用案例的成熟度來選擇建構方式，無論是免程式碼、低程式碼，或專業程式碼。謹慎挑選模型與工具，仔細衡量成本與效能。從小規模的單一代理開始，當複雜度增加時再擴展到多代理協調。從第一天起就將可觀測性、評估與負責任 AI 實踐納入基礎。最後，善用 AI 登陸區來進行企業級部署，確保安全性、可擴展性與治理。

對我而言，Azure AI Foundry 已不僅僅是部署語言模型的平台，而是連結實驗與企業就緒之間的橋樑。它提供了必要的框架、工具與防護措施，讓我們能以負責任的方式建構 agentic 應用程式。這段旅程起初可能令人望而生畏，但只要採用有結構的方法並專注於架構原則，agentic AI 很快就不再神祕，而是邁向現代系統設計的下一個自然步驟。