Тригери: режим вебхука

Ваш агент стартує тоді,
коли справді щось стається

Тригер відповідає на одне питання: коли стартує цей агент? Заплановане завдання відповідає годиною. Вебхук-тригер відповідає подією із зовнішнього світу. Відкривається pull-запит, ламається збірка, спрацьовує алерт, і агент уже працює.

AgentsRoom дає кожному тригеру публічну URL і секрет підпису. Вставте цю URL у GitHub, GitLab, Slack, Linear, Sentry або будь-що, що вміє надіслати POST з JSON. Виклик надходить, підпис перевіряється, payload стає змінними у вашій підказці, і у вашому проєкті стартує справжній агент зі своїм терміналом і своїм записом розмови.

Вебхук-тригерСлухає
POSTGitHubpull_requestДодати обмеження частоти запитів до API
Підпис перевірено
Фільтр збігся
Рецензент коду
{{event.title}} = Додати обмеження частоти запитів до API
Нічого не працює, поки нічого не стаєтьсяСтартує за подією

Один тригер, одна публічна URL. Подія надходить, підпис перевіряється, payload стає змінними підказки, і у вашому проєкті стартує агент.

Заплановані завдання розв'язали половину проблеми. Ви вже можете сказати агенту переглядати pull-запити щоранку о 8. Але більшість роботи, яку ви доручили б агенту, стається не о 8: вона стається, коли хтось відкриває pull-запит, коли збірка стає червоною, коли клієнт повідомляє про помилку о другій дня.

Досі єдиним способом це вловити було змусити агента стежити: запускати його за коротким розкладом, опитувати API, питати 'є щось нове?' і платити токенами за відповідь 'ні' кількасот разів на день. Це дорого, це повільно реагує і це погано масштабується тієї миті, коли ви захочете стежити за трьома репозиторіями.

Вебхук-тригер це перевертає. Сервіс сам вам каже. AgentsRoom дає вам URL, ви вставляєте її в GitHub, GitLab, Slack, Linear, Sentry або у свій CI, і нічого не працює, доки цей сервіс не звернеться до неї. Коли він звертається, агент стартує з подією, вже вписаною в його підказку. Нуль токенів, поки день тихий, і агент за роботою за кілька секунд, коли він не тихий.

Чому подія краща за цикл опитування

Ви перестаєте платити за тишу. Агент, який перевіряє репозиторій кожні п'ять хвилин, спалює повний хід контексту кожні п'ять хвилин, і майже кожен із цих ходів не знаходить нічого. Тригер не споживає рівно нічого, доки не надійде подія.

Реакція миттєва. Немає інтервалу, який треба підбирати, немає вікна, у якому pull-запит лежить одинадцять хвилин, бо опитування щойно відпрацювало. Агент стартує за викликом, тож рецензія вже чекає, коли автор оновить сторінку.

Подія приходить зі своїми даними. Payload розбирається на змінні, які ви вставляєте просто в підказку: заголовок, автор, URL, номер, гілка або весь сирий JSON. Агенту не треба йти й дізнаватися, що його запустило.

Це та сама панель, яку ви вже знаєте. Тригери зберігають список, перемикач увімкнення та вимкнення, історію по кожному запуску, вибір агента та прив'язку до машин, як у запланованих завдань. Вебхук: це просто ще одна відповідь на питання, коли це має спрацювати.

Один тригер, два способи спрацювати

Панель тримає обидва. Виберіть той, що відповідає тому, чого ви чекаєте.

За розкладом

Початковий режим, без змін. Кожні N хвилин, щогодини, щодня, щотижня або щомісяця, без жодного cron виразу. Для роботи, що належить годиннику: ранкова рецензія, понеділкова перевірка залежностей, п'ятничний changelog.

Вебхук

Агент чекає на подію замість години. AgentsRoom дає вам публічну URL і секрет підпису, ви вставляєте цю URL у сервіс, і тригер спрацьовує, коли той сервіс надсилає POST. Для роботи, що належить чомусь, що стається: pull-запит, невдала збірка, новий звіт про помилку.

Що запускати тригером

Реальні події та агент, якого ви хотіли б бачити на іншому кінці.

Переглядати кожен pull-запит, щойно він відкривається

