Subagents — параллельная работа без переполнения контекста

Почему я вообще начал использовать subagents

Полгода назад я работал над сайтом ErgonLab в одном чате. К концу дня — 85% контекста, Claude начинает терять детали, путать файлы, переспрашивать то, что было обсуждено два часа назад. Знакомо?

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

Subagent — это решение. Большую самостоятельную работу ты отдаёшь специализированному агенту. У него своё контекстное окно. Он делает свою задачу. Возвращает сжатый результат: «готово, вот изменённые файлы», «вот отчёт на 500 слов», «вот список проблем». Твой основной контекст остаётся чистым.

Через две недели работы с этой моделью у меня перестали быть «тяжёлые сессии». Сегодня (14 мая) я редактирую этот же сайт, и одновременно в фоне крутится subagent на content-polish — но об этом ниже.

Когда subagent, а когда основной чат

Простое решающее правило, которое я для себя вывел:

Если задача займёт больше 20% контекста и её результат можно сжать — это agent. Иначе — основной чат.

Примеры из последней недели:

Логика: если результат — «список из 5 пунктов» или «отчёт на 1000 слов», то 80% контекста, которое потребовалось агенту для этой работы, мне не нужно. Если же я обсуждаю архитектуру и каждый шаг важен — нет смысла отдавать это агенту, я хочу видеть рассуждение.

Foreground vs background

Тут вторая важная развилка. Subagent можно запустить:

• Foreground — основной чат ждёт, агент работает, возвращает результат, мы продолжаем.
• Background (run_in_background: true) — агент уходит работать, я в основном чате продолжаю заниматься другим.

Background я включаю, когда:

• Задача независимая. Мне не нужен результат, чтобы продолжить работу.
• Задача долгая. От 10 минут и больше.
• Результат пригодится потом, не сейчас.

Самый частый кейс — quality-guardian в фоне перед коммитом. Я говорю «прогони ревью», агент уходит в фон, я в это время дописываю CHANGELOG. Через 5 минут возвращается отчёт. Если всё ок — коммичу, если нашлись проблемы — фикшу.

Изоляция через worktree

Отдельный приём, когда я не хочу, чтобы агент в принципе видел моё текущее состояние файлов. Например — я экспериментирую в одной ветке, а агенту нужно сделать рефакторинг от main.

Git worktree создаёт второе рабочее дерево из той же репы, но с другой веткой. Subagent заходит туда, делает свою работу, я в основном дереве продолжаю своё. Никаких конфликтов, никаких «ой, я не там сохранил».

Использую это редко, но когда нужно — спасает. Особенно на SkandiKlubb, где параллельно может идти работа над сайтом и над ботом — agent под бота сидит в своём worktree, я под сайт в своём.

Бюджет контекста: 20/80

Я для себя ввёл правило: 20% контекста — на оркестрацию, 80% — на работу.

Оркестрация это:

• Постановка задач агентам.
• Обсуждение архитектуры со мной.
• Чтение их отчётов.
• Координация между параллельными работами.

Работа — это реальный код, тексты, разборы, которые я хочу видеть в основном чате.

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

На крупных проектах вроде Evolventa (платформа на Next.js + Prisma + Postgres, 17 эндпоинтов) это правило критично. Без него каждая фича раздувает контекст до 90% за день.

Реальный пример с сегодняшнего дня

Сегодня, 14 мая, я работаю над сайтом ErgonLab. Параллельно идут две задачи:

Основной чат (где я сейчас):

• Пишу контент для трёх новых статей в базу знаний.
• Думаю над структурой каталога Академии.
• Обсуждаю позиционирование с самим собой.

Фоновый subagent:

• frontend-specialist делает content-polish по всему сайту: проверяет тон, ищет dead code, выравнивает заголовки, чистит дубли.
• Запущен через run_in_background: true.
• ТЗ дано один раз, агент работает в своём контексте.

Когда я закончу со статьями, агент уже выдаст diff на 49 файлов в одном коммите. Я его пересмотрю, поправлю что не так, закоммичу. Если бы я это делал в основном чате — мой контекст забился бы чтением 49 файлов и я бы не смог сосредоточиться на текстах.

Это и есть смысл параллельной работы: не «делать быстрее», а «не мешать одной задаче другой».

Когда я ошибался с subagents

Несколько типичных ошибок, через которые сам прошёл.

Ошибка 1: запускать агента ради 50 строк кода.

Поправить три функции в одном файле — это не для агента. Overhead на постановку задачи и чтение отчёта больше, чем сама работа. Я однажды отправил backend-specialist дописать декоратор. Ушло три минуты на ТЗ и две минуты на чтение отчёта. Сам написал бы за полторы.

Правило: если задача меньше 20% контекста — делаю сам.

Ошибка 2: не давать агенту чёткое ТЗ.

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

Хорошее ТЗ: «Прогони код-ревью изменённых файлов в bots/lana/. Сфокусируйся на: безопасность хранения сессий, обработка ошибок Telethon, утечки памяти. Верни список из 3-5 главных проблем».

Конкретно. Ограниченно. С форматом ответа.

Ошибка 3: запускать много агентов одновременно без координации.

Я однажды запустил три параллельных агента: один на бэк, один на фронт, один на тесты. Через час получил три отчёта, в которых файлы пересекались. Конфликты merge на ровном месте.

Если задачи трогают одни и те же файлы — запускай последовательно или явно разделяй зоны ответственности в ТЗ.

Ошибка 4: использовать агента как чат-бота.

«Спроси у web-researcher, что лучше — Postgres или MongoDB» — нет. Это не задача для агента, это короткий вопрос. Агент тратит контекст на разворачивание исследования, а тебе нужен один ответ.

Агент — для самостоятельной работы. Для коротких вопросов — основной чат.

Чек-лист перед запуском subagent

Я каждый раз перед запуском прохожу по списку:

1. Задача займёт больше 20% контекста? Если нет — делаю в основном чате.
2. Результат можно сжать в отчёт/diff/список? Если нет — нужно обсуждение, не делегирование.
3. Дал ли я агенту чёткие границы файлов и формат ответа? Если нет — переписываю ТЗ.
4. Эта работа независима от того, что я делаю в основном чате? Если да — запускаю в фон. Если нет — foreground.
5. Есть ли пересечение с другими активными агентами? Если есть — последовательно, не параллельно.

Если на все «да» — запускаю.

Что сделать прямо сейчас

1. Открой свою текущую сессию. Сколько процентов контекста занято? Если >70% — у тебя проблема, которую решают агенты.
2. Найди в недавней истории задачу, на которой ты «утонул». Это была работа для агента, а ты тащил её в основной чат.
3. Заведи минимальный набор: quality-guardian (ревью), web-researcher (исследование), test-writer (тесты). Этого хватит на 80% случаев.

Через неделю работы с этой моделью ты заметишь, что сессии перестали разваливаться к концу дня.