Google สรุป 4 แพตเทิร์นจากผลงานที่ติดอันดับใน AI Agents Challenge — ไม่มีข้อไหนเลยที่ต้องใช้โมเดลใหญ่ขึ้น และข้อที่ประหยัดที่สุดคือการไม่เรียกโมเดล

2 กันยายน 2026 Sergio Villani จากทีม Technical Solutions ของ Google Cloud AI เขียนสรุปสิ่งที่เห็นหลังปิดการตัดสิน Google for Startups AI Agents Challenge ซึ่งมีผู้ส่งผลงานหลักพันทีมใน 3 แทร็ก และประโยคเปิดของเขาน่าจะโดนใจใครหลายคนที่เคยรีวิวโค้ดเอเจนต์:

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

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

1. MCP สองทาง: ทูลที่คุณสร้างให้ตัวเอง เสิร์ฟเอเจนต์อื่นได้ด้วย

ผลงานส่วนใหญ่ใช้ MCP ทางเดียว — เอเจนต์เรียกออกไปหา tool server เพื่อดึงข้อมูล แต่มีทีมหนึ่งทำสองทาง: เอเจนต์อ่านฐานข้อมูล telemetry ผ่านชั้น MCP tool ของตัวเอง แล้วเปิดการให้เหตุผลชุดเดียวกันนั้นออกมาเป็น MCP server ให้เอเจนต์อื่นเรียกได้

Villani ชี้ว่าครึ่งแรก (ฝั่งภายใน) มีค่าในตัวเองก่อนจะไปถึงครึ่งหลังด้วยซ้ำ เวอร์ชันที่ทำแบบตรงไปตรงมาจะยิง SQL ตรงเข้าฐาน telemetry แล้วเทแถวทั้งหมดเข้า context ของโมเดล — ซึ่งบนฐานข้อมูลโปรดักชันจริงคือวิธีเผางบโทเคนให้หมดในคำขอเดียว การผ่านชั้น MCP tool ทำให้เอเจนต์ได้เครื่องมือกรองข้อมูลเชิงโปรแกรม ดึงมาเฉพาะ execution plan ของ job หรือ stack trace ที่ต้องการ แทนที่จะดึงทั้งตาราง

และนั่นคือสิ่งที่ทำให้ครึ่งหลังเป็นไปได้เลย: ทูลที่คืนคำตอบแบบมีขอบเขตชัดเจนเสมอ เป็นสิ่งที่ยื่นให้ผู้เรียกที่คุณควบคุมไม่ได้ยังพอปลอดภัย ส่วน raw SQL connection ไม่มีวันปลอดภัย ผลลัพธ์เชิงผลิตภัณฑ์คือ coding agent ที่รันอยู่ใน terminal หรือ IDE เรียกเอเจนต์ตัวนี้ได้โดยตรง เหมือนเรียกทูลอื่น ๆ ไม่ต้องมีมนุษย์เปิดแดชบอร์ด พิมพ์อธิบายปัญหาในกล่องแชท แล้วก๊อบคำตอบกลับไปเอง

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

2. Event bus แทน call chain

อีกทีมเริ่มจาก pipeline เชิงเส้น: เอเจนต์เฝ้าเซนเซอร์เรียกเอเจนต์ตรวจ compliance ซึ่งเรียกเอเจนต์ส่งข้อความหาผู้พักอาศัย ซึ่งเรียกเอเจนต์ dispatch ต่อ — ใช้ได้ดีตอนเดโม แต่พังกับเคสจริง คือการจับสัญญาณความเสี่ยงล้มจากการเปลี่ยนแปลงของท่าเดิน ตรวจสอบกับฐานข้อมูลปฏิกิริยาระหว่างยาแบบเรียลไทม์ แล้วส่งข้อความถึงคนที่ถูกต้องให้ทันก่อนหน้าต่างเวลาจะปิด

ทางแก้คือ async event bus ที่สร้างจาก asyncio.Queue สี่ตัวแยกกัน ตัวละเอเจนต์ แต่ละตัวมี worker coroutine ของตัวเองคอยดึงงาน แทนที่ A จะเรียก B แล้วรอค่าคืน เอเจนต์จะ publish อีเวนต์ที่มีชนิดชัดเจนไปยัง topic แล้ว subscribe เฉพาะ topic ที่ตัวเองสนใจ

ตัวอย่างที่โพสต์ยกมาเป็นรูปธรรมมาก: ความเร็วการเดินที่ลดลงตั้งแต่ 15% ขึ้นไปจะ publish อีเวนต์ CLINICAL.ANOMALY_DETECTED เอเจนต์ compliance ที่จอดรออยู่บน topic นั้นหยิบไปทันทีที่มันเกิด ตรวจกับฐานข้อมูลยา แล้ว publish CLINICAL.COMPLIANCE_REPORT_READY ต่อทันทีที่เสร็จ — ไม่ใช่ตามรอบ polling และไม่ต้องรอให้ใครส่งงานมาให้

