Как субагенты и многоагентные системы делят работу и токены стоимости.
Подагенты против многогранных систем: концепция оркестратора и рабочих элементов, четыре топологии, стоимость использования каждой в токенах, а также случаи, когда один агент работает эффективнее.
Источники: Subagents vs. Multi-Agent Systems: The Complete Guide to How AI Agents Actually Work Together
Почему один агент достигает своего предела
Каждый, кто смотрел, как работают Claude Code, LangGraph или функция исследований Claude, видел момент, когда ассистент перестаёт отвечать самостоятельно и обращается за помощью. Появляется помощник для поиска файлов, он их изучает и возвращается с результатами. Вопрос для исследования бесшумно изучает десяток источников за то время, за которое человек открывает две вкладки. Модель не стала внезапно умнее — эту работу выполняет небольшая команда.
Ниже приведён простой обзор того, как формируется такая командная работа, включая сабагентов, многогранные системы агентов, их основную архитектуру и стоимость их использования.
Один агент, то есть одна модель, работающая в цикле с инструментами, тоже способен к выполнению задач. Он может читать файлы, искать информацию в интернете, писать код и рассуждать на протяжении множества шагов. Однако в его конструкции заложены три ограничения:
- Одно окно контекста. Всё, что агент читает, обдумывает и делает, скапливается в одном пространстве. При длительных исследовательских задачах результаты работы инструментов со временем вытесняют первоначальный вопрос на второй план.
- Одна линия выполнения. Работа происходит последовательно. Пятьдесят поисков по два секунды каждый занимают более девяноста секунд, прежде чем начнётся какая-либо запись.
- Одна точка зрения. Один запрос определяет каждое решение, поэтому агенту трудно одновременно рассматривать два противоположных подхода или выявлять собственные слабые места.
Подагенты и многогранные агентные системы — это два решения этой проблемы, которые часто используются вместе. Далее рассматривается, что такое каждый из них, как они создаются и когда они окупают себя.
Что такое подагент
Подагент — это помощник с узким кругом задач, запускаемый в рамках одной сессии. Он выполняет одну конкретную задачу в собственном окне контекста, а затем сообщает о результатах.
Хорошим примером является Claude Code. Если основная сессия программирования должна разобраться с незнакомой частью кодовой базы, она может передать эту задачу подагенту, тем самым освободив основной диалог. Подагент:
- начинает работу с чистым, свежим окном контекста
- обычно использует меньший, ограниченный набор инструментов
- выполняет собственный цикл чтения, поиска и обработки информации
- отправляет краткое резюме в родительскую сессию, сохраняя полный текст для себя
Здесь речь идет о изоляции, а не о дополнительной интеллектуальной способности. Основной диалог не видит пятидесяти файлов, открытых вспомогательным элементом, а только три важных предложения, поэтому основной поток остается четким на протяжении длительной сессии и не заполняется шумом.
Несколько особенностей определяют эту модель в тех инструментах, таких как Claude Code, где она реализована:
- Подагенты существуют внутри одной сессии. Они представляют собой способ делегирования задач, а не отдельные запущенные процессы.
- Как правило, они не могут запускать собственных подагентов, что делает иерархию плоской и легкой для понимания.
- Определение подагента записывается один раз и используется повторно. Если предоставить рецензенту-подагенту фиксированный системный промпт и короткий список инструментов, он будет вести себя одинаково при каждом вызове.
Что такое многопроцессорная система
Многопроцессорная система имеет иной формат. Несколько независимых агентов, каждый из которых обладает собственным контекстом, собственными инструментами и иногда собственной моделью, стремятся к общей цели, обычно в более длительном или сложном процессе, чем при делегировании задачи в рамках одной сессии.
Наиболее известным публичным примером является функция исследований от Anthropic. На общий вопрос не даётся прямой ответ. Вместо этого ведущий агент разрабатывает подход и создаёт несколько подагентов, каждый из которых исследует разный аспект одновременно. Их результаты объединяются, проверяется точность цитирования, и в итоге возвращается единый ответ.
В совокупности ведущий агент, специалисты-параллелисты и этап окончательной синтезации образуют схему, которую сегодня используют большинство производственных многопроцессных систем, и именно такая конструкция рассматривается далее в этой статье.
В чём различия между двумя подходами
В интернете эти термины используются как синонимы, что приводит к путанице. Фактическое различие показано здесь.
Самый простой способ запомнить это: подагент — это техника, применяемая внутри агента, тогда как многопроцессная система — это архитектура, построенная на основе нескольких агентов. На практике многие многопроцессные системы создаются с использованием схемы подагента. Ведущий агент, использующий подагенты, одновременно является и тем, и другим.
Архитектура оркестратора и рабочих процессов
Почти каждая производственная многоподразделенческая система, включая функцию исследований от Anthropic, паттерн руководителя от LangGraph и модель субагентов от Claude Code, представляет собой вариант одной концепции: оркестратор и рабочие агенты.
У каждого компонента есть своя конкретная задача:
- Главный агент (оркестратор). Он читает запрос, разрабатывает стратегию и определяет, сколько усилий требует выполнение задачи. Это решение имеет большее значение, чем кажется. В ранних версиях таких систем иногда запускалось пятьдесят субагентов для вопроса, который требовал всего одного.
- Память или временная память. План записывается вне рамок диалога. Длительная работа агентов может превысить объем контекстного окна модели, и если это происходит на полпути, план должен сохраняться после обрезки данных и не исчезать вместе с ними.
На диаграмме используются два вида стрелок. Толстые стрелки указывают на выполнение задач вниз, а пунктирные — на передачу кратких результатов вверх. Такая асимметрия преднамеренна: подагенты возвращают обобщённый результат, а не всю историю своей работы, что предотвращает перегрузку контекста главного агента.
Порядок работы от вопроса к ответу
Если отойти от отдельных компонентов, то вот последовательность событий от введённого пользователем вопроса до готового ответа.
Несколько этапов заслуживают особого внимания:
- Этап 2 (размышление перед планированием) имеет большее значение, чем кажется. На этом этапе система определяет, сколько усилий требует запрос: для быстрой проверки фактов может потребоваться один агент и несколько вызовов инструментов, тогда как обширный вопрос может потребовать десяти или более подагентов с чётко распределёнными обязанностями.
- Шаг 7 (повторный цикл) отличает агентный систему от фиксированной цепочки обработки. Ничего не предусмотрено заранее: ведущий агент анализирует результаты и решает, ответить ли ему или продолжить поиск. Именно на этом этапе чаще всего возникают сбои. Агент, слишком неохотно возвращающийся к циклу, дает краткие ответы, а тот, кто слишком стремится к этому, тратит время и ресурсы в поисках источников, которых на самом деле нет.
- Шаги 8 и 9, где цитирование является отдельным этапом, существуют потому, что агент, которому поручено написать ответ и одновременно оценить источники, склонен делать уверенные заявления, которые не имеют оснований. Независимая вторая проверка помогает выявить это.
Четыре способа организации нескольких агентов
Типичной структурой являются оркестратор и рабочие агенты, но это не единственный вариант. В зависимости от того, как на самом деле делится задача, одна из четырех общих топологий будет более подходящей, чем остальные.
Когда неясно, что выбрать, команды по разработке обычно следуют простому правилу: для всего, что предназначено для внедрения в производство, использовать иерархию с руководителем, а для исследовательской работы, где поток данных невозможно заранее определить, применять сетевые или сетчатые структуры. Сетчатые схемы выглядят элегантно на диаграммах, но при этом они всегда самые сложные для отладки.
Почему это работает: экономика токенов
Важно точно определить, почему многокомпонентные системы превосходят однокомпонентные в решении определённых задач, ведь ответ не заключается в том, что «больше агентов означает больше интеллекта».
Во внутренних тестах компании Anthropic схема, при которой ведущей ролью выступает агент Claude Opus 4, а вспомогательными — Claude Sonnet 4, превзошла одиночного агента Claude Opus 4 на 90,2% в рамках внутреннего исследовательского теста. При анализе причин этого преимущества основную роль сыграла емкость системы. В тесте на сложные поисковые задачи только использование токенов объясняло около 80% различий в производительности, а количество вызовов инструментов и выбор модели покрывали оставшуюся часть различий.
Короче говоря, преимущество в выполнении задач, требующих обработки большого объема информации, в основном обусловлено емкостью системы. Разделение работы между несколькими окнами контекста предоставляет системе гораздо больше возможностей для рассуждений, чем одно окно, причем каждый вспомогательный агент сжимает прочитанное в краткий отчет.
Эта емкость не бесплатна. Данные производства показывают, что рабочие процессы с агентами потребляют примерно в четыре раза больше токенов, чем обычный чат, а многоагентные рабочие процессы — примерно в пятнадцать раз. Именно этот коэффициент должен определять, стоит ли вообще использовать такую архитектуру, что приводит к следующему пункту.
Когда многоагентная система — неподходящий инструмент
Большинство материалов об архитектуре агентов пропускают эту часть, но именно она помогает сэкономить время и бюджет на токены.
Задача должна делиться на действительно независимые части. Когда подзадачи сильно зависят друг от друга, их распределение между агентами увеличивает нагрузку на координацию и не приносит реального параллелизма. Отдельные исследовательские вопросы хорошо поддаются разделению, в то время как написание одной целостной функции обычно этого не делает.
Кодирование — самый яркий противопример. Само описание от компании Anthropic говорит о том, что в большинстве задач по кодированию меньше параллелизуемых подзадач, чем в исследовательской работе, а современные агенты пока не способны надежно координировать действия и передавать задачи друг другу в реальном времени. Другие тестовые методики подтверждают это. Одна академическая оценка показала, что многоагентные системы для кодирования потребляют в 4 раза больше токенов или даже более чем в 200 раз больше, чем аналогичный одноагентный подход, а отдельный анализ отрасли показал, что многоагентные системы выполняют строго последовательные задачи на 39–70 процентов хуже, чем одноагентные системы.
Ошибки распространяются. Ошибка в одном агенте остается отдельной ошибкой. Однако в координированной системе она может распространяться через передачу задач и усиливаться. Один анализ оценил усиление ошибок примерно в 4 раза при централизованной организации работы, а при независимой работе агентов без координации ситуация становится еще хуже.
Результат должен покрывать затраты. Благодаря коэффициенту умножения около 15 раз конфигурации с несколькими агентами подходят для работы высокой ценности и высокой сложности, такой как глубокие исследования, междисциплинарный анализ и крупномасштабные рефакторинги. Для любых задач, которые хорошо настроенный одиночный агент с надлежащими инструментами может выполнить за один проход, они являются чрезмерными.
Существует простой тест: если невозможно определить, какие функции будет выполнять каждый агент в отсутствие остальных, вероятно, решением будет усиление одиночного агента, а не добавление новых.
Уроки создания таких систем
Отчет Anthropic об их системе исследований является одним из самых откровенных публичных описаний того, что идет не так, когда рабочая демо-версия превращается в производственную систему с несколькими агентами. Самые важные уроки в кратком изложении:
- Инструкции являются основным инструментом управления. Поскольку именно они направляют действия каждого агента, небольшие изменения в формулировках, определяющих способ распределения задач между агентами, оказывают значительное влияние на то, будут ли субагенты дублировать друг друга или оставлять пробелы в работе.
- Размытые поручения приводят к дублированию усилий. Инструкция вроде «Исследуйте проблему нехватки полупроводников» кажется ясной, но на самом деле ею не является. В ранних системах несколько субагентов занимались одним и тем же вопросом, поскольку никто не указывал, где заканчивается одна задача. Хорошие инструкции указывают на цель, ожидаемый формат результата и границы компетенций каждого агента.
Минимальный обзор структуры
Ниже приведен упрощенный, независимый от конкретной платформы обзор механизмов координации и выполнения задач. Повторные попытки, потоковая обработка и постоянная память опущены, чтобы была видна структура логики; это также служит псевдокодом для портирования в LangGraph, Claude Agent SDK или простой цикл API.
def run_research(query: str) -> str:
# 1. Lead agent plans
plan = lead_agent.think_and_plan(query)
memory.save("plan", plan) # survives context truncation
findings = []
subtasks = plan.subtasks # explicit objective + boundaries per subtask
# 2. Spawn subagents in parallel, not sequentially
results = run_in_parallel([
subagent.execute(task=subtask, tools=subtask.allowed_tools)
for subtask in subtasks
])
findings.extend(results)
# 3. Lead agent decides: enough evidence, or loop again?
while not lead_agent.has_sufficient_evidence(findings):
new_subtasks = lead_agent.refine_plan(findings)
more_results = run_in_parallel([
subagent.execute(task=t, tools=t.allowed_tools)
for t in new_subtasks
])
findings.extend(more_results)
# 4. Synthesize, then verify citations in a separate pass
draft = lead_agent.synthesize(findings)
cited_answer = citation_agent.attach_citations(draft, findings)
return cited_answer
Два аспекта заслуживают наибольшего внимания, и ни один из них обычно не учитывается в примерах с игрушечными агентами. Первый — это run_in_parallel: последовательное вызов подагентов полностью снижает скорость выполнения. Второй — это явный цикл while для перепланирования, поскольку один фиксированный цикл работы подагентов не может адаптироваться, когда после первого прохода остается больше вопросов, чем ответов.
Проверки перед выпуском
Перед публикацией подагента или многоподагентной рабочей схемы проверьте следующее:
- У каждого подагента есть четко определенная цель, формат вывода и границы задачи, а не просто однострочная инструкция.
- Подагенты выполняются параллельно там, где они действительно независимы.
- План сохраняется в хранилище, а не только в ходе диалога, на случай сокращения контекста.
Связанная литература
- Когда два агента побеждают одного: копилот для ревью кода в LangGraph, работающий в обоих режимах — Создайте инструмент для ревью кода в виде отдельного агента, а затем в виде анализатора с модулем проверки рисков в LangGraph; после этого изучите три случая, когда использование многокомпонентных агентов оправдано с экономической точки зрения.
- Практические рекомендации: как стать одним из лучших 1% пользователей агентов Hermes: полное руководство — Подробное пошаговое руководство по практическим рекомендациям для пользователей агентов Hermes из числа лучших 1%: шаблоны контрактов, проверки и готовые фрагменты кода для команд, использующих эту модель.