Как Jev управляет браузером и собирает интерфейсы, не генерируя текст: разбор Browser Use и json-render

Когда создают ИИ-систему для работы с браузером, самый очевидный подход обычно выглядит так: передать универсальной большой модели скриншот или DOM, попросить её проанализировать страницу и спланировать следующий шаг, а затем сгенерировать координаты клика, селектор или вызов инструмента.

С построением интерфейса часто поступают так же. Пользователь описывает задачу, модель напрямую генерирует JSON, JSX или фронтенд-код, после чего система пытается разобрать, проверить и отрисовать результат.

Jev Ultrafast от Browser Use и эксперимент Jev в json-render идут другим путём:

Сначала код ограничивает действия модели конечным набором, а Jev только выбирает внутри этого набора.

В Browser Use этот набор состоит из доступных действий и интерактивных элементов текущей веб-страницы. В json-render — из заранее подготовленных приложением компонентов, конфигураций свойств, привязок данных и позиций в макете.

Jev не нужно писать полный план действий или генерировать целое дерево UI в JSON. Он отвечает лишь на вопросы вроде следующих:

• Следующим шагом должен быть клик, ввод текста, прокрутка или ожидание?
• С каким элементом на текущей странице нужно взаимодействовать?
• Какие компоненты должны появиться в интерфейсе?
• В какой родительский контейнер, слот и позицию следует поместить компонент?

Эти два примера не доказывают, что «модель без генерации текста умеет всё». Они показывают другую архитектуру программного обеспечения: открытая генеративная задача превращается в последовательность ограниченных и проверяемых решений.

Что именно делает Jev

Jev — модель System One, выпущенная TypeSafe AI. Она принимает state и набор типизированных вопросов, заданных разработчиком, а возвращает структурированные результаты, например Choice, Score или Noul, вместо длинного текста для чтения человеком.

Её можно представить как функцию принятия решений с вероятностным выходом:

Текущее состояние
   ↓
Разработчик формирует конечный набор кандидатов
   ↓
Jev выбирает, оценивает или проверяет
   ↓
Обычный код валидирует результат
   ↓
Выполняется действие или отрисовывается интерфейс

Здесь:

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

Главное здесь не формат ответа, а разделение ответственности. Jev не генерирует свободно тексты для страницы, браузерные селекторы, JavaScript или полный JSON. Состояние, поток управления, права и исполнение по-прежнему контролирует код. TypeSafe описывает этот подход как «на входе неструктурированное состояние, на выходе — типизированные вероятностные решения». (typesafe.ai)

Ниже разберём, как Browser Use и json-render реализуют эту схему в реальных системах.

---

Browser Use: сначала превратить веб-страницу в конечное пространство действий

Проект jev-ultrafast от Browser Use показывает браузерного агента: пользователь задаёт цель на естественном языке, программа читает текущую страницу, Jev выбирает следующее действие, а браузерный код его выполняет.

В публичной демонстрации нужно найти в Google Flights билет в одну сторону из Zürich в London. В записи проекта задача заняла около 7,1 секунды, включая вызовы моделей, генерацию текста, действия браузера, загрузку страницы и повторные попытки из-за устаревших решений. Но это всё ещё один сценарий в одной конфигурации браузера, а не общий тест надёжности на произвольных сайтах. (github.com)

Шаг 1. Страницу читает код, а Jev не просто «смотрит на скриншот»

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

Упрощённый вариант может выглядеть так:

[1] button     Изменить тип билета · Туда и обратно
[2] combobox   Откуда?             · San Francisco
[3] combobox   Куда?               · пусто
[4] textbox    Дата вылета         · пусто
[5] button     Найти

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

В этом примере Jev не рассматривает скриншот напрямую и не угадывает, что кнопка находится в координатах (482, 316). Скриншоты нужны главным образом для демонстрации и проверки человеком. Решения принимает модель на основе структурированного состояния, извлечённого из DOM. В проекте также прямо сказано, что номера на странице добавляются при отрисовке скриншота и не управляют браузером. (github.com)

