Семь ИИ-агентов работают у нас по ночам: агенты по расписанию не только для кода, с промптами

23 сентября пользователь по имени Rob написал в нашем публичном бэклоге: «would love to get examples of how you guys are doing stuff beyond coding». Справедливый вопрос. Весь этот сайт посвящён кодинг-агентам, а то, что мы на самом деле запускаем каждый вечер, по большей части не код.

С 28 августа семь агентов запускаются на Mac mini в 20:00. Они читают коммиты за день, Search Console, админ-дашборды, бэклог, отзывы, которые прислали люди, отчёты прошлой ночи. Они исправляют баги, правят сайт, пишут и переводят статью для блога раз в три дня, публикуют посты в трёх соцсетях, обновляют базу знаний о продукте, а в 22:00 седьмой читает то, что оставили шестеро остальных, и отправляет письмо из 25 строк. Никто за ними не следит. Основатель читает письмо на телефоне на следующее утро.

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

Что дали 33 ночи

В папке отчётов в репозитории 33 датированные директории, с 28 августа по 30 сентября. Если их прочитать, получается вот что:

• 31 утреннее письмо, отправленное репортёром.
• 51 баг, исправленный фиксером, у каждого ссылка на коммит в строке отчёта. О нескольких из них сообщили пользователи в публичном бэклоге, и с ближайшим релизом они получили ответ.
• 7 статей для блога, написанных SEO-командой с 10 сентября, по одной раз в три дня, каждая сначала на английском и французском, затем ещё на 18 языках в ту же ночь.
• 29 дней журнала соцсетей: три сети и пять групп в Facebook за вечер, плюс благодарственный комментарий под каждым постом, где пользователь поделился AgentsRoom.
• База знаний о продукте примерно из сотни карточек, которая сверяется с коммитами за день; её читает встроенный ассистент, а сайт отдаёт её как llms-full.txt.

Ничего из этого не потребовало человека после 20:00. Кое-что потребовало человека в 08:00, и в этом весь смысл последнего агента.

Состав: кто запускается в 20:00

Каждый агент это запланированная задача в AgentsRoom: промпт, агент (роль, CLI, модель), машина и время. Все семь работают на Claude Code. Двое из них не одиночные агенты, а команды из двух шагов, и мы ещё вернёмся к тому, почему.

Файлы .md из последней колонки все лежат в reports/night/<date>/, закоммиченные и запушенные. Эта папка и есть вся система координации, а следующий раздел объясняет почему.

Как это устроено

Каждый из семи это запланированная задача одного и того же вида:

• Срабатывает ежедневно в 20:00 (в 22:00 для репортёра). Никакого cron-выражения; частота выбирается в редакторе.
• Привязана к одной машине. Проект открыт на нескольких компьютерах, и триггер срабатывает на каждой машине, где он есть, если его не ограничить. Наши ограничены Mac mini, поэтому ноутбук, открытый в 20:05, не запускает второго CEO.
• Будит машину. Mac mini спит. У задачи есть опция «разбудить машину», которая планирует пробуждение штатным инструментом операционной системы (pmset на macOS, Планировщик заданий с пробуждением для запуска на Windows, rtcwake на Linux) за несколько секунд до запуска. Без неё спящая машина просто пропускает запуск.
• Навёрстывание включено или выключено, для каждой задачи отдельно. Если в 20:00 машина была выключена, задача с включённым навёрстыванием срабатывает при следующем запуске приложения. У CEO, PM и репортёра оно включено. У задач SEO, фиксера, соцсетей и документации выключено: запуск, начавшийся в 11:00 следующего утра, столкнулся бы с дневной работой в том же чекауте.
• Режим разрешений задаётся на задаче, а не на провайдере. Запуск без присмотра не может остановиться на запросе подтверждения в 3 часа ночи, поэтому задача работает без них, а агенты, которыми основатель управляет вручную на том же CLI, по-прежнему сначала спрашивают.
• Консоль закрывается после 60 минут простоя. Агент, который закончил работу, не висит в боковой панели, пока его кто-нибудь не закроет.
• Промпт это первое сообщение. Текст каждого промпта хранится в библиотеке промптов и совпадает с текстом поля промпта в триггере, так что изменить один значит изменить оба. Промпты написаны на французском, потому что основатель читает отчёты на французском. Всё остальное, от сообщений коммитов до базы знаний, на английском.

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

