企業級 Skills

本指南適用於需要在組織內治理 Agent Skills 的企業管理員與架構師。內容涵蓋如何大規模審核、評估、部署及管理 Skills。如需撰寫指引，請參閱最佳實務。如需架構詳細資訊，請參閱 Skills 概述。



安全審查與審核

在企業中部署 Skills 需要回答兩個不同的問題：

1. Skills 整體而言是否安全？ 請參閱概述中的安全考量一節，以了解平台層級的安全詳細資訊。
2. 如何審核特定的 Skill？ 請使用下方的風險評估與審查檢查清單。



風險層級評估

在核准部署之前，請根據以下風險指標評估每個 Skill：



審查檢查清單

在部署任何來自第三方或內部貢獻者的 Skill 之前，請完成以下步驟：

1. 閱讀所有 Skill 目錄內容。 審查 SKILL.md、所有參照的 markdown 檔案，以及任何隨附的指令碼或資源。
2. 驗證指令碼行為符合所述用途。 在沙箱環境中執行指令碼，並確認輸出與 Skill 的描述一致。
3. 檢查是否有對抗性指令。 尋找指示 Claude 忽略安全規則、對使用者隱藏動作、透過回應外洩資料，或根據特定輸入改變行為的指令。
4. 檢查是否有外部 URL 擷取或網路呼叫。 在指令碼與指令中搜尋網路存取模式（http、requests.get、urllib、curl、fetch）。
5. 驗證沒有硬編碼憑證。 檢查 Skill 檔案中是否有 API 金鑰、權杖或密碼。憑證應使用環境變數或安全的憑證儲存區，絕不應出現在 Skill 內容中。
6. 識別 Skill 指示 Claude 調用的工具與命令。 列出所有 bash 命令、檔案操作與工具參照。當 Skill 同時使用檔案讀取與網路工具時，請考量其綜合風險。
7. 確認重新導向目的地。 如果 Skill 參照外部 URL，請驗證它們指向預期的網域。
8. 尋找讀取敏感資料後將其寫入、傳送或編碼以供外部傳輸的指令，包括透過 Claude 的對話回應。



部署前評估 Skills

如果 Skills 觸發不正確、與其他 Skills 衝突或提供不良指令，可能會降低代理程式的效能。在任何正式環境部署之前，都應要求進行評估。



評估項目

在部署任何 Skill 之前，請針對以下面向建立核准關卡：



評估要求

要求 Skill 作者提交評估套件，每個 Skill 包含 3 至 5 個代表性查詢，涵蓋 Skill 應觸發、不應觸發以及模糊邊緣案例的情況。要求在您組織使用的各個模型（Haiku、Sonnet、Opus）上進行測試，因為 Skill 的效果會因模型而異。

如需建立評估的詳細指引，請參閱最佳實務中的評估與迭代。如需一般評估方法論，請參閱開發測試案例。



使用評估結果進行生命週期決策

評估結果可指示何時採取行動：

• 觸發準確度下降： 更新 Skill 的描述或指令
• 共存衝突： 合併重疊的 Skills 或縮小描述範圍
• 輸出品質持續偏低： 重寫指令或新增驗證步驟
• 多次更新後仍持續失敗： 棄用該 Skill



Skill 生命週期管理



大規模組織 Skills



召回限制

作為一般準則，請限制同時載入的 Skills 數量，以維持可靠的召回準確度。每個 Skill 的中繼資料（名稱與描述）會在系統提示中競爭注意力。當啟用過多 Skills 時，Claude 可能無法選擇正確的 Skill，或完全遺漏相關的 Skills。請使用您的評估套件在新增 Skills 時衡量召回準確度，並在效能下降時停止新增。

請注意，API 請求每次最多支援 8 個 Skills（請參閱透過 API 使用 Skills）。如果某個角色需要的 Skills 數量超過單一請求所支援的上限，請考慮將範圍較窄的 Skills 合併為較廣泛的 Skills，或根據任務類型將請求路由至不同的 Skill 集合。



從具體開始，之後再整合

鼓勵團隊從範圍較窄、針對特定工作流程的 Skills 開始，而非廣泛、多用途的 Skills。當您的組織中出現共通模式時，再將相關的 Skills 整合為基於角色的套組。

範例進程：

• 開始：formatting-sales-reports、querying-pipeline-data、updating-crm-records
• 整合：sales-operations（當評估確認效能相當時）



命名與編目

在您的組織中使用一致的命名慣例。最佳實務中的命名慣例一節提供了格式指引。

為每個 Skill 維護內部登錄，包含：

• 用途：Skill 支援的工作流程
• 負責人：負責維護的團隊或個人
• 版本：目前部署的版本
• 相依性：所需的 MCP 伺服器、套件或外部服務
• 評估狀態：最近一次評估的日期與結果



基於角色的套組

依組織角色將 Skills 分組，讓每位使用者的現行 Skill 集合保持聚焦：

• 銷售團隊：CRM 操作、銷售管道報告、提案產生
• 工程團隊：程式碼審查、部署工作流程、事件回應
• 財務團隊：報告產生、資料驗證、稽核準備

每個基於角色的套組應僅包含與該角色日常工作流程相關的 Skills。



發佈與版本控制



原始碼控制

將 Skill 目錄儲存在 Git 中，以便追蹤歷史記錄、透過拉取請求進行程式碼審查，以及具備回溯能力。每個 Skill 目錄（包含 SKILL.md 與任何隨附檔案）自然對應至一個由 Git 追蹤的資料夾。



基於 API 的發佈

Skills API 提供工作區範圍的發佈。透過 API 上傳的 Skills 可供所有工作區成員使用。請參閱透過 API 使用 Skills 以了解上傳、版本管理與管理端點。



版本管理策略

• 正式環境：將 Skills 固定至特定版本。在推廣新版本之前執行完整的評估套件。將每次更新視為需要完整安全審查的新部署。
• 開發與測試：使用最新版本，在推廣至正式環境之前驗證變更。
• 回溯計畫：保留前一個版本作為備援。如果新版本在正式環境中未通過評估，請立即還原至最後已知正常的版本。
• 完整性驗證：計算已審查 Skills 的核對和（checksum），並在部署時進行驗證。在您的 Skill 儲存庫中使用簽署的提交以確保來源可信。



跨介面考量

將 Skill 原始檔案保存在 Git 中作為單一事實來源。如果您的組織在多個介面上部署 Skills，請實作您自己的同步流程以保持一致性。如需完整詳細資訊，請參閱跨介面可用性。



後續步驟