Субагенты в Claude Code и не только: зачем агенту делить задачу

В 2024–2025 годах разработчики агентских инструментов пришли к одной и той же идее: один большой агент с раздутым контекстом работает хуже, чем связка из главного агента и нескольких узких исполнителей. Anthropic встроила механизм субагентов в Claude Code, OpenAI описала похожий паттерн в своём Agents SDK, а фреймворки вроде LangGraph и CrewAI строят на делегировании всю архитектуру. Идея одна: вместо того чтобы держать всю задачу в голове одной модели, вы разбиваете её на подзадачи и раздаёте отдельным экземплярам — субагентам¹.

Что такое субагент и зачем он нужен

Субагент — это вложенный вызов модели с собственной инструкцией, собственным контекстным окном² и, часто, собственным набором инструментов. Главный агент (его иногда называют оркестратором) получает от пользователя задачу, дробит её на части и передаёт каждую часть отдельному субагенту. Тот работает изолированно, возвращает результат — и главный агент собирает из этих результатов ответ.

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

Оркестратор должен думать о том, что делать, а не о том, как. Как — это забота субагента, и его грязный контекст остаётся при нём.

Как это выглядит на практике

В Claude Code субагент задаётся отдельным файлом-описанием: имя, когда его вызывать, какие инструменты ему разрешены и системный промпт. Главный агент видит список доступных субагентов и сам решает, когда делегировать. Например, при рефакторинге репозитория оркестратор может запустить одного субагента на анализ зависимостей, второго — на переписывание конкретного модуля, третьего — на прогон тестов. Каждый работает в своём окне и возвращает короткую сводку.

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

Чем это отличается от простого длинного промпта

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

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

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

Сравнение подходов

Точные названия инструментов и синтаксис описаний меняются между версиями — сверяйтесь с актуальной документацией конкретного продукта, а не с этим текстом.

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

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

Пригодится

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

Не пригодится

• Короткие однозначные запросы. Написать функцию, ответить на вопрос по одному файлу — делегирование только добавит задержку и стоимость.
• Задачи, где важен единый непрерывный контекст. Если субагенту для работы нужна вся история диалога, изоляция превращается в потерю информации.
• Жёсткие ограничения по бюджету токенов. Несколько параллельных агентов сжигают токены быстрее одного, и на объёме это заметно в счёте.

Правило простое: если задачу нельзя честно разбить на независимые куски, субагенты вам не нужны — вы просто заплатите за оркестрацию, которая ничего не оркеструет.

Подводные камни

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

Второе — отладка. Когда что-то идёт не так в цепочке из оркестратора и пяти субагентов, найти, где именно сломалось, сложнее, чем в одном логе. Хорошие инструменты показывают дерево вызовов, но читать его — отдельный навык.

Третье — соблазн переусложнить. Легко построить архитектуру из десятка агентов там, где хватило бы одного вызова модели. Начинайте с монолита и выделяйте субагентов только тогда, когда упираетесь в деградацию контекста или явно видите независимые ветки работы.

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

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