AI-агенты сжигают миллионы токенов на отладке: метод BVC срезает расход на 22%

ИИ-агенты (программы, которые сами принимают решения и вызывают модель несколько раз подряд) при отладке кода способны за одну задачу сжечь миллионы токенов (единиц текста, за которые платит разработчик) впустую, и схема BVC, Budgeted Verified Council, позволяет сократить этот расход на 22% без потери качества патчей.

Автор исследования, разработчик собственной IDE, столкнулся с типичной проблемой: ИИ-агент при отладке цепляется за первую версию решения и наращивает костыли вместо того, чтобы вернуться к причине ошибки. Чтобы остановить этот цикл до первой правки кода, он встроил в среду разработки мультиагентное планирование и провёл 480 контролируемых запусков на двух открытых моделях. Результаты опубликованы в авторском исследовании и проверены через официальный оценщик SWE-bench.

Зачем вообще устраивать «совещание» моделей?

Идея мультиагентных дебатов (multi-agent debate) не нова. Существуют AutoGen и другие способы организовать обсуждение между несколькими экземплярами языковой модели. Здесь автор выделил четыре роли.

• Архитектор: где причина ошибки?
• Разработчик: что менять?
• Рецензент: что от этого сломается?
• Тестировщик: как проверить, что исправление сработало?

Все роли исполняла одна и та же модель, но каждая получала отдельный вызов с собственным системным промптом (инструкцией, задающей поведение модели). Сначала DeepSeek, затем весь набор задач повторили на Qwen.

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

Десять вызовов на задачу, даже когда хватало шести

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

Проблема в том, что второй круг критики часто ничего не менял. Роли и так соглашались друг с другом, но правил остановки не существовало.

Как устроен BVC?

Budgeted Verified Council (BVC, «совет с бюджетом и проверкой») добавил развилку перед критикой.

1. Каждая роль возвращает структурированную позицию: предполагаемую причину ошибки, способ исправления, затрагиваемые зависимости и тесты.
2. Система сравнивает эти поля между собой.
3. Если расхождений нет, критику пропускаем и сразу собираем план. Получается шесть вызовов вместо десяти.
4. Если расхождения есть, запускаем критику и укладываемся в прежние десять.

Формально просто: убрали четыре вызова. Но вся сложность в слове «лишних». Если ранняя остановка выбрасывает полезную проверку, качество падает.

Что показали 480 запусков?

Автор взял 60 задач из SWE-bench Verified (стандартный набор реальных багов из 11 Python-проектов). Лёгкие задачи, оценённые менее чем в 15 минут работы, намеренно исключили. Для каждой задачи сравнивались четыре режима, включая одиночный план без совета, чтобы не приписать пользу четырём ИИ-агентам, которую даёт обычная просьба «сначала подумай».

Каждый патч проверялся официальным оценщиком SWE-bench в контейнере. Мнение самой модели о качестве решения в результат не входило.

DeepSeek: BVC выбрал короткий маршрут в 32 задачах из 60.

• Полный совет: 600 вызовов, 18,37 млн токенов.
• BVC: 472 вызова, 14,28 млн токенов.
• Экономия: 22,2% токенов, 23,5% стоимости.

По зафиксированному тарифу разница составила 564,15 рубля (с 2 402,61 до 1 838,46 рубля). Для пет-проекта сумма скромная, но важен сам факт: правило остановки реально меняло расход, и можно было открыть конкретную задачу и увидеть, где система не сделала четыре лишних вызова.

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

Что делать с этим прямо сейчас?

Разработчику, который использует ИИ-агентов для отладки. Попробуйте перед запуском критики сравнивать структурированные ответы ролей. Если причина бага, способ исправления и затрагиваемые файлы совпали, второй круг обсуждения, скорее всего, не изменит результат. Это можно реализовать даже без собственной IDE, через скрипт поверх API.

Автору Дзена или маркетологу, который платит за API. Каждый лишний вызов модели стоит токенов. Если вы используете цепочки промптов (когда один промпт передаёт результат следующему), проверяйте: не повторяете ли вы шаг, который ничего не добавляет. Принцип BVC работает и за пределами кода: зачем просить модель «перепроверить» ответ, если структура ответа уже совпадает с ожидаемой.

Предпринимателю в РФ. Обе модели из эксперимента, DeepSeek и Qwen, доступны через API без VPN. Из российских аналогов для мультиагентных задач можно попробовать YandexGPT через Yandex Cloud, но встроенного механизма мультиролевых дебатов у него пока нет, придётся организовывать самостоятельно.

root_cause: "ошибка в обработке None в функции parse_input"
fix_approach: "добавить проверку на None перед вызовом .strip()"
affected_files: ["src/parser.py"]

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