Есть ощущение, что мы сейчас живём в странный период: 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 частей):

Почему многоагентные системы ломаются (эта статья)
Advisory-first и уровни зрелости: от “советов” до “действий”
Контракт результата: Артефакт + Доказательства + Метрика + Статус
Sandbox-first и bounded loop: как не выпускать хаос наружу
Deny-by-default: политики, права, гейты доступа к инструментам
Метрики полезности и kill-switch: когда агента надо выключать
Кейс дрейфа агента (обезличено): как система “уплывает” и почему
Стая как завод: Intake → Context → Patch → Checks → Apply → Audit

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

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

У вас стая ломается чаще из-за качества решений (галлюцинации/контекст) или из-за операционки (инструменты/деплой/повторы)?
Что для вас страшнее: неправильное действие или невозможность доказать, что действие правильное?
Если вы уже делали многоагентку: какая самая дорогая ошибка была — и почему она прошла “незамеченной”?

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

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