Как агенты разбивают задачи: decomposition и sub-goals

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

Что такое планирование задач у агента

Агент¹ — это система на базе языковой модели, которая не просто отвечает текстом, а выбирает действия: вызывает инструменты, читает файлы, обращается к API, делает несколько шагов подряд. Между запросом пользователя и финальным результатом лежит планирование: превращение расплывчатой цели в последовательность выполнимых подзадач.

Два ключевых понятия здесь — decomposition (декомпозиция) и sub-goals (подцели). Декомпозиция — это разбиение большой задачи на более мелкие. Подцели — промежуточные состояния, которых нужно достичь по дороге к финалу. «Отправить письмо руководителю» — финальная цель. «Получить данные о продажах», «посчитать разницу», «сформулировать текст», «найти адрес» — подцели, каждая из которых сама может делиться дальше.

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

Почему это сложнее, чем кажется

Языковая модель не хранит состояние между вызовами сама по себе. Всё, что она «знает» на очередном шаге, — это то, что уместилось в контекстное окно². Когда план разрастается на десять-пятнадцать шагов, ранние решения выталкиваются из окна или тонут в шуме, и агент начинает противоречить собственному плану: повторяет уже сделанное, забывает исходное условие, зацикливается.

Основные подходы к декомпозиции

За последние пару лет сложилось несколько семейств методов. Ни один не признан универсально лучшим — они по-разному ведут себя в зависимости от типа задачи.

• Chain-of-Thought и вариации. Модель проговаривает рассуждение по шагам перед ответом. Работает для задач, где план линеен, но плохо восстанавливается после ошибки: одно неверное звено тянет за собой всю цепочку.
• ReAct (Reasoning + Acting). Чередование рассуждения и действия: модель думает, вызывает инструмент, смотрит результат, снова думает. Даёт обратную связь на каждом шаге и позволяет корректировать курс.
• Планирование деревом (Tree-of-Thoughts и родственные). Агент рассматривает несколько веток решения параллельно, оценивает их и выбирает перспективную. Дороже по вызовам модели, но устойчивее к тупикам.
• Иерархическое планирование (planner + executor). Одна модель или один вызов строит высокоуровневый план из подцелей, другая — исполняет каждую подцель отдельно. Разделение снимает нагрузку с контекста: исполнителю не нужно держать в голове весь план.

Static plan против re-planning

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

Как подходы соотносятся между собой

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

Где всё ломается

Проблемы декомпозиции повторяются от системы к системе:

1. Дрейф цели. На шаге восемь агент решает задачу, которую сам придумал на шаге пять, а не ту, что поставил пользователь.
2. Накопление ошибок. Если один шаг выполняется правильно с вероятностью 90%, то на десяти шагах шанс пройти всю цепочку без ошибки падает примерно до трети — просто по перемножению вероятностей.
3. Слишком мелкое или слишком крупное дробление. Разобьёшь на слишком мелкие шаги — раздуешь стоимость и время; на слишком крупные — исполнитель не справится с подзадачей.
4. Отсутствие проверки. Агент считает подцель достигнутой, хотя инструмент вернул пустой результат или ошибку, и уверенно идёт дальше.

Кому это пригодится и кому нет

Пригодится, если вы строите:

• автоматизацию рутинных многошаговых процессов — сбор данных из нескольких источников, обработка, отчёт;
• ассистента для разработки, который читает репозиторий, вносит правки и запускает тесты;
• исследовательского агента, который декомпозирует широкий вопрос на подзапросы и собирает ответ из частей.

Не стоит городить планировщик, если:

• задача решается одним запросом к модели — тогда любая декомпозиция только добавит стоимость и точки отказа;
• цена ошибки высока и нет человека в цикле — финансовые операции или отправка юридически значимых документов без подтверждения человеком остаются рискованными;
• вам нужна воспроизводимость — многошаговый агент с перепланированием на одном и том же входе может дать разные траектории.

Практический вывод

Планирование — это не «включить умный режим», а инженерный компромисс между стоимостью, надёжностью и гибкостью. Чем длиннее цепочка, тем важнее не столько сила базовой модели, сколько устройство петли: как агент проверяет промежуточный результат, где хранит состояние вне контекстного окна, что делает при сбое. Начинать почти всегда стоит с простого линейного плана и добавлять ветвление и перепланирование только там, где статический план реально ломается — а не заранее.

¹ Агент — программа на базе языковой модели, которая выбирает и выполняет действия (вызовы инструментов, API, чтение данных) в цикле, а не просто генерирует один текстовый ответ.

² Контекстное окно — максимальный объём текста (в токенах), который модель обрабатывает за один вызов. Всё, что не поместилось, для модели не существует, пока это не подать ей заново.