← 所有文章
對比選型

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 發佈咗一支更靚嘅畫筆。水喉工程——將客戶嘅訊息送到你嘅團隊——係另一個問題，而且佢天然同平台無關。