MCP 真的快要過時嗎？AI 智能體從逐一呼叫工具轉為編寫程式碼

โดย Nokka (นก-กา) | ตรวจข้อมูล 27 ต.ค. 2026

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

มีคลิปสั้นความยาว 79 วินาทีจากบัญชี @ducktate.com ขึ้นหัวว่า "Apparently MCP is obsolete for AI AGENTS" โพสต์เมื่อ 26 ต.ค. 2026 ยอดชมตอนที่ผมเช็กอยู่ที่ 17,673 ครั้ง กดใจ 615 คอมเมนต์ 18 [1]

คำกล่าวหานั้นแรงพอให้ต้องไปดูต้นทางว่าเขาพูดถึงอะไรกันแน่ ถ้าอ่านผิวเผิน คุณอาจเข้าใจว่า Model Context Protocol หมดอายุแล้ว และคิดจะทิ้งของที่ทีมลงทุนไปทั้งกอง

คำตอบสั้น ๆ คือ MCP ไม่ได้ตาย ตัวที่กำลังเปลี่ยนคือวิธีที่ agent ใช้มัน จากเดิมที่เรียกเครื่องมือทีละครั้ง ตอนนี้หันมาเขียนโค้ดที่เรียกหลายตัวในรอบเดียว

คลิปนี้พูดอะไร

ใจความที่ได้ยินจากเสียงในคลิปมีสามชั้น

ชั้นแรก เขาบอกว่าการที่ agent ต้องโหลดนิยามเครื่องมือทั้งหมดเข้า context แล้วเรียกทีละตัว ทำให้เปลืองโทเคนและช้า
ชั้นที่สอง ทางออกคือให้ agent เขียนโค้ดเพื่อเรียกเครื่องมือผ่าน API แล้วรันในแซนด์บ็อกซ์ ผลลัพธ์ตรงกลางไม่ต้องวิ่งผ่านโมเดล
ชั้นที่สาม เขาอ้างงานทดสอบของ AIMultiple ที่บอกว่าประหยัดโทเคนได้ราว 77% แต่ก็ยอมรับว่า latency สูงขึ้น และจำเป็นต้องมีแซนด์บ็อกซ์

สามข้อนี้ตรวจสอบได้ทั้งหมด และตรงกับเอกสารต้นทางจริง

ทำไมโทเคนถึงบวม

สองจุดที่ทำให้ context บวม

Anthropic อธิบายปัญหานี้ไว้ตรง ๆ ในบล็อกวิศวกรรมของตัวเอง [2] มีสองจุดที่ทำให้ค่าใช้จ่ายพุ่ง

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

จุดที่สองคือผลลัพธ์ระหว่างทาง สมมติคุณสั่งว่า "ดาวน์โหลดทรานสคริปต์ประชุมจากไดรฟ์แล้วแนบไปที่ลีดในระบบขาย" โมเดลต้องเรียกเครื่องมือหลายครั้ง และผลลัพธ์ทุกก้อนต้องผ่าน context ทั้งก้อน ประชุมสองชั่วโมงอาจกินโทเคนเพิ่มอีกห้าหมื่นตัว

Anthropic เล่าเคสหนึ่งว่า ถ้าให้ agent โหลดเฉพาะนิยามที่ต้องใช้จริงผ่านไฟล์แทนการโหลดทั้งหมด การใช้โทเคนลดจาก 150,000 เหลือ 2,000 โทเคน หรือประหยัด 98.7% [2]

ตัวเลขนี้ไม่ใช่ค่ากลางของทุกงาน แต่เป็นตัวอย่างที่ชัดว่าเพดานของการประหยัดอยู่ตรงไหน

ผลทดสอบจาก AIMultiple ที่คลิปอ้าง

ตัวเลขที่ได้จากการวัดจริง

