Harness Engineering: ยุคที่การออกแบบสภาพแวดล้อมการทำงานสำคัญกว่าตัวโมเดล

นี่คือบทวิเคราะห์เกี่ยวกับ “Harness Engineering” ที่ Addy Osmani เรียบเรียงไว้ เขาวินิจฉัยว่าในช่วง 2 ปีที่ผ่านมา ความสนใจของวงการพุ่งไปที่คำถามว่า “โมเดล AI ตัวไหนฉลาดกว่ากัน” เพียงอย่างเดียว มีการเปรียบเทียบกันไม่รู้จบว่า GPT เขียนโค้ดได้เนี้ยบกว่าหรือไม่ หรือ Claude มีอาการหลอนน้อยกว่าหรือไม่ แต่ข้อโต้แย้งของเขาคือ ผลลัพธ์ของ AI สำหรับงานเขียนโค้ดจริง ๆ นั้นไม่ได้ถูกตัดสินด้วยตัวโมเดลเพียงอย่างเดียว หากแต่ถูกกำหนดโดยฮาร์เนสที่ล้อมรอบโมเดลนั้นมากกว่า คำว่า harness เป็นคำรวมสำหรับทุกอย่างที่ไม่ใช่ตัวโมเดล เช่น system prompt ที่ใช้สั่งงาน AI, เครื่องมือและเซิร์ฟเวอร์ภายนอกที่ใช้งานได้, นโยบายการจัดการคอนเท็กซ์, กลไกตรวจสอบอัตโนมัติที่แทรกระหว่างการทำงาน (hook), พื้นที่รันที่ปลอดภัย (sandbox), AI ผู้ช่วย (subagent), วงจรป้อนกลับ (feedback loop) ไปจนถึงขั้นตอนกู้คืนเมื่อการทำงานติดขัด Viv Trivedy ทำให้แนวคิดนี้เป็นทางการด้วยประโยคสั้น ๆ ว่า “AI agent = model + harness” และคนอย่างทีมวิศวกรรมของ Anthropic, HumanLayer, Simon Willison ก็กำลังขัดเกลาแนวทางนี้ให้ซับซ้อนและแม่นยำขึ้น Osmani มองว่ากระแสนี้ได้ตั้งหลักเป็นสาขาวิศวกรรมแขนงหนึ่งแล้ว

หากขยายประเด็นหลักออกมา จะได้ประมาณนี้

• ฮาร์เนสคืออะไร แค่โมเดลอย่างเดียวไม่สามารถทำให้ AI กลายเป็นผู้ช่วยที่ทำงานจนจบได้ ต้องมีโค้ดและการตั้งค่าที่ช่วยให้มันจำความคืบหน้าได้, เรียกใช้เครื่องมือได้, ดูผลลัพธ์แล้วตัดสินใจใหม่ได้, และป้องกันไม่ให้ทำสิ่งที่ไม่ควรทำ จึงจะกลายเป็น “AI ที่ทำงานได้จริง” ผลิตภัณฑ์อย่าง Claude Code, Cursor, Codex, Aider, Cline ล้วนเป็นฮาร์เนส และแม้จะใช้โมเดลตัวเดียวกัน พฤติกรรมที่ผู้ใช้รับรู้ได้ก็ขึ้นอยู่กับฮาร์เนส ตามคำอธิบายของ Simon Willison, AI agent คือ “ระบบที่วนใช้เครื่องมือซ้ำ ๆ เพื่อให้บรรลุเป้าหมาย” และสาระสำคัญของความสามารถก็คือการออกแบบเครื่องมือและโครงสร้างการวนซ้ำเหล่านั้นอย่างไร

