AI-харнесс для бизнеса: сокращение затрат на токены на 38%
Исследователи компании Writer опубликовали работу, в которой показали: оптимизация слоя оркестрации AI-агента — так называемого харнесса — позволяет сократить расход токенов на 38%, снизить стоимость выполнения задачи на 41% и уменьшить время ответа на 44%, не меняя при этом базовую языковую модель.
Это исследование затрагивает один из ключевых управленческих вопросов в корпоративном AI: почему вложения в искусственный интеллект растут, а экономический эффект не очевиден. Ответ, который дают авторы работы, неудобен для большинства команд разработки: проблема не в модели, а в архитектуре вокруг неё.
Почему токены становятся скрытым центром затрат
Большинство инженерных команд сегодня работают в режиме, который авторы исследования называют «tokenmaxxing». Вместо того чтобы проектировать эффективные рабочие процессы, разработчики заполняют контекстное окно моделей максимальным количеством данных, надеясь получить нужный результат за счёт объёма, а не архитектуры.
Механизм накопления затрат здесь нелинейный. Каждая итерация агентного цикла повторно передаёт весь накопленный контекст — включая историю ошибок, промежуточные результаты и исходные инструкции. Чем длиннее цикл, тем дороже каждый следующий шаг. При этом выходные токены стоят значительно больше входных у всех крупных провайдеров моделей, что делает неэффективное выполнение задач скрытым убытком.
Снижение цен на токены создаёт иллюзию контроля над расходами. Руководители видят падение стоимости единицы токена и считают проблему решённой, тогда как количество токенов на задачу продолжает расти быстрее, чем падает цена.
Ситуацию усугубляет то, что существующие подходы к оптимизации — сжатие промптов, ограничение шагов рассуждения, ускорение генерации через малые вспомогательные модели — работают с моделью в изоляции и не затрагивают архитектуру оркестрации. Это похоже на настройку двигателя при неисправной трансмиссии.
Что такое харнесс и почему он важнее, чем кажется
Харнесс — это слой оркестрации, который маршрутизирует запросы, форматирует данные, управляет историей взаимодействия и превращает языковую модель в работающую систему. Исторически его воспринимали как вспомогательный «склеивающий» код между API модели и интерфейсом пользователя.
Авторы исследования формулируют принципиально иную позицию: харнесс — это первичный программный артефакт, требующий собственного тестирования, версионирования и архитектурного проектирования. Именно он определяет стоимость каждой задачи, потому что именно он задаёт, сколько токенов потребляется на каждом шаге.
Эксперименты проводились на шести языковых моделях от разных поставщиков: Claude Sonnet 4.6, Gemini 3.1, Gemini Flash 3.5, Qwen 3.6, GLM 5.1 и Palmyra X6 от самой Writer. Исследователи зафиксировали 22 корпоративных задачи и сравнили стандартный агентный цикл с оптимизированным харнессом при одинаковых моделях и задачах. Это позволило изолировать эффект именно архитектуры оркестрации.
Результаты: средняя стоимость задачи снизилась с 21 цента до 12 центов, количество токенов на задачу — с 14 200 до 8 800, медианное время выполнения — с 48 до 27 секунд. При этом процент успешно выполненных задач не упал, а незначительно вырос — с 78% до 81%, хотя авторы оговариваются, что этот прирост не является статистически значимым при данном объёме выборки.
Важное ограничение: мультиагентная оркестрация с делегированием задач субагентам надёжно работает только на достаточно мощных моделях. Gemini Flash 3.5 и Qwen 3.6 показали коэффициент надёжности 0.45 и 0.42 соответственно — ниже порога практической применимости. Уверенные результаты показали только Palmyra X6 (0.86) и Claude Sonnet 4.6 (0.85).
Практические механизмы оптимизации харнесса
Исследование описывает конкретные архитектурные решения, доступные инженерным командам без изменения базовой модели.
Кэширование системного промпта. Современные API предоставляют возможность кэшировать часть промпта, но для этого необходима правильная структура запроса. Статичные элементы — базовые правила, схемы инструментов, регламенты — должны располагаться в начале промпта. Динамические элементы — текущий запрос, актуальное состояние задачи — добавляются в конец. Такое разделение позволяет харнессу переиспользовать кэшированный префикс в сотнях вызовов и не оплачивать одни и те же инструкции на каждом шаге агентного цикла.
Вынос контекста во внешнее хранилище. Вместо того чтобы накапливать историю взаимодействия и промежуточные артефакты внутри контекстного окна, их следует перемещать во внешнее хранилище с возможностью точечного извлечения. На каждом шаге в окно возвращается только то, что нужно для текущего действия. Делегирование поиска специализированным субагентам позволяет избежать заполнения основного контекста сырыми результатами.
Жёсткие ограничители агентных циклов. Неуправляемые агентные циклы — основной источник бюджетных потерь при работе с AI-агентами. Ограничения должны быть реализованы в коде на стороне разработчика, а не передаваться самой модели как инструкция. Это означает: фиксированный бюджет токенов на задачу с жёстким завершением при его исчерпании; ограничения на количество шагов, вызовов инструментов и глубину рекурсии; лимит расходов на повторные попытки после первой неудачной валидации.
Авторы также предупреждают об обратном эффекте чрезмерной оптимизации. Добавление структурных элементов в харнесс требует от модели обрабатывать этот контекст. Если модель недостаточно мощная, она тратит ресурсы на разбор инструкций вместо выполнения задачи — и точность падает, а расход токенов растёт. Принцип прост: если архитектурный элемент добавляет больше координационных токенов, чем экономит на задаче, его следует убрать.
Для команд, находящихся на этапе прототипирования, авторы прямо указывают: затраты на проектирование харнесса не оправданы до момента выхода в продакшн с существенным объёмом запросов. Оптимизация имеет смысл при масштабировании до миллионов обращений в сутки.
Практический вывод: если ваша компания уже использует AI-агентов в производственной среде, первым шагом должен стать аудит архитектуры оркестрации — не выбор другой модели. Зафиксируйте метрику «токенов на задачу» как основной показатель экономической эффективности AI, отдельно от цены за токен, и установите жёсткие программные ограничители агентных циклов до следующего цикла масштабирования.