當你建立代理或工作流程後，首先決定誰來操作其基礎設施。 這是在由 Microsoft 管理的 Foundry 託管代理程式與自行託管之間的營運層面選擇；這與用戶端用來連線到您的代理程式所使用的通訊協定彼此獨立。
選擇主機模式
| Foundry 託管代理程式 | 自行架設 | |
|---|---|---|
| 誰負責營運基礎設施？ | Microsoft Foundry Agent Service 負責執行容器、擴展、會話生命週期及平台整合。 | 你的應用程式運行於你的網路服務、容器、執行環境或現有基礎設施中。 |
| 你主要做什麼？ | 你的代理代碼和 Foundry 設定。 | 路由、身份、授權、請求政策、儲存、部署、擴展，以及原生客戶端函式庫。 |
| 在這種情況下請選擇此項 | 你想要的是 Microsoft 管理的代理主機。 | 你需要應用層級的控制，或必須與現有基礎設施整合。 |
| 從這裡開始 | 在 Foundry 中託管代理程式 | 自行架設代理框架應用程式 |
Microsoft Foundry 託管代理程式已普遍提供。 目前的 Python 自主機套件仍為預發布;有關套件生命週期的相關資訊，請參閱自家主機指南。
對於 Azure Functions 的觸發器、持久執行或長期執行的協調，請使用 Durable 擴充功能。 這是一種採用 Durable Task 基礎結構的自主管理託管方式。
請另行選擇協定
主機模型並不決定協定。 例如，OpenAI Responses 協定可同時支援這兩種模型：
- Foundry 代管代理程式提供受管理的 Responses 和 Invocations 端點，並支援 Microsoft 365 通道的 Activity 通訊協定。
-
自行託管可讓您的應用程式使用 Responses 輔助工具，透過自身的框架、路由和政策公開
/responses端點。
選擇主機後，選擇最適合你情況的客戶端整合：
- 適用於與 Responses 和 Chat Completions 相容之 API 的OpenAI 相容端點。
- 代理程式對代理程式（A2A），用於實現代理程式之間的互通性。
- 用於網頁型代理應用程式的 AG-UI。
- Telegram 機器人，用於與自行託管的原生 Telegram Bot API 整合。
- MCP 工具 ，用於將代理或工作流程暴露為原生 MCP 工具。
下一步
深入探討：