• มองว่าเป็นปัญหาการตั้งค่า ไม่ใช่ความผิดของโมเดล เมื่อ AI ทำอะไรเพี้ยน ๆ วิศวกรมักโทษโมเดลและจบลงที่ข้อสรุปว่า “รอเวอร์ชันถัดไปก็แล้วกัน” Harness Engineering ปฏิเสธปฏิกิริยาแบบนี้ ตามคำของ HumanLayer นี่คือ “ไม่ใช่ปัญหาของโมเดล แต่เป็นปัญหาของการตั้งค่า (skill issue)” แม้จะใช้ Claude Opus 4.6 ตัวเดียวกัน หากอยู่ในฮาร์เนสมาตรฐานอย่าง Claude Code ก็อาจอยู่แถวล่างของ Terminal Bench 2.0 แต่เมื่อย้ายไปอยู่ในฮาร์เนสที่ปรับแต่งเองกลับกระโดดขึ้นไปอยู่กลุ่มบนได้ ทีมของ Viv เคยยกระดับโมเดลตัวเดิมจากอันดับราวช่วง 30 ไปเป็นช่วง 5 ได้เพียงแค่เปลี่ยนฮาร์เนส นั่นหมายความว่าศักยภาพของโมเดลมักถูกฮาร์เนสบั่นทอนอยู่ไม่น้อย

• หลักการ “ratchet” ที่ทำให้ความผิดพลาดกลายเป็นกฎถาวร ถ้า AI เคยทำพลาดแม้เพียงครั้งเดียว จะไม่ปล่อยให้เป็นอุบัติเหตุชั่วคราว แต่ถือเป็นสัญญาณถาวร แล้วค่อย ๆ ขันให้แน่นขึ้นทีละขั้นเพื่อไม่ให้พลาดแบบเดิมอีก เช่น เพิ่มบรรทัดหนึ่งในเอกสารกฎ ติดกลไกบล็อกอัตโนมัติ หรือให้มี AI ผู้ช่วยทำหน้าที่รีวิว ตัวอย่างเช่น หาก AI เคยคอมเมนต์ทิ้ง test code เวอร์ชันถัดไปของเอกสารกฎก็จะมีบรรทัดว่า “ห้ามคอมเมนต์ test ให้ลบหรือแก้ไขแทน” และในขั้นตรวจก่อน commit ก็จะมีตัวตรวจจับ pattern แบบนั้นเพิ่มเข้ามา หัวใจสำคัญคือทุกบรรทัดในเอกสารกฎที่ดีควรเชื่อมโยงกับความล้มเหลวจริงที่เคยเกิดขึ้น ดังนั้น Harness Engineering จึงไม่ใช่การหยิบ framework ของคนอื่นมาใช้ตรง ๆ แต่ใกล้เคียงกับ “วินัย” ที่ค่อย ๆ บ่มเพาะตามประวัติความล้มเหลวของ codebase ตัวเองมากกว่า

• ออกแบบย้อนกลับจากพฤติกรรมที่ต้องการ วิธีคิดที่ Viv เสนอและมีประโยชน์มากคือ “ต้องการพฤติกรรมแบบนี้ → ฮาร์เนสชิ้นส่วนใดทำให้เกิดพฤติกรรมนั้นได้” แล้วออกแบบย้อนกลับจากจุดนั้น หากอธิบายไม่ได้ในหนึ่งบรรทัดว่าองค์ประกอบใดมีไว้เพื่อรองรับพฤติกรรมอะไร ก็มักจะดีกว่าถ้าตัดมันออก ตัวอย่างเช่น file system และ Git ใช้เพื่อเก็บงานระยะยาวและย้อนกลับได้, bash และการรันโค้ดเป็นเครื่องมือสารพัดประโยชน์สำหรับลองได้ทุกอย่าง, sandbox คือพื้นที่รันปลอดภัยที่พังได้โดยไม่กระทบระบบหลัก, ไฟล์หน่วยความจำและเครื่องมืออย่าง web search·MCP เป็นช่องทางสะสมความรู้ใหม่, การสรุปบีบอัดและการแยกผลลัพธ์ของเครื่องมือ รวมถึงฟีเจอร์ skill เป็นอุปกรณ์ช่วยขยายข้อจำกัดด้านความจำของ AI, และ Ralph loop กับโครงสร้างแยก planner/evaluator คือวิธีพางานยาวหลายวันไปจนจบ

