Испытательный срок для ИИ-агента: как выдавать права постепенно

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

Что за модель и почему она появилась

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

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

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

Из чего состоит испытательный срок

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

1. Наблюдение. Агент предлагает действия, но не выполняет их. Человек видит план — какой запрос к базе, какое письмо, какой коммит — и подтверждает вручную каждый шаг. Задача уровня: собрать данные о том, насколько агент вообще адекватен на ваших задачах.
2. Полуавтономия. Обратимые и дешёвые действия агент делает сам: читает данные, черновики писем, ветки без merge. Необратимое и дорогое — платёж, удаление, отправка внешнему адресату — по-прежнему через подтверждение.
3. Автономия с потолком. Агент действует сам в пределах лимитов: сумма платежа до порога, число операций в час, только определённые таблицы или репозитории. Выход за потолок эскалируется человеку.
4. Полная автономия в домене. В узкой, хорошо изученной области агент работает без ручного подтверждения, но под аудитом: каждое действие логируется, аномалии откатываются.

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

Метрики, на которые опирается переход

Без чисел испытательный срок превращается в ощущение «вроде норм». Что стоит считать:

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

Чем это отличается от привычных подходов

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

Технически под капотом ничего экзотического: те же ограниченные API-ключи, изолированные среды выполнения, лимиты на инструменты. Разница в оркестрации — в слое, который решает, какой набор инструментов доступен агенту прямо сейчас, и меняет его по результатам. Часть этой логики уже поддерживают фреймворки для агентов через права на вызов инструментов и человеческие подтверждения перед действием, но связку «метрики — уровень доступа» пока чаще собирают руками.

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

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

• Агент поддержки, оформляющий возвраты и компенсации. Возврат на 300 рублей — сам, на 30 000 — через оператора. Естественный потолок по сумме.
• Агент-разработчик в CI. Открывает pull request сам, но merge в основную ветку — после ревью человека, пока не накопит историю чистых изменений.
• Агент для DevOps. Читает метрики и логи автономно, перезапускает сервис по потолку, но масштабирование, стоящее денег, эскалирует.
• Агент-закупщик. Сравнивает предложения и готовит заказ, оплату подтверждает человек до определённого лимита.

Когда овчинка не стоит выделки:

• Все действия одинаково дёшевы и обратимы. Если худшее, что сделает агент — сгенерирует лишний текст, городить уровни незачем.
• Все действия одинаково критичны. Если любая операция необратима и дорога, честнее оставить human-in-the-loop на всё — испытательный срок только даст ложное чувство безопасности.
• Разовая задача. Модель требует потока: не на чем накопить статистику, чтобы обоснованно повышать уровень.

С чего начать, если решаете внедрять

Не пытайтесь сразу построить все четыре уровня. Минимальная рабочая версия — два: наблюдение и полуавтономия, с ручным решением о повышении. Автоматизацию порогов добавляйте, когда накопите данные о том, где агент реально ошибается на ваших задачах. И заведите аудит-лог с первого дня — без него любой разговор о доверии беспредметен.

Агент — программа на базе языковой модели, которая не просто отвечает текстом, а сама планирует шаги и вызывает внешние инструменты (API, код, поиск) для достижения цели, повторяя цикл «подумал — сделал — оценил результат» без участия человека на каждом шаге.