Microsoft Azure Developer Community 在 2026 年 6 月 11 日介紹 Foundry Hosted Agents 的 source-code deployment。這項 preview 功能讓開發者可以把 agent 以 '.zip' source package 上傳部署，而不一定要先建立和推送 container image。
這個更新看似只是部署方式多一個選項，但對 agent 開發流程很重要。很多團隊在 prototype 階段真正想做的，是快速修改 agent logic、測試工具調用、觀察執行紀錄，再逐步收緊權限和 runtime。若每次都要先處理 container build、registry、image tag 和部署流程，內循環會變慢。
Microsoft 文件描述的 lifecycle 很清楚：package、create 或 update、poll until active、invoke。source-code path 使用 'code_configuration'，而 container path 使用 'container_configuration'；兩者在同一版本上互斥。這代表團隊可以按成熟度選路徑：早期用 source-code zip 加快迭代，之後在需要完整 runtime 控制時再轉 container。
值得留意的是 dependency resolution。'remote_build' 讓 Agent Service 在 provisioning 時根據 requirements.txt 或 .NET project file 安裝依賴，適合小型上傳和初期開發；'bundled' 則把預建依賴一同放進 zip，較適合私有依賴、可重現 build 或 server-side restore 不穩定的場景。
這個方向也反映生產級 AI agent 正進入更清晰的部署分層。模型選擇和 agent framework 只是其中一部分，真正上線還需要身份、權限、日誌、狀態、版本、回滾和資源控制。Hosted Agents 的 source deployment 讓較多團隊可以先跨過 deployment friction，把注意力放在 agent 行為和驗收上。
不過，source-code deployment 不等於可以忽略工程治理。開發者仍要處理 dependency pinning、secret 管理、角色權限、成本估算、logs 是否含敏感資料，以及 preview API 可能變更。越容易部署，越需要有清楚的 promotion 和審批流程。
整體而言，Microsoft 這次更新顯示 agent runtime 競爭正在從「能否跑起來」走向「能否用軟件工程方式持續部署」。當 agent 可以用 source package、CLI、VS Code 或 REST API 進入受管 runtime，企業就更容易把 AI workflow 納入既有 CI/CD 和營運治理。
