想象一座叫“回声社区”的数字小区,它就安放在 Discord 服务器里。这里有电竞大厅、画师工坊、新手广场等各种“频道房间”,住着成千上万来自天南海北的居民。人越多,麻烦越多:新住户进门无人迎接、广告刷屏没人拦、同一个问题被问一百遍。终于有一天,物业团队请来了一位 AI 管家“小e”——一个住在小区里、7×24 小时不掉线的智能助手。 小e一人分饰三角:在前台当客服(AI 对话)、在楼道当保安(内容审核)、在办公室当文员(管理自动化)。而支撑它跑动自如的,是一整套“上岗装备”:工作证(Bot 账号)、对讲机(API 集成)和工具箱(斜杠命令与消息组件)。这篇文章就带你围观小e的入职全过程,把每个装备和技能拆开揉碎讲给你听。

岗位关联

掌握 Discord AI 集成,等于掌握了一套完整的社区 Agent 落地方法论:事件驱动、意图分类、内容风控、API 治理。这套能力不止适用于 Discord,可以平移到任意 IM 平台的 AI 助手开发中,是 AI 应用开发者从“会调模型”走向“能交付产品”的关键一跳。

目录
  1. 可视化演示
  2. Bot 基础入门:管家上岗记
  3. AI 对话机器人:管家的待客之道
  4. 内容审核机制:管家的火眼金睛
  5. API 集成开发:管家的通信走廊
  6. 社区管理自动化:管家的例行公事
  7. 交互体验增强:管家的百宝工具箱
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示Discord AI Bot的三种核心模式:内容审核自动检测违规消息、AI对话机器人响应交互、FAQ知识库自动应答,交互切换模式理解社区智能管理流程。

本节配有交互动效(进入视口后自动加载,约 3KB)。

内容审核:AI自动检测违规消息 红色为违规消息(垃圾/仇恨/NSFW) 绿色为正常消息(通过审核) 青色为Bot审核节点 Auto-rate = AI_processed / Total_violations, Target > 90% Bot通过Moderation API自动检测垃圾广告、仇恨言论和不当内容,自动化率目标>90%

Bot 基础入门:管家上岗记

小e要上岗,第一件事是“办编制”。在 Discord 里,这个编制叫 Bot 账号——它是专门给程序使用的身份,不占普通业主名额,头像下永远挂着一个“机器人”标签。物业为小e签发了一张专属工作证:Bot Token。这张证是它进出所有频道的唯一凭证,就像小区门禁卡,一旦弄丢或外借,任何人都能冒充管家进出小区。

从技术上说,Bot 的“神经系统”是一套事件驱动模型。Discord 服务器每时每刻都在产生事件:有人发消息、有人进频道、有人点击按钮。Discord 不会等 Bot 来“查岗”,而是通过 Gateway 通道把事件实时“推”到 Bot 门口。Bot 的编程范式因此变成:监听事件、解析事件、执行响应、返回结果。谁触发了事件、有没有权限处理,都由事件里的角色信息决定。

权限设计是这节的重点:Bot 权限应遵循“最小够用”原则,就像管家只配自己负责房间的钥匙,不必握有整个小区的备用钥匙串。开发时,需要在 Discord Developer Portal 精确勾选 Bot 所需权限(如“发送消息”“读取消息历史”),多一个权限就多一分风险。

小e上岗第一课,就是先搞懂“门铃响了该开哪扇门”。事件是它的神经系统,权限是它的行为准则,而 Response 就是它每一次恰当得体的举手投足。神经系统没接好,后面学再多技巧都是空中楼阁。

Response=Handler(Event,Message,Role)\displaystyle \text{Response} = \text{Handler}(\text{Event}, \text{Message}, \text{Role})
  1. 事件类型(Event)Discord 实时推送的事件名称,如“新消息”“成员加入”“按钮点击”,决定了“门铃为什么响”。
    Event\text{Event}
  2. 消息内容(Message)事件携带的具体数据,包含发送者、频道、文本内容,是管家决策的原材料。
    Message\text{Message}
  3. 身份角色(Role)触发者的权限角色集合,决定这个请求是不是“管家该管的事”。
    Role\text{Role}
  4. 处理函数(Handler)开发者为每类事件注册的响应逻辑,把输入映射为具体的输出动作。
    Handler\text{Handler}

