Asana рассказала о результатах оптимизации браузерного ИИ-агента: в тестах модельные затраты удалось снизить в 76 раз, а скорость выполнения задач — увеличить в 5 раз. Средняя расчетная стоимость одного запуска в оптимизированной конфигурации на GPT-6.1 Sol составила 0,47 доллара.

Речь идет о браузерном агенте в платформе StackAI, которую Asana использует для автоматизации действий в бизнес-приложениях: навигации по сайтам, заполнения форм и сбора данных. Для крупного бизнеса даже небольшая неэффективность в таких сценариях быстро превращается в заметные расходы, поэтому компания отдельно исследовала, как сократить стоимость и время работы агента.

Что именно изменили

По данным Asana, технический директор StackAI Фрэнк Идальго поручил GPT-6 Astra в Codex проанализировать кодовую базу агента, найти узкие места и проверить гипотезы в контролируемых тестах. Работа, которая вручную могла занять от одного до двух месяцев, заняла около недели.

Главная проблема оказалась в том, что агент кэшировал постоянные инструкции и описания инструментов, но не кэшировал растущую историю своей работы — тексты страниц и скриншоты. Из-за этого при каждом новом запросе большой объем данных отправлялся заново по полной цене.

В итоге команда протестировала три ключевых изменения:

  • распространила кэширование на историю работы браузерного агента;
  • увеличила объем сохраняемого текста в истории;
  • перешла от удаления скриншотов на каждом шаге к пакетному удалению.

Лучший результат дала стратегия, при которой скриншоты накапливались до 20 штук, после чего сохранялся только последний. Это позволило дольше не менять раннюю часть истории и эффективнее использовать кэш.

Какие результаты получила Asana

В исследовании было 144 запуска с участием GPT-6.1 Sol и еще трех моделей. Одна и та же задача заключалась в сборе шести полей по 32 книгам из открытого демонстрационного каталога — это типичный сценарий для клиентов StackAI.

По данным компании, оптимизированный процесс на GPT-6.1 Sol в среднем:

  • выполнялся примерно за 4 минуты;
  • стоил 0,47 доллара за запуск;
  • оказался в 76 раз дешевле и в 5 раз быстрее исходной рабочей конфигурации на модели B.

Если сравнивать только модель B до и после оптимизации, расчетные затраты снизились с как минимум 36,21 доллара до 1,24 доллара за запуск — это сокращение в 29 раз. На самой GPT-6.1 Sol новая схема дополнительно снизила стоимость с 1,97 до 0,47 доллара за запуск, то есть примерно в 4 раза.

Asana также отмечает, что около 89% входных данных в оптимизированной конфигурации поступало из кэша по цене в 5% от стоимости некэшированных данных. Это стало одной из главных причин экономии.

Почему выросла не только экономия, но и надежность

Исследование показало, что управление историей влияет не только на цену, но и на вероятность получить ответ вообще. При меньшем лимите истории GPT-6.1 Sol отвечала только в 3 из 18 запусков, а при увеличенном лимите — во всех 18 из 18. При этом каждый полученный ответ был правильным.

Для бизнеса это важный вывод: оптимизация агентных сценариев — это не только вопрос сокращения расходов на модель, но и способ повысить стабильность автоматизации. Если агент теряет контекст слишком рано, он может повторно обходить уже просмотренные страницы, тратить больше токенов и не доводить задачу до конца.

Что это значит для российского рынка

Новость важна не только для компаний, которые работают с OpenAI. Для российского рынка это показательный кейс о том, что стоимость ИИ-автоматизации часто зависит не столько от выбора самой модели, сколько от архитектуры процесса: кэширования, управления контекстом, хранения скриншотов и длины истории.

Этот подход применим в задачах, знакомых российским digital-командам: парсинг карточек товаров, проверка форм лидогенерации, мониторинг сайтов конкурентов, автоматизация рутинных действий в CRM и внутренних веб-интерфейсах. Для специалистов, которые работают и с Google, и с Яндексом, вывод практический: при внедрении ИИ-агентов в SEO, контентные и performance-задачи нужно отдельно считать стоимость каждого шага, объем передаваемого контекста и долю повторно используемых данных.

Особенно это актуально для агентств и крупных in-house команд, где браузерные агенты могут использоваться для массовых проверок посадочных страниц, сбора данных из веб-интерфейсов и автоматизации отчетности. Без настройки кэша и истории даже сильная модель может оказаться слишком дорогой для регулярного применения.

На практике кейс Asana показывает простую вещь: перед сменой модели или увеличением бюджета стоит сначала оптимизировать сам процесс работы агента. Для владельцев бизнеса, интернет-маркетологов, SEO- и PPC-специалистов это сигнал считать не только качество ответа ИИ, но и цену каждого сценария автоматизации в реальной эксплуатации.

Совет эксперта Analito

Проверьте все сценарии с ИИ-агентами, где модель на каждом шаге заново получает длинную историю действий, текст страниц или скриншоты. Если такие данные можно переиспользовать, внедрите кэширование и отдельно посчитайте стоимость одного полного запуска до и после изменений.

Для браузерной автоматизации протестируйте несколько лимитов контекста и стратегий хранения артефактов: текста, HTML, скриншотов, логов. Слишком короткая история часто снижает не только качество, но и вероятность завершения задачи.

Если агент используется в SEO, контенте или PPC-операциях, заведите метрики на уровне сценария: стоимость запуска, время выполнения, доля успешных завершений и число повторных шагов. Это поможет понять, где проблема в модели, а где — в архитектуре процесса.

Частые вопросы

За счет чего Asana получила основную экономию?

Главный эффект дали кэширование истории работы агента, увеличение объема сохраняемого контекста и пакетное удаление скриншотов вместо удаления на каждом шаге.

Почему это важно не только разработчикам, но и маркетологам?

Потому что те же принципы работают в автоматизации SEO-аудитов, сбора данных, проверки форм и других рутинных задач, где ИИ взаимодействует с сайтами через браузер.

Означает ли кейс Asana, что достаточно просто выбрать более дешевую модель?

Нет. Кейс показывает, что архитектура процесса может влиять на расходы сильнее, чем сама модель: без оптимизации даже хорошая модель будет работать медленно и дорого.