Направте вебхук GitHub або GitLab на тригер, поставте фільтр на відкриття pull-запиту, і агент-рецензент візьметься за диф за кілька секунд. Автор отримує відгук, поки зміна ще свіжа в його голові.

Автоматично розслідувати червону збірку

Ваш CI може надіслати POST, коли конвеєр падає. Тригер запускає агента з гілкою та URL запуску в підказці, тож він читає завдання, що впало, і повертається з причиною замість червоного значка.

Тріажити збій тієї миті, коли про нього повідомили

Підключіть алерт Sentry до тригера. Новий виняток у продакшені запускає бекенд-агента із заголовком помилки та URL тікета, тож перший погляд на стек трейс стається ще до того, як хтось відкриє дашборд.

Запустити агента зі Slack

Слеш-команда Slack або вихідний вебхук може звернутися до URL тригера. Хтось пише запит у каналі, payload потрапляє в підказку, і агент береться за нього в потрібному проєкті.

Оцінити новий тікет, щойно його створили

Тікет, створений у GitHub, GitLab або Linear, запускає продуктового агента, який читає звіт, ставить питання, яких бракує, і перетворює його на щось, за що розробник може взятися.

Проганяти QA після кожного розгортання

Ваш конвеєр розгортання надсилає POST, коли реліз виходить. Тригер запускає QA-агента, який перевіряє додаток на тій версії, що щойно поїхала, замість розкладу, який не має нічого спільного з релізами.

Писати релізні нотатки на тег

Запушено тег, опубліковано реліз, і агент документації перетворює коміти на читабельні нотатки. Подія несе назву тега, тож агент точно знає, який діапазон підсумовувати.

Будь-що, що вміє надіслати POST з JSON

Немає списку інтеграцій, на який треба чекати. Cron на сервері, крок Zapier, інструмент моніторингу, ваш власний бекенд: якщо воно вміє надіслати підписаний POST на URL, воно вміє запустити агента у вашому проєкті.

Як працює вебхук-тригер, крок за кроком

Від порожньої форми до агента, який реагує на продакшен, за пару хвилин.

01

Створіть тригер

Відкрийте панель Тригери у своєму проєкті та створіть новий. Той самий список, той самий перемикач увімкнення та вимкнення, та сама історія, що й у запланованого завдання, бо це та сама панель.

02

Перемкніть його на Вебхук

Виберіть Вебхук замість режиму За розкладом. AgentsRoom генерує публічну URL для цього тригера і секрет підпису поруч із нею. Секрет можна перегенерувати будь-коли, щоб відрізати того, хто мав старий.

03

Вставте URL у сервіс

Покладіть її у вебхук GitHub чи GitLab, у застосунок Slack, в інтеграцію Linear чи Sentry або у свій CI. Передайте сервісу також секрет підпису, щоб виклики, які він надсилає, можна було перевірити.

04

Відфільтруйте те, що справді має спрацьовувати

Репозиторій надсилає багато подій. Додайте необов'язкову умову на payload, наприклад action, що дорівнює opened, і все інше буде проігноровано. Задайте ліміт сплесків, щоб гучний сервіс не запустив двадцять агентів за хвилину.

05

Покладіть подію у свою підказку

Напишіть підказку зі змінними події: заголовок, автор, URL, номер, гілка або весь payload. Вони підставляються, коли тригер спрацьовує, точно як змінні дати й часу, які вже підтримують заплановані завдання.

06

Відтворіть останній виклик повторно і випускайте

Редактор показує останній виклик, який отримав тригер, разом із сирим JSON, і відтворює його повторно одним кліком. Ви налаштовуєте вебхук, дивлячись на нього, а не вгадуючи, і коли все правильно, вмикаєте тригер.

Редактор Тригери в AgentsRoom у режимі вебхука: згенерована URL тригера, яку треба вставити в сервіс, з кнопкою Copy, поле секрету підпису, вибір джерела з Any service (JSON), GitHub, GitLab, Slack, Linear та Sentry, фільтр Only fire if, заданий як action == "opened", налаштування захисту від сплесків не більше одного запуску на 2 хв, і змінні події, доступні в підказці.
Редактор тригера в режимі вебхука: одна URL, яку треба вставити в сервіс, секрет підпису, необов'язковий фільтр, вікно захисту від сплесків і поля payload, уже зіставлені зі змінними підказки.

