Agent Plugins v1.0 是什麼？跨 Agent 開放標準的承諾與缺口（2026）

2026 年 8 月 7 日（台北時間），OpenAI Developers 在 X 公開了 Agent Plugins 公告，第一句是「Build a plugin once and use it across compatible agent clients」；GitHub 主分支則已在 7 月 28 日（台北時間；UTC 為 7 月 27 日）把 Agent Plugins v1.0.0 規格標為 Published。

這則公告真正值得看的，不是又多了一個「plugin」名詞，而是幾家彼此競爭的 AI client，開始共用同一個套件底層。這篇會先忠實還原它承諾了什麼，再把規格、相容清單、治理與安全邊界逐一對帳，最後回答最實際的問題：Agent Plugins v1.0 到底省掉了哪些重工，又有哪些差異仍得為每個 client 各做一次？

公告的核心承諾：一份 plugin，可被多個 Agent client 讀懂

Build a plugin once and use it across compatible agent clients.

中文：做一次 plugin，就能在相容的 Agent client 間使用。

OpenAI Developers

公告把 Agent Plugins 描述成由 OpenAI 與 AWS、Cursor、GitHub、VS Code、Vercel 共同開發的開放標準，並在後續貼文列出六個首發相容 client：Codex、ChatGPT、Cursor、GitHub Copilot、Kiro、VS Code。這不只是未具名的未來願景：官方相容清單已列出每個 client 宣告可載入的元件與 MCP transport，Codex、Cursor、Kiro、Copilot CLI 與 VS Code 另有公開程式碼或產品文件可交叉確認；ChatGPT 部分則只能確認 OpenAI 的官方支援聲明。

社群反應也很快。本文在 2026 年 8 月 9 日 20:17（台北時間）截點時，主公告的公開資料顯示 2,315,952 次瀏覽、7,260 個讚；規格 repo則有 732 stars、41 forks。這證明話題已經出圈，但還不能證明工程團隊大規模採用——瀏覽與按讚衡量注意力，安裝量、相容測試與維護中的 plugin 數量才會回答落地程度。

先拆掉最大誤會：v1.0 只標準化兩種可攜元件

Agent Plugins v1 defines exactly two component types: skills and MCP servers.

中文：Agent Plugins v1 明確只定義兩種元件：Skills 與 MCP servers。

Agent Plugins Specification v1.0.0

這句是整篇最重要的邊界。Agent Skill可以理解成一個裝著指令、腳本、參考資料與資產的能力資料夾；MCP server 則把工具或資料來源接給 Agent。Agent Plugins v1.0 沒有取代這兩套標準，而是在它們外面加上一層固定包裝，讓 client 知道該去哪裡找。

my-plugin/
├── plugin.json                 # 必要：套件 manifest
├── skills/                     # 選配：Agent Skills
│   └── my-skill/
│       └── SKILL.md
├── mcp.json                    # 選配：MCP server 設定
└── com.example.client/         # 選配：特定 client 擴充

共同格式的價值很樸素：根目錄有一份 plugin.json，Skills 固定放進 skills/，MCP 設定固定放在 mcp.json；client 再把支援的部分映射到自己的系統。當 client 啟動 stdio MCP subprocess 時，規格也定義 PLUGIN_ROOT、PLUGIN_DATA 等執行期約定，減少每個平台各自發明路徑與設定欄位的重工。

UI 不在這兩種元件裡。如果 MCP server 要提供互動畫面，而且 host 支援這項選配 extension，可以另循 MCP Apps 開放標準提供 UI；那是另一層互通機制，不應寫成 Agent Plugins v1.0 自己打包了第三種「可攜 UI 元件」。這個區分看似吹毛求疵，實際上會直接影響開發者對支援範圍的預期。

哪些東西真的可攜？哪些仍由 client 決定？

共同互通層	仍由各 client 決定
套件根目錄與 plugin.json	安裝入口、marketplace、更新流程
skills/ 的探索位置	Skill 如何顯示、何時載入、模型如何使用
mcp.json 的 server 設定格式	支援哪些 transport、登入與憑證保存
啟動 stdio MCP 時的 PLUGIN_ROOT、PLUGIN_DATA 約定	權限提示、信任政策、sandbox 與稽核
可驗證的 schema 與錯誤隔離規則	client-specific extensions、UI 與最終使用體驗

規格甚至明寫，合規 client 不必支援所有元件類型；在符合 §1–10 其他適用要求的前提下，支援 Skills 或 MCP 其中一種就能符合最低要求。若支援 MCP，也只需在 stdio 與 streamable-http 中至少實作一種。因此最精確的說法不是「一次安裝、到處完整運作」，而是：同一個套件的可攜核心，可被多個相容 client 辨識與載入；每個 client 實際啟用的子集可能不同。

