การคลิก, บอท หรือเซสชัน: 3 ระดับของระบบอัตโนมัติบน Telegram ที่คนมักสับสน

การคลิก, บอท หรือเซสชัน: 3 ระดับของระบบอัตโนมัติบน Telegram ที่คนมักสับสน

ความแตกต่างระหว่างการจัดการ Telegram ผ่าน Cloud Phone, Bot API และ MTProto client สำหรับผู้ใช้ทั่วไป — และทำไมการเลือกผิดระดับจึงสร้างข้อจำกัดทางเทคนิค

ลองจินตนาการถึงทีมที่ซื้อบัญชี Telegram, พร็อกซี และสิทธิ์เข้าใช้งาน Cloud Phone โดยเปิดแต่ละบัญชีแยกกันในสภาพแวดล้อม Android ที่แตกต่างกัน ระบบ Window Sync ช่วยให้พนักงานคลิกซ้ำๆ บนอุปกรณ์หลายเครื่องพร้อมกันได้ จากนั้นคำถามก็ตามมา: ทีมจะอ่านบทสนทนา ตอบกลับในฐานะบัญชีผู้ใช้ปกติ ทำงานกับรายชื่อติดต่อ ตรวจสอบสถานะเซสชัน และรวบรวมผลลัพธ์โดยอัตโนมัติได้อย่างไร?

ปัญหาไม่ใช่ว่าวิธีใดวิธีหนึ่งมีข้อจำกัดในตัวเอง แต่เป็นเพราะผู้ใช้งานมักสับสนระหว่างกลไกอัตโนมัติ 3 แบบที่แตกต่างกัน ซึ่งแต่ละแบบควบคุมประเภทของเอนทิตีที่ต่างกัน

บทความนี้จะอธิบายความแตกต่างระหว่าง UI automation, Bot API และ MTProto ว่าแต่ละวิธีแก้ปัญหาใดได้บ้าง และเมื่อใดที่โครงสร้างพื้นฐานบนมือถือเพียงอย่างเดียวอาจไม่เพียงพออีกต่อไป

“Telegram อัตโนมัติ” เป็นความต้องการที่คลุมเครือเกินไป

เมื่อผู้ใช้พูดถึง “ระบบอัตโนมัติ” พวกเขาอาจหมายถึงสิ่งที่แตกต่างกันโดยสิ้นเชิง:

• การทำซ้ำการกระทำในแอป Android
• แชทบอท, ระบบบริการลูกค้า หรือระบบแจ้งเตือน
• การดำเนินการในฐานะบัญชี Telegram ปกติ
• การอ่านบทสนทนาที่มีอยู่ในบัญชีนั้น
• การจัดการเซสชันที่ได้รับอนุญาตหลายเซสชัน
• การจัดการข้อผิดพลาดและผลลัพธ์ของแต่ละบัญชี

จนกว่าจะระบุตัวตน (Identity) ได้อย่างชัดเจนว่า ใคร หรือ อะไร ที่ต้องเป็นผู้กระทำการ นั่นแสดงว่ายังเร็วเกินไปที่จะเลือกเครื่องมือ

ผู้ใช้ใน BlackHatWorld อธิบายสถานการณ์ทั่วไปว่า: เขาซื้อบัญชี Telegram 5 บัญชี, พร็อกซีแบบ residential rotating และสมาชิก AdsPower เพื่อสร้างโปรไฟล์แยกกันและเปิด Telegram Web หลังจากเตรียมสภาพแวดล้อมเสร็จ เขาถามว่าจะทำอย่างไรให้การกระทำเป็นอัตโนมัติในทุกโปรไฟล์พร้อมกัน และเขาต้องการ “บอท Telegram พิเศษ” หรือไม่ ผู้เข้าร่วมเสนอวิธีแก้ไขที่แตกต่างกันหลายวิธี: browser automation, RPA, สคริปต์สแตนด์อโลน, userbot และเครื่องมือ Telegram ของบุคคลที่สาม โปรไฟล์ที่แยกแยกกันเพียงอย่างเดียวไม่สามารถตอบโจทย์ว่าการกระทำนั้นจะถูกรันบน Telegram ได้อย่างไร