Ряд сервісів: це набір ярликів, а не список дозволених. Редактор так і пише під вибором, і саме тому перший пункт має назву Any service (JSON): працює будь-що, що вміє надіслати POST з тілом JSON. Вибір GitHub, GitLab, Slack, Linear чи Sentry додає рівно дві речі: власний заголовок підпису для перевірки та поля його payload, уже зіставлені зі змінними події. Ніщо не відхиляється через те, що його немає в списку.

Чипи змінних: це не документація, а кнопки. Клацніть по одному, щоб вставити його в підказку, а ті, які справді заповнив останній виклик, підсвічені. Під ними лежить останній виклик, який отримав тригер, тож ви пишете фільтр і підказку на реальному payload, який бачите, відтворюєте його повторно і вмикаєте тригер лише тоді, коли запуск виходить правильним.

Від події до агентаКрок 1 з 4
  1. Подія надходить на URL вашого тригера

    Сервіс надсилає POST зі своїм JSON. AgentsRoom звіряє підпис із вашим секретом і відхиляє все непідписане, а потім застосовує ваш фільтр, якщо ви його задали.

  2. Вона чекає, якщо нікого немає

    Ваша машина може бути вимкнена. Подія утримується до тижня і повторно відтворюється при наступному запуску, замість того щоб зникнути: та сама модель наздоганяння, яку вже використовують заплановані завдання.

  3. Її бере одна машина, і лише одна
    Робочий Mac
    Домашній Mac
    Машина збірки

    Якщо проєкт відкрито на кількох комп'ютерах, перший, хто підхопить подію, блокує її. Інші бачать, що вона зайнята, і йдуть далі, тож одна подія ніколи не породжує двох агентів.

  4. Агент виконується, один раз

    У проєкті відкривається справжній агент з роллю, провайдером і моделлю, які ви обрали, з власним терміналом, виглядом розмови та архівованим записом, який ви зможете перечитати пізніше.

