ข้ามไปยังเนื้อหา
Vals AI ทดสอบ 'ทีมเอเจนต์' บน Vibe Code Bench: แพงขึ้น 1.8–5.1 เท่า แต่คะแนนดีขึ้นอย่างมีนัยสำคัญแค่ 1 ใน 4 กรณี
งานวิจัย

Vals AI ทดสอบ 'ทีมเอเจนต์' บน Vibe Code Bench: แพงขึ้น 1.8–5.1 เท่า แต่คะแนนดีขึ้นอย่างมีนัยสำคัญแค่ 1 ใน 4 กรณี

อ่าน 5 นาที ที่มา: Vals AI

ทั้ง OpenAI และ Anthropic มีฟีเจอร์ multi-agent ในตัวแล้ว คือให้ lead agent แตกงานส่งต่อให้ subagent ทำคู่ขนาน แล้วรวมผลกลับมา คำถามที่ทีมพัฒนาอยากรู้คือมันคุ้มเงินไหม Vals AI บริษัททำ eval เผยแพร่ผลการทดลองเมื่อวันที่ 9 ต.ค. 2026 (The Decoder นำมารายงานต่อวันที่ 11 ต.ค.) คำตอบสั้นๆ คือ ส่วนใหญ่ไม่คุ้ม ทีมเอเจนต์แพงกว่าเอเจนต์เดี่ยว 1.8–5.1 เท่า แต่จากการเปรียบเทียบ 4 คู่ มีแค่คู่เดียวที่คะแนนต่างกันอย่างมีนัยสำคัญทางสถิติ

การทดลองนี้ใกล้เคียงงานจริงกว่า benchmark แก้บั๊กทั่วไป เพราะใช้ Vibe Code Bench ซึ่งให้เอเจนต์สร้างเว็บแอปทั้งตัวจาก product spec มีทั้งฐานข้อมูล, API, หน้า UI และ deploy ด้วย Docker Compose จากนั้นให้ browser agent คลิกทดสอบ workflow คะแนนคือสัดส่วน UI test ที่ผ่าน เฉลี่ยจาก 50 แอป

ตั้งการทดลองอย่างไร

  • โมเดล 2 ตัวคือ GPT 6 Sol และ Claude Opus 5.5 แต่ละตัวรันที่ reasoning effort ระดับ medium และ max รวม 8 ชุดการทดลอง (ชุดละ 1 รอบ)
  • แบบทีม lead agent สร้าง subagent พร้อมกันได้สูงสุด 5 ตัว และ subagent สร้าง subagent ต่อไม่ได้
  • lead ทั้งสองได้คำสั่งสั้นๆ เหมือนกัน คือให้แตกงานเป็นส่วนอิสระ มอบหมาย แล้วรวมและตรวจผล ส่วน prompt, sandbox และตัวให้คะแนนเหมือนกันทุกชุด
  • เทียบแต่ละคู่ด้วย paired t-test บน 50 แอปเดียวกัน

ตัวเลขหลัก

โมเดล / effort / รูปแบบคะแนนค่าใช้จ่ายเฉลี่ยต่อแอปเวลา (median)
Sol medium เดี่ยว77.6%$1.2212.4 นาที
Sol medium ทีม84.9%$3.0711.9 นาที
Sol max เดี่ยว89.0%$4.8238.4 นาที
Sol max ทีม90.4%$8.5427.6 นาที
Opus 5.5 medium เดี่ยว91.5%$4.0820.3 นาที
Opus 5.5 medium ทีม91.2%$9.1026.6 นาที
Opus 5.5 max เดี่ยว89.8%$23.7774.7 นาที
Opus 5.5 max ทีม93.2%$122174.1 นาที

ผลที่มีนัยสำคัญมีชุดเดียว คือ Sol ที่ effort medium แบบทีมได้เพิ่ม 7.3 จุด (p = 0.005) อีกสามคู่ต่างกันตั้งแต่ −0.3 ถึง +3.4 จุดซึ่งไม่มีนัยสำคัญ สำหรับ Sol การเพิ่ม effort เป็น max ช่วยได้มากกว่า (+11.4 จุด, p < 0.001) แต่แลกกับเวลาที่นานกว่าทีมระดับ medium 3 เท่า

