เปเปอร์ใหม่ชื่อ Harness Handbook เผยแพร่เมื่อ 14 กรกฎาคม และตอบคำถามข้อหนึ่งที่คนใช้ coding agent อยู่ทุกวันสงสัยกัน coding agent คือเครื่องมือ AI ที่รับคำสั่งเป็นภาษาคน แล้วลงมือเขียนและแก้โค้ดในเครื่องเราให้เอง คำถามคือ ทำไมคนสองคนถึงได้ผลลัพธ์ต่างกันมาก ทั้งที่ใช้ coding agent ที่รันโมเดลตัวเดียวกัน เปเปอร์ชี้ว่าคำตอบไม่ได้อยู่ที่ตัวโมเดล แต่อยู่ที่สิ่งที่หุ้มโมเดลไว้ อย่างแรกคือ system prompt ข้อความตั้งต้นที่บอกโมเดลว่าเป็นใครและทำอะไรได้ ถัดมาคือเครื่องมือที่เปิดให้มันเรียกใช้ ความจำระหว่างทำงาน และลำดับว่าจะทำอะไรก่อนหลัง ของทั้งหมดนี้รวมเรียกว่า harness

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

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

harness ไม่เคยอยู่นิ่ง

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

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

ปัญหาคือ repo เรียงตามไฟล์ แต่สิ่งที่เราสั่งให้แก้คือพฤติกรรม

เปเปอร์เรียกขั้นตอนการตามหานี้ว่า behavior localization ขั้นตอนนี้มีไว้หาให้ครบว่าพฤติกรรมที่อยากแก้อยู่ตรงไหนในโค้ดบ้าง ทั้งคนและ coding agent ต้องผ่านขั้นนี้ก่อนเสมอ ถึงจะลงมือแก้ได้

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

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

Harness Handbook จัดข้อมูลใหม่ตามพฤติกรรม ไม่ใช่ตามไฟล์

ข้อเสนอของเปเปอร์มีสองส่วนที่ทำงานคู่กัน ส่วนแรกคือโครงสร้างข้อมูลแบบใหม่ ส่วนที่สองคือวิธีค้นข้อมูลจากโครงสร้างนั้น

ชิ้นแรกคือ Harness Handbook โครงสร้างข้อมูลที่เอาพฤติกรรมเป็นตัวตั้ง แทนที่จะเรียงตามไฟล์ มันเรียงตามสิ่งที่ระบบทำ แล้วเชื่อมพฤติกรรมแต่ละข้อกับซอร์สโค้ดที่เป็นต้นทาง handbook ไม่ได้ให้คนเขียนขึ้นเอง แต่สร้างอัตโนมัติจากโค้ด harness ขั้นแรกคือ static analysis หรือการอ่านโครงสร้างโค้ดโดยไม่ต้องรันจริง จากนั้นจึงให้ LLM ซึ่งเป็นโมเดลภาษาแบบเดียวกับที่เราพิมพ์คุยด้วยทุกวัน นำผลจากขั้นแรกมาจัดใหม่เป็นหมวดพฤติกรรมที่คนอ่านเข้าใจได้

ชิ้นที่สองชื่อ Behavior-Guided Progressive Disclosure หรือ BGPD เป็นวิธีให้ agent ดูข้อมูลทีละชั้น เริ่มจากภาพรวมของพฤติกรรม แล้วค่อยลงไปดูรายละเอียดการทำงานเฉพาะส่วนที่เกี่ยวข้อง ไม่ใช่ส่งโค้ดทั้ง repo ให้ agent อ่านตั้งแต่แรก

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

handbook ไม่ได้เป็นประโยชน์กับทุกงานเท่ากัน

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

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

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

นำหลักการมาใช้กับไฟล์กติกาของเราวันนี้

เราไม่ต้องใช้ static analysis ก็หยิบหลักคิดของเปเปอร์มาใช้ได้ เพราะไฟล์กติกาของเราเจอปัญหาเดียวกัน แค่มีขนาดเล็กกว่า

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

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

จัดเนื้อหาจากภาพรวมไปสู่รายละเอียด นี่คือรูปแบบเดียวกับ BGPD ไฟล์หลักควรสั้นและทำให้เห็นภาพรวมว่ามีพฤติกรรมกลุ่มไหนบ้าง แล้วแยกรายละเอียดเชิงลึกออกไปไว้ในสกิลหรือไฟล์ย่อย เพื่อให้ agent เปิดอ่านเองตอนต้องใช้จริง ดีกว่ายัดทุกอย่างไว้ในไฟล์เดียวจนไม่มีใครหาอะไรเจอ

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

เช็กสุขภาพ harness ของตัวเองสามข้อ

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

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

ข้อไหนตอบไม่ได้ นั่นคือจุดที่ harness ของเราเริ่มโตเกินความจำของเจ้าของแล้ว

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