บนเวที พี่หมอจิมวางตัวเลข 2 ตัวไว้ข้างกัน แล้วถามคำถามเดียวตรงๆ ว่าจะจ้างใคร ตัวเลขแรกคือคะแนนสอบเขียนโค้ด อยู่ที่ราว 96% ตัวเลขที่สองคืองานใช้คอมพิวเตอร์เองแบบยาวต่อเนื่อง หรือ long-horizon computer use อยู่ที่ราว 20.6% เท่านั้น เขาทิ้งประโยคไว้ข้างตัวเลขคู่นี้แค่บรรทัดเดียว
เก่งข้อสอบ ไม่เท่า ทำงานจริงจบ
คอขวดของ agent ปี 2026 ไม่ได้อยู่ที่การสร้างอีกต่อไป แต่ย้ายไปอยู่ที่การดูแล และตัวเลขคู่นี้คือจุดที่เห็นการเปลี่ยนนั้นชัดที่สุด เพราะสิ่งที่มันชี้ไม่ใช่แค่ว่างานไหนเก่งงานไหนอ่อน แต่เป็นการเปลี่ยนนิยามของคำว่าวัดผลไปทั้งยวง
วัดกันด้วยเวลา ไม่ใช่ความถูกต้องอีกต่อไป
เดิมที benchmark วัดกันว่าคำตอบถูกไหม แต่ long horizon เปลี่ยนหน่วยวัดไปเป็นเวลา ตัวชี้วัดกลายเป็นว่างานหนึ่งรันต่อเนื่องได้นานแค่ไหนก่อนจะล้ม จุดที่เขาใช้อ้างอิงคือจุดที่ครึ่งหนึ่งของความพยายามทั้งหมดยังสำเร็จอยู่ พูดง่ายๆ คือไม่ได้ถามว่า agent ตอบถูกกี่เปอร์เซ็นต์ แต่ถามว่าถ้าปล่อยให้มันทำงานคนเดียวยาวๆ มันจะรอดไปถึงไหนก่อนเริ่มเดินหลุดทาง
ตรงนี้เองที่ทำให้ 96% กับ 20.6% เทียบกันตรงๆ ไม่ได้ด้วยซ้ำ เพราะ 2 ตัวนี้วัดกันคนละมิติ ตัวแรกวัดความถูกในโจทย์ที่จบในตัว ตัวที่สองวัดความอึดในงานที่ไม่มีจุดจบชัดเจน แล้วความอึดต่างหากที่งานจริงส่วนใหญ่ในองค์กรต้องการมากกว่าความถูกแบบข้อสอบ
context คือคอขวดของความจำ ที่ยังไม่มีใครแก้ได้
เหตุผลหนึ่งที่ทำให้ agent ล้มกลางทางคือ อินพุตของ context ต่อการเรียกหนึ่งครั้งอยู่ที่หลักหมื่นถึงหลักแสน token ขณะที่เอาต์พุตมีอยู่แค่หลักร้อย token กำลังประมวลผลส่วนใหญ่จึงหมดไปกับการอ่านของเดิมซ้ำ ไม่ใช่กับการคิดเรื่องใหม่ ยิ่ง context ยาว ยิ่งกินหน่วยความจำทำงานมาก บนโมเดลขนาดใหญ่ context ยาว 1 ชุดกินหน่วยความจำทำงานหลักสิบกิกะไบต์ และเขาบอกไว้ตรงๆ ว่ายังไม่มีวิธีไหนแก้เรื่องนี้ได้จริงในตอนนี้
ตรงนี้อธิบายได้ว่าทำไมงานยาวถึงพังกลางทาง ไม่ใช่เพราะโมเดลลืมว่าโจทย์คืออะไร แต่เพราะยิ่งทำงานนานเท่าไร ภาระในการแบกของเดิมไว้ในหัวก็ยิ่งหนักขึ้นเท่านั้น จนถึงจุดหนึ่งที่มันเริ่มเดินหลุดทางไปเอง โดยที่ไม่ได้ผิดตั้งแต่ต้น
ทำไมโค้ดไปได้ไกล ทำไมหน้าจอไปได้ช้า
สาเหตุที่ตัวเลข 2 ตัวห่างกันขนาดนี้ไม่ใช่เรื่องบังเอิญ งานเขียนโค้ดไปได้ไกลที่สุดเพราะมันตรวจสอบได้ ขอบเขตงานชัดเจน ผลลัพธ์วัดได้ตรงไปตรงมา รางวัลก็ชัดตามไปด้วย รันเทสต์แล้วรู้ทันทีว่าผ่านหรือไม่ผ่าน ไม่ต้องเถียงกัน
งานใช้คอมพิวเตอร์ล้าหลังกว่าด้วยเหตุผลตรงข้ามกันเป๊ะ งานเปิดกว้าง ไม่มีเทสต์ให้รันจบในตัว ต้องมองหน้าจอตีความเอาเองว่าตรงไหนถูกตรงไหนผิด แล้วยังทำได้ช้ากว่าคนทำเองหลายเท่าตัวด้วย ต่อให้ agent ไม่หลุดทางเลยสักครั้ง ความเร็วก็ยังเป็นอุปสรรคอยู่ดี
พูดอีกแบบคือ โค้ดดูฉลาดกว่างานหน้าจอ ไม่ใช่เพราะโมเดลเก่งเรื่องโค้ดมากกว่าเรื่องอื่น แต่เพราะโค้ดให้ทางตรวจสอบตัวเองที่งานหน้าจอไม่มีให้
สเกลขึ้น ปัญหาที่โผล่มาไม่ใช่ความสามารถ
พอขยับจากงานเดี่ยวไปที่สเกลระดับองค์กร ปัญหาที่โผล่มาเปลี่ยนหน้าไปเลย ไม่ใช่เรื่องว่าโมเดลเก่งพอไหมอีกต่อไป แต่เป็นเรื่องว่าใครกำกับดูแลมันอยู่ Gartner คาดว่าจำนวน agent ในบริษัทกลุ่ม Fortune 500 จะเพิ่มจากน้อยกว่า 15 ตัว ไปเป็นมากกว่า 150,000 ตัวภายในปี 2028 ต้นทุนต่อ workflow ก็เพิ่มขึ้นตามไปด้วยถึง 5 เท่าภายในปีเดียวกัน ขณะที่องค์กรที่มีระบบกำกับดูแลพร้อมใช้งานจริงอยู่ที่ 13% เท่านั้น จำนวนโตขึ้นหลักหมื่นเท่าในเวลาไม่กี่ปี แต่คนที่กำกับได้จริงมีอยู่แค่ 13% เท่านั้น ช่องว่างระหว่าง 2 ตัวนี้ต่างหากที่น่ากังวลกว่าตัวเลขต้นทุนเสียอีก เขาสรุปเองตรงจุดนี้ว่าคอขวดย้ายจากการสร้างไปเป็นการดูแลรักษา
โมเดลเล็กกลายเป็นตลาดของตัวเอง
อีกสัญญาณที่เขาแยกออกมาเป็นตลาดของตัวเองไปเลยคือโมเดลขนาดเล็ก โมเดลระดับพันล้านพารามิเตอร์ต้นๆ ที่รันบนอุปกรณ์ได้เองโดยไม่ต้องพึ่ง cloud หรือที่วงการเรียกกันว่างานฝั่ง edge ได้ครบสามอย่างในดีลเดียว คือความเป็นส่วนตัว ความหน่วงต่ำ และต้นทุนที่ลดลง เขายังบอกด้วยว่าตลาดโมเดลขนาดเล็กนี้ถูกคาดว่าจะโตเฉลี่ย 28.7% ต่อปี ตัวเลขนี้เป็นตัวเลขคาดการณ์ ไม่ใช่ของที่วัดมาแล้ว จึงควรอ่านเป็นทิศทางกว้างๆ มากกว่าตัวเลขที่ตายตัว
เรื่องนี้ต่อกับเรื่องกำกับดูแลพอดี เพราะถ้าองค์กรกำลังปวดหัวกับการดูแล agent จำนวนมากบน cloud อยู่แล้ว การมีบางงานที่รันบนเครื่องได้เองโดยไม่ต้องส่งข้อมูลออกไปไหนเลย ก็ช่วยลดขอบเขตงานที่ต้องกำกับดูแลลงไปได้ส่วนหนึ่งเหมือนกัน ไม่ใช่ทางแก้ทั้งหมด แต่เป็นทางลดความเสี่ยงในบางจุด
ประโยคปิดที่คุมทั้งบท
ประโยคปิดของช่วงนี้คือประโยคที่ใช้ได้จริงที่สุด agent ปี 2026 ไม่ได้ขาดความฉลาด แต่ขาดความอึดและขาดการดูแล สนามแข่งต่อไปจึงอยู่ที่สามเรื่องพร้อมกัน คือระยะยาวของงาน การกำกับดูแล และงานที่รันอยู่ฝั่ง edge
ตอนที่แล้วเราพูดถึงเรื่องเลือก framework กับการเริ่มด้วย agent ตัวเดียวก่อนเสมอ ตอนนี้คือคำอธิบายว่าทำไมถึงต้องเริ่มเล็ก ไม่ใช่เพราะระมัดระวังเกินไป แต่เพราะตัวเลข 20.6% บอกตรงๆ ว่างานยาวยังเป็นจุดที่ agent ล้มบ่อยที่สุด และยิ่งงานยาว ยิ่งต้องมีคนคุมอยู่ใกล้ๆ ไม่ใช่ปล่อยแล้วเดินจากไป
เอาไปใช้วางแผนปีหน้ายังไง
ถ้ากำลังวางแผนเอา agent เข้ามาใช้ในทีมปีหน้า คำถามแรกไม่ควรเป็นว่าจะเลือกโมเดลตัวไหนที่คะแนนสอบสูงสุด เพราะคะแนนสอบตอบได้แค่ว่างานบนขอบเขตชัดจะไปได้ไกลแค่ไหน ไม่ได้ตอบว่างานที่ต้องปล่อยให้ทำเองยาวๆ จะรอดถึงไหน
งานที่ควรให้ agent ทำก่อนคืองานที่ตรวจสอบผลได้ชัดแบบงานเขียนโค้ด ส่วนงานเปิดกว้างแบบงานหน้าจอเต็มรูปแบบ ให้รอจนกว่าจะมีจุดให้คนเช็คงานที่ล้มได้ก่อน
ส่วนเรื่องกำกับดูแล อย่ารอให้จำนวน agent ในทีมโตจนเกินจะดูแลไหวก่อนแล้วค่อยเริ่มวางระบบ 13% คือสัดส่วนองค์กรที่มีระบบพร้อมอยู่ตอนนี้ ถ้าทีมยังไม่มีจุดให้คนเช็คงานที่ agent ทำ นั่นแปลว่ากำลังอยู่ในกลุ่มส่วนใหญ่ที่ยังไม่พร้อม ไม่ใช่ข้อยกเว้นของใคร
ที่มา
เนื้อหาทั้งหมดมาจากงาน AI Update Bangkok 2026 ที่พี่หมอจิม (Jimmy Tejasen) จัดขึ้นวันที่ 21 สิงหาคม 2026 ที่ The Cloud Bangkok ตอนนี้สรุปจากช่วงที่เขาขึ้นพูดเรื่องความอึดของ agent และการกำกับดูแล