• ปัญหา context rot AI มีขีดจำกัดด้านปริมาณข้อความที่อ่านได้ในคราวเดียว และยิ่งเข้าใกล้ขีดจำกัดนั้น ความสามารถในการตัดสินใจก็ยิ่งตกลงอย่างเห็นได้ชัด เพราะฉะนั้นฮาร์เนสจึงเป็นชุดกลไกสำหรับใช้พื้นที่จำกัดนั้นให้มีประสิทธิภาพ อย่างแรก เมื่อใกล้เต็มก็ต้องสรุปของเก่าอย่างชาญฉลาดเพื่อลดขนาด อย่างที่สอง ถ้าเป็นผลลัพธ์ขนาดใหญ่อย่าง log 2,000 บรรทัด ก็จะคงไว้แค่ส่วนต้นกับท้าย แล้วแยกเนื้อหาหลักไปเก็บในไฟล์เพื่อให้อ่านกลับเมื่อจำเป็น อย่างที่สาม จะไม่แสดงเครื่องมือและคำสั่งทั้งหมดตั้งแต่แรก แต่ใช้วิธี “เปิดเผยแบบค่อยเป็นค่อยไป” โดยหยิบมาให้เฉพาะเมื่อจำเป็นจริงกับงานนั้น สำหรับงานที่ยาวมาก บางครั้งถึงขั้นเริ่มใหม่ในหน้าต่างใหม่โดยถือแค่เอกสารส่งต่องานเข้าไป Anthropic ชี้ว่า “สำหรับงานยาว การสรุปบีบอัดอย่างเดียวไม่พอ และอาจต้องเริ่มใหม่ด้วยเอกสารส่งต่อที่มีโครงสร้าง” ถ้ามองในแบบคนทำงาน ก็คล้ายกับการทำเอกสารสรุปไว้เมื่อต้องส่งต่องานให้พนักงานใหม่

• แพตเทิร์นสำหรับพางานยาวไปต่อจนจบ หนึ่งในจุดอ่อนของโมเดลปัจจุบันคือมันพยายามปิดงานเร็วเกินไป, แยกปัญหาใหญ่ให้เป็นส่วนเล็ก ๆ ไม่เก่ง, และเมื่อหน้าต่างคอนเท็กซ์เปลี่ยน กระแสการทำงานก็มักสะดุด ฮาร์เนสจึงต้องชดเชยจุดอ่อนนี้ Ralph loop เป็นเทคนิคง่าย ๆ ที่ hook จะคอยขัดจังหวะทุกครั้งที่โมเดลพยายามสรุปว่าจบงานแล้ว แล้วฉีดเป้าหมายเดิมกลับเข้าไปในหน้าต่างคอนเท็กซ์ใหม่เพื่อให้ทำงานต่อ แต่ละรอบเริ่มจากสภาพสะอาดใหม่ ทว่าผลลัพธ์ของรอบก่อนหน้ายังต่อเนื่องผ่าน file system ในอีกด้านหนึ่ง Anthropic เน้นว่าควรแยก “ผู้สร้างผลลัพธ์” กับ “ผู้ประเมินผลลัพธ์” ออกเป็น AI คนละตัว เพราะถ้าให้ AI ประเมินงานของตัวเอง มันมักให้คะแนนตัวเองสูงเกินจริง นอกจากนี้ แพตเทิร์น “sprint contract” ที่ตกลงกันล่วงหน้าตั้งแต่เริ่มงานว่า “คำว่าเสร็จ” หมายถึงสภาพแบบไหน ยังมีประสิทธิภาพมากในการป้องกันไม่ให้เป้าหมายค่อย ๆ บานปลายระหว่างทาง

