Herald

HTTP First

curl 友好，无业务 SDK 依赖，天然支持多语言和自动化

Runtime First

承认 Provider 的本质差异来自运行环境，支持 Builtin 和 Worker 两种 Runtime

Event First

处理事件而非简单发送消息，支持路由、重试、去重、限流

Rule Engine

表达式规则决定放行/抑制/改道：优先级、默认策略、shadow 观察、for/group_by/inhibit/silence/escalation

Notification Groups

命名受众，任何渠道位可写 group:<id>，投递时展开成员，API 热更新花名册

Worker Model

独立 Runtime 节点，支持浏览器自动化等复杂场景

Herald 是什么

Herald 是一个轻量、Provider 无关的统一订阅与投递中枢：业务方只描述「发生了什么、通知什么、通知谁」，把通知作为一条 HTTP 请求交给它，由 Herald 负责受众解析、模板渲染、渠道路由与可靠送达；谁在什么渠道、以什么频率收到什么品类，由受众自己的订阅关系决定。内置 Provider 覆盖即时通讯（飞书、企业微信、钉钉、Slack、Discord、Telegram、微信）、短信（阿里云、腾讯云、网易）、邮件、Webhook、日志调试与 App 推送（FCM、APNs、极光 JPush、个推 Getui）；受众 - 渠道 - Provider 的解耦模型见受众领域模型总纲。

去重、重试、限流、模板多渠道复用、规则引擎放行/抑制/改道，这些通知系统的公共部分在平台侧统一处理，业务方只关心「发什么、发给谁」。

使用场景

系统告警推送：监控、巡检产生的事件经规则引擎分级路由，IM 群即时弹窗、短信兜底，超时未确认按升级策略自动加码。

运营消息触达：模板一次定义、多渠道复用；命名受众（Notification Groups）维护花名册，运营公告一发即达飞书/企微/邮件。

验证码与事务短信：对接阿里云/腾讯云/网易短信通道，内置限流防刷与失败重试，验证码这类高时效消息不丢单。

多通道兜底重试：同一事件可路由到多个渠道，主通道故障自动重试、换道送达，指数退避直到成功或达到重试上限。

CI/CD 与自动化接入：curl 一行接入，无 SDK 依赖；构建、部署、备份任务的结束状态直接进群，或经 Webhook 联动自建系统。

界面速览

管理台（Dashboard）的界面速览，自动轮播，也可用两侧箭头、下方圆点或键盘 ←/→ 翻看，点击任意一屏可看大图：