Harness2 คืออะไร? เฟรมเวิร์กที่ให้ AI agent ปรับ harness ของตัวเองได้

Harness² คืออะไร? เฟรมเวิร์กที่ให้ AI agent ปรับ harness ของตัวเองได้

โดย Nokka (นก-กา) | นักเขียนอิสระสาย AI · 18 ตุลาคม 2026

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

ทวีตหนึ่งจาก Alvaro Cintas (@dr_cintas) ซึ่งเป็นอาจารย์สอนด้าน AI

และความมั่นคงไซเบอร์ เปิดด้วยประโยคสั้น ๆ ว่า "Google just open-sourced its Harness²" [1]

ตอนที่ผมเก็บข้อมูล ทวีตนั้นได้ 111 ไลก์ 16 รีทวีต และ 6,710 วิว โดยโพสต์เมื่อวันที่ 17 ตุลาคม 2026 [1]

ตัวเลขยังไม่มาก แต่ไอเดียข้างในนั้นใหญ่กว่าตัวเลขมาก

เพราะสิ่งที่ Google เปิดมานี้ ไม่ได้เป็นโมเดลใหม่ ไม่ได้เป็นเครื่องมือใหม่

แต่เป็นวิธีทำให้ agent ทำงานเก่งขึ้นโดยไม่ต้องเทรนโมเดลใหม่เลย

ผมเขียนเรื่องนี้เพราะตรงกับความสนใจของผมอยู่แล้ว คำถามที่ผมวนคิดบ่อย ๆ

คือ เมื่อโมเดลหยุดนิ่ง อะไรทำให้ agent เก่งขึ้นได้

คำตอบที่ Harness² เสนอคือ ตัวห่อรอบโมเดล หรือที่เขาเรียกว่า harness

harness คืออะไร

คำนิยามที่ตรงที่สุดอยู่ใน README ของโปรเจกต์เอง และผมคิดว่าอ่านแล้วเข้าใจได้ทันที

A harness is the system around a model that enables it to act as an agent: prompts, tools, memory, skills, orchestration, and more. Harnessing is the process of optimizing that system.

แปลความว่า harness คือระบบที่ห่อโมเดลไว้ เพื่อให้โมเดลลงมือทำอะไรได้จริง ประกอบด้วยคำสั่ง เครื่องมือ หน่วยความจำ สกิล และการประสานงาน [2]

ส่วน harnessing คือการปรับระบบนั้นให้ดีขึ้น

แนวคิดนี้ไม่ได้ใหม่ทั้งหมด ในแวดวงวิจัยมีงานเรื่อง harness engineering มาก่อนแล้ว รวมถึงบทความบนบล็อกชื่อดัง Lil'Log ที่เขียนเรื่อง Harness Engineering for Self-Improvement ไว้ตั้งแต่กลางปี 2026 [7]

แต่ที่ Harness² ต่างออกไปคือ มันทำให้กระบวนการปรับนี้เป็นอัตโนมัติ และทำซ้ำได้

8 องค์ประกอบที่แก้ได้

จุดที่ผมชอบที่สุดในงานนี้คือ เขาไม่ได้บอกว่า "ปรับได้ทุกอย่าง" แล้วปล่อยให้เรางง

README ระบุชัดว่ามี แปดองค์ประกอบที่แก้ได้ ดังนี้ [2]

• system prompt คำสั่งตั้งต้น
• guardrails กรอบกันไม่ให้ออกนอกทาง
• memory หน่วยความจำ
• tool guidance คำแนะนำวิธีใช้เครื่องมือ
• subagents ตัวแทนย่อย
• skills สกิล
• scripts สคริปต์
• plugins ปลั๊กอิน

และเขา จัดกลุ่มตามบทบาทตอนรัน ให้ด้วย ซึ่งช่วยให้เห็นภาพว่าอะไรทำหน้าที่อะไร

