Microsoft Build 2027 前，Foundry Hosted Agents 部署如何驗收？

部署後看得到版本，卻不確定 Agent 是否真的能接住請求、延續工作階段？
最快的驗收方式，是不要只看部署成功；本週先逐項確認執行協定、就緒檢查、身分設定、工作階段與部署後呼叫鏈路。

準備把本機 Agent 移到 Microsoft Foundry Hosted Agents 的 Python、.NET 開發者，可用本文整理部署前後的驗收流程。
負責容器與發布的平台工程師，可據此檢查執行環境、就緒探針與版本狀態。
若你正為 Microsoft Build 2027 前的基礎設施盤點做準備，請以現行官方文件和實際測試為準；不要把尚未確認的活動日期或產品更新當成已公布資訊。

先盤點依賴，再決定哪些工作適合託管

Microsoft Learn 說明，Foundry Hosted Agents 可將程式型 Agent 以容器化應用部署到託管基礎設施，並提供執行協定及部署文件。這表示平台負責託管流程的一部分，不代表你的 Agent 程式、相依套件或呼叫行為已自動通過驗收。可先對照Hosted Agents 的平台說明，確認方案與目前文件所述能力相符。

部署前要先看哪些項目？
先從本機專案整理三類資料：Agent 啟動方式與程式入口、建置所需的程式碼及套件、部署與呼叫所需的設定。把祕密值與一般設定分開，不要將憑證寫進程式碼或映像檔。接著列出外部依賴，例如資料庫、檔案服務、內部 API、子程序，以及需要的環境變數和連線權限。

以下對照可協助你判斷工作應放在哪個階段驗收：

檢查選項	適用情況	主要驗收重點	不應假設
本機 Agent 專案	還在確認程式與依賴能否啟動	套件、設定、輸入輸出及錯誤處理	本機可跑就等於雲端可跑
Foundry Hosted Agents	希望在託管環境發布程式型 Agent	執行協定、映像建置、發布狀態及端點呼叫	部署完成就代表應用邏輯正確
需要特殊依賴的 Agent	仰賴外部服務、特定系統工具或非預設設定	網路連線、授權、啟動依賴與失敗回應	託管平台會代替團隊補齊依賴

如果 Agent 依賴無法在目標環境安裝的工具、需要直接操作本機硬體，或必須存取尚未開通的內部網路，先不要急著發布。將這些列為阻擋條件，否則「容器建置成功」可能掩蓋執行期才會出現的問題。準備發布前，也可閱讀自有程式碼部署快速入門，並以當下頁面所列的發布方式和 SDK 狀態為準。

本機先驗協定，別把 SDK 當成應用保證

部署前應先確認 Agent 符合所選的請求協定。依照Hosted Agent 執行契約檢查請求與回應格式、啟動和處理方式，再用你自己的測試資料確認程式確實能處理它們。SDK 可以提供介面或輔助工具，但不會替你驗證自訂邏輯是否符合預期。

健康檢查和請求協定，應該怎樣一起驗證？
把健康檢查視為「服務目前是否就緒」的訊號，把請求測試視為「Agent 是否能完成工作」的檢查。核對就緒探針所使用的設定與應用啟動行為是否一致；若應用尚未完成必要初始化，就應確認探針不會過早回報可用。再分別送出正常輸入、缺少必要欄位的輸入，以及會觸發應用錯誤的輸入，記錄實際回應，而不是只確認端點有回覆。

至少測試這些情境：

正常請求：回應格式可被呼叫端解析，內容符合預期。
流式輸出：確認資料是否按應用設計逐段回傳；不要假定 SDK 會替所有程式處理串流。
工作階段延續：以同一工作階段連續提問，再以新的工作階段測試隔離情況。
錯誤輸入或依賴失效：確認錯誤能被辨識，且不會把內部祕密或敏感資料放進回應。
啟動與就緒：在依賴尚未就緒或啟動失敗時，核對健康檢查結果是否能反映實際狀態。

發布時看版本狀態，不要照抄過期命令

部署流程會受發布方式、SDK 與文件版本影響。開始前，先查看目前的 Hosted Agents 部署指南，核對建立版本、發布及端點呼叫的流程名稱和適用條件。本文不提供可能已變動的命令；請從官方指南確認當下語法，再按團隊使用的 SDK 版本執行。

第一步：固定可追溯的程式版本

