Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Веб-агента научили искать сведения, управлять страницами и возвращаться к найденным данным через один интерфейс. Хотя препринт не рецензирован и числа получили сами авторы, Web$hell показал лучший результат на всех шести тестах при сопоставимых или меньших затратах. Для команд это повод проектировать общий слой веб-доступа до того, как они начнут добавлять агенту отдельные поисковые, браузерные и файловые инструменты.
Раздельные инструменты заставляют агента читать одну страницу несколько раз
Поисковые агенты обычно получают очищенный текст. Такой формат удобно просматривать по ключевым словам, но при очистке исчезают кнопки, поля ввода и связи между элементами. Браузерные агенты видят структуру страницы и могут действовать, однако длинное представление страницы засоряет контекст, когда нужно собрать сведения из множества источников.
Файловый подход сохраняет страницы и позволяет искать по ним командами вроде grep. Он сокращает объём чтения, но найденный фрагмент часто не объясняет, как взаимодействовать с элементом рядом. Агент может увидеть название фильтра и не получить ссылку на управляющую им кнопку.
Команда Yonsei University сначала объединила поиск и браузер без нового интерфейса. На WideSearch такой гибрид расходовал в среднем 182,2 тысячи входных токенов за вызов против 46,7 тысячи у поисковых агентов. На WebArena-Verified разрыв составил 74,2 тысячи против 10,2 тысячи: агент повторно открывал одну страницу в очищенном виде и как браузерное представление, чтобы найти пропущенные сведения или проверить полноту данных.
Добавление файлового хранилища снизило затраты на поисковых задачах, но ухудшило навигацию. Выборочное чтение показывало нужный текст без контекста, необходимого для работы с элементами страницы. Значит, проблема заключалась не только в наборе инструментов, но и в том, как агенту представляли содержимое и действия.
Web$hell связывает сведения, действия и сохранённые страницы
Web$hell помещает между моделью и сайтом единый слой. WebCompiler преобразует живую страницу по правилам, основанным на семантике HTML. Он не отдаёт агенту весь исходный документ, а собирает адресуемые информационные объекты и объекты действий.
У каждого объекта есть адрес, значение и связи с другими объектами. Цена товара может ссылаться на название и вариант комплектации, а текст о статусе — на действие, которое открывает окно его изменения. Агенту не нужно заново восстанавливать эти отношения по соседним узлам страницы.
WebContract задаёт одинаковую структуру для разных сайтов и общий набор операций: найти страницы, прочитать объект, выполнить поиск по сохранённым данным или запустить действие. Адрес позволяет в следующем запросе сослаться на конкретный фрагмент или кнопку, не передавая страницу целиком.
WebCache сохраняет скомпилированные состояния страниц на протяжении задачи. После действия интерфейс обновляет текущее состояние, оставляет прежнее доступным только для чтения и сообщает, что изменилось. Поэтому агент может проверить результат клика, вернуться к ранее найденному доказательству и продолжить сравнение без повторной загрузки всего контента.
Связи между объектами помогают и там, где обычный поиск по тексту ничего не нашёл. В эксперименте с данными футбольных лиг очищенная страница содержала название турнира, но пропускала результаты сезонов. Web$hell сохранил ссылку на связанный раздел и дал агенту направление для следующего чтения.
Планы меняет слой доступа, а не выбор LLM
Работу проверяли на тестах веб-поиска, навигации и глубокого исследования. В набор вошли WideSearch, SealQA, WebArena-Verified и DeepWeb-Bench, а сравнение охватило поисковые, браузерные, файловые и гибридные системы. Предварительные опыты с разными способами доступа проводили на GPT-5.6-Luna, поэтому результат показывает влияние интерфейса при общей базовой модели.
Самый заметный выигрыш возник в длинных исследовательских задачах. На них CLI-Anything Browser требовалось в среднем 52,4 шага, а Web$hell — 17,6. Система также сохраняла близкие затраты после добавления в хранилище нерелевантных страниц: короткие адреса позволяли обращаться к нужным объектам без просмотра всего архива.
Для нового веб-агента разумная архитектура теперь выглядит не как набор независимых адаптеров. Нужен общий контракт, который одинаково описывает текст, таблицы, ссылки и элементы управления; стабильные адреса для повторных обращений; сохранение состояний; явный отчёт о результате действия. Поиск и браузер при этом остаются внутренними возможностями интерфейса, а не двумя несовместимыми представлениями для модели.
Для существующей системы работа предлагает конкретную проверку: посчитать, сколько раз агент получает одну страницу в разных форматах и сколько контекста уходит на восстановление связей между текстом и элементами управления. Если эти повторы составляют заметную часть затрат, единое представление может сократить их без замены LLM. Перенос результата в продукт всё равно требует испытаний на собственных сайтах и сценариях: в работе оценивали тестовые задачи, а не производственные процессы с авторизацией, нестабильной разметкой и внутренними политиками доступа.
Источники
Иллюстрация: рисунок из статьи «Web$hell: A Unified Interface for Agentic Web Access», Sunghwan Kim, Deogyong Kim, Sangam Lee и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