กลุ่มแรกคือ system prompt, guardrails, memory และ skills ทำหน้าที่ ประกอบบริบท ให้ agent

สองตัวถัดมาคือ tool guidance กับ scripts ทำหน้าที่ นิยามหน้าตาของเครื่องมือ

ส่วน subagents ทำหน้าที่ มอบงานต่อ และ plugins ทำหน้าที่ คุมชั้นกลาง [2]

ผมว่าการจัดกลุ่มแบบนี้มีประโยชน์มาก

เพราะเวลาที่ agent ทำงานพลาด เรามักไม่รู้ว่าควรไปแก้ตรงไหน การมีกรอบแปดช่องช่วยให้ถามได้ว่า "ความผิดพลาดนี้เกิดจากบริบท เกิดจากเครื่องมือ หรือเกิดจากการมอบงานต่อ"

ทำไมต้อง "เรียกซ้ำ"

ชื่อ Harness² มีเลขยกกำลังสอง เพราะมี การเรียกซ้ำสองชั้น และนี่คือหัวใจของงานชิ้นนี้

เปเปอร์ระบุปัญหาสองข้อที่ทำให้งานวิจัยลักษณะนี้ยังใช้จริงได้ยาก [3]

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

ข้อสอง กระบวนการปรับตัวเองแบบนี้มัก ติดอยู่กับงานใดงานหนึ่ง และไม่ย้ายไปงานใหม่ได้

ทางออกที่ Harness² เสนอคือแยกการเรียกซ้ำเป็นสองชั้น [2]

ชั้นที่หนึ่งคือการเรียกซ้ำระดับงาน (task-level recursion) ทำหน้าที่ปรับ harness สำหรับงานที่กำลังทำอยู่ตอนนี้

ชั้นที่สองคือการเรียกซ้ำระดับ harnessing (harnessing-level recursion) ทำหน้าที่เก็บสิ่งที่เรียนรู้จากแต่ละงานไว้ใน คลังปรับปรุงถาวร เพื่อใช้กับงานต่อ ๆ ไป

พูดง่าย ๆ คือ ชั้นแรกแก้ปัญหาเฉพาะหน้า ชั้นที่สองสะสมบทเรียน

ทำไมเปลี่ยนตัวห่อแล้วพฤติกรรมเปลี่ยนได้ ทั้งที่น้ำหนักไม่ขยับ

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

โมเดลอย่าง GLM-5 หรือ Gemini 3.5 Flash เป็น LLM ที่สร้างบนสถาปัตยกรรม Transformer กลไกหลักที่ทำให้มันอ่านบริบทได้คือ Attention

ซึ่งให้น้ำหนักกับแต่ละโทเคนในข้อความที่ป้อนเข้าไป

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

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

และผลลัพธ์ที่ออกมาก็คือการแจกแจง Probability ของโทเคนถัดไปที่ต่างออกไป

พูดอีกแบบคือ การแก้ harness คือการแก้ข้อมูลขาเข้า ไม่ใช่การแก้ตัวโมเดล

ส่วนการฝึกโมเดลซึ่งเป็นคนละเรื่องกันนั้น ใช้วิธีปรับค่าน้ำหนักด้วย Gradient Descent

โดยแปลงคะแนนดิบให้เป็นความน่าจะเป็นด้วย Softmax แล้ววัดความคลาดเคลื่อนด้วย Cross-entropy

ทั้งหมดนั้นคือสิ่งที่ Harness² ไม่ได้แตะเลย

และนั่นคือเหตุผลที่งานชิ้นนี้ทำงานได้โดยไม่ต้องมีคลัสเตอร์สำหรับเทรนโมเดล

จุดที่ผมว่าฉลาดคือ ทั้งสองชั้นทำงานโดยที่น้ำหนักของโมเดลไม่ขยับเลย [2] หมายความว่าไม่มีการเทรนใหม่ ไม่มีการปรับค่าพารามิเตอร์ มีเพียง ตัวห่อ เท่านั้นที่เปลี่ยนไป

