ยิ่งโมเดลเก่ง ยิ่งต้องถอดของออก: เมื่อ harness ของ AI Agent บวมเกินจำเป็น

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

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

Guy Erez เขียนเรื่อง Your Agent Harness Is Probably Overengineered บน Level Up Coding จากมุมคนที่พลาดมาก่อน เขากางสองเคสของระบบตัวเองพร้อมตัวเลข ทั้ง pull request ที่ถูกปิดทิ้ง และ agent เฝ้าเวร on-call ที่กิน cache-read token ไป 2.1 พันล้าน ผมสะดุดตรงประโยคเปิดที่ว่ายิ่งโมเดลเก่งขึ้น เขากลับยิ่งต้องเอาของออกจาก agent

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

นั่งร้านที่ลืมรื้อ คือหนี้ทางเทคนิคเฉพาะของ agent

นั่งร้านของ Guy Erez เคยทำงานได้ดีบนรุ่น 4.5 และ 4.6 คือวางแผนเอง ตรวจงานตัวเอง แล้วเดินรอบรีวิวเพิ่มก่อนตอบ

พอย้ายมาอยู่บน Fable 5 กับ Opus 5 ที่คิดเป็นขั้นเป็นตอนได้เองอยู่แล้ว harness ชุดเดิมกลับสั่งให้มันสงสัยงานตัวเองซ้ำ วางแผนแล้วทบทวนแผน ตรวจเสร็จแล้วเถียงกับผลตรวจ เผา token ไปกับการรื้อคำตัดสินใจที่ดีอยู่แล้ว

ของที่วัดได้คือไฟล์ prompt สำหรับรีวิวก่อน push เริ่มที่ 22 บรรทัด ตอนนี้ 37 บรรทัด จากรีวิวสองประเภทเป็นสามประเภท และไม่เคยถอดอะไรออกเลย ทุกกฎมีเหตุผลรองรับ เพราะเคยพลาดจริงใน pull request มาก่อน สิ่งที่หายไปคือขั้นที่สอง ไม่มีใครย้อนมาดูว่ากฎนั้นยังคุ้มไหม

เรื่องนี้ไม่ได้เกิดกับทีมเล็กเท่านั้น บทความของเขาอ้างถึงโพสต์ Scaling Managed Agents ของ Anthropic เมื่อเดือนเมษายน 2026 ที่บอกว่าทุกชิ้นใน harness คือสมมติฐานว่าโมเดลทำอะไรเองไม่ได้ และสมมติฐานหมดอายุเมื่อโมเดลเก่งขึ้น

ตัวอย่างในโพสต์คือ Sonnet 4.5 มักรีบสรุปงานเมื่อรู้สึกว่าใกล้ชน context limit อาการที่ทีมเรียกว่า context anxiety ทางแก้ตอนนั้นคือใส่ context reset พอถึง Opus 4.5 อาการหายไปเอง และกลไกนั้น ในคำของ Anthropic เอง คือ “had become dead weight” หรือกลายเป็นน้ำหนักส่วนเกินที่ไม่ได้ทำอะไรแล้ว

ทุกวันนี้พอมีโมเดลใหม่มา Guy Erez เลยให้มันตรวจ harness ของตัวเองก่อนรับงานจริง

ทุกตัวถามว่าโค้ดถูกไหม ไม่มีตัวไหนถามว่าควรมีไหม

สั่งให้ agent หาปัญหาในโค้ด มันหาเจอแน่นอน บางข้อสำคัญจริง บางข้อเป็นแค่เรื่องสไตล์หรือ edge case แบบสมมติที่ยังไม่เคยเกิดจริง ข้อที่แพงที่สุดไม่ใช่ข้อที่ผิด แต่คือ ข้อที่ถูกต้องแต่ไม่สำคัญ

พอกองรวมกันสิบข้อ คำถามจะเปลี่ยนจากว่าข้อนี้จริงไหม เป็นว่าข้อไหนควรสนใจ

นั่งร้านชุดรีวิวของ Guy Erez ทำให้เขาเสีย pull request ไปหนึ่งใบ ตั๋วงานคือ endpoint คืนค่า 500 แทนที่จะเป็น 409 การแก้ที่ถูกและเล็กที่สุดคือ 2 บรรทัดในไฟล์เดียว แต่ของที่ agent ส่งออกมาคือ 13 ไฟล์ เกือบ 500 บรรทัด ใน 3 services

