Agent Plugin 進入 1.0，團隊需要一張「能力清單」
在目錄裡找到一個 agent plugin，README 寫得完整，安裝步驟也只有一行。它能放進 VS Code，也能跟著團隊搬到 CLI 或其他相容的 agent client。這種可攜性很方便，卻也讓人容易沿用安裝一般套件的習慣：看來源、看星數、掃一下 README，然後按下安裝。
問題在於，agent plugin 帶進工作環境的東西比一般函式庫更接近「行動能力」。它可能包含會影響模型判斷的 instructions，也可能接上能讀寫檔案、連線或操作帳號的 MCP tools。當 skills 與 MCP 設定被包成同一個可安裝單位，團隊核准的就不只是幾個檔案，而是一組會改變 agent 行為的能力。
GitHub 在 2026 年 8 月發布 Agent Plugins 1.0，讓 skills 與 MCP configuration 可以打包，並在 VS Code、Copilot CLI、Copilot app 等相容 client 使用。個人的零散設定因此能變成可以分享、更新與管理的套件。
可攜性解決了重複設定，卻不會自動處理信任。相反地，同一個錯誤核准也更容易被複製到多個工作環境。團隊需要補上的，是一張能被人 review、也能約束實際執行的「能力清單」。
找到候選項，不等於核准它
README、星數、搜尋排名和資源目錄都適合用來發現候選項。它們回答「有哪些東西可以研究」，無法回答某個版本在真實環境裡能做什麼。
這個差距並不抽象。Island 在 2026 年 7 月公布的 AgentBaiting 調查，追蹤到約 7,600 個惡意 GitHub repositories，其中超過 800 個假扮成 AI skills 或 MCP servers。這不代表多數 plugin 都有問題，也不值得把每次安裝寫成資安恐怖故事。這份調查至少提醒我們：容易被找到、看起來像開發工具，從來不是可信任的證據。
例如，團隊想找能提供 MCP Apps UI、agent-rendered interface 或其他 Generative UI 能力的 plugin，可以先從整理過的生成式 UI 資源比較相關 SDK、實作與案例。這一步能縮小搜尋範圍，但資源整理不會替任何 package 完成 runtime approval。是否核准，仍要回到具體版本、工具權限與隔離試跑。
能力清單要記錄的五件事
能力清單不必一開始就做成新的規格。一份跟著專案版本控制的 Markdown 檔，先把下面五個區塊寫清楚，已經能避免很多模糊授權。
1. 身分
記錄來源、maintainer、版本、checksum 或 lock record，以及團隊內部的 owner。名稱不夠，因為安全決定應該綁定可重現的內容。內部 owner 也不能省略；沒有負責人的 plugin，出事時通常也沒有人知道該先停哪裡。
2. Instructions
列出 package 內含哪些 skills 或 instructions、它們會影響哪些判斷，以及更新時由誰 review diff。自然語言指令常被當成文件，但對 agent 而言，它們可能直接改變工具選擇、步驟順序與停止條件。
3. Tools 與權限
逐一寫下 MCP servers 和其他 tools 可以讀什麼、寫什麼、是否需要網路、能否取得 secrets，以及哪些動作具有破壞性。不要只記錄「需要 GitHub 權限」這種大範圍描述；讀取 public repository、修改 private repository 和發布 release 是三種完全不同的授權。
4. 可觸及的 surface
除了檔案與 repository，也要盤點 browser、cloud account，以及 plugin 可能產生的互動介面。對 generated UI 尤其要小心：畫面上出現一顆按鈕，不代表按鈕背後的 action 已經通過核准。介面只是呈現層，真正的權限仍在 tool 與 runtime。
5. 生命週期
寫明第一次試跑的 sandbox、需要人工確認的節點、更新政策、執行收據、停用與 rollback 方法，以及下一次重新 review 的日期。能力清單如果只在安裝前看一次，很快就會變成失效的文件。
實際檔案可以很短：
source / maintainer / version:internal owner:bundled instructions:MCP tools and scopes:
data, repository and UI surfaces:
first-run sandbox:
approval points:
update policy:
disable / rollback:
last review / next review:
欄位名稱可以調整，但團隊要能在安裝前說清楚：現在核准的是哪個版本，它被允許做哪些事，誰負責收回權限。
第一次執行只是隔離測試
比較穩健的採用流程可以維持得很小：先做靜態檢查，再放進沒有真實 secrets 的測試 workspace。試跑時記錄實際 tool calls、網路需求、修改過的檔案與失敗模式。觀察結果符合能力清單後，才由 owner 核准特定版本與必要權限，最後才進入正式環境。
這裡的「執行收據」很重要。靜態檢查告訴我們 package 宣稱會做什麼；執行收據則留下它那一次真的呼叫了哪些工具、碰了哪些資源、在哪個核准點停下。兩份紀錄放在一起，review 才不會只剩對 README 的印象。
UK AISI 公開的 cyber evaluation incident report 提供了一個邊界案例：在刻意寬鬆的測試條件下，122 次 runs 中記錄到 10 次 autonomous unsanctioned actions。這組數字不是一般 plugin 的事故率，也不能拿來推論 GitHub Agent Plugins。本來就寬鬆的測試環境，恰好說明 runtime boundary 的作用；package review 做得再仔細，也無法取代執行時的最小權限、核准點與停止機制。
更新後，要重新判斷能力
團隊很容易信任一個 plugin 的名字，然後讓它長期自動更新。但 instructions、MCP configuration、permission 或 UI surface 只要改變，原本的核准就可能不再適用。
比較可控的做法是 pin 住已核准版本，並把上述區塊的 diff 放進更新流程。修正文案和新增一個可寫入 cloud account 的 tool，不該使用同一種 review 強度。即使 maintainer 完全可信，功能正常擴張也可能超出團隊最初給的權限。
能力清單還需要自然到期。到了重新 review 的日期，或內部 owner 已經離開專案，系統應把 plugin 降回待核准狀態。若沒有清楚的 disable 與 rollback 路徑，就先不要讓它進入正式工作流。這個到期機制可以避免一個半年前裝來試用的能力，悄悄變成沒有人敢移除的基礎設施。
Plugin 讓 agent 工作流更容易搬移，團隊仍要逐次核准信任。成熟的做法不是拒絕新能力，而是隨時答得出三件事：目前允許哪個版本、它能碰哪些資源、需要時要怎麼收回。