Проактивные агенты: Routines и запуск по событию
Тема 3/4: Архитектура агента → Урок 3/5
До сих пор Claude Code работал только после того, как вы ввели запрос и нажали Enter. Этот урок — о том, как убрать это ограничение. Функция Routines запускает сессии Claude Code без вашего участия: по расписанию или по событию — например, когда в GitHub открыт issue. Вы узнаете, почему самодельный запуск по cron требует целого слоя инфраструктуры, как устроены рутины, какие три решения нужно принять при создании любой из них — триггер, контекст, управляемость — и разберёте реальный пример: рутину, которая раз в неделю сверяет изменения в коде с документацией и открывает PR при расхождениях.
Всё, что вы делали с Claude Code в предыдущих уроках, начиналось одинаково: вы формулируете запрос, нажимаете Enter и ждёте результат. Инструмент мощный, но реактивный — сам он ничего не замечает и ничего не начинает. Идея этого урока: превратить Claude Code из инструмента, который ждёт нажатия Enter, в коллегу, который сам видит проблему и реагирует на неё. Для этого в Claude Code появилась функция Routines — автоматический запуск сессий по расписанию или по событию.
Почему самодельный запуск по cron — отдельный проект
Запустить Claude Code по расписанию можно и своими руками, например через cron. Но тогда вокруг промпта придётся построить и поддерживать целый слой инфраструктуры. Во-первых, нужно решить, где агент будет работать. Локальная машина не подходит: закрыли крышку ноутбука — сессия оборвалась. Значит, нужны хостинг, хранение состояния и аутентификация. Во-вторых, нужно решить, когда запускать сессии: строить обвязку над cron или поднимать собственные точки входа для запросов. В-третьих — и это самое неприятное — непонятно, как в такой схеме участвовать человеку. У сессии, запущенной без интерфейса, трудно понять, что агент делает прямо сейчас: нельзя посмотреть на его работу, направить его или продолжить сессию позже.
Что такое Routines
Routines — функция Claude Code, которая снимает все три проблемы. Вы задаёте четыре вещи: промпт, репозитории, к которым подключается сессия, коннекторы, с которыми ей разрешено работать, и триггер. Остальное берёт на себя управляемая инфраструктура Claude Code: хостинг, состояние сессии, авторизацию коннекторов. От вашего ноутбука не зависит ничего.
Триггеры бывают двух видов. Первый — расписание: рутина запускается в заданное время с заданной периодичностью. Второй — событие: поддерживаются встроенные события GitHub, а также ваши собственные события, которые вы отправляете на webhook — адрес для входящих запросов; данные события передаются сессии как контекст.
Важно, что каждая рутина — это обычная сессия Claude Code. Её можно открыть, наблюдать за ней, задавать вопросы по ходу, направлять и продолжать — из веба, командной строки или настольного приложения. Это тот же Claude Code, что и в терминале, просто запускается он без вас.
Пример: документация, которая успевает за кодом
Представьте команду, где поток изменений в коде заметно вырос: новые функции выходят быстро — это хорошо и для команды, и для пользователей. Тяжелее всего в такой ситуации тому, кто отвечает за документацию: успевать за потоком изменений вручную почти невозможно. Это как раз задача для рутины.
Решение начинается с команды /schedule внутри Claude Code. Вы вводите запрос: раз в неделю просматривай все новые изменения, слитые в main, сверяй их с репозиторием документации и создавай PR, если видишь расхождения. В ответ Claude задаёт уточняющие вопросы: в какое время запускать, как уведомлять о созданном PR — например, сообщением в Slack. После ответов рутина создана, и её видно в веб-интерфейсе.
Три решения любой рутины
Первое решение — триггер: когда запускать. Это может быть расписание, как в еженедельной сверке кода с документацией. А может быть событие: например, когда готовится новый релиз — сравнить релизную ветку с документацией; или когда в main слит PR с меткой «нужна документация» — запустить сессию по этому изменению.
Второе решение — контекст: что агенту нужно знать. Как минимум — репозитории: в примере с документацией это исходный код Claude Code, чтобы видеть новые изменения, и репозиторий документации, чтобы создавать в нём PR. Дальше — дополнительный контекст: например, маркетинговые материалы в Google Drive через коннектор, чтобы Claude писал теми же формулировками, что приняты в компании, и коннектор Slack для уведомлений. Правило простое: какой контекст у Claude — таков и потолок его успеха.
Третье решение — управляемость: как обеспечить качество результата. Здесь три приёма. Первый — проверка агента агентом, знакомая по многоагентным системам пара «генератор — критик»: одна рутина создаёт PR с документацией, вторая срабатывает на его создание и оставляет комментарии ещё до того, как до PR доберётся человек. Второй — наблюдение за живой сессией: открыть её в вебе, посмотреть, что происходит, задать вопрос, подтолкнуть в другую сторону или продолжить прошлую сессию. Третий — проверка результата: для документации команда отрисовывает изменённую страницу и убеждается, что она выглядит как ожидалось.
Как это выглядит в интерфейсе
В интерфейсе Claude.ai рутины живут в разделе code → routines. Скажем, первая рутина подключена к двум репозиториям — исходному коду Claude Code и документации, запускается по понедельникам в 10:00 и связана с GitHub и Slack. В её сессии видно, как Claude прочитал инструкции, просмотрел недавние PR и список изменений, сравнил их с документацией, нашёл расхождения и открыл PR. Вторая рутина запускается по событию «открыт issue» в репозитории документации: разобрать issue, и если это пробел в документации — открыть PR и написать в канал. Создание issue запускает сессию — и здесь управляемость видна на практике: если по этой теме PR уже существует, вы вмешиваетесь прямо по ходу и останавливаете сессию.
Ещё три примера рутин
Контроль деплоя. Триггер: конвейер доставки отправляет запрос на webhook после каждого деплоя. Контекст: исходный код сервиса, инструменты мониторинга вроде Datadog или Grafana, оповещения через Slack, почту или Twilio. Управляемость: сначала Claude только проводит расследование и выдаёт решение «откатывать или нет», а сам откат остаётся за человеком; со временем, когда доверие к решениям агента вырастет, откат по данным мониторинга можно доверить ему.
Дежурный следователь. Рутина, которая первой разбирает инциденты, пока дежурный инженер только открывает ноутбук.
Разбор бэклога для менеджера продукта. Раз в неделю прочитать накопившиеся задачи — issue в GitHub или сообщения в канале Slack, — помочь расставить приоритеты и открыть PR по самым важным пунктам.
Итог
Главная мысль: проактивные агенты лучше реактивных. Агент, который ждал, пока вы нажмёте Enter и сами создадите PR, превращается в коллегу, который реагирует на проблему и сам открывает PR. Routines существуют для того, чтобы вы не строили инфраструктуру, а сосредоточились на знании своей области и своих процессов. А начинается всё с одной команды — /schedule.