Это важное различие.

Если модель свободно генерирует координаты или CSS Selector, она может вернуть:

• селектор, которого нет на странице;
• уже устаревшее положение элемента;
• перекрытый или недоступный для клика элемент;
• JavaScript, способный выполнить произвольное действие.

В Jev Ultrafast модель может выбирать только из индексов элементов, которые программа только что увидела.

Шаг 2. Jev выбирает действие и целевой элемент

В проекте предусмотрен такой набор действий:

CLICK
TYPE_TEXT
SELECT
SCROLL_UP
SCROLL_DOWN
WAIT
DONE
BLOCKED

В зависимости от текущего состояния страницы программа предлагает только те действия и совместимые цели, которые действительно доступны в данный момент.

Например:

• если на странице нет выпадающего списка, цели для SELECT не предлагаются;
• если есть три текстовых поля, целью ввода могут быть только эти три элемента;
• если есть десять кликабельных элементов, клик можно направить только на один из этих десяти элементов.

Одно решение можно упростить до такого вида:

Вопрос 1: Каким должно быть следующее действие?
Кандидаты: CLICK / TYPE_TEXT / SELECT / WAIT / DONE

Вопрос 2: Если выбрано CLICK, на какой элемент нажать?
Кандидаты: [1] / [5] / [8] / [11]

Вопрос 3: Если выбрано TYPE_TEXT, в какой элемент ввести текст?
Кандидаты: [2] / [3] / [4]

Эти вопросы можно обработать параллельно в одном запросе. Выполняется только та цель, которая совместима с выбранным действием. Если Jev выбирает CLICK, программа читает только click_target и не выполняет цель, заранее рассчитанную для TYPE_TEXT.

Авторы проекта называют это динамическим индексированным пространством действий. Оно сокращает число последовательных обращений к модели на каждом шаге и не требует от модели свободно генерировать параметры операции. (github.com)

Шаг 3. Генеративная модель вызывается только тогда, когда нужно написать текст

Jev может решить, что сейчас нужно ввести значение в поле отправления, но сам текст он не генерирует.

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

{
  "text": "Zürich"
}

Перед вводом в браузер результат всё равно нужно разобрать как небольшой JSON-объект.

Таким образом, браузерный агент объединяет две разные способности:

Задача	Кто отвечает
Решить, нужно ли кликнуть, ввести текст, выбрать значение или подождать	Jev
Выбрать элемент страницы	Jev
Сгенерировать естественный текст для ввода	Небольшая генеративная модель
Прочитать DOM и состояние страницы	Браузерный код
Кликнуть, ввести и выбрать	Браузерный код
Убедиться, что цель действительно достигнута	Независимый код проверки

Поэтому выражение «Jev управляет браузером» не означает, что Jev самостоятельно выполняет всю задачу.

Точнее будет сказать: Jev — это селектор действий внутри браузерного цикла.

Шаг 4. Перед выполнением код снова проверяет страницу

После выбора модели программа не нажимает на элемент вслепую.

Перед выполнением Jev Ultrafast проверяет:

• осталась ли текущая страница той же, которую наблюдала модель;
• существует ли соответствующий DOM-узел;
• не перекрыт ли элемент другим содержимым;
• остаётся ли его геометрия актуальной;
• совпадают ли значение формы и ближайший контекст со снимком состояния;
• не изменился ли вход для запроса генерации текста.

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

Проект прямо ограничивает превращение ответа модели в действие: он не преобразуется напрямую в CSS Selector, экранные координаты, shell-команду или исполняемый JavaScript. Любая исполняемая цель должна быть повторно разрешена в реальный DOM-узел, который ранее наблюдала программа. (github.com)

Этот код не выглядит «умным», но именно он определяет надёжность системы.

Результат в семь секунд нельзя приписывать только Jev

