Наблюдаемость роя ИИ-агентов: что они делают, кому это разрешено и как их остановить

На Dev Day в OpenAI рассказали, что разрабатывают специализированный механизм для наблюдения и контроля над большим количеством одновременно работающих ИИ-агентов. Деталей публично немного, поэтому говорю о нём обобщённо. Важна здесь не конкретная реализация, а сам факт: крупный поставщик моделей признал проблему достаточно серьёзной, чтобы строить под неё отдельный слой.

Проблема звучит просто и неприятно решается. Пока агент один, за ним можно присматривать вручную. Когда организация запускает сотни или тысячи автономных агентов, контролировать каждый их шаг привычными средствами уже не выходит. Рядом с AgentOps оформляется отдельный рынок: безопасность ИИ-агентов и наблюдаемость ИИ-агентов как самостоятельные дисциплины.

Мой угол зрения на это такой. Привычная наблюдаемость отвечает на вопрос «система жива и быстро ли отвечает». Для роя агентов вопрос звучит иначе: «что они сейчас делают, кому это разрешено и как это остановить». Из второго вопроса вырастает совсем другая архитектура, и дешевле заложить её сейчас, пока агентов десяток, чем переделывать на трёхстах.

Классическая наблюдаемость измеряет здоровье системы

Метрики, логи и трейсы собирали под конкретную задачу: понять, работает ли сервис и где он тормозит. Я про это писал подробно в заметке про три опоры наблюдаемости для продуктовых команд. Там всё строится вокруг запроса: пришёл запрос, прошёл через пять сервисов, вернул код ответа за столько-то миллисекунд. Метрика агрегирует, лог фиксирует деталь, трейс связывает участки одного пути.

Этот аппарат работает и для агентов, но отвечает только на половину вопросов. Он скажет, что агент выполнился за сорок секунд и не упал. Он не скажет, зачем агент полез в хранилище с клиентскими договорами, кто его об этом попросил и был ли вообще человек на том конце цепочки.

Разница вот в чём. Обычный сервис делает заранее описанное действие: эндпоинт заданный, его поведение определено кодом. Агент получает цель и сам выбирает, какими инструментами её достигать. Два запуска с одной и той же формулировкой дают разные последовательности вызовов. Здоровье системы при этом остаётся зелёным в обоих случаях, хотя в одном агент сходил в справочник, а в другом переписал тридцать записей в боевой базе.

Единица наблюдения смещается с запроса на намерение

Для роя агентов наблюдать нужно другую сущность. Полезная единица здесь это пара «намерение и действие»: какую цель агент перед собой поставил и какой вызов инструмента он в результате сделал. Запрос как единица слишком мелкий, а задача целиком слишком крупная.

Из этого следует несколько практических вещей.

• Нужен сквозной след от распоряжения человека до вызова инструмента. Человек попросил подготовить отчёт по просроченной задолженности. Агент решил, что для этого надо выгрузить таблицу платежей, вызвал инструмент выгрузки, получил отказ по правам, переформулировал задачу, пошёл в другой источник. Весь этот путь должен складываться в одну цепочку с одним идентификатором, который тянется от человека до последнего вызова. Если агент породил трёх подагентов, они наследуют этот идентификатор, иначе связь между распоряжением и последствием теряется.

• Запись нужна о попытках, а не только об успехах. Отказ по правам доступа в обычном сервисе это строчка в логе на четвёртом уровне важности. Для агента отказ это сигнал о том, куда он пытался дотянуться. Серия отказов подряд от одного агента интереснее, чем любая зелёная метрика.

• Сохранять надо вход и выход инструмента, а не только факт вызова. Иначе разбор инцидента через неделю упрётся в строчку «агент вызвал update_records» без понимания, что именно он там обновил.

• Наблюдать нужно популяцию, а не экземпляр. Один агент, который за час сделал сорок вызовов, это нормально. Сорок агентов, которые синхронно пошли в один и тот же источник после обновления промпта, это уже событие, и видно его только на уровне роя.

