把一個 Hugging Face 模型推上正式環境，要做的決定比想像中多：這個架構該配哪個 serving container、目前這個 Region 的 image tag 是哪一版、instance type 的記憶體夠不夠、autoscaling 怎麼設才不會讓 GPU 空轉、CloudWatch alarm 要抓哪些訊號。AWS Machine Learning Blog 在 2026 年 9 月 18 日的文章把這些工作稱為「結構化、可重複」的流程，而這正是 coding agent 擅長的形狀。
問題是，沒被引導的 agent 會自己補上錯的答案。
Agent 出錯的地方不是推理，是事實
AWS 團隊用 Kiro（Auto 或 Claude Fable 5）與 Claude Code（Opus 4.8）做了兩次測試。第一次要求把 Qwen/Qwen3-0.6B 部署成 real-time endpoint，兩個 agent 都先選了 Text Generation Inference（TGI）當 serving container——這個選擇在訓練資料裡很合理，因為 TGI 當了很多年的預設值。但該 Region 可用的 TGI 版本早於 Qwen3 的架構，載不進模型，health check 失敗。Agent 升版、重部署、再失敗，最後才轉向 vLLM，中間每一次失敗都燒掉 GPU 時間。
第二次更安靜：要求部署一個幾週前才發布的多模態 MoE diffusion 模型，agent 確認模型存在，然後照樣寫出以 TGI 為底的腳本——一個純文字生成伺服器，根本沒有這種模型的 backend。這次沒有任何東西大聲報錯，你要等到 endpoint 起不來才會發現。
AWS 的結論值得記住：兩次失敗的根因都是缺少部署事實，不是推理能力不足。Agent 的規劃與除錯都做得不錯，缺的是「最近的 Qwen 模型需要 vLLM」、「Python 3.13 還沒有 ML 生態的 wheel」、「container image 要從已發布的 AWS Deep Learning Containers catalog 解析」這類會比模型權重更快過期的知識。
六個 skill 把決策順序固定下來
解法是把這些事實寫成可編輯的 skill 檔案，而不是期待最新模型自己吸收。文章使用 Hugging Face Skills repo 裡的六個 skill，由 planner 負責編排：先做 AWS context discovery（profile、Region、account、caller identity，全部唯讀），再建立隔離的 Python 環境，接著做 IAM preflight 確認可用的 execution role，然後選 serving image，最後用 production defaults 部署並附上 autoscaling、alarms 與 tags。
其中 hf-cloud-serving-image-selection 的規則寫得很直白：Hugging Face 策展的 DLC 一律優先，vLLM 給 LLM 與 generative reranker、vLLM-Omni 給多模態、TEI 給 embedding 與 cross-encoder reranker；只有在沒有相容的 Hugging Face image 時才退到通用 image，而且不能因為版本比較新就換。Skill 明確禁止憑記憶硬寫 container URI，也禁止預設 TGI。
這其實和我們先前談 coding agent 修 production bug 要先補齊證據 是同一個思路：agent 的產出品質取決於你餵給它的上下文，而不是它的模型有多大。差別在於，修 bug 要補的是當下的現場證據，部署要補的是會隨時間失效的環境事實。
對照表比教學更有用
文章用一張表比較同一個請求在「無 skill」與「有 skill」下的差異，這張表比步驟教學更值得產品團隊看：
- Serving container：無 skill 是 TGI 失敗後才轉 vLLM；有 skill 是在建立任何資源之前就選定 vLLM。
- Image URI：一邊是試錯發現，一邊是從 DLC catalog 解析，並在 registry 查詢被拒時有 fallback。
- Autoscaling：一邊沒有，一邊是 target tracking、1–2 個 instance。
- Monitoring：一邊沒有，一邊是三個 CloudWatch alarm（latency、errors、overhead）。
- Teardown：一邊是「你可以自己跑的腳本」，一邊是跑完並驗證資源真的消失。
最後一列常被忽略。Real-time endpoint 不管有沒有流量都在計費，所以「刪得乾淨」不是收尾動作，而是部署流程的一部分。
什麼時候值得這樣做
這套 skill 是開源、只用 Python 與 AWS CLI，在 macOS、Linux、Windows 上行為一致，預設走 Boto3 而非 SageMaker Python SDK。前置條件也講清楚了：需要 SageMaker AI 權限與 execution role、AWS CLI v2、Python 3.10 到 3.12（3.13 以後不支援），以及支援 skill 的 coding agent。文章示範的是把 Qwen/Qwen3-0.6B 部署到 us-east-1 的單一 ml.g5.xlarge，並提醒先確認 instance quota。
如果你的部署是一次性的、模型很舊、環境很單純，直接照文件做可能更快。但當你要反覆部署不同架構的模型、或團隊裡有多人共用同一套流程時，把「哪個容器、哪個 image、哪些 alarm」寫成可版控的 skill 檔案，比寫在 wiki 或某個人的記憶裡可靠。要注意的是，skill 本身也會過期——文章測試時就綁定在特定 commit f3186efbbc322121eb5d0f31e8a1d669ee961159，這代表你之後得自己決定何時更新，而不是裝了就永遠正確。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。