5W速覽：2026年8月6日，OpenAI聯合Vercel、微軟、亞馬遜、Cursor母公司Anysphere五方組成技術指導委員會，正式公開發布Agent Plugins 1.0版規範——一種讓AI Agent的「技能」（Skills）和「工具」（MCP伺服器）可以打包成同一種目錄格式、在ChatGPT、Cursor、GitHub Copilot、VS Code、Kiro等不同產品間通用的開放標準。谷歌當天宣布以核心維護者身份加入。這一發布恰好卡在GPT-5發布一週年（8月7日）前一天，被外界解讀為OpenAI「從拼模型轉向拼生態」的信號。本文給出完整時間線、核心資料表、設計取捨拆解、橫向對比、安全爭議與FAQ，並附六步評估/打包清單。
01 發生了什麼：一條從MCP到Agent Plugins的時間線
AI Agent的「可擴展性」問題不是新話題。開發者真正的痛點是：Agent Skills解決了「怎麼給Agent教一套可複用技能」，MCP解決了「怎麼讓Agent連上外部工具和資料」，但兩者的打包、發現方式在不同客戶端（ChatGPT、Cursor、Copilot……）裡各有一套目錄結構和配置習慣——想讓同一個擴展包同時在這些產品裡跑，此前需要為每家平台各寫一份。
- 打包碎片化：同一套 Skills / MCP 配置要為 Claude Code、Cursor、VS Code Copilot 各打一版包裝。
- 發現機制不互通：客戶端認目錄習慣不同，跨產品「一次開發、多端載入」幾乎不可能。
- 安全責任懸空：惡意 Skill 已出現繞過主流掃描的案例，而新標準刻意不覆蓋信任與沙箱——風險原樣傳給下一步。
- 生態話語權博弈：統一包裝利好誰、中國大廠是否缺席，直接影響長期採用路徑。
Agent Plugins要做的，就是把Skills和MCP伺服器這兩種元件，統一裝進同一個「包裝盒」。完整時間線如下：
| 時間 | 事件 |
|---|---|
| 2023年3月 | OpenAI推出ChatGPT Plugins，允許第三方為ChatGPT開發外掛，是早期較開放的擴展生態 |
| 2024年1月 | OpenAI推出GPTs商店後，逐步關閉Plugins，轉向更封閉的平台模式 |
| 2024年11月 | Anthropic發布MCP（Model Context Protocol），標準化Agent連接外部工具/資料的方式，後捐贈給Linux基金會 |
| 2025年3月 | OpenAI、Google相繼宣布支援MCP，行業逐漸統一到這套協議上 |
| 2025年10月16日 | Anthropic在Claude Code中推出Agent Skills，用SKILL.md檔案封裝可複用的操作指令 |
| 2025年12月18日 | Agent Skills獨立為開放標準（agentskills.io），微軟、OpenAI在48小時內跟進支援 |
| 2026年3月 | Agent Skills採用範圍擴大到32款以上工具，包括Gemini CLI、JetBrains Junie、AWS Kiro等 |
| 2026年7月24日 | Agent Plugins規範1.0.0首次以「工作草案」形式發布 |
| 2026年8月6日 | Vercel領頭，聯合OpenAI、微軟、亞馬遜、Cursor正式公開發布Agent Plugins 1.0，谷歌同日加入核心維護者行列 |
Agent Plugins並不是從零發明能力，而是在 MCP（連接）與 Agent Skills（教學）之上，補上「打包與發現」這一層工程契約。
02 核心資料一覽與橫向對比：它和前輩們差在哪
先把規範本身的關鍵事實攤開，再和 ChatGPT Plugins / MCP / Agent Skills 並排對照：
| 專案 | 內容 |
|---|---|
| 規範版本 | Agent Plugins 1.0.0（狀態：工作草案） |
| 發起方 | Vercel（發起提案方） |
| 技術指導委員會（TSC） | 亞馬遜（AWS）、Cursor開發商Anysphere、微軟、OpenAI、Vercel；谷歌8月6日以核心維護者身份加入 |
| 標準覆蓋的元件類型 | 僅2種：Agent Skills、MCP伺服器 |
| 核心檔案 | 根目錄plugin.json清單檔案；skills/目錄存放技能；mcp.json描述MCP伺服器配置 |
| 發布首日支援客戶端 | ChatGPT與Codex、Cursor、GitHub Copilot、Kiro、VS Code |
| 治理方式 | 開放許可、公開儲存庫（GitHub agentplugins/agent-plugins-spec），無單一公司主導路線圖 |
| 標準明確不覆蓋 | 安裝機制、分發/市場、權限模型、沙箱隔離、信任與來源校驗、使用者體驗 |
*資料來源：Vercel官方博客、agent-plugins.org規範文件、Google Developers Blog（均為2026年8月6日發布）。*
| 標準/產品 | 發布方 | 解決的問題 | 現狀 |
|---|---|---|---|
| ChatGPT Plugins（2023） | OpenAI獨家 | 讓第三方為ChatGPT加功能 | 已於2024年停用，轉向封閉的GPTs商店 |
| MCP（2024） | Anthropic發起，後捐贈Linux基金會 | Agent連接外部工具/資料的通訊協定 | 已成為行業事實標準，OpenAI、Google均已支援 |
| Agent Skills（2025） | Anthropic發起，後開放為獨立標準 | 給Agent封裝可複用的操作指令/工作流 | 採用工具超32款，仍在快速擴張 |
| Agent Plugins（2026） | Vercel發起，五巨頭聯合制定 | 把Skills和MCP伺服器統一打包、統一發現 | 剛發布1.0工作草案，谷歌已跟進加入 |
可以看到，Agent Plugins並不是要取代MCP或Agent Skills，而是在這兩層協議之上加了一層「打包契約」——它解決的是「最後一公里」的工程摩擦，而不是重新定義Agent怎麼呼叫工具。
03 深度拆解：它到底標準化了什麼，又為什麼不多做
1. 一個清單檔案，兩種元件
Agent Plugins的技術設計其實很「小」：一個外掛就是一個目錄，根目錄放一個plugin.json清單，宣告這個包遵循哪個版本的規範。如果外掛裡帶了技能，就放在固定的skills/目錄下，且必須符合Agent Skills規範定義的SKILL.md格式；如果帶了MCP伺服器配置，就寫進mcp.json，支援stdio、Streamable HTTP等多種連接方式。客戶端只要認得這套固定的目錄結構，就能自動發現和載入對應元件——不認識的元件類型或格式錯誤，只需跳過該元件而不是拒絕整個外掛。此外還留了「反向域名擴展命名空間」機制（比如com.cursor.xxx/），允許各家客戶端在標準之外附加自己的私有能力，不會汙染通用部分。
my-agent-plugin/
├── plugin.json # 清單：宣告規範版本
├── skills/ # Agent Skills（須符合 SKILL.md）
│ └── .../SKILL.md
├── mcp.json # MCP 伺服器配置（stdio / Streamable HTTP 等）
└── com.cursor.xxx/ # 可選：客戶端私有擴展命名空間2. 故意留白的部分，才是真正的博弈焦點
規範文本裡明確寫著：v1版本「不定義安裝機制、不定義分發協議、不定義權限模型、不要求沙箱隔離、不做信任與來源校驗、不涉及使用者體驗」——這些統統留給各家客戶端自己決定。換句話說，Agent Plugins解決的是「包裝長什麼樣」，不解決「這個包能不能信、裝的時候有沒有風險、去哪兒下載」。這不是疏漏，而是刻意為之的設計取捨：範圍越窄，各方越容易達成一致、越容易落地。但代價是，恰恰最難、最要命的問題——誰來判斷一個外掛是否安全——被明確甩給了每一個客戶端自己去解決。
3. 為什麼這件事現在做，而不是更早
MCP和Agent Skills各自走過了「廠商自造標準→開放捐贈→行業跟進」的路徑（MCP捐給了Linux基金會，Agent Skills由Anthropic主動開放）。這一次Agent Plugins從第一天就是多家公司共同制定，某種程度上是行業吸取了此前「先各自為戰再艱難統一」的教訓，也說明Skills和MCP的採用規模已經大到「不統一打包方式，大家都要重複勞動」的臨界點——據統計，Agent Skills規範發布後半年內採用工具已超過32款。
影響與背景：從「拼模型」到「拼基礎設施」
這次發布還有一個耐人尋味的時間點——8月7日正是GPT-5發布一週年，OpenAI選在這個節點前一天官宣Agent Plugins，同時還在同一周更新了面向免費使用者的GPT-5.6 Luna模型（解除文字對話次數限制）和面向付費使用者的GPT-5.6 Sol（新增「思考強度」滑塊）。這種安排釋放的信號很明確：過去兩年AI行業比拼的是模型參數和榜單排名，但現在無論是OpenAI還是谷歌、微軟，都在同步往「基礎設施/生態」這條線上發力——用Google在官方博客裡的說法，「打包是不體面但必要的基礎設施，這種東西應該被共享，而不是被重新發明五次」。這也和更廣泛的行業敘事吻合：MCP解決了「連接」，Agent Skills解決了「教學」，Agent Plugins解決了「分發」——三層協議疊在一起，才勉強拼出一個「Agent真正能被規模化複用」的技術閉環。
04 六步落地：如何評估與打包一套Agent Plugins
規範剛發布，生產環境不必盲目全量遷移；但若你已在多客戶端維護 Skills / MCP，可用下面六步降低重複勞動與安全風險：
- 盤點現有元件：列出你已有的 Agent Skills（
SKILL.md）與 MCP 伺服器配置，確認它們各自符合現有規範，而不是平台私有格式。 - 建統一目錄骨架：新建外掛根目錄，寫入宣告規範版本的
plugin.json，並把技能放進skills/、把 MCP 配置寫入mcp.json。 - 先在首日支援客戶端驗證：優先在 ChatGPT/Codex、Cursor、GitHub Copilot、Kiro、VS Code 中載入同一包，確認「跳過未知元件」行為符合預期。
- 私有能力走反向域名命名空間：僅某客戶端需要的擴展放進如
com.cursor.xxx/，避免汙染可移植核心。 - 安全審查獨立於標準：標準不覆蓋信任校驗——安裝前走官方市場、核對來源儲存庫、關注 TOCTOU 類連結替換風險，不要只看 star 數。
- 對齊執行時算力環境：外掛再標準，Agent 仍要跑在真實機器上。若工作流依賴 Apple Silicon、iOS 工具鏈或長時間無人值守 Agent，同步評估裸金屬 Mac 節點與虛擬化雲端實例的損耗與穩定性差異（可參考 裸金屬架構宣言）。
05 爭議點、可引用資料、FAQ 與決策結論
爭議點：開放標準≠沒有風險，也≠沒有算盤
- 安全問題被明確甩鍋給客戶端：就在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的五個創始技術指導委員會成員以及後來加入的谷歌，清一色是美國公司；阿里、百度、字節、騰訊等在國內已經普遍支援MCP協議、甚至各自搭建了MCP廣場的廠商，均未出現在這份標準的制定名單裡。這既可能是時間差，也可能預示著中美AI Agent生態在底層協議層面的又一次「平行發展」。
可引用硬核資料（發稿口徑）
- 規範版本與狀態：Agent Plugins 1.0.0，工作草案；2026年7月24日草案首發，8月6日五方公開聯合發布，谷歌同日加入核心維護者。
- 覆蓋範圍：僅打包 Agent Skills 與 MCP 伺服器兩類元件；首日支援客戶端包括 ChatGPT/Codex、Cursor、GitHub Copilot、Kiro、VS Code。
- 安全側旁證：AIR 演示假技能繞過 Cisco / Nvidia / skills.sh 掃描，據稱觸達約 2.6 萬 Agent；Snyk 審計近 4000 個技能，36.8% 有缺陷、13.4% 含致命級問題。
FAQ
Agent Plugins和MCP、Agent Skills是什麼關係？會互相替代嗎？
不會替代。MCP負責「Agent怎麼連接外部工具和資料」，Agent Skills負責「怎麼給Agent封裝一套可複用的操作指令」，Agent Plugins則是在這兩者之上加了一層統一的打包和發現格式，讓開發者能把Skills和MCP伺服器一起塞進同一個目錄、被不同客戶端認出來。三者是分層關係，不是競爭關係。
普通開發者現在需要關心Agent Plugins嗎？
如果你正在給Claude Code、Cursor、ChatGPT等多個Agent工具分別開發擴展，且已經在用Agent Skills或MCP伺服器，那麼值得關注——用這套格式打包一次，理論上能同時被多家客戶端識別，減少重複勞動。如果只是普通使用者，短期內感知不會很明顯。
這個標準安全嗎，會不會被惡意外掛利用？
標準本身不提供安全保障——它只定義「包裝長什麼樣」，不涉及掃描、沙箱、來源校驗。安全責任完全在各家客戶端手裡。鑑於此前已經出現過繞過多個主流掃描器的惡意Agent Skill案例，建議安裝任何Agent外掛前，仍要通過官方市場、核實來源，不要盲目信任star數或「看起來正規」的儲存庫。
國內廠商（阿里、百度、字節等）會跟進這個標準嗎？
目前這些廠商都還沒有出現在Agent Plugins的制定名單裡，但它們此前已普遍支援MCP協議。考慮到該標準完全開放、任何客戶端都可以自行實現，不排除後續國內工具跟進適配，但目前沒有官方公開計劃，建議關注後續動態。
Agent Plugins會不會像2023年的ChatGPT Plugins一樣，過一段時間就被放棄？
兩者背景不同。ChatGPT Plugins是OpenAI獨家產品、決策權在一家公司手裡，說停就能停。Agent Plugins從第一天就是多家公司共同治理的開放標準，任何一家單獨退出也不影響規範本身的存續。但開放標準也有自己的風險——如果實際使用者寥寥，或者各家客戶端更願意投入資源做私有擴展，標準同樣可能被「晾在一邊」。目前處於剛發布階段，能否真正被廣泛採用還需要觀察後續幾個月的落地情況。
資料與報道來源（資訊截至2026年8月7日整理，發佈後請以最新官方文件為準）：
Vercel 官方博客：Introducing Agent Plugins（2026-08-06）
agent-plugins.org：Agent Plugins Specification 1.0.0（工作草案）
Google Developers Blog：Agent Plugins package your skills, tools, and more（2026-08-06）
The Next Web：OpenAI and four rivals just agreed on one standard for AI agents
Virtualization Review：Cloud Giants Back Agent Plugins for Cross-Client AI
開放標準統一了「包裝盒」，但沒有統一信任、沙箱與安裝路徑；各客戶端私有擴展仍會繼續分化，惡意 Skill 風險也不會因為多了一層 plugin.json 而自動消失。對企業側來說，把 Agent 工作流全部押在單一虛擬化雲端實例上，常見問題是 Hypervisor 損耗、Apple Silicon / iOS 工具鏈相容差、以及長週期無人值守穩定性不足。若你的團隊需要零損耗原生算力、穩定 iOS CI/CD 與 AI Agent 7×24 自動化，ZUKCLOUD 的裸金屬 Mac mini 雲端節點通常是更優解：獨占 Apple Silicon 實體機、無 Hypervisor 損耗、7×24 上線、按天/週/月彈性下單。可先看 定價頁 或直接前往 下單頁。