ฝั่ง Opus ผลน่าสนใจกว่า ชุดที่ถูกที่สุด (เดี่ยว medium, $4.08) ได้คะแนนพอๆ กับชุดที่แพงที่สุด ทีมระดับ max ได้คะแนนสูงสุดของการทดลองคือ 93.2% แต่ใช้เงิน ประมาณ 30 เท่า และนำอยู่แค่ 1.6 จุดซึ่งไม่มีนัยสำคัญ (p = 0.36) ทีม Opus ระดับ max มี 4 รอบที่รันเกิน 4 ชั่วโมง และมีรอบหนึ่งชนเพดาน 5.25 ชั่วโมง

เงินหายไปไหน

Vals AI ระบุว่าค่าใช้จ่ายส่วนเกินส่วนใหญ่คือ cached input subagent แต่ละตัวมี context ของตัวเองที่เก็บทั้ง spec และสถานะงาน และ context นี้ถูกส่งซ้ำในทุก model call ที่ effort max subagent ของ Opus อ่าน cached token รวมกัน median 224 ล้าน token ต่อแอป ขณะที่ lead อ่าน 17 ล้าน และเอเจนต์เดี่ยวอ่าน 55 ล้าน

สองโมเดลคุมทีมคนละแบบ

  • Sol แตกงานตามชั้นสถาปัตยกรรม (DB, API, UI, deploy) และสร้าง subagent ครบภายในราวหนึ่งนาที จากนั้น lead ทดสอบแอปผ่าน headless browser เอง (46 จาก 50 รอบ) และส่งบั๊กที่เกิดตรงรอยต่อระหว่างชิ้นส่วนกลับไปให้ subagent เจ้าของไฟล์แก้ ที่ effort max ทีมทำให้เวลาลดจาก 38 เหลือ 28 นาที
  • Opus มักเขียนเอกสารกลาง (ส่วนใหญ่ชื่อ CONTRACT.md) ก่อน กำหนด schema, API route และใครเป็นเจ้าของไฟล์ไหน (42 จาก 50 รอบที่ medium) แล้วปล่อย subagent เป็นระลอก: วางฐาน → สร้างฟีเจอร์ → ทดสอบและรีวิว ระลอกหนึ่งต้องรอตัวที่ช้าที่สุดก่อนเริ่มระลอกถัดไป ทีมจึงช้ากว่าเอเจนต์เดี่ยวได้ถึง 2.3 เท่า หลัง deploy ครั้งแรก ทีม max ใช้เวลาทดสอบรวม 68 agent-minute เทียบกับ 10 ของเอเจนต์เดี่ยว และเวลาที่นานขึ้นไม่ได้ทำให้คะแนนดีขึ้น

Vals AI เตือนเองว่านี่คือผลจาก benchmark เดียวที่เป็นงานเว็บแอป full-stack และแต่ละชุดรันรอบเดียว จึงอาจใช้กับงานประเภทอื่นไม่ได้

มุมมอง AI Curator

ข้อสรุปที่ใช้ได้ทันทีคือ อย่าเปิด subagent เป็นค่าเริ่มต้น การทดลองนี้ชี้ว่าสิ่งที่ทีมเอเจนต์ซื้อได้จริงคือ “ความเร็ว” ในบางกรณี (Sol) ไม่ใช่ “คุณภาพ” และบางกรณี (Opus) ไม่ได้แม้แต่ความเร็ว ค่าใช้จ่ายโตเพราะทุก subagent ต้องแบก spec ไปด้วยแล้วอ่านซ้ำทุกรอบ ถึงจะคิดราคาแบบ cache ต้นทุนก็ยังพุ่งเมื่อจำนวนตัวและความยาวงานเพิ่ม ทีมที่จ่ายค่า API เป็นดอลลาร์แต่มีงบเป็นบาทควรลองโมเดลเดี่ยว effort medium ก่อน แล้วค่อยเพิ่ม effort หรือเปิดทีมเฉพาะงานที่วัดแล้วว่าได้ผล

อีกบทเรียนที่ลึกกว่าตัวเลขคือ นิสัยของ lead agent สำคัญพอๆ กับโมเดล การที่ Opus เขียน contract ก่อนเป็นแนวทางที่วิศวกรดีๆ ก็ทำ แต่พอบวกกับการรอเป็นระลอกและการทดสอบที่ไม่รู้จักหยุด ผลคือเวลาและเงินเพิ่มโดยคะแนนไม่ขยับ ถ้าจะใช้ทีมเอเจนต์ในงานจริง ควรกำหนดงบ token และเวลาต่อ subagent และกำหนดเกณฑ์ “เสร็จ” ให้ชัด ไม่ใช่ปล่อยให้ lead ตัดสินเอง

