Google Skills 介紹

過往使用 Google Cloud 遇到問題時的流程是：先搜尋 Google Cloud Documentation，讀完文件、理解產品行為與限制，再自己轉換成 gcloud、kubectl 或 Terraform 指令，最後執行與驗證。這套模式存在了很多年。但隨著 Codex、Claude Code、Gemini CLI 等 Coding Agent 真正進入工程師的 Terminal，一個新的問題逐漸浮現：

如果實際操作 Cloud Infrastructure 的不只工程師，也包含 AI Agent，那麼官方文件是不是也需要一種「給 Agent 使用的版本」？

(本文含聯盟連結。As an Amazon Associate I earn from qualifying purchases.)

Google 在 Cloud Next 2026 推出的官方 Agent Skills repository：Google Skills（github.com/google/skills），正是在回答這個問題。Google 把 Skill 定義為一種為 Agent 提供額外能力與專業知識的開放格式，也把它描述成針對特定技術或任務設計的 agent-first documentation。

換句話說，它不是把 Google Cloud Documentation 再複製一次，而是把產品知識重新整理成 AI Agent 可以理解、判斷，並在適當時機使用的操作知識。

（一）從 13 個 Skills 開始

Google Skills 在 2026 年 4 月 Cloud Next 發表時，規模並不大。第一批只有 13 個 Skills：

• 產品類：AlloyDB、BigQuery、Cloud Run、Cloud SQL、Firebase、Gemini API、Google Kubernetes Engine（GKE）
• Well-Architected 類：Security、Reliability、Cost Optimization
• Recipe 類：Google Cloud Onboarding、Authentication、Network Observability

Google 當時就表示這個 repository 會持續增加新的 Skills。幾個月後回頭看，它已經不是十幾個產品範例，而逐漸形成一套相當完整的 Cloud Operational Knowledge Catalog。

對 Kubernetes、Platform Engineering 與 SRE 工程師來說，GKE 相關 Skills 已經細分到非常實際的工作情境，從 Cluster 建立（gke-cluster-creation）、網路（gke-networking）、可靠性（gke-reliability）、觀測（gke-observability）、平台安全（gke-platform-security）、儲存（gke-storage）、升級維護（gke-upgrades），到上線前的 Production Readiness 審查（gke-productionize），都各自是獨立的 Skill。

甚至開始把同一個領域拆成不同的操作責任。例如 gke-cost-analysis 負責回答：

• 哪個 Cluster 花費最高？
• 哪個 Namespace 成本最高？
• 為什麼某個 Workload 成本突然上升？
• CPU / Memory Request 是否遠高於實際使用量？

它會引導 Agent 使用 BigQuery Billing Export、GKE Cost Allocation、kubectl top、gcloud billing 進行分析。但如果問題變成「幫我把這些成本真正降下來」，它就會把工作交給另一個 Skill：gke-cost-optimization，處理 Rightsizing、VPA、Spot VM、ResourceQuota、Machine Type、Committed Use Discount。

這個細節很重要。它代表 Google 並不是把 Skill 當成「一大包 Prompt」，而是在建立 Operational Knowledge Boundary：不同 Skill 各自有清楚的責任範圍。

（二）Skill 並不是另一份 README

第一次看到 Agent Skill，很容易覺得「不就是 Markdown 文件嗎？」從檔案格式來看的確很像：一個 Skill 通常就是一份 SKILL.md，再搭配 references、scripts、assets 等輔助資料夾。

真正的差異不在檔案格式，而在 內容的寫法。傳統文件告訴人的是：這個產品是什麼、有哪些 Feature、API 怎麼使用、CLI 參數有哪些。Skill 告訴 Agent 的則是另一組問題：

• 什麼情況應該使用這個 Skill，什麼情況不應該使用？
• 需要先取得哪些資訊，應該按照什麼順序分析？
• 哪些操作是 Read-only，哪些操作會修改 Production？
• 遇到某種結果下一步該做什麼，什麼時候應該轉交另一個 Skill？

以 gke-cost-analysis 為例，它除了說明如何進行 GKE 成本分析，還特別註明：啟用 GKE Cost Allocation 會修改 Cluster，不是唯讀操作，必須先取得使用者明確確認。

這就是典型的 Agent Operational Knowledge。它回答的已經不是「這個 command 怎麼用？」，而是「在什麼條件下，可以安全地使用這個 command？」對 SRE 來說，這兩者差別非常大。

（三）從 Documentation 到 Agent-readable Knowledge