Почему это ближе к безопасности, чем к эксплуатации

Здесь главный сдвиг, который я советую уложить в голове собственнику и техническому директору. Агент ходит по вашим системам с валидным токеном. Для любой системы контроля доступа он легитимный клиент: права выданы, сессия живая, запросы корректно подписаны. Классический периметр такой трафик пропускает, потому что ему нечего предъявить.

Я уже разбирал смежный сюжет в заметке про ИИ-ассистентов и идентичность как поверхность атаки. С роем агентов эта история масштабируется. Отличие агента от скомпрометированного аккаунта сотрудника в том, что агент работает со скоростью машины и не спит, поэтому ошибка в его целеполагании разворачивается за минуты.

Аномалия здесь измеряется в поведении. У неё нет сигнатуры вредоноса и нет подозрительного IP. Подозрительно выглядит сам рисунок действий:

• агент, который обычно читает три справочника, вдруг начал перебирать содержимое хранилища;
• доля операций записи в его поведении выросла втрое за сутки;
• цепочка вызовов больше не ведёт к распоряжению живого человека, а замкнулась сама на себя;
• агент систематически пробует инструменты, на которые у него нет прав.

Ни одно из этих событий не ломает систему. Все четыре это поведенческие отклонения, и поймать их можно только при условии, что у вас есть базовая линия нормального поведения конкретного агента. Отсюда вывод, который я считаю главным: наблюдаемость агентов строится как контроль доступа с историей, а эксплуатационные метрики идут к ней довеском.

Алерт опаздывает, поэтому нужен предохранитель

Классический алерт устроен как уведомление: порог превышен, дежурный получил сообщение, дежурный пошёл разбираться. Между срабатыванием и реакцией проходят минуты, и для человеческой системы это приемлемо.

Агент за эти минуты успевает сделать сотни вызовов. Поэтому вместо уведомления нужен механизм, который останавливает действие сам, по заранее заданному правилу. Я называю это бюджетами и предохранителями.

Бюджет это лимит, в который агент обязан уложиться: число вызовов инструмента за период, объём потраченных токенов, количество записей, которые он имеет право изменить за один запуск, суммарная стоимость задачи. Про денежную сторону вопроса у меня есть отдельный разбор про токенные бюджеты и контроль затрат на LLM, и там логика ровно та же: лимит, который применяется автоматически, работает, а аккуратность разработчика не работает.

Предохранитель это правило, по которому выполнение прекращается при выходе за бюджет или при попадании действия в красный список. Остановка должна происходить до вызова инструмента, а не после. Разница между «агент отправил письмо тысяче клиентов, мы это увидели» и «агент попытался отправить письмо тысяче клиентов, вызов был отклонён» это разница между инцидентом и записью в журнале.

И третье, про что почти всегда забывают: нужна возможность массовой остановки. Кнопка, которая гасит не один процесс, а весь класс агентов разом, по признаку: все агенты этой версии промпта, все агенты с доступом к платёжному контуру, все агенты конкретной команды. Проверить эту кнопку надо до того, как она понадобится, и проверять регулярно. Кнопка, которую ни разу не нажимали, это предположение, а не механизм.

Практический минимум, пока агентов десяток

Переделывать на трёхстах агентах дорого. Вот что я советую заложить сразу, даже если сейчас у вас три сценария и один энтузиаст, который их поддерживает.

1. Заведите реестр агентов. Список: какой агент, кто владелец со стороны бизнеса, какая цель, к каким системам имеет доступ, какой версией промпта и модели работает. Это десять строк в таблице сегодня и единственный способ ответить на вопрос «а сколько их у нас вообще» через год. Агенты, которых завели в обход реестра, это та же теневая ИТ, только быстрее.

2. Дайте каждому агенту собственную идентичность. Отдельный технический аккаунт и отдельный токен на агента, а не общий сервисный ключ на всех. Без этого вы физически не сможете ни построить базовую линию поведения, ни отозвать доступ у одного агента, не положив остальных.

