Agent Plugins 是什麼？OpenAI 聯合五巨頭發布的 AI 擴充套件「統一包裝」標準
解決了什麼、又留下了什麼坑

發生了什麼：一條從 MCP 到 Agent Plugins 的時間線

AI Agent 的「可擴充性」問題不是新話題。Agent Plugins 是這條技術演進鏈上最新的一環，而不是從零發明：

Agent Skills 解決了「怎麼給 Agent 教一套可重用技能」，MCP 解決了「怎麼讓 Agent 連上外部工具和資料」，但兩者的打包、發現方式在不同用戶端裡各有一套目錄結構和設定習慣。Agent Plugins 要做的，就是把 Skills 和 MCP 伺服器這兩種元件，統一裝進同一個「包裝盒」。

核心數據一覽

資料來源：Vercel 官方博客、agent-plugins.org 規範文件、Google Developers Blog（均為 2026 年 8 月 6 日發布）。

深度拆解：它到底標準化了什麼，又為什麼不多做

1. 一個清單檔案，兩種元件

Agent Plugins 的技術設計其實很「小」：一個擴充套件就是一個目錄，根目錄放一個 plugin.json 清單，聲明這個套件遵循哪個版本的規範。如果擴充套件裡帶了技能，就放在固定的 skills/ 目錄下，且必須符合 Agent Skills 規範定義的 SKILL.md 格式；如果帶了 MCP 伺服器設定，就寫進 mcp.json，支援 stdio、Streamable HTTP 等多種連線方式。用戶端只要認得這套固定目錄結構，就能自動發現和載入對應元件——不認識的元件類型或格式錯誤，只需略過該元件而不是拒絕整個擴充套件。此外還留了「反向網域擴充命名空間」機制（比如 com.cursor.xxx/），允許各家用戶端在標準之外附加自己的私有能力，不會污染通用部分。

2. 故意留白的部分，才是真正的博弈焦點

規範文本裡明確寫著：v1 版本「不定義安裝機制、不定義分發協定、不定義權限模型、不要求沙盒隔離、不做信任與來源校驗、不涉及使用者體驗」——這些統統留給各家用戶端自己決定。換句話說，Agent Plugins 解決的是「包裝長什麼樣」，不解決「這個套件能不能信、裝的時候有沒有風險、去哪兒下載」。這不是疏漏，而是刻意為之的設計取捨：範圍越窄，各方越容易達成一致、越容易落地。但代價是，恰恰最難、最要命的問題——誰來判斷一個擴充套件是否安全——被明確甩給了每一個用戶端自己去解決。

3. 為什麼這件事現在做，而不是更早

MCP 和 Agent Skills 各自走過了「廠商自造標準→開放捐贈→業界跟進」的路徑。這一次 Agent Plugins 從第一天就是多家公司共同制定，某種程度上是業界吸取了此前「先各自為戰再艱難統一」的教訓，也說明 Skills 和 MCP 的採用規模已經大到「不統一打包方式，大家都要重複勞動」的臨界點——據統計，Agent Skills 規範發布後半年內採用工具已超過 32 款。

橫向對比：Agent Plugins 和它的「前輩們」

爭議點：開放標準≠沒有風險，也≠沒有算盤

• 安全問題被明確甩鍋給用戶端：就在 Agent Plugins 發布前一個月，資安公司 AIR 公開示範了一次「假技能」攻擊——一個名為 brand-landingpage 的惡意 Agent Skill，借用一個擁有 3.6 萬星標的知名倉庫的信譽，成功繞過了 Cisco、Nvidia、skills.sh 等多家安全掃描工具，據稱觸及約 2.6 萬個 Agent（部分為企業帳號）。核心漏洞是經典的「檢查時－使用時」（TOCTOU）時間差：掃描時連結指向的是正常文件，通過審核後再悄悄替換成惡意位址。Snyk 同期對近 4000 個已上線技能的稽核也發現，36.8% 存在安全缺陷，13.4% 含有致命級問題（惡意程式碼、憑證外洩等）。Agent Plugins 標準本身完全沒有涉及這類信任與來源校驗機制。
• 「這是不是一個太單薄的標準」：開發者工具框架 SST 的作者 Dax Raad 公開表示「非常反對」這份標準，認為它是「一個很薄的標準」，真正有用的部分最終還是會被各家用戶端做成自己的私有擴充。但也有開發者（如開發者布道師 Angie Jones）對此表示歡迎，認為終於有了一種方式，能把自己累積的技能包在不同工具間搬來搬去，不用來回重寫。
• 統一「包裝規格」到底利多誰：支持者的邏輯是，統一包裝能讓中小型開發者一次開發、同時觸及 ChatGPT、Cursor、Copilot 等所有主流用戶端的使用者。但反過來看，標準往往利多已經擁有使用者基數的頭部用戶端——因為不管擴充套件包裝得多標準，使用者還是要先打開一個具體的 Agent 產品才能用上它。
• 區域廠商集體缺席治理席位：值得注意的是，Agent Plugins 的五個創始技術指導委員會成員（Vercel、OpenAI、微軟、亞馬遜、Cursor 母公司 Anysphere）以及後來加入的 Google，清一色是美國公司。此前已在本地生態中廣泛支援 MCP、甚至各自搭建了 MCP 廣場的多家區域廠商，均未出現在這份標準的制定名單裡。這既可能是時間差（標準剛發布，後續不排除跟進），也可能預示著不同區域 AI Agent 生態在底層協定層面的又一次「平行發展」。

影響與背景：從「拼模型」到「拼基礎設施」

這次發布還有一個耐人尋味的時間點——8 月 7 日正是 GPT-5 發布一週年，OpenAI 選在這個節點前一天官宣 Agent Plugins，同時還在同一週更新了面向免費使用者的 GPT-5.6 Luna 模型（解除文字對話次數限制）和面向付費使用者的 GPT-5.6 Sol（新增「思考強度」滑桿）。這種安排釋出的訊號很明確：過去兩年 AI 業界比拼的是模型參數和榜單排名，但現在無論是 OpenAI 還是 Google、微軟，都在同步往「基礎設施／生態」這條線上發力——用 Google 在官方博客裡的說法，「打包是不體面但必要的基礎設施，這種東西應該被共享，而不是被重新發明五次」。

這也和更廣泛的業界敘事吻合：MCP 解決了「連接」，Agent Skills 解決了「教學」，Agent Plugins 解決了「分發」——三層協定疊在一起，才勉強拼出一個「Agent 真正能被規模化重用」的技術閉環。對需要在真實 macOS 環境裡驗證 Skills、MCP 與本地工具鏈的團隊來說，獨享物理 Apple Silicon 節點（非虛擬機、完整 Root／sudo、SSH 與 VNC 雙通道）往往比自建機房更快落地——可從 RUVCLOUD 下單頁按日起租。