← Назад в блог

Как я доверяю AI-агенту в продакшне: 3 паттерна из 13 cron-задач

Когда я отдал 7 из 13 cron-задач Claude, первое, что я сделал — написал STOP-файл и папку Inbox. Не промт. Не систему мониторинга. Именно это.

Потому что понял: AI в продакшне ломается не тогда, когда LLM выдаёт чушь. Ломается, когда нет рубильника и нет очереди на проверку.

Почему «доверять AI-агенту» — неправильный вопрос

Большинство статей про AI-агентов в production фокусируются на модели. Насколько точно отвечает GPT-4? Как часто галлюцинирует Claude? Это не тот вопрос.

Правильный вопрос: как устроена система вокруг агента? Что происходит, если он сделает лишний запрос? Кто принимает решение до того, как агент совершит действие с последствиями?

Я строил систему автоматизации из 13 cron-задач. 7 работают с approval gate, 5 — полностью автономно, 1 — только вручную. Разница не в сложности задачи. Разница в том, насколько последствия обратимы.

В итоге я вывел три паттерна, без которых не запустил бы это в прод.

Паттерн 1: Stateful drafts — агент предлагает, ты решаешь

Агент никогда не публикует напрямую. Он пишет черновик в папку Inbox, ставит статус draft во frontmatter — и ждёт.

Ты читаешь. Если нормально — переносишь в Queue, потом в Published. Каждый шаг атомарен.

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

Есть и менее очевидный эффект. Статус во frontmatter — это не просто метка, это контракт для следующего запуска: «эту задачу агент уже сделал». Без явного состояния агент при каждом тике переделывает одно и то же.

Паттерн работает везде, где у агента есть два режима: «предложить» и «совершить». Stateful drafts — это намеренный зазор между ними.

Подробнее про то, что именно делегировать агенту, а что оставить себе — в статье «Я даю Claude писать тесты. Я не даю ему выбирать архитектуру».

Паттерн 2: Stop-flag — аварийный стоп за 3 секунды

В рабочей директории лежит файл cron/STOP. Если он существует — ни один cron-агент не запускается. Никаких запросов, никаких действий.

touch "cron/STOP"   # выключить всё
rm "cron/STOP"      # включить обратно

Это не fallback. Это первое, что я реализовал перед любой автоматизацией.

Зачем? Потому что контекст меняется в сторону, которую не предсказать. Внезапно уезжаешь. LinkedIn ведёт себя странно. Рабочий день закончился, завтра разберёшься. touch STOP — три секунды.

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

Паттерн 3: Лимиты в коде, а не в промте

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

В промте можно написать «комментируй не чаще трёх раз в день». В коде это выглядит иначе:

MAX_COMMENTS_PER_RUN = 3
if comments_today >= MAX_COMMENTS_PER_RUN:
    log("rate limit hit, skipping")
    sys.exit(0)

Разница принципиальная. Промт — инструкция, которую модель интерпретирует. Код — граница, которую нельзя нарушить.

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

Ещё один момент: паузы между действиями. Не «примерно 30 секунд», а time.sleep(random.randint(30, 90)). Немного случайности — и шаблон исчезает.

Что я измерил

Три месяца. 7 задач с approval gate, 5 без. Ни одного случая, когда агент «сделал что-то лишнее». Один раз нажал STOP, потому что внезапно уехал. Система остановилась за 3 секунды.

Stateful drafts — около 10-15 минут в день на ревью черновиков. Это не накладные расходы. Это осознанный контроль: я вижу, что происходит, не поддерживая постоянно голову всей системы в памяти.

Что не работает

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

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

Ещё одна ловушка: пытаться всё предусмотреть в промте. Промт — это описание намерения, не контракт. Инварианты безопасности должны жить в коде.

О том, что бывает, когда AI-код уходит в прод без достаточного контроля — кейс из реальной практики в статье «Баг, который написал Claude: семь дней в проде».

Итог

Вопрос не в том, доверять ли AI-агенту. Вопрос — насколько звучна инженерная оболочка вокруг него.

Три паттерна, без которых я не запускаю автономный AI-агент в production:

  1. Stateful drafts — агент предлагает, ты решаешь.
  2. Stop-flag — возможность остановить всё за 3 секунды.
  3. Лимиты в коде, а не в промте.

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