Single-turn против multi-turn: когда агенту нужна память

Два способа заставить модель работать

Вы отправляете в модель промпт, получаете ответ, и на этом всё заканчивается — это single-turn. Вы ведёте с моделью многошаговый диалог, где каждый следующий вызов тащит за собой предыдущие сообщения, вызовы инструментов и промежуточные результаты — это multi-turn. Разница выглядит академической ровно до момента, когда приходит счёт за токены или пользователь жалуется, что агент забыл, о чём шла речь три реплики назад.

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

Single-turn: один вызов, ноль состояния

Single-turn агент не помнит ничего между запросами. Каждый вызов — чистый лист: вы собираете весь нужный контекст в один промпт, получаете ответ, разбираете его и забываете. Классификация обращений в поддержке, извлечение полей из документа, генерация краткого описания товара, перевод — всё это по природе одношаговое.

Плюсы такого подхода прямые:

• Предсказуемая стоимость. Размер промпта фиксирован, вы заранее знаете верхнюю границу токенов на вызов.
• Низкая задержка. Один round-trip до API, без цепочки промежуточных вызовов.
• Простая отладка. Вход и выход видно целиком, воспроизвести баг легко — достаточно того же промпта.
• Горизонтальное масштабирование. Нет общего состояния, значит вызовы независимы и параллелятся без блокировок.

Ограничение тоже прямое: если задача требует уточнений, ветвления по результату инструмента или накопления фактов — один вызов не справится. Вы либо запихиваете всё в гигантский промпт, либо переходите к multi-turn.

Multi-turn: диалог с состоянием и инструментами

Multi-turn агент держит историю. Он может задать уточняющий вопрос, вызвать инструмент¹, посмотреть на результат, решить вызвать другой, и только потом ответить. Именно так работают агенты, которые бронируют встречи, разбираются в кодовой базе или ведут длинный разговор с пользователем.

Цена гибкости — растущий контекст. На каждом шаге в модель уходит вся предыдущая переписка плюс новые данные. К десятому вызову вы можете отправлять десятки тысяч токенов, из которых половина — уже неактуальный шум. Отсюда три типичные проблемы multi-turn.

Контекст раздувается

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

Ошибки накапливаются

Если модель на третьем шаге сделала неверный вывод, он остаётся в истории и влияет на все последующие шаги. Single-turn таким не страдает — каждый вызов начинается с чистого состояния.

Отладка усложняется

Чтобы воспроизвести баг на восьмом шаге, нужно воспроизвести все семь предыдущих в том же порядке с теми же ответами инструментов. Без логирования каждого шага это превращается в гадание.

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

Как выбирать

Практический порядок решения

1. Опишите задачу как «вход → выход». Если она в это укладывается без потери смысла — берите single-turn.
2. Проверьте, нужен ли вызов внешних инструментов и зависит ли следующий шаг от их результата. Если да — вероятно, multi-turn.
3. Оцените, сколько шагов в среднем и в худшем случае. Если хвост распределения уходит за 15–20 шагов, закладывайте суммаризацию и лимит на длину цепочки заранее.
4. Посчитайте потолок токенов на задачу для multi-turn: примерно сумма контекста на каждом шаге. Сравните с бюджетом.

Гибрид: single-turn внутри оркестратора

Часто лучшая архитектура — не одно из двух, а комбинация. Внешний слой ведёт multi-turn логику: планирует, вызывает инструменты, хранит состояние. А тяжёлую предметную работу — классификацию, извлечение, суммаризацию — выполняют изолированные single-turn вызовы с узким промптом и без лишней истории.

Такой подход даёт предсказуемость подзадач и гибкость оркестрации одновременно. Каждый single-turn вызов легко тестируется отдельно, а оркестратор отвечает только за то, в каком порядке их звать и что делать с результатами. Ошибка внутри одного вызова не тянет за собой всю историю, потому что этот вызов не видит истории вообще.

¹ Инструмент (tool, function call) — внешняя функция, которую модель может вызвать: поиск, запрос к базе, отправка письма. Модель возвращает не текст, а структурированный вызов с аргументами, ваш код его исполняет и отдаёт результат обратно в диалог.