AI 对话机器人:管家的待客之道

小e站在前台,业主们陆续来问话:“新人该看哪份公告?”“今晚活动几点开始?”“我该怎么拿到游戏资格?”如果只靠预设话术,它会像个复读机,同一个意思换个说法就听不懂了。合格的管家,得先听懂来意,再记住前文,最后看人下菜碟——这恰好对应了 AI 对话机器人的三个核心模块:意图识别、上下文记忆、个性化回复。

意图识别本质是一个分类问题:给定一段用户输入,判断它属于“咨询规则”“询问时间”“报名活动”中的哪一类。社区对话往往短而碎,用朴素贝叶斯这类统计方法做意图分类非常经典——它把“这段消息像哪种意图”转化为概率比较问题。

除了选对意图,多轮对话还需要“上下文记忆”:把用户最近几轮的消息压缩成摘要存入会话状态,下一次回复时自动带上。情绪感知则更进一步——当识别到“你们规则好麻烦”这类抱怨,模型会降低回复的说教感,换上安抚语气。

有了这三件套,小e就不再是“听到问题”,而是“听懂人心”。它记得小明三分钟前问过怎么进游戏房,也知道此刻他带着情绪,于是回答不再是冷冰冰的规则复述,而是一句“刚来的吧?我带你走一遍流程”。这就是待客之道——用技术还原人与人之间的周到。

P(C∣M)=P(M∣C) P(C)P(M)\displaystyle P(C|M) = \frac{P(M|C)\,P(C)}{P(M)}
  1. 后验概率(P(C|M))已知消息 M,判断它属于意图 C 的概率,这是分类决策的直接依据。
    P(C∣M)P(C|M)
  2. 似然度(P(M|C))从历史对话样本中统计,在意图 C 下消息 M 出现的频率。
    P(M∣C)P(M|C)
  3. 先验概率(P(C))意图 C 在历史对话中固有的出现比例,比如“问规则”总比“投诉”多。
    P(C)P(C)
  4. 归一化项(P(M))所有消息出现概率的总和,用来把分子结果换算成真正的概率值。
    P(M)P(M)

内容审核机制:管家的火眼金睛

小区里总有人半夜贴小广告、发诈骗链接、放侮辱性图片。小e巡逻不能只靠肉眼,它需要一套“风险雷达”:把一条消息拆成多个信号,每个信号单独打分,再按严重程度加权汇总。分数超过阈值直接拦截,游离在临界区则转人工复查。

这套雷达正是内容审核系统。敏感词过滤负责文本层——现实中的黑名单不是简单字符串匹配,而是包含变形词识别,比如剔除中缀混淆;图像识别负责多媒体层,用 CV 模型判断图片中是否有违规元素;行为分析负责时序层,捕捉短时间高频发帖、批量私信等异常动作。三层信号从不孤立判定,而是融合打分。

得到风险分后执行“分级处置”:风险低→仅删消息并私信提醒;风险中→限时禁言并记录;风险高→踢出服务器并上报管理员。系统还需要人工复核通道,避免误伤正常讨论。

小e的火眼金睛,本质是一套“多信号互证”的评分体系。广告词变形了不要紧,陌生链接、低频账号、密集发送三个信号一叠加,风险分照样爆表。单点弱信号的一刀切审核,在小e这里已经过时了。

Risk=∑i=1nwisi\displaystyle \text{Risk} = \sum_{i=1}^{n} w_i s_i
  1. 风险信号(s_i)第 i 个审核信号,例如敏感词命中数、图片违规概率、发送频率异常度。
    sis_i
  2. 信号权重(w_i)该信号的严重程度权重,比如“诈骗链接”的权重远高于“日常广告”。
    wiw_i
  3. 加权求和(∑)把 n 个信号按权重累加,得到消息的综合风险分,再与阈值比较。
    ∑i=1nwisi\sum_{i=1}^{n} w_i s_i

API 集成开发:管家的通信走廊

小e能实时响应,靠的是一条双向通信走廊:一边是“顺风耳”WebSocket——一条从 Discord 服务器直通 Bot 的长连接,任何消息都会在毫秒级推送到 Bot 门口;另一边是“传真机”REST API——Bot 要主动发消息、查用户资料、修改频道权限时,就调用 HTTP 接口完成操作。