Как они передают друг другу работу, не разговаривая

Семь агентов никогда не пишут друг другу. Могли бы, в AgentsRoom есть обмен сообщениями между агентами, но сообщение не видно на следующее утро, и по нему нельзя сделать grep. Всё идёт через три вещи, которые переживают ночь:

Репозиторий. Каждый агент пишет reports/night/<date>/<agent>.md, открывает его в первую минуту запуска, переписывает после каждой законченной части работы, коммитит и пушит. У отчёта четыре фиксированных раздела: «В двух словах» (маркированный список, один пункт на каждое сделанное дело), «Решить» (только то, что промпт оставляет человеку), «Проверить» (локальный URL или экран, который нужно открыть), «Подробности» (сколько потребуется). Заканчивается он меткой запуска: последним коммитом, который видел агент.

Бэклог. Агент, который находит работу для другого, сам эту работу не делает. Он открывает тикет с тегом: ceo-fix для проверенного небольшого бага, который возьмёт фиксер; ceo-seo для задачи по контенту с целевым запросом; ceo-decision для всего, что требует человека (база данных, биллинг, авторизация, шифрование, цены, проиндексированный URL, поведение по умолчанию). Хранитель документации, читая коммиты, находит фичу без страницы на сайте: он заводит тикет ceo-seo, и SEO берёт его следующей ночью. CEO, читая логи ошибок, находит баг с его причиной в коде: ceo-fix, и фиксер берёт его следующей ночью.

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

Цикл замыкается на человеке. Письмо репортёра заканчивается одной строкой: чтобы ответить продакт-менеджеру, добавь раздел «## Решения» в конец rapport.md (P1 OK / P2 НЕТ: причина / P3 ПОЗЖЕ), commit, push. PM читает запушенную версию следующим вечером и выполняет то, что одобрено: создаёт тикет, объединяет дубликаты, откладывает остальное с указанием причины. Решение, на которое три ночи нет ответа, это тоже решение: предложение уходит из письма и остаётся тикетом.

Какая модель делает какую работу и почему

В таблице выше две модели. Это текущая конфигурация, а не бенчмарк, и она меняется. Но разделение сделано намеренно.

Fable там, где работа требует суждения. CEO решает, является ли «палец вниз» у оракула настоящей ошибкой или делом вкуса. Фиксер решает, является ли сообщение о баге багом или настройкой конкретной машины, а затем находит причину в коде. Шаг 1 SEO решает, какая фраза на сайте стала неправдой после сегодняшнего коммита, какую статью написать и какую страницу не трогать. Шаг 1 соцсетей выбирает тему вечера и пишет для аудитории, которая распознаёт сгенерированный текст за три строки. Эти промпты длинные (у SEO около 4 000 слов) и полны правил «ты решаешь, ты не спрашиваешь» с короткими списками исключений. Именно здесь самая сильная модель окупает свою цену.

Opus с контекстом 1M там, где работа это объём. Перевести статью на 18 языков с помощью субагентов, по три локали на каждого, а затем сверить объединённый результат с французским эталоном, это чтение и письмо, много чтения и письма, с одними и теми же правилами, применёнными 18 раз. Хранитель документации читает дневные диффы против сотни карточек. PM читает 8-мегабайтную выгрузку разговоров при уходе. Репортёр читает пять отчётов и копирует, он не думает. Там большой контекст и более низкая цена за токен важнее суждения.

Поэтому двое из семи это команды из двух шагов, где каждый шаг это агент со своей моделью. Шаг 1 на Fable заканчивает работу тем, что пишет раздел «Хендофф» в общем отчёте: точный список файлов и ключей, которые должен сдать переводчик, или точные посты, которые должен опубликовать публикатор. Шаг 2 на Opus читает этот раздел и делает только то, что в нём перечислено. Граф команды линейный, один цикл, и отчёт сохраняет строку «запуск в процессе», пока шаг 2 её не уберёт. Со стороны, в 22:00, отчёт, всё ещё помеченный «в процессе», означает либо оборванный запуск, либо команду между двумя шагами, и репортёр говорит, что именно.

