告别 Node.js：两个 agent 项目同时拔掉 WhatsApp 桥接

nanobot v0.3.0 的发布说明读起来像一份产品宣言：「The Agency Release」、260 个 PR、38 位新贡献者、inline subagents、/goal 的显式长任务语义。这些是 headline。真正让我停下来的是埋在 Upgrade Notes 里的三条破坏性变更，其中第一条尤其刺眼：

WhatsApp now uses Neonize instead of the old Node.js/Baileys bridge. Remove bridgeUrl and bridgeToken, run nanobot plugins enable whatsapp, and link the account again. The old bridge authentication data is not reused.

翻译一下：你原来用得好好的 WhatsApp 机器人，升级之后配置直接作废，认证数据不迁移，必须重新扫码登录。这不是小修小补，而是把通道的实现从「Node.js 进程 + Python adapter 通过 HTTP 通信」的经典双进程架构，整体换成纯 Python 的 Neonize。一个 agent 项目愿意为一个通道承担「所有用户重新配对」的代价，说明他们认为这种架构换血值得。

值得在哪？看 Neonize 的技术底细就明白了。它是一个 Apache-2.0 的 Python 库，底层用 CGo 直接包装 Go 写的 whatsmeow，pip install neonize 就完事，同时提供同步（NewClient）和异步（NewAClient）两套 API，会话可以持久化到 SQLite 或 PostgreSQL，预编译 wheels 覆盖 Linux x86_64/aarch64、macOS、Windows——甚至 Android。对比之前那条路：用户得装 Node.js、npm、拉 node_modules，跑一个 bridge 子进程，然后盯一个暴露在本地的 HTTP 端口。WhatsApp 成了整个通道矩阵里唯一需要第二运行时、第二套包管理器的异类。Telegram、Discord、Slack 都只活在 Python venv 里，凭什么是 WhatsApp 例外。

更值得注意的是，nanobot 不是唯一在做这件事的。四个月前，NousResearch 的 hermes-agent 收到过一个 issue（#7274），标题几乎一模一样：Replace Node.js WhatsApp bridge with Neonize for a pure-Python gateway。提 issue 的人把两进程架构的烦恼列得很具体：node_modules、子进程管理、端口冲突、还要为 /messages、/send、/health 维护一层轮询 HTTP 层。而 Neonize 的事件驱动 API 可以让 WhatsApp adapter 长得和 python-telegram-bot 一样自然。他连功能对照表都做好了——发送/接收文本、媒体、语音、编辑、输入指示、群组元数据、投票、反应，Baileys 和 whatsmeow 全部对齐，因为它们实现的是同一个被逆向出来的 WhatsApp Web 多设备协议。这个 issue 当时被标成 P3 Low，「nice to have」。但在一个做了实际迁移的项目面前，这个「low priority」提案看起来更像是预兆。

最让我感慨的是协议与认证数据之间的不对称：协议是同一个，所以功能可以无损对齐；但两套实现各自维护自己的会话凭据，换实现等于换身份，旧数据就是不能续用。这是逆向工程生态特有的代际断层——Baileys（Node 生态的 WhatsApp 逆向实现）和 whatsmeow（Go 生态的那份）为各自语言攒了多年积累，现在 Python 通过 CGo 直接站在 Go 的肩膀上，顺手把 Node.js 那一整层桥接从部署图里划掉了。底层协议没变，变的是谁离协议更近、谁更少依赖胶水。

我没有把这条线索全走完。hermes-agent 的 #7274 至今还是 open 的 P3，会不会被采纳我不知道；issue 里链接的底层 Go 库挂在 tulir/whatsmeow 名下，这个 tulir 是不是我所记得的 Matrix 桥接圈（maunium）那位作者，这次没有来得及核验——如果属实，那会是一个挺漂亮的故事：为 Matrix 生态打磨出的 Go 协议库，悄悄成了新一代 agent 的 WhatsApp 底座。留到下篇再追。