• บทบาทของ hook “บอก AI ไว้ว่าให้ทำแบบนั้น” กับ “ระบบบังคับให้มันทำแบบนั้น” เป็นคนละเรื่องกัน Hook คือกลไกอัตโนมัติที่เชื่อมช่องว่างนี้ โดยมันจะเข้ามาแทรกก่อนใช้เครื่องมือ, หลังแก้ไฟล์, ก่อน commit, หรือตอนเริ่มเซสชัน เช่น รันการตรวจ syntax·lint·test อัตโนมัติทุกครั้งที่มีการแก้โค้ด, บล็อกคำสั่งอันตรายอย่าง rm -rf หรือ git push --force, หรือบังคับให้ขออนุมัติจากมนุษย์ก่อนเปิด PR หลักการคือ “ผ่านแล้วเงียบ, พังแล้วดัง” ถ้าการตรวจผ่าน AI จะไม่ได้รับข้อความใด ๆ แต่ถ้าล้มเหลว ข้อความ error จะถูกฉีดกลับเข้าไปใน flow เพื่อให้มันแก้เอง เป็นโครงสร้างที่แทบไม่มีต้นทุนในเวลาปกติ แต่ช่วยได้อย่างแม่นยำทันทีเมื่อเกิดปัญหา

• เอกสารกฎและการเลือกเครื่องมือต้องสั้นและชัด AGENTS.md ที่วางไว้ใน project root คือไฟล์ตั้งค่าที่ทรงอิทธิพลที่สุด เพราะมันจะเข้าไปอยู่ใน system prompt ทุก turn HumanLayer แนะนำให้คุมเอกสารนี้ไว้ไม่เกิน 60 บรรทัด ยิ่งยาว น้ำหนักของแต่ละบรรทัดยิ่งจางลง ดังนั้นมันไม่ควรเป็นคู่มือบันทึกสไตล์ทั่วไป แต่ควรเหลือไว้เฉพาะสิ่งที่จำเป็นจริงเหมือน checklist ของนักบิน หลักการเดียวกันนี้ใช้กับเครื่องมือด้วย เนื่องจากชื่อ คำอธิบาย และ schema ของเครื่องมือจะถูกฝังลงใน prompt ทุกคำขอ จึงดีกว่าที่จะมีเครื่องมือ 10 ชิ้นที่ขัดเกลาดี มากกว่าเครื่องมือคล้าย ๆ กัน 50 ชิ้น HumanLayer ยังชี้ประเด็นด้านความปลอดภัยด้วย เพราะคำอธิบายของเครื่องมือก็คือข้อความที่ AI อ่านได้ การต่อ MCP server ภายนอกที่ยังไม่ผ่านการตรวจสอบ จึงเท่ากับเปิดทางให้มีการลอบฉีดคำสั่งที่คนอื่นเขียนไว้ล่วงหน้าเข้าไปใน AI

ส่วนที่นับเป็นข้อดีได้มีดังนี้

• เห็นจุดที่ควรลงทุนลงแรงชัดเจนขึ้น ข้อมูล benchmark แสดงให้เห็นว่าพฤติกรรมสามารถยกระดับได้มากโดยไม่ต้องเปลี่ยนโมเดล หากไปปรับที่ฮาร์เนส นั่นหมายถึงแทนที่จะหวังลอย ๆ ว่า “รอโมเดลถัดไป” ก็มีพื้นที่ที่ลงมือแก้ได้ทันทีอย่างเป็นรูปธรรม
• เป็นโครงสร้างที่สะสมองค์ความรู้ได้ แนวทาง ratchet ที่เปลี่ยนความผิดพลาดให้กลายเป็นกฎ ทำให้บทเรียนที่เรียนรู้ครั้งหนึ่งกลายเป็นทรัพย์สินของทีม แม้คนจะเปลี่ยน เอกสารกฎและ hook ก็ยังอยู่เพื่อปกป้องคนถัดไป
• การเกิดขึ้นของฮาร์เนสสำเร็จรูป (HaaS) กระแสที่ Viv เรียกว่า “Harness-as-a-Service” กำลังก่อตัวอย่างรวดเร็ว ผลิตภัณฑ์อย่าง Claude Agent SDK, Codex SDK, OpenAI Agents SDK ที่รวม task loop, เครื่องมือ, การจัดการคอนเท็กซ์, hook, sandbox ไว้ให้ล่วงหน้า กำลังทำให้ผู้ใช้ไม่ต้องสร้างทุกอย่างจากศูนย์ และหันไปโฟกัสกับความรู้เฉพาะโดเมนของตัวเองได้มากขึ้น

