บนเวที พี่หมอจิมวางทั้ง stack ของ agent ไว้แค่สามชั้น ชั้นล่างสุดคือ harness เทียบเป็น OS ชั้นกลางคือตัว agent เทียบเป็นแอป ส่วนชั้นบนสุดคือ framework เทียบเป็น SDK เขาย้ำไว้ตรงๆ ว่า framework ไม่ใช่ agent มันคือ SDK ของยุค agent เท่านั้น เทียบง่ายๆ ก็เหมือนตอนเขียนแอปมือถือ ไม่มีใครเรียก React Native ว่าเป็นแอป มันคือเครื่องมือที่ใช้ประกอบแอปขึ้นมา framework ของ agent ก็อยู่ในตำแหน่งเดียวกันนั้นเป๊ะ
พอวางเป็นสามชั้นแบบนี้ เขาก็แบ่งค่ายของ framework ไว้สองฝั่งทันที ฝั่งหนึ่งคือ framework อิสระที่รันกับโมเดลค่ายไหนก็ได้ อีกฝั่งคือ SDK ของผู้ให้บริการโมเดลเอง ที่แลกความเป็นอิสระเอาไว้กับความลึกของการผูกเข้ากับระบบตัวเอง เขาบอกไว้ตรงๆ ว่านี่ไม่ใช่ศึกใหม่ แต่เป็นศึกเดิมที่วนกลับมาในทุกชั้นของ stack เลือกทางไหนก็แลกกันระหว่างอิสระกับความผูก ไม่มีทางที่ได้ทั้งสองเต็มๆ
สามส่วนที่ agent ทุกตัวมีเหมือนกัน ไม่ว่าจะสร้างด้วย framework ไหน
ไม่ว่าจะเลือกฝั่งไหน agent ที่สร้างออกมาก็มีสามส่วนเหมือนกันหมด โมเดลคือสมอง เครื่องมือคือมือ คำสั่งคือคู่มือการทำงาน สามส่วนนี้ไม่เปลี่ยนไม่ว่าจะห่อด้วย framework ค่ายไหน
สามเสานี้อ่อนแอจุดไหน agent ก็ล้มตรงจุดนั้น โมเดลเลือกผิดขนาด งานง่ายเอาโมเดลใหญ่มาทำก็แพงเกินจำเป็น งานยากเอาโมเดลเล็กมาทำก็ตอบผิดบ่อย เครื่องมือให้น้อยไป agent ก็ทำงานได้แค่ครึ่งเดียว ให้มากเกินไปโดยไม่คัดกรอง agent ก็เลือกผิดตัวเพราะตัวเลือกเยอะเกิน ส่วนคำสั่งคือจุดที่คนมักมองข้ามที่สุด เพราะคำสั่งกำกวม 1 บรรทัดพอจะทำให้ agent ตีความผิดทางได้ทั้งงาน ไม่ต่างจากคู่มือทำงานที่เขียนไม่ชัดแล้วส่งให้พนักงานใหม่อ่านเอง
แล้วคำแนะนำที่ใช้ได้จริงที่สุดในบทนี้ก็มาจากจุดนี้เอง เริ่มด้วย agent ตัวเดียวก่อนเสมอ agent ตัวเดียวที่ทำดีจริงคลุมงานส่วนใหญ่ได้อยู่แล้ว ส่วน multi-agent นั้นเพิ่มความซับซ้อนเข้ามาก่อนที่จะมีใครพิสูจน์ได้ด้วยซ้ำว่ามันจำเป็น เขาสรุปไว้เป็นประโยคเดียวที่คุมทั้งช่วงนี้
เพิ่มความซับซ้อนเมื่อหลักฐานบังคับ ไม่ใช่ความอยาก
หลักฐานที่ว่านี้ไม่ใช่ความรู้สึกว่างานมันใหญ่ขึ้น แต่ต้องจับต้องได้ เช่น agent ตัวเดียวเริ่มทำเวลาหลุด งาน 1 ชิ้นเริ่มมีสองบทบาทที่ขัดกันเองอยู่ในคำสั่งเดียว หรือคิวงานเริ่มค้างเพราะรอ agent ตัวเดียวทำทีละอย่าง เมื่อเจอสัญญาณแบบนี้จริงถึงค่อยแตกเป็นหลาย agent ไม่ใช่แตกเพราะอยากลองสถาปัตยกรรมใหม่
พอถึงจุดที่ต้องเพิ่มความซับซ้อนจริงๆ เพราะหลักฐานบังคับแล้ว สิ่งที่ต้องมีคู่กันมาด้วยคือ guardrail กับจุดให้คนเช็คตรงขั้นตอนที่เสี่ยง เป้าหมายของทั้งระบบไม่ใช่ทำถูกแค่ครั้งเดียวแล้วจบ แต่คือทำถูกซ้ำได้ทุกรอบ และถ้าวันไหนพลาด ต้องพลาดแบบที่ควบคุมได้ ไม่ใช่พลาดแบบที่ไม่รู้ว่าจะไปหยุดตรงไหน
จุดที่คนต้องเคาะ ไม่จำเป็นต้องอยู่ทุกขั้นตอน แต่ต้องอยู่ตรงขั้นตอนที่ทำแล้วย้อนกลับยาก เช่น ก่อนส่งอีเมลออกจริง ก่อนลบข้อมูล หรือก่อน deploy งานเข้า production ส่วนขั้นตอนที่ทำผิดแล้วแก้คืนได้ง่าย ปล่อยให้ agent ทำต่อเนื่องไปได้โดยไม่ต้องหยุดรอคน
วิธีวัดว่าวางจุดเช็คไว้พอดีหรือยัง คือลองไล่ log ย้อนหลังของงานที่ agent ทำไปแล้วสักสิบครั้ง ถ้าทุกครั้งจบงานแบบเดียวกันได้ซ้ำ แปลว่าสามเสาแข็งแรงพอ แต่ถ้ามีบางครั้งที่ผลลัพธ์ต่างไปโดยไม่มีใครรู้ตัวจนมาเจอทีหลัง นั่นคือสัญญาณว่าจุดเช็คยังวางผิดที่ ไม่ใช่วางน้อยไปหรือมากไปอย่างเดียว แต่วางไม่ตรงจุดที่ระบบจริงเสี่ยงพัง
เกณฑ์เลือก framework ที่เชื่อได้กว่าจำนวนฟีเจอร์
ทีนี้พอต้องเลือก framework จริงๆ เขาให้เกณฑ์ตัดสินไว้ตัวเดียว คือความลึกของการรองรับ protocol ไม่ใช่จำนวนฟีเจอร์ที่โฆษณาไว้หน้าเว็บ framework ที่รองรับ protocol แค่ผิวๆ มักพังตอนต้องต่อเครื่องมือซับซ้อนหรือสลับโมเดลหลายค่ายพร้อมกัน ส่วน framework ที่รองรับลึกจริงจะยังใช้ได้ต่อแม้เปลี่ยนโมเดลเบื้องหลัง เขายกตัวอย่างให้เห็นว่าโมเดลเดียวกัน งานเดียวกัน แต่เปลี่ยน framework แล้วคะแนนต่างกันได้มาก
ซีรีส์ตอนที่ 2 เคยเตือนเรื่องนี้ไว้แล้ว ว่าตัวเลขเปรียบเทียบที่ยกมาอ้าง ต้องกลับไปดูที่มาก่อนเสมอ ก่อนจะเอาไปตัดสินใจอะไรต่อ เกณฑ์ที่เชื่อได้กว่าคือความลึกของการรองรับ protocol ซึ่งเห็นได้จากการลองต่อเครื่องมือจริงและลองสลับโมเดลดู ไม่ใช่จากตัวเลขสรุปตัวเดียว
เอาไปใช้ได้จริงตรงไหน
ตอนที่แล้วเราพูดถึงเรื่องสิทธิ์ ว่า agent ต่างจากแชตบอตตรงที่ลงมือแล้วเกิดผลจริงในโลก ตอนนี้คือภาคต่อ ก่อนจะให้ agent ลงมือ ต้องเลือกว่าจะสร้างมันด้วยอะไร แล้วสองบทนี้ก็ต่อกันเป็นคำแนะนำเดียวสำหรับคนที่กำลังจะเลือก framework หรือกำลังจะสร้าง agent ตัวแรกในทีม
เริ่มด้วย agent ตัวเดียวก่อนเสมอ ให้มันคลุมงานที่ตรวจสอบผลได้ชัดก่อน แล้วค่อยขยับไปงานที่ตีความยากขึ้นทีหลัง พอถึงจุดที่คิดจะเพิ่ม agent ตัวที่สอง ให้ถามตัวเองก่อนว่ามีหลักฐานอะไรบังคับให้ต้องทำจริงๆ ไม่ใช่แค่อยากลองของใหม่ ถ้าตอบไม่ได้ว่าหลักฐานคืออะไร นั่นแปลว่ายังไม่ถึงเวลา
พอถึงขั้นเลือก framework ให้เช็คความลึกของการรองรับ protocol เป็นหลัก ไม่ใช่ดูจากจำนวนฟีเจอร์ในหน้าโฆษณา และถ้าเห็นตัวเลขเปรียบเทียบระหว่าง framework ที่ไหนก็ตาม ให้กลับไปดูที่มาของตัวเลขนั้นก่อนเชื่อทุกครั้ง
และพอ agent เริ่มทำงานจริงแล้ว อย่าลืมวางจุดให้คนเช็คไว้ตรงขั้นตอนที่ย้อนกลับยากตั้งแต่ต้น ไม่ใช่วางเต็มทุกขั้นตอนจนระบบช้าเกินใช้งาน และไม่ใช่ไม่วางเลยจนพลาดแล้วตามแก้ไม่ทัน
เรื่อง framework กับ agent ตัวเดียวคือจุดเริ่มต้น แต่ยังเหลือคำถามที่บทนี้ยังไม่ตอบ คือถ้าเลือก framework ถูกและเริ่มด้วย agent ตัวเดียวถูกแล้ว ปล่อยให้มันทำงานจริงไปเรื่อยๆ มันจะอยู่ได้นานแค่ไหนก่อนล้ม และใครเป็นคนกำกับดูแลมันอยู่ ตอนหน้าจะพาไปดูคำตอบของสองคำถามนี้
ที่มา
เนื้อหาทั้งหมดมาจากงาน AI Update Bangkok 2026 ที่พี่หมอจิม (Jimmy Tejasen) จัดขึ้นวันที่ 21 สิงหาคม 2026 ที่ The Cloud Bangkok ตอนนี้สรุปจากช่วงที่เขาขึ้นพูดเรื่อง framework ของยุค agent