Разборы · Статья: · Видео: · 4:25
Браузерным агентам нужны не модели поумнее, а зрение получше: сжатая карта страницы вместо скриншотов
Кушан Радж (ARK) на AI Engineer объясняет, почему браузерные агенты медленные и ненадёжные не из-за слабых моделей, а из-за плохого «зрения»: полный DOM на 20 000 токенов и скриншоты не дают увидеть страницу целиком. Решение — сжатое markdown-представление всей страницы (~1 800 токенов) плюс обратная связь о том, что на странице изменилось.
Смотреть на YouTube Browser Agents Don't Need Better Models. They Need Better Eyes. - Kushan Raj, ARK
AI Engineer · 4:25
Главы видео — нажми, чтобы перейти к моменту 9
- 0:00 Браузерные агенты крутые, но их не используют Автор признаёт: идея огонь, но реального внедрения нет, и он сам почти не пользуется браузерными агентами.
- 0:17 Browser challenge вскрывает проблему На бенчмарке из 30 шагов агент тратит 10–20 секунд только чтобы нажать кнопку «старт».
- 0:51 Гипотеза: модели умные, инфра плохая Его собственный агент на дешёвой модели тот же сайт проходит заметно быстрее.
- 1:09 Основной тезис: дай агенту хорошую среду Сжатое представление, в котором агент видит всю страницу за считанные токены и может планировать длинные последовательности.
- 1:26 Пример 1: скачать документ (Aadhaar) Claude делает скриншот, видит кнопку, кликает — и застревает: скроллит, снова скриншот, две минуты впустую.
- 2:02 Пример 2: бронирование на канадском сайте Claude не может выбрать дату и зависает; агент автора выбирает дату и завершает бронь.
- 2:39 Что дальше: open source и API Код «не особо защищаемый», поэтому план — открыть проект и продавать API: дай URL и намерение, получи результат.
- 3:31 Сравнение по токенам Полный DOM ~20 000 токенов, скриншот ~1 100, markdown-карта ~1 800 — но показывает всю страницу, а не один фрагмент.
- 3:50 Обратная связь об изменениях Агенту сообщают, что появилось, что исчезло, что раньше блокировало клик и что клик не сработал.
Коротко
Браузерные агенты тормозят не потому, что модели глупые, а потому, что среда вокруг них плохая: агент видит страницу через «замочную скважину» скриншота или тонет в 20 000 токенов сырого DOM. Дай ему сжатую карту всей страницы и подсказки о том, что изменилось после клика — и даже дешёвая модель делает за секунды то, на чём дорогая застревает на две минуты.
Выжимка голосом
Самое ценное из разбора — за пару минут
Показать текст выжимки Скрыть текст выжимки
Озвучено синтезом речи · голос alena
Объясни проще
Суть без жаргона
Простыми словами
Браузерный агент — это ИИ, который сам кликает по сайтам вместо тебя: заказать билет, скачать документ, заполнить форму. Пока они работают плохо и медленно. Автор говорит: проблема не в «мозгах» модели, а в том, что она плохо видит страницу — либо через узкий скриншот, либо через огромную кучу технического кода. Он сжал всю страницу в короткую текстовую карту, которую модель читает целиком и дёшево, и добавил подсказки о том, что поменялось после каждого действия.
Как ребёнку
Представь, что робот должен найти выключатель в тёмной комнате, но ему разрешили светить фонариком только в одну точку за раз. Он тычется наугад и очень долго ищет. Автор просто включил в комнате свет — дал роботу увидеть всю комнату сразу. И тот же робот, даже самый простой, стал находить выключатель за секунду.
Аналогия — «это как…»
Это как разница между тем, чтобы читать сайт через трубочку от рулона бумаги и видеть только один абзац за раз, и тем, чтобы получить на руки аккуратную карту всей страницы. Модель одна и та же — но с картой она наконец понимает, где что находится, и куда нажимать.
Зачем это мне
Все ждут, что «вот выйдет модель поумнее — и агенты заработают». Этот доклад разворачивает фокус: чаще всего узкое место не в модели, а в инфраструктуре вокруг неё — в том, как ты подаёшь агенту контекст. Это меняет то, куда стоит вкладывать силы при разработке любого агента, а не только браузерного.
Для тех, кто в теме
Тезис: bottleneck браузерных агентов — не reasoning, а observation/representation. Полный DOM (~20k токенов) даёт шум, скриншот (~1.1k токенов) даёт только видимый вьюпорт. Автор строит компактное markdown-представление всей страницы (~1.8k токенов) плюс дельту состояния между шагами (что появилось, что исчезло, что разблокировалось, какой клик не сработал) — фактически observability-слой среды. Результат: дешёвая модель на длинных последовательностях бьёт дорогую в «сыром» окружении. Проект недифференцируемый по коду, автор целит в API/plugin-дистрибуцию.
Оценка видео
Чем выше — тем больше пользы на минуту
средняя из 5
Браузерные агенты и токен-эффективность контекста — одна из горячих тем 2026 года.
Идея ясная и ценная, но за 4 минуты это скорее демо и тезис, чем глубокий разбор — без метрик успешности и деталей формата представления.
«Сжатая карта страницы + дельта изменений» вместо гонки за умной моделью — свежая перерамка проблемы, хотя идеи accessibility-tree и семантического слоя существуют.
Задаёт верное направление, но готовой реализации не даёт — проект на момент доклада ещё не открыт.
Сравнения «Claude застрял / мой агент — раз и готово» наглядны, но это отобранные кейсы без воспроизводимого бенчмарка.
Кому будет полезно
Чем выше оценка — тем больше пользы для профессии. Разверни — почему.
Для разработчиков ИИ-агентов 4.7 /5
Прямое попадание: доклад формулирует архитектурный принцип — вкладывайся в представление среды и обратную связь, а не только в выбор модели.
Для инженеров автоматизации и QA-автоматизаторов 4.3 /5
Браузерная автоматизация без хрупких селекторов: как подать агенту всю страницу и состояние, чтобы длинные сценарии не рассыпались.
Для продакт-менеджеров ИИ-продуктов 3.8 /5
Помогает не купиться на «возьмём модель поумнее» и понять, что надёжность агента чаще упирается в инфраструктуру вокруг модели.
Для основателей стартапов 3.6 /5
Видна рыночная ниша быстрых браузерных агентов, но и честное предупреждение: алгоритм легко скопировать, защита — в дистрибуции и данных.
Для фронтенд-разработчиков 3.3 /5
Полезно понять, как страница «видится» агентом: семантика и доступность становятся входом не только для людей, но и для ИИ.
Инсайты
Нажми, чтобы раскрыть — то, что меняет взгляд на тему
01 Узкое место агента — не ум, а зрение 0:51
Мы привыкли объяснять провалы агента слабостью модели. Автор показывает: та же задача, тот же сайт, но дешёвая модель с хорошим «зрением» обгоняет дорогую — значит, лимитирует восприятие и среда, а не reasoning.
02 Полный DOM — это шум, а не зрение 3:31
20 000 токенов сырого кода страницы не помогают, а топят модель: она видит гору деталей, но не понимает структуру. Меньше, но осмысленнее — сильнее, чем «всё сразу».
03 Скриншот показывает окошко, карта — всю страницу 3:31
Скриншот дешевле по токенам, но это лишь видимый фрагмент. Сжатая markdown-карта примерно за те же деньги даёт агенту всю страницу целиком — и он наконец может планировать, а не тыкаться вслепую.
04 Агенту нужна память об изменениях, а не только текущий кадр 3:50
Ключевая часть — дельта между шагами: что появилось, что исчезло, что раньше блокировало клик, какой клик не прошёл. Без этой обратной связи агент застревает в цикле «скриншот — скролл — скриншот».
05 Дешёвая модель в хорошей среде бьёт дорогую в плохой 1:42
Это переворачивает экономику агентов: вместо того чтобы платить за самую мощную модель, дешевле построить правильное окружение и запускать на бюджетной модели быстрее и надёжнее.
Ключевые цитаты
Сильные фразы из видео — нажми тайм-код, чтобы услышать в оригинале
«Модели довольно умные — плохая инфраструктура вокруг них.»
«Агент потратил секунд десять-двадцать просто на то, чтобы нажать кнопку «старт». И вот мы на шаге один. А всего их тридцать.»
«Моя ключевая идея — дать агенту хорошую среду: где он может планировать длинные последовательности, понимать, где ошибся, и кликать правильно.»
«Полный DOM тут вышел бы примерно на 20 000 токенов. Скриншот — около 1 100 токенов. Моя markdown-карта — около 1 800, и в ней видно всю страницу, а не один фрагмент.»
«Мы говорим агенту: вот что нового появилось на странице, а вот это исчезло; то, что мешало нажать, теперь убрано.»
«Итог: я хочу сделать браузерных агентов быстрее, дешевле и надёжнее, чтобы ими пользовались все.»
«Мой код не особо защищаем.»
«Дай мне URL, дай мне намерение — и я выполню это за тебя и верну результат.»
Полезные советы
Что можно применить уже сегодня. Разверни совет — сколько займёт, что даст и что конкретно делать
1 Дай агенту всю страницу, а не окошко скриншота
полдня агент перестанет тыкаться вслепую и начнёт планировать действия
Дай агенту всю страницу, а не окошко скриншота
Скриншот показывает только видимый вьюпорт — агент не знает, что ниже или в свёрнутом меню. Собери компактное представление всей страницы, чтобы модель видела структуру целиком.
Что делать
- 1 Определи, что реально нужно агенту: интерактивные элементы, ссылки, поля, их состояние.
- 2 Собери из них плоский текстовый список по всей странице, а не только по видимой части.
- 3 Подавай эту карту вместе со скриншотом, а не вместо него.
2 Замени сырой DOM сжатым представлением
1–2 дня экономия токенов в разы и меньше шума для модели
Замени сырой DOM сжатым представлением
Полный DOM легко раздувается до десятков тысяч токенов и топит модель в деталях. Оставь только то, с чем агент может взаимодействовать, в человекочитаемой разметке.
Что делать
- 1 Замерь размер полного DOM своей целевой страницы в токенах.
- 2 Выкинь невзаимодействуемую разметку, стили и служебные узлы.
- 3 Сравни успех и стоимость на сжатой карте против полного DOM.
3 Добавь дельту изменений между шагами
день агент перестанет зацикливаться на «скриншот — скролл — скриншот»
Добавь дельту изменений между шагами
После каждого действия сообщай агенту, что на странице появилось, что исчезло и что разблокировалось. Это его обратная связь о том, сработало ли действие.
Что делать
- 1 Снимай состояние страницы до и после каждого действия.
- 2 Считай разницу: новые элементы, удалённые, ставшие кликабельными.
- 3 Передавай эту дельту в следующий промпт агента.
4 Логируй неудавшиеся клики и возвращай их агенту
2–3 часа агент поймёт, что попытка провалилась, и сменит тактику
Логируй неудавшиеся клики и возвращай их агенту
Если агент попытался кликнуть, но ничего не произошло, он должен это знать. Явное «твой клик не сработал» спасает от бесконечного повтора одного и того же.
5 Тестируй на длинных последовательностях, а не на одном клике
вечер увидишь реальную надёжность агента, а не удачу на простом кейсе
Тестируй на длинных последовательностях, а не на одном клике
Настоящие задачи — это десятки шагов подряд. Прогоняй агента на многошаговом бенчмарке (как browser challenge), где ошибка на шаге 5 рушит всё.
6 Начни с дешёвой модели и хорошей среды
полдня ниже счёт за API при той же или большей надёжности
Начни с дешёвой модели и хорошей среды
Прежде чем платить за самую мощную модель, вложись в представление страницы и обратную связь. Часто именно это, а не модель, определяет успех.
Что делать
- 1 Зафиксируй задачу и метрику успеха.
- 2 Запусти на дорогой модели с сырым контекстом — это baseline.
- 3 Запусти на дешёвой модели со сжатой картой и дельтой; сравни успех и цену.
7 Считай стоимость агента в токенах, а не только в «уме» модели
1 час поймёшь, где реально утекают деньги и скорость
Считай стоимость агента в токенах, а не только в «уме» модели
Разложи бюджет одного шага агента: сколько токенов уходит на контекст страницы, сколько на историю. Часто дешевле сжать вход, чем менять модель.
Сценарии применения
Как разные люди применяют это на практике
Я как Разработчик ИИ-агента
Проблема: агент застревает на многошаговых задачах и жжёт токены на бесконечные скриншоты
Хочу: понять, куда вложиться, чтобы агент стал надёжнее
Поможет: статья показывает: строй представление страницы и дельту изменений, а не гонись за более дорогой моделью
Я как Инженер QA-автоматизации
Проблема: тесты на хрупких селекторах ломаются при малейшем изменении вёрстки
Хочу: более устойчивый способ вести бота по интерфейсу
Поможет: видит идею подачи всей страницы как семантической карты вместо привязки к конкретным узлам
Я как Основатель стартапа
Проблема: хочу сделать продукт на браузерных агентах, но боюсь, что фича легко копируется
Хочу: оценить, где здесь защищаемая ценность
Поможет: автор прямо говорит, что код не защищаем — значит, ставку делать на дистрибуцию, данные и надёжность, а не на алгоритм
Я как Продакт-менеджер
Проблема: команда обещает, что «всё починит новая модель», но агент по-прежнему падает
Хочу: аргументы, чтобы правильно расставить приоритеты в роадмапе
Поможет: получает тезис, что надёжность чаще упирается в инфраструктуру контекста, а не в модель
Я как Фронтенд-разработчик
Проблема: не понимаю, почему ИИ-агенты плохо ходят по моему сайту
Хочу: сделать интерфейс дружелюбным к агентам
Поможет: осознаёт, что семантика и доступность — это вход для агента, и чистая структура страницы облегчает ему навигацию
Я как Аналитик, автоматизирующий рутину
Проблема: каждый день вручную скачиваю документы и заполняю формы на десятке сайтов
Хочу: делегировать это агенту, дав ему URL и намерение
Поможет: видит, какой продукт-API автор задумал под ровно этот сценарий и по каким критериям судить о его готовности
Логика повествования
Как устроена аргументация видео — пройди по шагам
-
Предпосылка Браузерные агенты крутые, но их не используют 0:00
Идея мощная, но реального внедрения нет, и сам автор ими почти не пользуется.
-
Пример Бенчмарк вскрывает провал 0:17
На browser challenge из 30 шагов агент тратит 10–20 секунд только на нажатие «старт».
-
Аргумент Значит, дело не в модели 0:51
Тот же сайт агент автора на дешёвой модели проходит заметно быстрее — модели умные, плохая среда вокруг них.
-
Аргумент Агенту нужна хорошая среда 1:09
Среда, где он видит всю страницу за мало токенов, планирует длинные последовательности и понимает свои ошибки.
-
Пример Сжатая карта дешевле и полнее 3:31
DOM 20k токенов и скриншот-окошко проигрывают markdown-карте на 1 800 токенов, показывающей всю страницу.
-
Аргумент Плюс обратная связь об изменениях 3:50
Дельта между шагами (что появилось/исчезло/разблокировалось, что клик не сработал) закрывает цикл восприятия.
-
Вывод Быстрее, дешевле, надёжнее — и в продукт 3:14
Итог: открыть код и продавать как API «URL + намерение → результат», чтобы агентами пользовались все.
Подробный разбор
Полный разбор — разверни, если нужно глубже
Развернуть подробный разбор Свернуть подробный разбор
Стоит ли смотреть целиком
Стоит, если ты строишь агентов любого рода — не обязательно браузерных. Это короткое (4,5 минуты) лайв-выступление с демо, а не глубокий технический разбор: не жди метрик успешности, деталей формата карты или кода. Ценность в одной сильной перерамке проблемы и в наглядных сравнениях «до/после».
Главная мысль переносится далеко за пределы браузеров: прежде чем требовать модель поумнее, посмотри, что именно ты ей показываешь. Полный DOM топит модель шумом, скриншот показывает лишь окошко, а сжатая карта всей страницы плюс обратная связь об изменениях превращают тыканье вслепую в осмысленное планирование — и позволяют перейти на дешёвую и быструю модель.
Чего в докладе нет
Автор честно оговаривает слабое место своего проекта: код «не особо защищаем». Поэтому за красивой идеей стоит открытый вопрос бизнеса — если сжатие страницы легко повторить, чем ты удержишь пользователей. В самом выступлении нет ни доли успешных прохождений на выборке задач, ни того, как представление ведёт себя на тяжёлых одностраничных приложениях и бесконечных лентах. Это стоит держать в голове: доклад задаёт верное направление, но проверять его придётся на своих задачах.
План внедрения
С чего начать — отмечай шаги, прогресс сохранится
Выполнено 0 из 5
Проверь себя
Ответь на вопросы, чтобы материал закрепился
-
1. В чём, по мнению автора, главная причина, что браузерные агенты медленные и ненадёжные?
-
2. Почему полный DOM (~20 000 токенов) — плохой способ показать страницу агенту?
-
3. Чем сжатая markdown-карта лучше скриншота при примерно сопоставимой цене в токенах?
-
4. Какую обратную связь автор считает важным давать агенту между шагами?
-
5. Почему автор готов открыть проект в open source?
-
6. Какой практический вывод для экономики агентов следует из демонстраций?
Словарь терминов
Понять незнакомое простым языком
Показать 5 терминов Свернуть словарь
- Браузерный агент
- ИИ, который сам управляет браузером вместо человека: кликает, вводит текст, листает страницы, чтобы выполнить задачу вроде заказа билета или скачивания документа.
- DOM
- Полная внутренняя структура веб-страницы — дерево всех её элементов. Для человека невидимо, но именно это «читает» браузер; для большой страницы легко разрастается до десятков тысяч токенов.
- Токен
- Кусочек текста (примерно слово или его часть), которым языковая модель измеряет вход и выход. Чем больше токенов подаёшь, тем дороже и медленнее запрос.
- Вьюпорт
- Видимая на экране часть страницы прямо сейчас. Скриншот показывает только вьюпорт, а не всю страницу целиком.
- Представление страницы
- То, в каком виде агент «видит» сайт: сырой DOM, скриншот или, как у автора, сжатая текстовая карта интерактивных элементов всей страницы.
Критический взгляд
Объективно: с какими тезисами можно поспорить и что преувеличено
Заголовок «не нужны модели получше» преувеличен
Хорошая среда снимает часть провалов, но на действительно сложных reasoning-задачах и неоднозначных интерфейсах ум модели по-прежнему решает. Правильнее: сейчас узкое место чаще в среде, но это не значит, что модель не важна.
Демонстрации — отобранные кейсы без воспроизводимого бенчмарка
Сравнения «Claude застрял / мой агент — раз и готово» эффектны, но это единичные примеры. Нет доли успеха на выборке задач, дисперсии, честного прогона обеих систем на одной модели.
Сжатая карта теряет визуальную информацию
Markdown-представление отлично для форм и ссылок, но плохо описывает canvas, кастомные виджеты, графики и раскладку, где важно именно «как выглядит». Для части задач скриншот незаменим, и автор это признаёт, оставляя его в связке.
Цифра «~1 800 токенов» — это одна страница
На тяжёлых SPA и бесконечных лентах компактное представление может раздуваться, а поддержание дельты состояния между шагами добавляет собственную инженерную сложность, о которой в 4 минутах не сказано.
Взгляни иначе
Новый угол, смежные области и потенциал на стыке — пища для размышлений
Это тот же принцип, что и в RAG
Не пихать всё в контекст, а подавать сжатую релевантную выжимку — ровно то, что делает поиск по документам. Браузерный агент — это RAG, где «документ» это живая страница, а retrieval это построение её карты.
Зрение агента — это доступность для незрячих
Агенту нужно ровно то же, что и скринридеру: семантическая структура страницы вместо пикселей. Сайты, сделанные доступными для людей с нарушением зрения, автоматически становятся дружелюбными к ИИ-агентам.
Дельта изменений — это сигнал среды из обучения с подкреплением
Сообщать агенту, что поменялось и сработало ли действие, — это по сути наблюдаемость среды и обратная связь как в RL. Браузер превращается в среду с явными наблюдениями, а не в чёрный ящик.
Может, чинить надо не агента, а браузер
Если агентам нужен семантический слой поверх страницы, логичный финал — браузеры и сайты, отдающие агент-френдли представление сами. Тогда каждому агенту не придётся заново расшифровывать DOM.
Незащищаемый код — не приговор, а смена поля
Раз алгоритм легко повторить, ценность уходит в дистрибуцию, данные о реальных сайтах и надёжность на длинном хвосте интерфейсов. Побеждает не тот, кто придумал сжатие, а тот, у кого больше пройденных сценариев.
Похожие разборы
Почему нейросети любят Markdown: как хранить документы, чтобы ИИ их понимал
Нейросеть никогда не видит ваш файл так, как вы: она читает голый текст со всей технической обёрткой, а каждый лишний символ съедает токены и место в разговоре. Markdown убирает обёртку и оказывается для ИИ родным языком, поэтому документы, заметки и даже схемы удобнее держать именно в нём.
Читать → РазборАгент со 100 инструментами — это ловушка: почему точность падает и как её вернуть роутингом
Если сваливать в промпт все определения инструментов сразу, агент тонет в контексте: на 741 инструменте точность выбора падает до 13,6%, а промпт раздувается до 127 000 токенов ещё до вопроса пользователя. Лечится это семантическим роутингом — ретривом 3–5 релевантных инструментов под конкретный запрос, который держит точность выше 83% и режет токены на инструменты почти на 99%.
Читать → РазборDomain-specific агенты: почему будущее за роем узких ИИ, а не за одним всемогущим
Компании пытаются интегрировать ИИ, навешивая на один большой агент всё больше MCP и skills — и упираются в раздувание контекста и хрупкость. Автор доказывает, что будущее за композицией: рой узких доменных агентов, каждый со своей моделью, инструментами и памятью, координируемых на обычном языке — это дешевле, безопаснее и масштабируется.
Читать → РазборМодель предлагает — платформа решает: инфраструктура надёжности для автономных ИИ-агентов
При переходе от чатботов к автономным агентам узкое место смещается с интеллекта модели на надёжность инфраструктуры вокруг неё. Модель должна лишь предлагать действия, а проверять, одобрять и исполнять их обязана детерминированная платформа — и именно она, а не лучший промпт, становится конкурентным преимуществом.
Читать →