Ваш агент стартует, когда
действительно что-то происходит
Триггер отвечает на один вопрос: когда стартует этот агент? Запланированная задача отвечает часом. Webhook-триггер отвечает событием из внешнего мира. Открывается pull request, ломается сборка, срабатывает алерт, и агент уже работает.
AgentsRoom выдаёт каждому триггеру публичный URL и секрет для подписи. Вставьте этот URL в GitHub, GitLab, Slack, Linear, Sentry или что угодно, умеющее отправлять POST с JSON. Приходит вызов, подпись проверяется, payload превращается в переменные вашего промпта, и в вашем проекте стартует настоящий агент со своим терминалом и сохранённой историей сессии.
Один триггер, один публичный URL. Приходит событие, проверяется подпись, payload становится переменными промпта, и в вашем проекте стартует агент.
Запланированные задачи решили половину проблемы. Вы уже можете поручить агенту проверять pull request каждое утро в 8. Но большая часть работы, которую вы бы отдали агенту, случается не в 8: она случается, когда кто-то открывает pull request, когда сборка становится красной, когда клиент заводит баг в два часа дня.
До сих пор поймать это можно было только одним способом: заставить агента наблюдать. Запускать его по короткому расписанию, опрашивать API, спрашивать «что-нибудь новое?» и платить токенами за ответ «нет» несколько сотен раз в день. Это дорого, это медленно реагирует и это плохо масштабируется, как только вам нужно следить за тремя репозиториями.
Webhook-триггер переворачивает это. Сервис сам вам сообщает. AgentsRoom выдаёт вам URL, вы вставляете его в GitHub, GitLab, Slack, Linear, Sentry или свой CI, и ничего не выполняется, пока этот сервис не вызовет его. А когда вызовет, агент стартует с событием, уже вписанным в его промпт. Ноль токенов, пока день спокойный, и агент за работой через считаные секунды, когда он спокойным быть перестал.
Почему событие лучше цикла опроса
Вы перестаёте платить за тишину. Агент, который проверяет репозиторий каждые пять минут, сжигает полный круг контекста каждые пять минут, и почти каждый такой круг не находит ничего. Триггер не потребляет ровно ничего, пока не придёт событие.
Реакция мгновенная. Нет интервала, который надо подбирать, нет окна, в котором pull request лежит одиннадцать минут, потому что опрос только что прошёл. Агент стартует по вызову, поэтому ревью уже ждёт, когда автор обновит страницу.
Событие приходит вместе со своими данными. Payload разбирается на переменные, которые вы вставляете прямо в промпт: заголовок, автор, URL, номер, ветка или весь сырой JSON. Агенту не нужно идти и выяснять, что его запустило.
Это та же панель, которую вы уже знаете. Триггеры сохраняют список, переключатель включения, историю по каждому запуску, выбор агента и привязку к машинам, как у запланированных задач. Webhook: просто ещё один ответ на вопрос «когда это срабатывает».
Один триггер, два способа сработать
Панель вмещает оба. Выберите тот, что подходит к тому, чего вы ждёте.
По расписанию
Исходный режим, без изменений. Каждые N минут, ежечасно, ежедневно, еженедельно или ежемесячно, и никаких cron-выражений писать не нужно. Для работы, которая принадлежит часам: утреннее ревью, понедельничная проверка зависимостей, пятничный changelog.
Webhook
Агент ждёт событие, а не час. AgentsRoom выдаёт вам публичный URL и секрет для подписи, вы вставляете URL в сервис, и триггер срабатывает, когда этот сервис отправляет POST. Для работы, которая принадлежит происходящему: pull request, упавшая сборка, новый баг-репорт.
Что запускать по триггеру
Настоящие события и агент, которого вы бы хотели видеть на другом конце.
Проверять каждый pull request в момент открытия
Направьте webhook GitHub или GitLab на триггер, отфильтруйте по открытию pull request, и агент-ревьюер возьмётся за diff через считаные секунды. Автор получает отклик, пока изменение ещё свежо у него в голове.
Разбирать красную сборку автоматически
Ваш CI умеет отправлять POST, когда пайплайн падает. Триггер запускает агента с веткой и URL запуска в промпте, поэтому агент читает упавший job и возвращается с причиной, а не с красным значком.
Разбирать краш в момент, когда о нём сообщили
Подключите алерт Sentry к триггеру. Новое исключение на продакшене запускает бэкенд-агента с заголовком ошибки и URL issue, поэтому первый взгляд на стек-трейс случается раньше, чем кто-либо откроет дашборд.
Запускать агента из Slack
Slash-команда Slack или исходящий webhook может обратиться к URL триггера. Кто-то пишет запрос в канале, payload попадает в промпт, и агент берёт его в работу в нужном проекте.
Прорабатывать новый issue сразу после его создания
Созданный в GitHub, GitLab или Linear issue запускает продуктового агента, который читает описание, задаёт недостающие вопросы и превращает его в то, что разработчик может взять в работу.
Прогонять QA-проход после каждого деплоя
Ваш деплой-пайплайн отправляет POST, когда выходит релиз. Триггер запускает QA-агента, который гоняет приложение на только что выпущенной версии, а не по расписанию, которое никак не связано с релизами.
Писать release notes по тегу
Тег запушен, релиз опубликован, и агент документации превращает коммиты в читаемые заметки. Событие несёт имя тега, поэтому агент точно знает, какой диапазон резюмировать.
Всё, что умеет отправлять POST с JSON
Никакого списка интеграций, которого нужно ждать. Cron на сервере, шаг в Zapier, система мониторинга, ваш собственный бэкенд: если оно умеет отправить подписанный POST на URL, оно умеет запустить агента в вашем проекте.
Как работает webhook-триггер, шаг за шагом
От пустой формы до агента, который реагирует на продакшен, за пару минут.
Создайте триггер
Откройте панель триггеров на своём проекте и создайте новый. Тот же список, тот же переключатель включения и выключения, та же история, что и у запланированной задачи, потому что это та же самая панель.
Переключите его в режим Webhook
Выберите «Webhook» вместо «По расписанию». AgentsRoom генерирует публичный URL для этого триггера и рядом с ним секрет для подписи. Секрет можно перегенерировать в любой момент, когда вы захотите отрезать того, у кого остался старый.
Вставьте URL в сервис
Положите его в webhook GitHub или GitLab, в приложение Slack, в интеграцию Linear или Sentry либо в свой CI. Передайте сервису и секрет для подписи, чтобы отправляемые им вызовы можно было проверить.
Отфильтруйте то, что действительно должно срабатывать
Репозиторий шлёт много событий. Добавьте необязательное условие по payload, например action равно opened, и всё остальное будет проигнорировано. Задайте лимит на всплеск, чтобы шумный сервис не смог запустить двадцать агентов за минуту.
Поместите событие в свой промпт
Напишите промпт с переменными события: заголовок, автор, URL, номер, ветка или весь payload. Они подставляются, когда триггер срабатывает, ровно как переменные даты и времени, которые запланированные задачи уже поддерживают.
Повторите последний вызов и выкатывайте
Редактор показывает последний вызов, который получил триггер, включая сырой JSON, и отправляет его повторно в один клик. Вы настраиваете webhook, глядя на него, а не гадая, и когда всё верно, включаете триггер.
Ряд сервисов представляет собой набор ярлыков, а не белый список. Редактор прямо говорит об этом под выбором источника, и именно поэтому первым пунктом идёт Any service (JSON): работает всё, что умеет отправить POST с телом JSON. Выбор GitHub, GitLab, Slack, Linear или Sentry добавляет ровно две вещи: собственный заголовок подписи для проверки и поля его payload, уже сопоставленные с переменными события. Ничему не отказывают из-за того, что его нет в списке.
Чипы переменных: это не документация, а кнопки. Нажмите на одну, и она вставится в промпт, а те, которые действительно заполнил последний вызов, подсвечены. Под ними лежит последний вызов, полученный триггером, поэтому вы пишете фильтр и промпт на настоящем payload, который видите своими глазами, отправляете его повторно и включаете триггер только тогда, когда запуск выходит верным.
- Событие приходит на URL вашего триггера
Сервис отправляет свой JSON через POST. AgentsRoom проверяет подпись по вашему секрету и отклоняет всё, что не подписано, затем применяет ваш фильтр, если вы его задали.
- Оно ждёт, если никого нет на месте
Ваша машина может быть выключена. Событие удерживается до недели и отправляется повторно при следующем запуске приложения, а не теряется: та же модель навёрстывания, что уже используют запланированные задачи.
- Событие берёт одна машина, и только однаMac в офисеMac домаСборочный сервер
Если проект открыт на нескольких компьютерах, тот, кто первым возьмёт событие, блокирует его за собой. Остальные видят, что оно занято, и идут дальше, поэтому одно событие никогда не порождает двух агентов.
- Агент выполняется, один раз
В проекте открывается настоящий агент с выбранными вами ролью, провайдером и моделью, со своим терминалом, своим окном переписки и сохранённой в архиве историей, которую вы сможете перечитать позже.
Публичный URL, который не является открытой дверью
URL доступен из интернета, поэтому триггер решает, что он принимает, до того как что-либо запустится.
Каждый вызов подписан
AgentsRoom проверяет каждый вызов по вашему секрету, прежде чем что-либо запустится: X-Hub-Signature-256 для GitHub, X-Slack-Signature для Slack, общий токен X-Gitlab-Token для GitLab и обычный HMAC от сырого тела для Linear, Sentry и произвольных источников. Вызов без подписи отклоняется, поэтому знания URL недостаточно, чтобы запустить агента на вашей машине.
Меняйте секрет когда захотите
Секрет для подписи показан в редакторе, и его можно перегенерировать прямо там. Старые вызовы сразу перестают проходить проверку, а именно это вам и нужно в тот день, когда сервис выводят из эксплуатации или секрет утекает в лог.
Фильтр по payload
Необязательное условие решает, заслуживает ли событие агента. Срабатывать только когда action равно opened, только на одной ветке, только для одной метки. Всё, что не совпало, отбрасывается, ничего не запуская.
Защита от всплеска
Не больше одного запуска за временное окно. Сервис, который шлёт тридцать событий за десять секунд, не запустит тридцать агентов: вызовы внутри окна группируются, и их покрывает один запуск.
Payload становится вашим промптом
JSON, который присылает сервис, разбирается на переменные, которые вы пишете прямо в промпте. Они подставляются в момент срабатывания, как переменные даты и времени, которые уже используют запланированные задачи.
Напишите промпт один раз, и каждый запуск получит данные того события, которое его запустило.
{{event.title}}Заголовок события: заголовок pull request, заголовок issue, имя алерта.{{event.author}}Кто его вызвал: автор pull request, человек, открывший issue.{{event.url}}Ссылка обратно на событие, чтобы агент мог открыть pull request или алерт.{{event.number}}Номер pull request или issue, когда сервис его присылает.{{event.branch}}Ветка, которой касается событие, для push, pull request или упавшей сборки.{{payload}}Весь сырой JSON, для всего, что не покрывают именованные переменные.
Review pull request #{{event.number}} "{{event.title}}" opened by {{event.author}} on branch {{event.branch}}. Read the diff at {{event.url}} and reply with the risky parts first.Имена переменных пишутся в поле промпта в двойных фигурных скобках, ровно как переменные даты и времени у запланированной задачи.
event.actionevent.numberevent.titleevent.bodyevent.authorevent.branchevent.baseevent.urlevent.repositoryevent.stateevent.actionevent.numberevent.titleevent.bodyevent.authorevent.branchevent.baseevent.urlevent.repositoryevent.stateevent.actionevent.titleevent.bodyevent.authorevent.channelevent.urlevent.teamevent.actionevent.numberevent.titleevent.bodyevent.authorevent.assigneeevent.stateevent.priorityevent.urlevent.teamevent.actionevent.titleevent.bodyevent.levelevent.projectevent.urlevent.countevent.actionevent.titleevent.bodyevent.authorevent.urlevent.idЧто на самом деле выполняется и где
Та же честная модель выполнения, что и у запланированных задач, расширенная на события.
Откуда приходят события
Запустить агента может всё, что умеет отправить подписанный POST с телом JSON. Вот те, которые подключают первыми.
Ваш CI, ваш бэкенд, что угодно
Шаг пайплайна, система мониторинга, внутренний сервис, shell-скрипт с curl. Не нужно запрашивать никакую интеграцию: POST с телом JSON и подписью, вот и весь контракт.
GitHub и GitLab
Открытые, отревьюенные или влитые pull request и merge request, созданные issue, push, релизы, падающие workflow. Классический источник и тот, у которого самый полезный payload.
Slack
Slash-команда или исходящий webhook превращает сообщение в канале в запуск агента в нужном проекте. Подписи Slack проверяются через X-Slack-Signature.
Linear и Sentry
Issue, перемещённый в колонку, новое исключение на продакшене, алерт о регрессии. Трекер срабатывает, агент стартует с тикетом или ошибкой в промпте.
Вторая половина той же панели
Триггеры и запланированные задачи: это одна функция с двумя ответами на один и тот же вопрос. Запланированная задача: это триггер, событием которого служат часы. Webhook-триггер: это запланированная задача, расписанием которой служит внешний мир. Они живут в одном списке, у них общая конфигурация агента, общий переключатель включения, общая история запусков и общая привязка к машинам.
Поэтому вы выбираете под работу, а не под инструмент. Аудит зависимостей остаётся на утро понедельника, потому что снаружи никто не объявляет, что пакет устарел. Ревью pull request переезжает на webhook, потому что GitHub и так знает точную секунду, когда это должно произойти. Про сторону часов в этой паре читайте на странице запланированных задач.
Смотрите «Запланированные задачи», сторону часов в той же панелиFAQ
Что такое webhook-триггер в AgentsRoom?
Это триггер, который запускает ИИ-агента, когда внешний сервис присылает ему событие, а не в заданное время. AgentsRoom выдаёт триггеру публичный URL и секрет для подписи; вы вставляете этот URL в GitHub, GitLab, Slack, Linear, Sentry или любой инструмент, умеющий отправлять POST с JSON. Когда этот сервис обращается к URL, подпись проверяется, применяется ваш необязательный фильтр, и в вашем проекте стартует агент, у которого payload уже доступен в виде переменных промпта.
Чем это отличается от запланированной задачи?
Меняется только ответ на вопрос «когда это срабатывает». Запланированная задача срабатывает по часам: каждые N минут, ежечасно, ежедневно, еженедельно или ежемесячно. Webhook-триггер срабатывает по событию извне. Всё остальное общее: тот же список, тот же переключатель включения и выключения, та же конфигурация агента, та же история по каждому запуску, та же привязка к машинам.
Почему бы просто не заставить агента опрашивать API?
Потому что опрос стоит токенов на каждом круге, и почти каждый круг не находит ничего. Агент, проверяющий репозиторий каждые пять минут, каждые пять минут отрабатывает полный круг, чтобы ответить «нет». Webhook-триггер не потребляет ничего, пока ничего не происходит, и реагирует за считаные секунды, когда что-то происходит. В этом весь экономический аргумент в пользу этой функции.
Безопасно ли выставлять URL триггера наружу?
Одного URL недостаточно, чтобы что-то запустить. Каждый вызов обязан доказать, что он пришёл от сервиса, у которого есть ваш секрет: X-Hub-Signature-256 для GitHub, X-Slack-Signature для Slack, общий токен X-Gitlab-Token для GitLab, обычный HMAC от сырого тела для Linear, Sentry и произвольных источников. Вызов без заголовка подписи отклоняется, его никогда не пропускают. Секрет показан в редакторе, и его можно перегенерировать в любой момент, что немедленно обесценивает всё, что пользовалось старым.
Могу ли я срабатывать только на некоторые события?
Да. Репозиторий шлёт куда больше событий, чем вы хотите запусков агентов, поэтому триггер принимает необязательное условие по payload, например action равно opened. События, которые не совпали, игнорируются, и ничего не запускается. Есть и лимит на всплеск: не больше одного запуска за временное окно, а вызовы, пришедшие внутри этого окна, группируются вместе.
Что происходит, если AgentsRoom закрыт в момент прихода события?
Событие встаёт в очередь на сервере и отправляется повторно при следующем запуске приложения, поэтому оно выполняется с опозданием, а не никогда. События из очереди хранятся неделю: этого хватает на ноутбук, закрытый на длинные выходные, и при этом по возвращении вам не воспроизведут месяц устаревшей работы. Это та же модель «внутри приложения плюс навёрстывание», что и у запланированных задач. Webhook-триггеры не выполняют вашего агента в облаке: агент всегда работает на вашей машине, в вашем проекте.
У меня проект открыт на двух компьютерах. Выполнится ли агент дважды?
Нет. Событие потребляется один раз. Машина, которая первой его подхватит, блокирует его за собой, а остальные видят, что оно занято, и пропускают его. Вы также можете закрепить триггер за конкретными машинами, ровно как запланированную задачу, если хотите, чтобы им владел определённый компьютер.
Что из события я могу поместить в промпт?
Payload разбирается на переменные, которые вы пишете прямо в поле промпта, в двойных фигурных скобках: event.title, event.author, event.url, event.number, event.branch и payload для всего сырого JSON. Они подставляются, когда триггер срабатывает, так же как переменные даты и времени у запланированной задачи.
Как понять, что мой webhook подключён правильно?
Редактор показывает последний вызов, который получил триггер, включая сырое тело JSON, и позволяет отправить его повторно в один клик. Так вы настраиваете фильтр и промпт на настоящем payload, который видите своими глазами, и повторяете отправку, пока запуск не станет верным, вместо того чтобы пушить тестовые коммиты ради выяснения.
Какие сервисы поддерживаются?
Любой сервис, который умеет отправить подписанный POST с телом JSON. GitHub, GitLab, Slack, Linear и Sentry подключают первыми, потому что их payload богатые, но списка разрешённых нет: job в CI, система мониторинга, ваш собственный бэкенд или curl в shell-скрипте работают ровно так же.
Это визуальный конструктор автоматизаций с многошаговыми сценариями?
Нет, и он к этому не стремится. У триггера одна работа: решить, когда стартует агент, и передать ему событие. Многошаговая часть: это сам агент, который читает код, запускает инструменты и делает работу. Если вы хотите, чтобы несколько агентов передавали работу друг другу, это «Команды агентов», а не полотно сценариев.
Может ли AgentsRoom отправлять webhook наружу, в другие сервисы?
Триггеры работают только на приём: AgentsRoom получает события, но не отправляет их. Если вы хотите, чтобы агент обратился к внешнему сервису в конце запуска, это работа самого агента, с теми инструментами и MCP-серверами, которые вы ему дали.
Хорошо сочетается с
Запланированные задачи
Сторона часов в той же панели. Каждые N минут, ежечасно, ежедневно, еженедельно или ежемесячно, и никаких cron-выражений писать не нужно.
Доска задач Backlog
Перетащите задачу в колонку, и агент берёт её в работу. Триггер делает то же самое, только перетаскивает внешнее событие.
Команды агентов
Агенты Dev, QA и PM, которые передают работу друг другу. Направьте триггер на команду, и событие запустит всю рутину.
AgentsRoom MCP
Инструменты, которыми агент читает бэклог, память и библиотеку промптов. Агент, запущенный триггером, получает их как любой другой.
Уведомления агентов
Узнавайте в тот же момент, когда триггер сработал, на рабочем столе и на телефоне, одним касанием открывая запущенного им агента.
Удалённый флот
Несколько машин в одном аккаунте. Закрепите триггер за той, которая должна на него отвечать, и агента запустит только она.
Хватит опрашивать. Начните реагировать.
Скачайте AgentsRoom, вставьте один URL в GitHub, GitLab, Slack, Linear или Sentry и позвольте событию запускать агента. Ничего не работает, пока ничего не происходит.
Приложение-компаньон: следите за агентами на ходу
Используйте Claude, Codex, Antigravity CLI или другого поставщика AI.
Отправляйте баги и запросы прямо в ваш публичный бэклог.
Взгляд на AgentsRoom в действии.