SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场relay

relay

智能体与模型

查看项目

更新于 10-16 02:05

技能介绍

用途

Relay 是一个消息集成专家技能，专注于设计消息平台与机器人相关的集成方案。它面向需要接入 Slack、Discord、Telegram、WhatsApp、LINE 等消息平台，或需要构建 Webhook 处理器、WebSocket 服务器、机器人命令框架、事件路由系统的场景。其定位是交付消息集成设计（适配器接口、Webhook 处理器、事件模式、机器人框架），而不是业务逻辑实现。

主要能力

  • 渠道适配器设计：为 Slack、Discord、Telegram、WhatsApp、LINE 等平台设计适配器接口，实现入站归一化、出站按平台适配（write-once, render-per-platform 模式）。
  • Webhook 处理器设计：包含 HMAC-SHA256 签名验证（基于原始请求字节）、幂等性、时间戳校验窗口（≤5 分钟）、载荷大小限制（≤100 KB）、3 秒内返回 2xx 并异步处理。
  • WebSocket 服务器架构：房间、心跳、连接生命周期管理，以及借助外部化状态（如 Redis）的水平扩展。
  • 传输方式选择：在 WebSocket / SSE / WebTransport / 长轮询之间进行选择，并给出相应约束（如不建议在 HTTP/3 上使用 WebSocket）。
  • 机器人命令框架：斜杠命令、会话状态机、中间件链（auth → validate → rate-limit → route → handle）。
  • 事件路由：使用可辨识联合（discriminated union）模式与路由矩阵，推荐 CloudEvents 信封格式，并可用 AsyncAPI 记录契约。
  • 统一消息格式设计：平台无关的归一化格式。
  • 消息队列集成：Redis Pub/Sub、BullMQ、RabbitMQ、Kafka 等，用于可靠投递。
  • 可靠性策略：熔断器、死信队列（DLQ）、带抖动的指数退避重试。
  • LLM 原生机器人集成：与 Dify、n8n、Langflow、Coze 等 AI runner 集成。
  • 跨平台机器人 SDK：如 Vercel Chat SDK（Slack/Teams/Discord/Telegram/Google Chat）。

使用方式

Relay 采用 LISTEN → ROUTE → ADAPT → WIRE → GUARD 的工作流：

  1. LISTEN（需求发现）：确定平台优先级、消息类型清单、方向（入/出/双向）、延迟预算、量级估算。
  2. ROUTE（消息架构）：定义统一模式（可辨识联合）、路由矩阵、命令解析规范、会话状态机、DLQ 策略。
  3. ADAPT（渠道适配器设计）：适配器接口（send/receive/normalize/adapt）、SDK 选择、归一化与适配规则、功能映射（线程/表情/嵌入）。
  4. WIRE（传输实现）：服务器架构、中间件链、连接生命周期、退避重试、队列集成。
  5. GUARD（安全与可靠性）：HMAC-SHA256 验证、令牌轮换、限流、幂等键、健康检查、告警阈值。

它提供多个 Recipe 子命令，通过解析用户输入的首个 token 来激活：

  • webhook（默认）：Webhook 接收处理器设计（HMAC 验证、幂等性）。
  • bot：机器人命令框架与会话状态机设计。
  • websocket：WebSocket 服务器与实时通信设计。
  • adapter：渠道适配器（Slack/Discord/LINE 归一化）。
  • sse：Server-Sent Events 设计，含 Last-Event-ID 恢复、心跳、代理安全头。
  • queue：消息队列生产者/消费者接线（SQS/SNS/RabbitMQ/Kafka/NATS），含 DLQ 与幂等消费者。
  • rate：消息场景的限流与背压（令牌/漏桶、429/Retry-After、按租户配额）。

若首个 token 不匹配任何子命令，则使用默认 Recipe（webhook）。

适用场景

  • 需要为某个消息平台设计渠道适配器。
  • 需要设计带签名验证与幂等性的 Webhook 处理器。
  • 需要设计 WebSocket 服务器或选择实时传输方式。
  • 需要构建机器人命令框架与会话状态机。
  • 需要设计事件路由、统一消息格式或跨系统事件互操作。
  • 需要为消息处理引入队列、熔断、DLQ 等可靠性机制。
  • 需要集成 LLM 原生机器人或跨平台机器人 SDK。

限制与边界

  • 不实现处理器背后的业务逻辑（应交给 Builder）。
  • 不设计无消息上下文的 REST/GraphQL API 规范（应交给 Gateway）。
  • 不编写 ETL/数据管道（应交给 Stream）。
  • 不进行无消息上下文的安全审计（应交给 Sentinel）。
  • 不设计聊天界面的 UI/UX（应交给 Vision 或 Forge）。
  • 消息指标的观测/告警设计交给 Beacon（Relay 提供指标规范）。
  • 强制要求：Webhook 必须基于原始字节做 HMAC-SHA256 验证并使用时间安全比较；生产环境必须 TLS；必须设置时间戳校验窗口与载荷大小限制；必须使用幂等键；必须为每个消息处理器提供熔断器与 DLQ；不得重试不可重试错误（4xx 除 429 外）；不得在代码中存储凭据；不得在无外部化会话状态的情况下对 WebSocket 做轮询负载均衡；不得在临时计算（Lambda、Cloud Functions）上部署 Discord 机器人；新应用不得使用 Slack RTM API；不得使用 Discord v10 之前的 API 版本。

平台约束（资料中提及）

  • Slack 经典应用将于 2026-11-16 停止运行，需迁移到细粒度 bot token；RTM API 为遗留，新应用须使用 Events API 或 Socket Mode；商业分发的非 Marketplace 应用在 conversations.history/.replies 上被限制为 1 req/min / 15 objects（自定义/内部应用不受影响）。
  • Discord 全局 50 req/s，按路由有 X-RateLimit-Bucket；API v10 为当前版本；Components V2 是新应用推荐路径；2026-02-23 起的权限拆分要求 PIN_MESSAGES 与 CREATE_EVENTS 分开。

以上平台约束与截止日期均来自资料原文，具体实施前建议核对官方最新文档。