เขาบอกเองว่าบรรทัดส่วนใหญ่เป็น test จึงไม่ได้แย่ไปทั้งหมด แต่ก็ยังใหญ่เกินโจทย์อยู่ดี เบื้องหลังคือ subagent รีวิวเฉพาะทาง 6 ตัว โดย subagent คือผู้ช่วยย่อยที่แตกไปทำงานเฉพาะทางแล้วส่งผลกลับให้ตัวหลัก ทั้งหกตัวไล่ตรวจ diff เดียวกัน เจอปัญหาจริงทุกตัว ตัวหลักแก้ตามทุกข้อ PR เลยพองขึ้น

จบด้วยมนุษย์คนหนึ่งมาเห็น เขียนแพตช์ 2 บรรทัด แล้วเวอร์ชันนั้นคือตัวที่ถูก merge ส่วนก้อนใหญ่ถูกปิดทิ้ง

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

ทางแก้ไม่ใช่การถอดผู้รีวิวออก แต่คือเพิ่มอีกตัวที่ได้คำสั่งตรงข้าม ให้ตั้งต้นว่า diff นี้ไม่ควรมีอยู่ แล้วบังคับให้เจ้าของงานเถียงแต่ละไฟล์กลับเข้ามาเอง คำตัดสินตั้งต้นคือ CUT และผลลัพธ์เหลืออัตราส่วนเดียว คือไฟล์ที่ส่งเทียบกับไฟล์ขั้นต่ำที่จำเป็น

นี่คือนั่งร้านที่ยังคุ้มค่าเช่า เพราะมันค้ำสิ่งที่โมเดลยังไม่ทำเอง คือการถามว่างานก้อนนี้ควรมีอยู่หรือเปล่า บทความยังยกโพสต์ออกแบบ harness ของ Anthropic เมื่อเดือนมีนาคม 2026 มาเสริม ที่แยก coding agent ออกจากตัวประเมิน เพราะ agent ที่ตรวจงานตัวเองมักชมงานตัวเองอย่างมั่นใจ ทั้งที่คนนอกมองว่าคุณภาพกลางๆ แต่คุณค่าของมันขึ้นกับงาน งานง่ายมันเป็นภาระ งานยากมันยังช่วยจริง

ตัวการไม่ใช่โมเดลแพง แต่คือ session ที่นั่งอ่านตัวเองซ้ำ

เคสที่สองของ Guy Erez หนักกว่า เพราะเป็น agent ที่รันตลอดกะ เขาสร้างมันไว้ช่วยเวร on-call ให้เฝ้าแชนเนลวิศวกรรมที่คนเข้าเวรอ่านไม่ไหว

เวอร์ชันแรกเขาใส่มาเต็ม ทั้งเครื่องมือจัดการ maintenance window การไล่ดูสถานะ service และการ query escalation policy เขาเรียกอาการตัวเองว่า oncall-maxxing แล้วถอยมาตั้งหลักกลางทาง

โจทย์จริงมีแค่สองข้อ คือรับทราบเหตุให้ไวพอที่จะไม่มีใครถูกโทรตาม กับเฝ้าแชนเนลให้เรื่องจริงได้รับการเหลียวมอง ข้อแรกต้องการแค่คำสั่งเดียวที่ไม่รับ argument ด้วยซ้ำ ที่เหลือเขาตัดทิ้ง

อีกสัปดาห์ถัดมาเขาพบว่านั่งร้านแบบเดียวกันซ่อนอยู่ลึกลงไปอีกชั้น ตัว loop รันทุก 10 นาทีตลอดกะ และ session เดิมสะสม context ไปเรื่อยๆ ทุกรอบจึงเท่ากับเอาบทสนทนาที่ยาวขึ้นมาอ่านซ้ำในรูป cache read บน Opus

cache read คือ token ที่โมเดลอ่านซ้ำจากบริบทเดิม ถูกกว่า token ใหม่มากแต่ไม่ได้ฟรี พอถึงท้ายกะ ยอดต่อรอบทะลุ 150k token

รวมช่วงที่เขาวัดคือ 2.1 พันล้าน cache-read token คิดเป็นมูลค่าการใช้งานราว $1,050 ตามราคาของทีมเขา ไม่ใช่เงินที่จ่ายออกไปจริง เพราะทีมอยู่บนแพ็กเกจเหมาจ่าย