Propose-Probe-Compose ทำงานอย่างไร

กลไกชั้นแรกเรียกว่า Propose-Probe-Compose หรือเสนอ ทดสอบ ประกอบ [2]

ขั้นเสนอ ตัวแก้ harness จะเสนอการแก้ไข

ขั้นทดสอบ รันงานเดิมซ้ำด้วย harness ที่แก้แล้ว เพื่อดูว่าผลเปลี่ยนไปอย่างไร

ขั้นประกอบ นำผลมาเทียบกัน แล้วประกอบเป็น harness ฉบับใหม่

จุดสำคัญที่ผมอยากเน้นคือคำว่า contrastive ในชื่อขั้นตอน

ซึ่งหมายถึงการเทียบ ความต่างของพฤติกรรม ระหว่างการรันแต่ละครั้ง

และมันทำงานได้ โดยไม่มีเฉลย [2]

ตรงนี้ต้องเข้าใจให้ถูก เพราะมันคือทั้งจุดแข็งและจุดอ่อนในตัวเดียวกัน

ถ้าไม่มีเฉลย แล้วมันรู้ได้อย่างไรว่าอะไรดีกว่ากัน

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

ในพรอมป์ของตัวแก้ harness เขียนไว้ตรง ๆ ว่าให้มองหาสามอย่าง คือ ความต่างระหว่างการรัน ความผิดพลาดซ้ำ ๆ

และ ความเสี่ยงที่เห็นในร่องรอยแต่ยังไม่เกิดขึ้นจริง [4]

พร้อมกับสั่งห้ามไว้ด้วยว่า อย่าแก้สิ่งที่การรันทำถูกอยู่แล้ว และอย่าเขียนซ้ำสิ่งที่ harness บอกไว้ชัดแล้ว

เพราะคำสั่งที่ซ้ำกันจะเจือจางคำสั่งอื่น [4]

ผมว่าการออกแบบพรอมป์แบบนี้ฉลาด เพราะมันบังคับให้ตัวแก้ หาสาเหตุที่แท้จริง

แทนที่จะเติมคำสั่งเพิ่มเรื่อย ๆ ซึ่งเป็นอาการที่คนใช้ agent บ่อย ๆ คุ้นดี

พรอมป์เดียวกันยังย้ำด้วยว่า ไม่มีเกณฑ์ให้คะแนน ไม่มีเฉลย และไม่มีคำตอบอ้างอิงอยู่ในบริบทของโมเดล

และห้ามพยายามเดาว่าคนตรวจจะให้คะแนนอย่างไร [4]

ปรับได้ลึกแค่ไหน

การเรียกซ้ำชั้นแรกมีสองโหมด [2]

โหมดขนาน (parallel) จะทดสอบ harness หลายแบบพร้อมกัน แล้วประกอบผลจากหลักฐานร่วมกัน

โหมดเรียง (sequential) จะปรับต่อเนื่องกันเป็นขั้น ๆ โดยพา harness ที่ปรับแล้วกับหลักฐานที่สะสมมาไปด้วย

README สรุปความต่างไว้สั้น ๆ ว่า โหมดขนานสำรวจได้กว้างกว่า ส่วนโหมดเรียงขัดเกลาได้ลึกกว่า [2]

รายละเอียดของแต่ละเบนช์มาร์กอยู่ที่ไฟล์คำแนะนำแยกต่างหากในที่เก็บโค้ด [9]

และหน้าประกาศของโปรเจกต์อยู่ที่ไซต์ของตัวเอง [8]

เราตั้งงบการเรียกซ้ำได้ด้วยค่า --k โดย --k 1 คือเรียกซ้ำหนึ่งรอบ และเพิ่มขึ้นได้ตามต้องการ [2]

ผลทดสอบที่เขารายงาน