ผู้ใช้ Stack Overflow ระบุปัญหาได้ชัดเจนยิ่งขึ้น: เขาต้องการให้บอทเข้าถึงบัญชีปกติ อ่านข้อความ และตอบกลับในลักษณะที่ดูเหมือนส่งโดยผู้ใช้จริง คำตอบอธิบายว่า Bot API ไม่ได้มีโมเดลการเข้าถึงทั่วไปเช่นนั้น

นี่ไม่ใช่ปัญหาที่สมมติขึ้น ในชุมชนต่างๆ ผู้คนใช้คำว่า “บอท” เพื่ออ้างถึงทั้งการจำลองหน้าจอ (screen automation), Bot API และ user client เหมือนๆ กัน

เรามาเริ่มที่วิธีที่เห็นภาพชัดที่สุด: ระบบอัตโนมัติที่มองเห็น Telegram ในแบบเดียวกับที่คนมองเห็น นั่นคือผ่านอินเทอร์เฟซของแอปพลิเคชัน

ระดับที่ 1 UI Automation: การควบคุมอินเทอร์เฟซ Telegram

Cloud Phone คืออะไร?

Cloud Phone คืออุปกรณ์ Android เสมือนที่ทำงานอยู่บนคลาวด์ มันจำลองสมาร์ทโฟนจริงๆ มีระบบปฏิบัติการ สภาพแวดล้อม และข้อมูลลายนิ้วมือเครื่อง (fingerprint) เป็นของตัวเอง ผู้ใช้สามารถติดตั้งแอปพลิเคชัน เปิดใช้งาน และโต้ตอบได้เหมือนใช้โทรศัพท์จริงๆ

FlashID ให้บริการ Cloud Phone ประเภทนี้และอนุญาตให้ผู้ใช้จัดการอุปกรณ์ Android หลายเครื่องพร้อมกันได้

Window Sync ทำงานอย่างไร

Window Sync จะซิงโครไนซ์การดำเนินการระหว่างหน้าต่างเบราว์เซอร์และ Cloud Phone การกระทำต่างๆ เช่น การพิมพ์ การคลิก การนำทาง และการเลื่อน จะทำในหน้าต่างเดียวและถูกทำซ้ำในสภาพแวดล้อมที่เลือก

สำหรับ Cloud Phone นี่หมายถึงการควบคุมอินสแตนซ์และแอปพลิเคชัน Android หลายตัว รวมถึง Telegram

ในทางปฏิบัติ Window Sync เป็นเครื่องมือกึ่งอัตโนมัติ (semi-automation) มากกว่าการเป็นระบบอัตโนมัติที่ใช้สคริปต์เต็มรูปแบบ: ผู้ควบคุมยังคงควบคุมกระบวนการแบบเรียลไทม์ ในขณะที่ระบบจะทำซ้ำการกระทำเดียวกันในสภาพแวดล้อมต่างๆ

ทำไมถึงเป็นการควบคุมอินเทอร์เฟซ (Interface Automation)

UI automation ควบคุมสิ่งที่แสดงบนหน้าจอ โดยการ:

• เปิดแอปพลิเคชัน
• คลิกองค์ประกอบต่างๆ ในอินเทอร์เฟซ
• ป้อนข้อความ
• เลื่อนหน้าจอ
• ทำซ้ำการดำเนินการในสภาพแวดล้อม Android ที่เลือก

มันไม่ใช่ Telegram API และไม่ได้เรียกใช้เมธอดของ Telegram โดยตรง

UI Automation มีประโยชน์เมื่อใด

แนวทางนี้เหมาะสมสำหรับ:

• กระบวนการที่มีให้ใช้งานผ่านแอป Android เท่านั้น
• การควบคุมหน้าจอที่ไม่เป็นมาตรฐานด้วยตนเอง
• การตั้งค่าบัญชีในเบื้องต้น
• การจัดการกับสิทธิ์การเข้าถึงระบบ
• การตรวจสอบผลลัพธ์ด้วยสายตา
• การดำเนินการที่ผู้ควบคุมต้องเห็นและยืนยันทุกขั้นตอน
• การทำซ้ำการกระทำที่เหมือนกันในสภาพแวดล้อมที่ซิงโครไนซ์หลายเครื่อง

สิ่งที่ UI Automation ไม่รู้เกี่ยวกับ Telegram