WebSocket 长连接听起来简单,实则有一个关键工程细节:心跳机制。网络环境不稳定,连接随时可能假死。Discord 规定 Bot 必须每隔一段时间发送一个心跳包(Heartbeat),用来告诉服务器“我还活着”。如果服务器迟迟收不到心跳,就会判定 Bot 掉线、断开连接并要求重连。这个判定逻辑可以用一个公式概括:

通信走廊的“门禁卡”是 Bot Token。每次 REST 请求都在请求头中携带 Authorization: Bot <token>,Discord 据此确认“你是小e”。Token 必须通过环境变量注入,绝不能硬编码进代码仓库——否则等于把小区门禁卡贴在了公告栏上。

小e之所以能在小区里行动自如,全靠这条走廊维持实时感知和精准行动。WebSocket 负责听,REST 负责说,Token 负责证明“我是我”,三者各司其职,任何一环掉了,管家就成了聋哑人。

在线=(tnow−tlast)<Ttimeout\displaystyle \text{在线} = (t_{\text{now}} - t_{\text{last}}) < T_{\text{timeout}}
  1. 当前时刻(t_now)Bot 本地时钟记录当前时间戳,是判断“是否超时”的参照基准。
    tnowt_{\text{now}}
  2. 上次心跳(t_last)上一次成功发送心跳包的时刻,与当前时刻的差值即为“沉默时长”。
    tlastt_{\text{last}}
  3. 超时阈值(T_timeout)Discord 允许的最大静默时间,超过这个值就会被强制判离线。
    TtimeoutT_{\text{timeout}}
  4. 比较判断(<)沉默时长小于阈值则连接在线,否则需立即启动重连逻辑。
    (tnow−tlast)<Ttimeout(t_{\text{now}} - t_{\text{last}}) < T_{\text{timeout}}

社区管理自动化:管家的例行公事

管家不能等业主上门才干活。每天早上八点,小e播报今日活动;每有新人加入,它第一时间致欢迎词;每晚十二点,它向运营群推送一天的活跃日报。这些“定时 + 触发”的例行公事,就是社区管理自动化——它把物业管理从“人肉盯群”升级为“系统自理”。

自动化的实现依赖三类触发源:事件触发(新成员加入 → 会员欢迎 + 默认角色)、定时触发(cron 表达式 → 早晚播报)、关键词触发(消息匹配“帮助” → 调出 FAQ 卡片)。自动化之上,还要有量化仪表盘——用活跃率这类指标衡量社区健康度:

有了自动化,管理员从“消防员”变回“园丁”:浇水、施肥、修剪由系统代劳,人只负责判断风向、规划花园。日报里的活跃率、违规数、消息量,则像花园的土壤传感器,持续反馈哪些区域需要更多照料。

小e把重复劳动全部接盘,物业团队才能把精力放在真正需要“人味”的事上——策划活动、维护情感、处理复杂纠纷。自动化不是让社区变得冰冷,恰恰相反,它让人力从琐事中解放出来,重新回到人与人的连接上去。

活跃率=N活跃N总×100%\displaystyle \text{活跃率} = \frac{N_{\text{活跃}}}{N_{\text{总}}} \times 100\%
  1. 活跃成员数(N_活跃)统计周期内至少发言一次的成员数量,反映“真正在动”的人。
    N活跃N_{\text{活跃}}
  2. 社区总人数(N_总)服务器内全部成员,包含长期潜水用户。
    N总N_{\text{总}}
  3. 百分化换比活跃人数除以总人数再乘 100%,得到社区活跃率,衡量运营健康度。
    N活跃N总×100%\frac{N_{\text{活跃}}}{N_{\text{总}}} \times 100\%

交互体验增强:管家的百宝工具箱

如果业主必须背“暗号”才能叫小e帮忙——比如输入“!report 名字 理由 证据”,既难记又容易漏参数,很多人试一次就放弃了。小e从百宝箱里掏出了几样神器:斜杠命令、弹窗提示、按钮组件、下拉菜单、内嵌卡片,把“背诵语法”变成“点一下就行”。

斜杠命令(Slash Command)是 Discord 原生的交互入口:用户敲下 /report,输入框上方自动浮现参数表单,依次提示填写举报对象、举报理由,选完即可提交。管理员处理举报时,看到的是带按钮的内嵌消息——点击“通过”或“拦截”,回调信息会携带组件绑定的 custom_id 回到 Bot。这条“点击 → 回调 → 路由”链路就是消息组件的状态机:

多语言支持是体验增强的最后一公里:Bot 的消息模板接入 i18n 框架后,可以按用户设定的语言自动切换欢迎语、错误提示和内嵌卡片文案,让国际社区的每个成员都感到被认真对待。

小e的百宝箱,本质上在践行一条设计原则:让 Bot 迁就用户,而不是用户迁就 Bot。命令、表单、按钮、语言适配——每一个设计都在消灭使用者头脑里“请问我要怎么操作?”那个问题。

Action=Route(custom_id,User,State)\displaystyle \text{Action} = \text{Route}(\text{custom\_id}, \text{User}, \text{State})
  1. 自定义标识(custom_id)每个组件在创建时绑定的唯一 ID,如"approve_msg_12",相当于按钮的身份证号。
    custom_id\text{custom\_id}
  2. 触发用户(User)点击组件的用户信息及其角色权限,用于校验有没有操作资格。
    User\text{User}
  3. 当前状态(State)该流程当前所处状态,如“待审核”“已处理”,决定路由到哪段逻辑。
    State\text{State}
  4. 路由函数(Route)按 custom_id 与 State 找到对应的处理逻辑,返回最终动作(如“通过审核”)。
    Route\text{Route}

AI 应用场景

游戏公会迎新与反诈

阶段:社区业务上线与运营

解决的问题:游戏公会 Discord 群新人涌入快,管理团队只有 3-5 人,无法 24 小时答疑;诈骗分子混入后批量私信“免费送皮肤”,人工依靠截图举报,滞后严重。

具体案例:某游戏公会接入 AI 管家后,新成员加入自动触发欢迎流程:发送规则卡片 + 赋予“萌新”角色 + 引导去新手频道。AI 对话机器人对本群高频问题实时作答,意图识别把“怎么进队”“版本更新”等问句分流到对应回复。审核系统对含陌生链接、高频私信、图片二维码的消息做多信号评分,命中即拦截并通知管理群。上线两周,管理员日均响应时长从 90 分钟降到 10 分钟。

创作者社区内容风控

阶段:内容治理与数据监控

解决的问题:创作者社区鼓励发图与外部链接,但广告机器人也趁机批量遍历频道发推广图;人工翻频道审核效率低且容易漏看。

具体案例:某创作者社区部署内容审核 Bot:图片识别模块给重复广告模板打“疑似广告”标签,行为模块检测到“新账号 30 秒内连发 5 条”的异常图谱,两路信号加权后风险分超过阈值,消息被自动折叠并进入人工复核队列。管理员在审核频道里通过按钮组件“通过/删除”快速处置,处置结果经由 Webhook 同步进工单系统留痕。

Python 演示

python67 行
import re  class CommunityAssistant:    def __init__(self, bot_name):        self.bot_name = bot_name        self.msg_count = 0        self.warning_count = 0        self.sensitive_words = ["广告", "诈骗", "仇恨"]        self.intent_words = {            "greeting": ["你好", "hi", "hello"],            "rule": ["规则", "公告", "公约"],            "activity": ["活动", "比赛", "开黑"]        }        self.reply_map = {            "greeting": "你好!我是{},社区智能助手,输入“规则”可查看公约。".format(self.bot_name),            "rule": "社区公约:友善发言、禁止广告、禁止人身攻击。",            "activity": "今晚 8 点有开黑活动,欢迎参加!"        }     def detect_intent(self, content):        text = content.lower()        for intent, keys in self.intent_words.items():            for key in keys:                if key in text:                    return intent        return "unknown"     def score_content(self, content):        score = 0        for word in self.sensitive_words:            if word in content:                score += 2        if re.search(r"https?://", content):            score += 1        return score     def handle_message(self, user, content):        self.msg_count += 1        risk = self.score_content(content)        if risk >= 2:            self.warning_count += 1            return "[审核] 检测到违规内容,消息已拦截。"        intent = self.detect_intent(content)        return self.reply_map.get(intent, "已收到消息,我会尽快处理。")     def generate_report(self):        return "今日共收到 {} 条消息,拦截 {} 条违规。".format(self.msg_count, self.warning_count)  def main():    bot = CommunityAssistant("小e")    messages = [        ("小明", "你好"),        ("小华", "点此链接免费领皮肤 http://xxx.com"),        ("小刚", "活动"),        ("小丽", "这是诈骗吗"),        ("小新", "规则")    ]    for name, text in messages:        reply = bot.handle_message(name, text)        print("[{}] {} -> {}".format(name, text, reply))    print(bot.generate_report())  if __name__ == "__main__":    main()
目的:用极简代码模拟社区 AI 管家的完整处理链路——消息进入后先过审核评分,再走意图识别,最后返回回复或拦截结果。
  1. self.intent_words = {...}构建意图关键词表,这是“听懂来意”的简化版
  2. def detect_intent(self, content):遍历关键词表,返回匹配到的意图类别
  3. def score_content(self, content):审核评分:敏感词 +2、外链 +1
  4. if re.search(r"https?://", content):用正则识别 URL,作为风险信号之一
  5. risk >= 2:风险分达到阈值直接拦截,对应审核系统的分级处置
  6. self.reply_map.get(intent, ...)按意图查回复表,未命中时给兜底话术
  7. self.msg_count += 1每条消息入账,为最终日报统计攒数据
  8. def main():模拟社区消息流,演示从审核到回复的完整链路