ทวีตไม่ได้ลงตัวเลขไว้เลย ตัวเลขชุดนี้อยู่ในเปเปอร์ และผมจะยกมาตรง ๆ ตามที่เปเปอร์เขียน [3]

ข้าม สามเบนช์มาร์กสายอาชีพ และ สี่ชุดคอนฟิกของโมเดลกับ harness การเรียกซ้ำเพียง หนึ่งรอบ

ทำให้ GLM-5 และ Gemini 3.5 Flash ทำได้ดีกว่า harness เดิมของตัวเอง

โดยเพิ่มขึ้นสูงสุด 11.5 คะแนนบน WorkBuddy-Bench 4.5 คะแนนบน JobBench

และ 11.8 เปอร์เซ็นต์บนอัตราผ่านบางส่วนของ LAB [3]

เปเปอร์ยังระบุว่า ถ้าเพิ่มงบการเรียกซ้ำระดับงานขึ้น ผลก็เพิ่มขึ้นอีก [3]

และคู่เทียบที่เปเปอร์ใช้เป็นหลักคือวิธีที่ชื่อ Meta-Harness ซึ่งเปเปอร์ระบุว่า การเรียกซ้ำแบบขนานที่ค่า k เท่ากับห้าเอาชนะคู่เทียบที่แข็งที่สุดในทุกโดเมน [4]

สามเบนช์มาร์กนี้ครอบงานต่างกัน คือ JobBench สำหรับงานอาชีพทั่วไป LAB สำหรับงานกฎหมาย

และ WorkBuddy-Bench สำหรับงานออฟฟิศ เว็บ และโค้ด [2]

ตัวรันที่รองรับคือ OpenCode เป็นค่าตั้งต้น และ Codex เป็นทางเลือก [2]

แต่ราคาที่ต้องจ่ายคืออะไร

ตรงนี้คือส่วนที่ผมคิดว่าสำคัญที่สุดของบทความนี้ และเป็นส่วนที่ทวีตไม่ได้บอก

เปเปอร์มีภาคผนวกชื่อ Limitations ที่เขียนไว้ตรงไปตรงมา และผมจะยกมาให้เห็น [4]

ข้อแรกคือเรื่องค่าใช้จ่าย เปเปอร์ยอมรับว่า Harness² ต้องใช้การรันเพิ่มและต้องเปิดเซสชันของตัวแก้เพิ่ม

เพื่อเสนอ ทดสอบ และประกอบการแก้ไข [4]

การเพิ่มงบการเรียกซ้ำจึง เพิ่มต้นทุนการประมวลผลตามไปด้วย

และแม้การรันแบบขนานจะช่วยลดเวลารอได้ แต่ ไม่ได้ทำให้ภาระการประมวลผลที่เพิ่มขึ้นหายไป [4]

เปเปอร์ยังยอมรับด้วยว่าการทดลองของเขา สำรวจช่วงงบประมาณหนึ่งเท่านั้น ไม่ได้หาจุดที่เหมาะที่สุดแบบสากล [4]

พูดอีกอย่างคือ เขาบอกว่าตัวเลขนี้ใช้ได้ในช่วงที่เขาทดลอง ไม่ใช่สูตรสำเร็จที่ใช้ได้ทุกสถานการณ์

ข้อสองคือความน่าเชื่อถือของสัญญาณ เปเปอร์ระบุว่าเมื่อไม่มีเฉลย การปรับ harness

จึงต้องอาศัย ความต่างของพฤติกรรมและดุลพินิจของโมเดล [4]

สัญญาณแบบนี้ช่วยประเมินผลของการแก้ไขได้ แต่มันยังอ่อนไหวต่อความแปรปรวนของการรัน และอคติร่วมของโมเดล [4]

และประโยคที่ผมคิดว่าสำคัญที่สุดในเปเปอร์ทั้งฉบับคือประโยคนี้

They do not guarantee correctness or establish that an adopted change will transfer to a different task.