Window Sync ทำงานกับการกระทำที่เป็นอินเทอร์เฟซที่มองเห็นได้ มันเลียนแบบการพิมพ์ การคลิก และการเลื่อน แต่ไม่ได้ตีความสถานะภายในของแต่ละเซสชัน Telegram หรือเลือกเส้นทางขั้นตอนการทำงานที่ต่างกันสำหรับแต่ละบัญชี

ด้วยตัวมันเอง UI automation ไม่รู้ว่า:

• บัญชี Telegram ไหนเปิดอยู่
• บัญชีถูกจำกัดการใช้งาน (restricted) หรือไม่
• บัญชีอยู่ในแชทที่ต้องการแล้วหรือยัง
• การกระทำก่อนหน้าโหลดเสร็จสิ้นหรือยัง
• บัญชีพบกับไดอะล็อกระบบปกติอื่นๆ หรือไม่
• งานของ Telegram เสร็จสมบูรณ์ในระดับเซิร์ฟเวอร์หรือไม่
• ผลลัพธ์ใดที่ควรถูกบันทึกในสถิติ

UI automation มีประสิทธิภาพเมื่อการดำเนินการต้องผ่านแอปพลิเคชันและอินเทอร์เฟซยังอยู่ในสถานะที่คาดการณ์ไว้ อย่างไรก็ตาม สิ่งที่มันควบคุมยังคงเป็น “หน้าจอ” ไม่ใช่เซสชัน Telegram ที่แสดงผลเป็นเอนทิตีที่มีโครงสร้าง

เมื่อทีมต้องการผู้ร่วมสนทนาอัตโนมัติแทนที่จะเป็นหน้าจออัตโนมัติ แนวทางที่สองจึงเข้ามามีบทบาท: คือ Bot API

ระดับที่ 2 Bot API: ระบบอัตโนมัติสำหรับบัญชี Telegram พิเศษ

Telegram Bot คืออะไร?

Telegram นิยามบอทว่าเป็นบัญชีพิเศษที่ควบคุมโดยซอฟต์แวร์ซึ่งไม่ต้องการหมายเลขโทรศัพท์แยกต่างหาก รหัสของบอทมักจะรันบนเซิร์ฟเวอร์ภายนอก ในขณะที่ Telegram จะส่งเหตุการณ์ (events) ไปหาผ่าน webhook หรือ getUpdates

การอนุญาตสิทธิ์ (Authorization) ของ Bot API จะใช้โทเค็น (token) ที่เป็นเอกลักษณ์ คำขอจะถูกส่งผ่าน HTTPS ไปยังเมธอดของ Bot API และรับคำตอบกลับมาในรูปแบบ JSON ซึ่งแตกต่างอย่างสิ้นเชิงจากการลงชื่อเข้าใช้ในฐานะผู้ใช้ด้วยหมายเลขโทรศัพท์ รหัสยืนยัน และ 2FA

โทเค็นของบอทไม่สามารถใช้แทนเซสชันของผู้ใช้ Telegram ได้ มันเป็นข้อมูลประจำตัวของตัวตนคนละแบบที่มีโมเดลการอนุญาตสิทธิ์ต่างกัน

งานที่ Bot API จัดการได้ดี

Bot API มีเอกสารประกอบครบถ้วนและออกแบบมาเพื่อสร้าง:

• แชทบอท (Chatbots)
• ระบบบริการลูกค้า
• ระบบส่งการแจ้งเตือน
• เมนูและปุ่มกดต่างๆ
• Mini Apps
• ระบบชำระเงิน
• การจัดการกลุ่มและช่องทาง (เมื่อมีสิทธิ์ตามที่กำหนด)
• การโต้ตอบกับผู้ใช้ที่เป็นฝ่ายเริ่มติดต่อกับบอทก่อน

ข้อจำกัดของ Bot API

Telegram แนะนำว่าบอทควรส่งข้อความไม่เกินประมาณ 1 ข้อความต่อวินาทีในแชทเดียว สำหรับกลุ่ม ขีดจำกัดที่ระบุคือไม่เกิน 20 ข้อความต่อนาที ในขณะที่การส่งแจ้งเตือนจำนวนมาก (bulk) จะจำกัดอยู่ที่ประมาณ 30 ข้อความต่อวินาที หากเกินขีดจำกัดเหล่านี้ Bot API จะเริ่มแจ้งข้อผิดพลาด 429