常见误区

误区我给 Bot 接一个 ChatGPT API,它就能自动管理社区了,不需要再设计其他逻辑。用户说什么它都能答,这不就是 AI 管家吗?

正解大模型只是管家的大脑,Bot 还需要“神经系统”(事件监听)、“手”(API 调用)、“眼睛”(审核策略)。最流畅的架构是:先让意图识别判断该不该动用大模型,再让审核系统过滤不安全输入,最后才让大模型生成回复。否则社区会被“什么都敢答”的 Bot 带去沟里。

为何常见:大模型效果惊艳,容易让人误以为它天然具备产品化的所有能力,忽略了真实工程链路中上下文过滤、权限控制和成本管理。

误区只要把常见的脏话、广告词放进黑名单,审核就完成了。毕竟社区里 80% 的违规都是广告,挡住关键词就行。

正解真实社区的违规内容会用变形词、谐音、图片、链接等形式出现。成熟的做法是多信号加权:文本命中、链接检测、图片识别、行为频率(如刷屏、短时间批量私信)综合打分,再配合分级处置。单靠关键词表,广告换个写法就穿帮了。

为何常见:敏感词过滤实现最简单、肉眼可见,容易让人误以为它是审核的全部,忽略了对抗性攻击的存在。

误区Discord 不也提供 Webhook 吗?我拿 Webhook 接收消息不就行了,为什么还要 WebSocket?

正解Webhook 是“出站”通知——它是 Discord 把事件推送到你预先登记的服务器 URL,主要用于服务器自运维,且只支持有限事件。而 Bot 与 Discord 的实时通信基于 WebSocket 长连接(Gateway API),事件全、延迟低、支持双向交互。两者是不同工具,Bot 场景必须用 WebSocket。

为何常见:名字里都带 web,概念容易混淆;且部分第三方教程把两者混为一谈,误导初学者。

误区给 Bot 注册几十条斜杠命令,显得功能强大,社区用户会觉得这个 AI 管家很厉害。

正解命令过多反而让用户选择困难。设计原则是“高频操作做命令,低频流程用按钮和菜单引导”。比如“举报”这种流程型操作,一个 /report 命令加按钮组件,比三条散乱命令更清晰,因为系统会一步步引导用户完成。

为何常见:平台支持的功能都想堆上去,忽略了交互设计和用户认知负担,本质是“以功能为中心”而非“以体验为中心”。

面试题

Q1. Discord Bot 接收新消息主要依赖于哪种连接方式?

单选题 · easy

  • A.客户端轮询 HTTP 接口
  • B.WebSocket 长连接推送← 正确答案
  • C.服务器定时同步文件
  • D.邮件网关转发通知

答案:B。Discord 使用 Gateway API(WebSocket)向 Bot 实时推送事件,保证低延迟且不依赖客户端反复请求。轮询虽可实现但效率低、易撞速率限制;C 和 D 不是 Discord 的事件通道。

Q2. 实现多轮对话式 AI 机器人,不可或缺的模块有哪些?