แปลว่า มันไม่ได้รับประกันความถูกต้อง และไม่ได้พิสูจน์ว่าการแก้ที่ถูกนำมาใช้นั้นจะย้ายไปใช้กับงานอื่นได้ [4]

9 เคสที่ผลแย่ลง

ส่วนที่ผมประทับใจที่สุดคืองานชิ้นนี้ รายงานความล้มเหลวของตัวเองไว้ด้วย

ภาคผนวก E.6 ชื่อ Failure Analysis รวบรวม เก้าเคสที่ผลลัพธ์แย่ลงกว่าเดิม และจัดเป็นสามกลุ่ม [4]

กลุ่มแรกคือการเลือกที่ผิดพลาด ในงาน WB-code ระบบ เลือกคำตอบที่ได้ 55 คะแนน แทนที่จะเป็น 95 คะแนน

และในงาน LAB การแก้ที่แคบลงทำให้ คะแนนตกลงจาก 54 เหลือ 26 [4]

ผมอ่านบรรทัดนี้แล้วหยุดคิดนาน เพราะนี่คือกรณีที่ ระบบเลือกคำตอบที่แย่กว่าทั้งที่คำตอบที่ดีกว่านั้นอยู่ในมือแล้ว

แต่ต้องเขียนให้ตรงด้วยว่า คะแนน 55 กับ 95 เป็นการประเมินย้อนหลัง และไม่ได้อยู่ในสายตาของระบบตอนที่มันเลือก [4]

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

ทำให้ คะแนนหายไป 2 ถึง 11 คะแนน [4]

กลุ่มที่สามคือความแปรปรวนของผลลัพธ์ คำตัดสินจากตัวให้คะแนนที่ขาดหาย

และการแก้ที่ไม่ตรงกับเกณฑ์ที่ถูกประเมิน ทำให้อธิบายสาเหตุที่เหลือได้ยาก [4]

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

และ การรันซ้ำเพื่อแยกผลของการแก้ ออกจากความแปรปรวนของผลลัพธ์ [4]

ผมคิดว่าการที่ทีมเขียนแบบนี้ออกมาเองเป็นสัญญาณที่ดี เพราะมันบอกว่าเขารู้ว่าระบบตัวเองพังตรงไหน

เสียงจากงานวิจัยอิสระที่ค้าน

และนี่คือส่วนที่ผมคิดว่าคนอ่านควรรู้มากที่สุด

ในบรรณานุกรมของ Harness² เอง มีงานวิจัยชิ้นหนึ่งชื่อ "Rethinking the Evaluation of Harness Evolution for Agents"

ซึ่งตีพิมพ์ก่อนหน้า และ ตั้งคำถามกับวิธีการประเมินในสายนี้ทั้งสาย [5]

งานชิ้นนั้นระบุ ปัญหาพื้นฐานสองข้อ ของวิธีประเมินที่ใช้กันมา [5]

ข้อแรก งานก่อน ๆ ไม่ได้เทียบกับการค้นหาแบบง่ายในระดับงาน ภายใต้งบป้อนกลับและงบประมวลผลที่เท่ากัน [5]

ข้อสอง งานก่อน ๆ ใช้สัญญาณตรวจสอบที่ดึงมาจากเบนช์มาร์กตัวเดียวกับที่เอามารายงานผลสุดท้าย

ซึ่ง ละเมิดหลักการแยกข้อมูลฝึกกับข้อมูลทดสอบ [5]

ทีมนั้นทดลองบน Terminal-Bench 2.1 และพบว่า วิธีปรับ harness อัตโนมัติไม่สามารถเอาชนะวิธีขยายการคำนวณตอนทดสอบแบบง่ายได้ ทั้งในกรณีที่มีชุดทดสอบและไม่มี

และยัง สรุปผลข้ามงานได้จำกัด [5]

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

แต่งานชิ้นเดียวกันก็ให้ข้อสรุปที่เปิดทางไว้ด้วยว่า เกมระยะยาวเป็นสนามที่เหมาะสมกับวิธีนี้มากกว่า