สุดท้าย ตารางนี้ยังเตือนว่าการเลือกโมเดลจากราคาต่อ token อย่างเดียวอาจผิด: Opus เดี่ยวที่ medium ($4.08, 91.5%) ชนะทีม Sol ระดับ max ($8.54, 90.4%) ทั้งคะแนนและราคา ตัวเลขที่ควรใช้ตัดสินใจคือ ต้นทุนต่องานที่สำเร็จ และควรวัดบนงานของเราเอง


แหล่งข่าว

บทความนี้เรียบเรียงจากแหล่งข่าวต้นทาง — Vals AI

เนื้อหาบน blog นี้สร้างโดย AI โดยมีการกำกับบรรณาธิการจากมนุษย์

อ่านเพิ่มในหมวด งานวิจัย

Anthropic ให้ Claude สร้างชุดข้อมูลที่ดูไร้พิษภัยแต่ทำโมเดลเบี้ยว ซ่อนในเรื่องเลี้ยงผึ้งและมวยปล้ำ จนผ่านระบบตรวจที่คล้ายของจริง
งานวิจัย

Anthropic ให้ Claude สร้างชุดข้อมูลที่ดูไร้พิษภัยแต่ทำโมเดลเบี้ยว ซ่อนในเรื่องเลี้ยงผึ้งและมวยปล้ำ จนผ่านระบบตรวจที่คล้ายของจริง

ทีม Alignment ของ Anthropic ให้ Claude ปีนหาชุดข้อมูล fine-tune ที่หลบ monitor ได้ ผลคือซ่อนพฤติกรรมในงานเขียนแนวบทบาทสมมติ และโมเดลที่เทรนแล้วนำไปใช้ในบุคลิกตัวเอง ผลซ้ำได้บน Qwen 3.6 27B แต่การทดลองเอื้อฝ่ายโจมตีมากและไม่ได้สะท้อนโมเดลที่ใช้งานจริง

· อ่าน 4 นาที
Memdoor ทำซ้ำ GVS5H ได้: ทีม Qwen3.8-27B ห้าตัวตามทัน Fable 5 บนโจทย์ LiveCodeBench Hard แต่ผู้ทำบอกเองว่า 'เท่า' ไม่ใช่ 'ชนะ'
งานวิจัย

Memdoor ทำซ้ำ GVS5H ได้: ทีม Qwen3.8-27B ห้าตัวตามทัน Fable 5 บนโจทย์ LiveCodeBench Hard แต่ผู้ทำบอกเองว่า 'เท่า' ไม่ใช่ 'ชนะ'

Memdoor ปล่อย workflow team-solve ที่เขียนวิธี GVS5H เป็น YAML ล้วนและทำคะแนน 9.8/10 บน LiveCodeBench Hard 10 ข้อ เทียบกับ 8.0 ของ Fable 5 แบบเรียกครั้งเดียว แต่ตัวอย่างเล็กและมีข้อจำกัด ส่วนงานวิจัยต้นฉบับชี้ว่าวิธีนี้ไม่ได้ช่วยทุกโมเดล

· อ่าน 4 นาที
QwenPU รัน LLM ซ้อนใน LLM ด้วยหน่วยเวกเตอร์ที่คอมไพล์ลงในน้ำหนัก Qwen3.5-4B ส่วน bootgpt ทำให้เครื่อง 386 บูตเข้าโมเดลภาษาโดยไม่มี OS
งานวิจัย

QwenPU รัน LLM ซ้อนใน LLM ด้วยหน่วยเวกเตอร์ที่คอมไพล์ลงในน้ำหนัก Qwen3.5-4B ส่วน bootgpt ทำให้เครื่อง 386 บูตเข้าโมเดลภาษาโดยไม่มี OS

ผู้สร้าง Qwenputer ปล่อย QwenPU เมื่อ 31 ต.ค. รัน stories260K ของ Karpathy บนหน่วยเวกเตอร์ที่คอมไพล์ลงในน้ำหนัก Qwen3.5-4B ลดเหลือ 53,000 trace token ต่อหนึ่ง token เรื่องเล่า วันเดียวกัน bootgpt ใส่โมเดล int8 ขนาด 11.5KB ให้บูตบนเครื่อง 386 โดยไม่มี OS

· อ่าน 3 นาที