1. 项目缘起与整体架构拆解QQ 这个国民级聊天工具在 Ubuntu 桌面环境下的使用体验一直是个老大难问题。官方客户端长期停留在 Electron 套壳阶段资源占用高、消息同步慢更别提做自动化了。我平时主力开发机就是 Ubuntu每天挂着 QQ 处理各种群消息和私聊时间一长就萌生了一个想法能不能让机器人帮我自动处理那些重复性高的回复比如常见问题答疑、群规提醒、消息分类归档这个项目的核心目标很明确——在 Ubuntu 上跑一个 QQ 智能回复机器人能自动接收消息、调用大模型生成回复、再把结果发回去。技术选型上消息协议层用 NapCatAI 推理层用 DeepSeek中间用 Python 做胶水逻辑。整套方案跑下来资源占用比想象中低得多一台 2C4G 的轻量服务器就能稳定运行。先说说为什么选 NapCat。QQ 的协议实现方案有好几种NapCat 的优势在于它基于 NTQQ 协议走的是官方客户端同款通信链路稳定性比那些逆向老协议好太多。而且它提供了标准的 OneBot v11 接口这意味着任何支持 OneBot 的框架都能直接对接生态兼容性极强。我实测下来NapCat 在 Ubuntu 上的部署难度很低Docker 一键拉起配置文件清晰日志也够详细出问题好排查。再说 DeepSeek。选它主要看中三点一是 API 价格便宜对于机器人这种高频调用场景成本可控是硬指标二是中文理解能力强QQ 聊天场景里大量口语化表达、网络梗、缩写DeepSeek 的处理效果明显好于同价位其他模型三是响应速度快流式输出延迟低用户等待感不强。当然你也可以换成其他兼容 OpenAI 接口的模型代码层面只需要改 base_url 和 model 名称。整个系统的数据流是这样的QQ 客户端收到消息 → NapCat 通过 OneBot 协议推送到本地 HTTP/WebSocket 服务 → Python 机器人框架接收事件 → 判断是否需要 AI 回复 → 调用 DeepSeek API → 拿到回复内容 → 通过 NapCat 的 send_msg 接口发回 QQ。这条链路里NapCat 负责协议转换Python 负责业务逻辑DeepSeek 负责内容生成各司其职。注意NapCat 的部署方式直接影响后续对接的稳定性。我建议用 Docker 方式部署版本锁定在稳定版不要追最新。配置文件里记得开启反向 WebSocket这样机器人框架可以主动连接 NapCat而不是 NapCat 推送到机器人网络穿透和重连逻辑会简单很多。架构设计上还有一个关键决策消息处理是同步还是异步我选择全异步方案用 Python 的 asyncio 配合 WebSocket 客户端。原因很简单QQ 消息是突发性的群里可能一瞬间涌进来几十条消息同步处理会阻塞异步方案可以并发调用 DeepSeek API响应更快。但异步也带来了新问题——消息顺序可能乱所以我在发送环节加了一个简单的队列保证同一会话的回复按顺序发出。2. 环境准备与 NapCat 部署实操Ubuntu 环境下的准备工作其实不复杂但有几个坑我踩过这里直接给你铺平。首先确认系统版本我用的 Ubuntu 22.04 LTS20.04 也能跑但 18.04 及以下不建议主要是 Docker 和 Python 版本太老依赖装起来费劲。硬件方面2 核 CPU、4G 内存是底线如果群多消息量大建议 4 核 8G。第一步装 Docker 和 Docker Compose。Ubuntu 官方源里的 Docker 版本偏旧我习惯用官方脚本安装curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun sudo systemctl enable docker sudo systemctl start docker装完之后验证一下版本Docker 20.10 以上、Compose v2 以上就够用。这里有个细节如果你的服务器在国内拉取 Docker Hub 镜像可能很慢建议配置镜像加速器。编辑/etc/docker/daemon.json加入加速地址然后重启 Docker 服务。具体加速地址网上很多选一个稳定的就行。接下来部署 NapCat。官方提供了 Docker 镜像直接拉取运行docker run -d \ --name napcat \ --restart always \ -p 3000:3000 \ -p 6099:6099 \ -v /opt/napcat/config:/app/napcat/config \ -v /opt/napcat/data:/app/napcat/data \ mlikiowa/napcat-docker:latest这里解释一下端口映射。3000 是 OneBot 的 HTTP/WebSocket 服务端口6099 是 NapCat 的 WebUI 管理端口。数据卷挂载很重要配置文件和登录态都在里面不挂载的话容器一删就得重新扫码登录。容器跑起来之后打开浏览器访问http://你的服务器IP:6099进入 NapCat 的 WebUI。第一次登录需要扫码用手机 QQ 扫一下就行。登录成功后在 WebUI 里配置 OneBot 服务。我建议开启反向 WebSocket配置如下配置项值说明服务类型反向 WebSocket机器人主动连接 NapCat服务地址ws://127.0.0.1:3001机器人监听的地址Token自定义一串随机字符用于鉴权防止未授权连接消息格式array推荐用数组格式解析更方便提示Token 一定要设置而且不要用简单密码。我见过有人没设 Token结果机器人被外部连接利用疯狂发广告。安全无小事这一步别偷懒。NapCat 配置好之后你可以先用 WebUI 里的测试功能发一条消息给自己确认协议链路通了。如果发不出去检查容器日志docker logs napcat常见问题是登录态失效或者端口冲突。Python 环境方面我建议用 3.10 以上版本直接系统自带或者用 pyenv 管理都行。依赖库主要就几个websockets用于 WebSocket 通信aiohttp用于调用 DeepSeek APIpyyaml用于读配置文件。创建一个虚拟环境把这些装进去python3 -m venv venv source venv/bin/activate pip install websockets aiohttp pyyaml到这里基础环境就齐了。整个准备过程顺利的话半小时内能搞定主要时间花在扫码登录和配置调试上。3. 机器人核心逻辑与 DeepSeek 对接机器人框架的核心其实就三件事收消息、判断、回消息。但要把这三件事做稳细节不少。我先从消息接收说起。NapCat 通过反向 WebSocket 把消息推送到我们监听的端口消息格式是 OneBot v11 标准的 JSON。一条典型的群消息事件长这样{ post_type: message, message_type: group, group_id: 123456789, user_id: 987654321, raw_message: 你好请问怎么配置机器人, message_id: 10001, sender: { nickname: 某用户, card: 群名片 } }我们需要解析这个 JSON提取出关键字段。私聊消息的message_type是private群消息是group。raw_message是纯文本内容如果消息里包含图片、表情等非文本元素raw_message里会有对应的 CQ 码比如[CQ:image,filexxx]。做智能回复的话我建议只处理纯文本消息非文本消息直接跳过或者记录日志不然处理逻辑会复杂很多。判断逻辑是机器人的大脑。我的设计是这样的首先判断消息是否来自允许的群或用户用一个白名单机制避免机器人被拉进陌生群乱说话。然后判断消息是否触发了回复条件我设了三种触发方式——机器人、以特定前缀开头比如#ai、或者私聊直接发消息。最后判断消息内容是否为空或者纯表情这类消息不调用 AI省点 API 费用。DeepSeek 的 API 调用是核心环节。它的接口兼容 OpenAI 格式所以直接用 aiohttp 发 POST 请求就行import aiohttp import json async def call_deepseek(prompt, api_key, base_urlhttps://api.deepseek.com): headers { Authorization: fBearer {api_key}, Content-Type: application/json } payload { model: deepseek-chat, messages: [ {role: system, content: 你是一个QQ群助手回答要简洁友好不超过100字。}, {role: user, content: prompt} ], temperature: 0.7, max_tokens: 200 } async with aiohttp.ClientSession() as session: async with session.post( f{base_url}/v1/chat/completions, headersheaders, jsonpayload, timeoutaiohttp.ClientTimeout(total30) ) as resp: data await resp.json() return data[choices][0][message][content]这段代码里有几个参数值得展开说。temperature控制回复的随机性0.7 是个比较平衡的值太低回复会显得死板太高又容易跑偏。max_tokens限制回复长度QQ 聊天场景不需要长篇大论200 个 token 足够。system提示词很关键我试过不加 system 提示模型会回复得很正式像在写邮件加了简洁友好的约束之后语气自然多了。实操心得DeepSeek 的 API 有速率限制免费额度和付费额度的限制不同。如果你的机器人消息量大建议在代码里加一个简单的令牌桶限流比如每秒最多调用 5 次超出的请求排队等待。不然触发限流会返回 429 错误用户体验很差。消息发送环节调用 NapCat 的send_msg接口async def send_message(ws, msg_type, target_id, content): payload { action: send_msg, params: { message_type: msg_type, user_id: target_id if msg_type private else None, group_id: target_id if msg_type group else None, message: content } } await ws.send(json.dumps(payload))这里有个细节群消息和私聊消息的参数名不同群消息用group_id私聊用user_id。传错参数消息发不出去而且 NapCat 不一定报错只是静默失败排查起来很头疼。我建议在发送之后加一个日志记录把发送内容和目标 ID 都打出来方便对账。整个核心逻辑串起来大概两百行代码不算复杂但每个环节都有坑。比如 WebSocket 断线重连、API 调用超时处理、消息去重防止同一条消息被处理两次这些都需要在代码里做好防护。4. 常见问题排查与稳定性优化机器人跑起来容易跑稳难。我上线第一周遇到了各种问题这里整理成速查表你遇到类似情况可以直接对照排查。问题现象可能原因排查方法解决方案机器人不回复WebSocket 未连接查看机器人日志有无连接成功记录检查 NapCat 反向 WS 配置和 Token回复重复发送消息事件被处理两次日志里看同一 message_id 是否出现两次加消息 ID 去重集合处理过的 ID 不再处理API 返回 401DeepSeek Key 无效或过期用 curl 直接测试 API重新生成 Key检查是否有多余空格回复内容乱码编码问题检查发送时的 content 编码确保 Python 字符串是 UTF-8发送前 encode机器人突然掉线NapCat 登录态失效查看 NapCat 容器日志重新扫码登录检查是否有异地登录群消息收不到群被折叠或免打扰检查 NapCat 是否收到该群事件在 NapCat 配置里开启所有群消息接收除了这些常见问题还有几个稳定性优化的点值得单独说。第一个是断线重连。WebSocket 连接不是永久的网络波动、NapCat 重启都会导致断线。我的做法是在机器人主循环里加一个重连机制连接断开后等待 5 秒重试重试次数不限但每次重试间隔递增避免疯狂重连把 NapCat 打挂。代码大概长这样async def connect_with_retry(uri, token): retry_delay 5 while True: try: async with websockets.connect(uri, extra_headers{Authorization: fBearer {token}}) as ws: retry_delay 5 await handle_messages(ws) except Exception as e: print(f连接断开: {e}{retry_delay}秒后重试) await asyncio.sleep(retry_delay) retry_delay min(retry_delay * 2, 60)第二个是消息去重。OneBot 协议在某些情况下会重复推送同一条消息比如网络抖动导致 ACK 丢失。如果不做去重机器人会对同一条消息回复两次显得很傻。我的方案是维护一个最近处理过的 message_id 集合用 LRU 策略只保留最近 1000 条内存占用可控。第三个是 API 超时和降级。DeepSeek API 偶尔会响应慢如果超过 30 秒还没返回用户早就等急了。我设置了两级超时15 秒内没响应就发一条正在思考中的提示30 秒还没结果就放弃本次回复记录日志。这样用户至少知道机器人在处理而不是石沉大海。避坑技巧NapCat 的日志级别默认是 info信息量很大长时间运行日志文件会撑爆磁盘。建议在 Docker 启动参数里加日志轮转配置或者定期清理日志。我见过一个案例服务器磁盘被 NapCat 日志写满导致整个系统崩溃。还有一个容易被忽略的点是资源监控。机器人跑在后台如果内存泄漏或者 CPU 占用飙升不监控的话很难发现。我加了一个简单的定时任务每 5 分钟记录一次进程的 CPU 和内存占用超过阈值就发告警消息到自己的 QQ。这个用 Python 的psutil库就能实现代码量很少但能提前发现很多隐患。5. 进阶玩法与场景扩展基础功能跑通之后可以玩的花样就多了。我陆续加了一些扩展功能这里分享几个实用的方向。第一个是上下文记忆。默认情况下每次调用 DeepSeek 都是独立的机器人不记得之前聊过什么。但在群聊场景里上下文很重要。我的做法是为每个群或每个用户维护一个最近 5 轮对话的缓存调用 API 时把历史消息一起传进去。这样机器人能记住刚才说的那个问题回复更连贯。但要注意 token 消耗会增加需要权衡记忆轮数和成本。第二个是敏感词过滤。QQ 群环境复杂机器人不能什么话都往外说。我在回复发送前加了一层过滤维护一个敏感词列表命中就替换成星号或者直接不发送。这个列表可以动态更新从配置文件读取不用改代码。第三个是定时任务。除了被动回复机器人还可以主动推送。比如每天早上发一条天气提醒或者每周发一次群公告。这个用 Python 的schedule库或者asyncio的定时器都能实现。我加了一个每日新闻推送从公开的新闻 API 拉取摘要让 DeepSeek 改写成适合群聊的语气群友反馈还不错。第四个是多模型切换。DeepSeek 虽然好用但不同场景可能需要不同模型。我在配置里支持了多个模型端点通过命令切换。比如#model deepseek切到 DeepSeek#model local切到本地部署的小模型。本地模型用 Ollama 跑虽然效果差一些但完全免费适合高频简单问答。扩展功能实现难度资源消耗适用场景上下文记忆低中私聊、小群深度对话敏感词过滤低低所有公开群定时推送中低资讯群、通知群多模型切换中高有本地算力的场景图片理解高高需要处理图片消息的群图片理解这个方向我还在折腾。NapCat 能收到图片消息但需要先把图片下载下来再调用支持视觉的模型接口。DeepSeek 目前主要是文本模型图片理解得换其他方案。这块复杂度较高建议先把文本场景做稳再考虑。最后说一个部署上的建议。如果你只是自己用跑在本地 Ubuntu 机器上就行。但如果要给多个群用建议放到云服务器上保证 7x24 小时在线。云服务器选最便宜的轻量款就够关键是网络要稳定。我试过用家里的宽带跑结果路由器重启一次机器人就掉线体验很差。迁到云上之后连续运行一个月没出过问题。这个项目从想法到落地大概花了我两个周末代码量不大但涉及的知识面挺广——协议对接、异步编程、API 调用、运维监控都有涉及。如果你也在 Ubuntu 上用 QQ又想让聊天更省心这套方案值得一试。后续我打算把配置管理做得更友好一些用 Web 界面替代现在的 YAML 文件降低使用门槛。 1. 项目缘起与整体架构拆解QQ 这个国民级聊天工具在 Ubuntu 桌面环境下的使用体验一直是个老大难问题。官方客户端长期停留在 Electron 套壳阶段资源占用高、消息同步慢更别提做自动化了。我平时主力开发机就是 Ubuntu每天挂着 QQ 处理各种群消息和私聊时间一长就萌生了一个想法能不能让机器人帮我自动处理那些重复性高的回复比如常见问题答疑、群规提醒、消息分类归档这个项目的核心目标很明确——在 Ubuntu 上跑一个 QQ 智能回复机器人能自动接收消息、调用大模型生成回复、再把结果发回去。技术选型上消息协议层用 NapCatAI 推理层用 DeepSeek中间用 Python 做胶水逻辑。整套方案跑下来资源占用比想象中低得多一台 2C4G 的轻量服务器就能稳定运行。先说说为什么选 NapCat。QQ 的协议实现方案有好几种NapCat 的优势在于它基于 NTQQ 协议走的是官方客户端同款通信链路稳定性比那些逆向老协议好太多。而且它提供了标准的 OneBot v11 接口这意味着任何支持 OneBot 的框架都能直接对接生态兼容性极强。我实测下来NapCat 在 Ubuntu 上的部署难度很低Docker 一键拉起配置文件清晰日志也够详细出问题好排查。再说 DeepSeek。选它主要看中三点一是 API 价格便宜对于机器人这种高频调用场景成本可控是硬指标二是中文理解能力强QQ 聊天场景里大量口语化表达、网络梗、缩写DeepSeek 的处理效果明显好于同价位其他模型三是响应速度快流式输出延迟低用户等待感不强。当然你也可以换成其他兼容 OpenAI 接口的模型代码层面只需要改 base_url 和 model 名称。整个系统的数据流是这样的QQ 客户端收到消息 → NapCat 通过 OneBot 协议推送到本地 HTTP/WebSocket 服务 → Python 机器人框架接收事件 → 判断是否需要 AI 回复 → 调用 DeepSeek API → 拿到回复内容 → 通过 NapCat 的 send_msg 接口发回 QQ。这条链路里NapCat 负责协议转换Python 负责业务逻辑DeepSeek 负责内容生成各司其职。注意NapCat 的部署方式直接影响后续对接的稳定性。我建议用 Docker 方式部署版本锁定在稳定版不要追最新。配置文件里记得开启反向 WebSocket这样机器人框架可以主动连接 NapCat而不是 NapCat 推送到机器人网络穿透和重连逻辑会简单很多。架构设计上还有一个关键决策消息处理是同步还是异步我选择全异步方案用 Python 的 asyncio 配合 WebSocket 客户端。原因很简单QQ 消息是突发性的群里可能一瞬间涌进来几十条消息同步处理会阻塞异步方案可以并发调用 DeepSeek API响应更快。但异步也带来了新问题——消息顺序可能乱所以我在发送环节加了一个简单的队列保证同一会话的回复按顺序发出。2. 环境准备与 NapCat 部署实操Ubuntu 环境下的准备工作其实不复杂但有几个坑我踩过这里直接给你铺平。首先确认系统版本我用的 Ubuntu 22.04 LTS20.04 也能跑但 18.04 及以下不建议主要是 Docker 和 Python 版本太老依赖装起来费劲。硬件方面2 核 CPU、4G 内存是底线如果群多消息量大建议 4 核 8G。第一步装 Docker 和 Docker Compose。Ubuntu 官方源里的 Docker 版本偏旧我习惯用官方脚本安装curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun sudo systemctl enable docker sudo systemctl start docker装完之后验证一下版本Docker 20.10 以上、Compose v2 以上就够用。这里有个细节如果你的服务器在国内拉取 Docker Hub 镜像可能很慢建议配置镜像加速器。编辑/etc/docker/daemon.json加入加速地址然后重启 Docker 服务。具体加速地址网上很多选一个稳定的就行。接下来部署 NapCat。官方提供了 Docker 镜像直接拉取运行docker run -d \ --name napcat \ --restart always \ -p 3000:3000 \ -p 6099:6099 \ -v /opt/napcat/config:/app/napcat/config \ -v /opt/napcat/data:/app/napcat/data \ mlikiowa/napcat-docker:latest这里解释一下端口映射。3000 是 OneBot 的 HTTP/WebSocket 服务端口6099 是 NapCat 的 WebUI 管理端口。数据卷挂载很重要配置文件和登录态都在里面不挂载的话容器一删就得重新扫码登录。容器跑起来之后打开浏览器访问http://你的服务器IP:6099进入 NapCat 的 WebUI。第一次登录需要扫码用手机 QQ 扫一下就行。登录成功后在 WebUI 里配置 OneBot 服务。我建议开启反向 WebSocket配置如下配置项值说明服务类型反向 WebSocket机器人主动连接 NapCat服务地址ws://127.0.0.1:3001机器人监听的地址Token自定义一串随机字符用于鉴权防止未授权连接消息格式array推荐用数组格式解析更方便提示Token 一定要设置而且不要用简单密码。我见过有人没设 Token结果机器人被外部连接利用疯狂发广告。安全无小事这一步别偷懒。NapCat 配置好之后你可以先用 WebUI 里的测试功能发一条消息给自己确认协议链路通了。如果发不出去检查容器日志docker logs napcat常见问题是登录态失效或者端口冲突。Python 环境方面我建议用 3.10 以上版本直接系统自带或者用 pyenv 管理都行。依赖库主要就几个websockets用于 WebSocket 通信aiohttp用于调用 DeepSeek APIpyyaml用于读配置文件。创建一个虚拟环境把这些装进去python3 -m venv venv source venv/bin/activate pip install websockets aiohttp pyyaml到这里基础环境就齐了。整个准备过程顺利的话半小时内能搞定主要时间花在扫码登录和配置调试上。3. 机器人核心逻辑与 DeepSeek 对接机器人框架的核心其实就三件事收消息、判断、回消息。但要把这三件事做稳细节不少。我先从消息接收说起。NapCat 通过反向 WebSocket 把消息推送到我们监听的端口消息格式是 OneBot v11 标准的 JSON。一条典型的群消息事件长这样{ post_type: message, message_type: group, group_id: 123456789, user_id: 987654321, raw_message: 你好请问怎么配置机器人, message_id: 10001, sender: { nickname: 某用户, card: 群名片 } }我们需要解析这个 JSON提取出关键字段。私聊消息的message_type是private群消息是group。raw_message是纯文本内容如果消息里包含图片、表情等非文本元素raw_message里会有对应的 CQ 码比如[CQ:image,filexxx]。做智能回复的话我建议只处理纯文本消息非文本消息直接跳过或者记录日志不然处理逻辑会复杂很多。判断逻辑是机器人的大脑。我的设计是这样的首先判断消息是否来自允许的群或用户用一个白名单机制避免机器人被拉进陌生群乱说话。然后判断消息是否触发了回复条件我设了三种触发方式——机器人、以特定前缀开头比如#ai、或者私聊直接发消息。最后判断消息内容是否为空或者纯表情这类消息不调用 AI省点 API 费用。DeepSeek 的 API 调用是核心环节。它的接口兼容 OpenAI 格式所以直接用 aiohttp 发 POST 请求就行import aiohttp import json async def call_deepseek(prompt, api_key, base_urlhttps://api.deepseek.com): headers { Authorization: fBearer {api_key}, Content-Type: application/json } payload { model: deepseek-chat, messages: [ {role: system, content: 你是一个QQ群助手回答要简洁友好不超过100字。}, {role: user, content: prompt} ], temperature: 0.7, max_tokens: 200 } async with aiohttp.ClientSession() as session: async with session.post( f{base_url}/v1/chat/completions, headersheaders, jsonpayload, timeoutaiohttp.ClientTimeout(total30) ) as resp: data await resp.json() return data[choices][0][message][content]这段代码里有几个参数值得展开说。temperature控制回复的随机性0.7 是个比较平衡的值太低回复会显得死板太高又容易跑偏。max_tokens限制回复长度QQ 聊天场景不需要长篇大论200 个 token 足够。system提示词很关键我试过不加 system 提示模型会回复得很正式像在写邮件加了简洁友好的约束之后语气自然多了。实操心得DeepSeek 的 API 有速率限制免费额度和付费额度的限制不同。如果你的机器人消息量大建议在代码里加一个简单的令牌桶限流比如每秒最多调用 5 次超出的请求排队等待。不然触发限流会返回 429 错误用户体验很差。消息发送环节调用 NapCat 的send_msg接口async def send_message(ws, msg_type, target_id, content): payload { action: send_msg, params: { message_type: msg_type, user_id: target_id if msg_type private else None, group_id: target_id if msg_type group else None, message: content } } await ws.send(json.dumps(payload))这里有个细节群消息和私聊消息的参数名不同群消息用group_id私聊用user_id。传错参数消息发不出去而且 NapCat 不一定报错只是静默失败排查起来很头疼。我建议在发送之后加一个日志记录把发送内容和目标 ID 都打出来方便对账。整个核心逻辑串起来大概两百行代码不算复杂但每个环节都有坑。比如 WebSocket 断线重连、API 调用超时处理、消息去重防止同一条消息被处理两次这些都需要在代码里做好防护。4. 常见问题排查与稳定性优化机器人跑起来容易跑稳难。我上线第一周遇到了各种问题这里整理成速查表你遇到类似情况可以直接对照排查。问题现象可能原因排查方法解决方案机器人不回复WebSocket 未连接查看机器人日志有无连接成功记录检查 NapCat 反向 WS 配置和 Token回复重复发送消息事件被处理两次日志里看同一 message_id 是否出现两次加消息 ID 去重集合处理过的 ID 不再处理API 返回 401DeepSeek Key 无效或过期用 curl 直接测试 API重新生成 Key检查是否有多余空格回复内容乱码编码问题检查发送时的 content 编码确保 Python 字符串是 UTF-8发送前 encode机器人突然掉线NapCat 登录态失效查看 NapCat 容器日志重新扫码登录检查是否有异地登录群消息收不到群被折叠或免打扰检查 NapCat 是否收到该群事件在 NapCat 配置里开启所有群消息接收除了这些常见问题还有几个稳定性优化的点值得单独说。第一个是断线重连。WebSocket 连接不是永久的网络波动、NapCat 重启都会导致断线。我的做法是在机器人主循环里加一个重连机制连接断开后等待 5 秒重试重试次数不限但每次重试间隔递增避免疯狂重连把 NapCat 打挂。代码大概长这样async def connect_with_retry(uri, token): retry_delay 5 while True: try: async with websockets.connect(uri, extra_headers{Authorization: fBearer {token}}) as ws: retry_delay 5 await handle_messages(ws) except Exception as e: print(f连接断开: {e}{retry_delay}秒后重试) await asyncio.sleep(retry_delay) retry_delay min(retry_delay * 2, 60)第二个是消息去重。OneBot 协议在某些情况下会重复推送同一条消息比如网络抖动导致 ACK 丢失。如果不做去重机器人会对同一条消息回复两次显得很傻。我的方案是维护一个最近处理过的 message_id 集合用 LRU 策略只保留最近 1000 条内存占用可控。第三个是 API 超时和降级。DeepSeek API 偶尔会响应慢如果超过 30 秒还没返回用户早就等急了。我设置了两级超时15 秒内没响应就发一条正在思考中的提示30 秒还没结果就放弃本次回复记录日志。这样用户至少知道机器人在处理而不是石沉大海。避坑技巧NapCat 的日志级别默认是 info信息量很大长时间运行日志文件会撑爆磁盘。建议在 Docker 启动参数里加日志轮转配置或者定期清理日志。我见过一个案例服务器磁盘被 NapCat 日志写满导致整个系统崩溃。还有一个容易被忽略的点是资源监控。机器人跑在后台如果内存泄漏或者 CPU 占用飙升不监控的话很难发现。我加了一个简单的定时任务每 5 分钟记录一次进程的 CPU 和内存占用超过阈值就发告警消息到自己的 QQ。这个用 Python 的psutil库就能实现代码量很少但能提前发现很多隐患。5. 进阶玩法与场景扩展基础功能跑通之后可以玩的花样就多了。我陆续加了一些扩展功能这里分享几个实用的方向。第一个是上下文记忆。默认情况下每次调用 DeepSeek 都是独立的机器人不记得之前聊过什么。但在群聊场景里上下文很重要。我的做法是为每个群或每个用户维护一个最近 5 轮对话的缓存调用 API 时把历史消息一起传进去。这样机器人能记住刚才说的那个问题回复更连贯。但要注意 token 消耗会增加需要权衡记忆轮数和成本。第二个是敏感词过滤。QQ 群环境复杂机器人不能什么话都往外说。我在回复发送前加了一层过滤维护一个敏感词列表命中就替换成星号或者直接不发送。这个列表可以动态更新从配置文件读取不用改代码。第三个是定时任务。除了被动回复机器人还可以主动推送。比如每天早上发一条天气提醒或者每周发一次群公告。这个用 Python 的schedule库或者asyncio的定时器都能实现。我加了一个每日新闻推送从公开的新闻 API 拉取摘要让 DeepSeek 改写成适合群聊的语气群友反馈还不错。第四个是多模型切换。DeepSeek 虽然好用但不同场景可能需要不同模型。我在配置里支持了多个模型端点通过命令切换。比如#model deepseek切到 DeepSeek#model local切到本地部署的小模型。本地模型用 Ollama 跑虽然效果差一些但完全免费适合高频简单问答。扩展功能实现难度资源消耗适用场景上下文记忆低中私聊、小群深度对话敏感词过滤低低所有公开群定时推送中低资讯群、通知群多模型切换中高有本地算力的场景图片理解高高需要处理图片消息的群图片理解这个方向我还在折腾。NapCat 能收到图片消息但需要先把图片下载下来再调用支持视觉的模型接口。DeepSeek 目前主要是文本模型图片理解得换其他方案。这块复杂度较高建议先把文本场景做稳再考虑。最后说一个部署上的建议。如果你只是自己用跑在本地 Ubuntu 机器上就行。但如果要给多个群用建议放到云服务器上保证 7x24 小时在线。云服务器选最便宜的轻量款就够关键是网络要稳定。我试过用家里的宽带跑结果路由器重启一次机器人就掉线体验很差。迁到云上之后连续运行一个月没出过问题。这个项目从想法到落地大概花了我两个周末代码量不大但涉及的知识面挺广——协议对接、异步编程、API 调用、运维监控都有涉及。如果你也在 Ubuntu 上用 QQ又想让聊天更省心这套方案值得一试。后续我打算把配置管理做得更友好一些用 Web 界面替代现在的 YAML 文件降低使用门槛。