ความต่างที่แท้จริงอยู่ตรงนี้: ใน call chain ความหน่วงรวมเป็นการบวกกัน เพราะแต่ละตัวถือ stack ค้างไว้รอตัวถัดไป ส่วนบน topic-based bus เอเจนต์สองตัวที่ไม่ได้พึ่งเอาต์พุตของกันและกันจะทำงานพร้อมกัน คุณอยากได้รูปแบบนี้เมื่อไหร่ก็ตามที่เอเจนต์ของคุณทำงานคนละจังหวะ — ตัวหนึ่ง poll ทุกไม่กี่วินาที ตัวหนึ่งยิง network call ครึ่งวินาที ตัวหนึ่งทำงานครั้งเดียวตอนจบ

ประโยคที่ Villani ทิ้งไว้ให้ตรวจสถาปัตยกรรมตัวเองคมมาก: ถ้าสถาปัตยกรรมของคุณบังคับให้เอเจนต์ตัวหนึ่งรอคิวอยู่หลังอีกตัวเพื่อจะตอบสนองสัญญาณเดียวกัน นั่นคือระบบเธรดเดียวที่สวมป้าย multi-agent

3. Fallback ต้องผ่านด่านตรวจเดียวกัน

เอเจนต์ให้เหตุผลทางคลินิกของอีกทีมรันบน Gemini 3.1 Pro แล้วเจอ 503 ตอนโหลดจริง ผลงานส่วนใหญ่จะแปะ retry loop ยิงกลับไปที่โมเดลเดิมแล้วจบ แต่ทีมนี้ทำ fallback ไป Gemini 3.6 Flash พร้อม backoff และ บังคับให้คำตอบจากทั้งสองโมเดลวิ่งผ่านฟังก์ชันตรวจสอบตัวเดียวกัน ก่อนถูกยอมรับ — เป็นการเช็กว่าคำตอบอ้างอิงแนวทางเวชปฏิบัติที่มีอยู่จริง ไม่ใช่แค่ภาษาทางการแพทย์ที่ฟังดูน่าเชื่อ

รายละเอียดที่ควรลอกไปใช้ไม่ใช่ “การมี fallback” แต่คือ ตำแหน่งที่โค้ดตรวจสอบวางอยู่ มันไม่ได้ถูกเขียนซ้ำสองชุด ชุดหนึ่งสำหรับทางหลักและอีกชุดสำหรับทาง fallback ซึ่งเป็นรูปแบบที่แก้ที่หนึ่งแล้วลืมอีกที่ได้ง่ายมาก แต่มี validate_clinical_response() ตัวเดียวที่ทั้งทาง Pro และทาง Flash ถูกบังคับให้เรียกก่อนที่ผลลัพธ์จะออกจากเอเจนต์ได้

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

4. คัดกรองเป็นชั้นก่อนจ่ายค่าโมเดล

ทีมหนึ่งวัดว่าอะไรกินงบ inference จริง ๆ แล้วพบว่าไม่ใช่คำถามยาก แต่เป็นคำถามง่าย — “ออเดอร์ฉันอยู่ไหน”, “ยกเลิกนัด” — ที่วิ่งผ่านการเรียกโมเดลเต็มรูปแบบเหมือนกับคำขอที่กำกวมจริง ๆ

ทางแก้คือ classifier สามชั้นวางไว้หน้าเอเจนต์: ชั้นแรกเป็น regex ในเครื่องที่จับ navigational intent ด้วยต้นทุนศูนย์โทเคน เคสที่กำกวมส่งต่อไปที่การเรียก Gemini แบบถูก ๆ ที่ใช้ราวสิบโทเคนและตั้ง temperature 0.1 เพื่อจำแนกเจตนาอย่างเดียว และเฉพาะสิ่งที่รอดสองชั้นแรกเท่านั้นที่ไปถึงโมเดลให้เหตุผลตัวเต็ม

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

สิ่งที่โพสต์นี้ไม่ได้ให้ และควรอ่านคู่กัน

โพสต์จบด้วยการบอกว่าผลงานที่สร้างบน Agent Development Kit (ADK) และขับผ่าน Agents CLI คือกลุ่มที่แพตเทิร์นเหล่านี้โผล่บ่อยที่สุด “เพราะเฟรมเวิร์กไม่ขวางคุณเรื่อง concurrency, fallback หรือการส่งทูลให้เอเจนต์อื่น”

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

ข้อจำกัดอื่นที่ควรรู้: ไม่มีชื่อทีม ไม่มีลิงก์โค้ด และไม่มีตัวเลขฐาน ตัวเลข 40% เป็นการวัดของทีมนั้นเอง ไม่มีการบอกว่าต้นทุนก่อน-หลังต่างกันเท่าไร ไม่มีข้อมูลว่าการกรองด้วย regex ทำให้พลาดเจตนาไปกี่เปอร์เซ็นต์ (false negative ของชั้นแรกจะเด้งไปชั้นสองซึ่งยังถูกอยู่ แต่ถ้าจับผิดประเภทจะกลายเป็นคำตอบผิดที่ไม่เคยไปถึงโมเดลเลย) และไม่มีตัวเลขความหน่วงเปรียบเทียบระหว่าง call chain กับ event bus

