Perplexity เท MCP: 4 เหตุผลที่ทีมเทคฯ ไทยต้องรื้อแผนสร้าง AI Agent ใหม่ด้วยสถาปัตยกรรม A2A

เห็นข่าวที่กำลังเป็นที่ถกเถียงกันอย่างดุเดือดในกลุ่ม Slack ของนักพัฒนาชาวไทยเมื่อเช้านี้ไหมครับ? การที่ Perplexity เพิ่งประกาศถอยทัพจากเฟรมเวิร์กที่คนทั้งวงการเคยมองว่าเป็นมาตรฐานอย่าง <em>Model Context Protocol</em> (MCP) ถือเป็นการส่งสัญญาณเปิดศึกสงคราม **<strong>AI Agent Protocol</strong>** ในปี 2026 อย่างเป็นทางการเลยทีเดียวครับ

ถ้าคุณเป็น CTO, Tech Lead หรือผู้ก่อตั้งธุรกิจที่กำลังอ่านบทความนี้ระหว่างจิบกาแฟยามเช้า ผมอยากให้คุณหยุดคิดสักนิดครับ ตลอดปีที่ผ่านมา พวกเราในวงการเทคฯ ไทยแทบจะยกให้ MCP เป็นคัมภีร์ศักดิ์สิทธิ์ในการสร้างเครื่องมือ AI ภายในองค์กร แต่การที่บริษัทยักษ์ใหญ่อย่าง Perplexity หันหัวเรือหนีและเทน้ำหนักไปที่สถาปัตยกรรมแบบ A2A (Agent-to-Agent) แทน มันกำลังบอกอะไรเรา? และที่สำคัญที่สุด แผนพัฒนา AI ของบริษัทคุณในปีนี้กำลังเดินมาถูกทาง หรือกำลังสร้าง Technical Debt ก้อนมหึมากันแน่?

มาคุยกันแบบเจาะลึกครับ ว่าสถาปัตยกรรมทั้งสองแบบนี้ต่างกันอย่างไร และทำไมธุรกิจไทย โดยเฉพาะกลุ่ม E-commerce และสถาบันการเงิน ถึงต้องตัดสินใจเลือกข้างตั้งแต่วันนี้

## ทำความเข้าใจก่อนว่าทำไม Perplexity ถึงเลือกเดินหันหลังให้ MCP

เพื่อให้เห็นภาพตรงกัน เรามาทบทวนกันสั้นๆ ครับว่า **Model Context Protocol (MCP)** คืออะไร ถ้าพูดแบบภาษาคนทำงานเลย MCP คือมาตรฐานที่ Anthropic (ผู้สร้าง Claude) พยายามผลักดันให้เป็น Universal Plug สำหรับ AI มันคือสถาปัตยกรรมแบบ Client-Server หรือแบบ "ศูนย์รวมอำนาจ" (Centralized) คุณมีโมเดล AI ตัวแม่หนึ่งตัว และคุณก็ใช้ MCP เป็นสะพานให้ AI ตัวแม่นั้นวิ่งไปดึงข้อมูลจาก Database (เช่น PostgreSQL ของคุณ), ดึงข้อมูลจาก GitHub, หรืออ่านไฟล์จาก Google Drive

ฟังดูดีใช่ไหมครับ? จัดการง่าย ควบคุมง่าย แล้วทำไม Perplexity ถึงถอยล่ะ?

เหตุผลก็คือ "คอขวดของบริบท" (Context Bottleneck) ครับ Perplexity พบว่าเมื่อคุณต้องสืบค้นข้อมูลที่ซับซ้อนมากๆ และดึงข้อมูลจากหลายแหล่งพร้อมกัน การโยนทุกอย่างกลับไปให้ AI ตัวแม่เพียงตัวเดียวประมวลผล มันทำให้เกิดอาการ "หลอน" (Hallucination) ได้ง่ายขึ้น เปลือง Token มหาศาล และจำกัดความสามารถในการให้ AI หลายๆ ตัวทำงานร่วมกัน