Четыре правила, которые пришлось выучить промптам

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

1. Метка запуска, прочитанная во вчерашнем отчёте. Первая версия SEO-агента читала «коммиты за последние 24 часа». Две проблемы: запуск в 20:00 и запуск в 20:10 на следующий день видят не одни и те же 24 часа, а ночь, когда агент не запускался, это день коммитов, на которые никто не смотрит. Теперь каждый отчёт заканчивается строкой Последний увиденный коммит: <sha>, и следующий запуск начинает с этого коммита, что бы ни показывали часы. Нет метки (первая ночь, отчёт отсутствует): два дня назад, и отчёт это указывает.

2. История лежит на диске, так что сделай по ней grep, прежде чем что-то поднимать. Жалоба, которая звучала чаще всего в первые две недели: «ты мне это уже говорил, я вчера это исправил». Исправление это правило с командой внутри: прежде чем сообщать о теме или браться за работу, grep -ril "<тема>" reports/night/ и git log --since="30 days ago" -- <файл>. Совпадение означает: сначала прочитай тот отчёт. Три случая, и только три, позволяют снова говорить о разобранной теме: исправление не сработало, и ты только что это проверил; исправление частичное, и ты называешь, что осталось; тема изменила свою природу. Вместе с этим пришли два следствия. Одна ночь, один запуск: если отчёт за эту ночь существует, содержит «В двух словах» и больше не говорит «запуск в процессе», агент останавливается. И предложение без ответа три ночи подряд уходит из отчёта; тикет остаётся.

3. Отчёт открывается до начала работы. Запуск, оборванный в 21:30, раньше не оставлял ничего. Теперь первое, что делает агент после загрузки навыка, это mkdir -p reports/night/$(date +%F) и запись каркаса отчёта с четырьмя заголовками разделов и строкой запуск в процессе, начат в 20:01. После каждой законченной работы он переписывает файл целиком. Оборванный запуск оставляет частичный отчёт, который репортёр может скопировать, и это намного лучше, чем агент, который «не запускался».

4. Коммить по ходу работы, никогда в конце. Замерено 9 сентября: два агента были остановлены в одну и ту же минуту. Тот, что коммитил после каждой работы, ничего не потерял. Другой оставил 45 изменённых, незапушенных файлов, которые ни к кому нельзя было отнести; основатель разбирал их вручную на следующее утро, а отчёта этого агента не существовало. С тех пор правило такое: один коммит на каждую законченную работу, файлы перечислены по одному, последний коммит для отчёта и хотя бы один push во время запуска. Коммит это ещё и датированный след, и именно по нему делает grep правило 2.

Пятое правило не про память, а про смелость, и именно оно сильнее всего изменило результат. Промпт SEO говорит: «Ты не аудитор, который докладывает о находках: ночью сайт принадлежит тебе. Запуск, который заканчивается шестью идеями на утверждение, это провальный запуск». Затем он перечисляет шесть случаев, и только шесть, когда агент должен спросить, а не действовать: удалить или переименовать URL, изменить заголовок страницы, которая ранжируется, юридический текст, цена или квота, утверждение о приватности или шифровании, изменение, затрагивающее больше пяти страниц. Всё остальное он делает, а основатель на следующее утро убирает то, что ему не нравится. У фиксера то же правило с тремя случаями. До этого правила отчёты были списками предложений. После него это списки коммитов.

Промпты

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

Блок 1: общие правила (все семь загружают их как навык)

# Ночные агенты: общие правила
Они важнее твоего собственного промпта, если они расходятся.

## Одна ночь, один запуск
DAY=$(date +%F); F=reports/night/$DAY/<ты>.md
Если F существует, содержит «В двух словах» и больше не содержит «запуск в процессе»:
остановись. Ничего не пиши, ничего не отправляй, закончи сообщением в одну строку.
Если там всё ещё написано «запуск в процессе»: это твой собственный запуск, оборванный несколько минут назад.
Продолжи с того места, где он остановился, не начинай заново.

