从QQ收到消息到DeepSeek自动回复：AstrBot+NapCat的Docker部署、OneBot联通、插件MCP与远程管理完整实战

前言

这篇不是只把两个 Docker 容器拉起来，而是完整验证一条 QQ AI 机器人链路：NapCat 登录 QQ 并提供 OneBot 接口，AstrBot 接收消息、管理机器人逻辑，再通过 DeepSeek API 生成回复。只有消息从 QQ 进来、AI 返回、回复再发回 QQ，这套系统才算真正工作。

部署从 Windows 11 + Docker 开始，同时保留 Linux Compose 方式。先确认 AstrBot 6185 和 NapCat 6099 页面，再完成 NapCat Token 登录、QQ 扫码、AstrBot 平台配置和消息收发测试。

随后继续接入 DeepSeek、人格设定、流式分段、插件和 MCP，并用 12306 MCP 做实际调用验证。

最后把 AstrBot WebUI 做远程访问，并区分随机地址与固定地址。全文重点放在“部署—QQ协议—AI回复—扩展能力—远程管理”这条链上，同时把第三方脚本、默认密码、Token和公网后台这些风险单独说清楚。

我也会把“容器启动成功”和“机器人真正可用”分开判断：6185、6099能打开，只能证明Web服务在；只有另一账号发消息后，AstrBot能收到、DeepSeek能返回、QQ端能看到回复，整条业务链才算跑通。

另外，这套方案后半段已经不只是聊天机器人：人格、插件和MCP都属于继续扩展能力的入口。正因为功能越来越多，账号、Token、API Key和后台访问权限也更值得提前处理，不能只追求“功能都装上了”。这也是这篇会把安全边界和功能步骤放在同一条主线里的原因。

1 先把AstrBot、NapCat、DeepSeek之间的关系理清楚

这套方案里最容易混淆的是：三个组件都和“机器人”有关，但职责完全不同。

NapCat 负责 QQ 这一侧。它是基于 NTQQ 的协议端实现，可以把 QQ 的消息能力通过 OneBot 等接口提供给上层程序。

AstrBot 是机器人框架，负责接收消息、管理平台适配、调用大模型、人格、插件和 MCP。

DeepSeek 在这里是模型提供商，负责真正生成 AI 回复。

整条链可以理解成：

QQ → NapCat → OneBot → AstrBot → DeepSeek → AstrBot → NapCat → QQ

只要这条链中的任何一段断开，机器人都可能表现成“不回复”。

2 先准备Docker环境

这篇演示环境是 Windows 11。

如果已经安装 Docker，可以直接进入后面的部署步骤。

Windows 下打开 PowerShell，执行：

irm https://gitee.com/jun-wan/script/raw/master/astrbot/deploy_astrbot.ps1 | iex

这条 PowerShell 命令会直接从第三方 Gitee 地址下载并执行脚本。

它确实省步骤，但长期使用前更稳妥的做法是先查看脚本内容，确认：

• 下载了什么文件；
• 使用了哪些镜像；
• 创建了哪些目录；
• 暴露了哪些端口；
• 有没有写入额外配置。

“一键脚本”方便，不代表应该无条件执行。

3 Linux可以直接使用Compose方式

Linux 方式：

mkdir astrbot
cd astrbot
wget https://raw.githubusercontent.com/NapNeko/NapCat-Docker/main/compose/astrbot.yml
sudo docker compose -f astrbot.yml up -d

这组命令会下载 NapCat-Docker 提供的 astrbot.yml，然后通过 Docker Compose 启动。

如果仍然希望用一键脚本，也可以执行：

curl -fsSL https://gitee.com/jun-wan/script/raw/master/astrbot/deploy_astrbot.sh | bash

同样建议先查看脚本来源和内容。

4 先确认两个Web页面都能打开

部署完成后，先看 AstrBot：

http://localhost:6185

再看 NapCat：

http://localhost:6099

现在只是证明：

• AstrBot WebUI 在 6185；
• NapCat WebUI 在 6099；
• 两个容器已经能从宿主机访问。

这还不代表 QQ 消息链已经打通。

5 NapCat先用Token登录WebUI

打开：

http://localhost:6099/

页面会要求 Token。

部署日志中会输出 Token：

如果控制台信息已经滚走，可以执行：

docker logs napcat | Select-String "Token"

找到 Token 后填回 WebUI：

Token 本质上是管理凭据，不要截图后公开，也不要把真实 Token 发到群里或文章里。

6 再登录真正要作为机器人的QQ账号

NapCat WebUI 登录后，选择扫码方式登录 QQ：

到这里，NapCat 才真正拿到了这个 QQ 账号对应的消息入口。

需要注意的是，NapCat 是社区 OneBot 方案。QQ 平台规则、客户端版本和协议实现都会影响长期可用性，账号使用时应遵守 QQ 相关规则，不要把“能登录”理解成“官方机器人接口”。

