通知系统

功能概述

通知系统用于把平台中的关键变化主动推送给用户、团队或管理员。
它解决的不是“页面上有没有消息”，而是“重要事件能不能及时被看到并被处理”。

适用场景

通知系统常用于：

• 工作流或任务执行完成后提醒结果
• 账号、安全或审批事件通知相关人员
• 团队、知识库、Agent 或 API Key 变更的同步提醒

前置条件

开始前建议先明确：

• 哪些事件属于必须通知的事件
• 应该通知给谁
• 平台已经接好了哪些通知渠道

操作步骤

第 1 步：先定义什么事件值得通知

不要一开始就把所有事件都打开。
建议优先筛选真正高价值的事件，例如：

• 执行失败
• 审批待处理
• 安全异常
• 关键资源变更

如果通知范围定义得太宽，后面用户很快就会忽略这些提醒。

第 2 步：再区分通知范围和接收对象

平台里通常至少要区分 3 类通知：

• 全局通知
• 团队通知
• 用户通知

完成这一步后，你应该能明确每类事件到底应该给管理员、团队负责人还是具体用户。

第 3 步：在后台确认通知字段和创建入口

如果你需要主动创建一条通知，或者验证平台通知的字段结构，建议先进入后台通知管理页确认以下信息都可以配置：

• 范围
• 类型
• 优先级
• 标题和内容
• 过期时间
• 外部通知渠道

第 4 步：确认渠道已就绪，再开始触发真实通知

通知系统不能脱离通知渠道独立工作。
在真正启用前，建议先确认：

• 邮件、Webhook 或 IM 渠道已经测试成功
• 对应事件确实会走正确渠道
• 失败时有明确反馈

第 5 步：进入通知中心，查看真实通知结果

当事件被触发后，进入通知中心查看通知是否真正到达。
重点看：

• 是否出现新通知
• 通知内容是否可读
• 已读和未读状态是否能正常变化

如果这一步能看到完整通知链路，说明平台内的消息展示已经跑通。

如果通知数量开始变多，建议优先使用筛选器快速定位高优先级事件，再去看具体处理动作。

如果你需要先看某一类对象的通知，例如只看团队级变更，也可以先按范围做筛选。

第 6 步：建立“事件到处理”的闭环

通知真正有价值，不是因为“发出去了”，而是因为接收人看完能做事。
因此上线前还应再确认：

• 关键告警有没有明确责任人
• 是否存在通知太多、难以识别优先级的问题
• 失败通知能不能引导用户回到正确页面处理

结果验证

一个可投入使用的通知系统，至少应满足：

• 关键事件会触发通知
• 目标对象能在通知中心或外部渠道收到提醒
• 已读、未读和失败状态都可追踪
• 接收人能根据通知快速定位问题或继续处理

常见问题

为什么系统里明明有通知功能，但用户还是不知道出了什么事

通常是因为：

• 通知事件定义过宽或过乱
• 通知优先级不清晰
• 接收人没有被正确配置

为什么通知发送成功了，但平台里感觉“没有闭环”

因为通知的目标不是展示，而是推动处理。
如果接收人收到后不知道该去哪看、该做什么，通知价值就会大打折扣。

为什么生产环境启用前一定要先做测试发送

通知跨越平台内外多条链路。
不做测试发送，你很难确认到底是平台事件、渠道配置还是接收端规则出了问题。

注意事项

• 先做高价值事件，不要一开始通知泛滥
• 通知系统要和通知渠道一起验证，不能只看站内展示
• 关键告警必须能追踪到人，不能只有系统里一条消息