Агенты уже умеют искать товары, сравнивать цены, выбирать подходящие предложения и даже проходить checkout. Но есть проблема: большинство сайтов всё ещё сделаны для людей, а не для программных агентов.
Человеку удобно открыть интернет-магазин, посмотреть карточку товара, пролистать фильтры, сравнить несколько вкладок и принять решение. AI-агенту приходится делать то же самое через браузер: читать HTML, кликать по страницам, запоминать контекст, возвращаться назад, искать цену, проверять наличие и пытаться не ошибиться в деталях.
Это медленно, дорого и ненадёжно.
Новое исследование “MCP vs RAG vs NLWeb vs HTML: A Comparison of the Effectiveness and Efficiency of Different Agent Interfaces to the Web” показывает: для e-commerce-задач AI-агенты работают лучше, когда получают данные через RAG, MCP, NLWeb или другие структурированные интерфейсы, а не пытаются использовать сайт как обычный человек.
Главная мысль простая: AI-агентам нужен не визуальный сайт, а понятный слой данных.
Почему эта тема важна
AI-агенты постепенно превращаются из чат-ботов в исполнителей задач.
Пользователь может попросить:
- найти самый дешёвый ноутбук с нужными характеристиками;
- сравнить цены на один товар в нескольких магазинах;
- подобрать совместимый аксессуар;
- найти замену товару, которого нет в наличии;
- собрать корзину по списку требований;
- проверить наличие, цену, рейтинг и условия доставки;
- подготовить короткий отчёт по рынку или конкурентам.
Для таких задач агенту нужны свежие данные из интернета: товары, цены, описания, характеристики, отзывы, ссылки, наличие, продавцы и региональные отличия.
Теоретически агент может открыть сайт в браузере и пройти путь как человек. Практически это часто превращается в цепочку хрупких действий: перейти по ссылке, дождаться загрузки, прочитать страницу, найти кнопку, открыть карточку, извлечь цену, не перепутать валюту, вернуться назад и повторить всё заново.
Чем больше сайтов и товаров, тем выше стоимость, задержка и риск ошибки.
Что сравнивали исследователи
Авторы исследования сравнили четыре способа, которыми AI-агент может взаимодействовать с интернет-магазином:
HTML-браузинг Агент работает с сайтом как пользователь: открывает страницы, кликает по ссылкам, читает содержимое и заполняет формы.
RAG Содержимое сайтов заранее индексируется, а агент ищет по этому индексу и получает релевантные фрагменты без необходимости каждый раз ходить по страницам.
MCP Магазин предоставляет агенту доступ к функциям через API: поиск товаров, получение деталей, добавление в корзину, checkout и другие действия.
NLWeb Агент задаёт запрос на естественном языке, а сайт возвращает структурированные данные, например в формате, похожем на Schema.org JSON.
Исследование проводилось в контролируемой среде: авторы использовали четыре симулированных интернет-магазина и одинаковые наборы e-commerce-задач. Это важно: сравнивались не случайные сайты из интернета, а одинаковые задачи на разных интерфейсах.
Задачи включали поиск конкретных товаров, поиск товаров по требованиям, сравнение самых дешёвых предложений, подбор замен и совместимых товаров, добавление в корзину и оформление заказа.
Что показал эксперимент
Результат оказался предсказуемым, но важным: HTML оказался самым слабым интерфейсом для AI-агента.
По данным technical report, средний F1 для HTML-браузинга составил 0.67, а для RAG, MCP и NLWeb — примерно 0.75–0.77. То есть структурированные подходы оказались заметно точнее.
Разница была не только в качестве ответа. HTML также оказался дороже по токенам и медленнее по времени выполнения. В среднем токенов на задачу стало меньше: примерно с 241k для HTML до 47k–140k для RAG, MCP и NLWeb. Время выполнения снизилось с 291 секунды до 50–62 секунд.
Лучший общий результат в эксперименте показал RAG с GPT-5: F1 0.87 и completion rate 0.79. При учёте стоимости авторы также выделяют RAG с GPT-5 mini как хороший компромисс между ценой и качеством.
Главный вывод: интерфейс, через который агент получает данные, сильно влияет на точность, скорость и стоимость работы.
Почему HTML плохо подходит для AI-агентов
HTML создавался для отображения страниц в браузере. Он хорош для людей, но не всегда удобен для машин.
На обычной странице интернет-магазина агенту нужно отделить полезные данные от всего остального:
- меню;
- баннеров;
- похожих товаров;
- рекламных блоков;
- футера;
- модальных окон;
- cookie-плашек;
- навигации;
- повторяющихся элементов;
- динамически подгружаемых данных.
Даже если страница визуально понятна человеку, для агента это может быть шумный и нестабильный источник.
Например, цена может быть в одном блоке, старая цена — в другом, скидка — в третьем, а доставка — ещё ниже. Если агент неправильно понял структуру страницы, он может выбрать не тот товар или сравнить не те предложения.
Есть и другая проблема: HTML-интерфейс требует много шагов. Агенту приходится не просто получить данные, а взаимодействовать с сайтом: переходить, кликать, ждать, анализировать, возвращаться, уточнять запрос. Каждый шаг потребляет токены и время.
Поэтому HTML-браузинг часто стоит воспринимать как fallback: запасной вариант, когда нет нормального API или структурированного источника данных.
Почему структурированные данные работают лучше
Структурированный интерфейс делает задачу агента проще.
Вместо того чтобы “смотреть” на страницу, агент получает уже подготовленные данные:
{
"title": "Wireless Keyboard",
"price": "49.99",
"currency": "USD",
"availability": "InStock",
"rating": 4.6,
"url": "https://example.com/product"
}
Такой формат легче сравнивать, фильтровать, сохранять и передавать в следующий шаг.
Если агенту нужно найти самый дешёвый товар, он может работать с полем price. Если нужно проверить наличие — с availability. Если нужно сравнить продавцов — с seller, rating, shipping и другими параметрами.
Это снижает количество лишнего текста, уменьшает риск неверной интерпретации и делает результат более предсказуемым.
RAG, MCP и NLWeb: в чём разница
Все три подхода лучше HTML, но решают задачу по-разному.
RAG
RAG — это подход, при котором страницы или данные заранее собираются, очищаются, индексируются и становятся доступными для поиска.
Агент не ходит по сайту каждый раз заново. Он задаёт поисковый запрос к индексу, получает релевантные документы или фрагменты, уточняет запрос и постепенно сужает выбор.
Для e-commerce это удобно, когда нужно искать по большому каталогу, сравнивать товары и работать с описаниями. Но важно, чтобы индекс был свежим: цены, наличие и условия доставки могут быстро меняться.
MCP
MCP даёт агенту доступ к функциям через API. Например:
search_products;get_product_details;add_to_cart;checkout;compare_offers.
Преимущество MCP — агент может не просто читать данные, а выполнять действия. Это особенно полезно для сценариев, где нужно не только найти товар, но и что-то сделать: добавить в корзину, оформить заказ, проверить статус.
Слабое место — разные сайты могут возвращать данные в разных форматах. Если у каждого магазина свои названия полей и своя структура API, агенту нужно нормализовать ответы перед сравнением.
NLWeb
NLWeb предлагает более стандартизированный способ: агент задаёт вопрос на естественном языке, а сайт возвращает структурированные данные.
Идея привлекательная: вместо набора разных API для каждого сайта появляется более единый интерфейс для AI-агентов. В исследовании NLWeb использовал Schema.org-подобные JSON-ответы, что упрощало сравнение данных между магазинами.
На практике такие подходы пока только формируются, но направление понятно: сайты будут всё чаще добавлять интерфейсы не только для людей, но и для агентов.
Что это значит для e-commerce
Для интернет-магазинов и маркетплейсов это важный сигнал.
Покупатель будущего может прийти не напрямую на сайт, а через AI-ассистента. Он не будет сам открывать десятки страниц. Он попросит агента:
“Найди мне лучший монитор до 300 евро для работы с MacBook, желательно с USB-C и хорошими отзывами.”
Агент должен будет найти варианты, сравнить характеристики, проверить цены, отфильтровать неподходящие предложения и объяснить выбор.
Если данные магазина доступны только в виде сложного HTML, агенту будет труднее корректно использовать их. Если же товары, цены, наличие и характеристики доступны в структурированном виде, шансы попасть в рекомендацию становятся выше.
Это меняет логику конкуренции. Важна не только красивая карточка товара для человека, но и качество данных для машинного чтения.
Что это значит для SaaS и внутренних инструментов
Тема важна не только для интернет-магазинов.
Многие SaaS-продукты уже строят AI-функции, которым нужны свежие данные из поиска и сайтов:
- мониторинг цен конкурентов;
- сравнение товаров на маркетплейсах;
- анализ спроса;
- подбор поставщиков;
- автоматические отчёты по рынку;
- brand monitoring;
- проверка наличия товаров;
- enrichment данных в CRM;
- внутренние ассистенты для закупок;
- AI-агенты для поддержки продаж.
Во всех этих сценариях агенту нужны не просто “страницы”, а данные, которые можно безопасно использовать в логике продукта.
Например, внутренний ассистент для закупок может получать запрос от сотрудника:
“Найди 5 предложений по офисным мониторам 27 дюймов с доставкой в Германию и ценой до 250 евро.”
Чтобы выполнить задачу, агенту нужно собрать поисковые результаты, карточки товаров, цены, доступность, продавцов и ссылки. Делать это через визуальный браузинг долго и дорого. Гораздо логичнее получать структурированные результаты через API.
Где здесь Search API
Search API решает похожую проблему: он даёт продуктам и агентам доступ к поисковым данным в структурированном виде.
Вместо того чтобы вручную парсить поисковую выдачу или заставлять AI-агента “гулять” по браузеру, приложение отправляет запрос и получает JSON:
- органические результаты;
- shopping-результаты;
- товарные карточки;
- цены;
- сниппеты;
- ссылки;
- рейтинги;
- локальные результаты;
- новости;
- изображения;
- видео;
- данные по разным поисковым engines.
На примере Xylop это особенно заметно: сервис даёт единый API-доступ к Google, Bing, DuckDuckGo, маркетплейсам, картам, локальному поиску, медиа и другим engines. Для разработчика это означает меньше ручного парсинга и более предсказуемую интеграцию.
В контексте AI-агентов Search API может выступать как внешний инструмент:
- Агент получает задачу от пользователя.
- Формирует поисковый запрос.
- Отправляет запрос в Search API.
- Получает структурированный JSON.
- Сравнивает результаты.
- Делает вывод или вызывает следующий инструмент.
Такой подход проще контролировать, логировать и масштабировать.
Пример: shopping-агент на Search API
Представим AI-ассистента, который помогает пользователю выбирать технику.
Пользователь пишет:
“Найди лучший ноутбук для работы с программированием до 1200 долларов. Важно: 32 ГБ RAM, хороший экран, не игровой дизайн.”
Агент может выполнить задачу так:
Сформировать несколько поисковых запросов:
best laptop for programming 32GB RAM under 1200;business laptop 32GB RAM reviews;developer laptop 32GB RAM price.
Получить поисковые и shopping-результаты через API.
Извлечь структурированные данные:
- название модели;
- цену;
- характеристики;
- рейтинг;
- продавца;
- ссылку;
- сниппеты обзоров.
Сравнить варианты.
Вернуть пользователю короткую рекомендацию:
- лучший вариант;
- бюджетный вариант;
- вариант с лучшим экраном;
- что проверить перед покупкой.
Такой агент не обязан сам открывать десятки страниц и читать весь HTML. Он может использовать Search API как первый слой свежих данных, а уже затем при необходимости уточнять детали другими инструментами.
Какие данные особенно важны для AI-агентов
Для e-commerce и продуктового поиска агентам особенно полезны такие поля:
title— название товара или страницы;link— URL результата;snippet— краткое описание;price— цена;currency— валюта;availability— наличие;rating— рейтинг;reviews_count— количество отзывов;seller— продавец;image— изображение;source— поисковая система или площадка;position— позиция в выдаче;location— регион выдачи;timestamp— время получения данных.
Чем чище эти поля, тем проще агенту принимать решения. И тем меньше вероятность, что он перепутает рекламный баннер с товаром, старую цену с новой или описание категории с описанием конкретной модели.
Почему это не значит, что HTML исчезнет
Важно не делать слишком резкий вывод. HTML никуда не исчезнет.
Сайты по-прежнему нужны людям. Визуальный интерфейс, бренд, контент, карточки товаров, фильтры, корзина и checkout останутся важными.
Но рядом с человеческим интерфейсом будет расти второй слой — интерфейс для машин:
- API;
- структурированные данные;
- Schema.org;
- feeds;
- MCP-инструменты;
- NLWeb-подобные интерфейсы;
- поисковые API;
- внутренние knowledge bases;
- RAG-индексы.
Для пользователя это будет почти незаметно. Он просто попросит ассистента выполнить задачу. А под капотом агент выберет наиболее удобный источник данных.
Если есть структурированный API — он использует API. Если есть индекс — обратится к индексу. Если ничего нет — пойдёт в HTML как в запасной вариант.
Что делать разработчикам уже сейчас
Если вы строите AI-продукт, shopping-ассистента, e-commerce-аналитику или внутреннего агента, стоит заранее продумать слой данных.
Минимальный план:
- Определить, какие свежие данные нужны агенту: поиск, товары, цены, отзывы, новости, локальные результаты.
- Разделить источники на стабильные API и нестабильный HTML.
- Использовать Search API как первый слой получения внешних данных.
- Сохранять результаты с датой, регионом и параметрами запроса.
- Нормализовать поля: цена, валюта, продавец, наличие, ссылка, рейтинг.
- Добавить валидацию: проверять, что цена подходит, товар в наличии, ссылка ведёт на нужную карточку.
- Использовать HTML-браузинг только там, где без него нельзя обойтись.
Главный принцип: не заставляйте AI-агента угадывать структуру страницы, если можно дать ему данные напрямую.
Что делать e-commerce-командам
Если вы управляете интернет-магазином или маркетплейсом, стоит думать не только о SEO и UX, но и об agent experience — удобстве сайта для AI-агентов.
Практические шаги:
- поддерживать корректные структурированные данные;
- следить за качеством product feeds;
- не прятать критичные данные только в JavaScript;
- явно указывать цену, валюту и наличие;
- обновлять данные по товарам;
- делать страницы понятными не только визуально, но и семантически;
- думать о будущем API-доступе для партнёров и агентов.
Если AI-ассистенты станут важным каналом выбора товаров, качество машинно-читаемых данных будет напрямую влиять на видимость товаров в рекомендациях.
Ограничения исследования
Исследование важно, но его нужно правильно интерпретировать.
Во-первых, эксперимент проводился в симулированных интернет-магазинах, а не на всём живом вебе. Это позволило честно сравнить интерфейсы на одинаковых задачах, но реальный интернет сложнее: сайты отличаются скоростью, антибот-защитой, разметкой, качеством данных и ограничениями доступа.
Во-вторых, RAG, MCP и NLWeb требуют подготовки инфраструктуры. Нельзя просто “включить” структурированный интерфейс без индекса, API, схем данных или поддержки со стороны сайта.
В-третьих, для некоторых задач HTML всё ещё может быть полезен. Например, если нужно проверить визуальный элемент, увидеть layout, пройти нестандартную форму или работать с сайтом, у которого нет API.
Но общий вывод всё равно сильный: для масштабируемых e-commerce-задач HTML-браузинг — не лучший основной интерфейс для AI-агентов.
Итог
AI-агенты меняют то, как продукты взаимодействуют с интернетом.
Раньше основной вопрос был: “Как человеку удобно пользоваться сайтом?” Теперь появляется второй вопрос: “Как агенту удобно получать данные и выполнять задачу?”
Исследование HTML, RAG, MCP и NLWeb показывает, что AI-агентам выгоднее работать со структурированными интерфейсами. Это быстрее, дешевле по токенам и точнее по результатам.
Для e-commerce это означает, что товарные данные должны быть понятны не только людям, но и машинам. Для SaaS и внутренних инструментов — что внешний поиск лучше подключать через API, а не через хрупкий браузерный парсинг. Для AI-продуктов — что Search API может стать одним из ключевых инструментов агента.
AI-агентам не обязательно “ходить по сайтам как человек”. Во многих задачах им достаточно получить правильные данные в правильном формате.
И чем раньше продуктовая команда построит такой слой данных, тем проще ей будет запускать AI-функции, shopping-ассистентов, мониторинг конкурентов и внутреннюю аналитику на основе свежей информации из веба.
FAQ
Почему AI-агентам неудобно работать с HTML?
HTML-страницы созданы в первую очередь для людей. На них много навигации, баннеров, повторяющихся блоков, JavaScript и визуальных элементов. Агенту приходится тратить больше шагов и токенов, чтобы извлечь цену, наличие, характеристики и другие важные данные.
Что лучше для AI-агента: HTML или API?
Для большинства задач поиска, сравнения и анализа лучше структурированный API. HTML может быть запасным вариантом, когда API или индексированных данных нет.
Что такое RAG в e-commerce?
RAG в e-commerce — это подход, при котором данные товаров и страниц заранее индексируются, а AI-агент ищет по этому индексу и получает релевантную информацию без постоянного браузинга сайта.
Что такое MCP?
MCP — это протокол, через который агент может использовать внешние инструменты и API. В e-commerce это могут быть функции поиска товаров, получения деталей, добавления в корзину и checkout.
Что такое NLWeb?
NLWeb — это подход, при котором сайт может отвечать агенту на естественном языке, но возвращать структурированные данные. В исследовании использовались Schema.org-подобные JSON-ответы.
Как Search API помогает AI-агентам?
Search API позволяет агенту получать поисковые, shopping, товарные и другие данные в структурированном виде. Это снижает зависимость от ручного парсинга HTML и упрощает построение AI-продуктов.
Для каких сценариев это полезно?
Для shopping-ассистентов, мониторинга цен, анализа конкурентов, e-commerce-аналитики, внутренних закупочных агентов, brand monitoring, market research и AI-инструментов, которым нужны свежие данные из интернета.