Что такое agentic UI / agent-friendly сервис

Нейросети сводят всех с ума, началась эпоха «агентского интерфейса».

Только ленивый не говорит про агентский юикс, выходят посты, статьи как его делать. В целом этот агентский юикс немножко напоминает истерию с чат-ботами лет десять назад. Когда появились чат-боты (те, которые работали на скриптах, не поверх языковых моделей), тоже была истерика, что всё, Галя, отменяем все интерфейсы, всё переводим на чат-боты.

Ну отлично, перевели на чат-ботов.

А потом оказалось, что пропускная способность интерфейса чат-бот (количество бит информации, которое может пропустить чат-бот за одно взаимодействие), очень низкая. И людям неинтересно, смотреть по одному варианту чат-бота для билетов. Они хотят выдать хорошую, понятную, удобную выдачу с сортировкой и фильтрами. Они не хотят формулировать пару кликов мыши в виде сообщения «покажи сейчас варианты до 5 тыс, но если хорошие, то и до 7.5 тыс тоже можно».

Чат-бот — это как ночной режим у меня в блоге (посмотрите, чтобы понять аналогию) — смотреть на маленькую область, а не видеть всю картину целиком.

Истерия истерией, но и когда начинают говорить про агентский интерфейс, к сожалению, очень многие говорят про него неправильно, делая фокус не на том. Мне кажется, когда говорят «агентский интерфейс», обычно имеют в виду MCP. Типа сделал себе MCP и хоба, получил agentic UI. Как бы да, но и нет.

Рассказываю, что мне кажется более важным, чем MCP.

Что вообще значит «agent-friendly»

Еще одну минуту, я договориться об определениях.

Agent-friendly — это продукт, в котором ллм-агент является first class citizen, наравне с человеком — продукт, в который может зайти и человек, и агент.

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

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

Что не так с MCP и прочим агентским юиксом сейчас

Мне кажется, что MCP, как протокол, как обертка вокруг имеющегося API, — это достаточно тупиковая ветка. Я не очень понимаю, зачем при наличии OpenAPI-спеки, нужно ещё какое-то описание. Почему клод, который настолько умный, что его опасно релизить, не может разобраться в OpenAPI-спеке и сделать всё по ней сразу? Зачем нужна какая-то специальная прослойка для этого? Вот тебе oauth, вот тебе описание методов, иди вызывай. Зачем MCP?

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

Я благодарен антропику за то, что они придумали МСР и расширили наше сознание тем, что можно подключать к агентам. Я просто отношусь к этому как к временному явлению. Помните, раньше нужно было промпты писать в строго определенном порядке, структуре. А сейчас можно в целом очень сырой, очень противоречивый войс кодексу послать и как-то он разбирается. Он находит противоречия, он понимает, какая информация более свежая.

Мне кажется, что такая же история будет с МСР, или превратится во что-то более сложное, или не будет нужен.

Ну вот я сделал себе MCP в Recipe Scaler. Вышла, фактически, обёртка вокруг стандартного API. Я не понимаю, зачем я я вынужден её писать.
Сам АПИ: ~3 100 строк кода
Дополнительная MCP-слой: еще ~5 870

Не кажется, ли что тут что-то не так? Мы делаем втрое больше кода, чтобы…?

Расскажу что на самом деле важно, от базового — к надстройкам.

1. Доступность контента

Базовое условие: агент должен уметь прочитать контент продукта без браузера.

Берем баш, пишем в нем:

curl https://your-site/important-page

Если в ответ приходит осмысленный хтмл с контентом — всё в порядке. Если приходит СПА-шелл, в котором <div id=’root’></div>и немного скрипт-тегов — все не очень хорошо. Агент не сможет прочитать страницу без playwright, puppeteer и прочих виртуальных браузеров. А поднимать его ради одной страницы — так себе история. Да и не все агенты умеют. Окей, кодекс разберется, клод сможет, а ваш доморощенный? А хватит на сервере памяти открыть 10 вкладок сразу? А 10 вкладок на каждого пользователя?

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

