Почему многоагентные системы ломаются (и почему это нормально)

Есть ощущение, что мы сейчас живём в странный период: LLM-агенты уже умеют “делать работу”, но ещё не умеют быть предсказуемыми.

На демке всё выглядит идеально:
— один агент пишет код,
— второй — тесты,
— третий — делает ревью,
— четвёртый — собирает артефакты и отчёт,
— пятый — “оператор”, который всё это оркестрирует.

Первые пару запусков ты сидишь и думаешь: “Ну всё. Завтра индустрия будет другой”.
На третьем запуске агент уверенно сообщает: “Я исправил проблему”, и одновременно:

• аккуратно удаляет половину нужных миграций,

• “чуть-чуть” меняет контракт API,

• и оставляет в логике дыру размером с грузовик.

И вот тут начинается самое интересное: система не “плохая”. Она просто… ведёт себя как стажёр с турбонаддувом.

Эта статья — старт цикла про многоагентные системы. Я хочу честно, без магии, разобрать: почему они ломаются, и какие инженерные принципы делают их ближе к “заводу”, а не к “лотерее”.

Что такое многоагентная система

Многоагентная система — это несколько автономных “исполнителей” (агентов), которые:

• имеют роли (Dev / QA / Reviewer / Ops / Analyst),

• получают задачи,

• используют инструменты (репозиторий, тесты, API, БД, браузер, файловую систему),

• обмениваются результатами между собой,

• и в идеале приближают систему к цели.

Звучит круто. Ломается тоже круто.

Главная причина поломок: мы путаем “умение говорить” с “умением работать”

LLM очень хорошо:

• объясняет,

• делает правдоподобные планы,

• пишет код, который выглядит как код,

• и уверенно звучит.

Но многоагентная система — это не текст. Это динамика: состояние, побочные эффекты, дедлайны, ошибки, повторы, непредвиденные ситуации.

В итоге ломается не “мозг”. Ломается контур управления.

10 типовых причин, почему “стая” разваливается

1) Размытая цель (DoD не определён)

Если у задачи нет чёткого Definition of Done (“что считаем готово”), агент оптимизирует то, что проще:

• “сделал красиво” вместо “работает”

• “прошёл один кейс” вместо “не регресснуло”

• “ответил уверенно” вместо “проверил”

Симптом: результаты выглядят разумно, но в проде — сюрпризы.

2) Проверки отсутствуют или слабые — и правда не имеет голоса

Если нет тестов/смоуков/валидаций — система живёт в режиме:
“мне кажется, всё ок”.

В одиночной работе это опасно. В многоагентной — смертельно, потому что агенты начинают усиливать самообман друг друга.

3) Контекст загрязняется

Агентам нужно “помнить”, но память часто превращается в свалку:

• устаревшие факты

• противоречивые решения

• “мы вроде договорились, но уже нет”

• куски логов без источника

Симптом: агенты спорят не с реальностью, а с тем, кто громче “помнит”.

4) Петли обратной связи превращаются в автогипноз

Классика: агент A написал вывод, агент B принял его как факт, агент C подтвердил, агент D “закрыл тикет”.

Это выглядит как командная работа, но иногда это просто эхо-камера.

5) Инструменты имеют побочные эффекты

Агенты любят “сделать быстро”. Инструменты любят “делать по-настоящему”.

Если агент может:

• применить миграции,

• удалить файл,

• развернуть деплой,

• поменять конфиг,

то одна неверная гипотеза превращается в реальное действие.
А “откат” часто сложнее “накат”.

6) Невоспроизводимость (non-determinism)

Температура, разные версии зависимостей, сетевые таймауты, порядок задач — и вот у тебя баг, который:

• вчера был,

• сегодня нет,

• завтра снова будет,

• а объяснение у всех разное.

Симптом: система не отлаживается, потому что нет стабильного “повторить”.

7) Идемпотентность отсутствует

Агенты часто повторяют шаги (по делу: ретраи, перезапуски).
Если действия не идемпотентны, появляются:

• дубли сущностей,

• двойные списания,

• повторные уведомления,

• “раздувание” БД.

8) Метрики нет → нет тормозов

Если система не измеряет:

• стоимость (время/деньги),

• качество (ошибки/регрессии),

• полезность (доставлено/принято),
  то она не понимает, что “плохо”.

И продолжает работать, потому что “работать” — единственное, что она умеет.

9) Безопасность и инъекции

Любой вход (письмо, веб-страница, документ) может “подсунуть” агенту инструкцию:

• украсть данные

• сломать логику

• “сделать вид, что проверил”

Если нет deny-by-default, это вопрос времени.

10) Мы ждём от стаи поведения команды, но не строим процесс команды

Агенты не обладают человеческими механизмами:

• ответственности,

• осторожности,

• “стоп, надо уточнить”.

Зато у них есть скорость, уверенность и желание завершить задачу.

Важный вывод

Многоагентные системы ломаются не потому, что “LLM глупые”.
Они ломаются потому, что мы ещё не привыкли строить для них инженерные рельсы: гейты, инварианты, доказательства, ограниченные контуры действий.

Что дальше: цикл статей про многоагентные системы

Если аудитории зайдёт — я продолжу цикл. План такой (8 частей):

1. Почему многоагентные системы ломаются (эта статья)

2. Advisory-first и уровни зрелости: от “советов” до “действий”

3. Контракт результата: Артефакт + Доказательства + Метрика + Статус

4. Sandbox-first и bounded loop: как не выпускать хаос наружу

5. Deny-by-default: политики, права, гейты доступа к инструментам

6. Метрики полезности и kill-switch: когда агента надо выключать

7. Кейс дрейфа агента (обезличено): как система “уплывает” и почему

8. Стая как завод: Intake → Context → Patch → Checks → Apply → Audit

Хочу что бы статьи были максимально полезными и интересными

Мне важно понять, где у вас болит сильнее всего.

1. У вас стая ломается чаще из-за качества решений (галлюцинации/контекст) или из-за операционки (инструменты/деплой/повторы)?

2. Что для вас страшнее: неправильное действие или невозможность доказать, что действие правильное?

3. Если вы уже делали многоагентку: какая самая дорогая ошибка была — и почему она прошла “незамеченной”?

Я в следующих статьях хочу опираться не на фантазии, а на реальные истории.