Telegram Bot API 10.1 เปิดตัว Rich Messages — อะไรเปลี่ยน (และไม่เปลี่ยน) สำหรับทีมที่รับข้อความ — UnifyPort

วันที่ 11 มิถุนายน Telegram ปล่อย Bot API 10.1 — และครั้งนี้ changelog สมกับความตื่นเต้น บอทสามารถส่ง rich message ที่มีตาราง, หัวข้อ, รายการซ้อน, สื่อแบบอินไลน์, ส่วนพับได้, สูตรคณิตศาสตร์, เชิงอรรถ และบล็อกอ้างอิง เมธอดใหม่ sendRichMessageDraft รองรับการสตรีมข้อความแบบเรียลไทม์ — AI agent สามารถส่งคำตอบ “กำลังคิด” ทีละส่วนแทนที่จะรอแล้วส่งข้อความยาวๆ ทีเดียว ความยาวข้อความสูงสุดเพิ่มเป็น 32,768 ตัวอักษร โดยมีปุ่ม “แสดงเพิ่มเติม” หลังจากประมาณ 8,000 ตัวอักษรแรก

ภายในไม่กี่วัน ไลบรารีบอทหลักทุกตัว — python-telegram-bot, puregram, Telegraf — เปิด issue ติดตามการรองรับ 10.1 เฟรมเวิร์ก AI agent เริ่มยื่นตั๋วเพื่อเปลี่ยนการเรนเดอร์ตอบกลับแบบ Markdown เป็นบล็อก RichMessage ใหม่ หากคุณพัฒนา Telegram บอท นี่คืออัปเกรดด้านฟอร์แมตที่ใหญ่ที่สุดตั้งแต่ MarkdownV2 ในปี 2019

แต่ถ้าทีมของคุณรับข้อความบน Telegram และแพลตฟอร์มอื่น คุ้มค่าที่จะถามคำถามที่ตรงกว่า: การอัปเดตเหล่านี้เปลี่ยนไปป์ไลน์ขาเข้าของคุณไหม?

Bot API 10.1 เพิ่มอะไรจริงๆ

ฟีเจอร์ใหม่ทั้งหมดอยู่ด้านขาออก — วิธีที่บอทจัดรูปแบบและส่งข้อความให้ผู้ใช้:

ความสามารถ	เมธอด	สิ่งที่ทำ
ฟอร์แมต Rich	sendRichMessage	ตาราง หัวข้อ รายการ สื่ออินไลน์ สูตร บล็อกพับได้ เชิงอรรถ
ตอบกลับแบบสตรีม	sendRichMessageDraft	สตรีมข้อความขณะสร้าง — ออกแบบมาสำหรับ AI agent
ข้อความยาวขึ้น	—	สูงสุด 32,768 ตัวอักษร (เดิมจำกัดจริงๆ ที่ ~4,096)
ผลลัพธ์อินไลน์ Rich	InputRichMessageContent	ฟอร์แมต Rich ในอินไลน์, guest mode และ Web App query
รองรับแก้ไข	editMessageText	พารามิเตอร์ rich_message ใหม่สำหรับแก้ไข rich message ที่ส่งแล้ว

ฟีเจอร์เหล่านี้ทั้งหมดปรับปรุงสิ่งที่บอทพูดได้ ไม่มีสิ่งใดเปลี่ยนสิ่งที่บอทได้ยิน ออบเจ็กต์ Update — โครงสร้างข้อมูลที่ Telegram ส่งให้บอทเมื่อผู้ใช้ส่งข้อความ — เหมือนเดิมทุกประการก่อน 10.1 ข้อความตัวอักษรจากผู้ใช้ยังคงมาถึงเป็น message update ที่มีฟิลด์ text สื่อยังคงมาถึงเป็น photo, document, voice ฯลฯ สกีมาขาเข้าไม่เปลี่ยนเพราะไม่จำเป็นต้องเปลี่ยน: ผู้ใช้ไม่ได้ส่ง rich message ที่มีสูตร LaTeX และส่วนพับได้ให้บอทของคุณ

ทำไมเรื่องนี้ไม่สำคัญอย่างที่เห็นสำหรับทีมหลายแพลตฟอร์ม

หาก Telegram เป็นช่องทางเดียวของคุณ 10.1 เป็นข่าวดีอย่างไม่ต้องสงสัย คำตอบของบอทสวยขึ้น เอาต์พุตสตรีมของ AI agent ลื่นไหลขึ้น และคุณไม่ต้องต่อสู้กับกฎ escape ของ MarkdownV2 อีกต่อไป

แต่ทีมส่วนใหญ่ที่รับข้อความขาเข้าในปี 2026 ไม่ได้ใช้แค่ Telegram พวกเขาจัดการ WhatsApp DM, ข้อความ LINE, การสนทนา TikTok Shop, การกล่าวถึงบน X และข้อความ Zalo OA ควบคู่ไป — ปัญหาไม่ใช่การจัดรูปแบบคำตอบที่ส่งออก แต่เป็นการรวบรวมข้อความขาเข้าทั้งหมดไว้ที่เดียว ในรูปแบบเดียว เร็วพอที่จะตอบภายใน SLA

