Google 公開了 5 種 AI Agent（智慧代理人） Skill 設計模式。
這是 Google 工程師研究整個 Skill 開發生態系統，從中濃縮出來的 5 條黃金法則。
本文完全忠於原文翻譯整理，開發者們趕緊學起來：
提到 SKILL.md，開發者往往會專注於格式：確保 YAML 格式正確無誤、建構目錄結構以及遵循規範。
但是，隨著超過 30 種 Agent 工具（如 Claude Code、Gemini CLI 和 Cursor）在同一套佈局上實現標準化，格式問題實際上已經不存在了。
現在的挑戰在於內容設計。
規範雖然解釋了如何打包一個 Skill，但對於如何建構其內部的邏輯卻未提供任何指導。
例如，一個封裝 FastAPI 約定的 Skill 與一個包含四個步驟的文件處理管線運作方式截然不同，儘管它們的 SKILL.md 檔案在外觀上看起來一模一樣。
透過研究生態系統中（從 Anthropic 的程式庫到 Vercel 和 Google 的內部指南）是如何建構這些 Skill 的，我們發現了 5 種反覆出現的設計模式，它們可以幫助開發者更好地建構 Agent。
每一種模式，都附帶可執行的 ADK（Agent Development Kit，智慧代理人開發套件）程式碼：
工具包裝器：讓你的 Agent 瞬間成為任何程式庫的專家
生成器：從可複用的模板生成結構化文件
審查器：根據嚴重程度對照清單對程式碼進行評分
反轉：Agent 在執行操作前先對你進行訪談
管線：強制執行帶有檢查點的嚴格多步驟工作流
模式 1：工具包裝器
工具包裝器為你的 Agent 提供關於特定程式庫的按需情境資訊。
你無需將 API 約定硬編碼到系統提示詞中，而是將它們打包成一個 Skill。你的 Agent 只有在實際使用該技術時才會載入這個情境資訊。
這是最容易實現的模式。SKILL.md 檔案會監聽使用者提示詞中特定程式庫的關鍵字，從 references/ 目錄動態載入你們的內部文件，並將這些規則作為絕對真理來應用。
這正是你將團隊的內部編碼規範或特定框架最佳實踐直接分發到開發者工作流中所使用的機制。
以下是一個工具包裝器的範例，它教導 Agent 如何編寫 FastAPI 程式碼。請注意，指令中明確告訴 Agent 只有在開始審查或編寫程式碼時，才去載入 conventions.md 檔案：
模式 2：生成器
工具包裝器側重於應用知識，而生成器則用於強制執行一致的輸出。
如果你正苦惱於 Agent 每次執行都會產生不同的文件結構，生成器可以透過精心編排的「填空」過程來解決這個問題。
它利用了兩個可選的目錄：assets/ 用於存放你的輸出模板，而 references/ 用於存放風格指南。
指令在這裡充當專案經理的角色。它們告訴 Agent 載入模板、閱讀風格指南、向使用者詢問缺失的變數，並填充文件。
這對於生成可預測的 API 文件、標準化提交訊息或搭建專案架構非常實用。
在這個技術報告生成器的範例中，Skill 檔案本身並不包含實際的排版或語法規則。它僅僅負責協調這些資產的檢索，並強制 Agent 逐步去執行它們：
模式 3：審查器
審查器模式將「檢查什麼」與「如何檢查」分離開來。
你無需編寫冗長的系統提示詞來詳細說明每一個程式碼異味，而是將模組化的評分標準存放在 review-checklist.md 檔案中。
當使用者提交程式碼時，Agent 會載入此清單並有條理地對提交內容進行評分，按嚴重程度將其發現進行分組。
如果你將 Python 程式風格檢查清單替換為 OWASP 安全檢查清單，你就可以使用完全相同的 Skill 基礎設施，獲得一個截然不同且高度專業的稽核過程。
這是一種非常有效的方法，可以自動化 PR 程式審查，或者在人工查看程式碼之前捕捉到漏洞。
下面的程式審查器 Skill 展示了這種分離機制。指令保持靜態不變，但 Agent 會從外部清單動態載入特定的審查標準，並強制輸出基於嚴重程度的結構化結果：
模式 4：反轉
Agent 往往本能地想要立刻進行猜測並生成結果。
反轉模式顛覆了這種動態邏輯。不再是使用者驅動提示詞而 Agent 去執行，而是由 Agent 扮演面試官（訪談者）的角色。
反轉模式依賴於明確的、不可妥協的閘門指令（例如「在所有階段完成之前，切勿開始建構」），以強制 Agent 首先收集情境資訊。
它會按順序提出結構化問題，並等待你的回答，然後再進入下一個階段。
在全面掌握你的需求和部署約束條件之前，Agent 會拒絕合成最終的輸出結果。
想要了解實際效果，可以看看下面這個專案規劃器 Skill。此處的關鍵要素是嚴格的階段劃分和明確的把關提示詞，它能夠阻止 Agent 在收集完所有使用者回答之前合成最終計畫：
模式 5：管線
對於複雜的任務，你無法承受遺漏步驟或無視指令所帶來的後果。
管線模式強制執行一個帶有硬性檢查點、嚴格按順序執行的工作流。
指令本身即作為工作流定義。透過實現明確的菱形閘門條件（例如，要求在從生成文件字串進入最終組裝階段之前必須得到使用者核准），管線確保了 Agent 無法繞過複雜任務並直接給出一個未經充分驗證的最終結果。
此模式利用了所有可選目錄，僅在需要的特定步驟才提取相應的參考文件和模板，從而保持情境視窗的乾淨整潔。
在這個文件處理管線範例中，請注意那些明確的閘門條件。我們明確禁止 Agent 進入組裝階段，除非使用者先確認了上一步生成的文件字串：
每種模式都解決了不同的問題。使用下圖這個決策樹來為你的使用案例尋找正確的模式：
這些模式並不是相互排斥的。它們可以進行組合。
一個管線 Skill 可以在最後包含一個審查器步驟，以複查其自身的工作。
一個生成器可以在最開始依賴反轉模式收集必要的變數，然後再填充它的模板。
得益於 ADK 的 SkillTools 和漸進式揭露機制，你的 Agent 只會在執行時為它實際需要的特定模式去消耗情境 token。
停止嘗試將複雜且脆弱的指令全部塞進單一的系統提示詞中吧。
拆分你的工作流，應用正確結構的設計模式，並建構可靠的 Agent。
Agent Skills 規範是開源的，並已在整個 ADK 生態系統中得到原生支援。
你已經了解了如何進行格式打包。現在你也掌握了如何設計其內容。現在，去使用 Google Agent Development Kit 建構更聰明的 Agent 吧。
參考資料：