【2026 最新】Agent Skill 管理怎麼做？Git、Lockfile、A/B Eval 6 步生命週期

Agent Skill 管理已經從「把好用的提示詞存起來」變成一個維運問題。2026 年 9 月 7 日，一篇詢問「大家怎麼管理 Skills 檔案？」的 Ask HN 討論出現大量實務回應；截至 9 月 9 日查核時，它有 307 points、278 則留言。這只能代表 Hacker News 開發者圈當下很關心，不等於整個市場的普及率，卻精準點出共同焦慮：你怎麼知道現在載入的是哪一版、它還有沒有用，以及該在何時撤下？

這篇專為剛開始累積 Skills 的個人與小團隊而寫。你不必先建一套昂貴平台；只要用 Git、一份自訂 lock manifest、固定題目的 with／without Eval，以及可演練的退役流程，就能把「散落的說明檔」變成可追蹤、可比較、可回復的資產。

Agent Skill 管理為什麼不能只靠資料夾？

Skill 可以理解成「給 AI 代理使用的工作手冊」：它告訴代理何時介入、要讀哪些參考資料、可執行哪些腳本，以及成功長什麼樣子。若你還不熟悉檔案結構，可以先讀 Agent Skill 與 SKILL.md 入門。

問題是，資料夾只能回答「檔案在不在」，回答不了五個更重要的問題：

• 責任：誰要審查、修正與決定退役？
• 追溯：它從哪個 repository、哪個完整 commit 來？
• 信任：腳本、連結、權限與依賴是否經過檢查？
• 效果：裝與不裝相比，成功率、成本與誤觸發有何差異？
• 期限：工具改版或負責人離開後，何時必須重測或停用？

截至 2026 年 9 月 9 日查閱的 Agent Skills 現行規格，必填欄位是 name 與 description，另提供選配欄位與自訂字串型 metadata；規格沒有替所有 host 定義版本鎖、到期、退役、rollback 或 Eval 的共同語意。因此，本文把治理資訊放在外部 skills.lock.yaml。這是 AlphaLab 建議的團隊範例，不是規格內建功能。

Agent Skill 管理的 6 階段生命週期

最小可行流程不是「下載 → 永久啟用」，而是盤點 → 審查 → 鎖版 → 評測 → 小流量啟用 → 淘汰。每次更新都重新走一次後四步，失敗就退回上一個已知可用版本。

1. 盤點：先讓每個 Skill 都有身分證

先列出所有載入路徑，不論它來自個人目錄、專案目錄或遠端平台。每筆至少記錄 id、owner、來源、用途、權限、目前狀態、下次審查日。若一個 Skill 找不到 owner，先標成 quarantine，不要默認它可以進 production。

schema_version: "1"
skills:
  - id: "team/code-review"
    owner: "platform-team"
    source_repo: "https://github.com/example/skills.git"
    source_commit: "0123456789abcdef0123456789abcdef01234567"
    bundle_sha256: "sha256:..."
    status: "active"
    review_due_at: "2026-12-01"
    expires_at: "2026-12-15"
    eval_report: "evals/code-review-2026-09.json"
    previous_known_good: "89abcdef..."

review_due_at 是提醒重新審核；expires_at 則由你自己的 CI 或 loader 政策決定是否禁止新部署。兩者都不會因為寫進 YAML 就自動生效。

2. 審查：把 Skill 當成會執行的程式

不要只讀 SKILL.md 的前幾段。完整檢查參考檔、scripts、下載 URL、shell 指令、檔案範圍、MCP 工具與環境變數；特別注意「讀取敏感檔案」和「可以連網」同時出現的組合。Anthropic 的 企業 Skills 指南也把 security review、權限盤點、隔離測試與職責分離列入部署生命週期。

一個 checksum 只能證明「今天部署的檔案與審核過的檔案相同」，不能證明內容安全；commit hash 能辨識內容，也不能單獨證明作者身分。需要來源保證時，還要搭配可信金鑰政策與已驗證簽章。你也可以把供應鏈檢查延伸成 套件來源與 provenance gate。

3. 鎖版：讓「昨天可用」今天仍可重建

正式環境不要只記 latest 或可被重新指向的 tag；Git 的 tag 指令本身就允許以 -f 取代既有 tag。若團隊用 Git submodule，可讓主 repository 的 gitlink 指向明確 commit；Git 官方文件說明，superproject 記錄的是 submodule 預期的 commit object name。

git submodule add <SKILL_REPO_URL> vendor/agent-skills
git -C vendor/agent-skills checkout <FULL_COMMIT>
git add .gitmodules vendor/agent-skills skills.lock.yaml
git commit -S -m "Pin reviewed Skill source"

