Agent Plugins 1.0：適用於所有 AI 代理程式的單一套件格式

什麼是 Agent Plugins？ Agent Plugins 1.0 是一項於 2026 年 8 月 6 日發布的開放、廠商中立封裝標準，它把 Agent Skills 與 MCP 伺服器設定綁進單一可攜目錄，任何相容的代理程式用戶端都能載入。外掛程式就是一個資料夾：必要的 plugin.json 資訊清單、選用的 skills/ 資料夾（存放 Agent Skills），以及選用的 mcp.json（宣告 MCP 伺服器）。發布之初，ChatGPT、Codex、Cursor、GitHub Copilot、Kiro 與 VS Code 均已支援。¹²

六家每天在市場上彼此競爭的公司，為一個所有代理程式使用者都體會過的問題交出了同一份答案：你為某個代理程式用戶端做的擴充，換到下一個就失效了。提案由 Vercel 發起，規格則由其與 Amazon、Anysphere（Cursor 的開發商）、GitHub、Microsoft 及 OpenAI 共同制定；² Google 也在同一天宣布加入核心維護者行列，並已著手在自家產品中提供支援。⁶ 官方網站的一句話說明是：「一種可攜的套件格式，用於擴充 AI 代理程式的可重複使用元件。」¹

被封裝的這兩層，恰好出自一家名字並未出現在維護者名單上的公司。這份缺席是故事的一半，也是本文後半段的主題。

重點摘要： Agent Plugins 1.0 標準化的是圍繞兩項既有規格——Agent Skills 與 Model Context Protocol——的封裝層，它並未取代其中任何一項，只是確定了兩者在可共享目錄中的落點。¹ 外掛程式就是一個資料夾：plugin.json 負責身分識別，skills/ 存放技能，mcp.json 宣告伺服器，再加上供用戶端專屬內容使用的反向網域命名空間資料夾。第 1 版刻意只做到互通性的地板線：規格未替安裝、登錄庫、權限、來源證明、密鑰或 OAuth 定義任何可攜語意，這些全數交由用戶端自行管理。¹² Codex 分別在 v0.146.0 與 v0.147.0 完成支援。⁴ 創造了 Agent Skills 與 MCP 的 Anthropic 並不在維護者之列，Claude Code 也維持自己的外掛程式格式。³⁷⁸

重點整理

• 個人開發者： 把技能寫成標準的 Agent Skills（一個含有 SKILL.md 的資料夾），它本身就已經是可攜的底層素材；要包成外掛程式，只差一份資訊清單。別再為每個用戶端各維護一份副本了。
• 技術主管： 這項標準涵蓋的是封裝，而非散布或政策。登錄庫、更新機制、允許清單的作法，依舊是各用戶端各自的決定。在內部承諾「寫一次、到處跑」之前，先把這部分工作量估進去。
• 資安工程師： 第 1 版既沒有來源證明層，也沒有權限層，更沒有簽章層，信任判斷整個被推到安裝時的人工審查。可攜性愈高，遭投毒技能攻擊的波及範圍也就愈廣。

這次推出了什麼

2026 年 8 月 6 日，Vercel 發布了 Agent Plugins 1.0.0——一份由其發起，並與 Amazon、Anysphere、GitHub、Microsoft 及 OpenAI 共同制定的開放規格。² 規範性規格放在一個公開儲存庫，維護者名單橫跨 Amazon、Cursor、Microsoft、OpenAI 與 Vercel；³ Google 則在發布當天宣布以核心維護者身分加入，支援能力也已陸續進入自家的代理程式工具鏈。⁶

首批用戶端名單涵蓋了生態系中最大的幾個入口：VS Code、Cursor、GitHub Copilot、ChatGPT 與 Codex，以及 Kiro。¹² Codex 的 CLI 支援其實早於公開發表：v0.146.0（7 月 29 日）加入了 Agent Plugins 資訊清單與工作區外掛程式發布，v0.147.0（8 月 7 日）補齊了可攜的外掛程式安裝，以及橫跨本機、個人、工作區與遠端目錄的搜尋。⁴

適用範圍就寫在規格的開場句裡：本文件「定義了正式的 Agent Plugins Specification v1.0.0，用於將擴充 AI 代理程式的可重複使用元件封裝成可散布的外掛程式」。¹ 是封裝，不是一套新的技能語言，也不是 MCP 的替代品。底層這兩種格式各自保留自己的規格；這項標準確定的，只是它們在用戶端能夠探索到的目錄中所處的位置。

外掛程式的結構

外掛程式是一個目錄，包含一個必要檔案與三個選用部分：¹

my-plugin/
├── plugin.json              # required: identity + metadata
├── skills/                  # optional: Agent Skills
│   └── release-notes/
│       └── SKILL.md         # one immediate subdirectory = one skill
├── mcp.json                 # optional: MCP server configs
└── com.example.client/      # optional: client-namespace directory

