← 所有文章
對比選型

Telegram 的 Guest Mode 與統一入站 Webhook：誰才能真正解決多平台訊息問題？ — UnifyPort

2026 年 3 月,Telegram 發布了 Bot API 9.5,順手解決了一個困擾機器人開發者多年的問題:當有人在一個機器人從未加入的群組中 @ 它時會發生什麼事?以前的答案是「什麼都不會發生」——機器人收不到這則訊息,看不到這個群組,也無法回覆。Guest Mode 改變了這一點。在 BotFather 中打開這個設定後,你的機器人就能收到一則 guest_message 更新,並透過 answerGuestQuery 回覆一次,完全不需要加入那個群組。

如果你在做 Telegram 機器人開發,這是一個非常實用的新功能。但如果你的代理程式需要同時跑在 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 聊天中 @ 提及或回覆)觸發。這些都無法移植到其他平台。

如果你的團隊在不止一個渠道上跑客服或代理工作流程——這在 2026 年的客戶自動化場景中幾乎是常態——那麼「我的機器人如何在沒有被正式加入對話的情況下,被拉入一次對話」就不只是 Telegram 的問題。同樣形態的問題也存在於:

  • WhatsApp——客戶直接發訊息給一個號碼,你的系統需要在沒有現成「對話」物件的情況下接住它
  • LINE——使用者追蹤一個官方帳號並開始發訊息,根本不涉及任何「群組」概念
  • 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 的入站事件則按每個渠道原生的觸發方式(私訊、追蹤、回覆)直接發出,並統一轉換成相同的 message.received 結構。你不需要等一個 Telegram 特有的訊號,再到其他五個根本沒有對應機制的平台上「複製」它。

實務上的意義

如果 Telegram 確實是你唯一的渠道,而你的場景也恰好符合 Guest Mode 的形態——偶爾在你不管理的群組裡被 @ 到——那它值得開啟。免費、原生,也不需要額外的基礎設施。

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