AI Agent后端任务调度开发工具可观测性AI 应用【免费下载链接】trigger.devTrigger.dev – build and deploy durable AI agents and workflows项目地址https://gitcode.com/gh_mirrors/tr/trigger.dev点击查看免费下载本篇技术指南以 Trigger.dev 仓库中托管 WebhooksHosted Webhooks功能的控制台前端UX/前端开发为线索完整梳理从零搭建本地开发环境、理解 Deliveries 数据流水线Postgres ClickHouse 复制、通过种子脚本/内置 Composer/真实 Provider 三条路径造出真实可截图数据以及前端代码地图、设计语言与提交规范的完整链路。读完本文你可以独立把一个干净的机器跑起带真实 Webhook 数据的 dashboard并知道每个界面背后由哪些源码支撑。托管 Webhooks 让 Trigger.dev 用户无需自建 Ingress 与验签代码就能把 Stripe、GitHub 等 Provider 的 Webhook 作为 Task 接收、校验并路由到自己的onEvent处理器。本文所依据的核心文档为仓库根目录下的 ONBOARDING.md对应 PR #4344 hosted webhooks, agent channels, and human-in-the-loop 的交接说明并辅以仓库源码作为实现佐证。功能背景托管 Webhooks 与四块待设计的界面用户在自己项目里写一个webhook()处理器即可获得一个托管 URLProvider 向该 URL 投递的请求会被验证、记录并路由到用户的onEvent处理器。Dashboard 在左侧导航 Webhooks 分区青色图标下共有四个界面归属前端设计全部位于/orgs/:org/projects/:project/env/:env之下界面路由展示内容Deliveries 列表/webhooks环境中所有端点的全部投递记录。复用 Runs 风格的筛选栏Status、Webhook、Created以及 More-filters 菜单里的 Delivery ID / Run ID、已应用筛选的 pills、链接到 handler 的 Webhook 列。主屏。Delivery 详情/webhooks/deliveries/:deliveryParam单条投递。主面板是选项卡视图Event payload / Request headers以 JSON 渲染侧栏属性表状态徽章、webhook 与 run 链接、external delivery id、幂等键、时间戳、计算出的耗时、错误信息并提供针对过期/失效链接的友好空状态not available / retained for N days。Handler 详情 Console/webhooks/:webhookParam用户代码中的webhook()处理器。选项卡Deliveries、Runs、Endpoints。此页还承载Webhook Console / Composer见下文造数据章节。Endpoint 详情/webhooks/endpoints/:endpointParam单个端点。左侧按端点过滤的投递右侧Connect卡片webhook URL、签名密钥的 set/rotate/generate、由 verifier 配置渲染出的 Provider 设置指引、Routing、Scope、Metadata。状态词汇、徽章与颜色分别集中在 DeliveryStatus.tsx 与 EndpointStatus.tsx 中。从源码可见投递状态复用 Runs 页的十六进制色板不新造颜色SUCCEEDED#28BF5C、FAILED#E11D48、PROCESSING#3B82F6、PENDING#878C99、FILTERED#64748B已接收并验证、有意不路由属中性色而非失败端点状态为 ACTIVE#28BF5C、INACTIVE#878C99、DELETING#F59E0B。导航强调色是 Tailwind token--color-webhooksteal定义于 tailwind.css--color-webhooks: var(--color-teal-500)通过text-webhooks使用侧边栏的注入点见 SideMenu.tsx。环境准备分支、工具链与依赖安装该功能的后端已全部就绪前端设计工作基于特性分支feat/hosted-webhook-ingressgit clone https://gitcode.com/gh_mirrors/tr/trigger.dev cd trigger.dev # 使用 gh 检出对应 PR 分支会落到 feat/hosted-webhook-ingress gh pr checkout 4344若计划把设计改动推回该分支需先与维护者协调该分支会被周期性 rebase 与 force-push应约定推送时机或改在子分支上开发并另开跟进 PR。工具链要求 pnpm 10.33.2经 corepack与 Node 22且必须用corepack pnpm裸的全局pnpm可能是旧版本会清掉node_modulescorepack enable corepack pnpm install启动本地栈四个基础服务与 webapp从仓库根目录依次执行。第一步拉起核心开发服务Postgres、Redis、Electric、MinIO、ClickHouse、s2-lite。# 1. 核心开发服务 corepack pnpm run docker # 2. 配置 cp .env.example .env关键一步编辑.env并追加两行 Webhook 投递复制replication配置。这两行不在.env.example中缺失会导致即使发送了 WebhookDeliveries 列表依然为空原因见下一节# webhook deliveries replicationDeliveries 列表/详情填充所必需 WEBHOOK_DELIVERIES_REPLICATION_CLICKHOUSE_URLhttp://default:passwordlocalhost:8123 WEBHOOK_DELIVERIES_REPLICATION_ENABLED1随后迁移、种子、构建并运行corepack pnpm run db:migrate corepack pnpm run db:seed # 创建 References 组织 hello-world 项目 # 顺序构建将要运行的组件勿与 db:seed 同时进行 corepack pnpm run build --filter webapp --filter trigger.dev --filter trigger.dev/sdk # 运行 webapphttp://localhost:3030 corepack pnpm run dev --filter webapp curl -s http://localhost:3030/healthcheck # 验证开发环境登录打开 http://localhost:3030提交邮箱localtrigger.dev。开发模式下会自动验证 magic link注意观察 webapp 日志中的/magic?token。该种子用户是组织管理员这对下一步的特性开关很关键。webapp 端口来自REMIX_APP_PORT回退到PORT/3030。开启特性hasWebhooksAccess 标志Dashboard 由特性标志hasWebhooksAccess默认关闭控制种子开发用户localtrigger.dev是管理员管理员绕过该标志因此在全新 seed 后 Webhooks 导航分区对你已经可见无需额外操作如果使用非管理员用户需要在Organization行上设置featureFlags.hasWebhooksAccess true才能显示导航分区。注意全局FeatureFlag行key 为hasWebhooksAccess只能让页面按 URL 直达左侧导航只读组织级标志所以非管理员的分区依然隐藏。如果左侧导航缺少 Webhooks 分区原因就是该标志。数据流水线为什么列表可能为空理解数据流向是排查列表为空的关键ingest - engineverify、filter、route- Postgres WebhookDelivery 行 - replication - ClickHouse从 WebhookDeliveriesListPresenter.server.ts 的实现可见Deliveries列表的排序与分页来自 ClickHouse随后每个可见字段再从 Postgres 水合hydrate——包括解析 run 的 friendlyId、会话归属以及为 Webhook 列解析每个投递所属的 handlerhandlerWebhookId与source。因此若复制关闭第三节你能创建投递却看到空列表。启用两个复制环境变量并重启 webapp 即可。一个内置于设计的注意事项复制从开启那一刻才开始流式传输所以开启之前写入的投递不会出现。务必先开复制再造数据。此外列表页支持跨端点全量查询页大小固定为 60DELIVERIES_PAGE_SIZE 60筛选器中的 webhookhandler slug会被解析为端点 ID 集合、runId 会被解析为内部 ID且当筛选命中为空时会解析为哨兵值__none__保证筛选后无结果而非筛选被静默丢弃countNewDeliveries用与列表一致的筛选逻辑统计N 条新投递徽章。投递详情页则直接读 Postgres——它是事件 payload 与请求头唯一的持久副本。造数据三路径投递行正是这些界面好看的关键丰富的 Provider、状态、payload、时间戳。下面按文档给出的三条路径逐一展开并给出源码佐证。路径一一键种子脚本推荐仓库提供一个种子脚本直接把完整、稳定的数据集写入两个存储Postgres 与 ClickHouse无需任何 worker、trigger dev或签名密钥配置即可在全新 DB 上得到真实的界面数据corepack pnpm --filter webapp run db:seed:webhooks # 可选每个端点的投递数默认 45 corepack pnpm --filter webapp run db:seed:webhooks -- 60脚本入口为 seed-webhook-deliveries.tsnpm 脚本db:seed:webhooks在 apps/webapp/package.json 中定义为varlock run --inject vars -- tsx seed-webhook-deliveries.ts。从源码可以确认其行为细节六个端点覆盖不同 Provider 与验签方案Stripe、GitHub、Slack、Svix、Discord非对称 ed25519以及一个自定义共享密钥端点且混合了 active/inactive 与 secret-set/not-set见ENDPOINTS数组seed-webhook-deliveries.ts每种投递状态全覆盖STATUS_WEIGHTS按权重生成 SUCCEEDED(68)、FAILED(12)、FILTERED(11)、PROCESSING(4)、PENDING(5)seed-webhook-deliveries.tsFAILED 带真实失败原因签名验证失败、未设置签名密钥、时间戳超出容差窗口FILTERED 带event.type不匹配的 filter reason最近两周的时间分布且偏向近期biasedCreatedAt使用Math.random() ** 1.7加权并混有 test/live约 15% 为测试投递每个 Provider 的真实感 payload 与签名头如 Stripe 的Stripe-Signature、GitHub 的X-Hub-Signature-256、Slack 的X-Slack-Signature、Svix 的webhook-signature、Discord 的X-Signature-Ed25519等脚本附着到本地用户可见的第一个 DEVELOPMENT 环境可用WEBHOOK_SEED_PROJECTproject name指定项目完成后会打印精确的 Deliveries URL可重跑每次运行先清空该环境的投递再重新种子保证始终得到同一份干净数据残留的 ClickHouse 行会因列表丢弃Postgres 行已不存在的有序 ID 而自动隐藏因为直接写 ClickHouse种子数据无需第三节的复制配置即可显示复制环境变量只在实时与 Composer 路径下需要。种子优先使用WEBHOOK_DELIVERIES_REPLICATION_CLICKHOUSE_URL未设置时回退到CLICKHOUSE_URL后者已在.env.example中细节陷阱在源码注释中有明确提醒投递的friendlyId必须是whd_前缀加 id详情页按whd_剥前缀后用id查 Postgres两者若独立铸造会导致每个种子投递的详情页 404脚本还会按需创建按天的 ClickHouse 分区表WebhookDelivery_YYYY_MM_DD并向trigger_dev.webhook_deliveries_v1以 JSONEachRow 批量写入。这是推荐的数据获取方式。下面的交互路径用于演练实时流水线真实验签、真实路由 run或应用内测试控制台。路径二交互式——创建端点 Webhook ConsoleComposer 把投递发给端点而端点只有在声明了webhook()的 Trigger 项目被 dev-run 或部署后才会存在。最快的方式是建一个微型 demo 项目// demo/src/trigger/demo-webhook.ts import { webhook, webhooks } from trigger.dev/sdk; export const demoWebhook webhook({ id: demo-webhook, source: webhooks.custom{ message: string }({ /* generic HMAC */ }), onEvent: async ({ event, headers, ctx }) { // event 是解析后的 bodyheaders 是 Web Headers 对象 }, }); // 真实 Provider用于真实感 payload export const stripeWebhook webhook({ id: stripe-webhook, source: webhooks.stripe(), onEvent: async ({ event }) {}, });将该 demo 项目链接到本地构建并运行trigger dev参见仓库 AGENTS.md 中 Testing with the hello-world Reference Project 的链接说明triggerdotdev/references仓库提供现成项目。trigger dev会注册webhook()处理器从而创建对应端点。随后在 endpoint 详情页的 Connect 卡片中为每个端点设置签名密钥Generate 或粘贴。打开 handler 详情页/webhooks/:webhookParam即进入内置的Composer组件 WebhookComposer.tsx 的源码位于 apps/webapp/app/components/webhookConsole/WebhookComposer.tsx。它直接把投递在进程内注入引擎速度快且不消耗真实速率额度。四个来源选项卡与四种签名模式源码中SourceTab与SignatureMode类型定义见 WebhookComposer.tsx来源选项卡说明Body手写任意 JSON内置 JSON 编辑器默认 body 为{message: hello from the webhook console}LibrarySample从内置事件目录internal/webhook-sources六个一级 Provider 外加大型 sample manifest目录见 internal-packages/webhook-sources挑选真实 Provider 事件是获取正确外观 Stripe / GitHub / Svix / Square / Discord payload 与头的最快方式Replay重发一条既有投递AI用提示词生成 payload签名模式行为signed用端点存储的密钥服务端签名验证通过并路由到 SUCCEEDED 投递端点未设密钥或为 asymmetric 方案时该选项禁用并给出原因提示simulate跳过验签注入但 filter、startOn、路由与 run 依然执行unsigned预期返回 400产生失败/拒绝投递tampered预期返回 400产生失败/拒绝投递fail-closed不写投递行这正是制造状态分布的手法signed配合已设密钥产出 SUCCEEDEDunsigned与tampered产出失败/拒绝。此外还有几个值得留意的 Composer 细节可选 Headers 编辑器签名头自动附加可加x-github-event等路由头Webhook URL 的剪贴板展示标注 POST为 Provider 投递的公网地址测试发送在进程内跑同一流水线handshake 发送按钮依据 verifier 配置构造 challenge body 并期望端点回显握手内联应答、不记录投递相同 payload 会被去重到原投递结果条显示 Deduplicated 徽章非开发环境发送前弹确认对话框并给出警告 Callout。结果条会显示 HTTP 状态 / Handshake / Deduplicated 徽章、投递 ID 与 View delivery 跳转链接。要想得到 SUCCEEDED 且其 run 也完成的最完整端到端数据请保持 demo 项目的trigger dev运行让被路由的 task 真正执行。路径三真实 Provider最真实想要真正的 payload 与请求头可把 Stripe CLI 指向端点stripe listen --forward-to http://localhost:3030/webhooks/v1/ingest/opaqueId先在 Connect 卡片里为该端点设置whsec然后stripe trigger payment_intent.succeeded。各 Provider 的验签配置签名头、时间戳容差、签名串模板、幂等字段在 packages/core/src/v3/webhooks/index.ts 中有纯数据形式的单一定义如stripeVerifierConfig、githubVerifierConfig、svixVerifierConfig、standardWebhooksVerifierConfigSDK 的webhooks.stripe()等生产者与样本目录共用这份来源。前端代码地图以下是前端各区域的代码位置速查表区域路径路由页面apps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.webhooks/ 及webhooks._index、webhooks.$webhookParam、webhooks.deliveries.$deliveryParam、webhooks.endpoints.$endpointParam等文件Deliveries 列表/详情组件apps/webapp/app/components/webhookDeliveries/v1/DeliveriesTable、DeliveryStatus、WebhookDeliveryFilters、DeliveryTimeline、useDeliveriesLiveReloadEndpoint 组件apps/webapp/app/components/webhookEndpoints/v1/EndpointsTable、EndpointStatusConsole / Composerapps/webapp/app/components/webhookConsole/WebhookComposer、SampleSourcePicker、ReplaySourcePicker数据presenter只读侧apps/webapp/app/presenters/v3/WebhookDeliveriesListPresenter.server.ts、WebhookDeliveryDetailPresenter.server.ts、WebhookDetailPresenter.server.ts、webhookComposerEndpoints.server.ts导航入口apps/webapp/app/components/navigation/SideMenu.tsxstaticSections中的 webhooks push配合text-webhooks路径构建器apps/webapp/app/utils/pathBuilder.tsv3WebhooksPath、v3WebhookTaskPath、v3WebhookDeliveryPath、v3WebhookEndpointPath强调色 tokenapps/webapp/app/tailwind.css--color-webhooks用法text-webhooks数据种子脚本apps/webapp/seed-webhook-deliveries.ts经db:seed:webhooks运行Composer 背后的资源路由发送、样本、重放来源、实时投递位于apps/webapp/app/routes/resources.orgs.$organizationSlug.projects.$projectParam.env.$envParam.webhooks.*例如webhooks.endpoints.$endpointParam.send.ts、webhooks.samples.ts、webhooks.endpoints.$endpointParam.replay-source.ts、webhooks.deliveries.live.ts投递重放 API 见apps/webapp/app/routes/api.v1.webhooks.deliveries.$deliveryId.replay.ts端点密钥轮换/启停见api.v1.webhooks.endpoints.$endpointId.{rotate-secret,enable,disable}.ts。样式体系webapp 使用 Tailwind v4CSS-first 的theme位于 apps/webapp/app/tailwind.css不存在tailwind.config.js。新增或修改设计 token 都在该文件进行。需要匹配的设计语言这些界面刻意复用 Runs 页原语——筛选栏由RunFilters/SharedFilters构建表格沿用 Runs 表格单元格。请对齐 Runs 与 Sessions 页面而不是另立一套视觉体系。迭代工作流HMR vs 重启编辑组件.tsx热更新编辑.server.ts文件会让 Remix dev server 重启应用短暂 connection refused 后恢复编辑 Tailwind token 热更新。截图从运行中的 dashboardhttp://localhost:3030截图保存到仓库外或 scratch 目录避免误提交。非平凡改动后跑类型检查corepack pnpm run typecheck --filter webapp约 1~2 分钟。小型样式调整可信任 CI 兜底。一个 dev server 不会捕获的边界陷阱路由文件绝不能把 server-only import 泄漏进客户端 bundle——dev server 能容忍但生产构建会失败。若你动了路由文件并引入任何 server-only 导入推送前务必执行corepack pnpm --filter webapp run build:remix。纯组件与样式改动不受影响。提交与 CI提交前先格式化与 lintcorepack pnpm run formatoxfmt与corepack pnpm run lint:fixoxlintCI 两者都强制。提交风格为 Conventional Commits例如feat(webapp): redesign webhook deliveries table不加 emoji不加署名 footer。PR 保持draft状态等待 AI review pass 再转人工 review之后才置为 ready不要自行翻转推送提交后由维护者协调 review 与 rebase 到main。需要关注的 CIcode-qualityoxfmt oxlint、typecheck、webapp 单元分片以及 Playwrighte2e-webapp任务。纯样式改动通常只影响code-quality。快速参考速查表Webapphttp://localhost:3030端口来自REMIX_APP_PORT回退PORT/3030默认 docker 服务Postgres 5432、Redis 6379、ClickHouse HTTP 8123default:password、MinIO、Electric、s2-lite特性标志hasWebhooksAccess管理员绕过种子数据corepack pnpm --filter webapp run db:seed:webhooks追加-- n控制每端点投递数必设环境变量数据要显示WEBHOOK_DELIVERIES_REPLICATION_ENABLED1与WEBHOOK_DELIVERIES_REPLICATION_CLICKHOUSE_URLhttp://default:passwordlocalhost:8123登录localtrigger.dev开发环境自动验证 magic link心智模型一段话总结用户在自己的项目中写一个webhook()。在部署或trigger dev时该 handler 会获得一个或多个托管端点每个端点带签名密钥。Provider 向端点的 URL 发 POST引擎验签、可选过滤、记录一条WebhookDelivery并触发被路由的 task run。Dashboard 读取这些投递列表从 ClickHouse 排序取数并从 Postgres 水合其余字段详情页直接读 Postgres那里保存着事件 payload 与请求头的唯一副本。你要设计的一切都落在那条投递记录与产生它的那个端点之上。赞分享AI Agent后端任务调度开发工具可观测性AI 应用【免费下载链接】trigger.devTrigger.dev – build and deploy durable AI agents and workflows项目地址https://gitcode.com/gh_mirrors/tr/trigger.dev点击查看免费下载相关推荐如何快速搭建Trigger.dev本地开发环境Docker Compose完整指南如何快速搭建Trigger.dev本地开发环境Docker Compose完整指南 Trigger.dev是一个强大的开源工具可帮助开发者构建和部署全托管的AI Agent后端任务调度开发工具可观测性AI 应用Cookiecutter Django 本地开发环境搭建完全指南从裸机同步开发到异步任务与前端流水线Cookiecutter Django 本地开发环境搭建完全指南从裸机同步开发到异步任务与前端流水线 本篇指南以 Cookiecutter Django 项目后端代码生成开发工具Kafka-UI React 前端从零搭建 Apache Kafka 管理界面的开发环境实战指南Kafka UI React 前端从零搭建 Apache Kafka 管理界面的开发环境实战指南 UI for Apache Kafka即 kafka ui后端前端可观测性消息队列上一篇终极指南如何在5分钟内快速搭建你的第一个Notion集成应用 下一篇终极Switch固件更新神器AIO-Switch-Updater 一键搞定CFW、作弊码与固件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考