plugin.json 是一份封閉綱要的資訊清單。頂層允許的欄位恰好十個：$schema、name、version、description、author、homepage、repository、license、keywords 與 extensions；至於其餘一切，規格的措辭相當嚴格：「用戶端必須（MUST）回報並忽略每一個未知欄位，而只要資訊清單在本節其他方面合規，就必須（MUST）繼續載入該外掛程式。」¹ name 欄位可使用小寫英數字、連字號與句點，首尾必須是英數字，且不得出現連續的連字號或句點。¹

skills/ 原封不動地承載既有形態的 Agent Skills：「凡直接子目錄中名為 SKILL.md 的路徑可解析為一般檔案者，該目錄即視為一個技能。」¹ mcp.json 用來宣告 MCP 伺服器；支援外掛程式內 MCP 伺服器的用戶端「必須（MUST）至少支援 stdio 或 streamable-http 其中之一」，並且應該（SHOULD）兩者皆支援，sse 則為選用。規格更明確允許只處理技能的用戶端，在完全不支援 MCP 伺服器的情況下仍算符合規範。¹

com.example.client/ 這類反向網域目錄用來承載用戶端專屬行為，而可攜性規則以規範性措辭寫明：「對於自己未實作的命名空間，用戶端必須（MUST）忽略其資訊清單項目，且不得驗證這些項目的值內容。」¹

最後這個機制的份量比表面上重得多。各用戶端之間差異最大的元件，被擋在可攜核心之外：命令、掛鉤、子代理程式、規則與 LSP 伺服器，正是規格自己舉出的那類「對穩定的可攜契約而言仍過度依附特定用戶端」的元件型別，在各自格式收斂之前都留在第 1 版之外。¹ 可攜核心就是技能加上 MCP 設定，如此而已。

第 1 版刻意留白之處

這份規格只標準化了足以運作的最小集合。它未替安裝、登錄庫、權限、來源證明、密鑰或 OAuth 定義任何可攜語意，上述每一項都仍歸用戶端管理¹²，也沒有定義簽章層。維護者規劃的擴張路徑在設計上就偏保守：某類元件唯有等到各家實作收斂到足以被精確定義時，才會晉升進可攜核心。¹

與其把這看成怯懦，不如視為聯盟的力學。六家公司——其中五家都在推出彼此不相容外掛程式格式的代理程式用戶端——能取得共識的，僅止於檔案放在哪裡；至於掛鉤如何觸發、命令如何註冊、誰的權限模型說了算，他們尚未談攏。於是標準凍結了行為早已收斂的那一層（技能是 Markdown 資料夾，MCP 是傳輸協定），把所有有爭議的部分圈進命名空間。這是一塊互通性的地板，而地板之所以有用，正是因為所有人都站得上去。

這塊地板的代價是：「建置一次、到處執行」適用於套件，而非體驗。外掛程式到哪裡都裝得起來，但它能做什麼仍因用戶端而異；如何安裝、如何更新、如何被信任，更是完全由用戶端決定。

一個 Anthropic 形狀的空缺

奇特之處在這裡。被這項標準封裝的 Agent Skills——那種以資料夾承載指令的格式——出自 Anthropic 之手，2025 年 10 月發表。⁸ Model Context Protocol 同樣如此，Anthropic 於 2024 年 11 月將其開源。⁷ 這項封裝標準底下的兩層，都來自同一家主流代理程式工具廠商，而它的名字在維護者名單上遍尋不著。³

Claude Code 維持著自己的外掛程式格式——自己的資訊清單、自己的市集來源、自己那套掛鉤與命令的封裝方式——8 月 6 日公布的任何內容都沒有改變這一點。目前的橋接是單向的：Codex 內建 Claude Code 市集來源（v0.146.0），其 /import 命令可將 Claude Code 的設定、MCP 伺服器、外掛程式、工作階段、命令與專案範圍的記憶遷移進 Codex。⁴

就實務而言，這道接縫比組織圖所暗示的窄，原因就在底層素材：不論在哪個生態系，技能都是一個含有 SKILL.md 的資料夾。你為 Claude Code 撰寫的技能，與 Agent Plugin 所承載的是同一份產物。真正無法搬遷的是外包裝——一邊是 Claude Code 的外掛程式資訊清單，另一邊是 plugin.json——以及各生態系各自原生保留的用戶端專屬元件（首推掛鉤）。若你今天在維護技能，其實已經在撰寫可攜的那一層；分歧發生在封裝，而不在內容。

Anthropic 最終會採納這套格式、推出對等方案，還是任由這座橋維持單向，正是這次發布拋出的開放問題。聯盟的組成——除一家之外的所有主流代理程式用戶端廠商全數在列——意味著這項封裝標準的走向，取決於其兩層底座的缺席作者是否認為這塊地板值得站上去，而非取決於技術上的高下。