Публічна 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-запиту, заголовок тікета, назва алерту.
  • {{event.author}}Хто це спричинив: автор pull-запиту, людина, яка відкрила тікет.
  • {{event.url}}Посилання назад на подію, щоб агент міг відкрити pull-запит або алерт.
  • {{event.number}}Номер pull-запиту або тікета, коли сервіс його надсилає.
  • {{event.branch}}Гілка, якої стосується подія: для пуша, pull-запиту або невдалої збірки.
  • {{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.

Імена змінних пишуться в подвійних фігурних дужках у полі підказки, точно як змінні дати й часу запланованого завдання.

GitHub
event.actionevent.numberevent.titleevent.bodyevent.authorevent.branchevent.baseevent.urlevent.repositoryevent.state
GitLab
event.actionevent.numberevent.titleevent.bodyevent.authorevent.branchevent.baseevent.urlevent.repositoryevent.state
Slack
event.actionevent.titleevent.bodyevent.authorevent.channelevent.urlevent.team
Linear
event.actionevent.numberevent.titleevent.bodyevent.authorevent.assigneeevent.stateevent.priorityevent.urlevent.team
Sentry
event.actionevent.titleevent.bodyevent.levelevent.projectevent.urlevent.count
Generic JSON
event.actionevent.titleevent.bodyevent.authorevent.urlevent.id

Що саме виконується і де

Та сама чесна модель виконання, що й у запланованих завдань, поширена на події.

Нічого не губиться, коли додаток закритий
Подія, яка надходить, поки AgentsRoom не працює, стає в чергу на сервері та повторно відтворюється при вашому наступному запуску, протягом щонайбільше тижня. Агент стартує трохи пізніше, а не ніколи.
Одна подія, один агент
Коли проєкт відкрито на кількох комп'ютерах, перша машина, яка бере подію, блокує її. Інші її пропускають. Дві машини ніколи не відповідають на той самий вебхук двічі.
Справжній агент, а не скрипт
Запуск відкриває справжнього агента в проєкті, з його роллю, провайдером, моделлю, рівнем зусиль, навичками та системним промптом, з власним терміналом і виглядом розмови. Ви можете перехопити керування посеред запуску.
Історія по кожному запуску
Кожне спрацювання потрапляє в історію тригера разом із тим, що написав його агент, і його можна прочитати пізніше, навіть після закриття сесії, і з іншої машини, де виконано вхід у той самий обліковий запис.

Звідки беруться події

Запустити агента може будь-що, що вміє надіслати підписаний POST з тілом JSON. Ось ті, які підключають першими.

Ваш CI, ваш бекенд, будь-що

Крок конвеєра, інструмент моніторингу, внутрішній сервіс, shell-скрипт із curl. Немає інтеграції, яку треба замовляти: POST із тілом JSON і підписом, ось і весь контракт.

GitHub і GitLab

Відкриті, переглянуті чи злиті pull-запити та merge-запити, створені тікети, пуші, релізи, невдалі workflow. Класичне джерело, і те, у якого найкорисніший payload.

Slack

Слеш-команда або вихідний вебхук перетворює повідомлення в каналі на запуск агента в потрібному проєкті. Підписи Slack перевіряються через X-Slack-Signature.

Linear і Sentry

Тікет, переміщений в іншу колонку, новий виняток у продакшені, алерт про регресію. Трекер спрацьовує, агент стартує з тікетом або помилкою в підказці.

Друга половина тієї самої панелі

Тригери та заплановані завдання: це одна функція з двома відповідями на те саме питання. Заплановане завдання: це тригер, чия подія є годинником. Вебхук-тригер: це заплановане завдання, чиїм розкладом є зовнішній світ. Вони живуть в одному списку, ділять ту саму конфігурацію агента, той самий перемикач увімкнення, ту саму історію запусків і ту саму прив'язку до машин.

Тож ви вибираєте під задачу, а не під інструмент. Аудит залежностей лишається на ранок понеділка, бо ніщо ззовні не повідомляє, що пакет застарів. Перегляд pull-запитів переїжджає на вебхук, бо GitHub уже знає точну секунду, коли це має статися. Прочитайте сторінку запланованих завдань, щоб побачити годинниковий бік цієї родини.

Дивіться Заплановані завдання, годинниковий бік тієї самої панелі

FAQ

Що таке вебхук-тригер в AgentsRoom?

Це тригер, який запускає AI агента, коли зовнішній сервіс надсилає йому подію, а не у визначений час. AgentsRoom дає тригеру публічну URL і секрет підпису; ви вставляєте цю URL у GitHub, GitLab, Slack, Linear, Sentry або будь-який інструмент, що вміє надіслати POST з JSON. Коли цей сервіс звертається до неї, підпис перевіряється, застосовується ваш необов'язковий фільтр, і у вашому проєкті стартує агент, у якого payload уже доступний як змінні підказки.

Чим це відрізняється від запланованого завдання?

Змінюється лише питання, коли це спрацьовує. Заплановане завдання спрацьовує за годинником: кожні N хвилин, щогодини, щодня, щотижня або щомісяця. Вебхук-тригер спрацьовує за подією ззовні. Усе інше спільне: той самий список, той самий перемикач увімкнення та вимкнення, та сама конфігурація агента, та сама історія по кожному запуску, та сама прив'язка до машин.

Чому б просто не змусити агента опитувати API?

Бо опитування коштує токенів на кожному циклі, і майже кожен цикл не знаходить нічого. Агент, який перевіряє репозиторій кожні п'ять хвилин, виконує повний хід кожні п'ять хвилин, щоб відповісти 'ні'. Вебхук-тригер не споживає нічого, поки нічого не стається, і реагує за кілька секунд, коли щось таки стається. У цьому весь економічний аргумент на користь функції.

Чи безпечно виставляти URL тригера назовні?

Самої URL недостатньо, щоб щось запустити. Кожен виклик має довести, що надходить від сервісу, який тримає ваш секрет: X-Hub-Signature-256 для GitHub, X-Slack-Signature для Slack, спільний токен X-Gitlab-Token для GitLab, звичайний HMAC від сирого тіла для Linear, Sentry та інших джерел. Виклик без заголовка підпису відхиляється, його ніколи не пропускають. Секрет показано в редакторі, і його можна перегенерувати будь-коли, що миттєво робить недійсним усе, що користувалося старим.

Чи можу я спрацьовувати лише на деякі події?

Так. Репозиторій надсилає значно більше подій, ніж вам потрібно агентів, тож тригер приймає необов'язкову умову на payload, наприклад action, що дорівнює opened. Події, які не збігаються, ігноруються, і нічого не породжується. Є також ліміт сплесків: щонайбільше один запуск на часове вікно, а виклики, що надходять усередині цього вікна, групуються разом.

Що станеться, якщо AgentsRoom закритий, коли надходить подія?

Подія стає в чергу на сервері та повторно відтворюється наступного разу, коли ви запускаєте додаток, тож вона виконується пізніше, а не ніколи. Події з черги зберігаються тиждень, чого вистачає на ноутбук, закритий на довгі вихідні, і водночас не призводить до відтворення місяця застарілої роботи, коли ви повертаєтеся. Це та сама модель у додатку плюс наздоганяння, яку використовують заплановані завдання. Вебхук-тригери не запускають вашого агента в хмарі: агент завжди виконується на вашій машині, у вашому проєкті.

У мене проєкт відкрито на двох комп'ютерах. Чи запуститься агент двічі?

Ні. Подія споживається один раз. Перша машина, яка її підхоплює, блокує її, а інші бачать, що вона зайнята, і пропускають її. Ви також можете закріпити тригер за конкретними машинами, точно як заплановане завдання, якщо хочете, щоб ним володів певний комп'ютер.

Що я можу підставити в підказку з події?

Payload розбирається на змінні, які ви пишете просто в поле підказки, у подвійних фігурних дужках: event.title, event.author, event.url, event.number, event.branch і payload для всього сирого JSON. Вони підставляються, коли тригер спрацьовує, так само, як змінні дати й часу запланованого завдання.

Як мені знати, що мій вебхук налаштовано правильно?

Редактор показує останній виклик, який отримав тригер, разом із сирим тілом JSON, і дозволяє відтворити його повторно одним кліком. Тож ви налаштовуєте фільтр і підказку на реальному payload, який бачите, а потім відтворюєте повторно, доки запуск не стане правильним, замість того щоб пушити тестові коміти, аби це з'ясувати.

Які сервіси підтримуються?

Будь-який сервіс, що вміє надіслати підписаний POST з тілом JSON. GitHub, GitLab, Slack, Linear і Sentry підключають першими, бо їхні payload багаті, але списку дозволених немає: завдання CI, інструмент моніторингу, ваш власний бекенд чи curl у shell-скрипті працюють точно так само.

Це візуальний конструктор автоматизацій з багатокроковими сценаріями?

Ні, і він не намагається ним бути. У тригера одна робота: вирішити, коли стартує агент, і передати йому подію. Багатокрокова частина: це сам агент, який читає код, запускає інструменти й робить роботу. Якщо ви хочете, щоб кілька агентів передавали роботу одне одному, це Команди агентів, а не полотно сценаріїв.

Чи може AgentsRoom надсилати вебхуки назовні, в інші сервіси?

Тригери працюють лише на вхід: AgentsRoom отримує події, він їх не надсилає. Якщо ви хочете, щоб агент звернувся до зовнішнього сервісу наприкінці запуску, це робота самого агента, з інструментами та MCP серверами, які ви йому дали.

Добре поєднується з

Досить опитувати. Починайте реагувати.

Завантажте AgentsRoom, вставте одну URL у GitHub, GitLab, Slack, Linear чи Sentry і дозвольте події запускати агента. Нічого не працює, поки нічого не стається.

БезкоштовноЗавантажити AgentsRoom

Додаток-компаньйон: контролюйте своїх агентів на ходу

Використовуйте свого: Claude, Codex, Antigravity CLI або іншого AI-провайдера.

Отримати розширення
Chrome Web Store

Надсилайте баги та запити прямо у свій публічний беклог.

Погляд на AgentsRoom в дії.

Кілька проектів
Багато постачальників
Кілька агентів
Статус в реальному часі
Різниця файлів і коміт
Мобільний компаньйон
Попередній перегляд в реальному часі
Команди агентів
Автоматизація браузера
Розробка, орієнтована на беклог
Бібліотека підказок
Бібліотека навичок
Переглянути всі функції