六個首發 client，不等於六份完全相同的體驗

截至 2026 年 8 月 9 日，官方矩陣把 ChatGPT 與 Codex 合併成一列，再列出 VS Code、Cursor、Kiro、GitHub Copilot。五列都標示支援 Agent Skills 與 MCP；其中 ChatGPT／Codex 列出 stdio、Streamable HTTP，其餘四列還列出 legacy SSE。光是 transport 清單不同，就足以說明「相容」不是「完全一致」。

但這張表是專案方公布的支援矩陣，不是共同 conformance suite 的測試報告；官方 Future Considerations 也明寫，目前尚未指定 test harness 或 validation tool。

• Codex：OpenAI 的公開程式碼已有辨識 Agent Plugins manifest，並把 metadata、skills/、mcp.json 映射進 Codex plugin manifest 的實作。
• ChatGPT：OpenAI 的首發貼文與官方矩陣都把它列為相容 client；但相容頁提供的 source-code 連結指向 Codex repo，因此本文能確認的是 ChatGPT 官方支援聲明，不能用同一份公開程式碼逐行驗證 ChatGPT 行為。
• Cursor、Kiro：Cursor與 Kiro 官方文件都說明如何載入 Agent Plugins，同時保留自家擴充。
• GitHub Copilot：官方矩陣把 GitHub Copilot 廣義列入支援；Copilot CLI plugin reference 另明確記載，以 canonical $schema 啟用 Agent Plugins v1.0.0 semantics。
• VS Code：官方文件已說明根 manifest、Skills 與 MCP。支援由 chat.plugins.enabled 控制；設定參考頁顯示預設值為 false，且可由組織政策管理，部分 marketplace 與本機位置設定另標為 Experimental。

另一個容易混淆的地方，是原生格式仍會並存。各 client 可以在共同底層之外加入專用能力；Claude Code 目前也有自己的 .claude-plugin 格式。Agent Plugins v1.0 能減少重複整合，卻沒有消滅每個產品的 adapter layer。

還有一個重要邊界：Agent Skills 官方文件明載，這個底層格式最初由 Anthropic 開發；但截至 2026 年 8 月 9 日，Agent Plugins v1 的共同開發公告、TSC 與首發相容清單都沒有列出 Anthropic／Claude Code。這只代表它不是首發名單中的 v1 client，不等於未來不能支援。

它為什麼可以叫「開放標準」？

公開文件顯示，這不是由 OpenAI 單獨治理的產品格式。Core Maintainers分別來自 Amazon、Cursor、Microsoft、OpenAI、Vercel；治理章程規定席位屬於個人、公司沒有保留席，而且單一 vendor 不得掌握多數 Core Maintainer 席次。依授權文件，除檔案另有授權聲明外，規格文字與文件等採 CC BY 4.0，schema、原始碼與腳本等軟體材料採 Apache 2.0；第三方素材仍依原授權。

所以「多家公司共同推動、vendor-neutral」有制度與授權依據。不過，這裡的 open standard 是專案以公開規格、授權與社群治理建立的標準，不應自動等同於 ISO 或 IETF 那類正式標準組織的認證。真正的中立性，還要看未來提案、維護權與相容測試是否持續由多方參與。

制度上的 vendor-neutral，也不等於實際編輯工作平均分散。截至 2026 年 8 月 9 日，按公開 git 歷史的 author 統計，repo 的 79 次提交中，76 次來自 Lead Core Maintainer Jonathan Hefner（Vercel）；章程提到代管名稱、網域與 GitHub 組織的「中立實體」，但沒有列出實體名稱。commit 數不包含 review、squash 或線下協作，不能反過來否定多家公司參與，卻足以提醒讀者把制度設計與實際貢獻分布分開看。

版本狀態目前還有一個小但值得記錄的瑕疵：repo 在 7 月 28 日（台北時間；UTC 為 7 月 27 日）已把 v1.0.0 標成 Published，但本文查核時，agent-plugins.org 的規格頁仍顯示 Working Draft，GitHub 也沒有 tag或 Release。兩個官方入口的狀態尚未同步；公開資料不足以判斷是網站部署延遲，還是正式 release 流程尚未完成。主分支規格文字本身已可用固定 schema URL 與 commit 鎖定。

最需要冷靜看的，是安全與信任層

v1.0.0 does not define a trust model, permission system, or sandboxing requirements for plugins.

中文：v1.0.0 沒有定義 plugin 的信任模型、權限系統或 sandbox 要求。

Agent Plugins Future Considerations