นั่นทำให้แนวคิด **<em>A2A Architecture</em>** เริ่มผงาดขึ้นมา แทนที่จะใช้ AI ตัวเดียวทำทุกอย่าง A2A คือการสร้างฝูง AI Agents (Swarm) ที่เชี่ยวชาญเฉพาะด้านมาคุยกันเองแบบ Peer-to-Peer ลองนึกภาพว่าคุณมี Agent ฝ่ายขาย, Agent ฝ่ายบัญชี, และ Agent ฝ่ายคลังสินค้า แต่ละตัวมีสมองเป็นของตัวเอง แล้วส่งข้อความคุยกันเพื่อแก้ปัญหาให้ลูกค้า

## กรณีศึกษา: ระบบ Customer Service ของ Retailer ไทยบน LINE OA

เพื่อให้เห็นภาพชัดเจนที่สุดสำหรับ **Thai Enterprise Tech** เรามาเจาะลึกกรณีศึกษาที่ผมเชื่อว่าเกือบทุกองค์กรในไทยต้องเจอ นั่นคือการเชื่อมต่อ AI เข้ากับ LINE Official Account

สมมติว่า "SiamMart" (ชื่อสมมติ) เป็นแบรนด์ค้าปลีกขนาดใหญ่ที่มีลูกค้าทัก LINE วันละ 50,000 ข้อความ ลูกค้าคนหนึ่งทักมาว่า: *"สวัสดีค่ะ อยากทราบว่ารองเท้าวิ่งรุ่น X สีดำไซส์ 42 ที่สาขาเซ็นทรัลเวิลด์ยังมีของไหมคะ? แล้วถ้าเอาแต้มสมาชิกไปแลกจะลดได้เท่าไหร่?"*

นี่คือคำถามปราบเซียน เพราะ AI ต้องเช็คระบบ Inventory (ERP) และเช็คระบบ CRM เพื่อดูแต้มสะสมพร้อมกัน

### ทางเลือกที่ 1: การแก้ปัญหาด้วย MCP (The Monolithic Approach)

ถ้า SiamMart เลือกใช้ MCP พวกเขาจะใช้ Claude 3.5 Sonnet เป็นสมองหลักตัวเดียว เชื่อมต่อกับเซิร์ฟเวอร์ MCP ภายในองค์กร

**กระบวนการทำงาน:**
1. ลูกค้าพิมพ์ข้อความเข้ามาใน LINE
2. ข้อความถูกส่งไปที่ Claude
3. Claude อ่านคำถาม แล้วใช้ MCP ยิงคำสั่งไปที่ระบบ SAP (เพื่อเช็คสต็อก) และ Salesforce (เพื่อเช็คแต้ม CRM)
4. เซิร์ฟเวอร์ภายในองค์กรส่งข้อมูลดิบกลับไปให้ Claude
5. Claude ประมวลผลและตอบกลับลูกค้า

**ข้อดี:** พัฒนาง่ายมาก โค้ดมีโครงสร้างที่ชัดเจน เป็นระเบียบเหมือนเราเขียน REST API
**จุดอ่อนสำหรับธุรกิจไทย:** ปัญหาเรื่องความหน่วง (Latency) ครับ ทุกครั้งที่ Claude เรียกขอข้อมูล มันต้องวิ่งข้ามทวีปไปกลับสหรัฐอเมริกา และปัญหาใหญ่กว่านั้นคือ คุณถูกผูกขาดกับ Anthropic Ecosystem ถ้าวันไหน API ของล่ม ระบบ LINE OA ของคุณก็จะกลายเป็นอัมพาตทันที

### ทางเลือกที่ 2: การแก้ปัญหาด้วย A2A (The Decentralized Swarm)

ถ้า SiamMart มองเกมขาดเหมือน Perplexity พวกเขาจะวางสถาปัตยกรรมแบบ **A2A Architecture** แทน โดยอาจจะใช้เฟรมเวิร์กอย่าง CrewAI หรือ AutoGen

**กระบวนการทำงาน:**
1. ข้อความใน LINE เข้ามาหา **Router Agent** (ตัวนี้อาจจะรันโมเดลขนาดเล็กในไทยอย่าง SeaLLM หรือ Llama 3 8B เพื่อประหยัดเงินและได้ความเร็วสูงสุด)
2. Router Agent วิเคราะห์คำถาม แล้วแยกงานส่งไปให้ **Inventory Agent** และ **CRM Agent**
3. Inventory Agent (ซึ่งอาจจะเป็นแค่โมเดลเล็กๆ ที่เก่งแต่เรื่องรัน SQL) ไปดึงข้อมูลสต็อก
4. CRM Agent ไปเช็คแต้มสะสม
5. Agent ทั้งสองตัวส่งข้อมูลสรุปกลับมาให้ **Synthesizer Agent** (ตัวนี้อาจจะใช้ GPT-4o หรือ Claude เพื่อเรียบเรียงภาษาให้สละสลวย)
6. ตอบกลับลูกค้าผ่าน LINE

