OpenAI 與主要科技公司統一 AI 代理插件格式

2026年8月6日，OpenAI、微軟、亞馬遜、Cursor 和 Vercel 聯合推出 Agent Plugins 1.0.0，試圖為 AI Agent 建立一種跨產品通用的插件封裝格式。開發者可將由操作說明、腳本和參考資料組成的 Agent Skills，與連接資料庫、雲服務及開發工具的 MCP 伺服器放入同一個目錄；理論上只需打包一次，即可在 ChatGPT、Codex、VS Code、Cursor、GitHub Copilot 和 Kiro 等相容客戶端中使用。它要解決的不是模型能力問題，而是 Agent 生態正在出現的格式碎片化：目前同一項能力往往需為不同產品分別編寫清單檔案、修改目錄結構並維護多個分支。然而，1.0.0 規範仍標註為「工作草案」，目前僅統一封裝方式，未規定插件商店、安裝協議、權限模型、沙箱隔離和來源驗證。因此，它更像 Agent 生態的「包格式」，還不是一個可以放心安裝任意插件的成熟應用商店。

文章作者、來源：Jonathan Hefner，Vercel 技術團隊成員

過去一年，AI Agent 生態形成了兩類重要擴展能力。

第一類是 Agent 技能。它們通常由一份SKILL.md檔案、相關腳本和參考資料組成，用來告訴 Agent 如何完成某類工作。比如，部署一個網站、分析財務檔案或檢查程式碼安全時，技能可以提供操作步驟、注意事項、驗證規則和可直接執行的程式。

第二類是 MCP 伺服器。MCP 負責讓 Agent 連接外部工具和資料，例如讀取資料庫、操作 GitHub、查詢雲平台狀態，或者調用企業內部系統。Skills 傾向於「教會 Agent 怎樣做」，MCP 則傾向於「給 Agent 提供可以實際調用的工具」。

問題在於，這些組件此前缺少統一的封裝方式。即使一項技能或 MCP 伺服器的核心內容完全相同，開發者將其接入不同 Agent 產品時，仍可能需要分別修改清單檔案、目錄結構和配置欄位。久而久之，同一個擴展會產生多個客戶端專用版本；其中一個版本修復了錯誤，其他分支卻未必同步，最終形成 Google 所說的“分叉與漂移”。

Agent Plugins 需要提供的，就是這些能力外面那個通用的包裝盒。其角色更接近 JavaScript 生態的package.json或容器領域的 OCI 格式：它不取代裡面的代碼和協議，而是統一描述這些東西應當怎樣被組織、發現和加載。

按照1.0.0版规范，一個Agent Plugin是具有固定結構的目錄，根目錄必須包含plugin.json。最簡清單只需要聲明所採用的規範版本和插件名稱。

如果插件包含技能，它們統一放入skills/目錄，每項技能擁有自己的SKILL.md，還可以附帶腳本、參考文件和其他資源。如果插件需要連接外部工具，則在根目錄放置mcp.json，聲明一個或多個MCP伺服器。

MCP 目前支援三種連接方式：本機啟動進程的 stdio、目前推薦的 Streamable HTTP，以及為兼容舊系統而保留的 HTTP+SSE。不同客戶端無需支援所有傳輸方式，但至少需支援 stdio 或 Streamable HTTP 中的一種。

這種固定結構帶來的直接好處是，客戶端不必猜測檔案在哪裡，插件作者也不需要針對每個產品重新設計目錄。一個兼容客戶端即使只支援 Skills、不支援 MCP，也可以繼續讀取技能部分；當某個 MCP 設定出錯時，規範要求客戶端盡可能跳過出錯的伺服器，而不是讓整個插件完全失效。

Agent Plugins 還允許廠商保留專屬功能。客戶端可以用反向域名建立自己的擴展命名空間，例如com.example.client。其他客戶端遇到不認識的專屬配置時應當忽略它，而不是拒絕整個插件。這讓標準能夠提供共同底座，同時不強迫所有產品擁有完全相同的功能。

官方相容清單目前包括 VS Code、Cursor、GitHub Copilot、ChatGPT 與 Codex，以及亞馬遜的 Kiro。Vercel 發起了最初的規範提案，之後由 AWS、Cursor 母公司 Anysphere、微軟、OpenAI 和 Vercel 共同建立初始技術指導委員會；GitHub 也參與了規範完善。

Google 在發布當天宣布加入核心維護工作，並開始讓相關產品支援這一格式。Google 計劃在 Agents CLI 和 Data Agent Kit 中採用 Agent Plugins，使開發者能夠將 BigQuery、Spanner 和 Cloud SQL 等數據能力組合成可移植插件。

這組參與者值得注意，因為它們在模型和產品層面並非同一陣營。微軟擁有 VS Code 和 GitHub Copilot，與 OpenAI 關係密切；Cursor 是獨立的 AI 編程工具；AWS 擁有 Kiro，同時在雲市場與微軟和 Google 競爭；Vercel 則希望成為 AI 應用部署平台。它們願意共同制定封裝標準，說明插件碎片化已開始增加所有廠商的維護成本。

