AI-кодинг-агенты и чат-ассистенты: как измерить разницу в нагрузке на LLM

Многие разработчики воспринимают AI-кодинг-ассистентов просто как чат, подключённый к редактору, но между чат-ассистентом и кодинг-агентом есть серьёзная разница. Обычный чат-ассистент обычно работает по простой схеме: пользователь передаёт запрос, модель обрабатывает его и возвращает код или объяснение. При этом пользователь сам выполняет большую часть работы: он предоставляет нужный фрагмент кода, сам запускает сборку, тесты и исправляет ошибки. AI-кодинг-агент действует иначе. Он получает не просто вопрос, а задачу, после чего сам может исследовать репозиторий, искать символы и файлы, читать код, вносить правки, запускать сборку и тесты, анализировать результаты и повторять цикл до тех пор, пока задача не будет завершена. Разница важна, даже если обе системы используют одну и ту же модель. Чат может выполнить один вызов модели с пятью тысячами входных токенов и тысячей выходных, тогда как агент на той же задаче может сделать двенадцать вызовов, обработать восемьдесят тысяч входных токенов, сгенерировать восемь тысяч выходных, двадцать раз обратиться к инструментам и четыре раза запустить тесты. Это меняет нагрузку на серверную часть: растут расход токенов, использование кэша, частота вызовов, задержка, стоимость, нагрузка на контекстное окно и вероятность сбоя. Поэтому сравнивать системы только по качеству ответов некорректно. Автор предлагает заранее определить единицу работы. Для чат-ассистента это может быть один запрос пользователя и один ответ модели. Для агента правильнее считать завершённое изменение в репозитории: например, добавить валидацию входных данных в Customer API и обновить тесты. Тогда бенчмарк проверяет именно выполнение задачи, а не просто осмысленность ответа. В статье перечислены категории задач, которые стоит включать в сравнение: генерация кода на C#, объяснение архитектуры аутентификации, поиск и исправление падающего теста, рефакторинг дублирующейся логики, добавление пагинации, обновление зависимостей с исправлением ошибок сборки и многошаговая разработка с новой конечной точкой, изменениями в модели данных и проверкой всего решения. Именно на многошаговых задачах агентное поведение заметнее всего. Для измерения предлагается записывать каждый вызов модели, а не смотреть на агента как на один непрозрачный запрос. В примере из статьи используется C#-запись ModelCall с полями Sequence, InputTokens, OutputTokens, DurationMs и Purpose. Это позволяет отслеживать последовательность вызовов, количество токенов, длительность и назначение каждого шага. Отдельно нужно учитывать суммарный контекст, а не только самый большой отдельный запрос. Если агент несколько раз читает один и тот же файл или накапливает результаты инструментов, отдельные вызовы могут быть небольшими, но суммарная обработка токенов окажется значительной. В статье приводится пример: четыре вызова с контекстом 8K, 12K, 18K и 25K токенов дают в сумме 63K токенов. Поэтому фиксировать стоит и контекст каждого вызова, и накопленный контекст. Дополнительно нужно следить за инструментами: фиксировать имя инструмента, число вызовов, успешные и неуспешные попытки, повторы и время выполнения. Это помогает понять, где агент тратит время, например на чтение файлов или повторные сборки после ошибок. Ещё одно отличие — исследование репозитория: пользователь может передать чату один файл, а агент сам обнаружит несколько связанных файлов и зависимостей. Такой подход даёт разработчикам не абстрактное сравнение, а измеримую картину нагрузки: она полезна при выборе инструмента, планировании ресурсов и оценке реальной стоимости агентных функций.