OpenAI та великі технологічні компанії об’єднали формат плагінів для AI-агентів

6 серпня 2026 року OpenAI, Microsoft, Amazon, 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, ніж на зрілу платформу для безпечного встановлення будь-яких плагінів.

Автор статті, джерело: Джонатан Гефнер, член технічної команди Vercel

За останній рік екосистема AI-агентів розширилася на дві важливі напрямки.

Першого типу — це навички агента. Вони зазвичай складаються з файлуSKILL.md, відповідних сценаріїв та довідкових матеріалів, які вказують агенту, як виконувати певний тип робіт. Наприклад, при розгортанні веб-сайту, аналізі фінансових документів чи перевірці безпеки коду, навички надають кроки дій, зауваження, правила перевірки та безпосередньо виконувані програми.

Другий тип — сервери MCP. MCP забезпечує підключення агентів до зовнішніх інструментів і даних, наприклад, читання баз даних, роботу з GitHub, запити стану хмарних платформ або виклик внутрішніх корпоративних систем. Навички зосереджені на «навчанні агента, як робити», тоді як MCP зосереджений на «наданні агенту практично доступних інструментів».

Проблема полягає в тому, що раніше ці компоненти не мали єдиної упаковки. Навіть якщо навичка або основний вміст MCP-сервера повністю однакові, розробник, підключаючи їх до різних продуктів Agent, все одно може змушений окремо змінювати файли маніфесту, структуру каталогів та поля конфігурації. З часом один і той самий розширення створює кілька версій, прив’язаних до клієнтів; коли одна версія виправляє помилку, інші гілки не обов’язково синхронізуються, що в кінцевому підсумку призводить до те, що Google називає «розгалуженням та відхиленням».

Agent Plugins мають надати саме ці можливості у зовнішньому універсальному контейнері. Їхня роль ближча до package.json у екосистемі JavaScript або формату 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 від Amazon. Vercel ініціював початкову пропозицію стандарту, після чого початковий технічний керівний комітет було створено AWS, Anysphere (материнською компанією Cursor), Microsoft, OpenAI та Vercel; GitHub також взяв участь у вдосконаленні стандарту.

Google оголосила про приєднання до основного супроводу в день випуску та початок підтримки цього формату відповідними продуктами. Google планує використовувати Agent Plugins у Agents CLI та Data Agent Kit, щоб розробники могли поєднувати функції даних, такі як BigQuery, Spanner та Cloud SQL, у переносимі плагіни.

Ця група учасників варта уваги, оскільки вони не належать до одного й того ж лагеря на рівні моделей та продуктів. Microsoft володіє VS Code та GitHub Copilot і тісно пов’язана з OpenAI; Cursor — це незалежний інструмент AI для програмування; AWS володіє Kiro та конкурує з Microsoft і Google на ринку хмарних послуг; Vercel прагне стати платформою для розгортання AI-додатків. Їх бажання спільно розробити стандарти упаковки свідчить про те, що фрагментація плагінів вже почала збільшувати витрати на підтримку для всіх компаній.

Стандарт використовує відкриту ліцензію, а технічні обговорення та рішення також плануються проводити в публічних проектах. Він хоча б у теоретичному проектуванні намагається уникнути повного контролю формату однією компанією. Однак ефективність відкритого управління в кінцевому підсумку залежатиме від процесу прийняття рішень у майбутніх версіях, а також від того, чи будуть продукти різних компаній сильно залежати від власних ексклюзивних розширень.

Найбільш частою помилкою щодо плагінів агента є те, що назва «плагін» викликає асоціації з розширеннями браузера чи магазинами додатків для смартфонів. Насправді, поточна версія 1.0.0 лише уніфікувала формат упаковки, але не створила повноцінної системи розповсюдження та безпеки плагінів.

Офіційна інтерпретація Google чітко вказує, що перша версія не встановлювала, яким протоколом слід встановлювати плагіни, де шукати та завантажувати їх, а також не передбачала єдиних вимог до запиту дозволів, підтвердження користувачем, роботи в пісочниці, перевірки ідентичності та джерела видавця. Ці завдання залишаються на розсуд кожного клієнта Agent.

Хоча вимоги передбачають, що шляхи файлів у плагіні не можуть виходити за межі кореневої директорії плагіну за допомогою../або символічних посилань, офіційно зазначено: таке обмеження шляхів не означає ізоляції процесу плагіна в пісочниці. MCP-сервер, запущений через stdio, все ще може виконувати програми; які саме файли, змінні оточення, мережа та користувацькі дані до них доступні, визначається системою прав клієнта.

