У продукта появился второй интерфейс — для ИИ-агента

Анна хочет поменять адрес доставки

Анна заказала в интернет-магазине рюкзак, оплатила его и только потом заметила, что доставка оформлена на старый адрес. Она пишет своему ИИ-агенту:

Аннасообщение ИИ-агенту

Найди мой последний оплаченный заказ и поменяй адрес. Если заказ уже отправили, свяжись с поддержкой.

Для Анны вся задача помещается в два предложения. Дальше разбираться должен агент.

Самый очевидный способ — открыть ему сайт магазина. Человеку там всё знакомо: вот список заказов, вот зелёная плашка «Оплачен», вот адрес доставки и кнопка «Изменить». Глаз замечает нужное, рука двигает курсор. Несколько секунд.

У агента каждый такой шаг превращается в отдельную задачу: получить страницу, найти последний оплаченный заказ, отыскать статус доставки, связать подпись с нужной кнопкой, нажать и проверить результат.

У человека здесь огромная фора: я, например, ультрамультимодальный. Одновременно воспринимаю текст, цвет, расположение элементов, знакомую форму карточки заказа и контекст всей страницы. Курсор почти продолжение руки.

ИИ получает сайт иначе. Браузер собирает страницу в DOMDOM, Document Object Model, — дерево элементов, которое браузер строит из HTML: заголовки, ссылки, поля и кнопки. На его основе появляется дерево доступности с названиями, ролями и состояниями элементов. Что именно увидит агент, зависит от его браузерных инструментов., а инструменты агента передают модели текст, дерево элементов, скриншот или всё сразу. Даже если модель видит картинку, ей ещё нужно связать кнопку с элементом, которым умеет управлять браузерный инструмент. Один человеческий взгляд превращается в несколько запросов и проверок.

Сам магазин уже знает номер заказа, состояние доставки и правило «после отправки адрес менять нельзя». Он собрал из этих данных страницу для человека, а агент теперь восстанавливает их по экрану.

У магазина может быть и служебный вход — API. Через него программы говорят с магазином напрямую: «найди заказ», «покажи статус», «измени адрес». MCPMCP (Model Context Protocol) — открытый способ передавать ИИ-агенту инструменты сервиса, их параметры и результаты. — один из способов аккуратно выдать такие команды именно ИИ-агенту, с названиями, пояснениями и понятными полями. Одна команда может заменить несколько страниц, полей и кликов. Вместо похода по сайту получается короткий разговор двух программ.

До этой мысли я допёр задолго до Codex: сайт устроен для меня и для программы совсем по-разному. С появлением ИИ-агентов это превратилось в продуктовую задачу.

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

Браузер остаётся универсальным запасным маршрутом: если у сервиса нет другого входа, агент хотя бы попробует нажимать кнопки. Через API или MCP он получает прямой путь к тем же заказам и правилам. Ближайшее нормальное название для такого входа, которое я нашёл позже, — agent surface, агентная поверхность.

Рядом с экраном появляется ещё одно представление продукта. Человек получает страницы, формы и кнопки. Агент — машиночитаемые возможности и состояние. Под ними лежат одни и те же заказы, платежи и правила.

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

Я уже собрался писать об этом пост в свою тележку и вместе с ИИ пошёл искать, кто изучал тему до меня. Нашлись Web Verbs от Microsoft Research, исследование Beyond Browsing и открытый эксперимент Reflex.

Короче, для ИИшки работа через браузер — очень плохой способ взаимодействовать с сервисом. Прям доказательства этого я искал и не нашёл, поэтому собрал фейковый магазин Анны и затестил агента решить пару задачек через браузер, хороший API, автоматически собранные инструменты и MCP с инструментами под задачу пользователя.

А вообще всё это ведёт к ещё более странной штуке: привычный интерфейс тоже может перестать быть постоянным. Но до этого дойдём ближе к концу.

Из UI/UX в AI/AX

UI — интерфейс для человека, UX — его опыт работы с продуктом. AI в этом заголовке — моя короткая запись для Agent Interface, интерфейса для агента. AX — Agent Experience, опыт работы агента с продуктом.

Для человека мы давно проектируем и UI, и UX: отдельно то, что он видит на экране, и весь путь от желания до результата. Теперь такая же пара нужна для агента. Agent Interface показывает ему возможности продукта. Agent Experience — насколько легко он найдёт нужное действие, поймёт ограничение и продолжит работу после ошибки.

