Разрыв между тем, что, по вашему мнению, делают ваши агенты, и тем, что они делают на самом деле, — главная причина закрытия ИИ-проектов. И дело вовсе не в технологиях. Это ваши отделы безопасности и юридический департамент «выдергивают вилку из розетки», как только понимают, что никто не может ответить на элементарные вопросы о том, что именно работает в их среде.
Несколько недель назад я задал аудитории инженеров простой вопрос: у кого прямо сейчас в продакшене работает ИИ-агент? Большинство подняли руки.
Затем я задал уточняющий вопрос: оставьте руку поднятой, если вы точно знаете, что этот агент делает в данную секунду. К каким данным он обращается? С кем он взаимодействует?
Почти все руки опустились.
Вот как я теперь смотрю на это: один агент — это научный эксперимент. Парк агентов — это обязательство. Большинство команд находятся где-то посередине, и слишком мало ИТ-департаментов задают правильные вопросы.
Бесконтрольное разрастание агентов начинается с одного. Потом пять. Потом десять. Маркетинг запускает одного для помощи с контентом. Финансовый отдел использует одного для сортировки отчетов о расходах. Операционный отдел — для внутренних рабочих процессов. По отдельности каждое из этих решений было разумным. Никто не садился и не решал намеренно создать что-то неуправляемое. Это просто накапливалось, по одному полезному агенту за раз…
Компания Retool опросила 307 технических директоров (CTO), ИТ-директоров (CIO) и директоров по информационной безопасности (CISO) в 2026 году и обнаружила, что лишь 5% из них были полностью уверены в том, что имеют полное представление о том, что работает в их производственных средах. И это касалось инструментов, созданных с помощью ИИ. А парки агентов накладываются поверх этого.
Сами агенты — не проблема. Тем не менее, умные команды приходят к системам, за которые никто не может поручиться, не потому что они стали беспечными, а потому что ситуация меняется в тот момент, когда команды переходят от одного агента к множеству. Проблема разрастания агентов заключается в подотчетности — кто несет ответственность, когда что-то идет не так.
Вы не можете привлечь к ответственности агентов. Разработчика, который их создал? Возможно. Но в конечном итоге ваша компания несет ответственность за системы, которые вы используете, каждый божий раз.
Одиночные агенты против множественных агентов (или парков агентов)
Один агент прост. Он выполняет одну задачу с одним набором разрешений. Вы можете держать всю картину в голове, и если что-то ломается, вы точно знаете, где искать и кто несет ответственность, потому что есть только один объект для проверки.
Теперь представим парк: это множество агентов, работающих одновременно, общающихся друг с другом и делегирующих задачи между собой. В тот момент, когда вы переходите от одного агента к множеству, вы управляете уже не агентом. Вы управляете системой, а системы ведут себя так, как их отдельные части никогда не вели бы себя по отдельности.
Управление парками агентов против управления одиночными агентами
Команды создают парки для специализации. Вместо одного агента-универсала, пытающегося сделать всё, вы создаете специалистов — один исследует, другой проверяет, третий составляет черновик, четвертый утверждает — и каждый становится по-настоящему хорош в своей работе. Оркестратор координирует их, разбивая сложную задачу на части и направляя каждую часть тому агенту, который лучше всего подходит для ее выполнения.
Именно с этой специализации и оркестрации начинаются проблемы. Те же функции, которые делают парки мощными, делают их трудными для управления. Это та же архитектура, если смотреть на нее со стороны вашей команды безопасности. Делегирование — это передача разрешений между агентами. Автономия — это принятие решений без участия человека. Специализация — это больше агентов, больше связей, больше площадь атаки.
И эта сложность нарастает. Два агента означают одну связь для отслеживания. Пять означают десять. Десять агентов означают сорок пять возможных связей между ними, и это еще до того, как вы посчитаете базы данных, API и сторонние инструменты, к которым обращается каждый из них. К тому времени, когда возникает проблема, вы построили не просто десять агентов. Вы построили сеть, и никто за этой сетью не следит.
В продакшене сбои в управлении мультиагентными системами почти всегда являются результатом одного из трех провалов:
1. Утечка разрешений
Агент получает доступ к базе данных для выполнения одной конкретной задачи, что нормально. Но теперь он сохраняет этот доступ для всего, что делает впоследствии, и в момент, когда он делегирует задачу другому агенту, разрешения перемещаются туда, где их никто не согласовывал. Никто не делает это намеренно, они просто «утекают».
2. «Черный ящик»
Ваш агент принимает решение. Аудитор спрашивает почему. Если ваш ответ — куча логов, разбросанных по четырем разным инструментам, у вас не аудиторский след, а археология. «Дайте мне пару недель покопаться» — это не ответ, который принимают аудиторы.
3. Разрывы в эскалации
Все согласны с тем, что человек должен участвовать в принятии решений с высокими ставками: одобрение крупного платежа, работа с конфиденциальными данными клиентов. Но почти никто на самом деле не выстроил этот процесс. Знает ли агент, когда нужно остановиться? Кому он передает задачу? Что происходит, пока он ждет? Если вы не можете ответить на это, ваши агенты либо принимают решения, которые не должны, либо молча зависают.
Вот система, которую я построил для знакомого сценария: ночной кошмар дежурного инженера в 3 часа ночи, когда измученный специалист просматривает Datadog, PagerDuty, Slack и GitHub, пытаясь найти источник инцидента. Вместо того чтобы один человек делал всё это, работу делят четыре агента. Оркестратор находится наверху, решая, кто что делает, а под ним работают три специалиста — один расследует, другой анализирует, третий общается. У каждого своя область ответственности, свои инструменты, свои разрешения. Нет общих учетных данных или заимствованного контекста.
Допустим, неудачное развертывание увеличило задержку API оформления заказа с 420 до 1840 миллисекунд. PagerDuty отправляет оповещение. В большинстве компаний это момент, когда просыпается человек. Здесь вместо него просыпается оркестратор.
Аудиторский след решает проблему «черного ящика».
Каждый вызов инструмента, каждый ввод, каждый вывод имеют временную метку и зафиксированы. Если в следующем месяце аудитор спросит, почему инцидент развивался именно так, есть один лог, который нужно открыть, а не четыре системы, которые нужно восстанавливать по памяти. Оркестратор делегировал задачи в определенном порядке. Он не пропустил шаг и не вызвал не того агента первым, и эта последовательность записана как во всей системе, так и внутри каждого агента по отдельности.
Разграничение разрешений решает проблему их утечки.
Следователь читает метрики и события. Он не может зайти в Slack. Он не может зайти в Linear. Координатор публикует обновления и отчеты об инцидентах, но не может делать запросы к Datadog. Разрешения не «дрейфуют» между агентами, потому что каждый из них обладает только тем, что ему нужно, и только до тех пор, пока это нужно.
Человеческий контроль (approval gate) решает проблему разрывов в эскалации.
Через тридцать секунд после возникновения инцидента дежурный получает одно структурированное сообщение: гипотеза (развертывание вызвало регрессию), уровень уверенности и рекомендуемое действие (откат). Но агент не делает откат сам. Он предлагает. Есть кнопка, и человек должен ее нажать. Действие, которое может обрушить продакшен, если оно неверно, — это единственное действие, требующее участия человека.
Централизованная система делает управление тем, что наследует каждый новый агент, а не тем, что вы перестраиваете с нуля каждый раз, когда кто-то запускает нового агента. Оглянитесь на то, что только что произошло в этом примере. Каждая функция управления — разграничение разрешений, шлюз одобрения, аудиторский след — не была построена для каждого агента отдельно. Она была частью платформы.
Риск децентрализованного управления агентами
Альтернатива — это разнородный стек: агенты живут в одном инструменте, рабочие процессы в другом, права доступа вообще где-то еще, приложения в четвертом. Каждый стык между этими инструментами — это место, где управление может дать сбой, а каждый новый агент означает перестройку защитных механизмов с нуля.
Централизованная платформа меняет это. Новый агент автоматически получает тот же фреймворк. А ваша служба безопасности одобряет платформу один раз, а не каждого отдельного агента каждый раз, что и является реальной разницей между безопасностью, выступающей в роли вашего тормоза, и безопасностью, выступающей в роли вашего союзника.
Задайте эти вопросы о вашей настройке агентов, чтобы понять ваш исходный уровень управления агентами в рабочей среде:
- Имеют ли все агенты четкие границы данных?
- Существует ли этап подтверждения человеком для критически важных действий?
- Можете ли вы предоставить полный журнал аудита по запросу?
- Наследуют ли ваши агенты вашу существующую систему разрешений или вы создали вторую модель безопасности специально для них?
- Встроено ли управление с первого дня или добавлено задним числом?
Если вы можете ответить утвердительно на все пять вопросов, то ваша команда безопасности станет вашим главным сторонником, а не главным препятствием. Если пока не можете, теперь вы точно знаете, с чего начать и какую из трех уязвимостей устранять в первую очередь.