釘釘 AI 助手怎麼接入?三種方案對比(附 Stream 模式程式碼)

釘釘接 AI 有三條路,選錯不是「多寫點程式」,而是上線後收不到訊息、被限流,或者資料邊界說不清

2026-09-21 · Leo · 接入教學 · 10 分鐘閱讀
TL;DR — 釘釘接 AI 助手有三條路:方案 A:企業內部應用機器人 + Stream 長連線(不用公網回調位址,收發都可控,正式場景首選);方案 B:自訂群機器人 Webhook(10 分鐘可用,但只能發不能收,做不了對話);方案 C:第三方 SaaS 託管(最快上線,但對話內容要過第三方平台)。本文給出三種方案的完整步驟和程式碼,以及 Stream 斷線、機器人收不到訊息、群 Webhook 被限流、卡片回調失敗等 5 個高頻坑的修法和上線前檢查清單。
⚠️ 本文是通用接入教學,介面欄位以釘釘官方文件為準;程式碼為範例設定,上線前請按自己公司的安全與合規要求調整。不涉及任何具體客戶案例。

先看結論:三種方案一張表

維度方案 A:企業內部機器人 + Stream方案 B:自訂群機器人 Webhook方案 C:第三方 SaaS 託管
收訊息✅ 單聊/群聊都可收可發❌ 只能往群裡發✅ 平台代收代發
要不要公網位址不用:服務主動連釘釘長連線不用(只出不進)不用
資料邊界訊息與回覆都在自己伺服器推送內容經釘釘伺服器對話內容經第三方平台
上線耗時1–3 天(主要是長連線與卡片除錯)約 10 分鐘半天到 1 天(設定為主)
適合場景正式 AI 助手、客服答疑、流程查詢警報播報、日報推送、CI/CD 通知快速驗證價值、無開發人力

一句話:做對話助手選 A,做通知播報選 B,先驗證價值選 C。最常見的錯誤是拿方案 B 做對話(收不到群裡的訊息,做不了),或者沒評估資料邊界就直接上方案 C。

方案 A:企業內部應用機器人 + Stream 長連線(推薦)

這是釘釘官方推薦的接入方式:你的服務用 Stream 模式主動和釘釘建立 WebSocket 長連線,員工在機器人會話裡發訊息 → 釘釘透過這條連線把訊息推給你的服務 → 服務調 AI → 再透過連線把回覆發回去。因為沒有入站 HTTP 回調,不需要公網 IP、不需要備案網域、不需要在防火牆上開埠,內網機器也能跑,這是它和「HTTP 回調」路線最大的區別。

第 1 步:建立企業內部應用與機器人(約 10 分鐘)

釘釘開發者後台 →「應用開發」→「企業內部應用」→ 建立應用,然後在應用裡「加入機器人」,訊息接收模式選 Stream 模式。記下三個值:

發布前先把可見範圍設成一個小部門做灰度,驗證通過再放開。

第 2 步:用 Stream 模式收訊息(約 30 分鐘,含除錯)

Stream 模式的核心是:服務啟動時用憑證換一個臨時連線位址,然後連上去、訂閱機器人訊息主題。連線斷了要重連——這是後面坑 1 的根源。

# dingtalk_stream_bot.py —— 建立長連線並訂閱機器人訊息
from dingtalk_stream import DingTalkStreamClient, Credential
from dingtalk_stream.chatbot import ChatbotHandler, ChatbotMessage

class AIHandler(ChatbotHandler):
    async def process(self, callback):
        msg = ChatbotMessage.from_dict(callback.data)
        # 先回執,再異步處理,別在回調裡等 AI(見坑 3)
        self.reply_text("收到,正在處理…", msg)
        question = msg.text.content.strip()
        answer = ask_ai(question)          # 你自己的 AI 服務 / 知識庫
        self.reply_text(answer, msg)
        return 200, "OK"

credential = Credential(CLIENT_ID, CLIENT_SECRET)      # 從環境變數讀,別寫死
client = DingTalkStreamClient(credential)
client.register_callback_handler("/v1.0/im/bot/messages/get", AIHandler())
client.start_forever()                 # 內含自動重連,但要有行程級守護

