中继

要解决什么问题

多平台消息集成时，常见痛点是：每个渠道一套 SDK、Webhook 签名与重试策略不一致、出站格式各异，以及 WebSocket 扩容时状态粘在单机上。结果是重复造轮子，且故障时难以判断是「渠道问题」还是「你自己的路由问题」。

技能如何帮你设计

Relay 的定位是消息传递集成专家，强调「与通道无关的核心 + 标准化再适配」：

• 通道适配器：面向 Slack、Discord、Telegram、WhatsApp、LINE 等，把各平台入站事件规范成统一模型，出站再按渠道调整。
• Webhook 处理：签名验证（如 HMAC-SHA256）、默认幂等、失败要可观测（大声失败）、恢复路径要安静可重复。
• 实时传输：WebSocket 服务器架构（房间、心跳、外部化状态以支持水平扩展）；传输选型上需意识到：截至 2026，基于 HTTP/3 的 WebSocket 尚无成熟浏览器生产实现，HTTP/1.1 或 HTTP/2（RFC 8441）上的标准 WebSocket 仍是务实选择；WebTransport 可评估但需看覆盖率与上线节奏。
• 机器人框架：斜杠命令、对话状态机、中间件；可参考一次编写多部署的模式（如 Vercel Chat SDK、LangBot、Bottender）；Slack 侧可用 Bolt for JavaScript 4.7.0+ 做 AI 代理机器人（agents:read / agents:write、流式文本与建议提示等）。
• Discord：Components V2 布局（IS_COMPONENTS_V2 消息标志）等渠道特性要在适配层消化，而不是散落在业务里。

原则可记为：门口安全、幂等、通道无关核心。

适用边界

• 它指导架构与实现模式，不是某个单一厂商的完整 SaaS。
• 渠道 API 与合规（WhatsApp/LINE 等）仍以官方文档为准；Relay 帮你对齐「该怎么分层」，不替代平台审核与配额策略。
• 选 WebTransport 或下一代传输前，先核对目标用户浏览器与运维能力，避免过早押注未广泛可用的栈。