Agent Plugins 1.0.0 — открытая спецификация, не привязанная к одному вендору. Она описывает, как собирать Agent Skills и MCP-серверы в переносимые плагины. Спецификацию развивает технический управляющий комитет (TSC), куда входят ключевые мейнтейнеры Amazon, Cursor, Microsoft, OpenAI и Vercel. Google присоединяется к группе в качестве основного мейнтейнера; компанию в ней представляет Kevin Hou. Параллельно Google начинает внедрять поддержку формата в своих продуктах.

Представьте обычную историю. Вы написали навык, добавили скрипт или MCP-сервер — и всё это решает вполне приземлённую, но полезную задачу: забирает сведения из базы отчётности, сворачивает их в недельную выжимку, которую команда действительно открывает, а не откладывает «на потом».

Потом решение нужно поставить второму клиенту. И тут начинается возня.

Сам навык в порядке. MCP-сервер — тоже. Проблема прячется в обвязке: другая структура каталогов, иной формат метаданных в манифесте, отличающаяся конфигурация MCP и собственный способ описать транспорт. В итоге появляется форк, затем второй; приходится поддерживать несколько копий одинаковых компонентов, и со временем они неизбежно расходятся. Медленно, но верно.

Корень проблемы — не в самих компонентах. Всё упирается в манифест.

Agent Skills уже дают агентам повторно используемые инструкции и ресурсы. MCP давно решает задачу подключения агентов к инструментам и сервисам. По отдельности оба механизма переносимы. Непереносимой оставалась «коробка» для них — её каждому клиенту приходилось собирать заново, на свой лад.

Разработчикам не стоит выбирать между широким охватом и нативными возможностями конкретного клиента. Нужны оба свойства: предсказуемая структура для общего ядра и свобода для того, что у разных клиентов действительно различается. Это важный практический шаг для проектирования и сборки AI-агентов под конкретную задачу, где повторное использование компонентов быстро становится вопросом не удобства, а экономики.

Поэтому Google становится основным мейнтейнером Agent Plugins и начинает встраивать стандарт в свою продуктовую линейку.

Что на деле представляет собой Agent Plugin

Плагин — это каталог. Собственно, всё. И эта нарочитая простота здесь не случайна.

reports-plugin/
├── plugin.json
├── skills/
│   └── summarize/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
├── mcp.json
└── com.example.client/

В манифесте — всего две действительно важные строки:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "reports-plugin"
}

Остальное лежит в заранее определённых местах. Навыки находятся в skills/: каждый — в собственном подкаталоге и в формате, который уже задаёт спецификация Agent Skills. MCP-серверы перечисляются в mcp.json, причём в каждой записи явно указан тип. Клиенту не нужно гадать о транспорте по форме конфигурационного объекта: поддерживаются stdio, Streamable HTTP и устаревший HTTP+SSE.

Не менее важно то, чего plugin.json делать не может. Он не переносит компоненты в произвольные места и не объявляет их inline. Не надо настраивать путь поиска или разбираться в приоритетах. Нет каталога skills/? Клиент загружает доступные части и идёт дальше. Не стартовал сервер из mcp.json? Навыки всё равно остаются доступными: клиент пропускает проблемную запись, сообщает об ошибке и продолжает загрузку. Независимые компоненты должны отказывать независимо — логично же.

Последний каталог, названный в обратной доменной нотации, служит своего рода аварийным выходом. com.example.client/ — пространство имён, целиком принадлежащее конкретному клиенту: для хуков, агентов, команд и любых других расширений. Клиенты, которым оно незнакомо, просто его игнорируют. Благодаря этому переносимое ядро не разрастается, а для непереносимых особенностей остаётся честное, предусмотренное место. Такая дисциплина особенно полезна при проектировании архитектуры агентных систем сразу под несколько клиентов и сложных интеграций.

Не каждому навыку нужен плагин

Перед созданием плагина стоит на секунду притормозить и спросить себя: он вообще нужен? Если вы поставляете один MCP-сервер одному клиенту, отдельный mcp.json остаётся более простым решением. Есть только один навык — плагин тоже необязателен. Agent Plugins оправдан, когда несколько компонентов должны поставляться вместе и работать как единое целое.