Telegram ยังรองรับการแพร่ภาพแบบชำระเงิน (paid broadcasts): เมื่อเข้าเงื่อนไขที่กำหนด บอทสามารถส่งข้อความได้สูงสุด 1,000 ข้อความต่อวินาทีโดยชำระค่าปริมาณผ่าน Telegram Stars ฟีเจอร์นี้มีไว้สำหรับการบรอดแคสต์ไปยังผู้ติดตามของบอทโดยเฉพาะ ไม่ได้เปลี่ยน Bot API ให้กลายเป็นระบบจัดการบัญชีผู้ใช้ปกติ

แม้ในโมเดลบอทอย่างเป็นทางการ การขยายขนาด (scaling) ก็ไม่ได้ทำโดยการเลียนแบบบัญชีผู้ใช้หลายร้อยบัญชี แต่ทำผ่านโมเดลแพลตฟอร์มแยกต่างหากที่มีกฎและขีดจำกัดเป็นของตัวเอง

Business Bots เปลี่ยนเส้นแบ่งระหว่างบอทและผู้ใช้

ในปี 2024 Telegram Business อนุญาตให้ผู้ใช้เชื่อมต่อแชทบอทเพื่อประมวลผลและตอบกลับข้อความในนามของตนเอง เจ้าของบัญชีสามารถเลือกได้ว่าจะให้บอทเข้าถึงแชทไหนได้บ้าง

ในเดือนพฤษภาคม 2026 Telegram ได้ขยายโมเดลนี้เป็น “Chat Automation” ในการตั้งค่าโปรไฟล์ ขณะนี้ผู้ใช้ทุกคนสามารถเชื่อมต่อบอทเข้ากับโปรไฟล์ของตนและกำหนดค่าการเข้าถึงแชทได้ ตั้งแต่วันที่ 8 พฤษภาคม 2026 ไม่จำเป็นต้องเป็นสมาชิก Premium ก็สามารถเชื่อมต่อ Business Bot ได้

ในทางเทคนิค การโต้ตอบจะเกิดขึ้นผ่านการเชื่อมต่อทางธุรกิจ (business connection) บอทจะได้รับ connection_id แยกต่างหาก ชุดของสิทธิ์ และการตั้งค่าผู้รับ

ผ่านการเชื่อมต่อที่ได้รับอนุญาต Business Bot สามารถใช้เมธอดที่รองรับเพื่อส่งและแก้ไขข้อความ ทำเครื่องหมายประวัติแชทว่าอ่านแล้ว แก้ไขข้อมูลโปรไฟล์ ทำงานกับสื่อ ปักหมุดข้อความ และการดำเนินการอื่นๆ อีกมากมาย

อย่างไรก็ตาม มีข้อจำกัดที่สำคัญ สิทธิ์ can_reply อนุญาตให้บอทธุรกิจที่เชื่อมต่อส่งและแก้ไขข้อความได้เฉพาะในแชทส่วนตัวที่ได้รับข้อความขาเข้าภายใน 24 ชั่วโมงก่อนหน้าเท่านั้น

ดังนั้นจึงไม่ถูกต้องนักหากจะบอกว่า Bot API ไม่สามารถดำเนินการแทนผู้ใช้ได้เลย แต่มันเป็นการดำเนินการที่จำกัดผ่านโมเดลการเชื่อมต่อธุรกิจซึ่งมีตัวบ่งชี้ สิทธิ์ และรายการเมธอดที่รองรับเฉพาะ — ไม่ใช่เซสชันของผู้ใช้เต็มรูปแบบ

เมื่อเป้าหมายไม่ใช่การมอบหมายงานบางอย่างให้บอท แต่เป็นการทำงานร่วมกับบัญชีผู้ใช้ที่สมบูรณ์ในฐานะ Telegram client ระดับที่ 3 จึงถูกนำมาใช้: นั่นคือ MTProto

ระดับที่ 3 MTProto: ระบบอัตโนมัติสำหรับ User Session ที่สมบูรณ์

MTProto คืออะไร?