โดยพบว่าการปรับ harness เฉพาะงานทำได้ดีกว่าวิธีค้นหาแบบพื้นฐานถึง 80 เปอร์เซ็นต์บน ARC-AGI-3 และ 11 เปอร์เซ็นต์บนเกม EdgeBench [5]

สรุปสั้น ๆ คือ วิธีนี้ยังไม่ได้พิสูจน์ว่าดีกว่าในทุกที่ แต่มีบางที่ที่มันชนะชัดเจน

มุมจากคนที่อ่านโค้ดจริง

มีทีมที่เขียนรีวิวแบบลงมืออ่านโค้ดไว้เมื่อวันที่ 16 ตุลาคม 2026 โดย Kevin Riedl จาก Wavect [6]

เขาตั้งข้อสังเกตที่ผมคิดว่าจำเป็นไว้สามข้อ

และปิดท้ายด้วยอีกข้อหนึ่งที่ผมคิดว่าสำคัญที่สุด

ข้อแรก ตัวเลขสูงสุดไม่ได้มาจากการทดลองเดียว เขาชี้ว่า 11.5 คะแนนบน WorkBuddy-Bench และ 4.5 คะแนนบน JobBench มาจากคอนฟิกคนละชุดกัน [6]

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

ข้อที่สอง Harness² ไม่ใช่เครื่องมือสำเร็จรูปสำหรับคนทำงานออฟฟิศ [6]

เขาระบุว่า ตัวรันถูกปล่อยให้เข้าถึงเครือข่ายได้แบบไม่จำกัด และแซนด์บ็อกซ์ของ Codex ถูกปิดไว้ [6]

ตรงนี้ตรงกับคำเตือนใน README เองที่บอกว่า ก่อนประเมินผล ควรตั้งข้อจำกัดเครือข่ายเพื่อป้องกันไม่ให้ agent เข้าถึงเฉลยและเกณฑ์การให้คะแนนของเบนช์มาร์ก [2]

ผมอ่านสองบรรทัดนี้แล้วรู้สึกว่ามันเป็นประเด็นใหญ่กว่าที่คนพูดกัน

เพราะมันแปลว่า ผลการทดสอบอาจปนเปื้อนได้ ถ้าผู้ใช้ไม่ตั้งข้อจำกัดเอง

ข้อที่สาม ไฟล์ guardrail ที่แก้ได้ไม่ใช่เส้นแบ่งความปลอดภัย [6]

ผมเห็นด้วยอย่างยิ่ง เพราะ guardrail ในความหมายของ Harness² เป็นแค่ข้อความที่บอกให้ agent ทำหรือไม่ทำ

ซึ่ง ตัว agent เองมีสิทธิ์แก้มันได้ และไม่ใช่กลไกบังคับในระดับระบบ

เขายังย้ำว่า ผลการทดสอบเป็นตัวเลขที่ผู้เขียนงานวัดเอง ไม่ใช่ผลที่ Wavect วัด [6]

ซึ่งเป็นวินัยการอ้างอิงที่ผมอยากให้มีกันทั่วไป

สิ่งที่ผมยังไม่ได้พิสูจน์

ผมยังไม่ได้รัน Harness² บนเครื่องตัวเอง

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

เหตุผลคือตัวโปรเจกต์ต้องใช้ Python 3.12, Node.js 20 ขึ้นไป, Google Cloud CLI และต้องมีโปรเจกต์ Vertex AI สำหรับการรันแบบใช้โมเดลจริง [2]

แต่มีทางที่ผมคิดว่าน่าสนใจสำหรับคนที่อยากลองแบบไม่เสี่ยง คือ demo ในเครื่อง

ซึ่งรันทั้งสองโหมดการเรียกซ้ำด้วยตัวแก้แบบกำหนดผลได้ และรันโค้ด Python จริง

