Многоагентный ИИ — это новые микросервисы: почему не стоит усложнять архитектуру

by Мэтт Эсей

Пишущий автор

Многоагентный ИИ — это новые микросервисы
мнение
6 апр. 2026 7 мин

Многоагентные системы, как и микросервисы, могут быть мощными. Но большинство предприятий рискуют добавить распределенную сложность задолго до того, как у них появится проблема, которую действительно стоит распределять.

Похоже, мы просто не можем удержаться. Наша нынешняя увлеченность многоагентными системами рискует принять полезный шаблон за неизбежное будущее — точно так же, как когда-то мы поступили с микросервисами. Помните их? По вполне веским (и не очень) причинам мы брали работоспособные приложения, разбивали их на запутанное облако сервисов, а затем строили service mesh, стеки трассировки и платформенные команды, лишь бы управлять созданной нами сложностью. Да, микросервисы давали реальные преимущества, как я уже утверждал. Но также вам не нужно «работать как Google», если у вас нет проблем Google. (Спойлер: у вас их нет.)

Теперь мы собираемся повторить ту же ошибку с ИИ.

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

Так когда же стоит использовать многоагентный подход?

Реальный шаблон, но с налогом на хайп

Даже компании, создающие передовые модели, практически умоляют разработчиков не использовать их без разбора. В своем руководстве 2024 года по созданию эффективных агентов Anthropic прямо рекомендует искать «наиболее простое возможное решение» и говорит, что это может означать вообще не строить агентную систему. Более того, Anthropic утверждает, что для многих приложений обычно достаточно оптимизировать одиночные вызовы LLM с использованием retrieval и примеров в контексте. Компания также предупреждает, что фреймворки могут создавать уровни абстракции, которые скрывают промпты и ответы, усложняют отладку систем и подталкивают разработчиков к добавлению сложности там, где хватило бы более простого решения. Сантьяго Вальдаррама сформулировал ту же мысль еще жестче: «Не все является агентом», — подчеркивает он, — и «в 99% случаев вам нужен обычный код».

Это не антиагентный подход. Это инженерная дисциплина.

OpenAI приходит примерно к тому же выводу. Ее практическое руководство рекомендует сначала максимально раскрыть возможности одного агента, потому что один агент плюс инструменты делают сложность, оценку и сопровождение более управляемыми. В нем прямо предлагаются шаблоны промптов как способ поглотить сложность ветвления без перехода к многоагентному фреймворку. Microsoft также говорит прямо: если сценарий использования явно не пересекает границы безопасности или соответствия требованиям, не включает несколько команд и в целом не требует архитектурного разделения, начинайте с прототипа на одном агенте. Компания даже предупреждает, что роли «планировщик», «ревьюер» и «исполнитель» сами по себе не оправдывают наличие нескольких агентов, поскольку один агент часто может имитировать эти роли через смену персоны, условные промпты и настройку прав доступа к инструментам. Google, со своей стороны, добавляет здесь особенно полезный нюанс: неверный выбор между подагентом и агентом, упакованным как инструмент, может создать огромные накладные расходы. Иными словами, иногда вам не нужен еще один участник команды. Вам нужна функция с четким контрактом.

Microsoft делает еще один акцент, заслуживающий особого внимания: многие кажущиеся проблемы масштаба возникают из-за дизайна retrieval, а не из-за архитектуры. Поэтому прежде чем добавлять еще агентов, исправьте chunking, индексацию, reranking, структуру промптов и выбор контекста. Это не менее амбициозно. Это более взрослый подход. Мы усвоили этот урок на микросервисах. Сложность не исчезает, когда вы декомпозируете систему. Она перемещается. Тогда она уходила в сеть. Теперь она угрожает переместиться в передачи задач, промпты, арбитраж и состояние агента.

Распределенный интеллект все еще распределен

То, что могло быть одним сильным вызовом модели, retrieval и несколькими тщательно спроектированными инструментами, быстро превращается в маршрутизацию агентов, передачу контекста, арбитраж, настройку прав и наблюдаемость в рое вероятностных компонентов. Это может быть оправдано, когда проблема действительно распределенная, но часто это не так. Распределенный интеллект — это все равно распределенные системы, а распределенные системы недешево создавать и поддерживать.

Как предупреждает руководство OpenAI по оценке, триаж и передачи задач в многоагентных системах вносят новый источник недетерминизма. В документации Codex говорится, что подагенты не включаются автоматически и должны использоваться только тогда, когда вы явно запрашиваете параллельную работу агентов, в том числе потому, что каждый подагент сам выполняет работу модели и инструментов и, следовательно, расходует больше токенов, чем сопоставимый запуск с одним агентом. Microsoft формулирует ту же мысль на языке корпоративных систем: каждое взаимодействие с агентом требует проектирования протокола, обработки ошибок, синхронизации состояния, отдельного промпт-инжиниринга, мониторинга, отладки и более широкой поверхности безопасности.

Модульность — да. Но не делайте вид, что модульность будет дешевой.

Вот почему я подозреваю, что у большинства команд, которым кажется, что им нужны несколько агентов, на самом деле другая проблема. Их инструменты слишком расплывчаты, retrieval слабый, права слишком широкие, а репозитории недостаточно документированы. Угадайте что? Добавление новых агентов ничего из этого не исправляет. Оно только усугубляет ситуацию. Как объясняет Anthropic, наиболее успешные реализации обычно используют простые, компонуемые шаблоны, а не сложные фреймворки, и для многих приложений достаточно одного вызова LLM с retrieval и примерами в контексте.

