Почти в каждом агентном проекте наступает момент, когда кто-то рисует на доске второй прямоугольник. Роутер. «Planner agent». Billing-агент, shipping-агент, compliance-агент. Это выглядит как хорошая архитектура, потому что выглядит как диаграмма микросервисов — а мы все десятилетие учились тому, что маленькие сфокусированные сервисы лучше большого кома грязи.
Для агентов эта интуиция часто неверна. Не всегда, но достаточно часто, чтобы притормозить перед вторым прямоугольником.
В течение 2026 Anthropic опубликовал серию практических статей на эту тему, и вместе они рассказывают согласованную историю. Последняя из них, Building agents: when to fold subagents into your main agent loop (октябрь 2026), заходит дальше всех: она описывает enterprise-команды, получающие лучшие результаты, когда убирают роутеры, planners и доменные subagents. Этот пост — мой синтез: когда несколько агентов помогают, какие паттерны координации подходят для каких задач, почему маятник качается обратно к одному циклу, где подходит advisor/executor, и фреймворк решений. Компромиссы идут от того, как устроены контекстные окна, а не от какого-то одного фреймворка, так что они применимы, используете ли вы Claude Agent SDK, LangGraph или самописный цикл.
Реальная цена второго агента
Начнём со счёта. Январская статья Anthropic 2026 оценивает типичный overhead multi-agent в 3–10 раз больше токенов, чем у одного агента на эквивалентной задаче. Причины банальны: дублирование контекста в разных окнах, координационные сообщения, не дающие пользователю ничего, и суммаризация на каждой передаче.
Последнее болит сильнее всего, и не из-за токенов. Каждая передача lossy: детали, казавшиеся неважными на первом hop, важны на третьем, а к тому моменту их уже нет. Та же статья описывает эксперимент с агентами planner, implementer, tester и reviewer, где subagents тратили на координацию больше токенов, чем на работу.
Latency — второй сюрприз. Параллелизм ускоряет отдельные подзадачи, но суммарные вычисления растут, поэтому система в целом часто оказывается медленнее. Октябрьская статья приводит одного клиента, у которого single-agent цикл работал примерно вдвое быстрее multi-agent harness, который он заменил — одна точка данных, не закон, но направление, которого я бы ожидал.
Самая недооценённая цена — организационная. Когда каждая команда строит своего агента, а platform-команда надстраивает сверху оркестратор, получается то, что перечисляет октябрьская статья: пересекающиеся subagents без владельцев, системный промпт, сшитый из конфликтующих командных правил, и evals, которые каждая команда оптимизирует локально, пока никто не отвечает за сквозное качество. Архитектура зеркалит оргструктуру. Закон Конвея не перестал действовать, когда компонентами стали LLM.
Когда несколько агентов действительно помогают
Ничто из этого не значит «никогда не используйте subagents». Январская статья называет три ситуации, где разделение стабильно выигрывает, и почти любой законный multi-agent дизайн сводится к одной из них:
- Защита контекста. Подзадача производит много вывода, не относящегося к основной задаче (статья называет примерно 1000+ токенов как точку, где изоляция окупается). Subagent переваривает его и возвращает компактное summary; основное окно остаётся чистым.
- Параллелизация. По-настоящему независимые грани — несвязанные направления исследования, отдельные измерения ревью — выполняются в отдельных окнах одновременно. Источник описывает выгоду как тщательность, а не скорость.
- Специализация. Слишком много инструментов для надёжного выбора, конфликтующие домены инструментов или персоны, тянущие в противоположные стороны. Как мы увидим, теперь есть более дешёвые способы получить большую часть этого.
Плюс одно сквозное применение: верификация. Агент, получающий артефакт и критерии успеха, но не историю сборки, — по-настоящему независимая проверка.
Декомпозируйте по контексту, а не по должностям
Самая полезная идея во всей серии: разделяйте по границам контекста, а не по типам задач. Хорошие границы там, где через них должно пройти мало контекста — независимые пути исследования, чистые интерфейсы, black-box верификация. Плохие границы — последовательные фазы одной и той же работы, тесно связанные компоненты, всё, что требует общего состояния. Пример из статьи: агент, который строит фичу, должен и писать её тесты, потому что контекст у него уже есть. Отдельный «tester agent» — аккуратное разделение ролей, стоящее fidelity. Если вы занимались domain-driven design, это снова bounded contexts — только ограничиваете вы буквально контекстное окно.
Пять паттернов координации и чего каждый стоит
Когда вы решили, что вам правда нужно больше одного агента, апрельская статья 2026 про паттерны координации описывает пять форм. Вот моё сжатое прочтение с failure mode, за которым я бы следил в каждом.
| Паттерн | Форма | Используйте, когда | Остерегайтесь |
|---|---|---|---|
| Generator–verifier | Один агент производит, другой проверяет по критериям, цикл до принятия или лимита | Качество важно и критерии можно сформулировать явно | Verifier без конкретных критериев штампует всё подряд; циклы, которые осциллируют |
| Orchestrator–subagent | Ведущий агент планирует, делегирует ограниченные подзадачи, синтезирует результаты | Чёткая декомпозиция, низкая взаимозависимость | Ведущий становится информационным бутылочным горлышком; последовательные subagents стоят токенов multi-agent без ускорения |
| Agent teams | Постоянные воркеры берут задачи из общей очереди и накапливают контекст | Независимые долгие партиции (например, один сервис на воркера при миграции) | Конфликтующие правки общих ресурсов; неравномерное время завершения |
| Message bus | Агенты публикуют/подписываются на события через роутер | Событийно-управляемые workflow, растущая экосистема независимо деплоящихся агентов | Тихие сбои из-за неверно маршрутизированных событий; трудно трассируемые каскады |
| Shared state | Агенты читают и пишут в общее хранилище, без центрального координатора | Совместное исследование, где находки должны перетекать между агентами по ходу | Дублирование работы, реактивные циклы, которые не сходятся без явного условия завершения |
Три вещи бросаются в глаза при сравнении.
Orchestrator–subagent — вариант по умолчанию, если вам вообще нужно несколько агентов. Остальные — то, к чему вы эволюционируете, когда появляется конкретная боль: логика маршрутизации, копящаяся в оркестраторе, намекает на bus; воркеры, которым нужно помнить между циклами, намекают на teams; агенты, которым нужны промежуточные находки друг друга, намекают на shared state.
Каждому циклу нужно правило остановки, написанное до его запуска — максимальное число итераций плюс fallback для generator–verifier; бюджет времени или «нет новых находок N циклов» для shared state. Блокировки решают параллельную запись; они не мешают двум агентам вежливо задавать друг другу уточняющие вопросы вечно.
Верификация хороша лишь настолько, насколько хороши её критерии. Январская статья описывает сбой «ранней победы»: verifier запускает два теста, видит зелёное, объявляет успех. Починка скучная: явно требовать полный сьют, негативные тесты и граничные случаи.
Мартовская статья про workflow-паттерны (последовательные, параллельные, evaluator-optimizer пайплайны с путём, зафиксированным в коде) добавляет совет, на котором держится всё здесь: сначала попробуйте один вызов и добавляйте структуру только там, где он наглядно не справляется.
Маятник качается обратно: один цикл, progressive disclosure
Вот где октябрьское руководство становится интересным. Многие enterprise-внедрения улучшились, свернув роутеры, planners и доменные subagents в один цикл; один агент со skills часто побеждал и дизайны с одним промптом, и дизайны с subagents по качеству, нередко при меньшей стоимости и latency. Отчасти причина в возможностях: новые модели берут на себя намного больше принятия решений, поэтому логика может переезжать из harness в модель.
Целевая архитектура:
- Одна модель, одно контекстное окно, один открытый цикл инструментов, с бюджетами ходов, бюджетами стоимости и write gates в harness. Вызовы инструментов приходят пачками и выполняются параллельно.
- Планирование происходит внутри цикла. Модель планирует на первом ходу и пересматривает по мере поступления результатов — planner и executor это одна и та же модель, так что при передаче ничего не теряется.
- Доменная процедура переезжает в skills; жёсткие лимиты и живые lookup’ы — в tools. Детерминированный код по-прежнему обрабатывает дешёвую, всегда нужную работу вроде entity resolution.
Масштабироваться это позволяет благодаря progressive disclosure: агент видит короткие описания каждого skill и tool и загружает полное содержимое, только когда оно нужно задаче. Статья отмечает, что Anthropic сократил системный промпт Claude Code более чем на 80% для более продвинутых моделей, отчасти именно так. Апрельская статья про harness-дизайн утверждает то же с другой стороны: каждый предзагруженный токен конкурирует за внимание модели.
Инструменты получают то же обращение. Январский текст предполагает, что выбор инструмента усложняется около 15–20 tools; октябрьский наблюдает деградацию свыше примерно 30–50 определений. Оба рекомендуют tool search с отложенной загрузкой прежде, чем добавлять агентов, плюс инструменты, сгруппированные по намерению пользователя, а не по одному на endpoint, с per-user permissions, применяемыми внутри каждого tool.
Заметьте, что это делает с аргументом о специализации. Большую часть того, что предлагал специализированный subagent — сфокусированные инструкции, подобранный набор инструментов, — progressive disclosure теперь даёт внутри одного окна, без lossy передачи. В этом и состоит настоящий сдвиг.
Как сворачивать, ничего не сломав
Октябрьский путь миграции аккуратен так, как мне нравится:
- Сначала постройте сквозные evals — десяти golden examples достаточно для старта. Отслеживайте точность маршрутизации сейчас; после сворачивания отслеживайте, загрузил ли агент нужный skill или tool.
- Слейте тесно связанных специалистов — тех, что цепляются на вывод друг друга или обычно вызываются вместе.
- Вызывайте оставшихся subagents как tools, чтобы основной агент владел разговором и у вас был baseline.
- Сворачивайте по одному. Промпты становятся skills, вызовы API становятся tools. Смотрите, какие задачи изменились, а не только на агрегированный score.
Предостерегающий пример из статьи: сворачивание одного subagent в support-агента снизило latency, но сломало процесс — основной агент сам ответил на вопрос о дате доставки вместо того, чтобы обратиться к shipping-специалисту, причём лишь в одном из двух прогонов. Гоняйте каждую задачу несколько раз; как утверждает пост про evals, поведение агента — это распределение.
Меняется и владение: команды перестают владеть агентами и начинают владеть skills и tools, а небольшая центральная команда владеет системным промптом и сквозным качеством. И subagents по-прежнему оправдывают своё место, когда раздувание контекста портит цикл, параллельным задачам нужны свежие окна, или выбор инструмента и конфликтующие инструкции не по силам одному агенту.
Паттерн advisor/executor: интеллект по требованию
Есть и третья форма, которая плохо вписывается в «один агент против многих», и о ней стоит знать. Апрельская статья Anthropic 2026 про advisor strategy описывает пару из меньшей executor-модели, которая выполняет всю задачу от начала до конца, и большей advisor-модели, к которой она обращается только в трудных точках принятия решений. Advisor читает общий контекст и возвращает план, поправку или сигнал остановки. Он никогда не вызывает инструменты и никогда не говорит с пользователем.
Это переворачивает паттерн orchestrator: вместо большой модели, декомпозирующей работу для маленьких воркеров, маленькая модель ведёт и эскалирует вверх. Никакой декомпозиции, никакого пула воркеров, а frontier-рассуждение оплачивается только когда нужно.
Цифры, о которых сообщает Anthropic (внутренние evals, с оговорками о различающихся настройках thinking и промптах между прогонами): на SWE-bench Multilingual Sonnet с advisor Opus набрал на 2,7 пункта больше, чем Sonnet один, при стоимости на задачу ниже на 11,9%; на BrowseComp Haiku с advisor Opus достиг 41,2% против 19,7% в одиночку. Их совет правильный: прогоните eval на трёх конфигурациях — маленькая solo, маленькая плюс advisor, большая solo — и пусть решают цифры.
Концептуально мне нравится, что здесь сохраняются один контекст и один владелец задачи — ровно то, что защищает руководство по сворачиванию, — при добавлении второго мнения там, где это важно. Хочется построить planner-агента? Сначала попробуйте advisor. (Подробнее о стороне стоимости — в экономике токенов.)
Фреймворк решений
Вот таблица, которую я бы приклеил рядом с доской, прежде чем кто-то нарисует второй прямоугольник.
| Форма задачи | Рекомендуемая архитектура |
|---|---|
| Одна задача, свободно помещается в одно окно | Один агент, один вызов. Никакой оркестрации. |
| Широкий домен, много процедур, много инструментов | Один цикл агента со skills + tool search (progressive disclosure) |
| В основном рутинная работа с редкими трудными суждениями | Меньший executor + больший advisor |
| Подзадача производит большой, в основном нерелевантный вывод | Основной цикл + subagent для защиты контекста, возвращающий summary |
| По-настоящему независимые грани исследования или ревью | Orchestrator–subagent, явно распараллеленный |
| Вывод должен удовлетворять явным проверяемым критериям | Generator–verifier с лимитом итераций и fallback |
| Независимые долгие партиции (по одной на сервис) | Agent teams с разделёнными ресурсами |
| Событийно-управляемый пайплайн из независимо деплоящихся агентов | Message bus с correlation ID и evals на маршрутизацию |
| Агентам нужно строить на находках друг друга почти в реальном времени | Shared state с явным условием завершения |
Прежде чем принимать что-либо ниже третьей строки, задайте три вопроса, адаптированных из январского чек-листа: есть ли реальное ограничение (контекст, параллелизм или специализация, которые skills и tool search решить не могут)? Следует ли разделение за контекстом, а не за должностями? Есть ли чёткая точка верификации? Если хоть один ответ «нет», у вас задача для одного агента. «Так чище» — это не ограничение.
Где я бы был осторожен
- Это статьи вендора. Написаны Anthropic, про Claude, с цифрами из внутренних evals или отдельных клиентов. Паттерны переносимы; цифры — не прогноз для вашей нагрузки.
- «Часто» — не «всегда». Октябрьская статья говорит, что одиночные циклы часто выигрывают. Ваш случай может быть исключением — это скажет только сквозной сьют evals, прогнанный несколько раз на каждую конфигурацию.
- Пороги будут смещаться. Лимиты на число инструментов и контекстные пороги сдвигаются по мере улучшения моделей; статья про harness-дизайн показывает scaffolding, который нужен был одному поколению моделей и не нужен следующему. Перетестируйте при каждом апгрейде.
- Сворачивание переносит сложность, а не удаляет её. Одному циклу нужны дисциплинированный системный промпт, точные описания skills и tools и осознанное управление памятью. Это контекст-инжиниринг, и это настоящая работа.
- Один цикл — это один процесс, который может упасть. Checkpointing и идемпотентные инструменты важнее, когда нет оркестратора, перезапускающего подзадачи — см. durable execution для агентов.
Как я бы подошёл к существующей multi-agent системе
Если сегодня у вас роутер плюс дюжина специалистов, не переписывайте всё:
- Сначала постройте сквозной набор evals, с одним владельцем. Без него ничто другое небезопасно.
- Инструментируйте передачи — логируйте, что каждый агент получает и возвращает. Lossy границы проявляются быстро.
- Слейте пару, которую всегда вызывают вместе. Наименьший риск, самый ясный сигнал.
- Преобразуйте специалистов в skills и tools (MCP — разумный стандарт для стороны инструментов), по одному, перепрогоняя evals на каждом шаге.
- Оставьте то, что оправдывает своё место — и задокументируйте, какое из трёх ограничений оправдывает каждого уцелевшего subagent.
Карьерный угол
Соединить пять агентов фреймворком теперь легко, и это отчасти и есть проблема. Ценный навык — знать, когда не надо, и доказывать это evals. Это значит свободное владение тем, что переживёт любую модель: проектированием границ контекста, написанием описаний skills и tools, которые модель выбирает надёжно, построением evals, ловящих регрессии процесса, и рассуждением о бюджетах токенов и latency. Инженер, который может взглянуть на диаграмму из двенадцати прямоугольников и сказать «это три прямоугольника, и вот eval», будет востребован надолго. Приходите из enterprise backend? См. от C# к агентам Claude.
Углубляясь
Claude Agent SDK hands-on проходит цикл агента, subagents, skills и дизайн tools. Building LLM-Powered Apps: RAG & Agents разбирает паттерны независимо от фреймворков. Claude API охватывает строительные блоки — tool use, caching, контроль стоимости. MCP Servers — про превращение доменных API в инструменты, сгруппированные по намерению. А Claude Code Mastery показывает продакшен single-loop агента с progressive disclosure со стороны пользователя.
Источники: Anthropic, Building agents: When to fold subagents into your main agent loop (октябрь 2026); Multi-agent coordination patterns: Five approaches and when to use them (апрель 2026); Building multi-agent systems: When and how to use them (январь 2026); Common workflow patterns for AI agents and when to use them (март 2026); The advisor strategy (апрель 2026); Harnessing Claude’s intelligence (апрель 2026). Этот пост — независимый комментарий; цифры приведены так, как их сообщают источники. Связанное в этой серии: контекст-инжиниринг, evals, экономика токенов, durable execution, AI-native SDLC.
