Сайт, на котором AI-агент может не только читать, но и действовать

Обычный сайт рассчитан на человека: он видит меню, понимает подписи, открывает карточку, заполняет форму и нажимает кнопку. Поисковый робот работает иначе — читает HTML, ссылки и структурированные данные. AI-агенту нужен третий слой. Он должен не только понять, что предлагает компания, но и безопасно выполнить действие: подобрать вариант, проверить наличие, рассчитать стоимость, записать клиента или собрать корзину.

Массовым пользовательским сценарием это пока не стало, но инфраструктура уже формируется. Google развивает Universal Commerce Protocol для покупок из AI Mode и Gemini, WebMCP позволяет страницам описывать доступные действия, а отдельные компании создают собственные MCP-серверы для работы с каталогом и сервисами. Подготовка к агентам начинается не с модного протокола, а с хорошей архитектуры сайта и данных.

WebMCP, UCP и интеграции AI-платформ меняются быстрее обычных веб-стандартов. Поэтому в финальной публикации рядом с возможностями нужно сохранить оговорку «на момент обновления материала» и перед релизом перепроверить географию, доступ, поддерживаемые операции и статус эксперимента по официальной документации. Архитектурные принципы — ясный контракт, права, подтверждение и журнал — стабильнее конкретного списка рынков.

На дату публикации WebMCP остаётся экспериментальным браузерным API и доступен через origin trial Chrome. Его сильная сторона — инструменты поверх видимого интерфейса и подтверждение человеком; ограничение — ранняя стадия стандарта и зависимость от поддержки браузера и агента.

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

UCP — специализированный протокол для торговли с REST- и MCP-привязками. Он описывает обнаружение возможностей и жизненный цикл checkout, включая профиль /.well-known/ucp. Это перспективный слой для e-commerce, но коммерческий эффект зависит от поддержки конкретными платформами, рынком и вашей инфраструктурой.

Понятный текст помогает модели ответить на вопрос. Agent-ready архитектура помогает ей перейти от ответа к операции. Для этого действие должно иметь ясное имя, входные параметры, результат, ограничения и подтверждение пользователя.

Если человек понимает кнопку «Узнать подробнее» из контекста, агенту она почти ничего не говорит. Намного полезнее операция «получить доступное время консультации» или «рассчитать доставку для индекса». То же касается каталога: красивые карточки недостаточны, если цена, наличие и варианты спрятаны в изображениях или загружаются непредсказуемо.

Большинству компаний не нужно внедрять все слои сразу. Если каталог неактуален, формы ломаются, а мобильная версия медленная, собственный MCP не исправит фундамент. Более того, готовность сайта к агентам не равна наличию MCP-сервера: иногда достаточно привести в порядок контент, данные, формы и внутренние API. Подготовка начинается с качества самого продукта.

Услуги, цены, ограничения, география, сроки и доказательства должны быть написаны явно. Важные факты нельзя оставлять только внутри баннеров, PDF или видео. У каждой сущности — услуги, товара, филиала, специалиста — нужен стабильный URL и однозначное название.

Структурированные данные помогают системам различать товар, организацию, статью, FAQ, событие или локальный бизнес. Они не гарантируют рекомендацию, но уменьшают неоднозначность. То же относится к языковым версиям, canonical и доступности контента для роботов.

Хорошая база одновременно работает для SEO, GEO и обычного пользователя.

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

Для надёжной операции агенту нужен интерфейс, который не зависит от расположения кнопки на экране. Это может быть внутренний API, публичный endpoint или специально описанный инструмент. В контракте фиксируются параметры, обязательные поля, форматы ошибок, авторизация, идемпотентность и ограничения.

API не обязательно открывать всему интернету. Можно разделить публичное чтение, действия после авторизации и операции, которые требуют подтверждения. Важно, чтобы права соответствовали риску.

WebMCP — предлагаемый веб-стандарт, при котором веб-приложение явно предоставляет AI-агенту набор инструментов в контексте страницы. На момент подготовки материала Chrome тестирует его через origin trial, а основной сценарий рассчитан на работу агента в локальной браузерной сессии с участием пользователя. Вместо попытки угадать назначение каждой кнопки агент получает описанные действия, схемы параметров и ожидаемый результат.