จุดที่ดีคือ demo นี้ไม่ต้องใช้ข้อมูลรับรองของโมเดลเลย [2]

uv venv --python 3.12 .venv
source .venv/bin/activate
uv pip install -e '.[render]'
harness2-demo --output runs/demo --k 2

ถ้าจะรันเบนช์มาร์กจริง คำสั่งจะหน้าตาแบบนี้ [2]

harness2-setup lab
harness2-check --bench lab
harness2 --bench lab --k 1 --mode parallel \
  --only-domains antitrust-competition --max-tasks 1
harness2-judge --bench lab --k 1 --mode parallel
harness2-report --bench lab --k 1 --mode parallel

เพิ่ม --dry-run เพื่อดูล่วงหน้าว่าจะเลือกงานอะไร โดยไม่เรียกโมเดล [2]

และ README ย้ำว่าการรันด้วยโมเดลจริง มีค่าใช้จ่ายจาก API จึงควรเริ่มจากงานจำนวนน้อยก่อน [2]

ข้อจำกัดที่ควรรู้ก่อน

มีอีกสองข้อที่ผมคิดว่าคนอ่านควรรู้

ข้อแรกคือสถานะของโปรเจกต์ ถึงแม้ที่เก็บโค้ดจะอยู่ในองค์กรของ Google Research และมีสัญญาอนุญาต Apache 2.0

แต่ตัว README เองเขียนไว้ชัดว่า นี่ไม่ใช่ผลิตภัณฑ์ที่ Google สนับสนุนอย่างเป็นทางการ และ ไม่เข้าเกณฑ์โครงการรางวัลช่องโหว่โอเพนซอร์สของ Google [2]

ผมว่าประโยคนี้สำคัญ เพราะทวิตเตอร์เขียนว่า "Google just open-sourced"

ซึ่งไม่ผิด แต่คนอ่านอาจเหมารวมว่ามันคือผลิตภัณฑ์ที่พร้อมใช้งานในองค์กร

ข้อที่สองคือทีมผู้เขียน เปเปอร์ระบุว่าผู้เขียนส่วนใหญ่อยู่ที่ Google Cloud AI Research

ส่วนผู้เขียนคนแรกมีสังกัดมหาวิทยาลัย Northwestern

และเป็นหนึ่งในผู้รับผิดชอบบทความ ร่วมกับนักวิจัยอีกสามคนจากทีม Google

จุดที่ผมชอบคือเปเปอร์เขียนกำกับไว้ท้ายหน้าแรกว่า งานชิ้นนี้ทำระหว่างที่ผู้เขียนคนแรกเป็นนักศึกษาฝึกงานที่ Google Cloud AI Research [4]

จุดนี้ไม่ได้ลดคุณค่าของงาน แต่มันช่วยให้เห็นว่านี่เป็น งานวิจัย ที่วางอยู่บนแพลตฟอร์มคลาวด์ของบริษัท ไม่ใช่ฟีเจอร์ที่ทีมผลิตภัณฑ์ปล่อยออกมา

สิ่งที่ผมคิดว่าคุ้มค่าที่สุดในงานชิ้นนี้

ถ้าถามผมว่า Harness² สำคัญตรงไหน ผมจะไม่ตอบว่าตัวเลข 11.5 คะแนน

ผมจะตอบว่า มันทำให้คำถามเรื่อง "agent เก่งขึ้นได้อย่างไร" มีคำตอบที่ไม่ใช่การรอโมเดลใหม่

เพราะถ้า harness คือระบบที่ห่อโมเดล และเราแก้ระบบนั้นได้เอง การพัฒนา agent ก็ไม่ต้องรอรอบอัปเดตของโมเดล