規範採用公開許可，技術討論和決策也計劃在公共項目中進行。它至少在制度設計上試圖避免由單一模型公司完全控制格式。不過，開放治理最終是否有效，仍取決於後續版本的決策過程，以及各家產品會不會大量依賴自己的專屬擴展。

Agent Plugins 最容易引起誤解的地方，是「插件」這個名稱會讓人聯想到瀏覽器擴展或手機應用商店。實際上，目前的 1.0.0 版本只統一了包裝格式，沒有建立完整的插件分發與安全體系。

Google 的官方解讀明確指出，第一版沒有規定插件應當通過什麼協議安裝、從哪裡搜索和下載，也沒有統一權限申請、用戶確認、運行沙箱、發布者身份及來源驗證。這些工作仍由各個 Agent 客戶端自行完成。

規範雖然要求插件內的文件路徑不能通過../或符號連結逃離插件根目錄，但官方特別說明：這種路徑約束不等於對插件進程進行沙箱隔離。一個通過 stdio 啟動的 MCP 伺服器仍然可能執行程式；它究竟可以存取哪些檔案、環境變數、網路和使用者資料，要由用戶端的權限體系決定。

遠端MCP端點原則上必須使用HTTPS，插件也不得直接將密碼或其他秘密寫入公開的請求頭與環境配置中。不過，1.0.0沒有提供通用OAuth配置或可移植的憑證引用機制，認證發現、用戶登錄和憑證保存仍由客戶端處理。

因此，統一格式同時也可能提高惡意擴展的傳播效率。開發者可以「一次打包、到處運行」，攻擊者理論上也能這樣做。未來真正決定該標準能否大規模使用的，可能不是目錄結構，而是簽名、權限提示、供應鏈審查、自動更新和撤銷機制能否及時跟上。

許多 Agent 產品還包含命令、事件鉤子、子 Agent 模板、介面組件以及自定義工作流。制定者並未在第一版中強制統一這些內容，而是僅選擇了 Skills 和 MCP 這兩種已建立一定跨平台基礎的組件。

這是一個較為保守但現實的選擇。如果一開始就試圖規範所有 Agent 的能力，很容易變得龐大，並將某個產品當前的設計固化為整個行業的長期規則。Agent Plugins 先解決最明確的問題：將 Agent 的操作知識和工具整合到同一個可移植的軟體包中。

Google 也特別提醒，並非每一項獨立技能或每一個 MCP 伺服器都需要被打包成插件。插件更適合一組需要共同安裝、共同版本管理與共同遷移的能力。例如，一套資料庫開發插件可同時包含 SQL 查詢技能、資料庫 MCP 連接、故障排除指南和部署腳本；如果僅是一份簡單的說明文件，直接以技能形式分發可能更合適。

如果標準獲得足夠多客戶端支持，開發者不必因為團隊從 Cursor 換到 VS Code、從 Codex 換到其他 Agent，就重新建設全部技能和工具連接。個人或企業長期累積的 Agent 能力可以跟隨用戶遷移，底層模型和客戶端因而更容易被替換。

這會改變 Agent 平台的競爭方式。廠商不能只靠封閉的插件格式留住用戶，而需要在模型質量、執行可靠性、權限控制、界面體驗和插件發現能力上持續競爭。對開發者而言，可移植插件也意味著一次投入能夠覆蓋更多潛在用戶，不必為每一個 Agent 市場重複維護幾乎相同的項目。

但真正的可移植性仍有邊界。客戶端可以只實現規範的一部分，不同產品的授權機制與執行環境也不相同；插件雖然能被識別，卻未必在每個客戶端上獲得完全一致的行為。大量使用廠商專屬命名空間的插件，還可能在形式兼容的外表下重新形成事實鎖定。

此外，MCP 最初由 Anthropic 推動，但 Anthropic 目前並未出現在 Agent Plugins 公布的初始核心維護者或首批正式兼容客戶端名單中。這並不意味著 Claude 未來不會支援該格式，卻說明新的封裝標準尚未覆蓋所有主要 Agent 陣營。

Agent Plugins 目前最大的價值不在於技術複雜度，而在於讓多家競爭廠商承認了同一個問題：模型可以調用越來越多的工具，但如果每個平台都擁有自己的插件包裝方式，Agent 生態會重演早期移動應用和瀏覽器擴展彼此割裂的歷史。

第一版規範非常小，甚至沒有解決插件如何找到、安裝和信任。但這種克制也可能是它的優勢。它先統一最基礎、最容易形成共識的一層，讓 Skills 和 MCP 伺服器擁有共同的運輸方式，再把權限、分發和更多組件留給後續版本。

需要注意的是，官方規範頁面雖然標註版本為 1.0.0，狀態仍是「Working Draft」，後續細節存在調整可能。目前支持也主要來自參與制定標準的廠商，尚不能證明更廣泛的 Agent 生態已經接受它。