**ทำไมสิ่งนี้ถึงสำคัญ?** ความคล่องตัวครับ! คุณสามารถสลับโมเดลได้ตามใจชอบ Agent ตัวไหนทำงานง่ายๆ ก็ใช้โมเดลฟรี Agent ตัวไหนที่ต้องรับมือกับข้อมูลลูกค้าอ่อนไหว (PII) คุณก็สามารถรันแบบ On-premise ในเซิร์ฟเวอร์ที่กรุงเทพฯ ได้เลย นี่แหละคือเหตุผลที่ A2A เป็นอนาคต

## ต้นทุนแฝงที่ไม่มีใครบอกคุณ (The Token Economics)

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

หากคุณใช้สถาปัตยกรรมแบบ MCP ทุกๆ ครั้งที่คุณโยน Context มหาศาลเข้าไปในโมเดลหลัก (เช่น โยนฐานข้อมูลลูกค้าทั้งตารางเข้าไปให้มันวิเคราะห์) คุณกำลังเผา Token อย่างบ้าคลั่ง ยิ่งบริบทยาว ค่าใช้จ่ายยิ่งทวีคูณ (Quadratic cost scaling ในบางโมเดล)

ในขณะที่การใช้ A2A สไตล์ Perplexity คุณสามารถสร้างการแบ่งแยกหน้าที่ (Separation of Concerns) ได้อย่างสมบูรณ์แบบ Agent ที่ทำหน้าที่ดึงข้อมูล ไม่จำเป็นต้องรู้ว่าลูกค้ากำลังคุยเรื่องอะไรอยู่ มันแค่รับคำสั่งเป็น JSON สั้นๆ ไปรัน แล้วส่งผลลัพธ์กลับมา การลดขนาด Context Window ในแต่ละ Node ช่วยประหยัดค่า API ได้สูงสุดถึง 40-60% ตามสถิติจากกรณีศึกษาขององค์กรระดับ Enterprise หลายแห่ง

แต่ช้าก่อนครับ... A2A ก็ไม่ได้มีแต่ข้อดีไปเสียหมด ข้อควรระวังที่ใหญ่ที่สุดคือ "จำนวนครั้งในการคุยกัน" (Chatter Latency) สมมติว่า Agent ของคุณต้องโยนข้อความไปมา 5 รอบกว่าจะได้คำตอบ หากรันผ่าน Cloud API ทั้งหมด ความหน่วงรวมอาจพุ่งไปถึง 10 วินาที ซึ่งสำหรับพฤติกรรมผู้บริโภคชาวไทยบน LINE ถือว่าช้าเกินไปจนพวกเขาอาจจะพิมพ์โวยวายซ้ำเข้ามาแล้ว

## PDPA และความปลอดภัย: ไพ่ตายที่ทำให้องค์กรไทยเลือก A2A

นอกจากเรื่องสถาปัตยกรรมทางเทคนิคแล้ว กฎหมายคุ้มครองข้อมูลส่วนบุคคล (PDPA) คือปัจจัยที่ทำให้ MCP อาจไม่ใช่ทางเลือกที่เซฟที่สุดสำหรับธนาคารหรือโรงพยาบาลในไทย

ลองคิดดูนะครับ MCP ถูกออกแบบมาเพื่อเอา Data ภายในองค์กรคุณ "ส่งออกไป" ให้โมเดลข้างนอกประมวลผล ถึงแม้จะมีมาตรการรักษาความปลอดภัย แต่การส่งประวัติการเงินหรือประวัติสุขภาพของลูกค้าชาวไทยออกไปยังเซิร์ฟเวอร์ต่างประเทศผ่าน API ของค่ายใหญ่ ย่อมทำให้ทีม Compliance ของคุณต้องกุมขมับ