นี่คือสิ่งที่ API อย่างเป็นทางการของแต่ละแพลตฟอร์มให้สำหรับการส่งขาเข้า:

แพลตฟอร์ม	วิธีรับอย่างเป็นทางการ	รูปแบบ	ค่าใช้จ่าย	เวลาตั้งค่า
Telegram	Bot API webhook (setWebhook)	Telegram Update JSON	ฟรี	ไม่กี่นาที
WhatsApp	Cloud API webhook	รูปแบบ Meta webhook	คิดราคาต่อข้อความ + ส่วนเพิ่ม BSP	หลายวัน–หลายสัปดาห์
LINE	Messaging API webhook	LINE event JSON	โควตาฟรี เกินแล้วคิดต่อข้อความ	หลายวัน–หลายสัปดาห์ (เฉพาะ 3 ประเทศ)
X	API v2 (polling หรือ filtered stream)	X API JSON	$0.001–$0.20/ครั้ง	หลายชั่วโมง–หลายวัน
TikTok	ไม่มี DM API ทั่วไป	—	—	ไม่มีเส้นทางโปรแกรม
Zalo	OA API webhook	Zalo event JSON	ราคา OA แบบขั้น	หลายวัน–หลายสัปดาห์

หกแพลตฟอร์ม หกโมเดลการยืนยันตัวตน หกรูปแบบ webhook หกโครงสร้างค่าใช้จ่าย Telegram Bot API 10.1 ทำให้คอลัมน์หนึ่งในตารางนี้แข็งแกร่งขึ้น — คอลัมน์ฟอร์แมตขาออกของ Telegram — แต่ไม่ได้เปลี่ยนแถวที่กำหนดความซับซ้อนในการเชื่อมต่อจริงๆ: รูปแบบข้อมูลของข้อความขาเข้า

ปัญหาขาเข้าคือการทำให้รูปแบบเป็นมาตรฐาน ไม่ใช่การจัดรูปแบบ

สิ่งที่ทีมรับข้อความหลายแพลตฟอร์มต้องการไม่ใช่ฟอร์แมตขาออกที่สมบูรณ์ขึ้นบนช่องทางใดช่องทางหนึ่ง แต่เป็นอีเวนต์ขาเข้าที่มาตรฐานเดียวกัน — ไม่ว่าข้อความจะมาจากแพลตฟอร์มไหนก็หน้าตาเหมือนกัน — เพื่อให้ webhook handler หนึ่งตัว การตรวจสอบลายเซ็นหนึ่งเส้นทาง และฟังก์ชัน routing หนึ่งตัวครอบคลุมทั้งหกช่องทาง

นั่นคือสิ่งที่ UnifyPort มอบให้ เชื่อมต่อบัญชีของคุณ — Telegram, WhatsApp, LINE, TikTok, Zalo, X — ทุกข้อความขาเข้าจะมาถึง webhook ของคุณเป็นอีเวนต์ message.received ในสกีมามาตรฐานเดียวกัน:

{
  "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 — โครงสร้างข้อมูลเหมือนเดิมทุกประการ handler ของคุณตรวจสอบลายเซ็น HMAC-SHA256 หนึ่งครั้งด้วย signing_secret ที่ตั้งไว้ตอนสร้าง webhook แล้ว route ข้อความ — ไม่ต้อง SDK แยกแต่ละแพลตฟอร์ม ไม่ต้อง logic แยก parse แต่ละช่อง ไม่ต้องแยกสาขาหกทางตามรูปแบบอีเวนต์

ไม่ต้องอนุมัติ API อย่างเป็นทางการหรือยืนยันธุรกิจ บัญชีส่วนตัวและบัญชีทั่วไปใช้งานได้ ไม่มีค่าใช้จ่ายต่อข้อความและไม่ต้องรอคิวอนุมัติ template

ควรทำอะไรกับ 10.1 จริงๆ

หากคุณพัฒนา Telegram บอท: อัปเกรดไลบรารีแล้วเริ่มใช้ sendRichMessage ความสามารถด้านฟอร์แมตน่าประทับใจจริงๆ และการสตรีมผ่าน sendRichMessageDraft เป็นข้อดีที่ชัดเจนสำหรับบอท AI ที่สร้างคำตอบยาว

หากคุณรับข้อความจากหลายแพลตฟอร์ม: 10.1 ไม่เปลี่ยนสถาปัตยกรรมขาเข้าของคุณ ข้อความที่ผู้ใช้ส่งให้คุณยังคงมาในรูปแบบเดิม — ทั้งบน Telegram และทุกที่อื่น ความท้าทายในการเชื่อมต่อยังคงเป็นการรวมหกรูปแบบขาเข้าที่แตกต่างกันเข้าไว้ใน handler เดียว และนั่นคือเลเยอร์ที่ unified webhook ขจัดงานแยกแต่ละแพลตฟอร์ม

Telegram ปล่อยพู่กันที่ดีกว่า ระบบท่อ — การส่งข้อความจากลูกค้าไปยังทีมของคุณ — เป็นปัญหาคนละเรื่อง และโดยธรรมชาติแล้วมันไม่ขึ้นกับแพลตฟอร์ม