แต่ก็มีส่วนที่ชวนให้หนักใจเช่นกัน

• ขอบเขตที่ต้องดูแลกว้างมาก ทั้งคำสั่ง, เครื่องมือ, พื้นที่รันปลอดภัย, การตรวจสอบอัตโนมัติ, ไปจนถึงการสังเกต log ล้วนต้องรับผิดชอบเอง แก่นสำคัญคือมันไม่ใช่สิ่งที่ผู้ให้บริการโมเดลจะจัดการให้เองทั้งหมด
• ความเสี่ยงจากการผูกกันแน่นระหว่างโมเดลกับฮาร์เนส โมเดลทุกวันนี้ถูกฝึกแบบมี post-processing ร่วมกับฮาร์เนสบางชนิด พอย้ายไปฮาร์เนสอื่น ประสิทธิภาพก็อาจตกลงทันที แค่เปลี่ยนชื่อเครื่องมือหรือรูปแบบ argument อย่างเดียว ผลลัพธ์ก็สั่นคลอนได้ หากเป็นโมเดลที่ทั่วไปจริง มันไม่ควรถูกชักจูงด้วยชื่อเครื่องมือ แต่เพราะมีการฝึกร่วมกัน จึงเกิดอาการคล้าย overfitting
• ความเสี่ยงด้านความปลอดภัยจากเครื่องมือภายนอก MCP server มีคำอธิบายเครื่องมือที่ AI อ่านตรง ๆ ได้ ดังนั้นทันทีที่ต่อเครื่องมือที่ยังไม่ผ่านการตรวจสอบ ข้อความจากภายนอกก็เริ่มมีอิทธิพลต่อ AI ตั้งแต่ก่อนผู้ใช้จะพิมพ์อะไรสักตัวแล้ว

มุมมองที่แตกต่างมีดังนี้

• เว้นระยะจากวาทกรรมที่ยึดโมเดลเป็นศูนย์กลาง แทนที่จะอยู่ในบรรยากาศแบบรอ GPT ที่ฉลาดกว่า บทความนี้เสนอวิธีทางวิศวกรรมเพื่อดันขีดจำกัดของโมเดลที่มีอยู่ตอนนี้ให้ไปได้ไกลที่สุด การวินิจฉัยคือช่องว่างระหว่างข้อจำกัดของ AI ที่เราเห็นวันนี้กับความสามารถจริงของโมเดล ส่วนใหญ่คือช่องว่างของฮาร์เนส
• ฮาร์เนสไม่ได้หายไป แต่ย้ายตำแหน่ง เมื่อโมเดลดีขึ้น ฮาร์เนสบางชิ้นก็ไม่จำเป็นอีกต่อไป เช่น Opus 4.6 แทบกำจัดอาการร้อนรนแบบ “คอนเท็กซ์ใกล้หมดแล้ว ต้องรีบปิดงาน” ที่พบบ่อยใน Claude Sonnet 4.5 ได้ ทำให้อุปกรณ์ช่วยประคองบางอย่างที่เคยใช้กันกลายเป็น dead code ทั้งก้อน แต่เมื่อโมเดลเข้าไปแตะพื้นที่ใหม่ ก็จะมีจุดอ่อนใหม่ตามมา และต้องมีฮาร์เนสแบบใหม่มาชดเชยอีกครั้ง คำของ Anthropic ที่ว่า “ทุกชิ้นส่วนของฮาร์เนสบรรจุสมมติฐานว่าโมเดลยังทำอะไรด้วยตัวเองไม่ได้” จึงเข้ากับภาพนี้อย่างดี
• วงจรป้อนกลับระหว่างการเรียนรู้ของโมเดลกับฮาร์เนส อีกกระแสหนึ่งที่ Viv ชี้ไว้คือวงจร feedback ระหว่างการออกแบบฮาร์เนสกับการฝึกโมเดล เมื่อค้นพบ pattern ที่ใช้ได้ผลในฮาร์เนส มันจะถูกทำให้เป็นมาตรฐาน จากนั้นโมเดลรุ่นถัดไปก็จะถูกฝึกโดยอิงกับ pattern นั้น และบนโมเดลใหม่นั้นก็จะเกิด pattern ฮาร์เนสชุดใหม่ขึ้นอีก ดังนั้นข้อสรุปจึงกลายเป็นว่า “ฮาร์เนสที่ดี” ไม่ใช่ฮาร์เนสที่โมเดลถูกฝึกมาด้วย แต่เป็นฮาร์เนสที่ถูกนำมาขัดเกลาใหม่ให้เข้ากับงานของตัวเอง
• ทั้งอุตสาหกรรมกำลังลู่เข้าสู่รูปแบบคล้ายกัน AI สำหรับงานเขียนโค้ดอย่าง Claude Code, Cursor, Codex, Aider, Cline แม้จะใช้โมเดลต่างกัน แต่รูปทรงของฮาร์เนสกำลังค่อย ๆ คล้ายกันมากขึ้น ข้อเท็จจริงที่ว่าโมเดลต่างกันแต่ฮาร์เนสกลับเหมือนกันขึ้นเรื่อย ๆ เป็นสัญญาณว่าทิศทางของวงการกำลังไปลงหลักที่ตรงไหน