## Что тебе можно
- Git: add <перечисленные файлы>, commit, push ТВОЕЙ работы, по ходу дела.
  Никогда: add -A, commit -a, push --force, stash, reset, checkout, clean, новая ветка.
- Сборка: typecheck, lint, скрипты проверки, локальная сборка для проверки.
  Никогда: скрипт, который деплоит или публикует.
- Бэклог: создать тикет, дописать в тикет, закрыть тикет, который ты исправил.
  Никогда: отвечать пользователю (это отправляет письмо), удалять тикет, перезаписывать описание.
- Никогда не выдумывай цифры. Источник недоступен: скажи об этом и иди дальше.
- Перед любой записью в git: git status --short. Дерево общее с другими агентами.

## Догнать изменения и знать, что УЖЕ сделано
git fetch && git status -sb
Отстаёшь, дерево чистое: git pull --ff-only. Отстаёшь, дерево грязное: не делай pull, напиши об этом в начале отчёта.
Твоя метка запуска: строка «Последний увиденный коммит: <sha>» в конце вчерашнего отчёта.
Нет метки: --since="2 days ago", и скажи об этом.
Три обязательных чтения перед любым анализом:
1. git log --no-merges --format='%h %s' <sha>..HEAD и git diff --stat <sha>..HEAD
2. тикеты, закрытые со вчерашнего дня, и тикеты, которые человек поставил на паузу
3. твой собственный вчерашний отчёт: «В двух словах» и «Решить»

## Папка отчётов И ЕСТЬ твоя история
Прежде чем поднимать находку или браться за работу:
grep -ril "<тема>" reports/night/ | sort | tail -5
git log --since="30 days ago" --oneline -- <файл>
Есть совпадение: прочитай тот отчёт, прежде чем что-либо решать.
Две ночи подряд на одну тему: вторая потрачена впустую.
Страницу или текст, которые ты трогал, не трогают снова три недели,
кроме как чтобы исправить то, что стало неправдой.

## Никогда не поднимай одно и то же дважды
Уже разобранная находка, которая возвращается на следующий день, это ошибка.
Это допустимо только в трёх случаях:
1. исправление не сработало, и ты только что это проверил: «исправлено <дата> в <коммит>, всё ещё сломано: <доказательство>»
2. исправление частичное: назови точно, что осталось
3. тема изменила природу: новая причина, новое измерение, новый охват
Не пересчитывай запас. Сообщай об изменении, никогда о запасе.

## Предложение без ответа умирает через три ночи
Ночи с 1-й по 3-ю: строка несёт свой счётчик и первую дату («2-я ночь, поднято 07/09»).
С 4-й: она уходит из «Решить». Тикет остаётся; максимум одна строка в «Подробностях».
Если решение в твоей зоне, прими его на 3-ю ночь и скажи об этом.

## Коммить и пушь по ходу работы
Первый коммит, как только первая работа закончена и проверена. Затем по одному на работу.
Последний коммит для твоего отчёта. Пушь хотя бы раз во время запуска и один раз в конце.
Push отклонён (удалённый репозиторий ушёл вперёд): git pull --ff-only, затем push. Снова отклонён: не форсируй,
не делай rebase, напиши об этом в отчёте.

## Твой отчёт: открыт в начале, никогда не пишется только в конце
reports/night/<YYYY-MM-DD>/<ты>.md, создан ДО работы, со следующим:
  # <Агент> - <дата>
  _запуск в процессе - начат в <HH:MM>_   (убирается в конце)
  ## В двух словах     (от 3 до 5 строк или маркированный список: один пункт на каждое сделанное дело)
  ## Решить            (только то, что твой промпт оставляет человеку; иначе «Ничего»)
  ## Проверить         (- [ ] что : где : что должно быть видно; иначе «Ничего»)
  ## Подробности       (сколько потребуется: доказательства, файлы, команды)
  ## Метка запуска
  Последний увиденный коммит: <git rev-parse HEAD после твоего последнего коммита>
Переписывай файл целиком после каждой законченной работы.
Читатель смотрит с телефона, две минуты: короткие фразы, без путей к файлам,
без SHA, без имён функций в первом разделе. Цифра только если она меняет решение.

Блок 2: репортёр (22:00)

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