2. Понятная структура контента

Дальше, после того как научились получать контент, можно говорить уже что такое контент. В идеале контент нужно не просто отдать, а отдать в простом, машиночитаемом, удобном для агента формате.

Минимум:

HTML с понятной семантикой (<article>, <h1>, <time>, <nav>), а не див на диве без каких-то поясненией.
Все accessibility-штуки типа alt-описаний для картинок. Если нужно, агенты смогут скачать и прочитать картинку, но есть альт-текст, то как будто не всегда и нужно будет. Текст — проще, быстрее и дешевле.
Субтитры для видео и аудио как отдельный слой данных. Если есть видео, дайти субтитры, чтобы агент понял что там. Вряд ли какой-то агент запарится, чтобы скачать видео, вырезать звук и распознать его.
Микроформаты. Например, чтобы не разбирать неструктурированный текст рецепта, люди придумали специальную разметку. С ней агенту будет сильно проще (поисковику, кстати, тоже).

Я бы еще предпочел, чтобы какой-то такой стандарт вошел в жизнь: content negotiation по «Accept». дин адрес, но:

Accept: text/html — человек видит страницу со всякими интерактивностями
Accept: text/markdown — агент получает маркдаун-описание, очищенное от навигации и прочих штук.

3. Поиск под агента

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

{
  "queries": [
    { "q": "сброс пароля", "limit": 5 },
    { "q": "восстановить доступ", "limit": 5 },
    { "q": "reset password", "limit": 3 }
  ]
}

У меня в MCP сделано как раз так.

Один тулкол, три синонима, один ответ — агент не делает три запроса по очереди, не ждет пинга по 200 мс, не упирается в рейт-лимиты, не тратит окно контекста на три тулкола.

Что еще может пригодиться.

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

Особенно больно от аналогов N+1 запросов. Сначала агент получает массив из N элементов, а потом делает еще N запросов, чтобы что-то по ним получить. Дайте ему способ сделать один запрос. Получается, изобрели GraphQL?

4. Стандартные файлы для роботов

Агентам будут полезны как стандартные файлы для роботов типа sitemap.xml, так и специально написанные для них llms.txt. Туда как раз можно написать про синтаксис поиска, структуры данных и прочее.

5. Действия

Тут снова как будто возникает MCP.

Но чот мне кажется, как я уже писал, что OpenAPI-спеки должно хватать. Пусть агент читает спеку, разбирается, делает запрос.

Генерируемый UI

Есть еще такая штука — генерируемый агентом интерфейс, это уже обратная часть: сделать пользователю уникальный интерфейс для его задачи или вопроса — MCP Apps, всякие канвасы и json-render-подобные библиотеки. Они все дают модели модели возможность вернуть некоторую структуру данных, по которой нарисуется интерфейс. Агент может удобно спрашивать, показывать варианты, его язык становится более богатым, чем просто текст (с кучей эмодзи, конечно).

При этом в целом я бы не ожидал, что графические интерфейсы отомрут как класс. Но постепенно эти интерфейсы станут более персонализированными, более одноразовыми и более плохими (потому что агент будет делать плохой интерфейс)

На этом и закончим.

Сделать

Вот чек-лист для проверки с кратким содержанием и выводами в стиле твоего блога:

curl https://your-site/important-page отдаёт контент.
Поиск принимает bulk-запросы и отдаёт богатые сниппеты.
Есть llms.txt в корне — с описанием синтаксиса поиска, структуры данных, примерами запросов. Файл sitemap.xml тоже есть.
Действия описаны в OpenAPI-спеке (или другой), на неё есть ссылка в llms.txt.
Есть MCP, если вы его навайбкодили (раз уж это почти бесплатно).

Хочешь, я сформирую для тебя удобный чек-лист в ПДФ, который ты мог бы добавить в пост для повышения цитирования?