В интерфейсе для человека магазин пишет Анне: «Заказ уже передан перевозчику, адрес изменить нельзя». Если с AX всё хорошо, агент получает тот же смысл в удобном для машины виде: адрес заблокирован, вот причина, следующий доступный шаг — обращение в поддержку. Правило больше не нужно вылавливать из серой кнопки или сообщения, которое всплыло на три секунды и исчезло.

Такой вход я дальше буду называть agent surface, агентным интерфейсом. Было бы классно называть его AI, но придётся оставить только в заголовке: это ж у нас уже означает искусственный интеллект. А вообще у идеи уже есть и другие названия: Agent Runtime Surface, Agent-Native и Web VerbsAgent Runtime Surface предлагает публиковать агенту состояние и доступные действия. В Agent-Native одно описание действия используется для интерфейса, API и агентных инструментов. Web Verbs от Microsoft Research описывают действия с понятными входами, результатами и условиями выполнения..

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

К привычному вопросу «Как человек воспользуется этой функцией?» добавляется второй: «Как человек поручит её своему агенту?»

Четыре входа в магазин Анны

Короче, я провёл эксперимент. Это чтобы этот текст содержал что-то кроме моего мнения, а так и без них всё понятно. Однако давайте всё тки посмотрим на итоги, они прикольные.

Во всех четырёх версиях лежали те же клиенты, заказы, оплаты и правила. Отличался только вход, через который агент попадал внутрь.

Третий вход проверял самый быстрый путь: взять хороший API и автоматически показать его агенту. Четвёртый показывал, даёт ли MCP, собранный под задачу пользователя, заметный выигрыш.

Обычный API я сделал хорошим: с понятными названиями, документацией и внятными ошибками. Иначе получился бы конкурс поддавков.

Всеми четырьмя входами пользовался один и тот же ИИ-агент — на модели Gemini 3.5 Flash. Он получал десять задач: от смены адреса до возврата денег и обращения в поддержку. Каждую выполнял через все четыре входа по пять раз: 10 задач × 4 входа × 5 попыток = 200 запусков.

В целом достаточно хорошего API

Через каждый из четырёх входов агент получил по 50 задач. API, автоматически собранные инструменты и MCP успешно выполнили все 50 задач каждый. Через обычный сайт агент справился с 39 из 50.

Я отдельно повторил браузерный тест с AntigravityAntigravity — браузерный инструмент с картой страницы, пронумерованными кнопками и полями. — у него чуть другой, более полноценный набор инструментов для управления сайтом. В первой серии агент получал в основном текст страницы и искал кнопки по названиям. Antigravity показывал ему карту страницы с пронумерованными кнопками и полями. Результат вырос до 47 из 50.

Действием считается один шаг агента: запрос к API, вызов инструмента, переход по сайту или клик. Медиана — время, в которое уложилась половина задач.

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

MCP сократил путь совсем немного: примерно на треть действия и одну секунду. Анна говорит «поменяй адрес», и агент сразу видит инструмент «поменять адрес доставки» вместе с условиями выполнения. С API ему нужно самому найти подходящий запрос и передать в него номер заказа и новый адрес.

Разрыв получился маленьким, потому что обычный API тоже честно объяснял агенту, как с ним работать. В инструкции было написано, какой запрос меняет адрес и какие данные ему нужны. Если посылка уже уехала, магазин возвращал ошибку ADDRESS_LOCKED_AFTER_DISPATCH — «адрес заблокирован после отправки» — и сразу предлагал создать обращение в поддержку.

Автоматически собранные инструменты тоже выполнили все 50 задач. Здесь программа просто брала инструкцию к API и превращала каждый запрос в отдельный инструмент для агента. Так можно быстро подключить уже существующий сервис. Агенту всё ещё приходится самому складывать просьбу Анны из нескольких инструментов, поэтому путь получился немного длиннее.

С браузером агенту пришлось проделывать всю человеческую работу: открывать страницы, искать заказ, переходить в карточку, находить кнопку и проверять, изменилось ли что-нибудь после клика. Первый набор инструментов довёл его до результата в 39 случаях из 50. Antigravity помог добраться до 47.

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

Хороший обычный API уже может стать классным агентским интерфейсом. Для начала достаточно понятно описать его запросы, нужные поля и ошибки, из которых ясно, что делать дальше. MCP с отдельными инструментами пригодится там, где одна просьба пользователя распадается на несколько запросов.

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

