← 所有文章
對比選型

Telegram Bot API 10.1 推出富文本訊息——對接收端團隊來說，什麼變了，什麼沒變 — UnifyPort

6 月 11 日，Telegram 發布了 Bot API 10.1——這一次，更新日誌確實值得興奮。機器人現在可以發送包含表格、標題、巢狀列表、內嵌媒體、摺疊區段、數學公式、註腳和引用區塊的富文本訊息。全新的 sendRichMessageDraft 方法支援串流傳輸部分訊息，這代表 AI 代理程式可以推送「思考中」的漸進式回覆，而非延遲後一次輸出一大段文字。訊息最大長度提升至 32,768 個字元，超過約 8,000 字元後會出現「顯示更多」按鈕。

幾天之內，各大主流機器人函式庫——python-telegram-bot、puregram、Telegraf——都開了 issue 追蹤 10.1 支援。AI 代理框架也開始提交工單，準備將基於 Markdown 的回覆呈現替換為新的 RichMessage 區塊。如果你在開發 Telegram 機器人，這是自 2019 年 MarkdownV2 以來最大的格式化升級。

但如果你的團隊是在 Telegram 和其他平台上接收訊息，值得問一個更尖銳的問題：這些更新對你的入站流程有影響嗎？

Bot API 10.1 到底新增了什麼

新功能全部在發送端——也就是機器人如何格式化和發送訊息給使用者。以下是本次更新內容：

功能方法說明
富文本格式sendRichMessage表格、標題、列表、內嵌媒體、數學公式、摺疊區塊、註腳
串流回覆sendRichMessageDraft邊生成邊推送訊息——專為 AI 代理設計
更長的訊息—最大 32,768 字元，先前有效上限約 4,096
富文本內嵌結果InputRichMessageContent內嵌查詢、訪客模式和 Web App 查詢中支援富文本
編輯支援editMessageText新增 rich_message 參數，可編輯已發送的富文本訊息

這些功能全部提升的是機器人能說什麼。沒有任何一項改變機器人能聽到什麼。Update 物件——使用者給機器人發訊息時 Telegram 推送給你的資料結構——和 10.1 之前完全一樣。使用者的文字訊息依然以 message 更新中的 text 欄位到達。媒體依然以 photo、document、voice 等形式到達。入站 schema 沒變，因為它不需要變：使用者不會給你的機器人發帶 LaTeX 公式和摺疊段落的富文本訊息。

為什麼這對多平台團隊沒那麼重要

如果 Telegram 是你唯一的頻道，10.1 毫無疑問是好消息。機器人回覆更美觀了，AI 代理的串流輸出更流暢了，你也不用再和 MarkdownV2 的跳脫規則奮戰了。

但 2026 年接收入站訊息的大多數團隊並不只用 Telegram。他們同時處理 WhatsApp 私訊、LINE 訊息、TikTok 電商客服對話、X 上的提及和 Zalo 公眾號訊息——痛點不在於如何格式化回覆，而在於如何把所有入站訊息匯集到同一處、用同一種格式、快到足以在 SLA 內回應。

以下是各平台官方 API 在入站訊息推送方面的比較：

平台官方入站方式格式費用接入時間
TelegramBot API webhook (setWebhook)Telegram Update JSON免費幾分鐘
WhatsAppCloud API webhookMeta webhook 格式按訊息計費 + BSP 加價數天至數週
LINEMessaging API webhookLINE 事件 JSON免費額度，超出按訊息計費數天至數週（僅 3 個國家）
XAPI v2（輪詢或篩選串流）X API JSON$0.001–$0.20/次數小時至數天
TikTok無通用私訊 API——無程式化路徑
ZaloOA API webhookZalo 事件 JSON分級 OA 定價數天至數週

六個平台，六種驗證模型，六種 webhook 格式，六種計費方式。Telegram 的 Bot API 10.1 讓這張表中的一欄更強大了——Telegram 的發送端格式化欄——但沒有改變真正決定你整合複雜度的那一列：入站訊息的資料格式。

入站的核心問題是格式歸一化，不是格式化

多平台入站團隊需要的不是任何單一頻道上更豐富的發送格式，而是一種歸一化的入站事件——不論訊息來自哪個平台都長同一個樣——這樣一個 webhook 處理器、一套簽章驗證邏輯、一個路由函式就能涵蓋全部六個頻道。

這正是 UnifyPort 提供的能力。連接你的帳號——Telegram、WhatsApp、LINE、TikTok、Zalo、X——每條入站訊息都以 message.received 事件的統一 schema 到達你的 webhook：

{
  "event": "message.received",
  "data": {
    "account_id": "acct_tg_support",
    "provider": "telegram",
    "chat_id": "chat_7d3a1f",
    "sender": "user_9c4b2e",
    "message": {
      "id": "tg_msg_8e1f4a",
      "type": "text",
      "text": "你好，這款有 L 號嗎？",
      "reply_token": "rt_3f7b9c..."
    },
    "timestamp": 1750636800
  }
}

把 provider 換成 whatsapp、line 或 tiktok，資料結構完全不變。你的處理器用建立 webhook 時設定的 signing_secret 驗證一次 HMAC-SHA256 簽章，然後路由訊息——不需要按平台引入 SDK，不需要按頻道寫解析邏輯，不需要六路分支判斷事件格式。

無需官方 API 審批或企業認證。個人帳號和普通帳號即可使用。沒有按訊息計費，也沒有範本審核排隊。

面對 10.1，應該怎麼做

如果你在開發 Telegram 機器人：升級你的函式庫，開始使用 sendRichMessage。格式化能力確實出色，透過 sendRichMessageDraft 實現串流輸出對生成長回覆的 AI 機器人來說是明顯的提升。

如果你在多個平台接收訊息：10.1 不會改變你的入站架構。使用者發給你的訊息依然以原來的格式到達——Telegram 如此，其他平台也一樣。整合的挑戰始終是把六種不同的入站格式歸一到同一個處理器裡，而這正是統一 webhook 消除逐平台整合工作的那一層。

Telegram 發布了一支更好的畫筆。水管工程——把客戶的訊息送到你的團隊——是另一個問題，而且它天然與平台無關。