AIMultiple ทดสอบเทียบสองแบบด้วยกัน [3] โดยใช้เซิร์ฟเวอร์ MCP ของ Bright Data โหมด Pro และใช้ GPT-4.1 เป็นโมเดล งานคือให้ agent เปิดหน้าเว็บที่กำหนดไว้แล้วดึงคำตอบสองข้อออกมา แต่ละงานรัน 50 รอบต่อวิธี

ผลที่ได้ออกมาดังนี้

อัตราความสำเร็จ 100% ทั้งสองแบบ
latency เฉลี่ย 9.66 วินาที (แบบเดิม) กับ 10.37 วินาที (แบบเขียนโค้ด) ช้าขึ้น 7%
input token เฉลี่ยต่อครั้ง 15,417 กับ 3,310 ลดลง 78.5%
output token เฉลี่ยต่อครั้ง 87 กับ 192 เพิ่มขึ้น 120%
โทเคนรวมทั้งงาน 775,197 กับ 175,081 ลดลง 77.4%

ตัวเลข 77% ในคลิปมาจากแถวสุดท้ายนี้ ไม่ใช่ตัวเลขจาก Anthropic และไม่ใช่ค่าที่การันตีว่าจะได้ทุกงาน

จุดที่น่าสนใจคือ output token เพิ่มขึ้นกว่าสองเท่า เพราะโมเดลต้องเขียนโค้ดแทนการเรียกเครื่องมือ การประหยัดจึงมาจากฝั่ง input เป็นหลัก

อีกจุดที่ต้องพูดให้ครบ หน้าเดียวกันนี้เปิดเผยว่าลูกค้าของบริการวัดผลด้าน MCP ของ AIMultiple มี Bright Data ซึ่งเป็นเจ้าของเซิร์ฟเวอร์ที่ใช้ทดสอบ อยู่ด้วย [3] ตัวเลขจึงควรอ่านเป็นผลจากผู้ให้บริการรายหนึ่ง ไม่ใช่การวัดที่เป็นกลางจากคนนอกทั้งหมด

ผู้ทดสอบเองก็ระบุจุดอ่อนไว้สามข้อ คือทดสอบคำถามเพียง 2 แบบ ใช้โมเดลเดียว และคุณภาพโค้ดขึ้นกับความสามารถเขียนโค้ดของโมเดล [3] ผมจึงยังไม่เห็นงานไหนที่ทดสอบกับเซิร์ฟเวอร์หลายสิบตัวพร้อมกันในเงื่อนไขเดียว

ต้นทุนที่คลิปไม่ได้เล่า

พื้นที่โจมตีที่กว้างขึ้น

มีงานวิจัยบน arXiv ที่เผยแพร่เป็น preprint เมื่อ 17 ก.พ. 2026 ชื่อ From Tool Orchestration to Code Execution: A Study of MCP Design Choices [4] ทีมผู้เขียนทดลองกับเซิร์ฟเวอร์ MCP 10 ตัว แล้วพบว่าโมเดลแบบเขียนโค้ดลดโทเคนและเวลาได้จริง แต่แลกมาด้วยพื้นที่โจมตีที่กว้างขึ้นมาก

เขาจัดหมวดการโจมตีได้ 16 แบบในห้าช่วงของการรันโค้ด รวมถึงการแทรกโค้ดผ่านข้อความ error และการประกอบความสามารถที่ไม่ปลอดภัยขึ้นมาเอง

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

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

แล้ว MCP ยังมีที่ทางตรงไหน

MCP ยังเป็นชั้นล่างของระบบ

Anthropic เขียนไว้ชัดว่า MCP คือมาตรฐานเปิดที่ชุมชนสร้างเซิร์ฟเวอร์ไว้หลายพันตัว และอุตสาหกรรมรับไปใช้เป็นมาตรฐานโดยพฤตินัยตั้งแต่เปิดตัวในเดือน พ.ย. 2024 [2] ตัวสเปกเปิดให้อ่านและนำไปใช้งานได้ฟรีที่เว็บทางการ [5]