บทความของ Osmani นำเสนอมุมมองว่า ความสามารถในการแข่งขันของ AI สำหรับงานเขียนโค้ดนั้นขึ้นอยู่กับการออกแบบฮาร์เนสรอบตัวมากกว่าการเลือกโมเดล และฮาร์เนสก็ไม่ใช่ไฟล์ตั้งค่าที่ตั้งครั้งเดียวแล้วจบ แต่เป็นระบบมีชีวิตที่อัปเดตต่อเนื่องตามประวัติความล้มเหลว ต่อให้โมเดลเก่งขึ้น ฮาร์เนสก็ไม่ได้หายไป เพียงแต่ระดับของปัญหาที่ต้องรับมือจะเลื่อนสูงขึ้นหนึ่งขั้น และมีฮาร์เนสแบบใหม่เข้ามาแทนที่จุดนั้น ดังที่ Viv กล่าวว่า “การสร้าง agent ที่ดีคือศิลปะแห่งการทำซ้ำ และถ้าไม่มีเวอร์ชันแรก ก็ไม่มีการทำซ้ำเช่นกัน” ซึ่งชวนให้อ่านได้ว่า สุดท้ายแล้วสนามนี้คือการแข่งขันว่าใครเริ่มเร็วกว่าและขัดเกลาบ่อยกว่ากัน สรุปสุดท้ายคือ จุดที่วิศวกรควรทุ่มเวลาจริง ๆ ไม่ใช่การสลับเปลี่ยนโมเดลตามกระแสทุกครั้ง แต่คือการปรับแต่งฮาร์เนสให้เข้ากับงานของตัวเองอย่างไม่หยุดยั้ง เพื่อค่อย ๆ ยกเพดานที่โมเดลเอื้อมถึงขึ้นไปทีละขั้น

[kimjoin2]

รู้สึกเหมือนมีแต่คำศัพท์การตลาดเพิ่มขึ้นเรื่อย ๆ แบบมหาศาลเลยนะ

[dongho42]

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

[dongho42]

เมื่อก่อนแม้จะเขียนในพรอมป์ชัดเจนว่าให้ทำ A แต่ก็ยังมีโอกาสอยู่เรื่อย ๆ ที่มันจะไม่ทำตาม เลยลองสารพัดวิธี ทั้งเน้นด้วยตัวหนาแบบ mrkdwn เขียนซ้ำสองรอบ เขียนเป็นภาษาอังกฤษ เขียนแบบรับต้นส่งท้าย เขียนเป็น xml แต่สุดท้ายมันก็ยังเมินพรอมป์อยู่เป็นระยะ ๆ...