3. Выдавайте права по минимуму и пересматривайте их. Агент наследует проблему жизненного цикла доступов в чистом виде: права выдали под одну задачу, задача изменилась, права остались. Логика та же, что и для людей, я её разбирал в заметке про минимальные привилегии на практике. Разница в том, что агент пользуется всем, что ему выдали, и делает это быстро.

4. Протяните один идентификатор от человека до вызова инструмента. Распоряжение человека порождает идентификатор, он наследуется подагентами и пишется в каждый вызов. Это самая дешёвая вещь из списка на старте и самая дорогая для внедрения задним числом.

5. Логируйте намерение, вызов, вход, выход и отказ. Пяти полей достаточно, чтобы через месяц восстановить картину. Решите заранее, что из этого вы имеете право хранить: в вызовах окажутся персональные данные, и срок хранения надо согласовать с юристами сразу, а не после первого запроса регулятора.

6. Поставьте бюджеты на каждый агент с первого дня. Лимит вызовов, лимит записей, лимит стоимости. Начните с заведомо щедрых значений: задача первого месяца это узнать, как выглядит норма, а не прижать агента.

7. Сделайте и проверьте массовый стоп. Один механизм, который останавливает агентов по признаку. Прогоните его на учениях, запишите время от решения до фактической остановки всех процессов.

8. Назначьте владельца. У роя агентов должен быть человек, который отвечает за реестр, бюджеты и разбор отклонений. Пока агентов десяток, это половина ставки. Когда их триста, это уже функция, и лучше, чтобы она выросла из существующей роли, а не появилась после инцидента.

Честные оговорки

• Ни один из этих механизмов не отменяет ошибку в постановке задачи. Агент с идеальной трассировкой и аккуратными бюджетами всё равно сделает ровно то, что ему поручили, включая то, чего поручающий не имел в виду. Наблюдаемость сокращает время до обнаружения и ограничивает ущерб, а качество формулировок остаётся на людях.

• Поведенческая базовая линия требует времени и данных. Первые недели вы будете видеть отклонения там, где их нет, и пропускать настоящие. Это нормальный период обучения, и закладывать его надо в план, а не удивляться потом.

• Рынок этих инструментов молодой, и устоявшихся стандартов пока нет. Поставщики моделей строят свои механизмы контроля, отдельные компании строят свои, и как это будет стыковаться между собой, сейчас честно не знает никто. Поэтому собственную запись о том, что делали ваши агенты, я советую держать у себя, а не полагаться на консоль одного поставщика.

• Глубокая часть работы остаётся за профильными специалистами. Я помогаю разложить риск, выстроить контур управления вокруг агентов и поставить нужные вопросы поставщикам. Детальную настройку систем обнаружения и формальную верификацию поведения делают узкие люди, и я их привожу, вместо того чтобы изображать эксперта во всём.

Если коротко

• Классическая наблюдаемость отвечает на вопрос о здоровье системы, а для роя агентов нужен ответ на вопрос о том, что они делают, кому это разрешено и как это прекратить.
• Единицей наблюдения становится пара «намерение и действие», и нужен сквозной след от распоряжения человека до вызова инструмента, включая отказы и действия подагентов.
• Это задача ближе к безопасности: агент с валидным токеном выглядит легитимным трафиком, а аномалия измеряется в поведении, не в сигнатуре.
• Алерт опаздывает за машинной скоростью, поэтому нужны бюджеты, предохранители, останавливающие вызов до его выполнения, и проверенная кнопка массовой остановки.
• Минимум на старте: реестр агентов, отдельная идентичность каждому, минимальные права, сквозной идентификатор, пять полей в логе, бюджеты с первого дня, учения на массовый стоп и назначенный владелец.

Если у вас уже работает несколько агентов и вы примеряете, что будет на тридцати, самый дешёвый момент разложить это по полочкам именно сейчас. Обсудить задачу можно через форму на главной, и первый разговор ни к чему вас не обязывает.