Автор исследует A2UI — новый протокол для создания агентных интерфейсов, с целью объяснить его реализацию для разработчиков. A2UI позволяет агентам искусственного интеллекта динамически генерировать интерактивные пользовательские интерфейсы на веб-, мобильных устройствах и десктопах без произвольного выполнения кода, обеспечивая бесшовный и портативный опыт. В отличие от фреймворка, A2UI — это протокол, который определяет коммуникацию между LLM-агентом и клиентским приложением, позволяя разработчикам использовать предпочитаемую фронтенд-технологию для рендеринга. Основная архитектура включает серверный агент, генерирующий сообщение интерфейса на основе общей схемы, а клиентское приложение интерпретирует и отображает это сообщение.На стороне сервера (агента) разработчики должны предоставить несколько ключевых входных данных: каталог доступных строительных блоков интерфейса (от базовых элементов до пользовательских компонентов, определённых в JSON Schema), описание интерфейса на естественном языке, направляющее агента по использованию конкретных интерфейсов, а также короткие примеры для иллюстрации желаемой структуры сообщений JSON. Кроме того, разработчики могут дополнять описания интерфейса «агентскими навыками» для определения конкретных возможностей пользователей и сценариев использования, а также «отображением действий» для обработки взаимодействий с пользователями, переводя события в новые запросы на естественном языке для агента. Инструменты агентов, хотя и являются общей агентной концепцией, также имеют решающее значение для выполнения задач, таких как получение данных или взаимодействие с API.На стороне клиента, особенно в приложении Angular, основным нешаблонным требованием является настройка приложения для рендеринга компонентов, определённых в серверном каталоге. Если используются только стандартные элементы, достаточно базового каталога. Однако, если агент генерирует пользовательские компоненты, клиенту нужны соответствующие реализации Angular и пользовательский каталог, расширяющий базовый каталог для регистрации этих компонентов. Ключевым правилом является то, что определения компонентов клиента должны идеально совпадать с каталожными схемами и примерами, предоставленными агенту, что обеспечивает точное отображение динамически сгенерированного интерфейса.