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