สิ่งที่ฟ้องจึงไม่ใช่ใบเรียกเก็บเงิน แต่คือโควตารายสัปดาห์ที่เต็ม 100% ทั้งที่อยู่ในช่วงโปรที่แถมมาอีก 50%

ทางแก้ไม่ใช่ prompt ที่ดีกว่า แต่เป็นสถาปัตยกรรมคนละแบบ ทุกรอบจะแตก agent อายุสั้นที่ใช้ Sonnet ไปอ่านเฉพาะของใหม่ จดเวลาที่อ่านล่าสุดของแต่ละแชนเนลลงไฟล์เล็กๆ แล้วคืนมาบรรทัดเดียว session ของ loop จึงแบนราบ โมเดลแพงถูกปลุกเฉพาะตอนตัวเล็กส่งเรื่องขึ้นมา คิดสุทธิคือลบโค้ดออก 79 บรรทัดกับอีกหนึ่ง component

ที่ผมชอบคือเขาไม่หยุดแค่ประเมิน เขาเดาไว้ก่อนว่าต้นทุนต่อรอบจะลดจากราว $0.25 เหลือ $0.03 แล้วลงมือวัดจริง โดยเทียบ 433 iteration ของแบบเก่ากับหนึ่งกะเต็มของแบบใหม่

ต้นทุนต่อ iteration	ที่ประเมินไว้	ที่วัดได้จริง
สถาปัตยกรรมเดิม	~$0.25	~$1.85
สถาปัตยกรรมใหม่	~$0.03	~$0.19

ทิศทางเดาถูก แต่ขนาดประเมินต่ำไปหลายเท่า ของจริงถูกลงราว 10 เท่า นี่คือเหตุผลที่ต้องวัด ไม่ใช่รู้สึกเอา และนี่ยังเป็นผลเบื้องต้นจากกะเดียวหลังเปลี่ยน ยังไม่มีเรื่องสำคัญหลุด เขาบอกเองว่าจะเฝ้าดูต่อ

ที่ต้องพูดให้ชัดคือ ต้นเหตุไม่ใช่การเอาโมเดลแพงมาอ่านแชนเนล งานอ่านเป็นหน้าที่ของ Haiku อยู่แล้ว และกิน cache read ไปไม่ถึง 1% โมเดลถูกเป็นคนทำงาน ส่วนโมเดลแพงนั่งอ่านสิ่งที่ทำไปแล้ว วนแบบนั้นทั้งกะ

บทเรียนจึงมีสองข้อ หนึ่ง อย่าให้โมเดลแพงทำซ้ำสิ่งที่โมเดลถูกทำจบไปแล้ว สอง งานที่ถี่และเดิมพันต่ำ โมเดลที่เก่งกว่าแทบไม่เพิ่มอะไรเลย แต่ตอนต้องมุดเข้าไปแกะปัญหา production ที่ซับซ้อน นั่นแหละคือจังหวะที่มันคุ้มค่าตัว

ของที่ยัดเข้า context ไม่ได้นอนเฉยๆ

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

แต่ของพวกนั้นไม่ได้นอนรออยู่เฉยๆ มันถูกนับเป็นส่วนหนึ่งของโจทย์ที่โมเดลต้องคิดผ่านทุกรอบ ทุกคำสั่งคือของอีกชิ้นที่ต้องตีความ ทุกเครื่องมือคือของอีกชิ้นที่มันอาจต้องหยิบใช้ ผลจึงไม่จบแค่บิลแพงขึ้น แต่คำตอบแย่ลงได้ด้วย Guy Erez สรุปไว้ว่า agent ที่ฉลาดขึ้นต้องการสมาธิ ไม่ใช่ input ที่มากขึ้น

อาการนี้คุ้นมาก ตอนผมเขียนเรื่อง รัน Local LLM ช่วยเขียนเว็บ แล้วเจอ OOM ต้นเหตุก็หน้าตาเดียวกัน คือของที่โตขึ้นทุกรอบจนระบบทรุด ต่างกันตรงรอบนั้นเครื่องฟ้องด้วย error ให้เห็นกับตา ส่วนรอบนี้มันไม่ฟ้องอะไรเลย แค่เงียบๆ แพงขึ้นและช้าลง ซึ่งอันตรายกว่า

คำถามจึงควรกลับด้าน แทนที่จะถามว่าใส่อะไรเพิ่มดี ให้ถามว่า เอาอะไรออกได้บ้างโดยที่ agent ไม่แย่ลง

