Сегодня у меня на тесте Kimi WebBridge — свежий релиз от Moonshot AI для автоматизации браузера, который обещает решить главную боль всех AI-агентов: экраны авторизации и антибот-защиту. В отличие от привычных headless-решений, инструмент работает как браузерное расширение плюс локальный daemon, управляя вашим реальным браузером по Chrome DevTools Protocol. Его главная заявленная фишка — local-first: ИИ-агент получает бесшовный доступ к уже залогиненным сессиям от корпоративных админок до соцсетей, при этом данные не уходят никуда в облако, а вся работа крутится прямо на вашей машине.
Звучит как идеальный способ поручить нейросети всю веб-рутину. Я решила проверить, насколько WebBridge улучшит мою жизнь в связке с Claude Code, и заодно сравнить его с привычными BrowserMCP и Playwright. Для этого я протестировала его на четырёх моих регулярных задачах: от ресёрча закрытых платформ и визуального анализа B2B-сервисов до автономного smoke-тестирования интерфейсов и пайплайна по генерации подкастов. Спойлер: пара старых подходов сломалась окончательно, но зато мы впервые получили реально работающий мост между агентом и приватным вебом. Проверим, как это работает на практике!
Сценарий 1. Исследование нового продукта
Моя обычная схема исследования новых сервисов выглядит так: собираю саммари обзоров через Claude Code, а потом иду за живыми реакциями пользователей на Reddit и X.com. Но сейчас этот флоу сломан. Встроенные в Claude Code инструменты WebFetch и WebSearch всё чаще упираются в антибот-детект, а X.com вообще не отдаёт контент без логина.
Поэтому первый тест Kimi WebBridge я решила сделать на нём самом и попросила Claude Code: «Исследуй Kimi WebBridge как продукт». План был такой: собрать новости через WebSearch, а затем пойти в соцсети. Для X.com и Reddit я параллельно запустила BrowserMCP и Kimi WebBridge, чтобы сравнить два подхода к управлению моим браузером.
Что в итоге произошло
WebSearch и WebFetch отработали ожидаемо: быстро нашли обзоры, но AI-агент сразу сделал вывод, что статьи чисто маркетинговые. А вот до Reddit встроенный WebFetch не добрался вообще — наткнулся на policy-блок. Путь к постам остался только через полноценный браузер.
И вот тут началось самое интересное. BrowserMCP отказался работать автономно: чтобы агент увидел вкладку, нужно руками жать «Connect» на каждой странице. Для автономного research-агента это попросту нерабочий путь, я считаю такое решение неполноценным.
Kimi WebBridge на той же задаче отработал за одну команду. Браузер открылся, агент зашёл на Reddit, прочитал треды, а потом открыл X.com и подхватил мою залогиненную сессию без всякого login-flow. Он увидел мой фид и подписки — это тот самый ключевой local-first эффект, ради которого инструмент создавался.
Кстати, на Reddit нашёлся отличный комментарий: WebBridge даёт классную privacy-историю, но для серьёзного использования нужны per-domain allowlists, видимый action-log и hard-confirm на необратимые действия. Полностью согласна: категорически не хочется, чтобы слишком проактивный AI-агент случайно оформил мне платную подписку.
Краткие итоги сценария:
- WebFetch и WebSearch работают только для публичной статики и далеко не везде.
- BrowserMCP подходит для интерактивной работы human-in-the-loop, но ломает автономность из-за ручных кликов.
- Kimi WebBridge впервые закрыл обе мои боли: он заходит в сервисы с моей сессией и не требует ручного подтверждения на каждой вкладке. В моём кейсе он оказался первым инструментом, который дал агенту реально автономный доступ.
Как выглядит в браузере
Сценарий 2. Визуальный обзор B2B-сервисов
Второй сценарий сугубо практический: мне нужен мини-обзор визуальной части четырёх-пяти B2B-продуктов. Сама идея звучит достаточно просто: даю агенту задачу найти сервисы, он проходит по каждому, делает 2–3 скриншота именно внутренних интерфейсов и собирает сводный документ.
Здесь я решила по-честному сравнить три инструмента без поправок на авторизацию (всё публичное): Kimi WebBridge, Playwright и BrowserMCP.
Тест 1. Kimi WebBridge и обход cookie-баннеров
Claude Code составил список из пяти продуктов и запустил WebBridge. Скорость впечатляющая: 15 страниц по три скриншота на каждый сервис за 5 минут, всё пишется прямо на диск. Но по ходу этой возни сразу вылезли проблемы:
- Cookie-плашки. Они перекрывали половину экрана. Решилось одним промптом: попросила агента сначала кликать «Reject». Он написал короткий JavaScript и прогонял его перед каждым скрином.
- Снимал не то. Агент скриншотил главные landing-страницы и прайсинги вместо самого продукта. Моя недоработка в промпте — переписала задачу точнее.
- Заглушки 404. Агент просто угадывал URL-ы типичными паттернами (
/dashboard,/app) и скринил страницы с ошибками. Пришлось попросить его проверять реальный код ответа сервера. Тогда он пошёл через WebSearch искать настоящие ссылки и сделал чистовой проход.
Пример скриншота с красивой, но несуществующей и бесполезной страницей
Тест 2 и 3. Провал BrowserMCP и ограничения Playwright
BrowserMCP я снова пропустила: 15 страниц означали бы 15 ручных кликов «Connect». Идею автономности это убивает.
Запуск через Playwright сразу подсветил архитектурные отличия. Он открыл чистый пустой Chrome без моей сессии. Качество и скорость сопоставимы с WebBridge, но есть серьёзное неудобство: Playwright открывал каждый следующий сайт в той же вкладке, перезаписывая контент. В WebBridge у меня оставалось 30 открытых вкладок, по которым я могла пройтись глазами. У Playwright после прогона не осталось ничего — чтобы понять, где был агент, пришлось бы лезть в историю логов.
Kimi WebBridge оставил множество вкладок, удобно смотреть историю
Подключаем Comet с ИИ-зрением
Пришло неудобное понимание: делать скриншоты вслепую бессмысленно. Ни WebBridge, ни Playwright не понимают, что именно изображено на PNG — живой интерфейс или пустая посадочная страница.
Я решила взять тяжёлую артиллерию — браузер Comet, который «видит» страницу целиком. Он действительно осмысленно смотрел на контент и отличал обложку от UI, но упёрся в собственные ограничения: у него нет доступа к моей файловой системе. Сохранить картинки наружу или собрать Google-документ он не смог.
Comet отлично понимает содержимое экрана, но не умеет писать на диск
Краткие итоги сценария
Если говорить про саму задачу — «собрать визуальный обзор B2B-продуктов автономно» — она пока за гранью того, что современные агенты-браузеры могут сделать без участия человека. И это не потому, что инструменты плохие, а потому, что у большинства таких сервисов попросту нет публичных UI и нужны живые демо-доступы, а также потому, что скриншот без понимания контента — это мусор.
С этим тестом идеально не справился никто, но моё впечатление от Kimi WebBridge укрепилось. Скорость работы, скриншоты на диск и сохранённые вкладки для ручного ревью дают ему реальные преимущества в моём флоу.
Да, идеального обзора у меня нет, но я при этом не потратила полтора часа на клики по 15 сайтам — я редактировала статью, пока агент бегал по интернету. Следующим шагом я оформлю триал-доступы и попрошу агента походить внутри — вот тут WebBridge со своей залогиненной сессией окажется в своей естественной нише.
Сценарий 3. Тестирование веб-интерфейсов и автоматизация smoke-тестов
Это самый болезненный из моих регулярных сценариев. Я часто собираю экспериментальные продукты и много вайб-кодю с Claude Code. Самая унылая рутина в этом процессе — вручную прокликивать smoke-тесты после каждой итерации. Проверки по API тут не спасают: у тебя может просто молча перестать нажиматься важная кнопка.
В идеальном мире мой пайплайн должен работать так: мы с ИИ-агентом пишем код, он сам прогоняет тесты, находит баги, чинит их и присылает уведомление в Telegram, чтобы я принимала уже полностью готовый результат.
Вайб-кодим тестовый интерфейс
Для проверки я попросила Claude Code за минуту набросать простую интерактивную Kanban-доску. Только HTML и JavaScript: без бэкенда, без авторизации, без сложной инфраструктуры. Ровно для того, чтобы сфокусироваться на том, как агент кликает по элементам.
Интерфейс, который навайбкодили с Claude Code
Автоматизация smoke-тестов
Claude Code сам составил план тест-кейсов и запустил прогон через WebBridge. Быстро отчитался, что всё отлично работает, и я уже почти завершила эксперимент. Но потом решила покликать руками: открыла задачу, нажала первую же кнопку Cancel в popup-окне — и она не сработала. Очевидный баг, который ИИ-агент пропустил при самотестировании.
Я вернулась к нему с прямой претензией: качество низкое, собери полный список всех кнопок и проверь системно каждую. Агент признал, что поленился. На второй итерации он прошёлся по всему интерфейсу, нашёл ещё один баг и сам его починил. После этого всё действительно заработало как нужно.
Даю задачу на тестирование
Отписался, что он красавчик
Что я из этого вынесла
Впечатление от работы Kimi WebBridge на этой задаче осталось положительным, хоть и с оговорками на лень ИИ-модели. Если сравнивать с Playwright, всё, что касается обычных кликов по кнопкам и проверки реакций UI, у обоих инструментов работает сопоставимо.
Но у WebBridge есть одно критически важное для меня преимущество — возможность автономно тестировать сервисы, которые находятся за экраном авторизации. И это решает очень многое.
Сценарий 4. Автоматизация пайплайна
Это самый личный сценарий, который закрывает мою давнюю боль. У меня постоянно копятся длинные отраслевые исследования в PDF. Читать 40 страниц некогда, а рынок меняется быстро. Идеальное решение — NotebookLM от Google: загружаешь документ, жмёшь кнопку и получаешь аудиоподкаст, который можно слушать на пробежке.
Но руками я это делаю редко: нужно открыть сервис, снять галочки с полсотни старых источников, загрузить файл, дождаться обработки, скачать. Слишком много рутины. Поэтому я захотела собрать автономный процесс на домашнем Mac Mini: раз в неделю ИИ-агент сам забирает свежие PDF, прогоняет их через NotebookLM и присылает мне аудио в Telegram.
Посмотрим, как тут поможет Kimi WebBridge
Claude Code открыл NotebookLM через WebBridge. Браузер сразу подхватил мою залогиненную Google-сессию без всяких экранов авторизации — ради этого момента всё и затевалось. Агент зашёл в проект, снял галочки со всех 58 источников и открыл окно добавления нового документа. И тут мы столкнулись с проблемой.
NotebookLM открывает системный диалог выбора файла, а у WebBridge нет к нему доступа, потому что это расширение внутри песочницы браузера. Никакие команды до нативных окон операционной системы не дотягиваются.
Сначала агент попытался загрузить файл через Google Drive, но безуспешно. Спустя 40 минут попыток он нашёл изящный хак. NotebookLM умеет принимать сырой текст. Поскольку Claude Code может читать PDF напрямую с локального диска, он сам извлёк всё содержимое документа и просто вставил его в поле браузера. И это сработало!
Генерация и скачивание
Агент запустил генерацию аудио и повесил фоновый процесс мониторить готовность. Пока ИИ работал, я не сидела перед экраном. Ушла на кухню, сделала кофе. Отличное ощущение: пока у меня нет домашнего робота, который сам разгрузит посудомойку, пусть алгоритмы хотя бы нажимают кнопки в браузере.
Когда я вернулась, подкаст был готов. Со скачиванием через всплывающее окно у агента возникла заминка. Я попросила его просто изучить структуру страницы — он нашёл прямую ссылку на mp3, открыл её в новой вкладке и успешно скачал 39 мегабайт напрямую в мою файловую систему.
Бот прислал мне желаемый подкаст
Финал без сюрпризов: через минуту настроенный Telegram-бот прислал мне готовое аудио. Я нажала Play, всё работает.
Что я в итоге об этом думаю
Сценарий прошёл end-to-end, и это случилось впервые за всё время моих экспериментов. Да, обход нативного диалога через вставку текста — это хакерское решение. Но оно работает!
WebBridge дал агенту автономный доступ к NotebookLM под моим аккаунтом, Claude Code прочитал файл, а Telegram-скилл закрыл последнюю милю до моего телефона. Теперь этот флоу точно уйдёт на регулярное расписание.
Общие выводы
Продукт получился на удивление полезным. В связке с Claude Code уровень автономности ИИ-агентов вырастает кратно. Главный минус на текущий момент — полное отсутствие инструментов для установки запретов и лимитов (тех самых allowlists), но, уверена, это исправят в ближайших релизах.
Мой личный итог тестирования: Kimi WebBridge однозначно оставляю в своём арсенале, BrowserMCP удаляю из-за нежизнеспособной архитектуры с ручными кликами, а Playwright MCP пока придержу — для специфических задач он ещё может пригодиться.
