当真的有事情发生时
你的智能体已经在跑了
触发器只回答一个问题：这个智能体什么时候启动？定时任务用一个时刻来回答。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 服务器来做。
搭配使用更佳
定时任务
同一个面板的时钟一侧。每 N 分钟、每小时、每天、每周或每月，不用写任何 cron 表达式。
待办任务看板
把一个工单拖进某一列，智能体就接手。触发器做的是同一件事，只是由外部事件来完成这次拖拽。
智能体团队
彼此交接工作的 Dev、QA 和 PM 智能体。把一个触发器指向一个团队，一个事件就能带起整套例程。
AgentsRoom MCP
智能体用来读取待办、记忆和提示词库的那套工具。被触发起来的智能体和其他智能体一样拿得到。
智能体通知
触发器一触发你就知道，桌面和手机上都有，轻点一下就打开它启动的那个智能体。
远程机群
一个账户上的多台机器。把一个触发器固定到该由它应答的那一台，就只有那台机器会运行智能体。
别再轮询了，开始响应吧。
下载 AgentsRoom，把一个 URL 粘贴进 GitHub、GitLab、Slack、Linear 或 Sentry，让事件来启动智能体。什么都没发生时，什么都不跑。
配套应用：随时随地监控你的 Agent
使用 Claude、Codex、Antigravity CLI 或其他 AI 提供商。
把 Bug 和需求直接发送到您的公开待办清单。
AgentsRoom 实际运行一瞥。