everything-maxxing กับ agentic engineering ต่างกันตรงไหน

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

ทุกชิ้นใน harness คือสมมติฐาน skill ตัวนี้อาจทำให้เขียนโค้ดดีขึ้น hook ตัวนี้อาจดักความพังของจริงได้ subagent ที่เยอะกว่าอาจทำให้งานจบไวกว่า คำว่าอาจทั้งหมดคือการเดา ไม่ใช่ข้อเท็จจริง

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

วิธีของ Anthropic ที่บทความยกมาก็เดินแบบเดียวกัน คือสร้าง harness ที่ซับซ้อนขึ้นมาก่อน มันได้ผล แล้วค่อยถอดออกทีละชิ้นเพื่อดูว่าชิ้นไหนยังจำเป็น ขั้นซอยงานเป็น sprint คือชิ้นที่ถูกถอด เพราะเมื่อ Opus 4.6 ดีขึ้นถึงระดับหนึ่ง มีเหตุผลให้เชื่อว่าโมเดลจัดการเองได้ ถอดทีละชิ้นแบบนี้จึงบอกได้ว่าอะไรพัง ต่างจากการรื้อทีเดียวทั้งชุด

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

มีคำพูดเก่าที่คนมักยกให้ Abraham Lincoln ทำนองว่า ถ้าให้เวลาหกชั่วโมงไปโค่นต้นไม้ เขาจะใช้สี่ชั่วโมงแรกลับขวาน งานน่าเบื่อที่ว่ามาทั้งหมดคือสี่ชั่วโมงนั้น

Recap: checklist ที่เริ่มพรุ่งนี้ได้

• โมเดลใหม่มาถึง ให้ตรวจ harness ก่อนรับงาน — context reset ที่เคยจำเป็นบน Sonnet 4.5 กลายเป็นน้ำหนักส่วนเกินบน Opus 4.5
• ไฟล์ prompt ที่มีแต่โตขึ้น คือสัญญาณ — 22 เป็น 37 บรรทัดโดยไม่เคยถอดอะไรออก
• เพิ่มผู้รีวิวที่ตั้งต้นว่า CUT — บีบผลลัพธ์ให้เหลือตัวเลขเดียว คือไฟล์ที่ส่งเทียบกับไฟล์ขั้นต่ำ PR 13 ไฟล์ใบนั้นมนุษย์จับได้ก่อน เขาเลยเพิ่มตัวนี้ไว้ดักรอบหน้า
• แยกผู้ทำงานออกจากผู้ประเมิน — งานง่ายผู้ประเมินคือภาระ งานยากมันยังให้ผลจริง
• ไล่ดูว่า session ไหนกำลังอ่านตัวเองซ้ำ — ต้นทุนของ agent ที่รันยาวมักอยู่ที่ transcript ที่โตขึ้นแล้วถูกอ่านซ้ำทุกรอบ
• ทำ loop ระยะยาวให้ session แบนราบ — ใช้ agent อายุสั้นรับงานถี่ แล้วปลุกโมเดลใหญ่เมื่อถูก escalate
• ประเมินได้ แต่ต้องวัดจริง — เคสนี้เดาว่า $0.25 เหลือ $0.03 ของจริงคือ $1.85 เหลือ $0.19
• ลบทีละชิ้น ไม่ใช่ทีเดียวทั้งชุด — จะได้รู้ว่าชิ้นไหนยังคุ้ม

ยิ่งโมเดลเก่งขึ้น รายการที่ต้องถอดออกก็ยิ่งยาว เริ่มจากชิ้นเดียวที่เราแอบสงสัยมานานที่สุดก่อนก็พอครับ

อ่านต่อ

• บทความต้นทาง: Guy Erez — Your Agent Harness Is Probably Overengineered
• เมื่อ AI Agent หลุด Sandbox — อีกด้านของการให้เครื่องมือกับ agent เกินจำเป็น
• Jalapeño ชิป Inference ของ OpenAI — เรื่องเดียวกันฝั่งฮาร์ดแวร์ ตัวเลขที่ดูดีต้องรู้ว่าวัดที่จุดไหน ไม่งั้นก็เดาถูกทิศแต่ผิดขนาด
• รัน Local LLM ช่วยเขียนเว็บ แล้วเจอ OOM — อีกเคสที่ต้นเหตุคือ context ที่โตขึ้นจนระบบทรุด
• ดูบทความอื่นในแท็ก ai และ performance