Это не то же самое, что обычный MCP-сервер. Классический MCP соединяет AI-клиент с внешним сервисом и может работать вне открытой страницы. WebMCP привязывает инструменты к текущему сайту и браузерной сессии, где пользователь видит интерфейс и подтверждает чувствительное действие. Поэтому WebMCP ближе к дополнительному слою существующего сайта, а MCP-сервер — к отдельному каналу доступа к возможностям бизнеса.

Подробное введение и разницу двух API мы собрали в статье что такое WebMCP. Практический ориентир уже есть и на локальном рынке: ВкусВилл запустил собственный MCP-сервис, через который агент может работать с возможностями компании. Это отдельный серверный сценарий, но он хорошо показывает направление: бизнес описывает не страницы, а доступные операции.

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

Universal Commerce Protocol — открытый стандарт для коммерческих операций в AI-интерфейсах. Google описывает его как способ включить прямую покупку из AI Mode и Gemini, сохраняя бизнес в роли Merchant of Record. Протокол поддерживает REST, MCP binding и совместимость с другими агентными протоколами.

Для магазина это означает структурированный цикл: обнаружение товара, корзина, доставка, оплата, подтверждение, а в перспективе — лояльность и post-purchase сценарии. Однако внедрение UCP пока зависит от рынка и допуска. На момент подготовки материала UCP checkout доступен только отдельным продавцам и подходящим товарам в США, Канаде и Австралии. Поэтому стандарт стоит рассматривать как направление архитектуры и ранний пилот, а не как кнопку, которую сегодня обязан включить каждый интернет-магазин.

Если задача агента — только понять ассортимент, услуги и ограничения, сначала достаточно контента, schema и стабильных URL. Если действие происходит внутри открытого сайта и пользователь должен видеть интерфейс, логичен пилот WebMCP. Если внешнему AI-клиенту нужно регулярно обращаться к каталогу, заказам или аккаунту вне страницы, нужен отдельный MCP-сервер или API-слой. Если бизнес строит полноценный коммерческий путь от товара до оплаты в поддерживаемой экосистеме, рассматривают UCP.

Эти варианты не являются лестницей, по которой обязан пройти каждый сайт. Сервисная компания может остановиться на хорошей структуре и одной предсказуемой форме; интернет-магазину с повторными заказами может понадобиться серверный интерфейс. Решение принимают по сценарию, аудитории, риску и стоимости поддержки, а не по новизне аббревиатуры.

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

Минимальные принципы:

• минимальные права для каждого инструмента;
• подтверждение перед необратимым действием;
• разделение чтения и записи;
• проверка параметров на сервере, а не доверие модели;
• rate limits, журналирование и возможность отмены;
• понятное сообщение пользователю о том, что сделает агент.

Agent-ready не означает «разрешить модели всё». Хорошая архитектура даёт ровно тот доступ, который нужен для конкретной задачи.

Идемпотентность означает, что повторный вызов с тем же ключом не создаст второй заказ или платёж. Авторизация должна быть ограничена конкретными scope и временем, а не выдавать агенту полный доступ к аккаунту. Перед необратимым действием пользователь видит понятное резюме: что будет создано, изменено или оплачено, на какую сумму и от чьего имени.

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

Отдельный класс риска — prompt injection и tool poisoning. Текст страницы, карточки товара или стороннего документа не должен иметь право расширять разрешения инструмента. Политика доступа и бизнес-правила исполняются на сервере, а чувствительные параметры проверяются независимо от формулировки, которую предложил агент.

Первый scorecard должен сочетать технические и бизнес-метрики. Технический слой: task success rate, tool-call error rate, медианное время выполнения, доля повторных вызовов, дублированных операций и успешных откатов. Пользовательский слой: доля подтверждений, отказов на шаге consent и передачи человеку. Бизнес-слой: завершённые корзины или заявки, качество переданных данных, повторное использование и дополнительная маржа.