Что намеренно остаётся за рамками

Agent Plugins v1 — это формат пакета и ничего сверх того. Спецификация не определяет установку, протокол распространения, модель разрешений, требования к песочнице, проверку доверия и происхождения, а также пользовательский интерфейс. Эти темы не забыты: они прямо перечислены в планах дальнейшей работы проекта.

Подход выглядит здравым. Установка, политики, корпоративные контроли и UX согласования заметно различаются у IDE, CLI и управляемой корпоративной платформы. У каждого агентного приложения — свои обязательства перед пользователем. В корпоративной среде эти вопросы обычно связывают с защитой агентного контура от чужого кода и требованиями к контролю доступа, а не пытаются решить одной универсальной настройкой.

Плагины в экосистеме: у каждого уровня своя работа

Упаковать компоненты — одна задача. Найти плагин и доставить его пользователю — совсем другая. Смешивать эти уровни не стоит.

• Найти — Agentic Resource Discovery. Открытый протокол обнаружения: клиент спрашивает «что доступно для этой задачи?» и получает подходящие ресурсы. ARD уже рассматривает плагин как ресурс первого класса наряду с агентами, MCP-серверами и навыками Agent Skills. Этот слой работает ещё до вызова.
• Описать — AI Catalog. Это формат записи, который индексирует ARD. В предлагаемом изменении application/agent-plugins+json регистрируется как известный тип: запись каталога сможет ссылаться на plugin.json так же, как сегодня ссылается на карточку агента или mcp.json.
• Упаковать — Agent Plugins. Один каталог, фиксированные расположения и переносимость между клиентами.
• Запустить — MCP и Agent Skills. Уже переносимые контракты исполнения.

Каждый слой полезен сам по себе и может внедряться независимо. Плагин можно опубликовать без записи в каталоге; в каталог можно добавить ресурс, который не является плагином; навыки можно запускать и вовсе без плагина. Принятие одного уровня не тянет за собой остальные — и в этом, пожалуй, главная прелесть.

Что доступно уже сейчас

Сегодня формат поддерживают два продукта Google.

Agents CLI упаковывает экспертные навыки Google для создания, оценки, развёртывания, наблюдаемости и публикации агентов. Так агент для программирования с ИИ — Antigravity, Gemini CLI, Claude Code или Cursor — получает специализированные знания по созданию и эксплуатации агентных систем. Эти навыки можно было распространять и раньше; теперь это возможно в формате, который не принадлежит исключительно Google.

Data Agent Kit предлагает набор плагинов, переносящих возможности Google Data Cloud в выбранный агент для программирования с ИИ или IDE. Решение рассчитано на инженеров данных и разработчиков: агенты могут управлять ресурсами данных, выполнять запросы и развёртывать пайплайны. Поддержка Agent Plugins делает набор навыков и MCP-серверов — для BigQuery, Spanner, Cloud SQL и других сервисов — переносимым между совместимыми клиентами. А когда такие решения объединяются в мультиагентные контуры под один бизнес-процесс, единый формат поставки заметно упрощает жизнь команде.

Google намерена добавить поддержку Agent Plugins и в другие продукты, уже работающие с Skills и MCP-серверами.

Как начать работать с Agent Plugins

• Создайте плагин: заведите каталог, добавьте plugin.json с именем и напишите короткую инструкцию «hello world» в skills/greet/SKILL.md. Всё — это уже валидный плагин. На деле займёт около минуты.
• Изучите документацию, полную спецификацию и список совместимых клиентов. Их, судя по всему, станет больше.
• Посмотрите на плагины Data Agent Kit и на плагин Agents CLI.

Упаковка — инфраструктура неброская. Но именно такой инфраструктурой разумнее делиться, чем изобретать её пять раз под пять клиентов. Область действия Agent Plugins намеренно узкая: формат хорошо делает одну вещь, остаётся открытым и поддерживает совместимость. Поэтому Google и поддерживает этот стандарт.

Если стандарт нужно довести до рабочего контура, а не до демо, мы развернём и сопроводим MCP-серверы под ваши источники данных — с манифестами, версионированием и доступами, которые переживут смену клиента.