从零简单拆解 QQ AI 机器人架构（纯原理向）

概要

最近 QQ 机器人（接入大模型）的浪潮挺火，在网上你能看到很多人晒出自家大肥鱼在 QQ 群里发了啥，甚至于在视频网站上做了啥。此时的你想到：“难不成，这是《一夜后，全世界精通 AI 技术而我不变》的展开？”

实际上也不可能如此，对外行人来说，只要他们想，只靠整合包也能一键跑起来。我对此好奇的点不在于整合包是啥、哪来的，而是它的底层通信链路到底是怎么设计的。

这篇博客不写实操教程，单挑它的底层通信架构，盘一下 WebSocket 长连接、OneBot 协议、以及应用端框架之间的关系，顺便解开一个我之前的迷思：为什么它们非要把连接和数据格式拆成两半？（至于啥是 WebSocket，啥是 OneBot，你先别急，会解释的）

整体架构流程

整个链路的逻辑其实就像个分工明确的餐厅（或快递站）：

用户在 QQ 里发消息 ➡️ 协议端（如 NapCat）接收并转换 ➡️ 通过 WebSocket 专线 ➡️ 应用端（如 AstrBot）接收并解析 ➡️ 调用 大模型 API / 工具（MCP） ➡️ 原路返回，输出给用户。

技术名词解释

• 协议端（如 NapCat / LLOneBot）：24 小时挂机的“收发室大爷”。负责跟腾讯的服务器通信，挂你的 QQ 号，收发消息。
• 应用端（如 AstrBot / NoneBot2）：发号施令的“AI 大脑”。你写代码、设置提示词、接大模型都在这里。
• WebSocket：打通收发室和大脑的“专线电话”。它保证这条电话线一直通着，随时能互相传话（长连接）。
• OneBot 协议：电话接通后，双方必须说的“普通话黑话”。它规定了传过来的数据长什么样（通常是一串 JSON）。
• MCP（Model Context Protocol）：给 AI 大脑加装的“USB 接口”。让 AI 能调用工具去搜 B站、查天气等。

上面这些，如果你只是单纯看个表层逻辑，那很够了；但如果你懂一些网络通讯，了解数据是怎么流通的（比如访问一个网站），你肯定会有些疑问。接下来我会讲出我在学习时遇到的疑问。

技术细节

1. 核心顿悟：为什么要把“铺路”和“运货”分开？（解耦）

插播一个名词解释：什么是“解耦”？
在软件工程里，耦合指的是各个模块之间互相依赖的程度。解耦，就是降低它们之间的依赖，让“各管一摊，互不干涉”。
打个比方，如果一辆汽车的油门踏板和发动机焊死在一起，想换个发动机，整个车都得拆了重造；但如果中间用了一根标准的线缆连接，发动机坏了，直接拔掉线换一个就行。这就是解耦带来的灵活性。把网络连接和数据格式拆开，就是为了实现这种“随时能换零件”的效果。

最初，我是把 NapCat 和 AstrBot 理解成俩个软件：AstrBot 接入你的模型，NapCat 中有个连接方法能让它和 AstrBot 一直连接着。毕竟这个软件上得挂着 QQ 号，而你的 model 从 AstrBot 想要使用账号，就得一直有个稳定访问的通道。

后来了解到，NapCat 用的这个方法叫 WebSocket。但我一问 AI，发现 AstrBot 里怎么还有个 OneBot 协议？这一问我不得劲了，咋还冒出两个“类 HTTP 协议”产物呢？

然后我便从最基础的网络架构开始分析。从五层协议来看，这俩东西都属于应用层。那么我们回忆一下 HTTP 协议（因为 HTTP 也在应用层），它是一种短连接，同时能规定数据格式。而在这里，我们也要一个等效于 HTTP 的、既能建立连接又能规定数据格式的东西。但是实际上，这俩功能在实现 model + QQ 机器人上被分开了：WebSocket 建立连接，而 OneBot 协议规定数据格式。