มุมมอง AI Curator

จุดที่ทำให้โพสต์นี้มีค่ากว่าคอนเทนต์การตลาดทั่วไปคือ สามในสี่แพตเทิร์นไม่ใช่ของใหม่ในวงการวิศวกรรมซอฟต์แวร์เลย — pub/sub event bus, fallback ที่ต้องผ่าน validation เดียวกัน และการคัดกรองเป็นชั้นก่อนเรียกทรัพยากรแพง เป็นสิ่งที่คนสร้างระบบกระจายทำกันมาสองทศวรรษแล้ว สิ่งที่โพสต์บอกกลาย ๆ คือ วงการเอเจนต์กำลังค้นพบวิศวกรรมพื้นฐานใหม่อีกรอบ เพราะคนจำนวนมากเข้ามาทางพรอมป์ตไม่ได้เข้ามาทางสถาปัตยกรรมระบบ ข้อที่ใหม่จริงมีข้อเดียวคือ bidirectional MCP — และมันใหม่เพราะโปรโตคอลเพิ่งมี ไม่ใช่เพราะแนวคิดใหม่

ประโยคที่มีมูลค่าสูงสุดในโพสต์นี้สำหรับทีมไทยคือประโยคของแพตเทิร์นที่ 4: “ดูการกระจายตัวของทราฟฟิกตัวเองก่อนจะสรุปว่าต้องใช้โมเดลใหญ่กว่า” เพราะข้อจำกัดของทีมไทยส่วนใหญ่ไม่ใช่ความสามารถของโมเดล แต่คือค่า API ต่อเดือนที่ต้องขออนุมัติ การกรองทราฟฟิกง่าย ๆ ออก 40% ก่อนแตะโมเดล มีผลต่อบิลมากกว่าการเปลี่ยนจากโมเดลหนึ่งไปอีกโมเดลหนึ่งเสียอีก และทำได้ในหนึ่งบ่าย

แต่มีกับดักที่ต้องเตือนไว้ตรง ๆ สำหรับงานภาษาไทย: ชั้น regex ต้นทุนศูนย์โทเคนทำงานกับภาษาไทยได้ยากกว่าภาษาอังกฤษมาก เพราะภาษาไทยไม่เว้นวรรคระหว่างคำ \b ที่ใช้จับขอบเขตคำในภาษาอังกฤษจึงใช้ไม่ได้ และการ match สตริงดิบ ๆ จะเจอปัญหาคำซ้อนคำ ทีมไทยที่จะลอกแพตเทิร์นนี้ควรเปลี่ยนชั้นแรกเป็นการตัดคำ (เช่น newmm ใน PyThaiNLP) แล้วค่อยแมตช์คีย์เวิร์ด หรือใช้ classifier ขนาดเล็กที่รันในเครื่องแทน — ยังเป็นต้นทุนศูนย์ค่า API เหมือนกัน แต่ไม่พังกับ “ยกเลิกนัดหมอ” ที่ผู้ใช้พิมพ์ติดกันหมด อย่าลอกโค้ด regex ภาษาอังกฤษมาแล้วคาดหวังอัตราการจับ 40% เท่ากัน

ส่วนแพตเทิร์นที่ 1 คือแพตเทิร์นที่ควรวางแผนไว้ล่วงหน้าที่สุด ถ้าทีมคุณกำลังสร้างเอเจนต์ที่มีความรู้เฉพาะทาง — เอเจนต์อ่านเอกสารราชการไทย เอเจนต์ที่รู้กฎ PDPA เอเจนต์ที่ต่อกับระบบภายในองค์กร — การวางมันไว้หลัง MCP tool interface ตั้งแต่แรก แล้วค่อยเปิดเป็น MCP server ทีหลัง แทบไม่มีต้นทุนเพิ่ม แต่ถ้าสร้างเป็นแชตบอตที่มีมนุษย์เป็นผู้ใช้เท่านั้นตั้งแต่ต้น การย้อนกลับมาทำทีหลังคือการเขียนใหม่ ในโลกที่ coding agent กำลังกลายเป็นผู้เรียกทูลหลัก “มีมนุษย์เป็นผู้ใช้เท่านั้น” กำลังกลายเป็นข้อจำกัดทางสถาปัตยกรรม ไม่ใช่ทางเลือกด้านดีไซน์ — และคำเตือนเรื่องการควบคุมสิทธิ์ที่โพสต์แปะไว้ท้ายแพตเทิร์นนั้นก็ต้องมาพร้อมกันตั้งแต่วันแรก ไม่ใช่ค่อยเติมทีหลัง

แหล่งข่าว

• Google Developers Blog — 4 engineering patterns behind the strongest AI Agents Challenge submissions (2 ก.ย. 2026)
• Google Agent Development Kit (ADK)
• Model Context Protocol — เอกสารโปรโตคอล