除錯期最容易踩的坑:主題(topic)寫錯——機器人訊息的主題是固定的,寫錯會表現為「連上了但永遠收不到訊息」,日誌裡卻沒有任何報錯。

第 3 步:發訊息與卡片(主動推送 + 會話回覆)

回覆會話用機器人訊息介面;如果要做「審批進度」「工單狀態」這類可點擊的互動,用互動卡片。兩個介面都走同一個 access_token,必須集中快取(有效期 7200 秒,有取得頻率限制)。

# dingtalk_client.py —— token 集中快取 + 發送機器人訊息
import time, requests

_token, _ts = "", 0

def get_token():
    global _token, _ts
    if _token and time.time() - _ts < 7000:          # 留 200 秒餘量
        return _token
    r = requests.post("https://api.dingtalk.com/v1.0/oauth2/accessToken",
                      json={"appKey": CLIENT_ID, "appSecret": CLIENT_SECRET},
                      timeout=5).json()
    _token, _ts = r["accessToken"], time.time()
    return _token

def reply_text(user_id, text):
    requests.post(
        "https://api.dingtalk.com/v1.0/robot/oToMessages/batchSend",
        headers={"x-acs-dingtalk-access-token": get_token()},
        json={"robotCode": ROBOT_CODE, "userIds": [user_id],
              "msgKey": "sampleText", "msgParam": '{"content": "%s"}' % text[:1800]},
        timeout=5)

注意最後一行:釘釘的文字訊息內容是包在 msgParam 的 JSON 字串裡的,超長要先截斷或分段,否則介面直接報錯(見坑 5)。

第 4 步:接上你的 AI 與知識庫

把 ask_ai() 換成你的 RAG 知識庫或大模型服務即可。三個工程要點:

方案 B:自訂群機器人 Webhook(10 分鐘,但只能發)

群設定 →「智慧群助手」→「加入機器人」→「自訂」,拿到一個 Webhook 位址,之後往這個位址 POST JSON 就能往群裡發訊息(可選加簽校驗):

curl 'https://oapi.dingtalk.com/robot/send?access_token=你的TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{"msgtype":"text","text":{"content":"部署完成:訂單服務 v2.3 已上線"}}'

它的定位是單向通知:監控告警、CI/CD 結果、每日播報。三個硬限制:收不到群裡的訊息(做不了對話)、每個機器人每分鐘發送條數有限(高頻告警必須做聚合)、@ 人要填手機號或 userId(不是暱稱)。支援 text、markdown、link、actionCard 等類型,適合「把系統裡的事件告訴人」,不適合「人問系統答」。

方案 C:第三方 SaaS 託管(最快,但先想清楚資料邊界)

市面上有不少託管平台:授權釘釘後網頁設定知識庫和話術,不用自己寫長連線程式,半天就能上線。適合兩種情況:沒有開發人力、想先小成本驗證 AI 助手有沒有價值。

但要在簽約前問清四件事,不然日後很難受:

  1. 資料存哪:員工提問和上傳的文件是否存在對方平台?存在哪個區域?
  2. 能不能匯出:哪天換方案,知識庫和會話紀錄能不能完整帶走?
  3. 支不支援私有化:驗證成功後能否遷到方案 A 的自建形態?
  4. 計費方式:按坐席還是按調用量?底層大模型的調用費是誰出?

橫向對比:釘釘 / 飛書 / 企業微信,接入難度差在哪

維度釘釘飛書企業微信
主流接入方式企業內部機器人 + Stream 長連線事件訂閱(長連線或 HTTP 回調)自建應用 + HTTP 回調
要不要公網位址不用(長連線主動外連)二選一,長連線可免要:必須 HTTPS 回調
回調時效要求長連線無 5 秒硬限HTTP 回調同樣要求快速返回5 秒內必須響應,否則重試
訊息去重按訊息 ID 去重按事件 ID 去重按 MsgId 去重
內網部署友好度高:不需要入站埠中低:要暴露回調位址

結論:如果公司內網出網受限、又不想為回調單獨申請公網網域,釘釘的 Stream 模式是三家裡面最好落地的;企業微信的 5 秒回調硬限最需要工程兜底;飛書介於兩者之間。多平台一起接的時候,把「收訊息 → 調 AI → 回覆」抽成一層統一閘道,各平台的差異只留在適配層,後面加平台才不會推倒重來。