確認待發布的程式碼、相依套件和設定有明確版本紀錄。記下預計部署的版本識別方式，並確認測試所用設定沒有混入正式環境祕密。若同一版本在本機無法重現，先處理程式或建置差異，再發布。

第二步：依文件打包並建立版本

按官方部署方式準備應用程式及容器所需內容。留意必要檔案是否包含在建置內容中，啟動指令是否指向正確入口。不要把文件範例的設定值、資源選項或命令直接當成 Hashvps 配置，也不要假定不同 SDK 版本的參數完全相同。

第三步：等待狀態明確，再測端點

查看部署狀態，確認版本已達到可測試狀態後，才由呼叫端送出請求。若狀態未完成、端點無法連線或回應不符合預期，記下版本、設定和錯誤訊息。依官方除錯指南逐項排查，不要因為建置工作結束就直接宣布上線。

上線後驗收：成功呼叫之外也要測失敗與連續工作階段

Microsoft Foundry Agent Service 的託管能力與你的應用行為，是兩個不同的驗收面向。前者看平台文件所描述的部署和執行流程；後者必須由團隊以可重現的輸入、帳號與設定親自測試。部署後至少完成一組成功請求、一組失敗請求，以及同一工作階段的連續呼叫。

程式型 Agent 上線後，怎樣確認工作階段正常？
先用同一個工作階段連續提出有關聯的請求，確認應用是否依設計保留必要狀態；再建立新的工作階段，確認不會意外帶入先前內容。若應用會在外部儲存狀態，另行檢查它使用的身分是否有正確權限。不要只憑回應文字判定狀態正常，應保留請求、回應與關聯識別資料，讓問題可以重現。

身份設定則要分清楚「呼叫端能否呼叫端點」和「Agent 能否存取它的依賴」。分別核對呼叫端使用的認證方式，以及應用存取外部資料或服務時所需的身分與權限。用不具必要權限的測試情境確認拒絕行為，再用授權情境確認正常流程。這能避免權限過寬被誤認為部署成功。

追查問題時，先比對版本與部署狀態，再檢查應用日誌及請求追蹤。可參考Hosted Agent 日誌監控文件及Agent 追蹤設定說明，依文件核對可用的診斷方式。記錄測試發生的時間、版本、使用情境與結果，方便把平台層問題和程式邏輯問題分開。

首週觀察後，再決定擴大試點或先回退

首週觀察不是微軟承諾的性能指標，而是團隊自訂的運維檢查。你可以記錄呼叫失敗類型、重試情況、工作階段異常、身分拒絕及版本變更。若某類問題反覆出現，先定位是程式、設定、依賴還是發布流程，再決定是否擴大試用。

部署失敗時，從最後一個已確認正常的環節開始排查：先看版本是否完成發布，再檢查端點與認證，接著比對應用日誌、輸入格式和外部依賴。不要同時更改程式、權限和部署設定，否則很難判斷是哪項修改解決或引入問題。保留可回復的上一個已驗收版本；回退後再重跑成功、失敗與連續工作階段測試。

發布復核清單：

[ ] 本機依賴、啟動入口與部署設定已整理，祕密未寫入程式碼。
[ ] 所選請求協定已按官方執行契約核對，正常與錯誤輸入均有測試。
[ ] 就緒探針與應用啟動狀態相符，未把「可啟動」誤當成「可完成任務」。
[ ] 新版本狀態明確，端點成功呼叫與失敗回應都已驗證。
[ ] 身分權限、工作階段延續與新工作階段隔離已按應用需求檢查。
[ ] 已指定日誌、追蹤、問題紀錄與回退方式，首週觀察結果有人負責檢視。

若清單中仍有未完成項目，先維持小範圍測試並修正；全部通過後，再依團隊的風險門檻擴大試點。

若你目前以本機環境或一般雲端主機驗證 Agent，常見代價是執行環境不一致、部署狀態與應用健康度難以分開，以及憑證和依賴需要自行維護。Foundry Hosted Agents 的驗收應以其託管容器流程為主，Mac 並不是它的替代執行環境；但若你的流程另有 macOS 原生建置、GUI 測試或遠端 Mac 開發需求，租用 Hashvps Mac 可讓這類工作不必綁定個人電腦。若不確定這類工作是否適合遠端 Mac，可先透過聯絡 Hashvps確認需求，再查看Hashvps 方案資訊評估是否需要額外的 Mac 執行資源；若只需 Foundry 託管 Agent，則不必為了部署驗收另外租用 Mac。