Ночь, о которой ты докладываешь, читается с диска, а не с часов:
DAY=$(ls -1 reports/night | sort | tail -1)

1. git fetch; git pull --ff-only, если дерево чистое: отчёты закоммичены.
2. ls reports/night/$DAY: дождись пяти файлов (ceo, seo, pm, fixer, social).
   Каких-то нет: sleep 9 минут и пересчитай, максимум 6 кругов. Потом всё равно отправляй, назвав, кого нет.
3. Отчёт, в котором всё ещё написано «запуск в процессе», это оборванный запуск, а не отсутствующий.
   Скопируй то, что в нём есть, и напиши в «Что не сработало», что этого агента оборвали.
4. Из каждого отчёта бери только три раздела: «В двух словах», «Решить», «Проверить».
   Никогда не цитируй «Подробности».
5. Исправленные баги фиксера это пункты из трёх частей, разделённых « > »:
   что терпел пользователь > причина одной фразой > URL коммита.
   Копируй их символ в символ, вместе со ссылкой, в «Исправленные баги».
6. git status -sb и git log --oneline --since="4 hours ago": отчёт, который заявляет
   работу без коммита, изменённые файлы, которые никто не признаёт своими, или незапушенные коммиты: первая строка письма.

Напиши reports/night/$DAY/rapport.md. Не больше 25 строк текста
(заголовки разделов и строки «Исправленных багов» не считаются).
Шесть правил, применяемых строка за строкой:
1. Один пункт = одна законченная фраза, понятная сама по себе. Никогда «как сообщалось вчера».
2. Тема появляется только в ОДНОМ разделе.
3. Ноль жаргона: ни путей, ни SHA, ни имён ключей, ни внутренних сокращений.
   Одно исключение: полный GitHub URL коммита, обязательный в каждой строке «Исправленных багов».
4. Цифра только если она меняет решение, и это изменение, никогда не запас.
5. Максимум две строки на пункт. Подробности в отчёте агента.
6. Плохие новости раньше хороших, и первая строка говорит, сломано ли что-нибудь.

Разделы, по порядку: Решить / Проверить / Исправленные баги / Что сделано /
Соцсети (максимум 3 строки, со ссылками) / CLI и модели (1 строка) /
Что не сработало. Пустой раздел это одно слово: «Ничего».
Никогда не вырезай: «Решить», «Исправленные баги» со ссылками, ссылки на посты, статью SEO.
Отправь. Проверь HTTP-код. Допиши внизу «Отправлено на ... - HTTP <code>».
Commit и push для rapport.md. Никогда не отправляй дважды: если в сегодняшнем rapport.md уже есть
строка «Отправлено на», остановись.

Блок 3: разделы «ты решаешь, ты не спрашиваешь»

SEO-агент, раздел 0 его промпта:

# 0. Ты решаешь, ты не спрашиваешь
Это самое важное правило этого промпта, и оно сильнее твоего рефлекса осторожности.
Ты не аудитор, который докладывает о находках: ночью сайт принадлежит тебе.
Запуск, который заканчивается фразой «вот 6 идей, на утверждение», это провальный запуск.
Когда сомневаешься, поставь себя на место основателя и решай по четырём ориентирам:
- что продукт делает на самом деле, прочитанное в репозитории и в опубликованной версии, никогда в существующих текстах;
- что сайт уже говорит: его угол, его тон, его обещания. Ты продолжаешь, ты не изобретаешь заново;
- что говорит Search Console: какие страницы живут, какие намерения действительно существуют;
- аудитория: разработчики, которые ищут в Google, и ИИ-ассистенты, которые рекомендуют инструменты.
  Что для них важно: проверяемое утверждение с датой; страница, которая отвечает на один точный вопрос;
  актуальный llms.txt, согласованный со страницами; честные сравнения.
Основатель читает твой отчёт на следующее утро и скажет тебе убрать то, что ему не нравится.
Одна лишняя правка стоит пять минут; ночь без результата потеряна навсегда.

