去年幫一個客戶做 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 模板怎麼設計。這些話題單開一篇文章都能寫，但今天先到這。