Это особенно важно еще и потому, что ИИ делает сложность дешевой. В эпоху микросервисов плохая архитектурная идея хотя бы ограничивалась усилиями, необходимыми для ее реализации. В эпоху агентов стоимость набросать еще один уровень оркестрации, еще одну специализированную персону, еще одну передачу задачи или еще один фрагмент glue code резко падает. Это может казаться освобождающим, даже когда оно разрушает нашу способность поддерживать и управлять системами со временем. Как я уже писал, снижение производственных затрат не автоматически превращается в рост продуктивности. Чаще оно просто облегчает массовое производство хрупкости.

Заслужите дополнительные подвижные части

Это также возвращает нас к мысли, которую я годами повторяю применительно к архитектуре гиперскейлеров. То, что Google, Amazon, Anthropic или OpenAI делают что-то, не означает, что это должны делать и вы, потому что у вас нет их проблем. Исследовательская система Anthropic впечатляет именно потому, что она решает сложную, открыто-ended, широкую исследовательскую задачу с обходом в ширину. Anthropic также откровенно говорит о цене. По ее данным, агенты использовали примерно в четыре раза больше токенов, чем обычные чаты, а многоагентные системы — примерно в 15 раз больше. Компания также отмечает, что большинство задач по программированию не очень хорошо подходят, потому что в них меньше действительно параллелизуемых подзадач, а агенты пока не особенно хорошо умеют координировать друг друга в реальном времени.

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

Лучший вопрос звучит так: «Какова минимально жизнеспособная автономность для этой задачи?» Начните с сильного вызова модели. Если этого недостаточно, добавьте retrieval. Все еще недостаточно? Добавьте лучшие инструменты. Если нужна итерация, заверните эти инструменты в один агентный цикл. Если загрязнение контекста становится реальной проблемой, если независимые задачи действительно могут выполняться параллельно или если специализация заметно улучшает выбор инструмента, только тогда начинайте «заслуживать» второго агента. Если вы не можете сказать, какую из этих трех проблем решаете, вам, вероятно, не нужен еще один агент. Не верите мне? Все ведущие поставщики агентных инструментов (Anthropic, OpenAI, Microsoft, Google) сходятся в том же совете.

Так что да, многоагентность — это новые микросервисы. И это одновременно комплимент и предупреждение. Микросервисы были мощными, когда у вас была проблема, которую стоило распределять. Многоагентные системы мощны, когда у вас есть проблема, которую стоит декомпозировать. У большинства корпоративных команд такой задачи нет, по крайней мере пока. У многих ее не будет никогда. Вместо этого большинству нужен один хорошо инструментированный агент, жесткие права доступа, надежные оценки, скучные инструменты и четкие условия выхода. Команды, которые выигрывают с агентным ИИ, будут не теми, кто первым выбрал самую сложную топологию. Напротив, они будут достаточно дисциплинированны, чтобы заслужить каждую дополнительную подвижную часть, и будут изо всех сил избегать лишних подвижных частей как можно дольше. В корпоративной среде именно скучное по-прежнему масштабируется.

Искусственный интеллектМикросервисыCloud-NativeОблачные вычисленияIT-стратегияИТ-лидерство

Matt Asay

by
Мэтт Эсей

Пишущий автор

Подписаться на Мэтта Эсея в X
Подписаться на Мэтта Эсея в LinkedIn

Мэтт Эсей руководит направлением developer marketing в Oracle. Ранее Асей руководил developer relations в MongoDB, а до этого был Principal в Amazon Web Services и руководителем экосистемы разработчиков в Adobe. До Adobe Асей занимал ряд должностей в компаниях open source: вице-президент по развитию бизнеса, маркетингу и сообществу в MongoDB; вице-президент по развитию бизнеса в компании аналитики в реальном времени Nodeable (приобретена Appcelerator); вице-президент по развитию бизнеса и временный CEO в стартапе мобильного HTML5 Strobe (приобретен Facebook); COO в Canonical, компании Ubuntu Linux; и руководитель по Северной и Южной Америке в Alfresco, стартапе по управлению контентом. Асей — почетный член совета Open Source Initiative (OSI) и имеет степень JD Стэнфорда, где он специализировался на вопросах open source и других лицензий на интеллектуальную собственность. Мнения, выраженные в публикациях Мэтта, принадлежат Мэтту и не отражают точку зрения его работодателя.

Еще от этого автора

мнение

Резко неоднородная реальность внедрения ИИ в корпоративной среде

30 мар. 2026 7 мин
мнение

Хаос безопасности агентов

23 мар. 2026 6 мин
мнение

Как ИИ меняет open source

16 мар. 2026 7 мин
мнение

Программирование для агентов

9 мар. 2026 8 мин
мнение

ИИ снова делает сети важными

2 мар. 2026 7 мин
мнение

ИИ-агенты и плохие метрики продуктивности

23 фев. 2026 7 мин
мнение

Поиск ключа к control plane ИИ-агента

16 фев. 2026 8 мин
мнение

Убивает ли ИИ open source?

9 фев. 2026 8 мин