Plugin 可能帶著腳本、啟動本機程式，或連上遠端 MCP server。規格雖要求 package path containment、非 loopback endpoint 使用 HTTPS，並禁止 client 在未取得明確使用者授權時，把設定的 headers 轉送到不同 origin，但它也明確說明：路徑限制不會替 subprocess 建立 sandbox。套件來源驗證、簽章、權限提示與秘密注入沒有被 v1 統一；v1 也沒有 OAuth 設定或可攜的 credential-reference 欄位，授權探索、使用者互動與憑證保存交由各 client 管理。

這不是 v1.0 「做錯了」，而是它刻意先把範圍壓到各家最容易同意的最低層。代價則是：同一個 plugin 在 A client 被隔離執行，在 B client 可能要求不同權限，在 C client 又可能根本不支援所需 transport。格式可攜，風險不會因此自動可攜或自動消失。

AlphaLab 的判讀：這是一塊重要地基，還不是完工的房子

1. 真正被標準化的是「包裝」，不是 Agent 的所有能力

這反而是 Agent Plugins v1.0 最合理的地方。MCP 已經處理工具與資料的連接，Agent Skills 已經處理可重用工作知識；新標準若再發明一套競爭協定，只會增加碎片化。現在它做的是把現有零件放進固定紙箱、貼上共同標籤，讓不同 client 至少知道怎麼拆箱。

2. 六個首發 client，讓它比「只有規格、沒有實作」更有機會

跨廠商標準最常死在雞生蛋問題：沒有 plugin，client 不想支援；沒有 client，作者不想打包。這次 Codex、ChatGPT、Cursor、GitHub Copilot、Kiro、VS Code 同時站上首發名單，至少先把供需兩端的起跑線鋪出來。是否成功，接下來要看真實 plugin 能不能通過多 client 測試，而不是看名單繼續變長。

3. client-specific extension 不是失敗，而是必要的逃生門

如果標準強迫所有產品只做共同功能，創新會被最低公分母鎖死；如果完全沒有共同層，作者又得維護六份套件。v1.0 的折衷是「portable core ＋ client adapter」：共同能力放 Skills／MCP，特定 client 的 manifest 資料可放進 extensions.<reverse-domain>，相關檔案則放在同名的頂層目錄，兩者都不是可攜元件。這不會把重工降到零，但能把重複範圍縮小到真正不同的部分。

4. 2.3 百萬瀏覽是注意力，不是相容性的驗收單

X 的百萬級觸及和 GitHub 數百顆 stars，只能顯示跨 Agent 可攜性這個命題獲得高度注意，不能證明讀者為何互動，更不能證明實際採用。但一個開放標準最終要靠枯燥的東西活下來：官方 Future Considerations 明確列入 conformance test suites、簽章與來源驗證；支援矩陣與 v1 版本規則已經存在，但截至本文查核，repo 沒有 tag 或 Release，規格也沒有指定標準 test harness／conformance suite。

我同意的部分：用最小共同層包住 Agent Skills 與 MCP，是目前降低生態系重工最務實的路；多方治理與六個首發 client，也讓這次合作不只是 OpenAI 的單邊格式。

我存疑的部分：「Build once」很容易讓人腦補成「Install once, works the same everywhere」。v1.0 沒有承諾這件事。只要安裝、權限、驗證、transport、UI 與原生擴充仍分散在 client 端，plugin 作者就必須把「可攜核心」與「平台適配」分開規劃。

現在要怎麼用這個標準？

1. 如果你在寫 plugin：先把通用能力收斂成 Skills 與 MCP，至少挑兩個不同公司的 client 做實測；平台專用功能留在 adapter，不要假設其他 client 會讀取。
2. 如果你在選工具：先看官方相容矩陣，再查該 client 的安裝、transport、權限與 Preview 狀態；「支援 Agent Plugins」不是一個只有是／否的開關。
3. 如果你負責企業治理：把 plugin 當成可能執行程式與連接資料的供應鏈元件，要求來源、版本、權限、秘密管理與撤銷流程，不要把 schema 驗證誤認成安全審查。
4. 如果你在觀察生態系：接下來別只數 stars。更有意義的指標是跨 client 測試案例、相容性 bug 的修復速度、簽章／信任層是否落地，以及第三方 plugin 是否真的只維護一份 portable core。

最值得做的第一步很簡單：挑一個你已經在用的 Skill 或 MCP server，把它整理成最小 Agent Plugins v1.0 套件，然後在兩個 client 上對照行為。能共用的留下來，不能共用的明確寫進 adapter 與測試；這會比任何「跨 Agent」口號更快告訴你，標準目前真正走到了哪裡。