重建時執行 git submodule update --init --recursive --checkout，再比對 git submodule status --cached 與 lockfile。若你用 hosted Skills，則 pin 該平台提供的精確 version ID；例如 OpenAI 的 Skills API提供不可變版本物件與 default version 指標，但這套 API 版本模型不能直接套用到 repo-local Skills。想深入版本感知，可接著看 把工具版本綁進 Skill 的做法。

4. 評測：先證明有 Skill 比沒有好

「跑過一次成功」不是評測。至少建立固定的任務 ID、輸入、模型、agent harness、工具權限、起始狀態與 grader，然後比較相同題目。想先理解 Eval 的基本觀念，可讀 AI Eval 新手指南；若已經在測路由，則看 Agent Skill 路由 A/B 測試。

5. 小流量啟用：通過離線測試仍先 canary

新版先只對少量工作或內部使用者啟用，並在 application layer 記錄實際觸發、成功、token、成本、延遲、工具錯誤與人工接管。Anthropic 的企業指南指出，其 Skills API 本身目前沒有 usage analytics，因此不能假設平台會替你完成監控；實際可觀測性要由應用層補上。

發布前就寫好 rollback：保留前一個 known-good commit、promotion commit 與完整 Eval 報告。若新版踩到預設門檻，以 git revert <PROMOTION_COMMIT> 建立反轉提交，再重新同步 submodule；這比刪檔更容易追查，也保留共享歷史。

6. 淘汰：到期不是刪除，而是停止擴散

建議使用 draft → canary → active → deprecated → retired，另保留任何狀態都能進入的 revoked。其中 deprecated 代表不再接受新使用者，但仍保留 rollback；retired 才是確認沒有 consumer、保存必要稽核資料後的移除候選；revoked 則用於安全事件的緊急停用。

Agent Skill 管理怎麼做 with／without A/B Eval？

這裡最常見的誤判，是 Skill 沒有被路由器選中，卻說 Skill 內容沒用。請把實驗拆成兩層：

1. 端到端 A/B：A 不安裝 Skill；B 安裝後讓代理自行判斷是否觸發。這測「路由＋內容」的總效果。
2. 條件式 A/B：A 不載入；B 強制載入指定 Skill。這較接近內容本身的邊際效果。

路由集至少放三種案例：should_trigger、should_not_trigger、模糊邊界；還要加入會和其他 Skills 競爭的共存案例。Anthropic 官方建議每個 Skill 先準備 3–5 個代表性 query 作為部署 smoke test，但這個數量只適合快速抓明顯錯誤，不能用來宣稱具有統計代表性的「高準確率」。

[
  {"id":"route-01","query":"請審查這個 PR","should_trigger":true},
  {"id":"route-02","query":"解釋什麼是 code review","should_trigger":false},
  {"id":"route-03","query":"幫我找出程式風險","label":"ambiguous"}
]

把路由結果記成 TP、FN、FP、TN，再計算 recall、precision 與 false-positive rate。任務結果則優先使用單元測試、schema、檔案狀態或人工事先寫好的 rubric。模型具有非決定性，同一題要重複多次，且 A、B 必須使用相同模型版本、權限與環境。OpenAI 的 Evals 指南示範代表性樣本、testing criteria 與人類標註；若要套用在本文的本地 Skill A/B，仍需由你自己的 agent harness 負責載入 Skill 與重建工具環境。

每次 trial 至少留下：是否成功、實際觸發版本、input／output／cached token、總成本、端到端延遲、turns、tool calls、errors。再算 cost_per_success = 全部 trial 成本 ÷ 成功 trial 數。門檻要在看結果前決定，例如「關鍵安全案例零新增失敗」；其餘成功率、成本與延遲門檻應依自己的風險與收益設定，不存在適用所有團隊的神奇數字。

30 分鐘建立最小 Skill Lifecycle

如果你今天只有一個 repository，可以先完成下面五件事。目標不是一次建成平台，而是讓下一次更新有證據可循。

1. 新增 inventory：建立 skills.lock.yaml，為每個 Skill 填 owner、來源 commit、狀態與審查日。
2. 保存精確版本：用完整 commit OID 或 hosted version ID，另留審核後 bundle 的 SHA-256。
3. 做 3 類路由 smoke：應觸發、不應觸發、模糊案例各放真實請求。
4. 做 paired A/B：固定三個常見任務，分別跑 without 與 with Skill；先使用可判定的成功條件。
5. 演練 rollback：故意把 canary 切回 previous_known_good，確認不是只在文件上「可以回復」。

