Погнали! Меня зовут Прохор, я лид команды агента «Исследовать» — это режим глубокого исследования в чате с Алисой AI.
Напомню, про что вообще речь, если никогда не пользовались Deep Research: это специальный режим работы, который строит уникальный план решения задачи пользователя, делает сотни поисков по вашему запросу, умеет ходить на сайты (даже с динамическим JavaScript‑контентом), писать и выполнять Python‑код (для сложных расчётов), работать со скачанными файлами и так далее. Всё это для того, чтобы дать лучший ответ на ваши сложные запросы, например: «Спланируй мне путешествие в Дагестан на две недели на машине с детьми».
За год агент прошёл путь от первого прототипа до продакшена — вместе с ним менялись качество ответов, скорость работы и потребление GPU. За продуктовую часть отвечал Руслан Илиев, продакт менеджер агента: он сформулировал продуктовые цели, определил набор инструментов и валидационный набор запросов, а затем вёл запуск от закрытого вейтлиста до 100% продакшена. Как мы к этому пришли — через выброшенный прототип, десятки слоёв обвязки и пару болезненных уроков, — расскажу по порядку. Добро пожаловать под кат!
От поиска в рассуждениях — к полноценному агенту
Агент «Исследовать» появился не сразу: всё началось с попытки научить режим «Рассуждать» работать со свежими данными из интернета. Простой поиск постепенно превратился в полноценный агентный цикл — с инструментами, собственной стратегией и инфраструктурой для длинных запросов. Разберём этот путь по порядку.
Рассуждения + поиск
Всё началось весной 2025-го, после релиза DeepSeek‑R1 и бума ризонинг‑моделей в целом. Тогда я техлидил выкатку режима «Рассуждать» в Алисе AI, и встал вопрос: как в него добавить поисковую выдачу для запросов, требующих свежих данных из сети?
В итоге мы сделали простой RAG‑пайплайн с мультизапросным поиском, где запросы генерировала сама LLM. Несмотря на простоту решения, пользователи полюбили этот режим за качество ответов на сложные вопросы. После первого успеха мы решили пойти дальше.
Агенты! Агенты!
Спустя пару месяцев начался страшный хайп вокруг агентов. Помню, как ходил по стендам на ICLR и все говорили именно про них. Первый успешный опыт у нас уже был, так что настала пора делать полноценный Deep Research — мы назвали его «Режим „Исследовать“».
Момент был суперудачный: в Алисе AI как раз началась большая стройка инфраструктуры под ATS (Agent Transport System) и Agent SDK (Python, Go, C++…). А наш режим — это прямо‑таки классический агент, потому что есть multi‑turn выполнение запросов. Ответ может занимать минуты (первая версия отвечала по 30 минут и дольше).
Если у вас возник вопрос, зачем нужно было строить отдельную инфру под агентов, то тут всё просто. Нам была важна гарантия выполнения длинных запросов с сотней tool‑calls, трассировка, логирование, масштабирование, алерты и вот это всё, к чему мы привыкли для обычных запросов в Алису AI. Подробнее про ATS коллеги уже рассказывали на Хабре.
В команде не хватало людей, а бежать мы хотели, конечно же, быстро. Поэтому договорились, что большие LLM обучать не будем, пока не упрёмся в их качество или перф. Упор делали на разработку обвязок вокруг LLM, context engineering и вспомогательные модели.
Интересно, что основатель Manus чуть позже пришёл ровно к тому же выводу: «Я обучал модели с нуля для извлечения информации и семантического поиска. Потом появились GPT-3 и FLAN‑T5 — и мои модели в одночасье утратили актуальность».
Первый прототип мы собрали на базе подхода CodeAgent: модель вызывает инструменты, генерируя Python‑код. Метрики сразу вышли приличные: FRAMES — 75, SimpleQA — 81, GAIA — 26 (на GAIA низко, потому что с файлами агент тогда работать не умел). Но мы радовались недолго.
Первый большой фейл: выбрасываем прототип целиком
Проблема вылезла, когда мы стали думать, как тащить CodeAgent в прод. Сгенерированный моделью код нужно исполнять в изолированной песочнице. При этом мы очень хотели, чтобы из песочницы был доступ в интернет, например для использования открытых API. Значит, жить ей предстояло за пределами внутреннего контура. А все инструменты агента, наоборот, живут внутри контура. В общем, получается, что нам нужно было бы делать проброс tool‑call из внешней сети во внутреннюю. Не звучит как что‑то безопасное.
И тут нам повезло: в конце июля 2025 года вышла опенсорс‑модель с по‑настоящему хорошим function calling. Две недели — и агент переписан на классический function calling loop. Ещё неделя — и метрики CodeAgent побиты. Инфраструктура упростилась в разы, секьюрити‑аудит перестал быть болью. Первая архитектура отправилась в корзину, и мы ни разу об этом не пожалели.
Харнесс и scaffolding
Про DeepResearch‑агентов сейчас пишут все, и почти все про одно и то же — про харнесс. Наши коллеги из Яндекса уже рассказывали, как собирали DeepResearch‑агента по корпоративным данным и кодовой базе, а недавно коллеги из «Сбера» выпустили подробный разбор своего конвейера.
Мы решали ту же задачу с другого конца. Если коллеги вынесли «агентность» в управляемый конвейер, то мы пошли по пути классического агента с tool‑call: модель сама держит стратегию, а вокруг неё — десятки слоёв обвязки. И каждый слой появился не из любви к красивым архитектурам, а из вполне конкретной боли. Но сначала — о терминах.
A decent model with a great harness beats a great model with a bad harness.
Эдди Османи, Google Cloud AI (Agent Harness Engineering)
Харнесс (обвязка) — это всё, что превращает «голую» LLM в агента: оркестрация, цикл tool‑use, работа с контекстом и памятью, ретраи, верификация, песочница, наблюдаемость.
Рядом живёт слово scaffolding — “строительные леса”: шаблоны промптов, схемы инструментов, заранее прописанные шаги.
Термины часто смешивают. Нам удобно так: scaffolding — заданная структура (дизайн‑тайм), харнесс — исполняющий движок (рантайм).
Насколько это вообще важно? Весьма. Просто посмотрите, как влияет наличие обвязки на одну и ту же модель:
Впечатляет: меняешь только обвязку — и метрика прыгает на десятки пунктов.
Что в итоге получилось: устройство агента
Итак, после переезда на function calling агент начал обрастать обвязкой. В основе — всё тот же классический агентный цикл: модель вызывает инструменты, пока не решит, что исследование закончено. Стратегию держит опять же сама модель: строит план, обновляет его по ходу и решает, куда копать дальше.
Звучит просто, правда? А теперь посмотрите, что наросло вокруг этого цикла за год:
Отдельно отмечу нарезку инфоконтекстов: границы фрагментов выбирает BERT‑модель по смыслу, а не механически — иначе на стыках теряется информация.
Ни один из этих компонентов — не «веса модели». И каждый двигает качество. Причём, как выяснилось, в обе стороны.
Наращиваем обвязку и учимся её срезать
Давайте для наглядности рассмотрим несколько кейсов.
Кейс 1. Один враппер над поиском → +9 п. п. на BrowseComp. Сырой поиск отдаёт десять сниппетов по ~500 токенов. Добрая половина из них — мусор, который перегружает контекст и уводит модель в сторону. Мы поставили между поиском и моделью классификатор релевантности: каждый сниппет получает вердикт «да», «частично» или «нет». В контекст попадают только релевантные.
Кейс 2. Файлы и мультимодальность → +8,5 п. п. на GAIA. Научили агента работать с PDF, CSV, XLSX и картинками: code sandbox — для табличек, VLM — для изображений, RAG — для больших документов. Понятно, для бенча с файлами рост ожидаем, но смысл в том, что обвязка для работы с файлами всё равно нужна и во многом от неё зависит качество работы с ними.
Кейс 3. Инструмент продвинутого рассуждения. Мы сделали отдельную тулу ризонера. Она докидывала нам по бенчам +5 п. п., но с выходом свежих моделей она начала только мешать — мы от неё избавились. Оказалось, это не наша частная боль, а закономерность, у которой уже есть имя:
99% работы делает сама модель. Нам не нужен сложный фреймворк вокруг неё.
Browser Use, The Bitter Lesson of Agent Frameworks
Это отсылка к Bitter Lesson Ричарда Саттона: методы, которые масштабируются с вычислениями, в итоге побеждают ручные надстройки. Каждый компонент обвязки, по сути, заплатка под текущее ограничение модели. С новым релизом это допущение протухает. Поэтому консенсус практиков (Anthropic, Cognition, Browser Use, Ramp) звучит неожиданно: харнесс нужно не только наращивать, но и регулярно срезать, повторно измеряя пользу каждого компонента на каждом релизе модели.
Инфраструктура: агент, который думает десять минут
Наш агент стал первым режимом Алисы AI, который может думать над ответом несколько минут. Иногда и больше десяти. За это время успевает случиться всё: пользователь закрывает вкладку и уходит пить кофе (а результат будет смотреть уже с телефона), рвутся сокеты, выкатываются сервисы, что‑то временно отваливается.
Теперь немного математики. Одно исследование — это сотни вызовов инструментов и сервисов, и каждый из них иногда отказывает. Каждый десятый пользователь ждал бы десять минут и уходил ни с чем. Согласитесь, так себе продукт.
Решение — добавить чекпоинты. Помните гарантию выполнения длинных запросов, ради которой строилась ATS? Вот она в деле! Состояние агента сохраняется после каждого вызова инструмента: если на пятнадцатой минуте исследования под уехал на обслуживание — нестрашно, прогресс не потерян, агент просыпается на другом поде и продолжает с того же места.
Работает ли это? Мы проверяли со всей строгостью: 11 экспериментов на проде с отключением подов. Тем не менее главный экзамен случился сам — и мы успешно его сдали.
Главный экзамен: День Победы
8 мая 2026 года, пятница, 10:00. Мы в нашем московском офисе. На лицах тревога: прод почти лёг, нам срочно нужны дополнительные 50 GPU карт, потому что в агент «Исследовать» пришло уже порядка 100 тысяч человек, а GPU было рассчитано на сильно меньший поток.
К 9 Мая мы запустили акцию: агент «Исследовать» помогает найти в открытых архивах информацию о родственниках, которые участвовали в Великой Отечественной войне. Человек пишет то немногое, что знает: имя, год рождения, обрывок семейной истории. Агент идёт в открытые архивы — ОБД «Мемориал», «Подвиг народа», «Память народа», сопоставляет документы и за несколько минут собирает биографическую справку: боевой путь, награды, место службы. На поиск вручную уходят часы.
Анонс дали заранее, и люди пошли, не дожидаясь самого праздника. Мы ждали наплыва. Но не такого. Сидим в переговорке, GPU взять неоткуда. Спас нас Паша, лид соседней команды: «Мы можем отдать 100 карт из функциональной модели, но на один день». В итоге мы забрали примерно половину — этого хватило, чтобы удержать нагрузку.
Люди находили своих близких. Кажется, это был самый осмысленный день работы агента.
А дальше начался долгий путь улучшений харнесса с целью оптимизации потребления GPU.
Харнесс — это ещё и деньги
Обвязка — это не только качество, но и деньги. Каждый токен в контексте и каждый лишний вызов модели — это GPU‑время, а значит, это влияет на число пользователей, которых мы можем обслужить на имеющемся железе. Вот что мы сделали:
-
обработку поисковых сниппетов отдали обученному классификатору вместо LLM;
-
ходим в инструменты, только когда это реально двигает исследование;
-
генерацию плана перевели на модель полегче без потери качества.
В итоге стоимость запроса сократилась в 6,6 раза за три месяца.
Больше пользователей — быстрее ответы с тем же качеством.
Цифры: бенчмарки
Мы регулярно замеряем агента на публичных бенчмарках. Ниже — замеры на Seal‑HARD (многошаговый фактологический поиск, метрика accuracy) и DeepResearch Bench RACE (LLM‑судья оценивает финальный отчёт по полноте, глубине анализа, следованию инструкции и читаемости) в сравнении с другими решениями.
Вот ещё несколько замеров на популярных бенчмарках:
И отдельно — наш главный внутренний замер, редакторский side‑by‑side против OpenAI Deep Research (осень 2025 года). Публичные бенчи удобны тем, что сравнимы, но на реальные пользовательские запросы похожи слабо, поэтому мы собрали свой набор. Подход к оценке качества на основе рубрик сейчас широко распространён и описан, например, в статье от Shopify.
В парных сравнениях мы стали выигрывать чаще, чем проигрывать.
Ну и завершим общими метриками, которые показывают рост агента за этот год.
Что дальше
Если попробовать сформулировать главный урок этого года, он такой: харнесс решает, но она же быстрее всего протухает.
Модели выходят каждые пару месяцев, и каждый релиз обесценивает часть обвязки (привет, тула ризонера). Повторно измерять и перенастраивать десятки компонентов руками под каждую новую модель — недели работы. Поэтому наш следующий большой шаг — автоадаптация харнесса: новая модель на входе → автоподбор промптов и обвязки → автозамер на бенчах → раскатка. Хотим, чтобы смена модели была не месяцем ручной перенастройки, а конвейером.
Ну и конечно, продолжаем наращивать качество и скорость самого агента. Куда расти, хорошо видно по графику бенчей выше.
И вот что я вам предлагаю забрать с собой из этой статьи:
-
Прежде чем винить модель — проверь харнесс, рычаг там. Наши кейсы дают +5…+9 п. п. на компонент.
-
Харнесс — это не только качество, но и экономика. Чем дешевле обвязка, тем больше пользователей на тех же GPU.
-
Модели меняются, и харнесс вместе с ними. Поэтому харнесс лучше держать простым, чтобы на каждом релизе можно было перемерить пользу каждого компонента и срезать то, что устарело.
На этом всё. Приходите в комментарии с вопросами — особенно про харнесс.
Хотел сказать большое спасибо команде агента, ребята, вы лучшие: Федор Воробьев, Даниил Беликов, Борис Пресняков, Глеб Нуждов, Сергей Ширяев, Рафиз Рагимов, Сергей Баршин, Александр Мосидзе.
Автор: prohor33
