Как развернуть ИИ-агента в продакшене: от демо до запуска с восстановлением, наблюдаемостью и откатом

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

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

Сначала определите условия запуска, входные данные, разрешенные инструменты, конечный бизнес-результат, обработку тайм-аутов и этапы подтверждения человеком. Если фиксированный процесс уже отвечает требованиям, не стоит внедрять несколько агентов только ради перехода к агентной архитектуре. О выборе между рабочими процессами и агентами читайте в материале Anthropic о подходах к созданию агентов. Подключение к интерфейсам систем и права доступа к инструментам подробно разобраны в статье «Как интегрировать ИИ-агента с существующими корпоративными системами».

Выбор варианта развертывания: учитывайте ограничения

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

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

Минимальная производственная архитектура: связываем запросы, выполнение, состояние и наблюдаемость

调用方 → 鉴权入口/请求校验 → 任务执行器（同步短任务或异步任务 ID）
      → Agent 运行逻辑 → 模型端点/受控工具 → 状态存储与结果核验
      → 日志、指标、追踪与告警

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

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

Подготовка артефактов релиза: обеспечиваем воспроизводимость изменений

Включайте в историю изменений код, файлы фиксации зависимостей, образ среды выполнения, конфигурацию окружения, шаблоны промптов, версии конфигураций моделей и инструментов. Проверяйте зависимости в процессе сборки; разделяйте среды разработки, тестирования и промышленной эксплуатации; передавайте учетные данные через контролируемый механизм конфигурации, не записывая их в репозиторий кода или обычные журналы. Управляйте ключами API моделей, учетными данными сервисов инструментов и бизнес-идентификаторами раздельно.

Контрольный список релиза должен как минимум подтверждать следующее:

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

Восстановление длительных задач: контрольные точки не гарантируют однократного выполнения бизнес-операций

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

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

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

Меры безопасности: задайте условия блокировки действий с высоким риском

Перед выпуском проверьте как минимум следующее:

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

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

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

Не считайте заявление агента «выполнено» основанием для приемки. Для каждого типа задач определите условия успеха, которые можно проверить в рабочей среде: например, состояние целевой записи, формат вывода и отсутствие запрещенных действий. Сохраняйте трассировку выполнения, чтобы находить ошибки в планировании, вызовах инструментов или проверке результатов. В качестве ориентира можно использовать описание методов оценки ИИ-агентов от Anthropic.

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

Мониторинг: качество, задержки, восстановление и затраты

Для каждой метрики определите правила расчета, точки сбора данных, условия оповещения и ответственного:

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

Поэтапное развёртывание, откат и обработка незавершённых задач

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

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

Учебная тренировка: проверка путей восстановления с помощью внесения сбоев

Ниже приведён план учебной тренировки, а не клиентский кейс или результаты реальных испытаний. Задача сформулирована так: «Сформировать отчёт и записать результат после подтверждения человеком». В каждом случае фиксируйте ожидаемый результат, фактический результат и подтверждающие данные:

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

Контрольный список приёмки перед запуском

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

Частые вопросы о развёртывании

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

Вопрос: нужно ли самостоятельно размещать модель для развёртывания агента? Ответ: не обязательно. Если для инференса используется API модели, обычно достаточно развернуть среду выполнения приложения, инструменты с контролируемым доступом и компоненты хранения состояния. При самостоятельном размещении инференса отдельно оцените требования к границам обработки данных, задержке, доступности и эксплуатации.

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

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

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