去年帮一个客户做 AI 落地，飞书、企微、钉钉、WhatsApp 一锅端，IT 那边一开始是按平台分别接的。结果三个月后问题全冒出来：离职员工关账号要在四个后台各点一遍；客户问"昨天 AI 回了什么"，回答"不知道，因为是企微 AI"；最离谱的一次，销售总监用企微问了一个合同条款，AI 给的答案是过期的——因为知识库没更新，而 IT 同学更新的是飞书那份。
这事让我意识到：多 IM 平台的 AI 助手，如果只接不通，坑比不接还大。
这一条最基础，但也最容易踩坑。很多所谓的"统一 AI 助手"做法是：把三个聊天窗口拼到一个页面上，账号还是各管各的。这种不叫统一，叫换皮。
真正能用的统一是：Mule 用户 → IM 账号（1:N）。一个员工离职，关一个 Mule 账号，所有 IM 平台的 AI 自动失效。这件事说起来简单，做起来涉及 IM 平台的开放能力限制，得一个个对接。
很多方案的"统一知识库"实际上是个备份机制——每个 AI 各查各的，再加个同步任务。这会导致"知识漂移"：你在飞书 AI 看到的答案和企微 AI 给的不一样，最后谁也不敢信。
我们最后选的是所有 AI 都查同一份 Qdrant，向量库是单一来源。这件事对架构要求比较高——单租户的 Qdrant 撑不住高并发，得做 sharding；但好处是知识库更新一次，所有平台立刻同步。
这一条是被合规逼出来的。客户是金融行业，问了一个很直接的问题："AI 调用了我们的数据库，密码给了 AI，那这事谁来背锅？"
后来我们选了带 get_service_credential 的方案——AI 不存密码，需要的时候按需取用，全留痕。这种设计看起来多此一举，但出事的时候能救命。
老实说，这套架构不是教科书式的优雅，有几个地方是凑合出来的：
第一，WhatsApp 接入走了 Baileys 桥接。原因是 WhatsApp 官方 Cloud API 申请流程太长，客户等不起。代价是——WhatsApp 那条线不算稳定，偶尔要重启 Bridge。
第二，企业微信走的是智能机器人模式。好处是不用公网回调 URL，部署省事；坏处是 dm_policy 不配置的话默认接受所有私聊，我们一开始没注意到，生产环境闹了个笑话——某个客户用我们机器人调戏了一个小时内所有陌生用户的私聊。
第三，Teams 的 Webhook 必须公网 HTTPS。这一条没得商量，所以最后还是用了 Nginx 反代。问题是反代一旦挂了，Teams 用户完全感知不到——他们会继续发消息，然后什么都收不到。
做了两年多，最大的感受是："统一"不是一个状态，是一个持续投入的过程。
很多客户买完 AI 助手就以为完事了，半年后跟我说"AI 没人用了"。一看——Skill 没人加、知识库没人更新、Token 没人看。这种情况不是产品的问题，是组织的问题。
所以如果你在选型，我会建议把这两个问题也问厂商：
这套东西我们跑了两年多，说实话，没有银弹。多 IM 统一管理的痛点会一直存在，只是程度不同。
如果你也在做类似的事，欢迎交流踩过的坑。
几个具体的技术细节，留言区聊聊——比如 Qdrant 的 sharding 怎么做、Token 用量怎么预测、Skill 模板怎么设计。这些话题单开一篇文章都能写，但今天先到这。