แต่ด้วย A2A Architecture คุณสามารถกำหนดทิศทางการไหลของข้อมูลได้อย่างเบ็ดเสร็จ (Data Flow Control) คุณสามารถสร้าง "Sanitizer Agent" ที่รันแบบ Local ภายใน Data Center ของบริษัทคุณเอง เพื่อทำหน้าที่ลบชื่อ-นามสกุล และเบอร์โทรศัพท์ของลูกค้าออก (Anonymization) ก่อนที่จะส่งต่อให้ "Reasoning Agent" ที่รันอยู่บน Cloud สาธารณะประมวลผลต่อไป วิธีนี้ทำให้องค์กรสามารถใช้ประโยชน์จากความฉลาดของ AI ระดับโลกได้ โดยที่ไม่ต้องละเมิดหรือสุ่มเสี่ยงกับข้อกำหนดของ PDPA

## แผนที่นำทางปี 2026: ธุรกิจไทยควรเลือกทางไหน?

อ่านมาถึงตรงนี้ หลายคนคงตั้งคำถามในใจแล้วว่า "สรุปแล้วฉันควรลบโค้ด MCP ทิ้งแล้วไปเขียน A2A แทนเลยไหม?" คำตอบคือ ไม่จำเป็นต้องสุดโต่งขนาดนั้นครับ นี่คือ Roadmap ที่ผมอยากแนะนำให้ธุรกิจไทยนำไปปรับใช้:

1. **สำหรับ Tech Startup หรือ SME (ทีมงานไม่เกิน 50 คน):**
   ยังคงใช้ MCP ต่อไปได้ครับ ความเร็วในการนำผลิตภัณฑ์ออกสู่ตลาด (Time to Market) สำคัญที่สุดในช่วงนี้ MCP ช่วยให้คุณสร้าง AI ภายในบริษัทที่เชื่อมต่อกับ Google Workspace หรือ Notion ได้ภายในเวลาไม่กี่วัน อย่าเพิ่งไปทำให้ระบบซับซ้อนเกินจำเป็น

2. **สำหรับ Enterprise, Banking, E-commerce ขนาดใหญ่:**
   เริ่มกระบวนการ Transition สู่ A2A ทันทีครับ การถอยของ Perplexity คือสัญญาณเตือนภัย (Canary in the coal mine) คุณไม่ควรสร้างระบบ Mission Critical ขององค์กรโดยเอาชีวิตไปแขวนไว้กับ Protocol ของบริษัทใดบริษัทหนึ่ง เริ่มสร้าง Proof of Concept (PoC) เล็กๆ โดยใช้ AI หลายโมเดลทำงานร่วมกัน ทดสอบการทำ Routing ระหว่างโมเดลภาษาไทย (เพื่อคุยกับลูกค้า) และโมเดลขนาดใหญ่ (เพื่อตัดสินใจเชิงตรรกะ)

3. **พิจารณาสถาปัตยกรรมแบบ Hybrid:**
   ในท้ายที่สุดแล้ว MCP อาจถูกลดบทบาทลงไปเป็นแค่ "เครื่องมือชิ้นหนึ่ง" ที่ Agent ตัวใดตัวหนึ่งในเครือข่าย A2A ของคุณเรียกใช้ แทนที่จะเป็นแกนกลางหลักของระบบทั้งหมด

## บทสรุป

การที่ Perplexity ตัดสินใจทิ้งระยะห่างจาก MCP ไม่ใช่แค่ดราม่าในวงการซอฟต์แวร์ แต่มันคือการเปลี่ยนกระบวนทัศน์ (Paradigm Shift) ของสถาปัตยกรรมซอฟต์แวร์ระดับโลก สงคราม **AI Agent Protocol** เพิ่งจะเริ่มต้นขึ้นเท่านั้น ในยุคที่ AI ไม่ได้แค่ตอบคำถาม แต่ต้อง "ลงมือทำงาน" แทนมนุษย์ สถาปัตยกรรมที่คุณเลือกในวันนี้ จะเป็นตัวกำหนดว่าองค์กรของคุณจะสามารถสเกลระบบออโตเมชันได้ไกลแค่ไหนในอีก 3 ปีข้างหน้า

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

โชคดีกับการเขียนโค้ดครับทุกคน!