MTProto คือโปรโตคอลที่ Telegram client ใช้ สำหรับนักพัฒนาภายนอก Telegram ได้จัดเตรียม TDLib ซึ่งเป็น library ของไคลเอนต์ข้ามแพลตฟอร์มที่มีฟีเจอร์ครบถ้วน จัดการเรื่องการสื่อสารเครือข่าย การเข้ารหัส การจัดเก็บข้อมูลในเครื่อง และความสอดคล้องของข้อมูล

การยืนยันตัวตน User Client ทำอย่างไร

User client ไม่ได้ยืนยันตัวตนด้วยโทเค็นจาก BotFather แต่ใช้ในลักษณะเดียวกับบัญชี Telegram ปกติ:

• ใช้ api_id และ api_hash
• หมายเลขโทรศัพท์
• รหัสยืนยันตัวตน
• 2FA (หากต้องการ)
• คีย์ที่จัดเก็บและข้อมูลเซสชัน

Telegram จะเชื่อมโยงการยืนยันตัวตนเข้ากับ auth_key_id ของไคลเอนต์ หลังจากผ่านการรับรองแล้ว ไคลเอนต์สามารถเรียกใช้เมธอดที่มีให้สำหรับบัญชีผู้ใช้ได้โดยไม่ต้องขอรหัสใหม่ทุกครั้งที่เริ่มทำงาน

คำทางเทคนิคที่ถูกต้องคือ Telegram user client แบบอัตโนมัติ คำว่า “Userbot” ยอมรับได้ว่าเป็นคำเรียกทั่วไป แต่สิ่งสำคัญคือต้องเข้าใจว่านี่ไม่ใช่บัญชีบอท แต่มันคือบัญชีผู้ใช้ปกติที่ถูกควบคุมผ่านไลบรารีไคลเอนต์

User Client สามารถทำอะไรได้บ้าง

Telegram แยกรายการเมธอดออกจากกัน: เมธอดสำหรับผู้ใช้เท่านั้น สำหรับบอทเท่านั้น และเมธอดผ่านการเชื่อมต่อธุรกิจ

User client สามารถทำงานร่วมกับเอนทิตีที่บัญชีที่ได้รับอนุญาตมองเห็นได้ โดยขึ้นอยู่กับสิทธิ์ การตั้งค่าความเป็นส่วนตัว และข้อจำกัดของเซิร์ฟเวอร์ นี่คือเหตุผลที่ MTProto ถูกเลือกสำหรับสถานการณ์ที่ต้องการให้ระบบ:

• ดำเนินการในนามของบัญชีปกติ
• ทำงานกับช่องทางและกลุ่มที่เข้าถึงได้
• อ่านบทสนทนา
• ใช้เมธอดดั้งเดิมของผู้ใช้ (native user methods)
• ตั้งเวลาส่งข้อความ
• เผยแพร่สตอรี่ (Stories) จากโปรไฟล์ผู้ใช้
• ประมวลผลเหตุการณ์เพิ่มเติมของ Telegram

ทำไม MTProto ถึงเป็นมากกว่าแค่ API อื่น

การทำงานกับ MTProto ต้องใช้โครงสร้างพื้นฐานที่มีสถานะ (stateful infrastructure):

• การยืนยันตัวตนแยกต่างหาก
• คีย์เซสชัน
• การจัดเก็บข้อมูลในพื้นที่
• แคชของเอนทิตี
• การอัปเดตต่างๆ
• ข้อผิดพลาด RPC
• การจัดการการเข้าถึงพร้อมกัน
• การกู้คืนหรือการเพิกถอนเซสชัน
• ขีดจำกัดทางฝั่งเซิร์ฟเวอร์

ความแตกต่างหลักคือ: ใน Bot API ทรัพย์สินหลักคือโทเค็นบอท แต่ในระบบอัตโนมัติของบัญชีผู้ใช้ ทรัพย์สินหลักคือ “เซสชัน Telegram”

Session File คืออะไร?

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

Telethon ยังจัดเก็บข้อมูลเกี่ยวกับเอนทิตีที่เคยพบก่อนหน้านี้ เช่น ผู้ใช้ แชท และช่องทาง ไว้ในเซสชัน เพื่อที่จะได้ไม่ต้องส่งคำขอที่ไม่จำเป็นไปยัง Telegram

เซสชันเป็นทรัพย์สินที่ละเอียดอ่อน: ใครก็ตามที่ได้ไฟล์ที่มีการรับรองสิทธิ์ที่ถูกต้องไป จะสามารถเข้าถึงบัญชีนั้นได้