В шести чередующихся запусках обе реализации успешно выполнили задачу по три раза. Медианное время снизилось примерно с 9,450 до 7,092 секунды, то есть примерно на 25%; число вызовов браузерного протокола уменьшилось с 1 092 до 101. Автор отдельно подчёркивает, что речь идёт лишь о трёх запусках каждой реализации на одной задаче и в одной конфигурации браузера, а не об общем тесте надёжности. (github.com)

Рост производительности связан не только со скоростью модели, но и со всей реализацией браузера:

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

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

Текущий MVP также не поддерживает полностью shadow DOM, iframe, canvas, загрузку файлов, всплывающие вкладки, вложенную прокрутку и произвольные клавиатурные виджеты. Даже если модель выбирает DONE, система всё равно отдельно проверяет, действительно ли задача завершена. (github.com)

---

json-render: Jev выбирает компоненты, а не генерирует весь JSON страницы

json-render решает другую задачу: как по запросу на естественном языке собрать интерфейс, который можно сразу отрисовать.

В традиционном генеративном UI модель часто просят напрямую создать:

• код React или Vue;
• целое дерево UI в JSON;
• CSS и параметры макета;
• логику обработки событий;
• конфигурацию привязки данных.

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

Эксперимент json-render с Jev формулирует задачу иначе:

Приложение заранее готовит набор допустимых экземпляров компонентов, а Jev лишь решает, какие из них использовать и как их объединить.

Эта возможность всё ещё помечена как экспериментальная. experimental_composeSpec и experimental_createEvaluator не выпущены как стабильные API; их названия и поведение могут меняться между версиями. Документация рекомендует фиксировать точную версию и проверять журнал изменений. (json-render.dev)

Сначала приложение предоставляет каталог компонентов и кандидатов

Допустим, пользователь просит:

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

Приложение не передаёт эту фразу Jev с просьбой свободно написать UI JSON.

Вместо этого оно сначала предоставляет кандидатов:

Dashboard
OrdersTable
MetricRow
RevenueMetric
OrdersMetric
NewCustomersMetric
RevenueBarGraph

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

• тип компонента;
• фиксированные свойства;
• доступную конфигурацию макета;
• привязки состояния;
• привязки данных;
• разрешённые действия;
• описание кандидата для модели.

Например, кандидат кнопки можно заранее определить так:

Компонент: Button
Текст: Сохранить
Действие: savePreferences
Аргументы: прочитать текущее состояние /name

Jev может выбрать, использовать ли эту кнопку, но не может придумать незарегистрированное действие deleteAllUsers.

Документация json-render подчёркивает, что доступные возможности и дизайн-систему контролирует платформа. Jev может выбирать только из компонентов, конфигураций и привязок действий, переданных приложением; отсутствующие тексты, данные и компоненты автоматически не создаются. (json-render.dev)

Этап 1. Выбрать необходимые компоненты интерфейса

При создании нового интерфейса первая группа решений определяет:

• какой кандидат станет корневым узлом;
• какие компоненты следует выбрать;
• сколько экземпляров повторно используемого компонента требуется;
• какой вариант выбрать, если у одного ресурса есть несколько вариантов.

Например:

Корневой компонент: Dashboard

Добавить:
- OrdersTable
- MetricRow
- RevenueMetric
- OrdersMetric
- NewCustomersMetric
- RevenueBarGraph

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

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

Это отличается от последовательной генерации полного JSON токен за токеном: Jev не пишет сериализованный JSON. JSON собирается кодом из ограниченных вариантов. (json-render.dev)

Этап 2. Определить отношения родитель—потомок и порядок

После выбора компонентов вторая группа решений отвечает за макет:

• к какому родительскому узлу относится каждый компонент;
• в какой именованный слот родителя его поместить;
• в каком порядке расположить соседние компоненты.

Итоговая структура может выглядеть так:

Dashboard
├── OrdersTable
├── MetricRow
│   ├── RevenueMetric
│   ├── OrdersMetric
│   └── NewCustomersMetric
└── RevenueBarGraph

Затем код проверяет:

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

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

Для простых структур с одним корнем или одним потомком в единственном слоте вторая оценка макета может вообще не потребоваться. (json-render.dev)

Редактирование интерфейса — тоже выбор, а не полная перезапись

json-render умеет редактировать существующий Spec, например:

• удалить кнопку «Сохранить»;
• переместить таблицу заказов выше графика;
• заменить один тип графика другим доступным кандидатом;
• изменить порядок полей;
• заменить конфигурацию компонента.

Обычно такие правки выполняются последовательно:

1. Выбрать элемент, который нужно изменить.
2. Выбрать новый рецепт компонента или целевую позицию.
3. Применить изменение в коде.
4. Снова проверить всё дерево.

Идентификаторы неизменённых компонентов, привязки состояния, данные и совместимые дочерние элементы по возможности сохраняются. Входной Spec не изменяется напрямую. (json-render.dev)

Выбор кнопки ещё не означает автоматическое выполнение её действия

json-render явно разделяет «сборку интерфейса» и «выполнение бизнес-действия».

Jev может выбрать кнопку, привязанную к savePreferences, но composer сам не вызывает это действие. Исполнение происходит только после клика пользователя и обрабатывается action handler хост-приложения.

Приложение всё равно должно обеспечить:

• проверку прав пользователя;
• проверку аргументов;
• серверную авторизацию;
• проверку корректности данных;
• идемпотентность и аудит;
• дополнительное подтверждение опасных операций.

Документация отдельно предупреждает: регистрация действия в каталоге не делает безопасным приём любых аргументов. Composer не может проверить будущие данные среды выполнения и не выполняет авторизацию вместо приложения. (json-render.dev)

Структурная корректность не гарантирует правильный интерфейс

json-render может гарантировать соответствие поддерживаемой структуре и схеме, но не может гарантировать, что выбранный Jev интерфейс будет полным, разумным или визуально удачным.

В документации приводится такой пример:

Создай панель с таблицей сверху

Такой запрос может выбрать только таблицу, потому что в нём явно не упомянуты показатели и график.

Более конкретный запрос:

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

с большей вероятностью выберет все необходимые кандидаты и расположит их в ожидаемом порядке.

Это показывает важное ограничение: Jev принимает решения только внутри пространства кандидатов, а за полноту этого пространства и ясность запроса отвечает разработчик.

В публичной документации для повторно используемого API по умолчанию указаны ограничения: не более 32 оценок, не более 32 элементов за одну пакетную операцию создания и максимальная глубина 8. В публичном Playground ограничения строже: не более 14 элементов в пакете, 14 оценок и глубина 4. При достижении лимита вызовов, элементов или глубины система может вернуть частичный Spec, но «процесс завершён» всё равно не означает, что результат семантически правильный. (json-render.dev)

---

Оба примера фактически используют одну архитектуру

Если поставить Browser Use и json-render рядом, видно, что они решают разные задачи, но имеют почти одинаковую структуру.

Этап	Browser Use	json-render
Цель пользователя	Найти рейс, заполнить форму, открыть страницу	Создать или изменить интерфейс
Состояние, которое читает код	Видимый DOM, элементы управления, текст и значения	Текущий Spec, кандидаты компонентов, каталог и структура дерева
Конечное пространство кандидатов	Клик, ввод, выбор, прокрутка и интерактивные элементы	Экземпляры компонентов, родители, слоты и порядок
Ответственность Jev	Выбор действия и цели	Выбор компонентов, отношений родитель—потомок и порядка
Ответственность генеративной модели	Генерация текста только тогда, когда нужен ввод	В пути Jev свободной генерации UI нет; новые тексты и данные нужно предоставить заранее или сгенерировать отдельно
Ответственность обычного кода	Снимки DOM, проверка актуальности, исполнение, ожидание и проверка результата	Сборка Spec, проверка схемы, проверка дерева, рендеринг и авторизация действий
Основные причины сбоев	Устаревшее состояние страницы, исчезнувшая цель, неподдерживаемый контрол	Недостающие кандидаты, неоднозначный запрос, неполный макет, неудачный выбор
Итоговая проверка	Проверить, действительно ли достигнута цель задачи	Проверить, полон ли Spec, пригоден ли он к использованию и соответствует ли требованиям продукта