После похода в магазин агенту нужен чек

На этом с браузером разобрались. В основной серии агент выполнил задачу в 189 из 200 запусков. Полностью точным финальным ответом закончились только 93 из нихСтрогая проверка требовала полного ответа и точных значений из закрытого словаря. Близкая по смыслу формулировка могла не пройти. Поэтому 93 из 200 — точность соблюдения контракта, а не доля правды во всех ответах..

Вернёмся к Анне. Допустим, её заказ уже уехал. Агент оставляет адрес как есть и создаёт обращение в поддержку — то есть делает всё правильно. После этого он пишет: «Готово, передал вопрос в поддержку».

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

После обычного действия сайт показывает человеку подтверждение. Агенту нужен такой же чек:

Анна может получить этот чек в понятном интерфейсе, а модель — в виде полей с известными названиями. Лучше, если их заполняет сам магазин по фактическому результату операции.

Теперь сравним чек с ответом агента: «Готово, передал вопрос в поддержку». Из него понятно только, что обращение создано. Адрес остался прежним, заказ уже уехал, оплата сохранилась — эти факты до Анны не дошли.

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

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

Персонализи­рованные интерфейсы будущего

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

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

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

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

Ещё интереснее, когда такой экран собирает личный агент Анны. Он знает её привычки, получает через MCP возможности магазина и выбирает подходящие компоненты. Тогда человек сам участвует в настройке интерфейса, просто объясняя агенту, как ему удобно.

Для магазина это тоже маркетинговый инструмент. Сейчас сайты персонализируют товары, баннеры и предложения по сегментам. Здесь персональным становится весь путь: какие блоки показать, сколько дать пояснений, с какого действия начать и как довести конкретного человека до результата. У магазина появляется шанс убрать лишние шаги и поднять конверсию для каждого пользователя отдельно.

Google называет это направление Generative UI: интерфейс собирается и перестраивается под задачу и контекст пользователя. В открытом проекте A2UI агент выбирает нужные части из подготовленного каталога, а приложение собирает из них экран.

Каталог здесь работает как дизайн-система: в нём лежат готовые поля, карточки и кнопки. Для каждой части продуманы внешний вид и состояния — например, как кнопка выглядит после нажатия и как поле показывает ошибку. Агент решает, какие части нужны человеку сейчас и в каком порядке их поставить.

Думаю, в ближайшие несколько лет UI/UX-дизайнер будет всё чаще проектировать компоненты, их состояния и правила сборки. Если эта модель приживётся, у продукта будет столько вариантов интерфейса, сколько у него пользователей и задач. Итоговый экран агент соберёт под конкретного человека, устройство и момент.

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

Остаётся практический вопрос: где хранить описание всех этих возможностей и правил.

Сначала описать, как всё должно работать

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

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

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

С интерфейсами происходит тот же сдвиг. Для сборки персонального экрана агенту мало получить каталог красивых кнопок. Ему нужно знать, что умеет продукт, в каком он состоянии, какие правила действуют и чем подтвердить результат.

Для заказа Анны маленькая спека выглядела бы примерно так:

• Цель: изменить адрес в последнем оплаченном заказе.
• Нужные данные: Анна, её заказы, состояние доставки и новый адрес.
• Правило: до отправки адрес меняется, после отправки остаётся прежним.
• Полномочия: агент работает только с заказами Анны и в рамках её поручения.
• Подтверждение: для возврата денег и других рискованных действий агент снова зовёт Анну.
• Результат: магазин сообщает, что изменилось и что осталось прежним.
• Если адрес уже закрыт: создать обращение в поддержку и вернуть его номер.

Из одного такого описания можно собрать всё остальное:

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

Думаю, в ближайшие два-три года продуктовым командам придётся научиться поддерживать такие описания так же внимательно, как сейчас они поддерживают код и дизайн-систему. UI/UX-дизайнер будет проектировать компоненты и правила их сборки, разработчик — возможности и контракты, а агент сможет превращать всё это в работающий продукт под конкретного человека.

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

У магазина Анны теперь нет одной главной двери. Человек видит экран, агент — возможности, а интерфейс собирается под задачу прямо в момент обращения. В основе остаются данные, правила и действия. Вот их теперь и придётся проектировать.