7 初始化AstrBot

打开：

http://localhost:6185

教程截图里使用了 astrbot 账号密码进入后台：

不同 AstrBot 版本初始化登录方式可能变化。

如果默认账号密码无法登录，不要反复尝试固定密码，优先看容器启动日志和当前版本的初始化说明。

第一次登录后，应立即修改管理凭据。

8 在AstrBot里创建QQ平台适配

进入机器人页面，创建机器人，消息类别选择 QQ 个人号并启用：

保存时如果出现安全提醒：

教程操作选择继续创建。

但“本地环境”并不等于可以永远不设 Token。

如果 OneBot 接口未来会跨容器、跨主机甚至对外开放，认证就应该重新评估。

9 先验证QQ消息能不能进AstrBot

用另一个 QQ 给机器人账号发消息：

日志里能看到消息以后，可以确认：

QQ → NapCat → AstrBot

这半条链已经通了。

这里还没有接大模型，所以这一阶段重点只看消息通信。

10 获取DeepSeek API Key

进入：

https://platform.deepseek.com

打开 API Keys 页面：

创建密钥：

API Key 只会完整显示一次。

复制以后应该放在安全位置，不要写进公开截图、GitHub 或文章正文。

如果怀疑密钥已经泄露，最稳妥的做法是立即删除并重新生成。

11 把DeepSeek接进AstrBot

AstrBot 后台进入模型提供商，新建 DeepSeek：

填入 API Key：

保存后测试：

这一层成功后，AstrBot 已经有了可调用的模型服务。

12 再从QQ端做一次完整对话验证

回到另一个 QQ 账号，给机器人发消息：

能收到 AI 回复以后，才算真正打通：

QQ → NapCat → AstrBot → DeepSeek → AstrBot → NapCat → QQ

这一步比“模型提供商测试成功”更有价值，因为它证明整条消息链都工作了。

13 默认回答太像机器人，可以再做人设

默认提示词类似：

你是一个乐于助人、友好的助手……

对应页面：

如果希望回复风格更像某个固定角色，可以在 AstrBot 里创建人格设定：

人格本质上是系统提示词。

它改变的是表达风格和行为约束，不会让底层模型能力凭空提升。

14 第三方人设包只能当可选资源

教程还提供了一个第三方人设包链接：

123云盘永久链接：https://www.123865.com/s/3jOKVv-GSNzH?pwd=1314#

提取码：1314

这类网盘资源不属于 AstrBot 核心部署必需内容。

如果要使用，建议先检查文件内容，不要把未知脚本、配置或提示词直接导入长期运行的机器人。

15 用命令查看和切换人格

查看人格相关命令：

/persona

查看人格列表：

/persona list

切换人格：

/persona 猫娘(请替换为你创建好的人格ID名称)

发送消息测试：

人格能生效以后，说明 AstrBot 已经把对应系统提示词应用到当前会话。

16 回复太长，可以开启分段方式

后台开启流式回复相关设置：

再次测试：

如果切换人格，教程还特别提醒清理上下文：

# 切换人设
/persona <你要切换的人格设定ID名称>

# 清空上下文，防止原人格对话影响现人格
/reset

重新测试：

这一点很重要。

如果旧人格的上下文还保留着，新人格很容易继续受到前面聊天内容影响。

17 插件是AstrBot的第二层扩展

进入插件市场：

搜索音乐插件：

安装前可以测试下载节点连通性：

安装完成后查看说明：

然后在 QQ 中发送：

/点歌 恋人（你想要点歌的歌曲名字）

成功返回歌曲卡片以后，可以确认：

插件功能已经真正进入 QQ 会话。

不过插件来自不同作者，权限、更新频率和数据来源都不同。

正式长期使用前，最好先看插件说明和代码来源。

18 MCP解决的是“让AI调用外部工具”

基础大模型只能根据已有上下文生成回答。

MCP 的作用，是通过标准接口让模型连接外部工具或服务。

例如：

• 查询数据；
• 调用 API；
• 获取实时信息；
• 执行某个具体工具。

AstrBot 把 MCP 作为一层可配置的工具能力。

19 在AstrBot里添加MCP服务

进入 MCP 页面：

教程跳转到：

https://www.modelscope.cn/mcp

以 12306 MCP 为例：

复制 MCP 配置：

{
    "mcpServers": {
        "12306-mcp": {
            "command": "npx",
            "args": [
                "-y",
                "12306-mcp"
            ]
        }
    }
}

然后回到 AstrBot，新建服务器并测试：

这里配置里的 npx -y 12306-mcp 会在运行时拉取并执行对应 npm 包。

因此和一键部署脚本一样，长期使用前应该确认包来源和维护状态。

20 测试12306 MCP

回到聊天窗口提问：

测试中返回了车次、时间、座位和价格等信息。

这证明 MCP 调用链能够工作。

