我搭建了一个 QQ 机器人——墨璃（Molí）

项目背景

墨璃（Molí）是一个基于 NoneBot2 框架、接入 DeepSeek 大模型的自建 QQ 机器人，部署在我自己的服务器上，主要用于所在 QQ 群的日常管理与信息查询。本文记录它的整体架构、已实现的核心功能，以及一次因腾讯风控策略导致的离线故障与处理过程。

整体架构

系统由两部分组成：

• NoneBot2 服务（qq-bot）：运行于服务器上的 Python 机器人进程，负责接收消息事件、按插件优先级进行分发与处理，并通过 DeepSeek 接口提供对话能力。
• NapCat 容器：以 Docker 形式运行的 OneBot 协议实现，负责与 QQ 服务器建立连接、登录机器人账号，并将消息以标准事件格式转发给 NoneBot2。

两部分之间的通信采用反向 WebSocket：NapCat 主动连接 NoneBot2 监听的 7700 端口。这一设计规避了正向 WebSocket 存在的 30 秒硬编码超时问题，连接稳定性更好。NapCat 通过扫码登录机器人账号（”寰墟”）后，依靠长连接持续收发消息；NoneBot2 收到 OneBot 事件后，依据插件声明的优先级进行分发——对话插件（priority=4）与 B 站解析插件（priority=3）各司其职，互不冲突。B 站数据获取部分还实现了 wbi 签名与针对 -352 风控码的退避重试机制，以降低接口请求被限频的概率。

核心功能

• 智能对话：接入 DeepSeek，支持 @ 触发对话，可作为搜索与问答入口。
• 群管理：提供 /ban、/mute、/kick 等指令，支持关键词撤回与全员提醒，权限划分为 superadmin 与 admin 两级。
• B 站数据解析：在群内发送 B 站链接并 @ 机器人，可返回视频标题、简介、UP 主信息、粉丝数及点赞 / 投币 / 收藏等互动数据；同时支持榜单查询与指定 UP 主的数据检索（粉丝数、稿件数、关注 / 被关注数、点赞数）。
• 管理面板：通过 bot.survoid.top 提供 Web 管理界面，可查看好友申请、配置管理员与插件的启用状态。

一次风控导致的离线故障

某日早晨，有群成员反馈机器人无响应。初步排查显示：qq-bot 进程处于 running 状态，NapCat 容器已持续运行多日未重启，反向 WebSocket 连接也保持 ESTABLISHED。然而 NapCat 日志中出现”账号状态变更为离线”的记录，表明问题并非服务进程崩溃，而是机器人账号被腾讯服务端强制下线。

使用手机客户端登录该账号时，系统提示”已登录设备风险提醒，设备存在外挂或其他软件影响 QQ 正常使用，已经进行下线处理”。该提示表明，腾讯将 NapCat 这类第三方协议客户端识别为违规外挂，并对账号及关联设备执行了强制下线。

重启 NapCat 并重新扫码登录只能临时恢复，因为此类风控针对的是协议层特征，NapCat 本身无法规避；反复登录反而可能触发更严格的账号限制。从长期稳定性考虑，可选方案包括：更换已被标记的服务器 IP、迁移至 QQ 官方机器人平台（合规但无法进入普通群）、或改用独立的机器人小号。

此次故障也印证了排查顺序的重要性：在确认进程、容器、网络连接均正常之前，不应贸然重启服务——表面的”无响应”未必源于服务崩溃。

代码仓库

墨璃核心的 B 站解析插件已开源，同时托管于 GitHub 与 Gitee：

• GitHub：GreaterLG70/nonebot-plugin-bilibili
• Gitee：smooge/nonebot-plugin-bilibili

主项目（含 NoneBot2 服务与部署配置）因涉及服务器凭据与私有配置，暂未公开。

小结

墨璃目前稳定运行于所在 QQ 群，承担了信息查询、群管理与日常对话等职责。作为一个个人项目，它在功能完整度与运维复杂度之间取得了可接受的平衡。后续若对账号或协议方案进行调整，将继续在此记录。