先看清員工用什麼，再決定機器人長在哪
很多團隊選型時把問題定義成「釘釘、飛書、企微誰的機器人更厲害」，這個問題問錯了。三家的機器人能力上限差距，遠小於員工是否願意打開它帶來的差距。
正確的問題應該是兩個：
下面五維對比，是為了回答第二個問題：當你需要在多個平台上都有入口時，哪些維度會成為真差異，哪些其實都差不多。
飛書的自建應用模式是三家里最開放的：建立應用 → 申請權限 → 拿 app_id/secret → 調事件訂閱 Webhook。權限顆粒度細到「讀訊息 / 發訊息 / 讀通訊錄」分別申請，適合有研發團隊做精細管控。
企業微信的機器人分兩類：群機器人（Webhook 推送為主，設定簡單但能力有限）與自建應用（需要企業 ID + Secret，能做更多事，但後台設定項多，第一次設定容易卡住）。
釘釘的機器人在企業內部管理場景裡整合度較高，掃碼綁定、組織架構同步這些能力開箱即用，但自訂能力的接口形態相對固定。
| 平台 | 最小可用接入 | 適合誰 |
|---|---|---|
| 飛書 | 自建應用 + 事件訂閱，權限按需申請 | 有研發團隊、需要精細權限控制 |
| 企業微信 | 群機器人 Webhook（簡單）／自建應用（完整） | 先快速驗證，或已有企微生態 |
| 釘釘 | 掃碼綁定 + 組織架構同步 | 已在釘釘上跑 OA、流程審批的企業 |
接入細節可參考《企業微信 AI 機器人怎麼搭建》《釘釘 AI 助手怎麼接入》與《AI Agent 知識庫的常見坑》三篇。
這是差異最容易被低估的一維。群聊裡 @ 機器人和單聊裡直接問，是兩種完全不同的互動密度：
群聊場景的優勢是一次提問、一群人看到答案，天然帶擴散效應，適合制度問答、進度查詢這類「圍觀型」需求。飛書與釘釘的群機器人訊息在群內的可見性和 @ 觸發體驗都比較順；企業微信的外部群（含客戶）在訊息可見範圍上有更嚴格的限制——這是合規設計，不是缺陷，但會改變你的用法：外部群適合只做單向推送，不適合做多輪問答。
單聊場景才是真正幹活的地方。員工私聊機器人問「上季度這個客戶的對賬流程是什麼」，助手需要讀知識庫、查權限、做匯總。飛書、企微、釘釘的單聊入口都支援接收訊息，但能不能把「查到的結果直接寫成檔案」取決於機器人的能力邊界，而不是平台本身。
三家的權限顆粒度不同，但更重要的是權限管理發生在哪一層。
如果 AI 機器人是平台內自建應用，權限跟著平台管理員走，IT 部門比較熟悉；如果機器人是獨立的 AI 中台，它自己有一套按部門、按崗位發能力的模型——技能啟停、命令黑白名單、知識庫可見範圍、遠端工具載入控制都在 AI 側做，與 IM 平台解耦。
這個差別在「平台只有一個」時看不出來，在多平台並存時就是關鍵：三個平台各配一套權限，出問題時你不知道是哪一層沒放行。做多平台時，權限應該收在 AI 側統一管，IM 平台只負責「訊息能進來」。
順帶一個容易忽略的點：可追溯。誰在什麼時候問了什麼、助手動了哪些檔案，能不能回看。權限放開的前提是可追溯，否則 IT 不會批。
這是選型時最該問、也最少人問的一維。你的制度文件在哪？
如果文件在飛書雲文件，那飛書機器人的檢索鏈路天然最短；如果在釘釘附件或內部系統裡，就得先把文件抽出來做統一索引；如果在企微的聊天記錄與文件裡，權限複雜度最高，因為聊天記錄往往混著個人內容與業務內容。
跨平台時更要注意：知識庫必須帶部門邊界。客服部的話術手冊只給客服部看，財務規章只給相關部門看。做多平台接入時，AI 側的知識庫按部門隔離，而不是按 IM 平台隔離——否則同一個人換個 IM 就能看到另一個部門的資料。
最後看能不能接到業務系統上：CRM、工單、ERP、內部資料庫。三家都提供了各自的開放接口，能力差異主要體現在能不能用統一協議接而不是逐個平台對接。
更省事的做法是用標準協議（如 MCP）統一接入內部系統：每台伺服器單獨啟停、哪些 Agent 能載入哪些遠端工具，按部門分別管控。這樣接一次，所有 IM 平台共用同一套工具集，不必為每個平台重做一遍整合。
相關機制見《AI Agent 與 IM 平台打通》。
如果你的員工分散在飛書、企微、釘釘、微信、QQ 上，最合理的架構是：IM 平台只做入口，AI 能力集中在中台。
這樣做的好處很直接：
綁定通常一次性完成：管理側掃碼綁定飛書/企微/微信，再配置 QQ 機器人、Teams 機器人、WhatsApp 機器人號碼等，綁定一次全公司可用，員工不用各自折騰。
每題 1 分。0-3 分：只接一個主力平台；4-7 分：主力平台 + 一個次要入口；8 分以上：上多平台統一後台。
| # | 判斷題 | 選型含義 |
|---|---|---|
| 1 | 員工主力 IM 是哪個？該平台用戶佔比多少？ | 佔比最高的就是第一入口，不要平均用力 |
| 2 | 公司有沒有第二個 IM 平台在混用？ | 有 → 必須考慮多入口，否則使用率被摩擦吃掉 |
| 3 | 有沒有客戶在外部群裡需要被服務？ | 有 → 企微外部群能力要單獨評估 |
| 4 | 有沒有研發團隊能自己配應用和調權限？ | 沒有 → 優先選設定門檻低的接入方式 |
| 5 | 制度文件主要存放在哪？ | 決定哪條平台的檢索鏈路最短 |
| 6 | 不同部門能看到的內容需要區分嗎？ | 需要 → 知識庫必須支援部門隔離 |
| 7 | IT 敢不敢放開機器人的檔案與命令權限？ | 不敢 → 先補可追溯能力，否則推不動 |
| 8 | 需要機器人接內部系統嗎？接幾個？ | 多系統 → 優先選統一協議接入，別逐個平台對接 |
| 9 | 公司已有哪個平台的 OA / 審批 / 日程在跑？ | 沿用現有生態，遷移成本最低 |
| 10 | 預算與合規上能否接受多平台並行？ | 不能 → 聚焦一個平台做深，別三個都做淺 |
功能清單和實際使用場景是兩件事。員工只會在一個地方用工具，那個地方是哪，決定了上限。先定場景再選平台。
短期省事，長期是三套權限、三套知識庫、三套日誌。出問題時無法定位是哪一層。建議統一到中台，IM 只做入口。
模型能力在三個平台上是同一個量級，真正的差異在入口和打通。先定平台與入口，再談模型，否則容易為用不上的能力付費。
釘釘、飛書、企業微信的 AI 機器人，能力差距沒有大到需要糾結的程度。真正拉開差距的是「員工願不願意用它」和「企業敢不敢給它權限」這兩件事。
所以順序應該是：先看清員工在哪個平台 → 再定入口要覆蓋幾個平台 → 然後才是選接入方式和模型能力。選型做對一次，後面所有落地動作才有地基。