Почему браузерный AI-агент дорожает: уроки теста Asana

Что показал свежий тест

8 октября Asana опубликовала разбор оптимизации браузерного агента StackAI. 9 октября OpenAI выпустила отдельный кейс: оптимизированный вариант на GPT-6.1 Sol обходился в среднем в 0,47 USD модельных расходов за запуск и выполнялся примерно за четыре минуты. Относительно исходной конфигурации на другой модели заявлены снижение расходов в 76 раз и ускорение в пять раз. Кейс OpenAI от 9 октября.

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

Почему сокращение истории может увеличить счёт

В описанной реализации агент повторно передавал модели историю страниц и снимков экрана. Кэш позволял дешевле использовать неизменное начало запроса. Но удаление старого снимка или обрезка текста меняли раннюю часть истории и нарушали повторное использование. Команда стала кэшировать историю, реже очищать снимки и увеличила запас для текста. Это описание конкретной архитектуры из разбора Asana от 8 октября.

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

Как читать результат «в 76 раз дешевле»

В кейсе OpenAI показаны разные сравнения. На исходной Model B оптимизация снизила оценку модельных расходов с как минимум 36,21 до 1,24 USD за запуск. Оптимизированный вариант на GPT-6.1 Sol стоил 0,47 USD. При сравнении только Sol с одинаковым увеличенным бюджетом истории эффект изменения кэширования и очистки составил около четырёх раз: с 1,97 до 0,47 USD. Поэтому 76-кратное снижение объединяет изменение процесса и смену модели. Условия и результаты сравнения.

Полный отчёт рассматривает одну задачу на демонстрационном каталоге: 32 книги и шесть полей для каждой. Основная серия включала 144 запуска на четырёх моделях, обычно по три повтора условия. Этапы исследования различались настройками; межмодельное сравнение автор назвал описательным. Оценки расходов исключают сервер и среду исполнения и не являются счетами. Полный отчёт, методы и ограничения, с. 15–19.

Практический вывод для сметы: 0,47 USD относится к условиям этого эксперимента. Используйте измерения своей задачи и применимый тариф поставщика. Общий порядок учёта платформы, инструментов и проверки сотрудником уже разобран в руководстве по AI-затратам.

Правильная сумма ещё не завершает сбор каталога

В полном отчёте есть важная деталь приёмки: GPT-6.1 Sol давал правильную итоговую сумму, самую дешёвую и самую дорогую книгу, однако возвращал краткую сводку вместо запрошенной полной таблицы. Авторы отдельно отмечают, что настройка окончательного ответа не входила в задачу исследования. Проверка ответов в отчёте, с. 18.

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

При оценке разделяйте четыре состояния: сведения прочитаны; сведения сохранены до конца; требуемый файл создан; файл прошёл проверку. Это предложенный редакцией порядок приёмки, который позволяет найти конкретное место потери результата.

Как поставить небольшой проверяемый эксперимент

Ниже — пример проверки для дистрибьютора, а не результат внедрения SABSUS. Выберите разрешённый для автоматизированного чтения каталог и фиксированный список товаров. На первом этапе агент только готовит файл для сотрудника. Обновление рабочих цен, отправка предложения клиенту и размещение заказа остаются отдельными согласованными действиями.

1. Зафиксируйте исходный вариант. Сохраните модель, настройки, список полей и одинаковые правила приёмки. Для изменяющихся цен укажите время чтения: иначе обновление страницы будет выглядеть как ошибка агента.
2. Попросите разработчика показать место изменения истории. В журнале должны быть видны очистка снимков, удаление текста и последующий расход. Одной надписи «кэш включён» недостаточно для объяснения счёта.
3. Меняйте один управляемый фактор. Сначала сравните настройки истории на той же модели. Затем, если есть смысл, отдельно сравните модели при одинаковых условиях. Несколько одновременных изменений мешают понять причину результата.
4. Повторяйте задачи и сохраняйте неудачи. Записывайте затраты, длительность, повторные посещения страниц и принятые файлы. Отдельно отмечайте остановку по лимиту: незавершённый дешёвый запуск не улучшает рабочий процесс.
5. Проверьте остановку и продолжение. Ответственный должен получить список обработанных товаров и остаток работы. Увеличение истории допустимо только вместе с проверенным ограничением расходов и действий.

В рекомендациях StackAI сохранение истории сопровождается ограничениями шагов, токенов и расходов. Полный отказ от очистки исследовали лишь в отдельной дополнительной серии; переносить его на любые длинные задачи авторы не предлагают. Пояснения StackAI о границах эксперимента.

Что спросить перед внедрением

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

По сообщению Asana, изменения уже выпущены в StackAI. Материал не устанавливает, в какой подписке доступны конкретные настройки и какие права есть у вашего аккаунта; это нужно подтвердить отдельно. Статус изменений в публикации Asana. Подключение результатов к CRM SABSUS также требует согласованного сопоставления полей и проверки записи.

Источники проверены 9 октября 2026 года UTC. Автор: редакция SABSUS. Числа выше относятся к опубликованному исследованию поставщиков; независимое воспроизведение и клиентское внедрение здесь не проводились. Диагностические вопросы и пример проверки — редакционный анализ.