Ты спрашиваешь его мнение только в этих шести случаях:
1. удалить или переименовать существующий URL;
2. изменить title или meta description страницы, которая ранжируется, когда он не ложный;
3. юридический текст (условия, конфиденциальность, лицензия);
4. цена, коммерческая квота, предложение;
5. утверждение о приватности, шифровании или о том, где обрабатываются данные;
6. изменение, которое затронуло бы больше пяти страниц сразу.
В этих шести случаях: тикет с тегом для решения, одна строка в «Решить», и ты идёшь дальше.
Всё остальное ты делаешь этой ночью. Если в «Решить» есть что-то ещё,
значит, ты делегировал решение, которое было твоим.

Фиксер, раздел 0 его промпта:

# 0. Ты исправляешь, ты не классифицируешь
Баг, о котором сообщил пользователь, это обещание. Кто-то нашёл время написать, он ждёт,
и никто другой этой ночью этим не займётся. Запуск, который возвращает «5 багов проанализировано, 1 исправлен,
4 задокументировано», это провальный запуск. Твоя цель это пустая очередь: сначала баги пользователей,
от самых старых, потом остальные, пока их не останется.
Когда сомневаешься насчёт исправления, решай по трём ориентирам:
- что код делает сегодня, прочитанное, а не предположенное;
- чего пользователь явно ожидал, когда писал сообщение;
- наименьший риск: самое узкое исправление, которое устраняет причину, а не самое элегантное.
Спорное исправление стоит пять минут на откат; баг, оставленный ещё на месяц, стоит пользователя.

Оставить сообщённый баг без исправления можно только в трёх случаях, доказанных в тикете:
1. ты не нашёл причину после настоящего расследования: напиши, что ты исключил,
   а не просто «не воспроизводится»;
2. это не баг, это решение: база данных, биллинг, авторизация, шифрование, приватность,
   проиндексированный URL, поведение по умолчанию. Тикет для решения, с твоей рекомендацией;
3. проверка отклоняет твоё исправление, и ты не можешь её починить.
«Это большое», «это затрагивает несколько файлов», «я бы лучше спросил» не причины.
Один баг = один коммит. Затем тикет уходит в готово, и если о нём сообщил пользователь,
сообщение из двух фраз ставится в очередь на следующий релиз. Никогда «в ожидании»: эта колонка
принадлежит людям.
Твоя строка отчёта для каждого исправленного бага, копируемая дословно в утреннее письмо:
- <что терпел пользователь> > <причина, одной простой фразой> > <URL коммита>

Остальные четыре промпта (CEO, PM, хранитель документации, шаг 2 SEO) следуют тому же каркасу: загрузи навык, назови файлы, которые тебе можно писать, перечисли чтения по порядку, скажи, что идёт в тикет и что в отчёт, закончи меткой запуска.

Что не сработало и до сих пор не работает

Некоторые ночи попадают в раздел «Что не сработало» письма, и их стоит перечислить, потому что именно с этим ты столкнёшься.

• Пять агентов пушат в одну ветку в одну и ту же минуту. Push отклоняется, потому что удалённый репозиторий ушёл вперёд. Правило: git pull --ff-only, затем push, никогда не форсировать, а если это не удалось дважды, отчёт говорит об этом, и человек пушит утром. Такое случается примерно раз в неделю.
• Коммит, который захватил файл, подготовленный другим агентом. 29 сентября первый коммит SEO унёс удаление, которое хранитель документации добавил в индекс в общем чекауте. Ничего не потерялось (удаление было намеренным), но коммит приписан не тому агенту. С тех пор каждый коммит использует явные pathspec, и правило «файлы перечислены по одному» это не вопрос стиля.
• Диск, на котором в 20:10 кончилось свободное место, два вечера подряд. Внешняя для агентов причина, место вернулось само в 20:25, ни один файл не потерян. Но отчёты об этом говорят, потому что ночь с полным диском выглядит точно так же, как ночь, когда агент ничего не сделал.
• Репортёр, который 54 минуты ждёт отчёт, который не придёт. Шесть кругов по девять минут это потолок. Команда между двумя шагами в 22:00 выглядит как оборванный запуск, и письмо говорит «не закончил», что честно и немного тревожно читать.
• Первые недели повторяющихся находок. Правила 2 выше не существовало, пока основатель в четвёртый раз не написал «ты мне это говорил три дня назад».