แต่ในทางกลับกัน งานวิจัยอิสระที่ Harness² อ้างถึงเองก็เตือนไว้ว่า ตัวเลขที่ดีขึ้นต้องเทียบกับวิธีง่าย ๆ ภายใต้งบที่เท่ากัน และต้องทดสอบบนงานที่ไม่เคยเห็น ไม่งั้นเราจะแยกไม่ออกว่า agent เก่งขึ้นจริง หรือแค่จำเบนช์มาร์กได้ดีขึ้น [5]

ทั้งนี้ต้องเขียนกำกับให้ตรงด้วยว่า งานชิ้นนั้นประเมินวิธีรุ่นก่อนหน้า และไม่ได้ทดสอบ Harness² โดยตรง เพราะงานชิ้นนั้นส่งก่อน Harness² ประมาณสามเดือน [5]

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

และ "ค่าใช้จ่ายที่เพิ่มขึ้นต่อผลลัพธ์ที่ยอมรับได้หนึ่งชิ้นเป็นเท่าไร" ซึ่งเป็นคำถามที่ทีมรีวิวอิสระเสนอไว้ตรง ๆ [6]

ถ้าคำตอบคือคุณมีงานที่ยากพอจะเหลือช่องให้พัฒนา และมีวิธีตรวจผลได้เอง วิธีนี้ก็มีเหตุผลให้ลอง

แต่ถ้าคำตอบคือคุณไม่มีทางตรวจผลได้เลย การรันซ้ำไปเรื่อย ๆ อาจทำให้ มั่นใจในสิ่งที่ผิด มากขึ้นเท่านั้น

และนั่นคือเหตุผลที่ผมคิดว่าผู้เขียนงานชิ้นนี้สมควรได้รับเครดิตที่มากกว่ายอดไลก์

เพราะเขารายงานทั้งตอนที่สำเร็จ และตอนที่ระบบเลือกคำตอบ 55 แทนที่จะเป็น 95

เอกสารอ้างอิง

[1] X (Twitter), Alvaro Cintas (@dr_cintas), "Google just open-sourced its Harness²", 17 ตุลาคม 2026 · https://x.com/dr_cintas/status/2111536299836354864
[2] GitHub, google-research/harness2, ไฟล์ README (เข้าถึง 18 ตุลาคม 2026) · https://github.com/google-research/harness2/blob/main/README.md
[3] arXiv, Ruiyao Xu และคณะ, "Harness^2: Recursive Agent Harnessing for an Open World" ฉบับย่อ arXiv:2610.14224 ส่งเมื่อ 9 ตุลาคม 2026 · https://arxiv.org/abs/2610.14224
[4] arXiv, Ruiyao Xu และคณะ, "Harness^2: Recursive Agent Harnessing for an Open World" ฉบับเต็ม ส่งเมื่อ 9 ตุลาคม 2026 ภาคผนวก E.6 Failure Analysis และภาคผนวก F Limitations · https://arxiv.org/html/2610.14224v1
[5] arXiv, Yike Wang และคณะ, "Rethinking the Evaluation of Harness Evolution for Agents" arXiv:2607.12227 ปรับปรุงล่าสุด 5 ตุลาคม 2026 · https://arxiv.org/abs/2607.12227
[6] wavect.io, Kevin Riedl, "Google Harness²: Setup, Benchmarks and the Real Cost" 16 ตุลาคม 2026 · https://wavect.io/blog/google-harness2-setup-cost-safety/
[7] Lil'Log, Lilian Weng, "Harness Engineering for Self-Improvement" 4 กรกฎาคม 2026 · https://lilianweng.github.io/posts/2026-07-04-harness/
[8] GitHub, google-research/harness2, หน้าเว็บไซต์โปรเจกต์ (เข้าถึง 18 ตุลาคม 2026) · https://harness2.github.io/
[9] GitHub, google-research/harness2, ไฟล์ docs/BENCHMARKS.md คำแนะนำเบนช์มาร์กทั้งสาม (เข้าถึง 18 ตุลาคม 2026) · https://github.com/google-research/harness2/blob/main/docs/BENCHMARKS.md