Kill switch для ИИ-агента: как выключатель работает на деле

Что вообще пытаются выключить

Автономный агент — это не чат-бот, который отвечает и замолкает. Это цикл: модель получает задачу, вызывает инструменты (API, шелл, платёжку, браузер), читает результат, снова думает и снова действует. Пока цель не достигнута или лимит не исчерпан. Именно из-за этого цикла нужен kill switch: если агент застрял в петле, начал списывать деньги или удалять файлы, у оператора должен быть способ остановить его за секунды, а не ждать, пока он «сам закончит».

Проблема в том, что «нажать кнопку» — это только интерфейс. За кнопкой стоит несколько слоёв, и надёжность выключателя определяется самым слабым из них. Если агент уже отправил HTTP-запрос на перевод денег, остановка модели ничего не отменит: запрос ушёл. Поэтому инженеры строят kill switch не как одну функцию, а как набор рубежей — от отзыва задачи до аппаратного обесточивания.

Из чего состоит выключатель

На практике надёжный стоп собирают из нескольких независимых механизмов. Каждый закрывает свой класс отказов.

• Отмена задачи (graceful cancel). Оркестратор выставляет флаг отмены, агент проверяет его между шагами цикла и завершается штатно, дописав логи. Самый мягкий вариант — но работает, только если агент вообще доходит до проверки флага.
• Прерывание процесса. Отправка сигнала процессу (SIGTERM, затем SIGKILL) или остановка контейнера. Убивает цикл принудительно, даже если код завис. Но не отменяет уже сделанные внешние действия.
• Отзыв доступов (revoke). Kill switch дёргает не только агента, но и его окружение: инвалидирует API-ключ, отзывает OAuth-токен, закрывает сетевой доступ через firewall или service mesh. После этого даже живой агент не может ничего вызвать.
• Circuit breaker на уровне инструментов. Каждый инструмент проходит через прокси, который считает вызовы и умеет захлопнуться: превышен лимит запросов в минуту, сумма трат, число операций удаления — прокси перестаёт пропускать вызовы, не трогая саму модель.
• Аппаратный или инфраструктурный рубеж. Крайний случай: отключение виртуальной машины, отзыв сетевого сегмента, обесточивание. Медленно и грубо, зато не зависит от кода агента вообще.

Хороший kill switch останавливает не мышление агента, а его руки. Модель может продолжать «хотеть» действие — важно, чтобы оно физически не проходило.

Где ставить точку остановки

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

Рабочая схема — не выбрать один уровень, а выстроить их каскадом: сначала мягкая отмена, если не сработала за таймаут — kill процесса, параллельно отзыв доступов, и firewall как страховка.

Идемпотентность и «руки», которые нельзя отозвать

Самая коварная часть — необратимые действия. Отправленный платёж, удалённая запись в БД, разосланное письмо. Kill switch не машина времени: остановить он может только то, что ещё не случилось.

Поэтому проектирование выключателя начинается раньше кнопки — с классификации инструментов. Действия с побочными эффектами прогоняют через прослойку, которая:

1. требует подтверждения оператора для необратимых операций (human-in-the-loop*) — например, любой перевод свыше порога;
2. делает вызовы идемпотентными, чтобы повтор после перезапуска не задвоил операцию;
3. работает по принципу двухфазного действия: сначала «намерение» в очередь, отдельный воркер исполняет с задержкой, и kill switch успевает отменить намерение до исполнения;
4. ведёт журнал всех вызовов, чтобы после остановки было видно, что уже произошло, а что нет.

Кому это пригодится, а кому нет

Не каждому агенту нужен многослойный выключатель. Стоимость и сложность должны соответствовать рискам.

Нужен полный каскад

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

Хватит минимума

• Агент в песочнице без сети и без записи наружу: только чтение и генерация текста. Достаточно kill процесса.
• Прототип на одном разработчике, который сидит рядом и видит логи. Ручной Ctrl+C — уже kill switch.
• Агент с read-only доступом к данным: максимум, что он натворит, — потратит токены. Тут важнее лимит бюджета, чем аварийный стоп.

Частая ошибка: выключатель, который выключают тем же каналом

Если команда на остановку идёт через ту же систему, что и работа агента (тот же брокер сообщений, тот же процесс, та же сеть), то при её сбое вы теряете и агента, и способ его остановить. Kill switch должен иметь независимый путь: отдельный канал управления, прямой доступ к оркестратору, возможность отозвать доступы из внешней панели. Иначе выключатель работает, только пока всё и так в порядке.

Технически kill switch для автономного агента — это не одна функция, а дисциплина проектирования: заранее решить, какие действия обратимы, поставить прокси перед необратимыми, развести каналы работы и остановки и выстроить каскад от мягкой отмены до обесточивания. Кнопка в интерфейсе — последнее, что делают, а не первое.

* human-in-the-loop — схема, при которой критичные шаги агента требуют явного подтверждения человека, прежде чем исполниться.