В обоих случаях используется одна формула:

Преобразовать среду в структурированное состояние
        ↓
Преобразовать доступные действия в конечный набор кандидатов
        ↓
Дать Jev сделать выбор
        ↓
Дать коду проверить и выполнить
        ↓
Снова наблюдать результат

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

---

Почему модель без генерации текста всё равно выглядит «умной»

Интеллект не обязательно должен выражаться статьёй, кодом или диалогом.

Во многих программных процессах системе нужен лишь выбор:

• На какую кнопку нажать сейчас?
• В какую область поместить этот элемент?
• Следует ли продолжать выполнение?
• Какая конфигурация компонента лучше соответствует запросу пользователя?
• Достигнут ли текущим результатом нужный итог?

Универсальная LLM может сначала написать объяснение, а затем упаковать ответ в JSON. Но если коду в итоге нужен только один вариант, большая часть промежуточной генерации текста может не приносить пользы.

Эксперименты Browser Use и json-render переносят значительную часть «мышления» в проектирование системы:

• разработчик определяет состояние;
• разработчик определяет пространство кандидатов;
• разработчик определяет правила выполнения;
• модель заполняет только те семантические пробелы, которые трудно покрыть обычными правилами.

Такая архитектура не устраняет ошибки, а меняет их форму.

Jev не вернёт компонент или действие вне набора кандидатов, но всё ещё может:

• выбрать не ту кнопку;
• выбрать не тот компонент;
• слишком рано объявить задачу завершённой;
• выбрать менее удачный макет из нескольких разумных;
• пропустить необходимое содержимое из-за неоднозначной формулировки.

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

---

Какие задачи подходят для такого подхода

Browser Use и json-render дают практический критерий:

Если задачу можно разложить на «выбрать из конечного набора кандидатов», такой узел решения можно рассмотреть для Jev.

Относительно хорошо подходят:

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

Не следует напрямую передавать Jev:

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

В реальном продукте обычно сочетаются разные модели:

Универсальная модель: генерирует цели, текст, код или варианты плана
Jev: оценивает, фильтрует и маршрутизирует кандидатов
Обычный код: проверяет, выполняет, применяет резервный путь и ведёт журнал

Небольшая генеративная модель в Browser Use — прямой пример такого разделения: Jev решает, что текст нужно ввести, а генеративная модель определяет, какой именно текст.

---

Главный урок — разделение ответственности, а не сами два демо

Самый полезный вывод из Browser Use и json-render состоит не в том, что «Jev умеет ходить по сайтам» или «Jev умеет генерировать UI».

Точнее сформулировать так:

• Browser Use превращает свободную генерацию браузерных действий в выбор над реальными DOM-элементами;
• json-render превращает свободное написание JSON-интерфейса в выбор и упорядочивание компонентов из собственного каталога приложения;
• Jev предоставляет семантическое решение;
• код ограничивает права, хранит состояние, проверяет структуру и исполняет результат;
• когда нужен открытый текст, его по-прежнему создаёт генеративная модель.

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

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

• какое состояние увидела модель;
• какие кандидаты предоставил разработчик;
• какие действия разрешены системой;
• можно ли перехватить ошибочный результат;
• можно ли принять новое решение после изменения страницы или интерфейса;
• проверяется ли завершение независимо.

Отсутствие генерации текста не означает, что Jev ничего не умеет.

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