開發工具與代理平台
Foundry Toolkit 1.6.13 接入非 ACR 私有映像庫，並更換 Windows ML 執行階段
新版 VS Code 工具可從具連線設定的私有容器登錄部署託管代理，也加入 AMD NPU 版 Fara 7B 與 Aion 量化 adapter。Windows ML 升至 `windowsml` 2.3，既有專案必須檢查執行供應器及相依套件。
Microsoft 在 9 月 16 日發布 Foundry Toolkit for VS Code 1.6.13，把代理部署、端側模型與微調產物的幾條路徑一起更新。最具部署影響的變化，是託管代理現在可選擇預先建置、存放於非 Azure Container Registry 的私有映像；前提是 Foundry 專案已建立相符的 registry connection。Microsoft 的外部登錄文件描述以 OIDC 交換短效權杖，避免把使用者名稱、密碼或長效 access token 留在設定中。
這不代表任何私有映像都能直接執行。Foundry 的託管代理仍要求 `linux/amd64` 容器；網路封閉、映像拉取權限及專案身分的 RBAC 也要另外驗證。對受管制團隊而言，新路徑的價值是可沿用 JFrog Artifactory 或自架 Docker Distribution 等既有供應鏈，不必為了代理平台複製映像到 ACR，但 CI 必須新增 OIDC、映像簽章與失敗拉取的測試。
端側部分新增 Fara 7B 的 VitisAI INT4 版本，支援 Windows x64、AMD NPU 與影像輸入；Aion 微調流程則能下載 `quantized_adapter.safetensors`，同時保留舊的 `adapter_model.safetensors`。後者還要求套件內含配套模板，因此只搬 adapter 檔案未必足以重建工作流。
需要升級測試的是 Windows ML：工具鏈改用 `windowsml` 2.3 與更新後的 execution providers，並移除對 Windows App SDK 的必要依賴。更新紀錄明確指出既有專案需要調整，而不是完全無痛替換。1.6.13 也修正 Agent Inspector 在回應完成後遺失輸出或錯誤、以及工具批准與登入步驟中斷 continuation 的問題。工程團隊接下來應鎖定擴充套件版本，分別回歸本機 NPU、adapter 下載及私有映像部署；官方尚未提供這些新路徑的端到端效能或失敗率數據。