Google 官方 skills 儲存庫於 2026 年 3 月底開源,十月底累積 21,540 顆星標,內含 175 個 Agent Skills,覆蓋 Google Cloud、Ads、Analytics 與開發者工具,全部以 Markdown 撰寫,代理可依需求載入。

Google skills 儲存庫 README 開頭畫面,顯示 Agent Skills 標題、skills.sh 安裝徽章,以及 npx skills add google/skills 的安裝指令段落

Google Skills 是什麼?

Google Skills 是 Google 官方維護的 Agent Skills 儲存庫,把雲端與廣告產品的操作知識寫成 Markdown 技能檔,供 AI 代理在需要時載入執行。

儲存庫建立於 2026 年 3 月 31 日,描述為「Agent Skills for Google products and technologies」,明確把 Google Cloud 列為主要涵蓋範圍。專案採 Apache 2.0 授權,主要語言標示為 Python,但實際內容主體是 Markdown 技能文件與驗證腳本,Python 部分約 1.35 MB,負責校驗、部署與同步。

維護方式帶有明顯的企業特徵。全部約 486 次提交中,442 次來自名為 cloud-ix-copybara 的自動同步帳號,其餘由少數 Google 員工提交,公開列出的貢獻者共八位。這種結構說明技能內容在內部流程中生產,再經自動化管道同步到公開儲存庫,而非依靠社群提交。最近七日的 32 次提交集中在 GKE 可觀測性指標文件與 Application Integration 新技能,更新節奏接近每日。

這個儲存庫包含哪些技能內容?

175 個技能分佈於五個目錄,雲端佔 154 個,廣告 14 個,開發者工具 3 個,分析與身分各 2 個,另附 17 個可安裝外掛。

雲端目錄是整個專案的重心。內容涵蓋 GKE 的叢集建立、升級、網路、儲存與疑難排解,BigQuery 的查詢撰寫與成本優化,AlloyDB、Spanner、Cloud SQL 與 Bigtable 的基礎操作,以及 Cloud Run、Firebase 與 IAM 的常見流程。另有整組 Agent Platform 技能,處理模型部署、提示管理、RAG 引擎、評估迴圈與微調,對應 Gemini API 在企業環境的落地需求。

廣告目錄處理 Google Ads API 與 Mobile Ads SDK 的整合,包含 Data Manager API 的受眾與事件上報、橫幅與插頁廣告的實作,以及 SDK 整合驗證。開發者目錄只有三項,卻值得單獨留意:技能搜尋入口、把舊程式碼庫遷移到安全 Rust 的流程,以及 Google 開發者知識的檢索方式。身分目錄則處理 DPoP 採用與 Sign in with Google 的整合架構。

README 同時列出外部延伸技能,指向 Android、Flutter、Dart、Firestore、Google Maps Platform 與 Agent Development Kit 各自的儲存庫。這種分拆讓單一儲存庫不必承擔全部產品線,代價是使用者必須跨多個來源安裝,版本一致性需要自行確認。

Agent Skills 的檔案結構如何運作?

每個技能是獨立目錄,內含 SKILL.md,以 YAML 前置資料描述名稱、版本、分類與觸發條件,並在描述中寫明何時使用、何時應跳過。

以技能搜尋入口為例,前置資料包含名稱、版本 1.1.0、分類 MultiProductSolutions,以及一段刻意寫得具體的描述。描述先說明適用情境,例如開發者正在選擇服務執行位置、資料庫、身分驗證或模型推論方案;再補上排除條件,例如技術棧已確定使用其他供應商且未提及 Google 產品。這種「何時用」加「何時不用」的雙向寫法,讓代理在載入前就能判斷是否相關。

真正的內容放在目錄外的索引檔。專案根目錄的 index.json 約 115 KB,列出 175 個技能的名稱、描述與入口網址,技能本身則在觸發後才讀取。這種分層設計控制了上下文成本,代理平時只需知道目錄存在,真正需要時再取用單一技能,避免把整份產品手冊塞進提示。

