现在的 QQ 和微信 Bot，还能优雅地跑起来吗？ • 雪泥工坊

如果只看理想状态，QQ 和微信 Bot 应该是一件很舒服的事：接入一个统一框架，写一套插件，消息从各个平台进来，模型、记忆、工具调用在后面安安静静工作。用户发一句话，Bot 回一句靠谱的话，世界从此清爽。

但现实通常不会这么懂事。

这次折腾下来，阶段性结论很明确：QQ 端继续走 NoneBot ↗ + Lucky Lillia Bot / LLBot ↗；微信端先使用 Claw / WxClaw 这一条路，能快速跑起来，但要承认它只是一个临时解法。至于 Wechaty ↗，它仍然值得后续尝试，不过这次没有完成免费可用方案的验证，所以暂时不把它作为当前主线。

一句话总结：QQ 端是“能做成工程”，微信端目前更像“先找个能过河的木板”。木板能用，但只是能用。来给大伙看看现在所谓的开放，实际上是啥玩意吧，丑丑的下等公民 alt text

QQ 端：NoneBot + LLBot 是当前更稳的选择#

QQ 端这次采用的是 NoneBot 2 + OneBot V11 + LLBot 的组合。

这个组合的优点不在于它看起来多么华丽，而在于它很工程化。NoneBot 负责插件系统、事件分发、运行时管理；OneBot 适配器 ↗负责把平台消息转换成相对统一的协议事件；LLBot 则承担 QQ 协议侧接入工作。每一层职责都比较清楚，出了问题也更容易定位。

对于一个需要长期维护的 Bot，这种分层很重要。Bot 项目一旦开始长功能，最怕所有逻辑混在一起：平台协议、消息解析、LLM 调用、记忆、权限、日志全部揉成一团。刚开始看着“就一个文件，简单”，过几天就会变成“谁碰谁沉默”。

当前 QQ 端的实际路线是：

QQ
  -> LLBot
  -> OneBot V11 reverse WebSocket
  -> NoneBot
  -> 本地插件 / LLM / 记忆 / 工具调用

text

LLBot 的价值主要在于部署体验和协议兼容。它提供桌面版、CLI、Docker 等多种形态，支持 OneBot 11、Milky、Satori 等协议；对我们这个项目来说，最关键的是可以稳定对接 NoneBot 生态，并且本地调试路径比较短。

所以，QQ 端现在不需要太花哨。先把消息链路跑稳，把插件结构留干净，把后端能力抽象好，比追求“一次接入全平台”更现实。

Claw 的 QQ 版本：能用，但不是这个项目的主菜#

Claw / OpenClaw 这一类方案最近确实很吸引人，尤其是 ClawBot Wiki ↗ 里已经能看到 QQ、微信等不同通道的适配信息。QClaw ↗ 这类方案主打的是把聊天入口接到本地 AI 助手，让用户通过熟悉的 IM 工具遥控自己的 Agent。

这个方向很有意思，但它和我们现在要做的 Bot 不完全是一类东西。

我们现在更需要的是一个“可以长期扩展的平台 Bot”：能承载插件、权限、状态、记忆、群聊或私聊策略，后续还要接更多业务逻辑。而当前放出来的一些 Claw 版本，更偏向“用户自己和自己的 AI 助手对话”。这对个人效率工具很顺手，但对一个完整 Bot 来说，功能边界就显得太窄。

尤其是只能和自己对话这一点，直接决定了它不太适合作为 QQ 端主方案。Bot 要是只能陪自己聊天，听起来很赛博，也很孤独。

因此 QQ 端的取舍很清楚：Claw 可以观察，但当前主线仍然是 NoneBot + LLBot。

微信端：难点不是写代码，而是入口#

微信端的问题比 QQ 端更现实。

从框架层面看，Wechaty ↗ 仍然是一个很成熟、很有代表性的聊天机器人 SDK。它的设计思路也很清晰：上层写 Bot 逻辑，下层通过不同 puppet 接入具体平台。理论上这很优雅，工程师看了会点头，架构图画出来也很顺。

但真正卡住的地方往往不在 SDK，而在“现在有没有一个免费、稳定、可测试、风险可控的微信接入通道”。这次没有完成 Wechaty 免费方案的验证，也没有把它接进当前项目。这里不能硬写“已经可用”，否则博客是写爽了，项目运行时会当场拆台。

