架构一览：一条消息从聊天软件到大模型的完整链路

理解架构不看代码，看一条消息的旅程就够了。假设有人在 QQ 群里 @ 了机器人一句「今天天气怎么样」，这句话要穿过下面这几层。

第一站：消息平台适配层

QQ 的消息先被协议实现端（如 NapCat）或平台官方 API 接住，转交给对应的消息平台适配器。适配器负责把各家格式不一的消息统一注册进系统。这层解释了为什么同一个机器人能同时挂在十几个平台上——每个平台只是多注册一个适配器实例。

适配器把消息上报到 Event Bus（事件总线），由事件流水线层消费。这是整个系统的调度中枢：所有消息、所有平台，都汇入这一条总线再分发。

事件流水线由多个阶段串联组成（架构图里的「流水线阶段 1, 2, 3…」）：唤醒检测、权限校验、人格注入、上下文组装等处理都发生在这一段。你的各类配置——唤醒词、访问控制、自定义规则——实际上都是在改这条流水线的行为。

流水线走到大模型调用这一步，服务商适配器出场。OpenAI、Gemini、Anthropic 等格式各有适配器，请求被翻译成对应 API 格式发出去，回复再翻译回来。

插件在流水线各处挂载自己的处理逻辑：注册指令、监听消息、提供工具。知识库插件、长期记忆插件、代码执行器插件都属于这一层。插件和服务商适配层、上下文之间是双向调用关系。

这条链路记住一个结论就够用：消息平台决定消息从哪来，流水线决定怎么处理，服务商决定交给哪个模型，插件决定额外做什么。后面排查「机器人不回话」之类的问题时，就是沿着这条链路逐段检查。