當真的有事情發生時
你的代理已經在跑了
觸發器只回答一個問題：這個代理什麼時候啟動？定時任務用一個時刻來回答。webhook 觸發器用一個來自外部世界的事件來回答。一個 pull request 被開啟，一次建置掛掉，一條告警響起，而代理已經在跑了。
AgentsRoom 為每個觸發器提供一個公開 URL 和一個簽名金鑰。把這個 URL 貼上進 GitHub、GitLab、Slack、Linear、Sentry，或任何會發 POST JSON 的東西。呼叫到達，簽名被校驗，payload 變成你提示詞裡的變數，一個真實的代理就在你的專案中啟動，帶著它的終端和它的會話記錄。
一個觸發器，一個公開 URL。事件到達，簽名被校驗，payload 變成提示詞變數，一個代理在你的專案中啟動。
定時任務解決了一半問題。你已經可以讓一個代理每天早上 8 點評審 pull request。但你想交給代理的大部分活兒並不發生在 8 點：它發生在有人開啟 pull request 的時候，發生在建置變紅的時候，發生在客戶下午兩點提了一個 bug 的時候。
在此之前，唯一能抓住這些時刻的辦法就是讓代理去盯：用很短的間隔執行它，讓它去輪詢 API，問一句「有新東西嗎？」，然後為「沒有」這個答案，一天付上幾百次 token。這很貴，反應很慢，而且一旦你想同時盯三個儲存庫，就完全撐不住了。
webhook 觸發器把方向反了過來。是服務來告訴你。AgentsRoom 給你一個 URL，你把它貼上進 GitHub、GitLab、Slack、Linear、Sentry 或你的 CI，在那個服務發起呼叫之前什麼都不會跑。它一呼叫，代理就帶著已經在提示詞裡的事件啟動。安靜的日子裡零 token，不安靜的時候幾秒之內就有一個代理上手。
為什麼事件勝過輪詢迴圈
你不再為沉默付錢。每五分鐘檢查一次儲存庫的代理，每五分鐘就燒掉完整的一輪上下文，而其中幾乎每一輪都什麼也沒找到。觸發器在事件到達之前不消耗任何東西。
反應是即時的。沒有間隔要調，也不會出現一個 pull request 因為輪詢剛剛跑過而乾等十一分鐘的視窗。代理在呼叫到達時就啟動，所以作者重新整理頁面時，評審已經等在那裡了。
事件自帶資料。payload 會被解析成變數，你直接把它們放進提示詞：標題、作者、URL、編號、分支，或者整份原始 JSON。代理不必再自己去查是什麼把它叫起來的。
還是你已經熟悉的那個面板。觸發器保留了定時任務的列表、開關、按執行的歷史、代理選擇器和按機器的作用範圍。webhook 只是對「這個什麼時候觸發」的另一種回答。
一個觸發器，兩種觸發方式
面板同時容納這兩種。挑跟你正在等的東西相匹配的那一種。
定時
最初的模式，原封不動。每 N 分鐘、每小時、每天、每週或每月，不用寫任何 cron 表示式。適合歸屬於時鐘的工作：早晨的評審、週一的依賴檢查、週五的 changelog。
Webhook
代理等的是一個事件，而不是一個時刻。AgentsRoom 給你一個公開 URL 和一個簽名金鑰，你把 URL 貼上進那個服務，它一發 POST，觸發器就觸發。適合歸屬於某件事發生的工作：一個 pull request、一次失敗的建置、一份新的 bug 報告。
可以觸發什麼
真實的事件，以及你會希望在另一端接手的那個代理。
每個 pull request 一開啟就評審
把 GitHub 或 GitLab 的 webhook 指向這個觸發器，過濾出 pull request 被開啟的情況，幾秒之內就有一個評審員代理開始看 diff。作者還沒把這次改動從腦子裡放下，就已經拿到了反饋。
自動排查一次變紅的建置
你的 CI 可以在流水線失敗時發一個 POST。觸發器啟動一個代理，把分支和這次執行的 URL 放進它的提示詞，於是它去讀失敗的那個 job，帶回來的是原因，而不是一枚紅色徽章。
崩潰一被報上來就分流
把一條 Sentry 告警接到觸發器上。正式環境裡的一個新異常會啟動一個後端代理，帶著錯誤標題和工單 URL，於是在任何人開啟 dashboard 之前，堆疊的第一眼就已經看過了。
從 Slack 啟動一個代理
Slack 的 slash command 或出站 webhook 都可以打到觸發器 URL。有人在頻道里敲下需求，payload 落進提示詞，代理就在正確的專案裡接手。
工單一建立就把範圍理清
在 GitHub、GitLab 或 Linear 上建立的一個工單，會啟動一個產品代理：它讀完這份反饋，把缺掉的問題問清楚，再把它變成開發者可以直接接手的東西。
每次部署之後跑一輪 QA
你的部署流水線會在一個版本發布時發 POST。觸發器啟動一個 QA 代理，針對剛剛上線的那個版本去跑應用，而不是按一個跟發布毫無關係的時刻表來跑。
打 tag 時寫好發布說明
推一個 tag，發布一個 release，一個文件代理就把這些提交變成讀得懂的說明。事件帶著 tag 名，所以代理清楚知道該總結哪一段範圍。
任何能發 JSON 的東西
沒有什麼整合清單需要等。伺服器上的一個 cron、一個 Zapier 步驟、一個監控工具、你自己的後端：只要它能往一個 URL 發出帶簽名的 POST，它就能在你的專案裡啟動一個代理。
webhook 觸發器如何運作，分步講解
從一張空表單，到一個會對正式環境作出反應的代理，只要兩分鐘。
建立一個觸發器
在你的專案上開啟觸發器面板，新建一個。和定時任務同一份列表、同一個開關、同一份歷史，因為它就是同一個面板。
把它切換到 Webhook
選擇 Webhook 而不是定時。AgentsRoom 會為這個觸發器生成一個公開 URL，旁邊還有一個簽名金鑰。金鑰隨時可以重新生成，用來切斷還握著舊金鑰的那一方。
把 URL 貼上進服務裡
把它放進 GitHub 或 GitLab 的 webhook、一個 Slack 應用、一個 Linear 或 Sentry 整合，或者你的 CI。簽名金鑰也一併給那個服務，這樣它發來的呼叫才能被校驗。
過濾掉不該觸發的東西
一個儲存庫會發很多事件。加一個可選的 payload 條件，比如 action 等於 opened，其餘的一律忽略。再設一個突發上限，讓一個話多的服務沒法在一分鐘裡啟動二十個代理。
把事件放進你的提示詞
用事件變數來寫提示詞：標題、作者、URL、編號、分支，或者整個 payload。它們會在觸發器觸發時被解析，就跟定時任務已經支援的日期和時間變數一樣。
重放最近一次呼叫，然後上線
編輯器裡顯示觸發器收到的最近一次呼叫，原始 JSON 也在，一鍵就能重放。你是看著實際的呼叫來接線的，不是靠猜；接對了，就把觸發器開啟。
那一排服務是一組快捷方式，不是白名單。編輯器就在選擇器下面這麼寫著，第一項之所以是 Any service (JSON)，正是這個原因：任何能 POST 一份 JSON 正文的東西都行得通。選了 GitHub、GitLab、Slack、Linear 或 Sentry，只多出兩樣東西：它自己那個要校驗的簽名頭，以及已經對映到事件變數的 payload 欄位。沒有任何東西會因為不在這份列表裡而被拒絕。
那些變數小標籤不是文件，它們是按鈕：點一下就把變數插進提示詞，而最近一次呼叫真正填上了值的那些會被高亮。它們下面就是觸發器收到的最近一次呼叫，所以你是對著一份看得見的真實 payload 去寫過濾條件和提示詞，重放它，等這次執行跑對了，再把觸發器開啟。
- 事件到達你的觸發器 URL
服務發來它的 JSON。AgentsRoom 用你的金鑰校驗簽名，拒絕一切沒有簽名的呼叫，然後應用你設過的過濾條件（如果你設過的話）。
- 沒人在的時候，它會等
你的機器可以是關著的。事件會被留住最長一週，在下次啟動時重放，而不是被丟掉，和定時任務已經在用的補跑模型完全一樣。
- 只有一台機器取走它，而且只有一台辦公室 Mac家裡的 Mac建置機
如果好幾台電腦都開啟了這個專案，第一台取到事件的機器會把它鎖定。其他機器看到它已被取走，就跳過去做別的，所以一個事件永遠不會產生兩個代理。
- 代理執行，只執行一次
一個真實的代理在專案中開啟，帶著你選的角色、provider 和模型，擁有自己的終端、自己的對話檢視，以及一份歸檔的會話記錄，你之後隨時可以回看。
一個公開的 URL，但不是一扇敞開的門
這個 URL 從網際網路上就能訪問，所以在任何東西啟動之前，觸發器先決定它接受什麼。
每一次呼叫都帶簽名
在任何東西啟動之前，AgentsRoom 都會用你的金鑰校驗每一次呼叫：GitHub 用 X-Hub-Signature-256，Slack 用 X-Slack-Signature，GitLab 用 X-Gitlab-Token 共享令牌，Linear、Sentry 和通用來源則用對原始正文計算的普通 HMAC。沒有簽名的呼叫會被拒絕，所以光知道 URL 並不足以在你的機器上啟動一個代理。
想換金鑰就換
簽名金鑰顯示在編輯器裡，當場就能重新生成。舊的呼叫會立刻校驗不透過，而這正是某個服務被下線、或某個金鑰洩進日誌的那天你想要的效果。
在 payload 上做過濾
一個可選條件決定這個事件值不值得一個代理。只在 action 等於 opened 時觸發，只在某一個分支上觸發，只對某一個標籤觸發。不匹配的一律丟棄，不啟動任何東西。
突發防護
每個時間視窗最多一次執行。一個在十秒裡發出三十個事件的服務不會啟動三十個代理：視窗內的這些呼叫會被歸併，用一次執行覆蓋它們。
payload 變成你的提示詞
服務發來的 JSON 會被解析成變數，你直接寫進提示詞。它們在觸發的那一刻被解析，就像定時任務已經在用的日期和時間變數一樣。
提示詞只寫一次，而每次執行都會拿到觸發它的那個事件的資料。
{{event.title}}事件的標題：pull request 的標題、工單的標題、告警的名稱。{{event.author}}是誰引起的：pull request 的作者、開出這個工單的人。{{event.url}}回到事件的連結，好讓代理能開啟這個 pull request 或這條告警。{{event.number}}pull request 或工單的編號，前提是那個服務發了這個欄位。{{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到底跑的是什麼，跑在哪裡
和定時任務一樣坦誠的執行模型，只是擴展到了事件。
事件從哪裡來
任何能發出帶簽名、帶 JSON 正文的 POST 的東西，都能啟動一個代理。下面這些是大家最先接上的。
你的 CI、你的後端，任何東西
一個流水線步驟、一個監控工具、一個內部服務、一段用 curl 的 shell 腳本。沒有什麼整合需要申請：一個帶 JSON 正文和簽名的 POST，就是全部的約定。
GitHub 和 GitLab
pull request 和 merge request 被開啟、被評審或被合併，工單被建立，push，release，失敗的 workflow。最經典的來源，payload 也最有用。
Slack
一個 slash command 或一個出站 webhook，就把頻道里的一條訊息變成正確專案中的一次代理執行。Slack 的簽名用 X-Slack-Signature 校驗。
Linear 和 Sentry
一個工單被挪進某一列，正式環境裡的一個新異常，一條迴歸告警。跟蹤工具一觸發，代理就帶著這個工單或這個錯誤在提示詞裡啟動。
同一個面板的另一半
觸發器和定時任務是同一個功能對同一個問題給出的兩種回答。定時任務是一個以時鐘為事件的觸發器。webhook 觸發器是一個以外部世界為時刻表的定時任務。它們住在同一份列表裡，共用同一份代理配置、同一個啟用開關、同一份執行歷史和同一套按機器的作用範圍。
所以你是按活兒來選，而不是按工具來選。依賴審計仍舊留在週一早晨，因為外面沒有任何東西會宣布某個包過時了。pull request 評審改成 webhook，因為 GitHub 早就知道它該在哪一秒發生。想看這一家的時鐘那一側，去讀定時任務那一頁。
看看定時任務，同一個面板的時鐘一側FAQ
AgentsRoom 裡的 webhook 觸發器是什麼？
它是一個觸發器：當外部服務給它發來一個事件時啟動一個 AI 代理，而不是在某個設定的時刻啟動。AgentsRoom 給這個觸發器一個公開 URL 和一個簽名金鑰；你把 URL 貼上進 GitHub、GitLab、Slack、Linear、Sentry 或任何能發 POST JSON 的工具。那個服務一呼叫，簽名就被校驗，你設的可選過濾條件被應用，一個代理在你的專案裡啟動，payload 已經作為提示詞變數準備好了。
它和定時任務有什麼不同？
變的只有「這個什麼時候觸發」這個問題。定時任務按時鐘觸發：每 N 分鐘、每小時、每天、每週或每月。webhook 觸發器按外部事件觸發。其餘全部共用：同一份列表、同一個開關、同一份代理配置、同一份按執行的歷史、同一套按機器的作用範圍。
為什麼不乾脆讓一個代理去輪詢 API？
因為輪詢每一輪都要花 token，而幾乎每一輪都什麼也沒找到。每五分鐘檢查一次儲存庫的代理，每五分鐘就跑完整的一輪，只為了回答「沒有」。webhook 觸發器在什麼都沒發生時不消耗任何東西，而一旦有事，幾秒之內就作出反應。這就是這個功能全部的經濟學理由。
把觸發器 URL 暴露出去安全嗎？
光有 URL 什麼也啟動不了。每一次呼叫都必須證明它來自握著你金鑰的那個服務：GitHub 用 X-Hub-Signature-256，Slack 用 X-Slack-Signature，GitLab 用 X-Gitlab-Token 共享令牌，Linear、Sentry 和通用來源用對原始正文計算的普通 HMAC。不帶簽名頭的呼叫會被拒絕，絕不會被放行。金鑰顯示在編輯器裡，隨時可以重新生成，用舊金鑰的那一方會立刻失效。
我可以只在某些事件上觸發嗎？
可以。一個儲存庫發來的事件，遠多於你想為之啟動代理的那些，所以觸發器接受一個可選的 payload 條件，比如 action 等於 opened。不匹配的事件被忽略，什麼也不會生成。另外還有一個突發上限：每個時間視窗最多一次執行，落在這個視窗裡的呼叫會被歸併到一起。
事件到達時 AgentsRoom 是關著的，會怎樣？
事件會在服務端排隊，並在你下次啟動應用時重放，所以它是遲到，而不是永遠不到。排隊的事件會保留一週：這足以覆蓋一台筆記本合上過一個長週末，又不至於讓你回來時重放一個月的陳舊工作。這和定時任務用的「應用內加補跑」模型是同一個。webhook 觸發器不會在雲端跑你的代理：代理永遠跑在你的機器上，在你的專案裡。
我在兩台電腦上都開啟了這個專案。代理會跑兩次嗎？
不會。一個事件只被消費一次。第一台取到它的機器會把它鎖定，其他機器看到它已被取走就跳過。你也可以像定時任務那樣，把一個觸發器固定到指定的機器上，如果你想讓某一台電腦來負責它的話。
我能從事件裡往提示詞放些什麼？
payload 會被解析成變數，你直接寫進提示詞欄位的雙大括號之間：event.title、event.author、event.url、event.number、event.branch，以及代表整份原始 JSON 的 payload。它們在觸發器觸發時被解析，和一個定時任務的日期、時間變數是同一套做法。
我怎麼知道自己的 webhook 接對了？
編輯器會顯示觸發器收到的最近一次呼叫，包括原始 JSON 正文，並讓你一鍵重放它。所以你是對著一份看得見的真實 payload 去調過濾條件和提示詞，然後一遍遍重放，直到這次執行跑對為止，而不是靠推測試提交去碰運氣。
支援哪些服務？
任何能發出帶簽名、帶 JSON 正文的 POST 的服務。GitHub、GitLab、Slack、Linear 和 Sentry 是大家最先接上的，因為它們的 payload 內容最豐富，但這裡沒有白名單：一個 CI job、一個監控工具、你自己的後端，或者 shell 腳本里的一句 curl，用起來完全一樣。
這是一個多步驟場景的視覺化自動化編排器嗎？
不是，它也不打算做成那樣。觸發器只有一個職責：決定一個代理什麼時候啟動，並把事件交給它。多步驟的那部分是代理自己，它讀程式碼、跑工具、把活兒幹完。如果你想讓好幾個代理互相交接工作，那是代理團隊的事，不是一塊場景畫布。
AgentsRoom 能向其他服務發出 webhook 嗎？
觸發器只管入站：AgentsRoom 接收事件，不發出事件。如果你想讓代理在一次執行結束時去呼叫某個外部服務，那是代理自己的活兒，用你給它的工具和 MCP 伺服器來做。
搭配使用更佳
別再輪詢了，開始響應吧。
下載 AgentsRoom，把一個 URL 貼上進 GitHub、GitLab、Slack、Linear 或 Sentry，讓事件來啟動代理。什麼都沒發生時，什麼都不跑。
配套應用：隨時隨地監控你的 Agent
使用 Claude、Codex、Antigravity CLI 或其他 AI 提供商。
把 Bug 和需求直接傳送到您的公開待辦清單。
AgentsRoom 實際執行一瞥。