Формат: Мнение
Коротко
В статье, переведенной и адаптированной с английского источника InfoWorld, автор сравнивает нынешний ажиотаж вокруг мультиагентных ИИ-систем с эпохой микросервисов. Главная мысль: распределять сложность нужно только тогда, когда у проблемы действительно есть смысл для распределения — иначе многoагентность лишь добавляет накладные расходы.
Ключевые тезисы
- Крупные вендоры ИИ советуют начинать с максимально простого решения: одной модели, retrieval и инструментов, а не с множества агентов.
- Роли вроде planner, reviewer и executor не всегда требуют отдельных агентов — их часто можно реализовать одним агентом с разными режимами работы.
- Мультиагентные системы усложняют отладку, синхронизацию состояния, безопасность и наблюдаемость, а также увеличивают расход токенов.
- Прежде чем добавлять новых агентов, стоит улучшить retrieval, chunking, индексирование, reranking и структуру промптов.
- Мультиагентность оправдана только там, где задачи реально параллельны, разделены по доменам или требуют архитектурной изоляции.
Детали
Это перевод и адаптация материала InfoWorld с английского языка.
Автор статьи проводит прямую параллель между нынешней модой на мультиагентный ИИ и прошедшей волной увлечения микросервисами. И тогда, и сейчас разработчики рискуют принять полезный паттерн за универсальную архитектуру будущего, хотя на практике он оправдан далеко не везде.
Реальный паттерн, но с налогом на сложность
Даже компании, создающие передовые модели, советуют не злоупотреблять агентными системами. Anthropic в своем руководстве прямо рекомендует искать «самое простое возможное решение» и отмечает, что во многих случаях достаточно одной LLM-вызова с retrieval и примерами в контексте.
Anthropic также предупреждает, что фреймворки могут создавать лишние слои абстракции, скрывать промпты и ответы, усложнять отладку и провоцировать добавление ненужной сложности. Santiago Valdarrama формулирует это еще жестче: «Не все является агентом», а в 99% случаев нужен обычный код.
Похожей позиции придерживается OpenAI. В его практическом руководстве рекомендуется сначала максимально раскрыть возможности одного агента, потому что связка «один агент + инструменты» делает систему проще в оценке, поддержке и сопровождении.
Microsoft тоже советует начинать с прототипа на одном агенте, если задача не требует явного разделения по границам безопасности, комплаенса или команд. Даже роли «planner», «reviewer» и «executor» не обязательно означают несколько агентов: один агент может имитировать их через смену персоны, условные промпты и разграничение прав на инструменты.
Google добавляет важную деталь: неверный выбор между субагентом и агентом, оформленным как инструмент, может создать огромные накладные расходы. Иными словами, иногда вам не нужен новый «член команды» — вам нужна функция с четким контрактом.
Распределенный интеллект все равно остается распределенной системой
То, что могло бы решаться одним сильным вызовом модели, retrieval и несколькими аккуратно спроектированными инструментами, быстро превращается в маршрутизацию агентов, передачу контекста, арбитраж, настройку прав доступа и наблюдаемость в наборе вероятностных компонентов.
OpenAI предупреждает, что triage и hand-off в мультиагентных системах добавляют новый источник недетерминизма. В документации Codex говорится, что subagents не включаются автоматически и должны использоваться только при явном запросе на параллельную работу агентов, потому что каждый subagent потребляет дополнительные токены.
Microsoft формулирует это в корпоративных терминах: каждая агентная интеракция требует проектирования протоколов, обработки ошибок, синхронизации состояния, отдельной настройки промптов, мониторинга, отладки и расширения поверхности безопасности.
Вывод автора прост: модульность полезна, но не стоит делать вид, что она бесплатна.
Сначала чините базовую архитектуру
По мнению автора, многие команды, которым кажется, что им нужны несколько агентов, на самом деле сталкиваются с другой проблемой. Их инструменты слишком размыты, retrieval работает слабо, права доступа слишком широкие, а репозитории плохо задокументированы.
Добавление новых агентов не решает ни одну из этих проблем — напротив, оно их усугубляет. Anthropic подчеркивает, что наиболее успешные внедрения опираются на простые, компонуемые паттерны, а во многих задачах достаточно одного вызова LLM с retrieval и примерами в контексте.
Автор отдельно отмечает, что ИИ делает сложность дешевой. В эпоху микросервисов плохая архитектурная идея хотя бы сдерживалась трудозатратами на реализацию, а сейчас стоимость создания очередного orchestration layer, новой персоны или очередного hand-off быстро падает.
Это кажется удобным, но одновременно ухудшает долгосрочную управляемость систем. Дешевле произвести fragility в масштабе, чем потом исправлять ее.
Заслужите лишние подвижные части
Отдельный акцент автор делает на hyperscaler-подходе: если Google, Amazon, Anthropic или OpenAI что-то используют, это не значит, что так же стоит делать всем остальным. У них просто другие проблемы и другой масштаб.
На примере исследовательской системы Anthropic видно, что мультиагентность оправдана там, где задача действительно широкая, открытая и требует параллельного поиска. При этом сама Anthropic честно указывает на цену: агенты использовали примерно в четыре раза больше токенов, чем обычные чат-взаимодействия, а мультиагентные системы — примерно в 15 раз больше.
Кроме того, компания замечает, что большинство задач программирования плохо подходят для такого подхода, потому что в них меньше реально параллелизуемых подзадач, а координация агентов в реальном времени пока далека от идеала.
Отсюда практический совет: сначала начните с сильного вызова модели. Если этого мало — добавьте retrieval. Если и этого недостаточно — расширьте инструменты. Если нужен цикл итераций — оберните инструменты в один агентный loop. И только если есть реальная необходимость в параллельной работе, изоляции или специализации, «заслужите» второго агента.
Итоговая мысль статьи такова: мультиагентный ИИ действительно похож на микросервисы. Это одновременно и комплимент, и предупреждение. В enterprise-среде выигрывают не те, кто первым выбирает самую эффектную топологию, а те, кто дисциплинированно добавляет сложность только тогда, когда она действительно необходима.
Оригинал: Multi-agent AI is the new microservices