GitHub Agent Plugins 1.0 怎麼用？先看 plugin.json、Skills 與 MCP 邊界

Q: 只想使用一個 Skill，是否也要安裝整個 Plugin？

不一定。Copilot CLI 的文件把 skill 安裝和 plugin 安裝分開，--skill 可以處理單一 skill 的來源或目錄。先判斷是否真的需要 plugin 內的 MCP、hooks 或其他 agent 元件，再選擇安裝範圍。

2026-08-13

AI

/

/

/

/

GitHub 在 2026 年 8 月 6 日發布 Agent Plugins 1.0，並於 8 月 12 日說明它已經能在 VS Code、Copilot CLI、GitHub Copilot SDK 與 Copilot app 使用。它的目標是讓同一個 plugin 同時包住 agent skills 和 MCP server，降低每個 agent client 都要維護一份目錄與 manifest 的重複工作。

這不代表「裝好 plugin 就能安全執行所有工具」。比較準確的理解是：plugin 是能力的包裝與分發格式；Skills、MCP server、client 權限和來源 repository 仍然要分開審核。

Agent Plugins 1.0 包的是什麼#

一個 plugin 可以包含多種 agent 元件，但它們的責任不同：

元件	解決的問題	導入前要問什麼
`plugin.json`	描述名稱、版本和元件路徑	來源、維護者、版本和更新方式是否可信？
Skill	提供指引、腳本和參考資料	會讀哪些檔案？是否包含不該照做的自動化指令？
MCP server	提供外部資料或工具呼叫	連到哪個 endpoint？能讀取或修改什麼？
Agent client	載入並執行 plugin	這個 client 支援哪些元件與政策？

GitHub 的公告把 Agent Plugins 1.0 描述成開放標準，既有沒有採用 1.0 格式的 Copilot plugin 仍可繼續使用，也不需要因為標準發布就立刻全部遷移。真正需要處理的是跨 client 的元件差異和組織治理。

先讀 `plugin.json`，不要先按 Install#

GitHub Copilot CLI 的 plugin 至少要在 plugin 目錄根部放一個 plugin.json。下面是只保留基本欄位的檢查範例：

1
{
2
  "name": "my-dev-tools",
3
  "description": "Repository development utilities",
4
  "version": "1.0.0",
5
  "skills": "skills/",
6
  "mcpServers": ".mcp.json"
7
}

name 是必要欄位，官方文件要求使用 kebab-case，長度最多 64 個字元。agents 預設從 agents/ 讀取，skills 預設從 skills/ 讀取；mcpServers 可以指向 MCP 設定檔或直接放定義。這些預設路徑讓你可以快速開始，但也代表審核 plugin 時不能只看 manifest 的五行文字，還要打開它指向的目錄與檔案。

特別注意以下三個位置：

Skills 內容：是否藏有會修改檔案、上傳資料或執行網路請求的腳本？
MCP 設定：是否含有固定遠端 URL、本機 command 或需要環境變數的 credentials？
版本與來源：marketplace 的版本是否能回到公開 repository、release 或可審核的 commit？

用 Copilot CLI 做一次可回溯安裝#

Copilot CLI 的 plugin 管理指令可以把來源、已安裝版本和啟用狀態留在操作紀錄裡。先列出 marketplace，再瀏覽和安裝：

1
copilot plugin marketplace list
2
copilot plugin marketplace browse awesome-copilot
3
copilot plugin install OWNER/REPO
4
copilot plugin list

也可以從 marketplace、GitHub repository、Git URL 或本機目錄安裝。測試階段不要直接把一個來源不明的 plugin 加到所有工作區；先在沒有敏感資料的 repository 執行 copilot plugin list，確認它載入的 agent、skill 和 MCP server，再決定是否納入團隊預設。

copilot plugin install 和 copilot plugins install 是同一組指令的不同寫法，但「安裝 skill」不是「安裝 plugin」。如果只需要一個 skill，使用 CLI 的 --skill 流程；不要因為兩者都出現在同一個命令群組，就把 skill 的來源審核和 MCP server 的 action 權限混在一起。

Skills、MCP 與 Plugin 權限要分開審#

Plugin 只能降低分發摩擦，不能替你決定權限。可以用下面的方式拆分驗證：

驗證面	最小測試	通過條件
Skill	讓 agent 只讀取一個測試檔案	沒有未預期的寫入、網路或秘密讀取
MCP	啟動一個唯讀 server，查看工具清單	endpoint、credentials 和可用 tool 都在預期範圍
Client policy	在 VS Code、CLI 或 app 分別啟用	每個 client 的 policy 與支援矩陣都有紀錄
更新	比較新舊版本 manifest 與腳本	新增的工具和權限經過重新審核

若是企業集中管理 Copilot MCP，還要搭配 GitHub Copilot MCP Server Allowlist 的設定方式。allowlist 管的是 server 是否能啟動，plugin 的 skill 內容和本機執行環境仍然需要另一層檢查。

團隊 rollout 前的五個檢查#

先固定 marketplace 或 repository 來源，記錄 plugin 名稱、版本、commit 和審核日期。
打開 plugin.json 指向的 agents、skills、hooks、MCP 和 LSP 設定，不要只看 marketplace 摘要。
使用沒有 secrets 的測試 repository，先驗證唯讀任務與失敗時的停止行為。
在實際使用的 client 分別測試 model、MCP policy、sandbox 和 permission prompt；不要用 CLI 的結果推論 IDE 一定相同。
把更新當成供應鏈變更。plugin 版本改動、MCP endpoint 變更或新增 script，都應重新跑一次審核。

如果團隊還不確定是否需要外部工具，可以先看接 MCP 前的能力盤點。先確認任務真的需要 MCP，再決定要不要透過 plugin 把它分發給更多 client。

結論：先審元件，再享受跨 client#

Agent Plugins 1.0 的價值在於「一次打包，多個相容 client 載入」，不是把所有 agent 工具變成無差別的自動化入口。先確認 manifest、Skills 內容、MCP server、client policy 和更新來源，再用小範圍唯讀任務驗證；這樣跨 VS Code、Copilot CLI 或 Copilot app 共用 plugin 時，仍然能回答資料去哪裡、誰能執行，以及版本變更了什麼。