Показать HN: Magnitude – Open-source AI браузерный фреймворк автоматизации ( github.com/magnitudedev ) Привет, HN, Андерс и Том здесь. У нас был пост о нашем фреймворке автоматизации тестирования AI 2 месяца назад, который получил приличное количество откликов ( https://news.ycombinator.com/item?id=43796003 ).
Мы получили несколько замечательных отзывов от сообщества, причем наиболее позитивный отклик был о нашем подходе Vision-first, используемом в нашем браузерном агенте. Однако многие хотели использовать базовый агент за пределами области тестирования. Поэтому сегодня мы выпускаем нашу полнофункциональную инфраструктуру автоматизации браузера AI.
Вы можете использовать его для автоматизации задач в Интернете, интеграции между приложениями без API, извлечения данных, тестирования ваших веб-приложений или в качестве строительного блока для ваших собственных агентов браузера.
Традиционно автоматизация браузера могла быть реализована только через DOM, хотя люди не используют браузеры таким образом. Большинство агентов браузера все еще застряли в этой парадигме. Благодаря подходу Vision-first мы избегаем использования нестабильной навигации DOM и лучше справляемся со сложными взаимодействиями, которые встречаются на самых разных сайтах, например:
– Взаимодействие методом перетаскивания
– Визуализации данных, диаграммы и таблицы
– Устаревшие приложения с вложенными фреймами
– Сайты с большим объемом информации на основе Canvas и WebGL (например, инструменты для дизайна или редактирования фотографий)
– Удаленные рабочие столы транслируются в браузер
Для точного взаимодействия с браузером мы используем визуально обоснованные модели для выполнения точных действий на основе пиксельных координат. Модель, используемая Magnitude, должна быть достаточно умной, чтобы планировать действия, но также иметь возможность их выполнять. Немногие модели одновременно умны *и* визуально обоснованы. Мы настоятельно рекомендуем Claude Sonnet 4 для лучшей производительности, но если вы предпочитаете открытый исходный код, мы также поддерживаем Qwen-2.5-VL 72B.
Большинство агентов браузера никогда не попадают в производство. Это происходит из-за (1) нестабильной навигации DOM, упомянутой выше, но (2) отсутствия контроля, который предлагают большинство агентов браузера. Доминирующая парадигма заключается в том, что вы даете агенту высокоуровневую задачу + инструменты и надеетесь на лучшее. Это быстро разваливается для автоматизации производства, которая должна быть надежной и конкретной. С Magnitude у вас есть детальный контроль над агентом с помощью нашего синтаксиса `act()` и `extract()`, и вы можете смешивать его с вашим собственным кодом по мере необходимости. У вас также есть полный контроль над подсказками как на уровне действий, так и на уровне агентов.
“`ts
// Magnitude может выполнять высокоуровневые задачи
await agent.act('Создать задачу', {
// При необходимости передайте данные, которые агент будет использовать при необходимости data: { title: 'Использовать Magnitude', description: 'Запустите “npx create-magnitude-app” и следуйте инструкциям', }, });
// Он также может обрабатывать низкоуровневые действия
await agent.act('Перетащите “Использовать величину” в верхнюю часть столбца выполнения');
// Интеллектуальное извлечение данных на основе содержимого DOM, соответствующего предоставленной схеме zod
константные задачи = ожидание агента.извлечение(
'Список текущих проблем', z.array(z.object({ title: z.string(), description: z.string(), // Агент может извлекать существующие данные или новые идеи difficulty: z.number().describe('Оцените сложность от 1 до 5') })), );
“`
У нас есть скрипт настройки, который делает запуск примера тривиальным, просто запустите “npx create-magnitude-app”. Мы будем рады услышать, что вы думаете!
Репозиторий: https://github.com/magnitudedev/magnitude
Существует множество таких программ, и эта имеет суперлегкую настройку и, кажется, просто работает, так что это отличная работа. Я запустил ее и она выдала правдоподобные результаты примерно через минуту.
Мне интересно, делает ли кто-нибудь это в масштабе? Проблема, которую я вижу, заключается в том, что в сложных рабочих процессах, которые занимают несколько десятков шагов и имеют сложный поток управления, вероятность достижения конца падает довольно сильно, потому что если каждый шаг имеет 0,95 шанса на успешное завершение, после не очень большого количества шагов у вас довольно маленькая общая вероятность успеха. Эти варианты использования имеют высокую ценность, потому что написание традиционного скрапера — это огромная боль, но мы, похоже, просто еще не достигли этого.
Другая сторона медали — простые рабочие процессы, но это, как правило, те рабочие процессы, где написание скрапера довольно тривиально. Это сработало, и я сказал ему искать продукт в местном магазине, но программа стоила 1,05 доллара за запуск. Поэтому делать это в любом масштабе быстро становится немного глупо.
Поэтому, полагаю, мой вопрос таков: кому удается успешно использовать эти инструменты, и для чего вы их используете?
Один из путей, с которым я добился некоторого успеха, — это написание DSL для скрапинга, а затем генерация этого кода llm, его интерпретация и редактирование, когда он зависает. Но есть еще часть «обнаружения зависания», которая сложна и т. д. и т. п.
Рад, что вам удалось быстро всё настроить!
В настоящее время мы оптимизируем надежность и качество, поэтому мы предлагаем Claude – но это может быть дорого в некоторых случаях. Использование Qwen 2.5-VL-72B будет значительно дешевле, хотя не всегда надежно.
В настоящее время мы в основном используем qwen для запуска тестовых случаев, и люди, похоже, часто предпочитают использовать его именно в этом случае, поскольку обычно в тестовых случаях более понятно, как их выполнять.
Самое главное — найти хороший способ «кэшировать» рабочие процессы, которые будут выполнены. Таким образом, вы сможете повторять автоматизацию либо без LLM, либо с меньшим/дешевым LLM. Это позволит реализовать детерминированные, повторяемые потоки, которые также очень доступны и быстры. Так что даже если каждый шаг в первом запуске надежен только на 95% — если он пройдет его, он сможет повторить его со 100% надежностью.
Использование этого для тестирования вместо обычного драматурга должно в 10000 раз увеличить стоимость и скорость, не так ли? В какие моменты преимущества перевешивают затраты?
Я думаю, во многом это зависит от того, насколько вы цените свое время, поскольку писать и обновлять сценарии драматурга довольно долго. Это сэкономит вам часы разработчика, чтобы писать автоматизацию на естественном языке, а не возиться с селекторами и исправлять их. Он также способен справляться с задачами, которые драматург вообще не смог бы выполнить — например, извлекать структурированные данные из запутанного/неоднозначного DOM и автоматически адаптироваться к изменяющимся ситуациям.
Вы также можете использовать более дешевые модели в зависимости от ваших потребностей, например, Qwen 2.5 VL 72B довольно доступен по цене и хорошо подходит для большинства ситуаций.
Почему бы просто не использовать Claude отдельно? Opus и Sonnet отлично справляются с получением пиксельных координат и использования инструментов из скриншотов UI. Интересно, что ваш фреймворк дает мне по сравнению с простой базовой моделью.
Эй! Чтобы иметь фреймворк, который может эффективно контролировать агентов браузера, вам нужны системы для взаимодействия с браузером, но также для передачи соответствующего контента со страницы в LLM. Наш фреймворк управляет этим циклом агента таким образом, что обеспечивает гибкое агентское выполнение, которое может смешиваться с вашим собственным кодом, предоставляя вам контроль, но удобным способом. API/циклы использования компьютеров Claude и OpenAI медленнее, дороже и предназначены для ограниченного набора вариантов использования автоматизации рабочего стола, а не для надежной автоматизации браузера.
Наконец-то браузерный агент, который не паникует при виде холста
Точно 🙂
Не уверен, так как вы автор.
Попробуйте и сообщите результат!
Нет
Классическая враждебность новостей хакеров нового века. Думаете, этот ответ что-то добавляет?
Source: news.ycombinator.com