Aspire 把 Agent 圖譜收進一個 AppHost

Aspire 13.4 把多代理 App 收進同一個圖譜，讓聊天、語音、專家代理和資料服務一起跑、一起追蹤。

說真的，這篇重點很明確。Aspire 不再只是啟動服務的工具。它現在更像整個系統的藍圖。

在 Microsoft 的 AlpineAI 範例裡，聊天、語音、專家代理、Foundry 資源，還有 Cosmos DB Emulator 都放進同一個 AppHost。版本是 13.4，發布日是 2026 年 6 月 9 日。這些數字很直白，意思也很直白：多代理系統開始走向可管理，而不是靠啟動腳本硬撐。

一個 AppHost 就是整張圖

這次最有意思的地方，是 AppHost 的角色變了。它不只是啟服務而已。它開始描述整個 app graph，包括模型部署、prompt agent、hosted agent、Python 服務、Go 服務，還有它們依賴的基礎設施。

講白了，就是把原本散掉的東西收回來。你不用再靠腦內記憶去拼湊「誰先起、誰連誰、誰吃哪個資料庫」。Aspire 直接把依賴關係寫進去。

在 AlpineAI 範例裡，這張圖包含前端、資料產生器、聊天 advisor、語音 advisor，還有多個專家代理。Aspire 會照順序啟動，建立引用關係，然後把實際跑起來的東西攤給你看。

• Foundry account 和 project 管 agent 資源。
• Model deployments 分開一般聊天和 realtime 語音。
• App references 連結代理、資料和其他服務。
• Azure Container Apps 把執行環境講清楚。

這種做法比「先把 API 起來再說」實際太多。因為一旦加上 voice、tool call、live telemetry，單靠手動啟動很容易炸。你今天記得住，明天就忘了。

Microsoft 也把不同執行模型放在同一份定義裡。Foundry 可以放 prompt agent。自家程式也能包成 hosted agent。兩者不是同一種東西，但 Aspire 把它們當成同一個系統的一部分。

Advisor 才是 orchestration 層

聊天 advisor 才是整個體驗的腦袋。它接收使用者問題，判斷要叫哪些專家代理，再把答案整合成一段回覆。這比把所有問題丟給一個大模型硬猜，乾淨很多。

Tommaso Stocchi 在文章裡寫得很清楚。這個範例像一個真實的滑雪場櫃台。它能回答旅客問題、讀即時 resort telemetry、轉派任務給專家代理、查網路上的一般滑雪知識，還能同時支援聊天和語音。

“The important part is not that the demo is about skiing. The important part is how Aspire turns a complex multi-agent system into one application graph you can run, observe, and publish.”

這句話很到位。重點真的不是滑雪。重點是系統一大之後，還能不能看懂它、跑它、修它。

在這個設計裡，使用者只跟 advisor 對話。weather、lift traffic、safety、ski coach 和 web research 都變成工具。每個工具只做一件事，這樣 trace 才看得懂，問題也比較好抓。

• Weather agent 管即時天氣和預報。
• Lift traffic agent 管排隊時間和纜車狀態。
• Safety agent 管封閉路段和坡面風險。
• Ski coach agent 把程度轉成建議。
• Ski researcher 用 web search 回答一般滑雪問題。

語音不是另一個 App

語音 advisor 的做法很聰明。它不是再做一套獨立系統，而是走同一組專家代理，只是 transport 和 runtime 不同。它是 .NET WebSocket service，接瀏覽器音訊，再串 Azure AI Voice Live。

這種設計很務實。很多團隊會把 voice 和 chat 拆成兩個世界。結果就是行為不一致，prompt 不一致，debug 也不一致。最後大家只好互相怪來怪去。

Microsoft 在 Foundry 裡也把 realtime 和一般聊天模型分開。範例裡，一個 deployment 給標準對話，另一個給語音即時互動。這個切法合理，因為 latency、streaming 和 prompt tuning 的需求本來就不同。

對開發者來說，真正省事的是啟動流程。Aspire 可以把前端、語音服務、advisor、資料產生器一起起來。你不用自己寫一坨 launch script，還要怕漏掉某個環節。

數字一看，架構就清楚了

這篇文章給了不少具體數字。Aspire 是 13.4。發文日是 2026 年 6 月 9 日。範例裡有 2 個 model deployments、5 個 specialist agents、2 個使用者面向的 advisor 體驗。這不是空泛描述，是真的有東西在協調。

如果你拿這些數字去比，就會更有感。單一 advisor 只是一個 MAF agent，卻要 fan out 到 5 個工具。語音 advisor 也是另一條服務路徑，但它還是靠同一個 Foundry project 和同一份即時資料。資料產生器則是 Go 寫的，專門餵 telemetry。

這種多語言、多 runtime 的混搭，Aspire 沒有假裝不存在。它直接把事實攤開。這點我覺得比很多平台誠實多了。

• Go 負責資料產生器。
• Python 負責 weather、safety、ski coach agents。
• .NET 負責 advisor、lift traffic、voice service。
• A2A 讓專家代理把能力包成工具。

還有一個很重要的點，是觀測性。文章提到 OpenTelemetry 已經接進 advisor，還有敏感資料開關。這代表 Microsoft 預設你要 trace agent 行為，不是只把它跑起來就算了。

當 advisor 決定要不要叫 weather、lift traffic、safety 或 ski coach 時，trace 應該說得出理由。沒有這個，除錯就會變成猜謎。尤其一個模型呼叫後面又串好幾個工具時，猜錯一次就很痛。

這種結構，不只適合滑雪場

AlpineAI 雖然是 demo，但架構很容易對到真實產品。客服助理、現場營運儀表板、旅遊規劃器、內部 IT agent，很多都會長成同一種樣子：一個 orchestrator，加上幾個窄職責的專家，再接一個即時資料源。

這裡也看得出平台和自訂程式的分工。Foundry 管 hosted prompt agent 和 model 資源。自家程式管 domain logic、orchestration，還有需要自己依賴的服務。Aspire 把兩者放在一起，但不硬把它們混成同一件事。

這個分法很重要。它避免兩種常見災難。第一種是把所有工作硬塞進一個大 prompt。第二種是把 agent 拆得滿地都是，repo 多到你自己都找不到。

我覺得接下來真正的問題，不是 agent 能不能互相講話。問題是團隊願意把 graph 維持多大，才需要更強的 policy、測試和 trace 分析。現在這個範例給的答案很務實：先用一張圖，讓專家保持窄，讓 advisor 當唯一入口。

結語：先把系統畫清楚，再談聰明

這次 Aspire 的訊號很明白。它想處理的不是單一 API，而是整個 agentic app 的結構。對台灣開發者來說，這很實用，因為真正難的通常不是模型，而是系統怎麼管。

如果你也在做多代理應用，我會建議先問一件事：你的 AppHost 能不能一眼看出誰依賴誰。能看懂，才有辦法 trace、測試、上線。看不懂，後面再多模型都只是堆複雜度。