Суб-агенты: изоляция контекста и цена передачи

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

Суб-агенты: изоляция контекста и цена передачи

Изоляция — четвёртая операция контекста в рамке LangChain рядом с write, select и compress (её пересказывает Marina Wyss в «Context Engineering in 29 Minutes»). Из четырёх операций только изоляция обещает другое: развести контексты по разным окнам. Дальше — что она даёт, чем за это платят на стыках и где она превращается в способ испортить один хороший контекст четырьмя посредственными.

Измеренный эффект: суб-агент не тратит окно родителя

Самая наглядная цифра — у David Mahler («Claude Code: Context, Memory & Compaction Explained»). Он запустил general-purpose суб-агента на целую задачу: тот читал файлы, гонял команды, собирал учебное пособие. Заполнение основного контекста — 19% до и 19% после. Наверх вернулась только финальная сводка. У суб-агента своё окно, своя модель, свои инструменты и инструкции — родитель не платит за его чтение ничем.

IndyDevDan («Elite Context Engineering with Claude Code») меряет то же с другой стороны. Определения кастомных суб-агентов попадают не в пользовательский промпт, а в системный, поэтому три кастомных агента стоят 122 токена в главном окне — при «сыром» размере одного описания около 900 токенов. Работа (веб-скрейп документации) идёт в окнах 8–10 суб-агентов примерно по 3k токенов, наружу выходит только файл-результат. Суммарно сэкономлено порядка 40 000 токенов, главное окно осталось на ~9k.

Anthropic в пересказе Lance Martin (LangChain) формулирует эффект в терминах пропускной способности: многоагентность увеличивает общее число токенов, которое система способна обработать, — отсюда более богатые отчёты, а не только более дешёвые.

Но экономия — побочный приз. Marina Wyss ставит акцент иначе: главная проблема одного агента на всё — контаминация. Подробные результаты поиска из фазы research продолжают лежать в контексте на фазе написания кода и отвлекают. Суб-агент работает в чистом окне и возвращает сжатое резюме. Весь мусор поиска остаётся у него. Emre (OpenAI, «Build Hour: Agent Memory Patterns») называет тот же приём isolate and route и говорит прямо: цель — минимизировать context conflict и context poisoning, и лишь во вторую очередь счёт за токены.

Arize («How we solved Context Management in Agents») описывает переход буквально. Было: разговор, история чата, тяжёлые данные и поиск в одном контексте. Стало: главный агент держит только чат и лёгкий контекст, а сотни спанов внутри одного трейса живут в суб-агенте. Назвали game-changer и раскатали на все data-intensive операции — и тут же честно добавили, что «огромный контекст всё ещё ломает всё».

Восстановление после взрыва: context bundles

У изоляции есть побочный полезный эффект — она делает состояние переносимым. IndyDevDan через хуки Claude Code дописывает все вызовы (промпты, read, search) в лог-файл в каталоге agents/context-bundles/, уникальный по дню, часу и session ID. Когда окно взорвалось, новый инстанс поднимается через /load_bundle <path>: дедуплицирует повторные чтения и восстанавливает картину работы предыдущего агента, включая исходный пользовательский промпт — ответ на вопрос «зачем контекст такой, какой он есть».

Цифра важная и отрезвляющая: бандл восстанавливает 60–70% состояния, но не все сто процентов. Причём остальное режется сознательно: логировать всё нельзя — переполнишь окно следующего агента, поэтому содержимое записей и детали чтений в бандл не пишут, а загружать его нужно выборочно.

Запомни эти 30–40%. Ровно они и есть цена передачи. Дальше — что происходит, когда передач в системе не одна, а четыре подряд.

Главный контр-кейс: почему ZS убили четырёхагентный пайплайн

Что произошло: мультиагентный пайплайн выдавал связный по форме, бессвязный по сути результат

• Кто: ZS Associates, фарма-аналитика для крупных клиентов (доклад «Why We Killed Our Multi-Agent Pipeline», AI Engineer).
• Что делали: скопировали работу живого аналитика в топологию агентов — агент детекции сигналов, агент локализации источника, агент атрибуции драйверов, агент синтеза и оркестратор поверх.
• Результат: на выходе пакет выглядел прилично. Сигнал определён верно (падение назначений на 18% за 4 недели), причина найдена верно (страховщик перевёл препарат в худший тариф) — а рекомендованное действие мимо (отправить больше торговых представителей), и прогноз следом неверный. Ни один агент не владел картиной целиком.
• Вывод: три причины провала по их же разбору — LLM выполняла детерминированную работу; контекст терялся на каждом хендоффе; не было общего доменного знания. Пайплайн убили и пересобрали.