索引檔的使用方式也寫進技能指示。文件提醒直接抓取會因輸出長度限制而被截斷,且截斷後的預覽按字母排序,容易誤判產品數量,因此要求以原樣下載並用 jq 之類的工具先縮小範圍。這類細節反映撰寫者理解代理實際執行時的失敗模式,而不只是描述理想流程。

如何安裝與更新 Google Skills?

執行 npx skills add google/skills 後選擇技能、目標代理與安裝範圍即可;日後以 npx skills update 更新,並可一併移除已淘汰的技能。

安裝流程依賴社群工具 skills.sh,指令為 npx skills add google/skills。執行後會依序詢問要安裝哪些技能、要配置哪些代理,以及安裝範圍屬於專案層或全域層。環境若沒有 npx,官方建議先安裝含 npm 的 Node.js,這是唯一的硬性前置條件。更新時執行 npx skills update,工具會提供移除過時技能的選項。

外掛路線則針對特定代理設計。Claude Code 用戶先加入外掛市場,再安裝指定外掛;Codex 用戶在命令列加入同一個市場後,從外掛瀏覽介面挑選;Antigravity CLI 直接以外掛網址安裝。三條路線共用同一份技能內容,差別只在打包與分發方式。

外掛清單本身是一份獨立的中介資料,名為 google-plugins,版本 0.0.1,共 17 個項目,涵蓋 AlloyDB、BigQuery、Cloud SQL 三種資料庫引擎、Dataproc、Looker、Spanner 與 Cloud Storage 等。清單中的每個外掛都指向 GoogleCloudPlatform 旗下的獨立儲存庫,並鎖定具體版本標籤,例如 AlloyDB 外掛指向 0.2.0 版。技能留在主儲存庫,外掛放在外部,這種安排讓各產品線能獨立發版,同時維持統一的安裝入口。

它與其他代理技能格式有何異同?

它沿用社群共通的 SKILL.md 格式,同一份內容可餵給多個代理;差別在官方把企業級產品知識與外掛清單一併納入,並以自動化流程持續同步。

Agent Skills 已形成跨廠商的檔案慣例:單一目錄、一份 SKILL.md、YAML 前置資料帶名稱與描述,描述中寫明觸發條件。Google 的實作完全遵循這套慣例,因此同一個技能目錄可以放進 Claude Code、Codex、Cursor 或自建代理,不需要為各平台改寫。這種可攜性是它能在七個月內累積兩萬餘顆星標的結構性原因。

與模型上下文協定相比,兩者解決的問題不同。協定提供工具與資料的連接方式,技能提供的是流程知識,說明在什麼情境下該依序呼叫哪些工具、產出什麼格式。Google 在外掛層把兩者綁在一起,README 明言外掛同時包含技能與 MCP 伺服器,於是安裝一個外掛就同時取得操作知識與執行通道。

與其他高星技能集合相比,定位差異在深度。社群技能庫多半集中在編碼習慣、設計品味或提示技巧,單一技能數百字;Google 的技能直接對應具體產品與 API,篇幅更長,且與雲端主控台的實際欄位綁定。這種深度換來的是即時可用性,代價是維護成本高,需要持續跟上產品改版。

星標與開發數據反映什麼?

儲存庫累積 21,540 顆星標、1,821 個分支與 142 位關注者,七日內提交 32 次,主要語言為 Python,採 Apache 2.0 授權。

21,540Stars
1,821Forks
175技能數
17外掛
486累積提交
Apache 2.0授權條款

Google skills 儲存庫首頁頂部,顯示 google/skills 專案名稱、兩萬一千餘顆星標與分支數,以及 Agent Skills for Google products and technologies 的專案描述

星標與分支的比例值得注意。約 12 比 1 的星標對分支比,低於一般教學型專案常見的 20 比 1,說明相當比例的使用者不是只按讚,而是實際複製或分叉準備改造。對照專案定位,這個數字合理:企業團隊評估技能時,通常會先分叉到內部儲存庫做調整,再決定是否長期跟隨上游。