การเข้าถึงเซสชันพร้อมกัน

เมื่อทำงานกับไฟล์เซสชัน อาจเกิดข้อผิดพลาด sqlite3.OperationalError: database is locked สิ่งนี้เกิดขึ้นเมื่อมีการใช้เซสชันเดียวกันโดยไคลเอนต์สองตัวขึ้นไปพร้อมกัน วิธีที่แนะนำคือการใช้เซสชันแยกกันสำหรับแต่ละไคลเอนต์

ในระดับเซิร์ฟเวอร์ Telegram จะมีข้อผิดพลาด AUTH_KEY_DUPLICATED ซึ่งเกิดขึ้นเมื่อเซสชันที่ได้รับอนุญาตส่งคำขอพร้อมกันผ่านการเชื่อมต่อ TCP หลักเกินจำนวนที่อนุญาต ในกรณีนี้ คีย์อาจถูกยกเลิก

การขยายขนาด MTProto ไม่ได้ง่ายเพียงแค่คัดลอกไฟล์เซสชันเดียวไปยังหลายกระบวนการ ทีมต้องเข้าใจความแตกต่างระหว่างการยืนยันตัวตน Telegram, เซสชัน MTProto, การจัดเก็บเซสชันในเครื่อง และการเชื่อมต่อพร้อมกัน

ข้อผิดพลาดเป็นเรื่องปกติของการทำงาน

เอกสารทางการของ Telegram ระบุไว้อย่างชัดเจนว่า: ข้อผิดพลาดจะเกิดขึ้นเมื่อทำงานกับ API และไคลเอนต์ต้องจัดการให้ถูกต้อง

FLOOD_WAIT_X หมายความว่าจำนวนครั้งที่อนุญาตสูงสุดในการเรียกใช้เมธอดล้นขีดจำกัดแล้ว และไคลเอนต์ต้องรอตามจำนวนวินาทีที่ระบุ นี่คือข้อจำกัดทางฝั่งเซิร์ฟเวอร์ ไม่ใช่ข้อผิดพลาดของอินเทอร์เฟซหรือความล้มเหลวของไลบรารี MTProto

การเพิ่มจำนวนการทำงานพร้อมกัน (concurrency) ไม่ได้ช่วยกำจัด FloodWaitError การทำงานขนานกันมีแต่จะทำให้ระบบเข้าใกล้ขีดจำกัดเร็วขึ้นเท่านั้น

การมี API อย่างเป็นทางการไม่ได้หมายความว่าทุกสถานการณ์จะเป็นที่ยอมรับ

Telegram ยินดีกับการพัฒนาไคลเอนต์ของบุคคลที่สาม แต่เงื่อนไข API (API Terms) กำหนดว่าแอปพลิเคชันต้องไม่ดำเนินการในนามของผู้ใช้โดยที่ผู้ใช้ไม่ทราบและไม่ยินยอม

Telegram ยังเตือนด้วยว่าไคลเอนต์ API จะถูกตรวจสอบอย่างใกล้ชิดเพื่อป้องกันการใช้งานในทางที่ผิด การใช้ API เพื่อระดมส่งข้อความ (flooding), สแปม หรือการปั๊มยอดต่างๆ อย่างผิดธรรมชาติ อาจส่งผลให้ถูกแบนถาวร

การเลือกใช้ UI automation, Bot API หรือ MTProto ไม่ได้อยู่เหนือกฎของ Telegram ทั้งไคลเอนต์ Android ทางการ API ทางการ หรือซอฟต์แวร์เฉพาะทาง ไม่ได้ทำให้สถานการณ์ที่ถูกห้ามกลายเป็นเรื่องยอมรับได้

ปัญหาที่แท้จริงไม่ได้เริ่มที่การล็อกอินครั้งแรก แต่เริ่มที่เซสชันที่ร้อย

ไคลเอนต์ MTProto ตัวเดียวสามารถสร้างได้บนไลบรารี แต่เมื่อจำนวนบัญชีเพิ่มขึ้น ความท้าทายจะกลายเป็นเรื่องของการปฏิบัติงานพอๆ กับทางเทคนิค:

• แต่ละเซสชันถูกเก็บไว้ที่ไหน
• บัญชีไหนกำลังใช้งานอยู่
• เซสชันไหนถูกจำกัดหรือถูกเพิกถอน
• งานไหนกำลังทำงานอยู่
• การกระทำใดที่เสร็จสิ้นแล้ว
• ข้อมูลประจำตัว 2FA และพารามิเตอร์เพิ่มเติมถูกเก็บไว้ที่ไหน
• บัญชีที่ระบุสามารถใช้ในงานถัดไปได้หรือไม่
• แต่ละบัญชีดำเนินการไปแล้วกี่ครั้ง
• จะจัดการกับ FLOOD_WAIT, ข้อผิดพลาดในการยืนยันตัวตน และข้อจำกัดต่างๆ อย่างไร
• จะป้องกันไม่ให้เริ่มเซสชันเดียวกันในลักษณะที่ขัดแย้งกันในหลายกระบวนการได้อย่างไร

การสร้างไคลเอนต์ MTProto ไม่ได้เหมือนกับการสร้างระบบสำหรับจัดการไคลเอนต์ Telegram จำนวนมาก

สิ่งที่ต้องสร้างเพิ่มเติมรอบๆ ไลบรารี MTProto มาตรฐาน

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

• การจัดเก็บเซสชัน
• การผูกบัญชีเข้ากับพารามิเตอร์และพร็อกซี
• คิวงาน (Task queue)
• การควบคุมการดำเนินการพร้อมกัน
• การจัดการข้อผิดพลาด RPC
• สถานะบัญชี
• ตัวจัดการการลองใหม่ (Retry logic)
• บันทึกผลลัพธ์ (Results log)
• การกระจายโหลด (Load distribution)
• อินเทอร์เฟซสำหรับผู้ควบคุม
• การนำเข้าและส่งออกรูปแบบไฟล์
• การรายงานผล

Telegram Expert: ไม่ใช่ระบบอัตโนมัติประเภทที่ 4 แต่เป็นระบบสำเร็จรูปสำหรับจัดการ MTProto Workflows

Telegram Expert ทำงานในระดับที่ต่างออกไปและช่วยจัดการงานที่เกิดขึ้นเมื่อต้องควบคุมบัญชี Telegram จำนวนมากจากส่วนกลาง

ผลิตภัณฑ์ประกอบไปด้วย:

• แผงควบคุมบัญชี
• โฟลเดอร์และสถานะต่างๆ
• การตรวจสอบบัญชีแบบเป็นกลุ่ม (bulk checking)
• การจัดการเซสชัน
• รองรับรูปแบบ Session, JSON และ TData
• ดำเนินการที่ทำด้วยบัญชีผู้ใช้
• การจัดการบทสนทนา
• รายชื่อติดต่อ
• ข้อความ
• การจัดการกลุ่มเป้าหมาย
• รายงาน
• การติดตามจำนวนการกระทำที่เสร็จสมบูรณ์
• พร็อกซีและการตรวจสอบพูลพร็อกซี

ใน Telegram Expert บัญชีสามารถถูกจัดกลุ่มไว้ที่ลาง เช่น กลุ่มที่กำลังใช้งาน, ถูกจำกัดชั่วคราว, ถูกจำกัดถาวร, ถูกระงับ, Premium, เก็บถาวร และลบแล้ว การตรวจสอบแบบกลุ่มช่วยให้สามารถยืนยันบัญชีและย้ายไปยังโฟลเดอร์ต่างๆ ตามผลลัพธ์ได้

มูลค่าหลักของแผงควบคุมไม่ใช่แค่การแสดงรายชื่อบัญชี แต่มันช่วยป้องกันไม่ให้ผู้ควบคุมใช้ไฟล์เซสชันที่ไม่เหมาะสมมาทำงาน

Telegram Expert เข้าใจ “งาน” ไม่ใช่แค่ “พิกัดปุ่ม”

Telegram Expert รับคำสั่งงานในระดับของขั้นตอนการทำงาน Telegram (Telegram workflow):

• ตรวจสอบบัญชีที่เลือก
• อ่านข้อความที่ยังไม่ได้อ่าน
• ดำเนินการโดยใช้เซสชันที่เหมาะสม
• บันทึกผลลัพธ์
• แยกบัญชีที่มีปัญหาออกมา
• สร้างสถิติ