但车票属于强时效数据，真正出行仍应以官方铁路渠道显示的信息为准，不能只把一次机器人回答当作最终购票依据。

21 到这里，本地QQ AI机器人已经真正跑通

现在已经实际验证：

• AstrBot WebUI；
• NapCat WebUI；
• QQ扫码登录；
• QQ消息进入 AstrBot；
• DeepSeek 模型调用；
• QQ端收到 AI 回复；
• 人格切换；
• 分段回复；
• 插件；
• MCP。

如果只在家里维护机器人，到这里已经可以使用。

后面的公网部分解决的是：

人在外面怎么进入 AstrBot 管理后台。

22 远程访问AstrBot后台之前，先看清风险

AstrBot WebUI 里可能存在：

• 模型 API Key；
• 机器人平台配置；
• 人格；
• 插件；
• MCP；
• 日志；
• 管理账号。

所以它和普通静态网页完全不同。

把 6185 放到公网之前，应至少做到：

• 修改默认管理密码；
• 不共享管理员账号；
• 不把公网地址公开发布；
• 能加额外访问控制时尽量加；
• 不在截图里泄露 API Key 和 Token。

23 安装cpolar

说明页面：

Windows 下载：

安装以后执行：

cpolar version

24 注册并进入Web UI

注册：

继续完成：

访问：

http://127.0.0.1:9200

登录：

后面的隧道都从这个页面配置。

25 先用随机地址验证6185

教程利用已有 website 隧道：

编辑为 AstrBot 需要的 6185：

在线隧道：

然后外部浏览器测试：

能打开以后，可以确认：

外部浏览器 → 公网地址 → cpolar → 本机6185 → AstrBot WebUI

链路已经通了。

26 随机地址变化周期不要写成永久规则

教程里写“约24小时自动更换”。

这属于产品策略，可能随套餐和版本调整。

长期文章更稳妥的说法是：

随机地址可能变化，具体规则以当前账号页面为准。

如果只是临时远程维护，随机地址已经够用。

27 长期维护再考虑固定二级子域名

进入：

https://dashboard.cpolar.com/reserved

示例保留：

astrbot

然后进入隧道列表：

把域名类型切换为二级子域名：

更新后查看：

最后访问：

到这里，固定远程入口配置完成。

但“固定”只是地址不需要频繁修改，不代表账号、服务和套餐条件永远不会变化。

28 最不建议做的是把管理面板发给朋友随便看

教程里提到可以把管理面板分享给异地朋友。

从安全角度看，这并不是一个好的默认建议。

AstrBot 后台是管理面板，不是展示页。

如果只是想让别人体验机器人，最合理的入口就是：

QQ机器人本身。

远程 WebUI 更适合管理员自己维护，而不是当成公开页面分享。

29 整套链路真正应该这样理解

QQ通信：

QQ → NapCat → OneBot → AstrBot

AI：

AstrBot → DeepSeek → AstrBot

扩展：

AstrBot → 人格 / 插件 / MCP

远程管理：

浏览器 → 公网入口 → AstrBot 6185

每一层职责分开以后，排错也会简单很多。

机器人不收消息，先查 NapCat / OneBot。

能收消息但不回复，查 AstrBot 和模型提供商。

插件不工作，查插件自身。

MCP 不工作，查 MCP 服务。

外面打不开后台，再查网络入口。

30 这篇真正完成了什么

实际验证：

• Docker 部署 AstrBot + NapCat；
• AstrBot 6185；
• NapCat 6099；
• NapCat Token；
• QQ 扫码登录；
• OneBot 消息进入 AstrBot；
• DeepSeek API；
• QQ AI 回复；
• 人格切换；
• 分段回复；
• 插件；
• 12306 MCP；
• AstrBot 随机公网访问；
• 固定二级子域名访问。

需要继续谨慎的地方：

• 第三方一键部署脚本；
• 默认账号密码；
• NapCat / OneBot Token；
• DeepSeek API Key；
• 第三方人格包；
• 插件来源；
• MCP npm 包；
• AstrBot WebUI 公网暴露。

把这些边界说清楚以后，这篇才真正像一套可以长期维护的 QQ AI 机器人方案。

总结

整套方案可以拆成四层：NapCat负责QQ协议和OneBot接口，AstrBot负责机器人逻辑，DeepSeek负责模型回复，插件与MCP负责扩展工具能力。

本文已经完成Docker部署、QQ扫码登录、消息联通、DeepSeek回复、人设、插件、MCP，以及AstrBot WebUI的随机和固定远程访问。

需要注意的是，能从公网打开6185并不等于应该公开它。AstrBot后台属于管理入口，包含敏感配置，长期远程使用时必须把登录凭据、API Key、Token和访问范围一起考虑。

把这些职责和边界分清以后，这套系统才更适合作为长期运行的QQ AI机器人，而不是一次性的“5分钟能跑起来”演示。