Пять протоколов для ИИ-агентов в 2026 году: что внедрять сейчас, а что подождёт

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

Что нужно знать до того, как внедрять что-либо

Раньше GEO/AEO сводилось в основном к одному вопросу: может ли ИИ прочитать и процитировать вашу страницу (об этом у меня есть отдельный разбор патента на «персистентный агентский поиск» — поиск, который не заканчивается на выдаче). Пять протоколов ниже расширяют этот вопрос на три новых действия ИИ: найти нужный ресурс среди множества сайтов, подключиться к вашим данным и инструментам напрямую, и совершить транзакцию от лица пользователя, не выходя из чата.

Они не заменяют классическое SEO и разметку Schema.org — они надстройка поверх уже готового фундамента. Не все протоколы одинаково зрелые: у одних версия 0.1 и статус общественной инициативы, у других — консорциум Google, Microsoft, Anthropic и десятков других компаний. Ниже — от самого простого к самому сложному, с честной оценкой, что из этого стоит делать уже сейчас.

llms.txt

Простыми словами: это файл в корне сайта, который в двух словах объясняет ИИ, что это за сайт и куда смотреть дальше — как оглавление книги, но для роботов. Формально — открытая инициатива, предложенная в сентябре 2024 года Джереми Ховардом (создателем fast.ai), стандартизирующая то, что сайт отдаёт языковым моделям в момент их работы. По аналогии с robots.txt, который указывает поисковым роботам, что можно сканировать, /llms.txt даёт ИИ-агентам, чат-ботам и IDE-ассистентам (Cursor, Windsurf, Copilot) чистый структурированный контекст о сайте.

Как это работает

Протокол держится на двух идеях. Первая — обычный Markdown-файл /llms.txt в корне сайта: краткое описание проекта и список ссылок на разделы, полезные для ИИ. Вторая — «чистые» Markdown-версии страниц по тому же адресу с добавлением .md в конце (например, /docs/intro.md) — без шапки, подвала, рекламы и JS.

Как использовать владельцу сайта

Разместить llms.txt в корне, описать в нём суть проекта и дать структурированные ссылки на документацию. Настроить отдачу «чистых» .md-версий страниц. Существуют CLI-утилиты (например, llms_txt2ctx), которые обходят ссылки из llms.txt и собирают их в один файл контекста — пользователи сайта могут скопировать его целиком в ChatGPT или Claude.

Плюсы и минусы

• За: экономит контекстное окно ИИ (не тратится на HTML-обвязку), снижает риск галлюцинаций у ассистентов, реализуется без базы данных и API — только текстовые файлы, уже поддерживается Cursor и Windsurf.
• Против: требует ручной поддержки актуальности, не подходит для быстро меняющихся данных, до сих пор не официальный стандарт W3C — общественная инициатива.

Я внедрил оба слоя протокола на этом сайте — можно посмотреть вживую: /llms.txt — карта сайта, и /llms-full.txt — полные тексты всех опубликованных материалов одним файлом, оба генерируются автоматически при публикации нового материала.

Open Knowledge Format (OKF)

Простыми словами: это папка с обычными текстовыми файлами, где поля вроде «заголовок» и «тип» всегда стоят на одних и тех же местах — чтобы ИИ, а не только человек, сразу понимал структуру ваших знаний. Формально — открытая vendor-neutral спецификация, формализующая паттерн «LLM-wiki»: представление метаданных, контекста и курируемых знаний, читаемое и людьми, и ИИ-агентами. Решает проблему фрагментации контекста — когда важные знания разбросаны по базам данных, Notion, комментариям в коде и головах инженеров.

Как это работает

OKF умышленно простой: никаких новых runtime или обязательных SDK. Пакет документов состоит из трёх элементов: обычный Markdown (.md), обычные файлы (архив .tar.gz, Git-репозиторий или примонтированная файловая система) и YAML frontmatter — небольшой набор стандартизированных полей (type, title, description, resource, tags, timestamp) в начале каждого файла. Если вы пользовались Obsidian, Notion, Hugo или писали CLAUDE.md/AGENTS.md — структура покажется знакомой: OKF просто стандартизирует имена полей.

Как использовать владельцу сайта

Создать публичную директорию (или открытый Git-репозиторий) с файлами в формате OKF — точный, структурированный контекст об услугах, ценах, API или продуктах вместо того, чтобы ИИ «догадывался» по неструктурированному HTML. Тем же набором файлов можно кормить собственного чат-бота поддержки — он будет отвечать без галлюцинаций, опираясь на чёткую структуру метаданных. При ведении документации в Git можно настроить CI/CD-пайплайн, который автоматически обновляет OKF-файлы при изменении услуг.

Плюсы и минусы

