Одна модель решает одну задачу за один прогон. Это базовая схема использования LLM, которая хорошо работает для запросов вида «переведи абзац» или «напиши код функции». Но как только задача начинает дробиться на несколько разнородных шагов, схема ломается: либо приходится держать всё в одной модели и переплачивать, либо вручную копировать промежуточные результаты между чатами.
Sub-agents — это механизм, при котором главный агент сам решает: эту подзадачу я делегирую другой модели, у неё с этим лучше. В EPIHEN такая схема встроена и работает прозрачно. Разберём как именно и когда это полезно.
Что такое sub-agent в нашем понимании
Sub-agent — это вызов отдельной LLM-сессии из родительской. Главный агент (тот, с которым общается пользователь) формирует промпт, выбирает модель, запускает sub-agent с этим промптом и получает результат как обычный текст. Результат может быть использован в дальнейшем рассуждении или передан пользователю напрямую.
Технически это вызов tool'а с именем run_subagent. Главный агент решает не «я отвечу пользователю», а «я вызову sub-agent, дам ему такую инструкцию, дождусь ответа и потом продолжу думать». Для пользователя это выглядит как обычный ответ, просто чуть дольше — потому что внутри прошло два LLM-вызова, а не один.
В EPIHEN доступны следующие алиасы для sub-agent моделей:
haiku— Claude Haiku 4.5, быстрая и дешёвая, для рутины.sonnet— Claude Sonnet 4.6, баланс цены и качества, для среднего класса задач.opus— Claude Opus 4.7, для глубокого анализа на Anthropic.gpt— GPT-5.5, альтернатива Sonnet, иногда лучше на формальных текстах.r1— DeepSeek R1, дешёвый reasoning, идеально для рутинных reasoning-задач.gemini— Gemini 2.5 Pro, long-context до 2M токенов.gpt-pro— GPT-5.5 Pro, тяжёлый reasoning через background-режим.
Зачем нужны sub-agents
Главных причины три.
1. Декомпозиция большой задачи
Запрос «проанализируй мне три репозитория, сравни их архитектуру и сделай отчёт» — это четыре подзадачи:
- Проанализировать репозиторий A.
- Проанализировать репозиторий B.
- Проанализировать репозиторий C.
- Синтезировать отчёт.
Если поручить всё одной модели в одном прогоне, она будет вынуждена держать в контексте все три репозитория одновременно. Контекст раздувается, ответ становится поверхностным, есть риск, что модель упустит детали из ранних частей.
С sub-agents главный агент запускает три параллельных вызова Haiku — по одному на репозиторий. Каждый Haiku смотрит только свою задачу, даёт подробный анализ. Затем главный агент (например, Sonnet) получает три структурированных результата и синтезирует отчёт. Быстрее, дешевле, точнее.
2. Делегирование по силе модели
Иногда задача требует двух разных типов мышления. Например: «придумай идею стартапа в области медицины и проверь, не существует ли такая компания уже на рынке». Первая часть — креатив, вторая — фактологическая проверка с поиском.
Главный агент Opus, отличный в креативе, делегирует фактологическую проверку Sonnet'у — у того нет смысла переплачивать за Opus на рутинном поиске.
3. Делегирование по специализации
Некоторые модели лучше других в конкретных доменах:
- R1 — формальная логика, математика, code review.
- Gemini Pro — анализ длинных документов (200K+ токенов).
- GPT-5.5 — формальные тексты, презентации, корпоративные документы.
- GPT-5.5 Pro — самые сложные reasoning-цепочки, где можно подождать минуты.
Если в середине разговора потребовалось проанализировать 500-страничный PDF — главный агент делегирует Gemini, не пытаясь запихать документ в собственное окно (даже если оно теоретически вместит).
Конкретные кейсы из реальных чатов
Несколько типовых паттернов, которые мы видим в production.
Кейс 1: технический ревьюер
Пользователь просит «проверь мой PR на типовые проблемы». Главный агент Sonnet:
- Получает diff из git.
- Делегирует R1: «проверь логику этих изменений на корректность, особенно edge-cases».
- Делегирует Haiku: «проверь форматирование, имена переменных, соответствие стилю проекта».
- Получает два ответа, синтезирует общий ревью.
Стоимость такого ревью: ~5 центов на R1 + ~1 цент на Haiku + ~3 цента на главный Sonnet = 9 центов. Если бы делать всё одним Opus'ом — около 40-50 центов.
Кейс 2: исследователь рынка
Пользователь: «найди мне 10 главных трендов в Indie-game разработке 2026». Главный агент Sonnet:
- Запускает поиск.
- Получает 30+ источников.
- Делегирует Gemini (long-context): «прочитай все эти источники и выдели в них пересекающиеся темы».
- Получает консолидированный список тем.
- Синтезирует финальный отчёт с цитатами.
Здесь Gemini незаменим: один прогон в 200K+ токенов справится быстрее и аккуратнее, чем 10 отдельных прогонов в Sonnet с фрагментами.
Кейс 3: тренинг-бот
Пользователь: «помоги мне подготовиться к интервью по системному дизайну». Главный агент Sonnet ведёт диалог, но когда пользователь даёт неверный ответ — делегирует Opus с инструкцией «вот вопрос, вот ответ юзера. Объясни в чём именно ошибка и какой был бы правильный ход мысли». Opus, лучший в архитектурных рассуждениях, выдаёт подробный разбор. Sonnet передаёт его пользователю и продолжает диалог.
Главный агент не «выходит из роли», он остаётся коучем — а Opus используется как привлечённый эксперт.
Что внутри: технические детали
Когда главный агент вызывает run_subagent, происходит следующее:
- Из tool-call'а извлекаются: model (slug), prompt (что спросить), и опциональные параметры (max_tokens, temperature).
- Создаётся новый клиент к API соответствующего провайдера (Anthropic, OpenAI, DeepSeek, Google).
- Отправляется один запрос. Sub-agent не имеет доступа к памяти, инструментам или tool-use — он чистая LLM, отвечает текстом.
- Ответ возвращается главному агенту как результат tool-call'а.
- Главный агент продолжает свой цикл рассуждения с этим результатом.
Время ожидания зависит от модели. Haiku отвечает за 2-4 секунды, Sonnet за 5-10, Opus за 10-30, GPT-Pro может ждать минуты (внутри использует background-режим OpenAI Responses API с поллингом).
Биллинг прозрачный: токены sub-agent'ов считаются по тарифам соответствующих моделей и добавляются к общей стоимости turn'а главного агента. Пользователь видит итоговую стоимость, а в детализации может посмотреть какие именно sub-agents были вызваны.
Ограничения и подводные камни
Рекурсия запрещена. Sub-agent не может вызвать ещё одного sub-agent'а. Это сделано намеренно: рекурсивные цепочки делегирования трудно дебажить, легко зациклить и они быстро становятся дорогими.
Sub-agent не видит контекст диалога. Если пользователь общался с главным агентом два часа и у вас в памяти много контекста, sub-agent при вызове получит только тот промпт, который ему сформулирует главный агент. Это значит, что инструкция должна быть самодостаточной — нельзя сказать «продолжи мысль из предыдущего сообщения».
Не все модели одинаково хороши на коротких задачах. Opus теряет преимущество перед Sonnet'ом на простых запросах. Если задача в 200 токенов промпта и 500 токенов ответа — Sonnet справится за половину цены и почти не хуже. Бенчмарки моделей разбираем в обзоре 2026.
Параллельность стоит оптимизировать. Если делегировать 5 sub-agent'ов одновременно — все 5 запускаются параллельно, что быстро. Но если зависят друг от друга (сначала A, потом B на результате A) — придётся ждать последовательно. Главный агент должен это правильно планировать.
Когда sub-agents НЕ нужны
Если задача укладывается в один прогон одной модели и не требует сильного reasoning'а — sub-agents только замедлят и удорожат. Не нужно делегировать «переведи этот абзац» в R1, не нужно вызывать Opus для «придумай заголовок».
Главный агент в EPIHEN обучен этим самооценкам: если он видит, что задача проста, никаких sub-agents он не вызывает. Делегация включается только когда от неё реальный выигрыш.
Резюме
Sub-agents в EPIHEN — это способ собрать «команду» специализированных моделей, в которой главный агент работает менеджером, а sub-agents — экспертами. Декомпозиция больших задач, делегирование по силе и по специализации, экономия за счёт правильного выбора модели — три главных причины использовать.
На бесплатном тарифе sub-agents доступны с ограничениями (преимущественно Haiku и R1). На Pro и Max открывается весь стек, включая GPT-Pro для самых тяжёлых reasoning-задач.
В следующих статьях разбираем модели по отдельности — Opus vs Sonnet, DeepSeek R1, Gemini long-context.