夜雨聆风
你手里有个 AI 小助手——可能是个能自己干活的 Agent（会自动调工具、分步骤办事的 AI），也可能就是个调大模型的小脚本。它在你电脑的命令行里跑得好好的，但你想让它走出命令行——能在微信、飞书、Telegram 里，像跟人聊天一样直接对话。
于是你打开搜索框，输入「AI 怎么接微信」「Agent 接飞书」，翻了一圈，没找到那个装上就能用的现成工具。
你以为是自己姿势不对。
不是。那种现成工具根本不存在。
我最近把一个开源项目 Hermes 的源码翻了个底朝天——它的聊天入口目录下躺着 19 个文件，对应 19 个平台。翻完我确认了一件事：跨平台接 bot 这件事没有银弹——至少做自建 bot，绕来绕去都会落到同一套笨结构上。这篇就把这套结构，和国内两个最容易踩的坑，一次说清。
你要找的那种现成工具，不存在
先说结论：没有任何一个现成框架，能让你的 AI 一键接入所有聊天平台。这是个特别普遍的误会。
多数自建跨平台 bot，绕来绕去都会落到同一套结构，工程上叫适配器模式（说人话就是「一个平台写一个转接头」）。每个平台一个转接头，转接头里干三件事：调这个平台的官方工具包（没有官方的，就自己拼一个）、处理它的登录鉴权、把它的消息格式翻译成你内部统一的格式。最后那件事，就是后面会反复提到的归一化层——把各平台五花八门的消息，统一翻译成你内部只认的同一种格式。
Hermes 那 19 个文件，就是 19 个这样的转接头。
你那个 AI 的「大脑」（理解消息、想出回复的那部分），在这套架构里只负责中间那一段。消息怎么进来、回复怎么发回去，它管不着，得你自己接。所以「给 AI 接微信」更准确的说法是：AI 负责想内容，进出的门你得自己装。
说清楚点：不存在的，是那种装上就能通吃所有平台的「万能工具」。各平台自己的官方工具包当然有——你要做的不是去找一个不存在的「万能轮子」，而是「给第一个平台装上转接头」。
「微信」不是一个微信
如果你的第一个平台是微信，先停一下。国内做 bot 最大的坑，是「微信」根本不是一个东西。
你跟老板说「咱接个微信机器人吧」，老板脑子里是公众号粉丝自动回复，你以为是在群里拉个机器人陪聊，隔壁同事以为是企业内部的办公助手——三个人说的是三个完全不同的微信，配置互相不通用。
| 你说的微信 | 到底是 | 有官方接口吗 | 给谁用 |
|---|---|---|---|
| 企业微信 | 公司内部办公 IM | 有，完整 | 公司员工 |
| 微信公众号 | 面向粉丝的服务号 | 有，但限制多 | C 端用户 |
| 个人微信 | 你天天用的那个 | 完全没有 | 你的好友 |
这三个里，企业微信最接近飞书，适合做公司内部的办公助手；在国内微信生态里，公众号服务号是面向 C 端用户的官方正路，但它有个绕不过去的政策限制——只能在用户主动给你发消息后的 48 小时内回复。超过这个窗口，你想主动推一句都不行，只能走模板消息（每月配额有限）或订阅消息（用户授权后也只能发一次）。这不是技术难题，是规则画的线，做 C 端 bot 之前必须想清楚。
至于个人微信，单独拎出来说。
个人微信：唯一的建议是别碰
你大概率最想要的，其实是个人微信——毕竟那才是你和朋友每天聊天的地方。
但微信官方没有开放任何个人号接口。市面上那些「能接个人微信」的方案，全是灰色地带：
早年的 itchat，早就停更了wechaty这类走网页版协议的，封号风险很现实还有些付费的协议方案，同样游走在灰色边缘
说实话，我把话撂这儿：别把任何正经业务接到个人微信上。 它要封号几乎没有商量余地，封一次，你跑在上面的东西全停。省下来纠结它的时间，去把一个有官方支持的平台跑通，回报高得多。
一个飞书机器人，真要 4801 行吗
回到那个 AI 助手。假设你想让它先进公司飞书——好选择。至少在 Python 接入这件事上，飞书比企业微信省心得多：飞书有官方维护的工具包 lark_oapi，而企业微信连个统一的官方 SDK 都没有，基本靠社区自己拼（Hermes 那个 1607 行的企微转接头，就是自己撸的 WebSocket 加解密）。
但你扒 Hermes 源码会被吓一跳：它那个飞书转接头，4801 行。
先别慌。我把 Hermes 几个主要平台的代码量摆成一张计分板：
基类（公共契约） 3382 行
飞书 4801 行
Telegram 3663 行
Slack 2926 行
企业微信 1607 行
飞书那 4801 行，不是因为飞书难，而是 Hermes 把所有消息类型——文本、卡片、富文本、图文、语音、视频、文件、@提醒、表情、回复链——全做了双向翻译。你做飞书 bot，根本不需要 4801 行。 只支持「收文本、回文本和卡片」，500 行左右就能跑起来（这个数是照着 Hermes 的飞书转接头结构估的）。
注意上面那张表数的是全功能转接头，不是起步量。各平台真正的起步门槛，是另一张账：
Telegram / Discord 100–200 行 拿到 token 就能跑
Slack 100–200 行 登录配置稍繁
飞书 500 行起 回调验证要磨合一两天
企业微信 1000 行起 没官方 SDK，自己撸
公众号 300–500 行 还得扛 48 小时窗口
看出来了吗？Telegram、Slack、Discord 是一档——文档全、接口干净、免费，一两百行就有个能聊天的 demo。飞书、企业微信、公众号是另一档——加密、平台审核、政策限制，代码量更大，第一次接还要花一两天跟回调配置死磕。
光飞书第一步的「回调验证」就够卡人：它首次配置时会发来一个 challenge 字符串，你得原样把它回吐回去才算验证通过，不少人第一天就栽在这一下。（一个省事的选择：开发期用「长连接」——你的程序主动去连飞书，不用公网域名；等真上线再换成飞书回调你服务器的 Webhook 模式。）
所以如果你只是想先玩起来、用最少的代码验证你那个 AI 助手好不好用，Telegram 写起来最省事——拿到 token（机器人的登录密钥），百来行代码就能聊上。
但有个前提得先说清楚：Telegram 在国内直接访问不了，你得有稳定的科学上网，或者把程序跑在海外服务器上。要是没这条件、又不想折腾梯子，那就别跟它较劲，直接上飞书——国内能直连，官方工具包也省心。
而且飞书在这件事上还藏了张王牌：它官方出了个命令行工具（lark-cli，飞书开放平台官方维护），用户发来的消息能实时收，回复一条命令就发出去，连前面那个最劝退的「回调验证」都替你包好了——你甚至不用自己写那几百行。论对 AI 接入的友好程度，这是国内几个平台里最省事的一个。没梯子的人，飞书几乎是默认最优解。
别学 Hermes，一上来就做 19 个
最后这条，是我翻完源码最大的感触。
Hermes 那 19 个平台，是它的历史包袱，不是你的起点。你看着它支持 19 个平台很气派，于是也想搭个「全平台通吃」的架子——这是很容易掉进去的坑：还没跑通一个，先为想象中的「跨平台」过度设计。
真实的成本曲线是这样的：
第一个转接头：所有时间都花在「学这个平台的工具包 + 调通登录鉴权」上，最磨人。 第二个转接头：归一化层能复用，工作量大概掉到三成——但也正是这时候你才发现，第一个平台定的那套内部格式，多半得改。 做到第三个：被两个平台反复捶打过的格式才算稳，「跨平台」这事到这儿才真正立住。
这串数字是 Hermes 这类项目的经验值，不是铁律——具体降多少，看你接的两个平台差多少。但方向是稳的：归一化层往往是被第二个平台逼出来的，而不是第一天就能拍板设计好的。
一上来就做 19 个，等于把第一个坑连踩 19 遍，毫无意义。
什么时候才该考虑 Hermes 这种重型方案？一个大致的分界是：你手上已经同时压着 5 个以上平台的硬需求。在那之前，自己装转接头，多半比改一个 19 平台的庞然大物省事——毕竟光读懂它那 19 个转接头共用的底层契约，就够你喝一壶。
现在，去装第一个转接头
把这篇收个尾，给你一条今晚就能动手的路径：
挑第一个平台，按你的网络条件二选一： 有稳定科学上网 → 选 Telegram，代码最少：搜官方的 BotFather（Telegram 的「机器人管家」账号），跟它对话就能领到一个 token（机器人的登录密钥，务必保密），免费、不用域名备案。 没梯子、不想折腾 → 选 飞书：国内直连，用官方工具包 lark_oapi，把前面说的「回调验证」过一遍，今晚一样能跑通一个能对话的 bot。
先写死一条链路：收到文本 → 丢给你的 AI 助手 → 把回复发回去。先别急着抽什么统一格式，让这一个平台先跑通。 想清楚「哪个微信」再碰国内平台：公司内部用企业微信或飞书，面向 C 端用公众号服务号，个人微信直接划掉。 跑通第一个，再加第二个时，归一化层该长什么样会自己浮现出来——到那时再抽象，比现在拍脑袋定强得多。
到这一步，你的 AI 助手已经能在聊天软件里收发消息了。但你很快会撞上两个新问题：Telegram 来的消息和飞书来的消息，格式天差地别，业务逻辑怎么共用一套？多平台的对话记忆，又该存在哪、怎么不串台？
这正是那个「归一化层」真正开始干活的地方——下一篇，我们就拆它。
