← 所有文章
對比選型

Telegram 嘅 Guest Mode 同統一入站 Webhook：邊個先真正解決多平台訊息問題？ — UnifyPort

2026 年 3 月,Telegram 推出咗 Bot API 9.5,順手解決咗一個困擾機器人開發者多年嘅問題:有人喺一個機器人從未加入嘅群組裡 @ 佢嗰陣,會發生咩事?以前嘅答案係「乜都唔會發生」——機器人收唔到呢個訊息,睇唔到呢個群組,亦無法回覆。Guest Mode 改變咗呢一點。喺 BotFather 裡打開呢個設定之後,你嘅機器人就能收到一個 guest_message 更新,並透過 answerGuestQuery 回覆一次,完全唔需要加入嗰個群組。

如果你做 Telegram 機器人開發,呢個係一個非常實用嘅新功能。但如果你嘅 agent 需要同時喺 Telegram、WhatsApp、LINE、Zalo、TikTok 同 X 上運作,咁佢只解決咗你大約六分之一嘅問題——值得將呢個「六分之一」講清楚。

Guest Mode 究竟做咩

佢嘅機制非常明確且範圍有限。當用戶喺受支援嘅聊天中 @ 提及你嘅機器人,或回覆機器人之前發嘅訊息嗰陣,Telegram 會發送一個包含 guest_message 嘅 Update,附帶一個一次性嘅 guest_query_id,以及觸發者 guest_bot_caller_user 同 guest_bot_caller_chat 嘅識別碼。你嘅機器人呼叫 answerGuestQuery 並傳入呢個 token,會攞到一個 SentGuestMessage 作為回應。一次提及,一次回覆。

僅此而已。Telegram 明確列出咗呢個功能嘅邊界:

  • 冇聊天記錄。 機器人只能睇到觸發呢次互動嗰條訊息,睇唔到之前嘅內容。
  • 冇成員名單。 無法列舉群組裡有啲咩人。
  • 冇常駐關注。 除非再次被 @ 或回覆,機器人唔會收到呢個聊天後續訊息嘅任何通知。
  • 一次提問,一次回覆。 呢係一個請求/回應原語,唔係訂閱。

對於某類特定嘅機器人——例如經常被 @ 到各種開發群組裡嘅文件查詢機器人、單位換算機器人、翻譯助手——呢個設計啱啱好。佢好輕量,係 opt-in 嘅(群組管理員唔需要將機器人加入群組,機器人方只需要喺 BotFather 嘅 MiniApp 裡打開一個開關),亦消除咗「請將 @MyBot 加入呢個群組」呢道曾經扼殺咗唔少工具型機器人嘅門檻。

佢解決唔到啲咩

Guest Mode 係一個徹頭徹尾嘅 Telegram 功能。佢實作喺 Telegram 嘅客戶端同伺服端,透過 Telegram 嘅 Bot API 暴露,由 Telegram 特有嘅 UI 行為(喺 Telegram 聊天裡 @ 提及或回覆)觸發。呢啲都無法移植到其他平台。

如果你嘅團隊喺唔止一個渠道上運作客服或 agent 工作流程——呢喺 2026 年嘅客戶自動化場景裡幾乎係常態——咁「我嘅機器人點樣喺未被正式加入對話嘅情況下,被拉入一次對話」就唔只係一個 Telegram 嘅問題。同樣形態嘅問題亦存在於:

  • WhatsApp——客戶直接發訊息畀一個號碼,你嘅系統需要喺冇現成「對話」物件嘅情況下接住佢
  • LINE——用戶 follow 一個官方帳號並開始發訊息,根本唔涉及任何「群組」概念
  • X——有人私訊你嘅帳號,或喺回覆裡 @ 提及佢
  • TikTok 同 Zalo——各自有自己嘅入站訊息格式