• За: невероятно просто внедрить (достаточно уметь писать Markdown и YAML), человекочитаемо в отличие от JSON-LD и RDF-графов, Git-friendly (история, pull request'ы, откаты), изначально спроектирован под нарезку на чанки для RAG.
• Против: ранняя стадия (v0.1, представлен в середине 2026 года), требует ручной поддержки на старте, разграничение доступа нужно настраивать отдельно на уровне хостинга — во встроенной безопасности нет, не подходит для данных, меняющихся в реальном времени.

Agentic Resource Discovery (ARD)

Простыми словами: это справочник ваших ИИ-инструментов и API, который агент может спросить «у кого есть то, что мне нужно прямо сейчас?» — и получить точный адрес, вместо того чтобы перебирать тысячи вариантов сам. Формально — открытый децентрализованный протокол обнаружения «агентских ресурсов»: специализированных ИИ-агентов, MCP-серверов, плагинов, API, инструментов, канвасов или рабочих процессов. Разрабатывается консорциумом Microsoft, Google, Hugging Face, GoDaddy, Cisco, Databricks, GitHub, Nvidia, Salesforce, ServiceNow, Snowflake и других — под лицензией Apache 2.0. Решает конкретную проблему: ИИ-ассистент не может держать в контекстном окне тысячи схем API одновременно, и ARD позволяет ему в реальном времени спросить, какие инструменты доступны для конкретной задачи.

Как это работает

ARD работает на этапе до вызова инструмента — сам вызов идёт через нативный механизм (например, MCP или REST). Процесс в пять шагов: разработчик описывает ресурс по стандарту AI Catalog; сервисы собирают эти описания в коллекции (публичные, корпоративные или нишевые); поверх коллекции разворачивается стандартизированный API — обязательный POST /search для семантического поиска по описанию задачи на естественном языке, опциональные POST /explore и GET /agents; ИИ-клиент обращается к поисковому эндпоинту, находит подходящий инструмент и предлагает пользователю его задействовать.

Как использовать владельцу сайта

Три шага. Первый — создать манифест ai-catalog.json: статический JSON-файл с описанием ваших ресурсов, включая поле representativeQueries — 2–5 примеров запросов на естественном языке, по которым семантический поиск найдёт ваш инструмент. Второй — разместить его по адресу /.well-known/ai-catalog.json, с заголовком Access-Control-Allow-Origin: *, чтобы краулеры могли его прочитать. Третий, опциональный — если сайт на GitHub Pages или S3 и папку .well-known не разместить, прописать DNS TXT-запись _catalog._agents.yourdomain.com со ссылкой на файл.

Плюсы и минусы

• За: новый канал видимости — сервисы предлагаются пользователям прямо внутри ChatGPT, Claude или Copilot в момент релевантной задачи; экономия контекста ИИ; децентрализация — нет единого монопольного магазина; участие Google, Microsoft и Hugging Face; для базового участия достаточно одного статического файла.
• Против: ранняя стадия (v0.1); проблема доверия — любой может опубликовать манифест, поисковым сервисам придётся модерировать спам и вредоносные записи; размещение файла не гарантирует индексацию или ранжирование.

Model Context Protocol (MCP)

Простыми словами: это универсальный переходник, который позволяет любой ИИ-модели подключаться к вашим данным и инструментам одним и тем же способом — вместо отдельного плагина под каждый чат-бот. Создатели протокола, компания Anthropic (авторы Claude), называют его «портом USB-C для ИИ-приложений»: подобно тому, как USB-C стандартизировал подключение физических устройств, MCP стандартизирует подключение моделей к внешним данным, инструментам и рабочим процессам. Протокол поддерживают OpenAI, Cursor, VS Code и другие.

Как это работает

MCP построен на клиент-серверной архитектуре поверх JSON-RPC 2.0. Три элемента: ИИ-клиенты (Claude Desktop, ChatGPT, Cursor, VS Code) инициируют соединение; MCP-серверы — лёгкие программы на Python, Node.js или Go, локальные или удалённые, которые «оборачивают» конкретные базы данных, API или файлы; источники данных — сами файлы, базы (PostgreSQL, SQLite), внешние API (GitHub, Slack, Google Calendar). Сервер передаёт клиенту три типа возможностей: ресурсы (данные только для чтения — схемы БД, логи, документация), инструменты (исполняемые функции вроде «отправить сообщение в Slack», вызываются строго с согласия пользователя) и шаблоны (готовые сценарии системных промптов).

Как использовать владельцу сайта

Вместо отдельных плагинов под ChatGPT, Claude и расширений под Cursor — один MCP-сервер для вашего API: любой разработчик подключает его к своему ИИ-ассистенту и работает с сервисом (аналитика, заказы, баланс) прямо из чата. Если сайт даёт инструменты разработчикам (облачный хостинг, база данных) — MCP-сервер позволит управлять инфраструктурой из Cursor или VS Code силами ИИ. Внутри компании через MCP-серверы можно объединить Notion, Jira, базы сайта и Google Диск в единый безопасный корпоративный поиск, не переобучая модель заново.

Плюсы и минусы

• За: «напиши один раз, используй везде» — один сервер работает в Claude, ChatGPT, Cursor без изменений; безопасность — модель не имеет прямого доступа к БД, только к разрешённым командам сервера, критические действия требуют подтверждения пользователя; гибкий транспорт (локальный Stdio или удалённый SSE); растущий публичный реестр готовых серверов под GitHub, Postgres, Slack, Google Drive.
• Против: требует написания и постоянного хостинга полноценного серверного приложения, а не просто текстового файла; конечному пользователю нужно вручную прописать конфигурацию в своём ИИ-клиенте; многослойная архитектура (модель → клиент → JSON-RPC → сервер → API) добавляет задержку по сравнению с прямым вызовом API.

Universal Commerce Protocol (UCP)

Простыми словами: это протокол, который позволяет ИИ-ассистенту не просто посоветовать товар, а сразу купить его от вашего имени, не выходя из чата. Формально — открытый стандарт, дающий ИИ-агентам совершать транзакции (покупки, бронирования) от лица пользователя прямо в интерфейсе ИИ, минуя переход на сайт. Уже расширяется за пределы классического ритейла на общественное питание и бронирование жилья.

Как это работает

UCP связывает три стороны: ИИ-поверхность (клиента), продавца и платёжные/идентификационные сервисы. Протокол использует существующие товарные фиды продавца в Google Merchant Center для поиска и предложения товаров в момент, когда пользователь выражает намерение купить прямо в ИИ-поиске, и создаёт защищённый след транзакции между продавцом, провайдерами учётных данных и платёжными шлюзами. Два варианта оформления заказа: native checkout — логика покупки полностью внутри интерфейса Gemini/AI Search, максимум автономности для агента; embedded checkout — опциональный вариант для одобренных крупных брендов, оформление через защищённый iframe продавца внутри интерфейса ИИ.

Как использовать владельцу сайта

Три шага для владельца магазина, службы доставки еды или отеля: убедиться, что аккаунт Google Merchant Center настроен и данные о товарах актуальны; подать заявку на участие в программе на официальном сайте Google для своей ниши (Retail, Lodging или Food) — по состоянию на середину 2026 года протокол ещё расширяется по заявкам; изучить открытую спецификацию UCP на GitHub и настроить платёжную систему и систему заказов на приём запросов в формате UCP.

Плюсы и минусы

• За: zero-click покупки — не нужно переходить на сайт, регистрироваться, заново вводить карту, что снижает процент брошенных корзин; продавец остаётся Merchant of Record — сохраняет данные клиентов, управляет доставкой; готовый доступ к аудитории Gemini и AI Mode в Google Search без необходимости продвигать собственное приложение; в роадмапе Google — мультикорзины, программы лояльности, послепродажная поддержка через ИИ.
• Против: закрытое тестирование и лист ожидания, а не открытый доступ «из коробки»; техническая сложность нативного чекаута и обработки транзакций от внешних ИИ-систем; зависимость от экосистемы Google как ключевого бенефициара; при native checkout бренд ограничен стандартным интерфейсом Google — сложнее делать апсейл и показывать собственный дизайн.

Сводная таблица

Что делать: рекомендации

Внедрять уже сейчас: llms.txt — это буквально один файл, ничего не сломает, а я на собственном сайте вижу, что он реально работает. Если у вас SaaS, документация или API с знаниями, разбросанными по десятку мест, — туда же добавить OKF: тоже просто файлы, но решает проблему фрагментации контекста, которая иначе никуда не денется сама.

Готовиться и пилотировать: ARD, если у вас уже есть API или MCP-сервер, которые стоит сделать обнаружимыми, — манифест на один JSON-файл не требует крупных вложений, а стандарт поддержан слишком крупным консорциумом, чтобы исчезнуть. MCP — если ваш сайт или сервис даёт что-то, чем реально хочется управлять из чата (аналитика, заказы, инфраструктура): это уже инженерный проект, не разовая правка, но за ним стоят и Anthropic, и OpenAI одновременно, случай редкий для конкурентов.

Пока можно не спешить: UCP — если вы не в ритейле, доставке еды или бронировании жилья с уже настроенным Google Merchant Center, для вас это преждевременно: протокол на стадии листа ожидания, и тратить на него ресурсы сейчас означает готовиться к двери, которая может открыться, а может и не открыться в ближайший год. Проверяйте раз в квартал, не спешите увольнять с этим свою команду разработки.

Maxim Safianov

Я работаю на стыке технического SEO и разработки: помогаю сайтам оставаться видимыми и для классического поиска, и для AI-ответов — и пишу инструменты на Python, которые это автоматизируют.