INTERNAL · 产品手记
2026.07
发信只能各写一套 SDK？
消息一次入队 · 处处送达
多渠道 · Agent 派发 · 按用户投递 · 自托管推送中台
八爪鱼 · Octopus
自托管
推送中台
EDITOR'S NOTE
一句话定位
把多通道通知收拢成一条投递总线：业务只负责入队，Agent 负责送达，全程可追踪。
业务系统里到处散落着SMTP、企微机器人、钉钉 Webhook，改一处要动三处，失败了还不知道卡在哪。团队越大，发信代码越像债务。
这篇手记把八爪鱼讲清楚：定位、架构、渠道与接入路径。读完你可以判断：要不要用它做自建通知中台。
01
PART
它是谁：自托管的统一消息推送平台
POSITIONING · 产品定位
对外品牌叫八爪鱼，部署产物名octopus。纪律很明确：业务只负责入队，Agent 负责送达。
中小团队自建通知中台
多业务系统要统一发告警、运营消息、用户触达，又不想把发信逻辑散落在各项目里。
按外部用户 × 多渠道投递
每个终端用户可独立绑定邮箱、钉钉、企微等，一次入队，按配置分别送达。
管理员 + 对接开发者双角色
管理员管站点、用户、Agent 与运维；普通用户在推送中心创建应用、配渠道、查记录。
各处直连发信 统一入队派发 不是客服 / 即时聊天
02
PART
怎么跑：入队、Agent、留痕
ARCHITECTURE · 核心架构
八爪鱼强制一条纪律：一切对外发信都先入队。Webhook、OpenAPI、渠道测试都先写消息与任务，再由 Agent 拉取执行——业务代码里不直连 SMTP 或第三方 API。
PIPELINE
业务入队
Agent 领取
渠道送达
状态回写
本机 Worker
开箱即可发信
vs
远程 Agent
WebSocket 横向扩展
渠道「测试」成功 = 已入队 不等于接口里同步发完。真正送达看消息记录与 Agent 监控。
03
PART
发到哪：多渠道能力盘点
CHANNELS · 通道清单
渠道配置由服务端元数据驱动，管理端表单按类型下发。当前覆盖办公群、个人推送与自定义出口，支持文本与 Markdown。
类型
通道
要点
邮箱
SMTP
账号池轮发
办公群
企微 / 钉钉 / 飞书
群机器人加签
个人推送
WxPusher / ClawBot
极简 / 扫码绑定
终端触达
华为负一屏等
负一屏生态
自定义
HTTP Webhook
对接自有系统
差异化不在渠道多 而在「按外部用户 × 多渠道」：不是简单群发，而是每个用户各自的通知偏好。
04
PART
怎么接：三步上手
GET STARTED · 接入路径
Step 01
创建应用并配置渠道
在推送中心新建应用，按需打开邮箱、钉钉、企微等渠道。应用凭证与对接密钥在个人中心管理，密钥不要进前端。
Step 02
同步用户并完成绑定
把业务侧的外部用户 ID 同步进来，让终端用户在绑定页完成各自渠道配置。没有绑定，入队后也无处可投。
Step 03
业务侧带用户 ID 入队
调用 Webhook 或 OpenAPI，带上 external_user_id 与正文，在推送记录里查看任务成败。
CONSOLE MAP
管理后台能力地图
推送中心
应用 / 渠道 / 记录
推送运维
Agent 监控与部署
系统底座
用户 / 站点 / 鉴权
此外还有数据看板、可选充值与套餐、运维中心。部署侧常见组合是MySQL + Redis + octopus，本机跑通后再按需挂远程 Agent。
///
END
写在最后
SUMMARY · 选型一句话
如果你只是偶尔往一个钉钉群丢告警，直连机器人就够了。但如果你要多系统统一发信、按用户多渠道、可观测可扩展，八爪鱼这类自托管推送中台会省下大量后期维护。
业务零发信代码，Agent 统一送达——这就是八爪鱼想守住的边界。
消息一次入队，处处准时送达