貢獻者結構則是另一面。公開列出的八位貢獻者與 486 次提交並不相稱,因為絕大多數提交來自同步機器人。這種模式在企業開源專案中常見,好處是內容品質與內部版本一致,缺點是外部回報的問題修補速度取決於內部排程。目前 22 個未結問題,相對於兩萬餘顆星標的關注度,屬於偏低水平。

Google skills 儲存庫的提交記錄頁面,顯示近期新增 Application Integration 技能與 GKE 可觀測性指標文件的提交標題與時間

提交頻率的變化也提供訊號。最近一批提交集中於單一產品線的文件補強,例如把 kube-apiserver 的 HTTP 存取日誌欄位、API 優先級與公平性指標寫進可觀測性技能。這種逐項補齊的做法顯示維護者正把內部除錯經驗轉成可重複使用的判斷路徑,而不是補充泛泛的產品介紹。

使用時有哪些限制與風險?

技能以英文撰寫並指向 Google Cloud 付費服務,部分流程會要求安裝命令列工具;企業採用前須確認權限邊界、資料落地與版本漂移風險。

第一個限制是環境依賴。多數技能假設使用者具備可用的雲端專案與命令列環境,部分流程需要安裝 gcloud 命令列工具。專案在十月的提交中特別加入一項改動,要求代理在安裝 gcloud 前先取得確認,避免代理在未經同意的情況下改動開發環境。這項設計值得其他技能庫參考。

第二個限制是版本漂移。技能內容與主控台欄位、指標名稱、API 版本緊密綁定,產品一旦改版,文件就可能失準。專案以每日級別的提交節奏維持同步,但使用者從安裝到實際執行之間若間隔數週,仍可能遇到描述與介面不符的情況。建議在關鍵流程前先確認技能版本,並以官方文件交叉驗證。

第三個限制屬於安全層面。技能本質是給代理的指示,會影響它後續的動作順序與工具選擇,因此引入外部技能等同引入一段可執行的操作邏輯。企業在導入前應逐份檢視技能內容,特別是涉及 IAM 政策、服務帳號與資料匯出的部分,並在受控專案中先行測試。外掛清單雖鎖定版本標籤,來源仍分散於多個儲存庫,供應鏈審查需一併涵蓋。

出處連結有哪些?

原始碼位於 GitHub 的 google/skills 儲存庫,安裝入口為 skills.sh 的對應頁面,完整技能清單可從根目錄 index.json 取得。

專案位址為 https://github.com/google/skills,README 內的安裝段落與技能清單是主要參考。技能索引位於 https://github.com/google/skills/blob/main/index.json,可直接以命令列下載後過濾。外掛清單則放在 .claude-plugin/marketplace.json,內含 17 個外掛的來源儲存庫與版本標籤,適合在評估供應鏈時逐項核對。

總結:Google Skills 適合哪些團隊?

已在採用 Google Cloud 並以 Claude Code、Codex 或 Antigravity 開發的團隊最適合;技術棧不在 Google 生態內的團隊,實際收益有限。

這個儲存庫的價值不在技能數量,而在把內部除錯經驗轉成代理可讀的判斷路徑。GKE 的疑難排解技能不是產品介紹,而是列出指標、查詢語句與判斷順序,這種內容只有在實際處理過故障之後才寫得出來。175 個技能的規模,本質是一份持續更新的維運手冊。

對使用 Google Cloud 的團隊,安裝成本低,先行試用單一產品線的技能再擴大範圍是合理路徑。對其他技術棧的團隊,這個專案更適合當作技能撰寫的範本,觀察它如何在描述中界定適用與排除條件、如何用索引檔控制上下文成本,以及如何用確認機制約束代理動作。這幾項設計與平台無關,可以直接搬到自家的技能庫。