ถอดบทเรียน MCP server ระดับโปรดักชัน — Smartsheet ประหยัดโทเคนไป 3 พันล้าน ด้วยการออกแบบ tool ไม่ใช่การเปลี่ยนโมเดล

วันที่ 17 กรกฎาคม 2026 บล็อก Machine Learning ของ AWS เผยแพร่บทความถอดสถาปัตยกรรมของ remote MCP server ของ Smartsheet ตั้งแต่ชั้น edge ลงไปถึงชั้นข้อมูล เขียนโดยทีมวิศวกรของ Smartsheet ร่วมกับ AWS

บทความแนวนี้มีเยอะขึ้นเรื่อย ๆ ในปี 2026 แต่ตัวนี้ต่างออกไปตรงที่มันไม่ได้ขายว่า “เราต่อ MCP แล้วนะ” — มันลงรายละเอียดว่า ทำไม MCP server ที่ทำงานได้จริงในระดับองค์กรถึงไม่ใช่แค่การเอา REST API เดิมมาห่อใหม่ และตัวเลขที่ทีมงานยกมายืนยันก็ตรงประเด็นสำหรับคนที่กำลังจะสร้าง MCP server ของตัวเอง: นับจากเปิดใช้ พวกเขา ประหยัดโทเคนไปแล้วกว่า 3 พันล้านโทเคน ไม่ใช่ด้วยการเปลี่ยนไปใช้โมเดลถูกลง แต่ด้วยการออกแบบ tool ให้ตอบข้อมูลกลับน้อยลง

สามชั้นของการลดโทเคน — หัวใจจริงของบทความ

ทีม Smartsheet แยกเทคนิคลดต้นทุนโทเคนออกเป็นสามชั้นที่ทำงานคนละหน้าที่:

1. Progressive disclosure — เซิร์ฟเวอร์คำนวณขนาด response แบบไดนามิกจาก จำนวนคอลัมน์และความหนาแน่นของข้อมูล แทนที่จะยัดทุกแถวกลับไปให้โมเดล แล้วแนบ metadata บอกสถานะไว้ด้วย ได้แก่ is_sampled, rows_actual และ filters_applied จุดสำคัญคือชั้นนี้ไม่ได้แค่ตัดข้อมูลทิ้ง แต่ บอกโมเดลตรง ๆ ว่าข้อมูลที่ได้ไปถูกตัดมา ซึ่งเป็นความต่างระหว่าง “ตัดข้อมูล” กับ “โกหกโมเดล”

2. Schema-driven contract — พารามิเตอร์ของทุก tool ถูกบังคับด้วย JSON schema ที่ validate ด้วย Pydantic จำกัดค่าให้อยู่ใน enum และชื่อคอลัมน์ที่มีจริงเท่านั้น ผลคือโมเดลไม่มีช่องให้เดาชื่อคอลัมน์ที่ไม่มีอยู่ — เป็นการกัน hallucination ที่ชั้น interface ไม่ใช่ชั้น prompt

3. Serialization เฉพาะทาง — ทีมเขียนฟอร์แมตของตัวเองมาแทน JSON เพื่อตัด overhead เชิงโครงสร้าง (ปีกกา เครื่องหมายคำพูด ชื่อ key ที่ซ้ำทุกแถว) บทความระบุว่ากินโทเคน น้อยลงราว 35% เทียบกับ JSON ที่ให้ข้อมูลเท่ากัน บนคิวรีตัวแทน

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

MCP layer เดียว เสิร์ฟทั้งเอเจนต์ในบ้านและนอกบ้าน

การตัดสินใจเชิงสถาปัตยกรรมที่บทความเน้นชัดคือ Smart Assist ซึ่งเป็นผู้ช่วย AI ของ Smartsheet เอง กับไคลเอนต์ภายนอกอย่าง Amazon Quick วิ่งอยู่บนโครงสร้างเดียวกันทุกประการ — tool ชุดเดียวกัน การ optimize ชุดเดียวกัน intelligence stack ชุดเดียวกัน ทีมงานสรุปเจตนาไว้ว่า Smartsheet “สร้างครั้งเดียว แล้วไคลเอนต์ agentic ทุกตัวได้ประโยชน์ทันที”

ฝั่งโครงสร้างพื้นฐาน request วิ่งจากไคลเอนต์ AI เข้า API gateway ที่ validate OAuth ก่อน แล้วต่อเข้า MCP server ที่รันเป็น stateless container บน AWS Fargate for Amazon ECS ก่อนแยกไปยัง domain service และ intelligence layer ส่วนงานข้อมูลใช้ Kinesis Data Streams กับ Managed Service for Apache Flink ไหล change event ลง S3 ตามสถาปัตยกรรมแบบ medallion มี Amazon Neptune เป็น knowledge graph สำหรับ insight ข้าม project และ Amazon Bedrock สำหรับ inference ขอบนอกป้องกันด้วย WAF, Shield และ Application Load Balancer

เรื่องสิทธิ์ที่ทำถูก และวินัยการ deploy

จุดที่ควรลอกไปใช้มากที่สุดคือหลักการเรื่องสิทธิ์: fine-grained permission ยังอยู่ที่ชั้น domain service ไม่ได้ย้ายมาไว้ที่ MCP ทีมงานสรุปเป็นประโยคที่ควรติดไว้หน้าจอทุกคนที่ทำ MCP server ว่า — ถ้าผู้ใช้เข้าถึงชีตนั้นผ่าน UI ไม่ได้ ก็เข้าถึงผ่าน MCP ไม่ได้เหมือนกัน