Google Skills 真正值得注意的地方，不是 GitHub Star 數量，而是 Google 正在把 Vendor Documentation 先整理成 Operational Knowledge，再封裝成 Agent Skill。

過去的路徑是工程師自己讀文件、自己理解，再自己下 gcloud 或 kubectl。未來的路徑則可能是：工程師把需求交給 Codex、Claude Code 或 Gemini CLI，Agent 載入對應的 Google Skill 取得 Google Cloud 的操作知識，再轉成 gcloud、kubectl 或 Terraform 執行。

圖 1：工程師的工作流程，從自行閱讀文件轉向由 Agent 透過 Skill 取得操作知識

這並不代表工程師不需要理解技術，恰恰相反。工程師的角色會逐漸從 Command Executor，往 Architecture Designer、Risk Reviewer、Operational Decision Maker、Agent Supervisor 移動。AI Agent 負責搜尋、比對、產生 Command、分析 Metrics、產生 YAML、整理 Troubleshooting Path；工程師則負責判斷 Context、確認風險、決定 Change、驗證結果，並承擔 Production Responsibility。

這其實非常接近 SRE 本來就強調的 Engineering Model。

（四）Google Skills 不再只服務 Google Agent

另一個值得注意的訊號是：Google Skills 已經不只是 Gemini 的知識庫。官方 repository 直接提供 Claude Code、Codex、Antigravity CLI 等不同 Agent Harness 的安裝方式。例如 Codex 只要一行：

codex plugin marketplace add google/skills

就能加入 Google 的 Plugin Marketplace，再從 /plugins browser 安裝需要的 plugin。

Google 自己有 Gemini，卻仍然選擇讓產品知識能被其他 Agent 使用。這代表 Skill 的價值不綁定某一個 Model：同一套 Skill 可以同時被 Codex、Claude Code、Gemini CLI 與其他 Agent 使用，底層 Model 可以不同，產品操作知識則可以重複利用。

如果這種模式持續發展，Skill 很可能成為 AI Engineering Stack 裡獨立的一層：由下往上依序是 API / CLI / Infrastructure、MCP / Tools、Skills、Agent，最上層才是 LLM。

圖 2：Skill 在 AI Engineering Stack 中的位置，Skills 負責 Know How，MCP / Tools 負責 Do It

Skill 負責 Know How，MCP 或 Tool 負責 Do It。這個區分值得 DevOps / SRE 特別注意。

（五）對 DevOps / SRE 的實際價值：企業自己的 Skill Repository

對 SRE、DevOps Engineer 或 Platform Engineer 而言，Google Skills 最值得研究的地方反而不是 Google Cloud 本身，而是：

Google 正在示範 Operational Knowledge 應該如何封裝。

很多公司的 SRE Knowledge 散落在 Confluence、Wiki、Google Docs、Slack、Git Repository、Runbook，以及 Senior Engineer 的腦袋裡。例如：Kafka latency 突然增加怎麼查？OpenShift Upgrade 前需要確認什麼？Production Deployment Failure 如何 rollback？金融系統 Change Management 有哪些限制？Incident 發生後 Postmortem 怎麼寫？這些才是企業真正有價值的工程知識。以前企業做的是 Internal Documentation，下一步很可能是 Internal Agent Skills：一個專屬的 Skill Repository，裡面依責任切分成 kubernetes-production、incident-response、kafka-troubleshooting、openshift-upgrade、change-management、financial-compliance、postmortem 等 Skill。

這時候 Codex 或 Claude Code 就不只知道「Kubernetes 一般應該怎麼做」，還會知道「這家公司的 Kubernetes Production Environment 應該怎麼做」。兩者價值完全不同。

對金融、電信、製造這類高度重視 Governance、Security、Change Management、Compliance、Audit 的環境而言，這可能比「讓 AI 自己操作 Production」更實際。第一階段真正要解決的不是「AI 能不能執行 kubectl？」，而是「AI 知不知道我們公司的 kubectl 應該怎麼用？」

（六）SRE Runbook 是下一批最適合 Skill 化的內容

企業內部最適合轉成 Agent Skill 的內容之一，就是 SRE Runbook。傳統 Runbook 通常只有診斷步驟，例如 Node NotReady 時依序檢查 kubelet、Disk Pressure、Memory Pressure、CNI 與 Node Events。轉成 Skill 之後，還會多出 Trigger Conditions、Required Context、Read-only Checks、Diagnostic Sequence、Risk Classification、Escalation Conditions、Allowed Actions、Forbidden Actions。Google 自己的 gke-node-notready 就是這樣設計的：先排除升級、修復、縮容造成的「預期中 NotReady」，只做唯讀診斷，修正指令交給人執行，不自動 drain 或重建 Node。