[kurthong]

ผมก็ยัดทุกอย่างคล้าย ๆ กับที่ Osmani พูดเหมือนกัน
ตอนที่กำลังทำแอปอยู่ แล้วประเด็นนี้ก็โผล่ขึ้นมา เลยรีบพูดหน่อย
Osmani เองก็อย่าพูดอย่างเดียวเลย
ผมว่าถ้าเอาสิ่งที่ตัวเองพูดไปใส่ไว้ใน Google Anti-Gravity ด้วยก็น่าจะดีกว่าไหม
Karpathy ก็เหมือนกัน ตอนนี้เหมือนไม่คิดจะลงมือทำแล้ว เอาแต่โยนบทความออกมานิด ๆ หน่อย ๆ เฉย ๆ แบบนี้ก็ไม่ค่อยไหร่นะ! ครับ

https://github.com/hang-in/tunaFlow

[tangokorea]

ถ้าถอยออกมาหนึ่งก้าวจากมุมมองที่ว่าระหว่างโมเดลกับฮาร์เนส อะไรดีกว่ากัน แล้วลองมองว่าโมเดลแบบไหนเหมาะกับการใช้ฮาร์เนสแบบไหนมากกว่ากัน จะเป็นอย่างไร?

[jimmy2056]

ถ้าโมเดลดี ภาระในการออกแบบฮาร์เนสก็จะลดลงด้วย

[akapwhd]

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

[blackfabric]

สรุป 3 บรรทัด

• ระบบ (harness) สำคัญกว่าตัวโมเดลในการตัดสินความสำเร็จหรือความล้มเหลว: ประสิทธิภาพของ AI ไม่ได้ขึ้นอยู่กับตัวโมเดลอย่าง GPT หรือ Claude เพียงอย่างเดียว แต่ถูกกำหนดโดยการออกแบบสภาพแวดล้อมการทำงานที่ล้อมรอบมัน เช่น พรอมป์ต์ เครื่องมือ แซนด์บ็อกซ์ และลูปฟีดแบ็ก ซึ่งเรียกรวมว่า harness
• หลักการ 'Ratchet' ที่เปลี่ยนความผิดพลาดให้กลายเป็นกฎ: ไม่ควรมองความผิดพลาดของ AI เป็นแค่อุบัติเหตุชั่วคราว แต่ต้องสะท้อนกลับเข้าไปในเอกสารกฎ (เช่น AGENTS.md) หรือฮุกทันที เพื่อให้ระบบแข็งแรงขึ้นเรื่อย ๆ ตามกาลเวลา
• ปัญหาไม่ได้อยู่ที่ตัวโมเดล แต่อยู่ที่การตั้งค่า (Skill): บ่อยครั้งที่ AI ทำงานได้ไม่ดี ไม่ใช่เพราะสติปัญญาของโมเดลไม่พอ แต่เพราะการออกแบบ harness ไม่ดีพอ และจำเป็นต้องใช้แนวทางเชิงวิศวกรรมโดยออกแบบส่วนประกอบและข้อจำกัดที่ต้องมี ไล่ย้อนกลับมาจากผลลัพธ์ที่ต้องการ

[yungoun]

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

[click]

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

[kurthong]

นี่เป็นเนื้อหาที่ถึงขั้นวิเคราะห์บทความของนักพัฒนาระดับสูงที่พูดเรื่องไม่ค่อยมีแก่นสารแต่ทำให้ดูน่าเชื่อถือเลยนะครับ (ขออภัยด้วยที่ส่วนตัวผมไม่ค่อยชอบ Google) แน่นอนว่าการพยายามเข้าถึงเพื่อทำความเข้าใจปรากฏการณ์นี้ ผมมองว่าเป็นความพยายามที่ดีครับ