Разберём механику потери, потому что она универсальна и не зависит от домена.

Первое. Хендофф — это компрессия без критерия. Агент передаёт вниз текстовое резюме состояния и физически не может знать, что понадобится потребителю ниже по цепочке: тот ещё не начал думать. У ZS агент локализации источника знал, что дело в тарифной сетке страховщика, — но резюмировал это как «источник: страховщик», и следующий агент работал уже с ярлыком вместо факта. Действие «отправить представителей» логично для ярлыка и абсурдно для факта «препарат переведён в худший тариф».

Второе. Потеря не сигнализируется. Carly Richmond (Elastic, NDC Conferences) описывает это как отдельный класс отказов: если вывод агента 1 нужен агенту 3 и не передан, ломается результат всей цепочки. Ошибка при этом не выглядит как ошибка — никто не падает, ничего не переполняется. «Слишком хорошая» изоляция просто режет нужные связи.

Третье. Каждый следующий агент достраивает недостающее правдоподобным. Модель оставленную дыру заполняет домыслом. Поэтому четыре хендоффа дают гладкий текст, где пробелы заклеены, вместо результата с четырьмя видимыми пробелами. Это и есть «связный по форме, бессвязный по сути»: увидеть дефект можно, только зная предметную область, — по форме претензий нет.

Dex Horthy (HumanLayer, YC Root Access) называет это испорченным телефоном и делает операционный вывод: значение имеет только то, что суб-агент вернул, — поэтому промптить надо родителя, объясняя ему, как промптить ребёнка о формате ответа. И добавляет: детерминированные системы уже хаотичны, недетерминированные тем более.

Рабочее правило: рассуждение не делится

Как ZS пересобрали систему: консолидировали всё рассуждение в одного агента. Параллелизм оставили — убрали именно распределённое суждение. Суб-агенты порождаются динамически под узкую задачу расследования (например, активность представителей в конкретном регионе) и возвращают результаты, но не рассуждение и не решение. Архитектура стала легче исходной, а хендоффов, на которых терялся контекст, просто не стало.

Формулировка, которую стоит унести целиком: один агент владеет рассуждением, суб-агенты возвращают результат, а не суждение.

К той же топологии пришли эмпирически и другие. Cognition дали Devin'у MCP, чтобы он произвольно писал другим Devin'ам и создавал новых, — получился, по словам Walden Yan (LatentSpace), «хаотичный мир». В практике осталась схема «один агент сегментирует работу и раздаёт её изолированным агентам, у каждого своя машина, машины не разделяются». Эксперименты Cursor, по его же наблюдению, пришли ровно к тому же виду.

Он же даёт трезвую проверочную рамку: «это вообще мультиагентность или просто вызов инструмента?» Большинство «мультиагентных» кейсов — суб-агент, посланный найти файл или реализацию. Вся ценность в том, что его tool calls и токены схлопываются в один ответ для главного агента (так у Cognition устроен вызов DeepWiki). Это управление контекстом, сотрудничества агентов здесь нет.

Единственное принципиальное исключение из правила «не делить суждение» — независимая проверка. JetBrains («How AI Agents Work») отделяют evaluator от исполнителя намеренно: у того, кто только что написал код, есть все основания считать его хорошим, у независимой проверки таких оснований нет. Но обрати внимание на характер суждения: checker судит о факте завершения по бинарному критерию и не выносит суждений о предметной области.

Метод ZS: посадить агента в пустую папку и смотреть

Отдельно стоит забрать не вывод ZS, а способ его получить. Они посадили кодового агента в пустую папку, дали bash и доступ к базе, поставили реальную задачу — и просто смотрели: какие запросы он пишет, куда лезет первым делом, где спотыкается. Фиксы вывели из наблюдения, отбросив представления о том, как «должен» работать аналитик.

