Практика · Средний уровень

Чек-лист выпуска AI-агента в production

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

Время чтения: до 8 минут Результат: проверки перед релизом и план отката

Почему успешной демонстрации недостаточно

AI-агент в production работает не только с моделью, но и с инструментами, пользовательскими данными, очередями, базами и внешними API. Ошибка в рассуждении становится инцидентом, если агенту разрешено без подтверждения удалять записи, отправлять сообщения или раскрывать чужие данные.

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

Шаг 1. Зафиксируйте единицу релиза

Откатывать нужно не абстрактного «агента», а согласованный набор версий. Создайте запись релиза и храните её рядом с конфигурацией развертывания.

# Пример файла release.yaml — значения демонстрационные
release_id: agent-2026-07-28-01
application_image: registry.example.invalid/agent:1.8.0
prompt_version: prompt-14
model_alias: approved-model
tool_policy_version: tools-7
schema_version: "12"
feature_flags:
  autonomous_write: false
  require_confirmation: true

Адрес с доменом .invalid намеренно неработоспособен. Замените его внутренним адресом реестра. Не помещайте токены, пароли и ключи API в этот файл.

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

Шаг 2. Ограничьте доступ и полномочия

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

# Пример политики; синтаксис условный и требует адаптации
principal: service-account/agent-production
default: deny
allow:
  - resource: knowledge-base/public
    actions: [read]
  - resource: tickets
    actions: [read, create]
conditions:
  tenant_from_authenticated_session: true
  destructive_actions: deny
  external_messages:
    require_human_confirmation: true

Идентификатор пользователя или организации берите из проверенной серверной сессии, а не из текста запроса к модели. Модель не должна выбирать роль, область данных или владельца ресурса.

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

Шаг 3. Проверьте поведение воспроизводимо

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

Запустите тесты без сетевого доступа или с имитаторами внешних сервисов.
Зафиксируйте версию модели и параметры генерации, если платформа это поддерживает.
Повторите критические сценарии несколько раз: недетерминированность может скрыть редкую ошибку.
Сравните кандидата с текущей production-версией на одном наборе входов.

# Пример безопасного локального запуска
# Команда должна читать только тестовые данные и использовать имитаторы инструментов
agent-eval run \
  --cases ./eval/cases.jsonl \
  --tool-mode mock \
  --network disabled \
  --report ./artifacts/release-report.json

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

Минимальный набор сценариев:

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

Шаг 4. Установите технические предохранители

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

# Пример конфигурации защитных лимитов
runtime:
  request_timeout_seconds: 45
  max_agent_steps: 8
  max_tool_calls: 5
  max_parallel_tool_calls: 2
  max_output_tokens: 1200

tools:
  write_operations:
    require_idempotency_key: true
  failure_policy: stop
  unknown_tool_policy: deny

budget:
  per_request_cost_limit: configured_by_owner
  daily_limit_action: disable_new_runs

Заданы тайм-ауты, лимиты шагов, вызовов инструментов и размера ответа.
Повтор записи не создаёт дубликат благодаря ключу идемпотентности.
Неизвестный инструмент и неверные аргументы отклоняются.
При серии ошибок агент останавливается, а не повторяет действие бесконечно.
Есть лимит расходов и автоматическая реакция на его превышение.

Шаг 5. Подготовьте наблюдаемость

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

Определите пороги для остановки выпуска:

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

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

Шаг 6. Выпускайте поэтапно

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

# Пример последовательности для оркестратора с декларативной конфигурацией
# Сначала только просмотр изменений
deploy-tool diff --file release.yaml

# Затем применение после ручной проверки diff
deploy-tool apply --file release.yaml

# Проверка состояния без изменения ресурсов
deploy-tool status --release agent-2026-07-28-01

Названия команд условные. Перед применением проверьте справку вашего оркестратора и убедитесь, что команда diff действительно не меняет состояние.

Шаг 7. Проверьте план отката до релиза

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

План отката

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

# Пример аварийного переключения; команды условные
deploy-tool flag set autonomous_write=false
deploy-tool traffic set --release agent-previous-stable --percent 100
deploy-tool traffic set --release agent-2026-07-28-01 --percent 0
deploy-tool status --release agent-previous-stable

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

Проверка результата

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

Запрещённый запрос отклоняется до вызова инструмента.
Агент не получает данные за пределами текущей серверной области доступа.
Повтор операции записи не создаёт второй объект.
Тайм-аут инструмента завершает выполнение предсказуемым статусом.
Версия релиза видна в журналах и метриках.
Флаг экстренно отключает новые записи.
Предыдущая версия разворачивается и проходит проверку готовности.
Учебный откат укладывается в согласованное время восстановления.
Ответственный за остановку выпуска знает процедуру и имеет нужный доступ.

Типовые ошибки

«Модель получила инструкцию ничего не удалять»: Промпт не является границей безопасности. Удаление нужно запретить в политике инструмента и в серверной авторизации.
Один общий ключ для разработки и production: Инцидент в тестовой среде затронет реальные ресурсы. Разделяйте учётные записи, права, квоты и хранилища секретов.
Логи содержат полный промпт и ответы API: Так в журнал могут попасть персональные данные и секреты. Применяйте минимизацию, маскирование и ограничение срока хранения.
Откатывается только код: Промпт, политика инструментов или флаги остаются новыми. Храните их версии в единой записи релиза.
Канареечный выпуск без критериев остановки: Малая доля трафика сама по себе не защищает. Нужны пороги, окно наблюдения и ответственный за решение.
Сначала релиз, потом проверка отката: В момент инцидента выясняется, что старый образ удалён или схема несовместима. Репетиция должна предшествовать выпуску.

Ограничения чек-листа

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

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

Короткий выпускной барьер

Не переводите агента на полный production-трафик, пока не выполнены четыре условия: полномочия минимальны, опасные сценарии воспроизведены, отклонения видны в метриках, а предыдущая версия реально восстановлена на учебном откате.

Дополнительные практические материалы доступны в разделе гайдов, а определения терминов — в глоссарии.