ตอนนี้ MCP กลายเป็นชั้นล่าง ส่วนชั้นบนคือโค้ดที่ agent เขียนขึ้นมาเรียกใช้ เปรียบเทียบง่าย ๆ คือ MCP เป็นปลั๊กไฟ ส่วนโค้ดคือเครื่องใช้ไฟฟ้าที่เสียบเข้าไป

เลือกแบบไหนดี

ในทางปฏิบัติ การเลือกใช้ขึ้นอยู่กับสามเงื่อนไข ซึ่งเป็นข้อสังเกตของผมเอง ไม่ใช่ตัวเลขจากต้นทาง

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

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

แต่ถ้าสคริปต์นั้นรันบนเครื่องคุณโดยไม่มีอะไรกั้น มันก็อ่านไฟล์อะไรก็ได้ที่สิทธิ์ของคุณอ่านได้ นี่คือจุดที่บทความของผมเรื่อง NVIDIA OpenShell เข้ามาเกี่ยวข้อง

โค้ดนี้เป็นภาพประกอบเชิงแนวคิด ไม่ใช่ API จริงของไลบรารีใด

หน้าตาของโค้ดแบบที่ว่านั้นประมาณนี้

# agent เขียนสคริปต์เอง แล้วรันในแซนด์บ็อกซ์
rows = mcp.csv.read("leads.csv")
clean = [r for r in rows if r["country"] == "TH"]
mcp.crm.upsert(clean)
print(f"sync {len(clean)} rows")

โมเดลเห็นแค่บรรทัดสุดท้าย ไม่ต้องแบกข้อมูลทั้งไฟล์ไว้ใน context

สิ่งที่ทีมไทยควรทำก่อนเปลี่ยน

ถ้าคุณกำลังดูแล agent ที่ต่อ MCP อยู่ ลองทำตามลำดับนี้

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

ข้อสี่สำคัญมาก ผมเห็นหลายทีมดูแค่ input token แล้วสรุปว่าประหยัด แต่พอรวม output กับค่าแซนด์บ็อกซ์แล้ว ตัวเลขอาจไม่สวยอย่างที่คิด

คำตอบของคำถามตั้งต้น

MCP ไม่ได้ใกล้ตาย และคำว่า "obsolete" ในคลิปก็เป็นถ้อยคำเชิงพาดหัวมากกว่าข้อเท็จจริง

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

ถ้าจะสรุปสั้น ๆ ในแบบที่ผมเชื่อ มันไม่ใช่การฝัง MCP แต่คือการย้ายที่ซ่อนความซับซ้อนไว้ในโค้ดแทน context

คำถามที่ควรถามจึงไม่ใช่ "MCP ตายหรือยัง" แต่เป็น "ทีมเราพร้อมจะรับโค้ดที่โมเดลเขียนขึ้นมารันบนเครื่องตัวเองหรือยัง"

ถ้ายังไม่พร้อม คำตอบที่ปลอดภัยคือใช้วิธีเดิมไปก่อน แล้วค่อยขยับเมื่อมีแซนด์บ็อกซ์ที่ไว้ใจได้

REF

[1] ducktate.com (26 ต.ค. 2026) · Apparently MCP is obsolete for AI AGENTS (TikTok). https://www.tiktok.com/@ducktate.com/video/7701079401403813133

[2] Anthropic (พ.ย. 2025) · Code execution with MCP: Building more efficient agents. https://www.anthropic.com/research/code-execution-with-mcp

[3] AIMultiple (2026) · Code Execution with MCP: A New Approach to AI Agent Efficiency. https://aimultiple.com/code-execution-with-mcp

[4] arXiv (17 ก.พ. 2026) · From Tool Orchestration to Code Execution: A Study of MCP Design Choices. https://arxiv.org/abs/2602.15945

[5] Model Context Protocol (2026) · Specification. https://modelcontextprotocol.io/specification