接著把檔案放進同一個 Pull Request：Skill 內容、lockfile 變更、Eval fixture、報告與 promotion decision 一起審。大型團隊可再加 registry 與自動儀表板；小團隊先把這條證據鏈跑通就夠。若你正在搭整體執行層，可參考 AI Agent Harness 建置指南。

哪些 Skill 值得留下，哪些該改成 script？

保留一個 Skill 的好理由，是它處理反覆出現、與情境相關、需要判斷、又能驗證的工作，例如公司內部 incident 流程、專屬資料 schema、品牌交付規格。相反地，如果規則必須百分之百執行，例如禁止提交密鑰、JSON schema 必須合格、測試必須通過，就把 enforcement 放進 script、hook 或 CI；Skill 只負責說明與路由，不要把確定性要求押在模型記得照做。

遇到下列任一條，就把 Skill 放進淘汰清單：長期沒有 owner、找不到 consumer、與另一 Skill 重複、路由 false positive 持續偏高、任務成功沒有優於 baseline、成本上升卻沒有可觀察收益，或所依賴的工具版本已離開測試範圍。這不是宣告 Skills 無用，而是要求它們和程式碼一樣用結果續約。

最容易踩的 5 個管理坑

1. 把 metadata.version 當套件鎖：它只是自訂字串；host 不一定解讀，更不會自動抓回同一份內容。
2. 把可讀 tag 當不可變版本：tag 可以被重新指向；lock 應保存解析後的完整 commit，必要時再驗簽章。
3. 只測正向觸發：沒有 negative 與 coexistence cases，就看不見 Skill 偷走別人任務的成本。
4. 只看成功率：相同成功率仍可能伴隨更多 token、較慢 p95、更多工具錯誤或安全退步。
5. 把刪除當 rollback：先切回已知可用版、停用新版、保存事故證據，再依 retention policy 決定何時移除。

尤其不要用「我們裝了很多 Skills」當成熟度指標。active set 愈大，名稱與 description 之間的語意重疊愈值得測；需要進一步改善分流時，可搭配 Skill Router 的分層路由方法。

常見問題 FAQ

1. 我只有三個 Skills，也需要 lockfile 嗎？

需要，但可以很小。只記 owner、完整 commit、狀態、審查日與上一個可用版，就已經比「記得某天複製過」更容易重建。Skill 少正是建立習慣成本最低的時候。

2. 直接把 Skills 放在同一個 monorepo 不就鎖版了？

內容版本是鎖住了，部署與評測狀態仍要記。monorepo commit 能重建檔案，但不會自動告訴你哪個模型、harness、權限與 Eval 報告核准了該版。

3. checksum 跟 Git commit 留一個就好嗎？

兩者回答不同問題。commit 連到歷史與差異，bundle checksum 適合在部署邊界驗證實際 artifact；兩者都不等於安全審查或作者身分保證。

4. 每個 query 跑一次夠嗎？

只夠找明顯壞掉，不夠比較小幅差異。模型輸出會變動；先做少量重複的 smoke，接近發布門檻或風險較高時，再增加任務與重複次數，並呈現變異。

5. A/B 的 A 應該是完全沒有 Skill，還是上一版？

兩種都值得跑。「無 Skill vs 候選版」回答它是否有存在價值；「目前 production vs 候選版」回答新版能否升級。不要把兩個問題混成一個分數。

6. 到期日一到就應自動刪除嗎？

不要。較安全的預設是阻止新部署、通知 owner、切回 known-good 或停用，再確認 consumer 與稽核保留需求。刪除通常是退役流程的最後一步。

7. 團隊應多久重跑 Eval？

由變更事件與風險決定。Skill、模型、harness、工具 API、權限或關鍵資料格式任一改變都應重跑；高風險流程再加固定週期。沒有跨所有團隊通用的最佳天數。

8. Skill 效果不好，先改 description 還是正文？

先看是哪一層失敗。該觸發卻沒觸發，先修 name／description 與競爭集合；已正確觸發但結果差，再修正文、參考資料、腳本或 grader。這就是把路由 Eval 與條件式 A/B 分開的價值。

給新手的 6 個重點

• 先為每個 Skill 指定 owner，再談擴充數量。
• 正式環境 pin 精確版本；可讀版本名只當輔助。
• checksum 驗一致性，不替代安全與來源審查。
• 路由正確與任務改善要分開測。
• 成功率必須與 token、成本、延遲、誤觸發一起看。
• 每次 promotion 都保留上一版，並真的演練 rollback。