多选题 · mid

  • A.上下文记忆存储← 正确答案
  • B.意图识别模块← 正确答案
  • C.物理声卡驱动
  • D.独立网页服务器

答案:AB。多轮对话需要记住前文(上下文记忆)并判断每句来意(意图识别),才能给出连贯回复。C 和 D 与文本对话场景无关——Discord Bot 运行在云端,不需要本地声卡,也不需要自建网页服务器。

Q3. 内容审核中,综合风险分最常见的计算方式是?

单选题 · mid

  • A.保留所有信号中的最大值
  • B.多个信号加权相加← 正确答案
  • C.随机生成一个分数
  • D.所有信号简单求平均

答案:B。风险分 = Σ(w_i × s_i),加权让不同信号按严重程度贡献分数。取最大值会忽略多个弱信号的叠加;平均值丧失权重语义;随机数完全没有意义。

Q4. REST 方式调用 Discord API 时,身份凭证应放在哪里?

单选题 · easy

  • A.请求头 Authorization 中← 正确答案
  • B.请求体 JSON 字段中
  • C.URL 查询参数明文中
  • D.请求来源 IP 地址中

答案:A。Discord REST API 要求请求头携带 Authorization: Bot <token>。Token 放入 Body 或 URL 都容易泄露,IP 地址只用于访问来源识别,不能作为授权凭证。

Q5. 社区“欢迎新成员”自动化流程通常包含哪些动作?

多选题 · mid

  • A.发送定制欢迎语← 正确答案
  • B.自动赋予默认角色← 正确答案
  • C.清空所有历史消息
  • D.将成员移出服务器

答案:AB。欢迎新成员 = 给个问候 + 给个身份(默认角色),让新人快速开始探索社区。C 和 D 是惩罚性操作,与“欢迎”完全反向,也不是自动化欢迎流程的组成部分。

Q6. 关于 Discord 速率限制(Rate Limit),正确的描述是?

单选题 · hard

  • A.允许请求无限量追加
  • B.按窗口时长等分配额← 正确答案
  • C.只限制 Webhook 通道
  • D.与 Bot Token 毫无关系

答案:B。Discord 对每个接口按固定时间窗口设置请求配额,窗口内的请求需等分间隔,避免压垮服务器。A 与限制初衷相悖;C 和 D 错误——速率限制作用于所有 REST 与 Gateway 流量,且按 Token 计数。

Q7. 斜杠命令相比普通文本命令的最大优势是?

单选题 · easy

  • A.自动弹出参数提示表单← 正确答案
  • B.无需注册即可全局生效
  • C.无法返回任何类型信息
  • D.只能由管理员权限触发

答案:A。斜杠命令由 Discord 原生解析,用户输入 / 即看到命令和参数占位提示,减少格式错误。B 错误——斜杠命令必须先注册到服务器或全局;C 和 D 是错误结论。

Q8. 适合作为内容审核风险信号的是?

多选题 · hard

  • A.敏感词命中检测← 正确答案
  • B.发送频率异常上升← 正确答案
  • C.图片违规概率分← 正确答案
  • D.用户头像背景颜色

答案:ABC。文本、行为、图片三类信号是风控雷达的组成。头像颜色与内容违规无因果关联,既不是信号,也不该进入风险计算,否则会制造大量误判。

Q9. Discord 消息组件(Message Components)的主要作用是?

单选题 · mid

  • A.在消息里渲染按钮与菜单← 正确答案
  • B.替代 Token 完成身份验证
  • C.压缩大型文件后转发
  • D.自动翻译全部频道内容

答案:A。消息组件让 Bot 在消息内嵌入按钮、选择菜单等交互控件,点击后以 custom_id 回调 Bot。B、C、D 分别属于身份、文件、翻译能力,与消息组件无关。

Q10. Bot 的 WebSocket 频繁掉线,最可能的原因是?

单选题 · extreme

  • A.心跳包未及时发送导致超时← 正确答案
  • B.服务器内存小于 64GB
  • C.用户头像使用了动态图
  • D.Bot 名称包含中文字符

答案:A。Discord Gateway 用心跳判定连接存活性,Bot 未按频次回复心跳包即被强制断开。B、C、D 与连接稳定性无关——服务器硬件、头像格式、Bot 名称均不影响 Gateway 连接。