至于为什么嘛，个人理解是为了保持架构灵活。如果让 WebSocket 既管“长连接”又管“数据格式”，那就成了一个死局。明天你想换个协议端（把 NapCat 换了，换一个不是使用 WebSocket 的“软件”），即便它的连接方法（平替 WebSocket）能与应用端兼容，只要它用的数据格式变了（比如没用 OneBot 格式），你的应用端（AstrBot）就无法顺利解析。所以如果这俩绑定，你想换协议端，还得专门去找既有与应用端兼容的连接方法、又有相应数据格式的协议端，实在麻烦。

所以必须拆开：WebSocket 只负责铺路（维持不断开的长连接），OneBot 只负责运货（规定 JSON 格式）。只要大家都认 OneBot 这门普通话，不管换谁来接电话（换协议端），大脑都能继续聊下去。架构保证灵活。

2. 谁才是核心？铁打的营盘流水的兵

顺着解耦的逻辑往下想，WebSocket 是可以平替的（比如以后可能有更省资源的连接方式），OneBot 协议也是可以平替的（比如 Satori 协议）。

在这个浪潮里，最核心不变的永远是应用端（大脑）。协议端只是消耗品。

就拿 NapCat 来说，它本质上是基于 QQ NT 架构（就是你现在电脑上用的那个新版 QQ）搞出来的一个“无头客户端”。它的唯一使命，就是帮你把 QQ 挂上去，然后监听群消息。如果哪天你要搞微信机器人，NapCat 就直接下岗了，你得去换一个专门针对微信的协议端（比如 Wechaty）。

只要你的应用端里存着你写的 AI 人格、接好的大模型和 MCP 工具，哪怕明天你不做 QQ 机器人了，去做微信、钉钉机器人，换个协议端，大脑依然能无缝平移。

而且应用端生态不止 AstrBot 一家，有硬核的 NoneBot2，有前端界面极其好看的 Koishi。大家只要能读懂同一个协议，就能指挥不同的兵。

3. 完整链路的数据包“一生”

以让 AI 去 B站 搜个视频为例，这中间网络通信的逻辑极其严密：
用户发出请求，应用端把用户的提问、加上设置好的 System Prompt 打包，发给大模型。大模型一看，决定调用工具。工具跑完把结果还给大模型，大模型总结后，再把话交回给应用端。最后通过 OneBot 协议包装，顺着 WebSocket 专线丢给协议端，协议端再发到 QQ 群里。在这个过程中，应用层负责格式，传输层（TCP）负责保证数据包不丢。

如果上面没看懂，那看看这个：

NapCat 只负责把消息从 QQ 服务器拉下来，传递给 AstrBot；AstrBot 把消息交给 Model 生成回复。然后，这个回复再以同样的方式——通过 OneBot 协议打包，走 WebSocket 建立的长通道，原路扔回给 NapCat，最后由 NapCat 发到 QQ 群里。

在这个架构里：
NapCat 负责物理输出；
WebSocket 负责一直通着电话；
OneBot 负责大家说同一种语言；
AstrBot 负责指挥交通；
Model 负责提供智力；
MCP 负责给 AI 长手长脚。

小结

很早以前学计算机网络的时候，总觉得网络层、传输层、应用层这些概念很抽象。怎么说呢，你啥不懂的情况下，老师上来给你整一套这个雷霆通讯协议的发展史，然后跟你讲啥啥啥的几层协议的更迭，最终确定在官方七层协议。你认真记笔记，准备记住每层的作用，但没个实例，记住并理解基本天方夜谭哦。

最后你硬记了这个七层协议（其实原理还是不懂），然后老师跟你说，这个七层协议啊基本上理论存在，我们实际都用五层协议的哈哈哈。

那我还能说啥，你都这样整了，我给你了呗。
bro belike：

好了，玩笑到此为止。

通过研究 QQ 机器人的架构，这些底层的分层逻辑全活了。
软件架构的“解耦”设计，就是为了让系统变得足够灵活、有扩展性。理清了这个链路，计算机各行各业的师傅，无论是玩机器人，还是搭 Agent 都会得心应手；如果跟我一样搞安全的，对于以后搞网安内网渗透、理解各种协议代理，也是极其重要的底子。