五個高頻坑:現象與修法

坑 1:Stream 長連線半夜斷掉,白天沒人發現

現象:早上員工問機器人沒反應,重啟服務就好了。

根因:長連線被中間網路設備掐斷,客戶端沒有重連成功,或者行程因為未捕獲異常退出了。

✅ 修法:客戶端開啟自動重連 + 用 systemd/容器把行程守護起來(異常退出自動拉起);加一條「存活探針」——定時發一條心跳訊息給自己,超過 N 分鐘沒收到就告警。
坑 2:連線建立成功,但永遠收不到訊息

現象:日誌顯示已連線,員工發訊息卻毫無反應,也沒有報錯。

根因:訂閱的主題寫錯;或者機器人沒有發布、可見範圍沒包含提問人;或者註冊的回調路徑與訊息類型不匹配。

✅ 修法:核對主題常數(機器人訊息有固定主題);確認應用已發布且可見範圍覆蓋測試帳號;把收到的原始 callback 資料整體打日誌,先確認「有沒有到」,再查「為什麼沒回」。
坑 3:AI 處理慢,員工收到重複回答或空回覆

現象:問題複雜時,同一句話被回答兩三次,或者只回了個「收到」。

根因:在回調裡同步等 AI,逾時後平台重推;或者先回了「收到」卻沒有後續訊息。

✅ 修法:回調裡只做去重 + 入列,立刻返回;AI 處理放到異步任務,算完主動推送;按訊息 ID 去重(Redis SETNX 帶過期時間),多實例部署共享去重狀態。
坑 4:群機器人被限流,警報反而沒發出去

現象:故障期間警報刷屏,最關鍵的幾條反而沒到群裡。

根因:自訂群機器人有每分鐘發送條數上限,超了直接丟棄或報錯。

✅ 修法:警報先做聚合(相同警報合併、按 1 分鐘視窗彙總),失敗重試要有退避;關鍵警報走企業內部機器人單聊通道,別和群播報搶同一個出口。
坑 5:長回覆發不出去或被截斷

現象:AI 回答長一點,員工端收不到或只有前半截,介面報參數錯誤。

根因:文字內容包在 msgParam 的 JSON 字串裡,超長或引號未轉義都會失敗。

✅ 修法:用 json.dumps 產生 msgParam 而不是手拼字串;超長內容按段落切分成多條,或只回摘要 + 連結到知識庫頁面。

上線前檢查清單(8 條)

  1. 長連線是否有自動重連 + 行程守護(異常退出能自動拉起)?
  2. 是否有存活探針:定時心跳,超過閾值沒收到就告警?
  3. 訊息去重是否落地(Redis/記憶體集合),多實例是否共享去重狀態?
  4. access_token 是否集中快取、加鎖刷新、留過期餘量?
  5. AI 調用是否有逾時兜底(先回執,逾時給提示,而不是讓使用者乾等)?
  6. 長回覆是否分段或摘要化,msgParam 是否用序列化產生而非手拼?
  7. 發送前是否有敏感詞/權限過濾,誰能用這個機器人是否按部門收斂?
  8. 日誌是否脫敏,Client Secret 是否全部走環境變數而非程式庫?

寫在最後

三種方案沒有絕對優劣,選擇取決於三件事:資料邊界要求多高、有多少開發人力、要解決什麼場景。通知播報別上方案 A 浪費人力;正式對話助手別用方案 B(收不到訊息);上方案 C 之前把資料邊界四問問清楚。多數團隊的真實路徑是:先用 C 或 B 快速驗證,驗證成功後遷到方案 A 做長期自營。

如果只需要一個結論:做對話選 A,做通知選 B,做驗證選 C——別混用。

💡 延伸閱讀:其他 IM 平台怎麼接?看《企業微信 AI 機器人怎麼搭建?三種方案對比》和《企業 IM 裡直接調 AI Agent:4 步搞定飛書/釘釘/企微接入》;知識庫品質決定回答上限,見《企業 RAG 知識庫,為什麼 90% 都做不好?6 個真實踩坑》。
公司裡多 IM 平台各管各的?
飛書/企微/釘釘/微信/QQ 一個後台統一接入
免費諮詢 →