Как настроить это у себя

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

1. Напиши промпт в библиотеке промптов. Начни с блока 1 выше как навыка и короткого промпта, который говорит, за что отвечает этот агент и какие файлы ему можно писать.
2. Создай запланированную задачу в проекте: ежедневно в нужный тебе час, роль, CLI и модель агента, промпт, а в расширенном блоке режим разрешений для запуска без присмотра. Привяжи её к машине, которая будет её выполнять, и включи «разбудить машину», если эта машина спит.
3. Создай папку reports/night/ в репозитории и закоммить её. Это и есть весь слой координации.
4. Добавь второго агента в тот день, когда первый начнёт создавать тикеты для кого-то другого: тег ceo-fix что-то значит, только если фиксер читает его следующей ночью.
5. Когда одна работа распадается на суждение и объём, сделай из неё команду из двух шагов с двумя моделями и пусть шаг 1 пишет раздел хендоффа, который читает шаг 2.

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

Rob, вот что мы делаем помимо кода. Промпты это и есть продукт.

Часто задаваемые вопросы

Нужен ли AgentsRoom, чтобы запускать агентов по расписанию вот так?

Нет. Строка cron и claude -p запустят сессию Claude Code в 20:00 на любой машине. Всё остальное ты пишешь сам: разбудить спящий компьютер, навёрстывать запуск, который машина пропустила, оставить один запуск за ночь, когда проект открыт на двух компьютерах, передать отчёт от одного агента второму на другой модели и увидеть на телефоне, что запуск застрял на вопросе. Запланированные задачи AgentsRoom берут на себя эти части, и семь агентов из этой статьи используют их все. Промпты и правила переносятся как есть, что бы ни запускало сессию.

Сколько стоит ночь семи агентов?

Они работают как сессии Claude Code на подписке Claude, как любой агент, запущенный в AgentsRoom, поэтому потокенного счёта за них нет, и стоимость одной ночи мы не публиковали. Держит её в рамках правило «одна ночь, один запуск»: триггер, сработавший дважды, или запуск, оборванный и начатый заново, не повторяет работу, потому что первое, что делает каждый агент, это проверяет, существует ли уже отчёт за эту ночь и закрыт ли он.

Безопасно ли разрешать агентам делать commit и push, когда никто не смотрит?

Безопасно благодаря тому, что им запрещено, а не тому, чего им велено хотеть. Общие правила запрещают git add -A, commit -a, принудительный push, stash, reset, checkout, clean, создание ветки и любой скрипт, который деплоит. Каждый коммит перечисляет свои файлы по одному, дерево проверяется через git status перед любой записью, а push, отклонённый из-за того, что удалённый репозиторий ушёл вперёд, решается через pull в режиме fast-forward или остаётся человеку. Утренняя проверка это список коммитов за ночь, а всё, что не так, откатывается revert за пять минут.

Почему агенты пишут отчёты в Markdown прямо в репозиторий, а не в дашборд?

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

Почему два из семи агентов это команды из двух шагов на двух разных моделях?

Потому что две половины работы это не одна и та же работа. SEO-шаг, который читает Search Console, решает, что на сайте стало неправдой, и пишет статью на английском и французском, требует суждения и работает на Fable. Перевести эту статью ещё на 18 языков, прогнать i18n-проверки и сборку это объём, и он работает на Opus с контекстом 1M. Первый шаг пишет в общем отчёте явный раздел хендоффа, второй делает только то, что перечислено в этом разделе. Так же разделена команда соцсетей: тексты и визуал на Fable, публикация в Chrome и благодарности на Opus.

Что происходит, когда запуск обрывается на середине?

Отчёт существует с первой минуты запуска, со строкой «запуск в процессе», и каждая законченная часть работы коммитится сразу. Поэтому запуск, оборванный в 21:40, оставляет частичный отчёт, свои коммиты и ни одного неотслеживаемого файла. Репортёр копирует частичный отчёт и пишет, что агента оборвали. Мы усвоили это на горьком опыте 9 сентября: два агента остановились в одну и ту же минуту, тот, что коммитил по ходу работы, ничего не потерял, другой оставил 45 изменённых файлов, которые никто не мог ни к кому отнести.