Azure Foundry Hosted Agents 實戰入門：讓子 Agent 化身為工具

原始來源與檔名：20260512_2026-05-06T095712+0800-Getting Started with Foundry Hosted Agents.md

來源：[[Valentina Alto]] / Medium — 2026-05-03 原始檔名：2026-05-06T095712+0800-Getting Started with Foundry Hosted Agents.md

NAPKIN | 餐巾紙

餐巾紙公式

Agent Orchestration: Multi-Agent Handoff vs. Agents as Tools. Agents as Tools Pattern = 1 Concierge (Face) + N Specialists (Wrapped as functions via agent.as_tool()). Foundry Hosted Agents = Dockerfile + agent.yaml + Port 8088 (OpenAI Responses Protocol).

這是一篇關於如何在 Microsoft Azure Foundry 環境中部署 AI Agent 的實戰教學。作者延續了之前的「AI 旅行社」範例，但這次她拋棄了傳統的「Multi-agent Handoff (多代理交接)」模式，改用語法更簡潔、對話體驗更一致的「Agents as Tools (將代理作為工具)」模式：客戶只與一位「前台禮賓員 (Concierge)」對話，而「航班專家」與「飯店專家」則被包裝成普通的 Function Tool 供禮賓員隨時呼叫。最後，文章展示了如何透過簡單的 Dockerfile 與 agent.yaml，將這個 MAF (Microsoft Agent Framework) 應用程式部署為標準的 Hosted Agent API。

一句話

不要讓你的 Agent 互相把客戶「踢皮球」。如果你有一個前台 Agent 和幾個後端專家 Agent，最好的設計模式是把專家 Agent 包裝成「工具 (Tools)」：前台決定何時呼叫專家，專家在背景查完資料後交給前台，由前台統一回覆客戶，這樣能保證對話語氣的一致性。在微軟的架構下，只需一行代碼 agent.as_tool() 就能搞定。寫好後，加上一個監聽 8088 埠的 Dockerfile，你就能把它一鍵部署到 Azure Foundry，自動享有完整的企業級權限控管與監控追蹤。

餐巾紙草圖

[ Agents as Tools Pattern ]

Instead of Hand-offs: (User -> Concierge -> FlightAgent -> HotelAgent -> User)

Use Tools Topology:
[ USER ] <---> [ Concierge Agent ]
                     │ (Calls tools when needed)
                     ├──> Tool: flight_assistant.as_tool()
                     └──> Tool: hotel_assistant.as_tool()

[ Foundry Deployment ]
Code + Dockerfile (EXPOSE 8088) + agent.yaml --> Azure Foundry Agent Service

ROUND 1: SKELETON | 骨架掃描

“這篇文章在說什麼”

• 目標: 將一個基於 Microsoft Agent Framework (MAF) 建構的「AI 旅行社」部署到 Azure Foundry Agent Service 上。
• 架構設計轉變 (Agents as Tools):
  • 放棄了「Handoff (交接)」模式，改採「工具模式」。
  • 只有一個對外窗口：Concierge Agent。
  • Flight Specialist 與 Hotel Specialist 被宣告為獨立的 Agent，但透過 agent.as_tool() 將自己偽裝成普通的函數工具，放入 Concierge 的 tools=[] 陣列中。
  • 優點: 聲音一致、沒有循環交接的死鎖問題，同時底層的 Tracing 依然能精準紀錄哪個子 Agent 做了什麼事。
• 本地端測試:
  • 透過一個輕量級的 HTTP Adapter 封裝，讓 Agent 監聽 localhost:8088 並遵循 OpenAI Responses Protocol。
  • 使用 VS Code 的 Foundry extension 進行視覺化的 Agent Inspector 偵錯。
• 部署到 Foundry (Hosted Agent):
  • 需要兩個檔案：Dockerfile (建置環境並開放 8088 埠) 與 agent.yaml (定義 Metadata)。
  • 部署後即可獲得標準化的端點 (Endpoint)、企業級的治理 (RBAC、身份驗證)、以及自動化的遙測 (App Insights)。
• 消費模式:
  • 整合到 Microsoft 365 Copilot 或 Teams (無須撰寫前端)。
  • 透過 API 介接到自定義的前端 APP。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

核心論證鏈

1. Handoff vs Tools 的抉擇: 在多代理系統中，Handoff 容易讓對話失去上下文，且一旦進入死循環（Agent A 把任務丟給 B，B 又丟回 A）很難除錯。將 Sub-agents 降級為 Tools，讓主 Agent 保留對狀態和對話語氣的絕對控制權，是一種更強健的架構選擇。
2. 標準化協定的力量: Foundry 並不綁定 MAF。只要你的 Docker 容器能在 8088 埠上說出標準的 OpenAI Responses Protocol，裡面裝的是 LangGraph、AutoGen 還是你自己寫的 while True 迴圈都無所謂。這種解耦設計才是企業級 PaaS 該有的樣子。

關鍵證據

• 程式碼展示了 MAF 中的優雅設計：tools=[flight_assistant.as_tool(), hotel_assistant.as_tool()]。這行代碼完美抹平了「呼叫一個簡單的加法函數」與「呼叫一個背後有完整 LLM 推理邏輯的子代理」之間的介面差異。

邊界條件

• 何時不該用 Hosted Agents: 如果你需要極端特殊的底層硬體資源，或是完全不希望資料流經微軟的網路控制面，那麼這篇提到的 Hosted Path 就不是首選，你必須退回到 Self-Hosted Path (自行管理 K8s)。

ROUND 3: SOUL | 靈魂提取

“還能怎么用”

• 知識連結: 呼應了《Building an AI Agent from Scratch》一文對架構的解構。這篇文章展示的 Hosted Agent，本質上就是把我們自己寫的 Agent Loop 打包進 Docker，然後套上一個遵循 OpenAPI 協定的 Adapter，讓外部系統（如 Foundry）可以直接呼叫。
• 深層洞見: “The conversation has one consistent voice. There are no cycles to terminate… you don’t lose any observability by collapsing the topology.” (對話擁有一致的聲音。沒有需要終止的循環… 你不會因為扁平化拓撲結構而失去任何可觀測性。) 在多 Agent 協作中，「擬人化」往往是個陷阱。我們不需要讓三個 Agent 像開會一樣七嘴八舌，我們只需要一個聰明的大腦，把另外兩個 Agent 當作 API 來呼叫就好。
• 行動呼籲: 如果你正在設計多 Agent 系統，請立即停止撰寫複雜的「Handoff」邏輯。重構你的架構，指定一個主 Agent 作為唯一的對外窗口，將其他所有的輔助 Agent 轉換為 Tool。這不只會讓你的對話體驗大幅提升，還能避免無窮迴圈造成的 Token 破產。