Telegram 解決咗佢自己版本嘅「接收一條發畀你、但你之前並未明確關注嘅訊息」。但如果你圍繞 guest_message 同 answerGuestQuery 搭建入站管道,你只為六分之一嘅渠道搭建咗佢。剩落嘅五個渠道需要各自嘅整合、各自嘅驗證方式、各自嘅事件格式——而且 Guest Mode 嗰啲特定嘅限制(冇記錄、單次回覆、需要重新觸發)甚至無法乾淨咁對應到 WhatsApp 或 LINE 嘅對話模型上。

問題嘅真正樣貌

將各平台特有嘅機制去除,每個處於呢種局面嘅團隊真正想要嘅其實係同一件事:一個統一規範嘅事件,只要有訊息發畀你某個帳號——無論嚟自邊個平台——佢就會觸發,再加一個用嚟回覆嘅統一介面。

呢個唔係 Telegram 嘅功能。呢係一個整合層——亦正正係 UnifyPort 存在嘅意義。

統一 Webhook 點樣喺六個平台上覆蓋同樣嘅場景

UnifyPort 嘅 webhook 會為任何已連接渠道上嘅入站訊息,統一發出一個 message.received 事件:

{
  "event": "message.received",
  "account_id": "acct_8Q2vK",
  "provider": "telegram",
  "from": "user_3f9c1a",
  "text": "Hey, are you open on weekends?",
  "timestamp": 1749427200,
  "message_id": "tg_msg_5d2b7e"
}

將 provider 換成 whatsapp、line、zalo、tiktok 或 x,事件嘅結構唔會改變——只有呢一個欄位嘅值唔同。你嘅處理邏輯唔需要為六個唔同嘅 SDK 或六種唔同嘅 webhook 格式分別寫分支;只需要判斷一次 evt.event === "message.received",然後用 evt.provider 決定回覆時行邊個渠道(如果呢點對你嚟講重要嘅話)。

回覆同樣係對稱嘅:統一呼叫一次 POST /v1/messages,用 Bearer API key 驗證,透過 account_id 同 from 定址——無論入站訊息嚟自邊個平台,呼叫方式完全一樣。每一次推送到你 webhook 嘅資料,都用你設定嘅 signing_secret 做咗 HMAC-SHA256 簽名,所以驗證邏輯亦只有一套,唔係六套。

Telegram ─┐
WhatsApp ─┤
  LINE   ─┼──► UnifyPort ──► message.received ──► 你嘅 webhook
  Zalo   ─┤         ▲                                   │
 TikTok  ─┤         │                                   ▼
   X     ─┘    POST /v1/messages ◄──────────── 你嘅回覆邏輯

Guest Mode 需要群組管理員(或對話上下文本身)先 @ 你嘅機器人先可以觸發動作,而 UnifyPort 嘅入站事件就按每個渠道原生嘅觸發方式(私訊、follow、回覆)直接發出,並統一轉換成相同嘅 message.received 結構。你唔需要等一個 Telegram 特有嘅訊號,先去其他五個根本冇對應機制嘅平台上「複製」佢。

實務上嘅意義

如果 Telegram 真係你唯一嘅渠道,而你嘅場景亦啱啱好符合 Guest Mode 嘅形態——偶爾喺你唔管理嘅群組裡被 @ 到——咁佢值得開啟。免費、原生,亦唔需要額外嘅基礎設施。

但如果你已經行過呢一步,正在跑一個需要同時喺 Telegram 同 WhatsApp 以及 客戶用嘅其他渠道上接收訊息嘅 agent 或客服工作流程——圍繞 Telegram 特有嘅原語嚟搭建,意味住同樣嘅邏輯要為另外五個平台各重做一次,每個仲都有自己嘅怪癖。統一 webhook 將呢一切收攏成一次整合,做一次就夠。連接你嘅渠道,查看 message.received 參考文件——如果你打算將佢交畀 AI 編碼工具嚟搭建接收端,呢裡有一個實際嘅搭建過程。