Twój agent startuje, gdy
naprawdę coś się dzieje
Wyzwalacz odpowiada na jedno pytanie: kiedy ten agent startuje? Zaplanowane zadanie odpowiada godziną. Wyzwalacz webhook odpowiada zdarzeniem ze świata zewnętrznego. Otwiera się pull request, psuje się build, odpala alert, a agent już działa.
AgentsRoom nadaje każdemu wyzwalaczowi publiczny adres URL i sekret do podpisywania. Wklejasz ten adres do GitHuba, GitLaba, Slacka, Lineara, Sentry albo czegokolwiek, co potrafi wysłać POST z JSON-em. Wywołanie przychodzi, podpis zostaje zweryfikowany, payload staje się zmiennymi Twojego promptu, a w Twoim projekcie startuje prawdziwy agent, z własnym terminalem i archiwalnym zapisem rozmowy.
Jeden wyzwalacz, jeden publiczny adres URL. Zdarzenie przychodzi, podpis zostaje sprawdzony, payload staje się zmiennymi promptu, a w Twoim projekcie startuje agent.
Zaplanowane zadania rozwiązały połowę problemu. Już dziś możesz kazać agentowi przeglądać pull requesty każdego ranka o 8. Ale większość pracy, którą powierzyłbyś agentowi, nie dzieje się o 8: dzieje się wtedy, gdy ktoś otwiera pull requesta, gdy build robi się czerwony, gdy klient zgłasza błąd o drugiej po południu.
Do tej pory jedynym sposobem, żeby to złapać, było kazać agentowi pilnować: uruchamiać go w krótkim harmonogramie, odpytywać API, pytać „coś nowego?” i płacić tokenami za odpowiedź „nie” kilkaset razy dziennie. To drogie, reaguje wolno i fatalnie się skaluje w chwili, gdy chcesz pilnować trzech repozytoriów.
Wyzwalacz webhook odwraca to. To serwis daje Ci znać. AgentsRoom daje Ci adres URL, wklejasz go do GitHuba, GitLaba, Slacka, Lineara, Sentry albo swojego CI, i nic się nie uruchamia, dopóki ten serwis nie wywoła tego adresu. Gdy to zrobi, agent startuje ze zdarzeniem już w prompcie. Zero tokenów, gdy dzień jest spokojny, i agent na miejscu w kilka sekund, gdy spokojny nie jest.
Dlaczego zdarzenie bije pętlę odpytywania
Przestajesz płacić za ciszę. Agent, który sprawdza repozytorium co pięć minut, spala pełny obieg kontekstu co pięć minut, a prawie żaden z tych obiegów niczego nie znajduje. Wyzwalacz nie zużywa dokładnie nic, dopóki zdarzenie nie przyjdzie.
Reakcja jest natychmiastowa. Żadnego interwału do dostrojenia, żadnego okna, w którym pull request czeka jedenaście minut, bo odpytywanie właśnie się wykonało. Agent startuje na wywołanie, więc recenzja czeka już wtedy, gdy autor odświeża stronę.
Zdarzenie przychodzi ze swoimi danymi. Payload jest rozkładany na zmienne, które wrzucasz prosto do promptu: tytuł, autor, adres URL, numer, gałąź albo cały surowy JSON. Agent nie musi iść i szukać tego, co go uruchomiło.
To ten sam panel, który już znasz. Wyzwalacze zachowują listę, przełącznik włącz/wyłącz, historię per uruchomienie, wybór agenta i zakres per maszyna, znane z zaplanowanych zadań. Webhook to po prostu kolejna odpowiedź na pytanie, kiedy to ma wystartować.
Jeden wyzwalacz, dwa sposoby odpalenia
Panel mieści oba. Wybierz ten, który pasuje do tego, na co czekasz.
Zaplanowany
Pierwotny tryb, bez zmian. Co N minut, co godzinę, codziennie, co tydzień lub co miesiąc, bez wyrażenia cron do napisania. Do pracy, która należy do zegara: poranny przegląd, poniedziałkowe sprawdzenie zależności, piątkowy changelog.
Webhook
Agent czeka na zdarzenie zamiast na godzinę. AgentsRoom daje Ci publiczny adres URL i sekret do podpisywania, wklejasz adres do serwisu, a wyzwalacz odpala się, gdy ten serwis wyśle POST. Do pracy, która należy do tego, co się właśnie stało: pull request, nieudany build, nowe zgłoszenie błędu.
Co wyzwalać
Prawdziwe zdarzenia i agent, którego chciałbyś mieć po drugiej stronie.
Przeglądaj każdy pull request, gdy tylko się otworzy
Skieruj webhook GitHuba lub GitLaba na wyzwalacz, ustaw filtr na otwarcie pull requesta, a agent recenzent rzuci się na diff w kilka sekund. Autor dostaje informację zwrotną, póki ma zmianę świeżo w głowie.
Automatycznie zbadaj czerwony build
Twoje CI może wysłać POST, gdy pipeline zawiedzie. Wyzwalacz uruchamia agenta z gałęzią i adresem URL uruchomienia w prompcie, więc czyta zadanie, które padło, i wraca z przyczyną zamiast z czerwoną plakietką.
Posegreguj crash w chwili zgłoszenia
Podepnij alert Sentry do wyzwalacza. Nowy wyjątek na produkcji uruchamia agenta backendowego z tytułem błędu i adresem URL zgłoszenia, więc pierwsze spojrzenie na stack trace następuje, zanim ktokolwiek otworzy dashboard.
Uruchom agenta ze Slacka
Slackowa slash command albo wychodzący webhook może trafić w adres URL wyzwalacza. Ktoś wpisuje prośbę na kanale, payload ląduje w prompcie, a agent podejmuje ją we właściwym projekcie.
Doprecyzuj nowe zgłoszenie, gdy tylko wpłynie
Zgłoszenie utworzone na GitHubie, GitLabie lub w Linear uruchamia agenta produktowego, który czyta opis, dopytuje o to, czego brakuje, i zamienia je w coś, co programista może wziąć na warsztat.
Wykonaj przebieg QA po każdym wdrożeniu
Twój pipeline wdrożeniowy wysyła POST, gdy wychodzi wydanie. Wyzwalacz uruchamia agenta QA, który testuje aplikację na wersji dopiero co wypuszczonej, zamiast działać według harmonogramu niemającego nic wspólnego z wydaniami.
Napisz notatki o wydaniu przy tagu
Wypchnięty tag, opublikowane wydanie i agent od dokumentacji zamienia commity w czytelne notatki. Zdarzenie niesie nazwę taga, więc agent wie dokładnie, jaki zakres podsumować.
Cokolwiek, co potrafi wysłać POST z JSON-em
Nie ma listy integracji, na którą trzeba czekać. Cron na serwerze, krok w Zapierze, narzędzie do monitoringu, Twój własny backend: jeśli coś potrafi wysłać podpisany POST na adres URL, potrafi uruchomić agenta w Twoim projekcie.
Jak działa wyzwalacz webhook, krok po kroku
Od pustego formularza do agenta, który reaguje na produkcję, w kilka minut.
Utwórz wyzwalacz
Otwórz panel Wyzwalacze w swoim projekcie i utwórz nowy. Ta sama lista, ten sam przełącznik włącz/wyłącz, ta sama historia co przy zaplanowanym zadaniu, bo to ten sam panel.
Przełącz go na Webhook
Wybierz tryb Webhook zamiast Zaplanowany. AgentsRoom generuje dla tego wyzwalacza publiczny adres URL, a obok niego sekret do podpisywania. Sekret możesz wygenerować od nowa, kiedy tylko chcesz odciąć tego, kto miał stary.
Wklej adres URL do serwisu
Wrzuć go do webhooka GitHuba lub GitLaba, aplikacji Slacka, integracji Linear lub Sentry albo do swojego CI. Podaj serwisowi także sekret do podpisywania, żeby wysyłane przez niego wywołania dało się zweryfikować.
Odfiltruj to, co naprawdę ma odpalać
Repozytorium wysyła mnóstwo zdarzeń. Dodaj opcjonalny warunek na payloadzie, na przykład action równe opened, a cała reszta zostanie zignorowana. Ustaw limit nawału, żeby hałaśliwy serwis nie uruchomił dwudziestu agentów w minutę.
Umieść zdarzenie w swoim prompcie
Napisz prompt ze zmiennymi zdarzenia: tytuł, autor, adres URL, numer, gałąź albo cały payload. Rozwijają się w chwili odpalenia wyzwalacza, dokładnie tak jak zmienne daty i godziny, które zaplanowane zadania już obsługują.
Odtwórz ostatnie wywołanie i ruszaj
Edytor pokazuje ostatnie wywołanie, które wyzwalacz odebrał, razem z surowym JSON-em, i odtwarza je jednym kliknięciem. Webhooka podpina się, patrząc na niego, a nie zgadując, a gdy już wszystko gra, włączasz wyzwalacz.
Rząd serwisów to zestaw skrótów, a nie lista dozwolonych. Edytor mówi to wprost pod wyborem źródła i właśnie dlatego pierwsza pozycja to Any service (JSON): działa wszystko, co potrafi wysłać POST z ciałem JSON. Wybranie GitHuba, GitLaba, Slacka, Lineara lub Sentry dodaje dokładnie dwie rzeczy: jego własny nagłówek z podpisem do zweryfikowania oraz jego pola payloadu już odwzorowane na zmienne zdarzenia. Nic nie zostaje odrzucone dlatego, że nie ma go na liście.
Kafelki zmiennych to nie dokumentacja, tylko przyciski: kliknij jeden, aby wstawić zmienną do promptu, a te, które ostatnie wywołanie faktycznie wypełniło, są podświetlone. Pod nimi znajduje się ostatnie wywołanie odebrane przez wyzwalacz, więc filtr i prompt piszesz na prawdziwym payloadzie, który widzisz, odtwarzasz je i włączasz wyzwalacz dopiero wtedy, gdy uruchomienie wychodzi jak trzeba.
- Zdarzenie trafia na adres URL wyzwalacza
Serwis wysyła swój JSON. AgentsRoom sprawdza podpis Twoim sekretem i odrzuca wszystko, co niepodpisane, a potem stosuje Twój filtr, jeśli go ustawiłeś.
- Czeka, jeśli nikogo nie ma
Twoja maszyna może być wyłączona. Zdarzenie jest przechowywane przez maksymalnie tydzień i odtwarzane przy następnym uruchomieniu aplikacji, zamiast przepaść: ten sam model nadrabiania, którego już używają zaplanowane zadania.
- Bierze je jedna maszyna i tylko jednaMac w biurzeMac w domuMaszyna do buildów
Jeśli kilka komputerów ma otwarty ten projekt, pierwszy, który sięgnie po zdarzenie, blokuje je dla siebie. Pozostałe widzą, że jest zajęte, i idą dalej, więc jedno zdarzenie nigdy nie tworzy dwóch agentów.
- Agent wykonuje się, raz
W projekcie otwiera się prawdziwy agent, z rolą, dostawcą i modelem, które wybrałeś, z własnym terminalem, widokiem rozmowy i archiwalnym zapisem, który możesz odczytać później.
Publiczny adres URL, który nie jest otwartymi drzwiami
Adres URL jest osiągalny z internetu, więc wyzwalacz decyduje, co przyjmuje, zanim cokolwiek wystartuje.
Każde wywołanie jest podpisane
AgentsRoom weryfikuje każde wywołanie Twoim sekretem, zanim cokolwiek wystartuje: X-Hub-Signature-256 dla GitHuba, X-Slack-Signature dla Slacka, współdzielony token X-Gitlab-Token dla GitLaba oraz zwykły HMAC z surowego ciała żądania dla Lineara, Sentry i źródeł ogólnych. Wywołanie bez podpisu jest odrzucane, więc znajomość adresu URL nie wystarczy, aby uruchomić agenta na Twojej maszynie.
Wymień sekret, kiedy chcesz
Sekret do podpisywania jest pokazany w edytorze i można go wygenerować od nowa na miejscu. Stare wywołania natychmiast przestają przechodzić weryfikację, a tego właśnie chcesz w dniu, w którym serwis zostaje odłączony albo sekret wycieka do loga.
Filtruj na payloadzie
Opcjonalny warunek decyduje, czy zdarzenie zasługuje na agenta. Odpalaj tylko wtedy, gdy action równa się opened, tylko na jednej gałęzi, tylko dla jednej etykiety. Wszystko, co nie pasuje, jest odrzucane bez uruchamiania czegokolwiek.
Ochrona przed nawałem zdarzeń
Co najwyżej jedno uruchomienie na okno czasowe. Serwis, który wysyła trzydzieści zdarzeń w dziesięć sekund, nie uruchamia trzydziestu agentów: wywołania z tego okna są grupowane i pokrywa je jedno uruchomienie.
Payload staje się Twoim promptem
JSON wysłany przez serwis jest rozkładany na zmienne, które wpisujesz prosto do promptu. Rozwijają się w chwili odpalenia, tak jak zmienne daty i godziny, których już używają zaplanowane zadania.
Piszesz prompt raz, a każde uruchomienie dostaje dane zdarzenia, które je wywołało.
{{event.title}}Tytuł zdarzenia: tytuł pull requesta, tytuł zgłoszenia, nazwa alertu.{{event.author}}Kto je spowodował: autor pull requesta, osoba, która otworzyła zgłoszenie.{{event.url}}Odnośnik z powrotem do zdarzenia, żeby agent mógł otworzyć pull requesta albo alert.{{event.number}}Numer pull requesta albo zgłoszenia, jeśli serwis go wysyła.{{event.branch}}Gałąź, której dotyczy zdarzenie, przy pushu, pull requeście albo nieudanym buildzie.{{payload}}Cały surowy JSON, na wszystko, czego nie pokrywają nazwane zmienne.
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.Nazwy zmiennych pisze się w podwójnych nawiasach klamrowych w polu promptu, dokładnie tak jak zmienne daty i godziny zaplanowanego zadania.
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.idCo naprawdę się wykonuje i gdzie
Ten sam uczciwy model wykonania co przy zaplanowanych zadaniach, rozszerzony na zdarzenia.
Skąd biorą się zdarzenia
Cokolwiek potrafi wysłać podpisany POST z ciałem JSON, może uruchomić agenta. Oto te, które ludzie podpinają najpierw.
Twoje CI, Twój backend, cokolwiek
Krok pipeline'u, narzędzie do monitoringu, usługa wewnętrzna, skrypt powłoki z curl. Nie ma integracji, o którą trzeba prosić: POST z ciałem JSON i podpisem, to cały kontrakt.
GitHub i GitLab
Pull requesty i merge requesty otwarte, zrecenzowane lub scalone, utworzone zgłoszenia, pushe, wydania, nieudane workflow. Klasyczne źródło i to z najbardziej użytecznym payloadem.
Slack
Slash command albo wychodzący webhook zamienia wiadomość na kanale w uruchomienie agenta we właściwym projekcie. Podpisy Slacka są weryfikowane przez X-Slack-Signature.
Linear i Sentry
Zgłoszenie przeniesione do innej kolumny, nowy wyjątek na produkcji, alert o regresji. Narzędzie do śledzenia odpala, a agent startuje ze zgłoszeniem albo błędem w prompcie.
Druga połowa tego samego panelu
Wyzwalacze i zaplanowane zadania to jedna funkcja z dwiema odpowiedziami na to samo pytanie. Zaplanowane zadanie to wyzwalacz, którego zdarzeniem jest zegar. Wyzwalacz webhook to zaplanowane zadanie, którego harmonogramem jest świat zewnętrzny. Żyją na tej samej liście i dzielą tę samą konfigurację agenta, ten sam przełącznik włączania, tę samą historię uruchomień i ten sam zakres per maszyna.
Wybierasz więc według zadania, a nie według narzędzia. Audyt zależności zostaje w poniedziałek rano, bo nic z zewnątrz nie ogłasza, że pakiet się zestarzał. Przegląd pull requestów przenosi się na webhook, bo GitHub zna już dokładną sekundę, w której powinien nastąpić. Zajrzyj na stronę zaplanowanych zadań po zegarową stronę tej rodziny.
Zobacz zaplanowane zadania, zegarową stronę tego samego paneluFAQ
Czym jest wyzwalacz webhook w AgentsRoom?
To wyzwalacz, który uruchamia agenta AI, gdy zewnętrzny serwis wyśle mu zdarzenie, zamiast startować o ustalonej godzinie. AgentsRoom nadaje wyzwalaczowi publiczny adres URL i sekret do podpisywania; wklejasz ten adres do GitHuba, GitLaba, Slacka, Lineara, Sentry albo dowolnego narzędzia, które potrafi wysłać POST z JSON-em. Gdy ten serwis wywoła adres, podpis zostaje zweryfikowany, zastosowany zostaje Twój opcjonalny filtr, a w Twoim projekcie startuje agent z payloadem już dostępnym jako zmienne promptu.
Czym to się różni od zaplanowanego zadania?
Zmienia się tylko odpowiedź na pytanie, kiedy to ma odpalić. Zaplanowane zadanie odpala według zegara: co N minut, co godzinę, codziennie, co tydzień lub co miesiąc. Wyzwalacz webhook odpala na zdarzenie z zewnątrz. Cała reszta jest wspólna: ta sama lista, ten sam przełącznik włącz/wyłącz, ta sama konfiguracja agenta, ta sama historia per uruchomienie, ten sam zakres per maszyna.
Dlaczego po prostu nie kazać agentowi odpytywać API?
Bo odpytywanie w pętli kosztuje tokeny przy każdym obiegu, a prawie każdy obieg niczego nie znajduje. Agent sprawdzający repozytorium co pięć minut wykonuje pełny obieg co pięć minut, żeby odpowiedzieć „nie”. Wyzwalacz webhook nie zużywa nic, dopóki nic się nie dzieje, i reaguje w kilka sekund, gdy coś się wydarzy. To cały argument ekonomiczny za tą funkcją.
Czy wystawienie adresu URL wyzwalacza jest bezpieczne?
Sam adres URL nie wystarczy, żeby cokolwiek uruchomić. Każde wywołanie musi udowodnić, że pochodzi z serwisu, który ma Twój sekret: X-Hub-Signature-256 dla GitHuba, X-Slack-Signature dla Slacka, współdzielony token X-Gitlab-Token dla GitLaba, zwykły HMAC z surowego ciała żądania dla Lineara, Sentry i źródeł ogólnych. Wywołanie bez nagłówka z podpisem jest odrzucane, nigdy nie zostaje przepuszczone. Sekret jest pokazany w edytorze i można go w każdej chwili wygenerować od nowa, co natychmiast unieważnia wszystko, co używało starego.
Czy mogę odpalać tylko na niektórych zdarzeniach?
Tak. Repozytorium wysyła znacznie więcej zdarzeń, niż chcesz mieć agentów, więc wyzwalacz przyjmuje opcjonalny warunek na payloadzie, na przykład action równe opened. Zdarzenia, które nie pasują, są ignorowane i nic się nie uruchamia. Jest też limit nawału: co najwyżej jedno uruchomienie na okno czasowe, a wywołania, które przyjdą w tym oknie, są grupowane.
Co się dzieje, jeśli AgentsRoom jest zamknięty, gdy przychodzi zdarzenie?
Zdarzenie trafia do kolejki na serwerze i zostaje odtworzone przy następnym uruchomieniu aplikacji, więc wykonuje się z opóźnieniem, a nie nigdy. Zdarzenia w kolejce są przechowywane przez tydzień, co pokrywa laptopa zamkniętego na długi weekend i jednocześnie nie odtwarza miesiąca nieaktualnej pracy, gdy wrócisz. To ten sam model „w aplikacji plus nadrabianie”, z którego korzystają zaplanowane zadania. Wyzwalacze webhook nie uruchamiają Twojego agenta w chmurze: agent zawsze działa na Twojej maszynie, w Twoim projekcie.
Mam projekt otwarty na dwóch komputerach. Czy agent uruchomi się dwa razy?
Nie. Zdarzenie jest konsumowane raz. Pierwsza maszyna, która je podejmie, blokuje je dla siebie, a pozostałe widzą, że jest zajęte, i je pomijają. Możesz też przypiąć wyzwalacz do wybranych maszyn, dokładnie tak jak zaplanowane zadanie, jeśli chcesz, żeby odpowiadał za niego konkretny komputer.
Co mogę wstawić do promptu ze zdarzenia?
Payload jest rozkładany na zmienne, które wpisujesz wprost w pole promptu, w podwójnych nawiasach klamrowych: event.title, event.author, event.url, event.number, event.branch oraz payload dla całego surowego JSON-a. Rozwijają się w chwili odpalenia wyzwalacza, tak samo jak zmienne daty i godziny zaplanowanego zadania.
Skąd mam wiedzieć, że mój webhook jest dobrze podpięty?
Edytor pokazuje ostatnie wywołanie, które wyzwalacz odebrał, razem z surowym ciałem JSON, i pozwala odtworzyć je jednym kliknięciem. Filtr i prompt ustawiasz więc na prawdziwym payloadzie, który widzisz, a potem odtwarzasz go, aż uruchomienie będzie dobre, zamiast wypychać testowe commity, żeby się przekonać.
Które serwisy są obsługiwane?
Każdy, który potrafi wysłać podpisany POST z ciałem JSON. GitHub, GitLab, Slack, Linear i Sentry to te, które ludzie podpinają najpierw, bo ich payloady są bogate, ale nie ma zamkniętej listy: zadanie CI, narzędzie do monitoringu, Twój własny backend albo curl w skrypcie powłoki działają dokładnie tak samo.
Czy to wizualny kreator automatyzacji ze scenariuszami wielokrokowymi?
Nie i nie taki jest zamysł. Wyzwalacz ma jedno zadanie: zdecydować, kiedy agent startuje, i podać mu zdarzenie. Częścią wielokrokową jest sam agent, który czyta kod, uruchamia narzędzia i wykonuje pracę. Jeśli chcesz, żeby kilku agentów przekazywało sobie pracę, od tego są Zespoły agentów, a nie płótno ze scenariuszami.
Czy AgentsRoom może wysyłać webhooki do innych serwisów?
Wyzwalacze są tylko przychodzące: AgentsRoom odbiera zdarzenia, nie wysyła ich. Jeśli chcesz, żeby agent na koniec uruchomienia wywołał zewnętrzny serwis, to jego własna robota, przy użyciu narzędzi i serwerów MCP, które mu dałeś.
Dobrze współgra z
Zaplanowane zadania
Zegarowa strona tego samego panelu. Co N minut, co godzinę, codziennie, co tydzień lub co miesiąc, bez wyrażenia cron do napisania.
Tablica zadań Backlog
Przeciągasz zgłoszenie do kolumny, a agent je podejmuje. Wyzwalacz robi to samo, tyle że przeciąga je zdarzenie z zewnątrz.
Zespoły agentów
Agenci Dev, QA i PM, którzy przekazują sobie pracę. Skieruj wyzwalacz na zespół, a zdarzenie uruchomi całą rutynę.
AgentsRoom MCP
Narzędzia, którymi agent czyta backlog, pamięć i bibliotekę promptów. Wyzwolony agent dostaje je jak każdy inny.
Powiadomienia agentów
Dowiedz się w chwili, gdy wyzwalacz odpala, na pulpicie i na telefonie, z jednym dotknięciem otwierającym agenta, którego uruchomił.
Zdalna Flota
Kilka maszyn na jednym koncie. Przypnij wyzwalacz do tej, która ma na niego odpowiadać, a tylko ona uruchomi agenta.
Przestań odpytywać. Zacznij reagować.
Pobierz AgentsRoom, wklej jeden adres URL do GitHuba, GitLaba, Slacka, Lineara lub Sentry i pozwól, żeby zdarzenie uruchomiło agenta. Nic nie działa, dopóki nic się nie dzieje.
Aplikacja towarzysząca: monitoruj agentów w podróży
Użyj Claude, Codex, Antigravity CLI lub innego dostawcy AI.
Wysyłaj bugi i prośby bezpośrednio do swojego publicznego backlogu.
Spojrzenie na AgentsRoom w akcji.