最後的流程會變成：Alert 觸發後由 Agent 載入對應的 SRE Skill，透過 kubectl、Monitoring 與 Logs 完成診斷，把結果與建議的修正方式交給工程師審核，經過 Human Approval 後才進入 Remediation。

圖 3：Runbook 轉成 SRE Skill 後，Agent 負責診斷，修正前必須經過人工核准

這比單純把 Runbook 丟進 RAG Knowledge Base 精細得多。因為 Skill 不只是 Knowledge Retrieval，它還包含：When to use、How to reason、What to check、What not to do、When to stop、When to ask。

結語：文件開始出現第二種讀者

過去 Software Documentation 的讀者只有一種：Human。現在開始出現第二種：AI Agent。未來成熟的產品知識體系，可能同時包含 Human Documentation、API Documentation、Agent Skills 與 MCP / Tools。

現在看起來 Google Skills 只是一個 GitHub repository。但如果 Coding Agent 持續進入日常 Engineering Workflow，幾年後回頭看可能會發現：Google Skills 代表的不是另一種 Documentation Format，而是 Software Vendor 開始正式把 AI Agent 視為產品介面的使用者。

對 DevOps / SRE 而言，更值得思考的問題不是「要不要安裝 Google Skills？」，而是：

我們公司累積十年的 Operational Knowledge，什麼時候開始整理成自己的 SRE Skills？

系列預告：《從 Google Skills 建立企業自己的 SRE Skill Repository》

常見問題（FAQ）

Google Skills 和 MCP 差在哪？兩個都要裝嗎？

Skill 提供的是 Know How：什麼情況該用、依什麼順序判斷、哪些操作不能做；MCP 或 Tool 提供的是 Do It：實際呼叫 API、讀寫資源。兩者是上下層關係，不是二選一。只用 Skill 時，Agent 會透過 kubectl、gcloud 等 CLI 執行；搭配 MCP 時，Skill 會指引 Agent 呼叫對應的 MCP Tool。Google Skills 的 Plugin 就是 Skills 加 MCP Server 的組合包。

Agent Skill 和 README、官方文件差在哪？

傳統文件告訴人產品是什麼、API 與 CLI 參數怎麼用；Skill 則告訴 Agent 什麼情況該用、什麼情況不該用、需要先取得哪些資訊、依什麼順序分析、哪些操作是唯讀、哪些會修改 Production，以及何時轉交另一個 Skill。例如 gke-cost-analysis 明確標註啟用 Cost Allocation 會修改 Cluster，必須先取得使用者確認。

Google Skills 只能搭配 Gemini 使用嗎？Claude Code 和 Codex 可以用嗎？

可以。Google Skills 採用開放的 Agent Skills 格式，以 Apache 2.0 授權釋出。官方 README 提供 Claude Code（claude plugin marketplace add google/skills）、Codex（codex plugin marketplace add google/skills）與 Antigravity CLI 的安裝方式，也可以用 npx skills add google/skills 挑選個別 Skill 安裝到指定的 Agent。

企業內部 Runbook 直接放進 RAG 知識庫，和改寫成 Skill 差在哪？

RAG 解決的是找得到資料；Skill 還定義了觸發條件、必要 Context、唯讀檢查、診斷順序、升級條件，以及允許與禁止的操作。例如 Skill 可以明確規定 Agent 不得 reset Kafka offset、只能提出指令給人執行，這類行為邊界在 RAG 裡只是一段文字，Agent 不一定會當成約束。對重視 Change Management 與 Audit 的環境，Skill 化的 Runbook 較容易審核與驗收。

延伸閱讀

• Loop Engineering（本站 AI Agent 系列）
• Uber AI Agent 成本治理（本站 AI Agent 系列）
• google/skills（GitHub 官方 repository）
• Google Cloud Blog：Announcing Google's Official Skills Repository

📚 延伸閱讀・Kindle 電子書（2026 年 9 月推出）

Site Reliability Engineering, 2nd Edition

Google SRE 經典的第二版。第一版著重 Google 內部實踐，第二版新增了社會技術基礎、持續備戰、湧現式可靠性，以及專章討論 AI 與 SRE 的關係：這正是第一版沒有、也是現在最需要的部分。

在 Amazon 訂購 Kindle 版 →