ทำไม Session, JSON และ TData ถึงกลายเป็นชั้นโครงสร้างพื้นฐานแยกต่างหาก

รูปแบบของบัญชีไม่ใช่แค่ไฟล์ประกอบฉาก

ใน Telegram Expert:

• ตัวสร้าง JSON จะสร้างไฟล์ JSON ที่หายไปหรือเสียหายสำหรับ Session
• ตัวแปลง (converter) จะแปลงบัญชีจาก Session เป็น TData และข้ามกลับไปมาได้
• ตัวทำซ้ำ (duplicator) จะสร้างเซสชันสำหรับทั้งมือถือและคอมพิวเตอร์
• แผงควบคุมจะจัดการบัญชีและเซสชันจากส่วนกลาง

Cloud Phone ทำงานเพื่อเก็บสภาพแวดล้อมมือถือ ส่วน Session หรือ TData คือตัวแทนการยืนยันตัวตนของ Telegram client สำหรับทีมงาน สิ่งสำคัญไม่เพียงแค่การรักษาแต่ละส่วนประกอบไว้ แต่คือการย้ายบัญชีไปมาระหว่างรูปแบบที่จำเป็นสำหรับงานเฉพาะหน้า

การควบคุมผลลัพธ์สำคัญกว่าการเริ่มงาน

การซิงโครไนซ์ UI แสดงให้เห็นชัดเจนว่าการกระทำได้เริ่มขึ้นแล้ว อย่างไรก็ตาม ระบบอัตโนมัติระดับมืออาชีพจะต้องตอบได้ว่า:

• มีกี่บัญชีที่เริ่มทำงาน
• มีกี่บัญชีที่ทำงานเสร็จสมบูรณ์
• มีกี่บัญชีที่พบข้อผิดพลาด
• แต่ละบัญชีดำเนินการไปแล้วกี่ครั้ง
• ข้อมูลส่วนไหนควรถูกคัดออกหรือรวมเข้าด้วยกัน
• บัญชีใดที่ไม่ควรถูกจ่ายงานให้อีก

Telegram Expert มีเครื่องมือสร้างรายงาน การรวมฐานข้อมูล และเครื่องคิดเลขที่ติดตามจำนวนการกระจายเสียง (broadcasts) และการเชิญ (invites) ของแต่ละบัญชี

FlashID และ Telegram Expert ครอบคลุมขั้นตอนคนละส่วน

FlashID:

• มอบ Android Cloud Phone แยกเครื่อง
• แยกสภาพแวดล้อมมือถือออกจากกัน
• ช่วยให้เปิดแอป Telegram ได้
• ซิงโครไนซ์การคลิก การพิมพ์ และการเลื่อนหน้าจอ
• ช่วยทีมจัดการกลุ่มอุปกรณ์มือถือ

Telegram Expert:

• จัดการเซสชันผู้ใช้ Telegram
• ติดตามสถานะบัญชี
• ปฏิบัติงานเฉพาะทางของ Telegram
• กระจายภาระงาน
• บันทึกผลลัพธ์
• รักษาไฟล์รูปแบบ Session, JSON และ TData

FlashID จัดการสภาพแวดล้อมและหน้าจอ ส่วน Telegram Expert จัดการบัญชี Telegram ในฐานะหน่วยปฏิบัติการ

ในขณะที่ Bot API ยังคงเป็นเครื่องมือแยกต่างหากสำหรับแชทบอท, Mini Apps, ขั้นตอนการบริการลูกค้า และสถานการณ์ทางธุรกิจที่ได้รับอนุญาต

บทสรุป

ไม่มีแนวทางใดในสามแบบนี้ที่สามารถใช้แทนกันได้ทั้งหมด

1. Cloud Phone จำเป็นเมื่อกระบวนการต้องรันผ่านแอปมือถือเท่านั้น
2. Bot API เหมาะสมเมื่อบริษัทต้องการผู้ร่วมทำงานที่เป็นซอฟต์แวร์แยกต่างหากใน Telegram หรือระบบอัตโนมัติสำหรับแชทธุรกิจที่ได้รับสิทธิ์
3. MTProto จำเป็นเมื่อระบบต้องทำงานร่วมกับเซสชันผู้ใช้ที่สมบูรณ์

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