六家AI巨頭（OpenAI、微軟、GitHub、AWS、Vercel、Anysphere）聯合發布 Agent Plugins 1.0.0 開放規範，統一 AI 智能體插件的打包標準。開發者只需一次打包，即可在 Cursor、GitHub Copilot、Codex 等多個客戶端通用。該規範定義了 plugin.json 清單、skills 和 mcp.json 等結構，但僅統一包裝層，未涉及 hooks、custom agents 等核心競爭力。Anthropic 作為 Claude Code 插件系統的開創者並未參與共建，但其格式已被多方兼容。這意味著底層標準競爭已轉向插件生態爭奪，真正的較量在於誰能吸引更多開發者。文章作者、來源：新智元
Six giants in the AI industry sat at the same table for the first time.
8 月 6 日，一份名為 Agent Plugins 1.0.0 的開放規範正式公開。
它做了一件無數AI開發者期盼已久的實事：為AI智能體的插件制定一個統一的「包裝盒」，從此一份打包即可通吃，無需為每家客戶端重複打包。
OpenAI 開發者在官方推特上發帖：一次打包，即可在所有兼容的智能體客戶端中通用，並 @ 了一串合作方。
這份規範看似不起眼，卻準確地擊中了痛點。
同一個技能（Skill）、MCP伺服器（MCP Server），核心明明完全一樣，你卻得為 Cursor、GitHub Copilot、Codex 一家家重新封裝一遍：誰家一更新，還得挨個跟著修改。
Agent Plugins 想要終結的，正是這種重複勞動。
目錄結構、清單檔案、MCP 設定寫法，一併統一。打包一份，支援此格式的客戶端都能識別。
Agent Plugins 工作原理示意：左邊散裝的技能與 MCP，收進中間那只 plugin.json「包裝盒」，再一次分發給 IDE、CLI、企業端等各類客戶端。
例如。
你開發了一個「查詢資料庫、撰寫週報」的插件，其中一個功能教 AI 將查詢結果整理成團隊喜愛的週報，另一個 MCP 伺服器負責為 AI 連接資料庫。
以前想讓它同時在三個客戶端裡使用，就得打包三次，修改一處要改三遍。現在，打一份包、只改一遍就夠了。
在共建者名單中，AWS、Anysphere（Cursor 母公司）、GitHub、微軟、OpenAI、Vercel 六家均在列，就連谷歌也在發布當天被追加為核心維護者。
唯獨少了這套玩法的開創者——Anthropic 的身影。
統一的是「包裝盒」，不是智能體
一個插件，通常由兩樣東西組成。
同樣是 Agent Skills，提供模型可重複使用的指令和資源；另一種是 MCP Server，負責連接外部工具與服務。
這兩樣原本就能跨客戶端重用。
真正卡住的地方，是最外層：每家客戶端的目錄結構、清單檔案、MCP 設定寫法都不一樣，同一個組件換個客戶端，就得照「新家」的規矩，重新打一次包。
而 Agent Plugins 統一了外層的打包箱。
一個插件就是一個資料夾。
在根目錄放置一份 plugin.json 清單，將所有技能放入 skills/，MCP 設定寫入 mcp.json。
清單中只有 $schema 和 name 兩個欄位為必填，其餘全部依固定位置查找，客戶端無需猜測，甚至連版本號都可不寫。
至於各家想夾帶的「私貨」，例如自己特有的鉤子、命令、介面，統統放入一個以反向域名命名的目錄中。
其他客戶端不識別此目錄，掃描到也會直接略過。這層是公開的，因此更乾淨、更精簡，實現起來也不費力。
而且它管得很少。
1.0 僅認可兩類可移植組件：skills/ 中的技能，以及 mcp.json 中的 MCP 設定。
hooks、斜杠命令、custom agents 這些，仍各為其主，尚未統一。
規範正文目前仍標註為「工作草案（Working Draft）」，彷彿官方在旁輕聲補充：「仍在修改中」，距離業界認可的成熟標準，仍有一段距離。
一句話，Agent Skills 管指令，MCP 管連工具，Agent Plugins 管把這兩個裝進同一個包裝盒。
Only the packaging box is unified; the agents inside remain unchanged.
一次打包，不等於到處運行
即使包裝盒統一了，運行還遠未跟著統一。
它只管理 skills 和 mcp.json 這兩類組件的外殼。真正到了運行層面，它就不管了：
安裝、分發、權限、沙箱、認證、信任驗證、使用者體驗，一樣都不管，全留給各家客戶端自己做。各家對 stdio、Streamable HTTP、舊版 HTTP+SSE 這幾種傳輸方式的支持也不完全一致。同一個插件換個客戶端，能否順利運行，還要看運氣。
Microsoft also specifically reminded users about security: the MCP Server and hooks in the plugin will execute code on your local machine—always verify the source and author before installing, and be especially cautious with items from the community marketplace.
OpenAI 自家的打包文件，目前仍使用 .codex-plugin/plugin.json 這套結構，與開放規範根目錄的 plugin.json 並非同一回事。
規範僅保證相容的客戶端能發現其支援的可移植元件；實際運行時，認證方式和運行環境仍可能有所不同。
因此，打包統一，並不代表運行也統一了，中間還隔著一整條工程鏈。
歸根結底，這次統一的，恰恰是巨頭們最不介意放手的那層。
真正值錢的那些，應用市場、權限體系、用戶入口，還有 hooks、custom agents 這些專有能力，一個也沒交。
這套結構，怎麼這樣眼熟
熟悉 Claude Code 插件的人，可能已經愣住了。
plugin.json、skills、mcp.json，這不就是 Claude Code 一直都在用的那套嗎？
早在這份標準出現之前，Anthropic 就為 Claude Code 準備了一整套插件系統：在根目錄下放置一份 .claude-plugin/plugin.json，搭配 skills、mcp.json、commands、agents，並開設了兩個官方市場供用戶分享插件。
「插件等於技能加 MCP 加一份清單」的打包思路，Anthropic 是最早成功實現的公司之一，而且它的系統更完整：技能、鉤子、MCP、子智能體、斜線命令，一整套全包進去。
這次的新標準只收錄了兩項通用內容：技能和 MCP，其他更花哨的部分未納入。
有趣的是，這次 Anthropic 雖然尚未加入，但格式卻幾乎照著它的樣子設計。
Claude Code 已有一個專門指向插件目錄的根變量，新標準原封不動地搬了過來，僅更換了名稱，作用完全相同，骨架也幾乎一致。
The compatibility layer can't be hidden anymore.
在微軟的 VS Code 官方文檔中，預設插件市場就包含 anthropics/claude-code 這一項。
它同時支援新的開放格式，並繼續認可 Claude 格式的 .claude-plugin/plugin.json。
OpenAI 的 Codex 更是乾脆，連 Claude 原來的變數名都專門保留，以兼容現有的 Claude 插件。
換個說法，大家聚在一起，統一了一套「很像 Claude Code」的格式，但 Anthropic 卻不在場。
創始者，變成了缺席者
一家開創了玩法的公司，在別人將這套玩法定為標準時，全程缺席。
但这並不等於 Anthropic 被關在了門外。
谷歌新推出的兩套工具都將 Claude Code 列為適配對象，它自身還有兩個官方插件市場。
更準確的說法是，Anthropic 向來更願意自己蓋自己的樓。
這次，它沒有坐上這張統一標準的桌，而是繼續經營自己那一整套從格式到市場、再到分發的閉環。
這也不是它第一次在「大家一起来」的場合裡，成為最顯眼的缺席者。
熟悉這家公司的人都知道，它一向先把自己的體系打磨到極致，再談是否要與他人對齊。
這樣做的好處是產品自成體系、體驗統一，代價是每一次行業級的握手，它都容易不在場。
那麼，為什麼是現在？
一旦底層標準達成共識，競爭就會向上提升一層。
舉個例子，商場的地基可以由幾家共同建造，但地基一旦完成，競爭就轉移到了樓上的店面和貨架上。
那是各家公司自己的領域，比拼的不再是谁家模型跑分更高，而是誰的插件生態更大，誰能讓開發者第一個就想到自己。
Six家這次把盒子的規格定了。
但真正決定勝負的不是盒子，是裡面裝的智能體——誰能靠它把開發者留在自己身邊，誰才是贏家。