Віддалені MCP-ендпоінти за принципом повинні використовувати HTTPS, а плагіни не повинні прямо вписувати паролі чи інші секрети у публічні заголовки запитів та конфігурації середовища. Однак у версії 1.0.0 відсутні загальні налаштування OAuth або переносні механізми посилань на облікові дані; виявлення автентифікації, увійти користувача та збереження облікових даних все ще обробляються клієнтом.

Тому уніфікація формату також може підвищити ефективність поширення зловмисних розширень. Розробники можуть «один раз зібрати — запускати будь-де», і зловмисники теоретично можуть робити те саме. У майбутньому справжнім фактором, що вирішить, чи буде цей стандарт широко використовуватися, може бути не структура каталогів, а чи зможуть підпис, підказки дозволів, перевірка ланцюжка постачань, автоматичне оновлення та механізми відкликання вчасно залишатися на одному рівні.

Багато продуктів Agent також мають команди, подійні хуки, шаблони суб-Agent, інтерфейсні компоненти та користувацькі робочі процеси. Розробники не намагалися уніфікувати ці елементи у першій версії, а вибрали лише два компоненти — Skills і MCP, які вже мають певну міжплатформну основу.

Це більш консервативний, але реалістичний вибір. Якщо спочатку спробувати визначити всі можливості агентів, стандарт легко стане надто об’ємним і заморозить поточний дизайн певного продукту як довгострокове правило для всієї галузі. Агент-плагіни спочатку вирішують найбільш очевидні проблеми: поєднуючи знання та інструменти для дій агента в один переносний програмний пакет.

Google також звертає увагу, що не кожну окрему навичку чи кожен сервер MCP потрібно упаковувати як плагін. Плагіни краще підходять для групи навичок, які потребують спільної встановлення, спільного управління версіями та спільного перенесення. Наприклад, набір плагінів для розробки баз даних може одночасно містити навички SQL-запитів, підключення MCP до бази даних, керівництва з виправленням помилок та сценарії розгортання; якщо ж це лише окремий простий файл із поясненнями, то його краще розповсюджувати як окрему навичку.

Якщо стандарт отримає достатню підтримку з боку клієнтів, розробникам не доведеться заново будувати всі навички та з’єднання інструментів, коли команда переходить з Cursor на VS Code або з Codex на інший агент. Навички агентів, накопичені особисто або підприємством протягом тривалого часу, можуть супроводжувати користувача під час переходу, що робить нижчі рівні моделей та клієнтів легшими для заміни.

Це змінить спосіб конкуренції на платформі Agent. Виробники не можуть більше залежати від закритих форматів плагінів для утримання користувачів, а повинні постійно конкурувати якістю моделей, надійністю виконання, контролем прав доступу, досвідом інтерфейсу та здатністю до виявлення плагінів. Для розробників переносимі плагіни означають, що одноразові вкладення дозволять охопити більше потенційних користувачів, не потребуючи повторного підтримування майже ідентичних проектів для кожного ринку Agent.

Але справжня переносимість все ще має межі. Клієнти можуть реалізовувати лише частину специфікації, а механізми авторизації та середовища виконання різних продуктів відрізняються; плагіни хоча й виявляються, але не завжди працюють однаково на кожному клієнті. Широке використання плагінів із власними іменними просторами виробника може призвести до фактичного залежності, навіть якщо зовні вони сумісні.

Крім того, MCP спочатку розроблявся Anthropic, але Anthropic наразі відсутній у списку початкових основних супроводжувачів або перших офіційно сумісних клієнтів, опублікованих у Agent Plugins. Це не означає, що Claude не підтримає цей формат у майбутньому, але свідчить про те, що новий стандарт упаковки ще не охоплює всі основні групи Agent.

Найбільша цінність Agent Plugins зараз не в технічній складності, а в тому, що кілька конкуруючих виробників погодилися з однією проблемою: моделі можуть використовувати все більше інструментів, але якщо кожна платформа матиме власний спосіб обгортки плагінів, екосистема Agent повторить історію розколу між ранніми мобільними додатками та розширеннями браузерів.

Перша версія специфікації дуже мала і навіть не вирішувала, як плагіни мають знаходити, встановлювати та довіряти. Але ця обережність також може бути її перевагою. Спочатку вона уніфікує найбільш базовий і найлегший для досягнення консенсусу рівень, надаючи Skills і MCP-серверам спільний спосіб транспортування, а повноваження, розповсюдження та інші компоненти залишає для майбутніх версій.

Варто зауважити, щоофіційна сторінка з нормамихоча позначена версією 1.0.0, статус залишається «Working Draft», і подальші деталі можуть бути змінені. Наразі підтримка надається переважно виробниками, що брали участь у розробці стандарту, і ще не доведено, що ширший екосистемний агент прийняв його.