沒有人標準化的供應鏈問題

一種沒有來源證明層的可攜套件格式，同時也是一種可攜的攻擊格式。第 1 版把來源證明與權限交由用戶端管理，也未定義任何簽章或驗證工具，¹ 這代表信任判斷完全落在安裝那一刻，落在每個用戶端、每位使用者身上。

這件事在本月比上個月更為要緊。近期關於技能層級攻擊的研究——ElasticBack 是其中最銳利的例子——示範了植入單一技能文件的條件式後門，並把代理程式技能界定為「一條正在成形的供應鏈，其中一份遭投毒的技能就足以持續危害每一個安裝它的代理程式」。⁵ 可攜性把這份風險成倍放大：同一個遭投毒的外掛程式如今裝進的是六個用戶端而非一個，而標準的適用範圍又把偵測留給各用戶端（或各使用者）自行審查。

在這項標準問世之前，我已在Agent Skills 需要套件管理器一文中做過更完整的論證：代理程式的脈絡早已成為一條軟體供應鏈，要安全地安裝它，就需要套件生態系老早學會打造的那套機制——資訊清單、鎖定檔、限定範圍的安裝、審查關卡、還原。Agent Plugins 1.0 交出了資訊清單，然後就停下；清單以外的其他項目，恰恰是第 1 版留給用戶端的部分。安裝什麼，就自己檢視什麼，格式不會代勞。（我的代理程式看不見的技能一文還帶出一個相鄰的陷阱：代理程式是在嚴格的脈絡預算下載入技能說明的，隨外掛程式配送的技能也會加入同一份目錄清單——可攜性等於往一個本來就會悄悄被截斷的佇列裡繼續塞技能。）

今天可以做的事

若你使用 Codex： 標準已在你手上。codex plugin 提供可攜的 Agent Plugins 安裝，自 v0.147.0 起，外掛程式搜尋橫跨本機、個人、工作區與遠端目錄。⁴ 團隊可以把外掛程式發布到自己的工作區，而不必另外架設公開市集。

若你使用 Claude Code： 你的外掛程式格式毫無變動。請繼續以標準技能資料夾的形式撰寫技能——那才是可攜的一層——並把外包裝視為可拋棄之物。若你同時也跑 Codex，其 Claude Code 市集來源與 /import 能把既有設定帶過去。⁴

若你使用 VS Code、Cursor、Copilot、ChatGPT 或 Kiro： 你在首批用戶端名單之中；外掛程式如何安裝取決於你所用用戶端的使用體驗設計，因為標準刻意不去規定這件事。¹

若你在做開發者工具： 這份資訊清單小到一個下午就能導入，規格儲存庫也是公開的。³ 真正值得琢磨的決定不是要不要讀取 plugin.json，而是要把自家哪些元件圈進反向網域命名空間——那條界線實際上就是你對「什麼算可攜」的公開表態。

常見問題

Agent Plugins 會取代 MCP 或 Agent Skills 嗎？

不會。規格自陳的職責是「將擴充 AI 代理程式的可重複使用元件封裝成可散布的外掛程式」¹——技能保留 SKILL.md 格式，MCP 伺服器保留自己的協定，而標準確定的只是兩者在可共享目錄中的落點。

外掛程式能夾帶掛鉤、斜線命令或自訂代理程式嗎？

在第 1 版裡，無法以可攜的方式做到。規格點名命令、掛鉤、子代理程式、規則與 LSP 伺服器，作為「對穩定的可攜契約而言仍過度依附特定用戶端」的元件型別範例，在其形態收斂之前都被排除於可攜格式之外。用戶端可以把它們放進自己的反向網域命名空間目錄，而對未實作的命名空間，用戶端必須（MUST）忽略。¹ 可攜核心是技能加上 MCP 設定。

為什麼 Anthropic 沒有參與這項標準？

規格方與聯盟方都未說明。已公開的事實是：維護者名單橫跨 Amazon、Cursor、Microsoft、OpenAI 與 Vercel，Google 於發布時加入，³⁶ 而同時創造了 Agent Skills 與 MCP 的 Anthropic⁷⁸ 缺席，Claude Code 也保留自己的外掛程式格式。當前實際可用的橋梁在 Codex 這一側：它的 Claude Code 市集來源與 /import 遷移功能。⁴

安裝第三方 Agent Plugins 安全嗎？

這個格式幫不上你做判斷：第 1 版把權限與來源證明交由用戶端管理，也未定義簽章或驗證工具。¹ 請把外掛程式當成任何一段你授予自身權限的程式碼來看待。技能層級的後門研究（ElasticBack）顯示，一份遭投毒的技能文件就能有條件地危害每一個安裝它的代理程式，而可攜性會把這個安裝基數成倍放大。⁵

參考資料