До запуска задают базовую линию обычного интерфейса. Если агент выполнил 90% операций, но пользователи чаще бросают подтверждение, чем в стандартном checkout, технический успех ещё не стал улучшением продукта. Если аудитория слишком мала для вывода о продажах, пилот можно признать успешным только в исследовательском смысле — при условии, что он доказал стабильность, безопасность и приемлемую стоимость операции.

Agent-ready архитектура выглядит технической, но начинается с маркетинговых решений. Какую задачу человек поручает агенту? Какие параметры влияют на выбор? Чем продукт отличается? Как доказать качество? В какой момент нужна консультация?

Если эти ответы не определены, API лишь быстрее передаст неясность. Поэтому проект должен объединять маркетинг, продукт, разработку, SEO/GEO и аналитику. В этом и состоит практический смысл: сайт становится не только витриной, но и понятным сервисом для человека, поисковой системы и агента.

Сегодня MCP остаётся узким каналом. Большинство обычных пользователей не знает, что это такое, не подключает внешние серверы к AI-ассистентам и не строит через них регулярные покупки. На рынках, где нейросетями постоянно пользуется небольшая доля аудитории, потенциальный охват ещё меньше. Поэтому сам факт запуска MCP нельзя превращать в прогноз продаж.

Наиболее понятный коммерческий сценарий — e-commerce с большим структурированным каталогом, актуальными ценами и остатками, повторными покупками и существующей клиентской базой. Агент может помочь постоянному покупателю найти привычный товар, проверить наличие, собрать корзину или повторить заказ. Здесь сокращение пути действительно способно дать ценность, если каталог и процессы уже работают без ручного вмешательства.

Для обычного сайта услуг собственный MCP-сервер чаще всего преждевременен. Клиент приходит нерегулярно, выбор требует консультации, а конверсия зависит от оффера, доверия, кейсов и качества обработки заявки. В такой ситуации бизнесу полезнее сначала вложиться в продукт, контент, структуру сайта, формы, аналитику и CRM. WebMCP можно попробовать для записи или заполнения формы, но пока это экспериментальный дополнительный интерфейс, а не замена основному пути пользователя.

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

Для сайта услуг самый простой пилот — декларативный WebMCP-инструмент поверх существующей формы. Например, действие book_consultation принимает желаемую дату, часовой пояс, имя и контакт. Видимая форма остаётся источником истины: те же обязательные поля, валидация и итоговое подтверждение. Агент не получает скрытый обход бизнес-правил, а лишь заполняет и отправляет понятный пользователю сценарий.

Для внешнего MCP-сервера контракт может выглядеть так: инструмент get_available_slots получает service_id, date_from, date_to и timezone, а возвращает список слотов и request_id. Сервер сам проверяет доступ, ограничения и актуальность, не доверяя параметрам агента. Действие бронирования нужно отделить от чтения доступности и требовать отдельного подтверждения.

Для e-commerce UCP добавляет стандартный слой commerce-операций. Профиль возможностей публикуется через /.well-known/ucp, после чего клиент может создавать, обновлять, завершать или отменять checkout в рамках объявленных возможностей. Это не заменяет каталог, цены и fulfillment — протокол связывает их с агентом через предсказуемый контракт.

Авторизация должна использовать OAuth с минимальным набором прав и короткоживущими токенами. Каждый запрос получает Request-Id, а операции, меняющие состояние, — idempotency key, чтобы повтор после сетевой ошибки не создал второй заказ. До оплаты, бронирования или отправки заявки пользователь видит итог: товар или услугу, цену, адрес, дату и последствия действия.

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

Минимальный набор проверяет правильный выбор инструмента, отсутствие обязательного параметра, неверный формат, повторный запрос, отказ пользователя, prompt injection в содержимом страницы, недоступность зависимого API и передачу человеку. Сценарии запускают на неизменной тестовой выборке после каждого изменения контракта.

Кроме бизнес-метрики измеряйте task success rate, p95 latency, долю дублей, долю отмен и откатов, ручные передачи и стоимость успешной задачи. Руководство Chrome по evals предлагает тестировать не только вызов функции, но и то, способен ли агент корректно завершить задачу в реальном интерфейсе; спецификация UCP отдельно описывает стабильные идентификаторы и жизненный цикл checkout.