Как заставить Codex возвращаться к задаче самому и не устроить хаос
Автоматизация звучит соблазнительно: пусть Codex сам проверяет, сам продолжает, сам напоминает, сам двигает работу. Но именно здесь легко перепутать полезную регулярность с опасным автопилотом. Если агент просыпается без человека, у него должны быть не только часы, но и границы.
В официальной документации OpenAI по Codex app automations автоматизации описаны как способ планировать повторяющиеся задачи и возвращать Codex к работе по расписанию. Там же видна важная идея: результаты автоматизаций попадают в triage-интерфейс, а thread automations подходят, когда нужно сохранить контекст текущей ветки работы.
Для владельца проекта это не техническая настройка. Это новый тип поручения: "проверяй это регулярно, но не делай вид, что финальное решение уже принято".
Автоматизация - это не власть, а расписание с рамками
Плохая автоматизация звучит так: "каждые 20 минут делай публикации". В ней нет границ, нет проверки, нет условия остановки, нет различия между "подготовить" и "отправить".
Хорошая автоматизация звучит иначе:
Каждые 20 минут проверь очередь публикаций. Если есть уже подготовленные и разрешенные посты, синхронизируй статус и сообщи только о сбое. Не создавай новые статьи, не публикуй напрямую, не отправляй в соцсети в обход очереди. Если буфер ниже 24 часов, подготовь отчет, что нужна новая пачка.
Разница огромная. В первом случае Codex получает смутную власть. Во втором - получает рабочую смену: что проверить, где смотреть, что можно делать, что запрещено, когда молчать, когда звать человека.
Когда Codex должен просыпаться сам
Автоматизации полезны там, где задача повторяется и имеет понятный критерий состояния. Например:
| Сценарий | Что проверяет Codex | Что остается человеку |
|---|---|---|
| Публикационный буфер | сколько часов постов осталось, нет ли failed jobs | менять стратегию контента |
| Долгая команда | завершилась ли сборка, появились ли ошибки | принимать риск релиза |
| Мониторинг источников | появились ли новые материалы по теме | выбирать, что достойно статьи |
| Review loop | ответили ли на замечания, прошли ли проверки | принимать финальную версию |
| Проектный контроль | есть ли новые файлы, задачи, комментарии | менять приоритеты |
Codex хорош в регулярном наблюдении. Он не устает открыть одно и то же место, сверить статусы, собрать краткий отчет и не трогать лишнее. Но регулярность не делает его владельцем процесса.
Как написать безопасный automation brief
Перед созданием автоматизации полезно заполнить маленькую карточку:
| Поле | Вопрос |
|---|---|
| Цель | зачем задача должна просыпаться без меня |
| Частота | как часто проверять и в каком часовом поясе |
| Источник | где Codex берет состояние: файл, очередь, сайт, GitHub, почта |
| Разрешено | что можно сделать автоматически |
| Запрещено | что нельзя делать без человека |
| Уведомлять если | какие события действительно требуют сообщения |
| Молчать если | когда нужно просто записать статус и не дергать человека |
| Стоп-условие | когда автоматизацию нужно остановить или перевести в ручной режим |
Эта карточка важнее красивой формулировки. Она превращает "агент сам что-то делает" в управляемую процедуру.
Что проверять не-программисту
Не-программисту не нужно знать внутренний формат расписания, чтобы проверить автоматизацию. Достаточно задать пять вопросов:
- Понятно ли, какую задачу Codex проверяет?
- Есть ли список действий, которые ему разрешены?
- Есть ли список действий, которые ему запрещены?
- Есть ли правило, когда уведомлять человека?
- Есть ли статус, по которому видно: все нормально, блокер, нужна новая пачка, публикация запрещена?
Если хотя бы на один вопрос нет ответа, автоматизация еще не готова. Она может сработать формально, но будет опасной организационно.
Почему это важно для журнала и контент-завода
В публикационном процессе автоматизация особенно чувствительна. Есть текст, визуал, Ghost, Telegram, VK, очередь, статусы, проверки. Если смешать все в одну команду "публикуй", агент начнет делать то, что кажется логичным, но не обязательно безопасно.
Правильная схема другая: Codex может писать статьи, готовить пакеты, проверять буфер, синхронизировать статусы, создавать задачи на визуал, запускать review gates. Но публикация и социальный handoff должны идти только после явных проверок: текстовый review, live audit, готовый визуал, очередь через ArticleFactory. Так автоматизация помогает процессу, а не заменяет контроль.
Рабочая карточка автоматизации
Можно начать с такого шаблона:
Раз в N минут проверь [источник]. Если состояние нормальное, не уведомляй. Если найден [сбой], напиши короткий отчет: что случилось, где видно, что нужно сделать. Разрешено: читать, синхронизировать статусы, обновлять cockpit. Запрещено: публиковать напрямую, создавать новые внешние отправки, менять правила без человека. Если [стоп-условие], переведи задачу в blocked.
Этот шаблон скучный. И в этом его сила. Автоматизация должна быть скучной, пока все работает. Интересной она становится только тогда, когда действительно нужен человек.
Codex не должен "жить своей жизнью". Он должен возвращаться к задаче по понятной причине, приносить видимый статус и останавливаться там, где начинается ответственность владельца.
