Agent Plugins 1.0 — открытый, независимый от поставщиков стандарт, который упаковывает возможности ИИ-агента (навыки, MCP-серверы, команды и правила) в один устанавливаемый плагин: вы создаёте его один раз и запускаете в разных инструментах, вместо того чтобы переделывать под каждый. В августе 2026 года GitHub объявил о полной поддержке стандарта в VS Code, Copilot CLI, приложении Copilot и его SDK во всех тарифах Copilot. Прямой смысл для владельца бизнеса: время и деньги, которые вы тратите на настройку ИИ-инструментов для своей команды, больше не находятся в заложниках у одной платформы.

Какую проблему он на самом деле решает?

За последние два года ИИ-инструменты превратились из окна чата в агентов, которые читают ваши файлы, обращаются к вашим системам и выполняют реальные действия. Чтобы настроить таких агентов под свою компанию, им нужно дать три вещи: письменные инструкции о том, как устроен ваш бизнес, подключение к внутренним системам через MCP-серверы и правила, не позволяющие им выходить за рамки своих полномочий.

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

Что содержит плагин на практике?

Один пакет по этому стандарту прост по форме и чётко определён. Он состоит из:

  • Манифеста plugin.json с названием плагина и номером версии — именно он делает возможными обновление и отслеживание.
  • Папки навыков с письменными инструкциями, которые объясняют агенту, как выполнять повторяющуюся задачу в вашей компании так, как вы этого хотите.
  • Файла mcp.json, который определяет MCP-серверы, связывающие агента с вашими реальными системами: складом, базой клиентов, биллингом.
  • Расширений для конкретных инструментов, размещённых в отдельном пространстве имён, чтобы общие части оставались переносимыми, даже когда отдельный поставщик добавляет собственную функцию.

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

Почему это должно волновать владельца бизнеса, а не только разработчика?

Настоящее различие — в управлении. Стандарт разрабатывается публично под открытой лицензией, а надзор за ним ведёт технический руководящий комитет, в который входят представители Amazon, Microsoft, OpenAI, Cursor и Vercel. Когда конкурирующие компании договариваются об одном формате, это сигнал, что формат переживёт не один продуктовый цикл и что это не попытка одной из сторон привязать к себе клиентов.

Это важно, потому что главный риск при внедрении ИИ сегодня не технический, а договорной. Провайдер, которого вы выбираете сегодня, может поднять цены, закрыть сервис, от которого вы зависите, или изменить качество. Открытый стандарт не устраняет эти риски, но снижает ваши издержки выхода, а низкие издержки выхода — самый сильный козырь на переговорах.

Что это значит для компаний в Саудовской Аравии?

Поскольку 2026 год объявлен в Королевстве Годом искусственного интеллекта, многие компании после нескольких лет демонстраций перешли к этапу серьёзных экспериментов. Повторяющаяся картина, которую мы видим: компания покупает подписки для команды, затем ничего не настраивает и в итоге получает универсального ассистента, который знает всё о мире и ничего о её системах. Настоящая ценность возникает благодаря настройке, а не подписке.

С появлением переносимого стандарта решение о настройке стало гораздо менее рискованным. Компания может написать внутренний плагин, описывающий её цикл согласований, подключить агента к своей системе биллинга или управления заказами и распространить его на всю команду, будучи уверенной, что вложения сохранят ценность, если в следующем году она перейдёт на другой инструмент.

Но учтите один принципиальный момент: то, что пакет переносим, не означает, что доступ к вашим данным становится допустимым. Любой плагин, который подключает агента к вашим внутренним системам, по-прежнему подпадает под действие Закона о защите персональных данных (PDPL), и вы должны точно определить, что агент может и чего не может читать, и задокументировать это.

Практические шаги, чтобы начать на этой неделе

  • Проведите инвентаризацию текущих настроек. Запишите, что ваша команда реально создала в виде инструкций, подключений и правил, и определите, где сегодня находится каждый элемент.
  • Начните с одной повторяющейся задачи. Не переводите всё сразу; выберите один ежедневный процесс, который заметно отнимает время, и упакуйте его в один плагин.
  • Настройте разрешения до распространения. Тарифы Business и Enterprise включают централизованные настройки, которые определяют, какие плагины разрешены и из каких одобренных источников. Настройте это до того, как использование распространится, а не после.
  • Задокументируйте, что переносится, а что нет. Общие части переходят между инструментами; расширения для конкретных инструментов могут и не перейти. Узнайте границы переносимости, прежде чем строить на ней обещания.

Вывод: отрасль движется от хаоса конкурирующих форматов к общему формату, и именно на этом этапе инвестиции в настройку ИИ становятся взвешенным решением, а не азартной игрой. В Origami мы создаём такие плагины и подключения к реальным системам наших клиентов, с самого начала проектируя их так, чтобы владение и гибкость оставались у клиента, а не у поставщика.

Источники

  • Официальное объявление GitHub о поддержке Agent Plugins 1.0: github.blog
  • Официальный сайт стандарта и его технический руководящий комитет: agent-plugins.org
  • Текст спецификации 1.0.0: agent-plugins-spec