เสริมด้วย defense-in-depth หลายชั้น: mTLS สำหรับการเรียกระหว่างเซอร์วิส, OAuth2 proxy ที่ปัดคำขอที่ไม่ผ่าน auth ทิ้งตั้งแต่ก่อนถึงชั้น compute, rate limiting แบบเป็นชั้นผ่าน WAF (ทั้งแบบครอบทั้ง edge, แบบนับรายผู้ใช้ผ่าน custom identity header และแบบเจาะ path ที่แพงเป็นพิเศษ) และให้ผู้ดูแลองค์กรคุมจังหวะการเปิดใช้เองได้ผ่าน toggle สามระดับ — เปิดทั้งหมด, อ่านอย่างเดียว, หรือเขียนได้เต็ม

ที่น่าสนใจอีกจุดคือการใช้ annotation ของโปรโตคอล MCP เอง คือ readOnlyHint และ destructiveHint เพื่อให้ไคลเอนต์เด้ง confirmation flow อัตโนมัติเมื่อ tool นั้นทำงานที่ย้อนกลับไม่ได้ — เป็นการใช้สเปกให้เต็มความสามารถ แทนที่จะปล่อยให้ไคลเอนต์เดาเอง

ฝั่งวินัยการปล่อยของ: ECS auto scaling ดูทั้ง traffic และ compute utilization ประกอบกัน, มี deployment circuit breaker ที่ตรวจจับ container พังระหว่าง rollout แล้วย้อนกลับอัตโนมัติ, รัน canary test ที่เดินเวิร์กโฟลว์หลายขั้นจริงทุก 15 นาที บนสภาพแวดล้อมที่ใช้งานอยู่ และไล่ปล่อยทีละ region โดยต้องผ่าน validation แบบ end-to-end ก่อนไป region ถัดไป ส่วน observability ส่งสัญญาณ OpenTelemetry ผ่าน Kinesis เข้า OpenSearch มี Datadog ทำ APM รายตัว tool และ PagerDuty จัดการ incident

หลังเปิด GA สี่สัปดาห์แรก บทความรายงานการเติบโตของผู้ใช้ที่ 87% เมื่อเทียบสัปดาห์ต่อสัปดาห์

มุมมอง AI Curator

ถ้าจะสรุปบทความนี้เหลือประโยคเดียวสำหรับคนที่กำลังจะสร้าง MCP server: ต้นทุนของเอเจนต์ไม่ได้อยู่ที่ราคาโมเดล แต่อยู่ที่ปริมาณข้อมูลที่คุณยัดกลับเข้าไปในหน้าต่างบริบท ตัวเลข 35% จาก serialization และ 3 พันล้านโทเคนสะสมเกิดจากงานที่ไม่เกี่ยวกับ AI เลยแม้แต่นิดเดียว — มันคืองานออกแบบ API แบบเก่า ๆ ที่วิศวกรทำกันมาสามสิบปี แค่ย้ายมาใช้กับผู้บริโภคชนิดใหม่ที่คิดเงินเป็นโทเคน

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

อีกประเด็นที่ควรพูดตรง ๆ คือ บทเรียนสำคัญที่สุดของบทความนี้ไม่ผูกกับ AWS ใครที่อ่านแล้วสรุปว่า “ต้องมี Fargate กับ Neptune ถึงจะทำได้” คืออ่านผิดทาง เพราะ progressive disclosure, การบังคับพารามิเตอร์ด้วย schema, การเลิกใช้ JSON กับข้อมูลตาราง และการไม่ย้ายตรรกะสิทธิ์มาไว้ที่ MCP — ทั้งสี่ข้อทำได้บน VPS เครื่องเดียวในราคาหลักร้อยบาทต่อเดือน ส่วนที่ต้องใช้ของแพงคือส่วนที่รองรับสเกลระดับ Smartsheet ซึ่งเป็นคนละปัญหากับที่ทีมส่วนใหญ่กำลังเจอ

สำหรับทีมไทยและ SEA ที่กำลังเปิด MCP server ให้ระบบภายในองค์กร — ERP, ระบบ HR, ฐานข้อมูลลูกค้า — สองข้อที่ควรหยิบไปใช้ตั้งแต่วันแรกคือ การบังคับพารามิเตอร์ด้วย schema เพราะมันตัดปัญหาโมเดลเดาชื่อฟิลด์ผิดซึ่งเป็นบั๊กอันดับหนึ่งของ MCP server ที่ต่อกับระบบเก่า และ การยืนยันว่าสิทธิ์อยู่ที่ระบบต้นทาง เพราะความเสี่ยงที่ใหญ่ที่สุดของการเปิด MCP ให้ระบบภายในไม่ใช่ค่าโทเคน แต่คือการที่เอเจนต์กลายเป็นทางลัดข้ามระบบสิทธิ์ที่องค์กรใช้เวลาหลายปีสร้างขึ้นมา — ซึ่งเป็นความผิดพลาดที่มักไม่มีใครรู้ตัวจนกว่าจะมีคนถามคำถามที่ไม่ควรได้คำตอบ แล้วได้คำตอบ

แหล่งข่าว

• How Smartsheet built a remote MCP server on AWS — AWS Machine Learning Blog
• Smartsheet MCP server introduction — Smartsheet Developers
• Smartsheet AI & MCP server changelog
• AWS Machine Learning Blog