Вот, пожалуй, главный вопрос, который возникает, когда начинаешь всерьёз разбираться в мультиагентных системах. Сначала всё выглядит красиво: — один агент анализирует запрос; — второй ищет информацию; — третий проверяет результат; — четвёртый принимает решение; — пятый вызывает инструменты… А потом ты понимаешь, что построил не «умную систему», а распределённый backend, где некоторые сервисы ещё и разговаривают с тобой естественным языком. 😂 И тут выясняется простая вещь: Главная проблема мультиагентной системы — не заставить агентов быть умными. Главная проблема — заставить их не мешать друг другу. Кто имеет право принимать решение? Кто может вызвать конкретный инструмент? Кто отвечает за состояние процесса? Что происходит, если агент ошибся? Что делать, если два агента приняли противоречащие решения? Когда нужно остановиться? Сколько денег можно потратить на один запрос? И самое интересное — кто вообще главный? Поэтому хорошая мультиагентная архитектура всё больше напоминает обычную инженерную систему: Decision → Policy → Agent → Tool → Result → State → Decision А вокруг этого появляются Guard, Runtime, Memory, Observability, Retry, Timeout, Cost Control и прочие вещи, которые мы, backend-разработчики, почему-то уже где-то видели. 😏 И постепенно приходит понимание: LLM — это не архитектура. LLM — это всего лишь один из компонентов архитектуры. А настоящая инженерная задача — построить систему, в которой даже десять достаточно умных агентов не смогут коллективно устроить распределённый бардак.