所以当前微信端先使用 Claw / WxClaw。项目里对应的是 nonebot-adapter-wxclaw，通过 WXCLAW_ACCOUNTS 配置账号信息，再让 NoneBot 注册 WxClaw Adapter。它的优势非常直接：接入快、代码少、路径短。

当前微信端路线大致是：

WeChat
  -> WxClaw / ClawBot
  -> NoneBot Adapter
  -> 本地插件 / LLM / 记忆 / 工具调用

text

这个方案的定位也要说清楚：它是当前阶段的临时解法，不是最终答案。

Claw 方案更像“把微信变成一个私人 Agent 入口”。如果目标只是自己在微信里唤起本地助手，它很方便；但如果目标是完整的微信 Bot 能力，比如更丰富的消息场景、更自然的联系人交互、更完整的自动化能力，那它目前确实不够。功能被阉割之后，体验就会从“我有一个 Bot”变成“我有一个能聊天的遥控器”。遥控器不是不好，只是别拿它当操作系统。

为什么微信端仍然先用 Claw？#

原因很简单：项目需要先跑起来。

工程上很多选择不是“最好”和“最差”的二选一，而是“当前能稳定推进”和“理论上更漂亮但还没验证”的取舍。微信端如果现在强行押 Wechaty，就必须先解决 puppet、登录、稳定性、风控、部署成本这些问题。每一个都不是不能做，但都会把主线拖进不确定性里。

而 Claw / WxClaw 的好处是可以快速建立一条可用链路。它不完美，但它能让我们先验证后端能力：消息能不能进来，NoneBot 插件能不能复用，LLM 记忆是否合理，工具调用是否可控。这些才是 Bot 的核心资产。

换句话说，微信端现在用 Claw，不是因为它是最优解，而是因为它是当前最省心的可运行解。这是无奈之举，但不是乱来。

当前架构上要坚持的几条原则#

第一，平台适配和业务逻辑要分开。

QQ 用 LLBot，微信用 WxClaw，后续可能再试 Wechaty。平台通道一定会变，协议也一定会变。如果核心对话、记忆、权限、工具调用都绑定在某一个平台适配器上，后面每换一次入口都像搬家。

第二，能力要按平台降级。

不要假设 QQ 和微信支持同样的事件、同样的消息类型、同样的联系人模型。统一入口可以做，但统一能力要谨慎。比较靠谱的做法是定义一层内部消息模型，然后给每个平台标记能力边界：能收什么、能发什么、能不能群聊、能不能识别发送者、能不能拿到上下文。

第三，先跑通最小闭环。

对这个阶段来说，最小闭环不是“支持所有平台”，而是：

QQ 端能稳定收发消息；
微信端能通过 Claw 跑通个人入口；
LLM 能被统一调用；
记忆和插件不依赖具体平台；
后续替换 Wechaty 或其他微信通道时，业务层少改代码。

这几个点跑稳了，项目才是真的在变强。否则只是接入方式看起来很多，实际每条路都虚。

后续计划：Wechaty 仍然值得再试#

微信端后续还是要回头看 Wechaty。

不是因为它名字老，也不是因为它生态有情怀，而是因为它的抽象方向更接近“真正的聊天机器人框架”。如果能找到稳定、成本可接受、风险可控的 puppet 方案，Wechaty 仍然可能比 Claw 更适合作为长期微信入口。

但在这之前，当前项目不应该为了追求架构上的完美而停摆。先用 WxClaw 把微信端挂上，承认它的限制，把核心能力沉到平台无关层，后面再替换入口，这是更务实的路线。

结论#

这次 QQ 和微信 Bot 的阶段性结论可以很简单：

QQ 端：使用 NoneBot + Lucky Lillia Bot，主打稳定、可扩展、工程化；
微信端：暂时使用 Claw / WxClaw，主打快速接入，但接受功能受限；
Wechaty：这次没有验证免费可用方案，后续再作为重点尝试；
Claw：适合作为个人 Agent 入口，但目前不适合作为完整 Bot 主方案；
核心策略：平台通道可以临时，业务能力必须长期。

所以现在不是“QQ 和微信 Bot 已经优雅解决了”，而是“QQ 端比较像工程，微信端先像补丁”。这听起来不够浪漫，但很真实。

而真实，通常是项目能活下去的第一步。对了还有一个新问题为啥deepseek要假装自己不是deepseek，我也没写什么奇奇怪怪的prompt？真是奇怪 alt text