Webhook 与触发器

触发器是 Letaido 实时注意到另一个应用中发生了某件事的方式，而无需持续检查。

当新联系人进入 HubSpot、有人在 Slack 上 @提及你，或交易推进到新阶段时，Letaido 会立即发现并采取行动。

你可以用它做什么

团队在这里设置的内容类似于：

当新的 HubSpot 联系人是 MQL 时，根据我们的 ICP 为其评分，并将结果发布到 #mql-review。
当有人在 #pmm-questions 中 @mentions Slack 机器人时，用我们的品牌语调回答。
当 Linear issue 被标记为 customer-facing 时，起草一段面向公众的摘要，并通过 DM 发送给 PMM 负责人。
当 GitHub release 发布时，自动起草一封发布邮件，并发送到 Notion 供审核。
当 Fathom meeting 结束时，提取行动项并添加到 Linear。
当 Apify scraper 完成时，启动 pipeline 的下一阶段。

你用简单英语描述触发条件和操作。智能体会设置连接，请求一次批准，然后自行运行。

幕后工作原理

有两种版本：

连接器触发器（首选）。 对第三方服务的类型化订阅。设置只需一次调用。平台会处理订阅、签名密钥、重试逻辑和事件队列。事件会以已知 Schema 到达（Slack、GitHub、Linear、HubSpot、Fathom、Apify 等）。
临时 webhook。 对于尚未内置连接器触发器的服务，智能体会生成一个通用 webhook URL，配置第三方向其 POST，并将事件拉入同一个队列。代价是需要多做一些解析工作，因为 Schema 取决于第三方发送的内容。

无论哪种方式，智能体都会为你选择合适的那个。你不用选择。

事件如何流转

第三方服务向平台拥有的公共 URL 发起 POST 请求。
平台验证签名，解析载荷，丰富其内容（例如，将 Slack 的频道 ID 解析为名称），并将其推送到内部队列。
消费者（应用、作业或聊天智能体）使用命名游标轮询队列并处理事件。
每个事件在处理后都会被确认；如果消费者崩溃，未确认的事件会被重新投递。

游标按消费者分别维护，因此 Console 应用和作业都可以监听相同事件，而不会互相影响。

可靠 vs 自动确认

自动确认（默认）。 读取事件；它们会立即从队列中消失。简单。适合“跟踪 feed，并记录到表中。”
手动确认。 读取事件、处理它们，然后显式确认。如果处理过程崩溃，该事件会被重新投递。当副作用（电子邮件、数据库写入、下游 API 调用）不能丢失时使用此方式。

如果你向智能体请求“一个可靠的工作流”，它会默认选择手动 ack。

常见的提问形式

“当新的 HubSpot 联系人创建且生命周期阶段 = marketingqualifiedlead 时，根据我们的 ICP 为该公司打分，并将结果发布到 #mql-review。”

该智能体： 1. 订阅 HubSpot 联系人创建触发器。 2. 编写一个小型消费者（控制台应用或作业），用于拉取事件、调用 ICP 评分器，并通过 Slack 连接器发布到 Slack。 3. 如果是首次使用这些界面，则同时显示 HubSpot 订阅审批和 Slack 审批。

"当 GitHub issue 被标记为 pmm-review 时，起草一段面向客户的摘要，并通过私信发给我。"

“当有人在 #pmm-questions 中 @提及 Slack 机器人时，使用品牌语气技能回答。”

你在工作区中看到的内容

对于每个有效订阅： - 连接器和事件类型。 - 签名密钥状态。 - 公共 URL（用于 ad-hoc）或第三方应用配置（用于连接器触发器）。 - 读取队列的消费者。

你可以在工作区 UI 中暂停或撤销订阅。撤销后，任何后续入站 POST 都会返回 410。

限制和边缘情况

任何事件都不会“从聊天中扇出”。 触发器由服务器驱动。如果聊天会话已关闭，事件仍会到达并堆积在队列中，直到消费者读取它们。
队列有保留窗口。 超过几天未读的事件会被丢弃。如果你怀疑某个消费者曾离线，请先检查，再判断事件是否被错过。
公开站点消费者受到额外限制。 站点表面触发器需要按调用逐次明确审核（不做一揽子批准），因为由访客控制的流程存在扇出成本风险。
签名密钥会被存储，但永不显示。 agent 可以使用它们，但无法回读它们。

底层机制。 入站事件进入 nginx → api-proxy → connectors service。该服务会根据已存储的签名密钥验证签名，运行连接器的 enrich hook（例如 Slack 的用户 ID 到用户名解析器），然后向 webhook_events 写入一行。消费者通过 GET /webhooks/events?cursor=<name> 拉取，并可选择使用 provider 和 ack 参数。手动确认的消费者会使用 through_id POST 回 /webhooks/ack。