Это решает исходную ошибку в корне. Главный вывод ZS: архитектура должна выводиться из задачи, без человеческих и организационных ограничений, внесённых сверху. Разбиение по шагам живого аналитика выглядело логично, и именно оно создало точки потери контекста.

Метод переносится дословно. Leonie Monigatti (Elastic, «Agentic Search for Context Engineering») три дня логировала exec-инструмент своего агента, а потом спросила самого агента, какие паттерны он видит, — и получила рекомендации, какие специализированные search-инструменты стоит реализовать. Её порог тревоги: 4–5 вызовов инструмента на один вопрос — признак, что инструмент слишком сложен для агента.

Дешёвая версия для маленькой команды: пустая папка, bash, реальные данные, один прогон, полный лог. Смотреть при этом стоит на траекторию, а не на результат.

Границы: где многоагентность оправдана, а где это распил одного контекста

Оправдана, когда суб-агент возвращает факт или артефакт, а не мнение:

• поиск и локализация — «найди, где именно происходит событие и как данные текут между компонентами» (Dex Horthy), вызов DeepWiki (Cognition);
• работа с тяжёлыми данными — сотни спанов в трейсе остаются внизу, наверх идёт результат (Arize);
• фазовое разбиение с коротким дайджестом наверх — reader извлекает факты, scorer применяет политику, writer собирает итог (Google Cloud, «Context engineering explained»);
• независимая проверка условия завершения (JetBrains);
• объём, который физически не влезает в одно окно (Anthropic, LangChain);
• разная экспертиза. Ragunath Jawahar (Developer Summit): суб-агент для security review работает принципиально по-разному в зависимости от жаргона в системном промпте, поэтому писать этот промпт стоит вместе с профильным экспертом команды — так активируется нужный регион знаний модели.

Не оправдана — и обычно это просто способ распилить один контекст на несколько испорченных:

• роли скопированы с оргструктуры: «продакт-менеджер, дата-сайентист и фронтендер» (Dex Horthy). Суб-агенты существуют ради контроля контекста, роли здесь ни при чём;
• суждение распределено по цепочке — случай ZS;
• детерминированную работу отдали LLM. ZS вынесли детекцию сигналов в детерминированный пайплайн со статистикой, гардрейлами, порогами и приоритизацией: он кладёт сигнал в очередь, агент просыпается на готовый. До этого модель то применяла статистику, то на глаз объявляла сигналом шум. Формула — работа агента расследовать, а не обнаруживать;
• ты не удерживаешь «core four» (контекст, модель, промпт, инструменты) каждого агента. IndyDevDan: если теряешь из виду контекст даже одного агента — ты ещё не готов к суб-агентам.

И рамка сверху, объясняющая, почему всё это раз за разом сходится к схеме «менеджер и изолированные исполнители». Danielle Perszyk (Amazon AGI Lab, LatentSpace) наблюдает мультиагентные системы на открытых харнессах: со стороны похоже на человеческое взаимодействие, но при росте масштаба видно, что ничего долговременного не остаётся — нет накопительной культуры, агенты фактически не влияют друг на друга. Практических рецептов отсюда пока нет, но вывод для проектирования есть: пока между агентами ничего не накапливается, любая топология сложнее «один рассуждает — остальные приносят» — это просто больше стыков, на которых теряется контекст.

Что с этим делать

Делегируй чтение и поиск, не делегируй вывод. Суб-агент возвращает факт, файл, дайджест, число. Интерпретация и решение остаются у одного агента.

Пропиши формат возврата в промпте родителя, того, кто запускает ребёнка (Dex Horthy). Значение имеет только то, что вернулось.

Замеряй экономию. /context до и после делегирования: 19% и 19% (David Mahler) — так выглядит работающая изоляция. Если окно родителя растёт вместе с работой ребёнка, изоляции нет.

Заведи бандлы контекста до того, как окно взорвётся. Хуки пишут лог вызовов, новый инстанс поднимается из него и восстанавливает 60–70%. Содержимое чтений не логируй — утопишь следующего агента.

Перед разбиением на агентов вынеси наружу всё детерминированное. Пороги, статистика, приоритизация, SQL — это пайплайн, а не агент. Агент просыпается на готовый сигнал.

Проектируй от задачи. Прежде чем рисовать топологию, посади одного агента в пустую папку с bash и данными и посмотри, что он делает. Архитектуру выводи из лога.