คุณเคยเจอสถานการณ์แบบนี้ไหม?
Claude ตัวเดียวกัน, GPT-4o ตัวเดียวกัน—คนหนึ่งใช้มันเขียนโค้ด 1 ล้านบรรทัดใน 5 เดือน, อีกคนกลับทำให้มันทำงานเสถียรได้ไม่ถึงสองชั่วโมง
โมเดลเหมือนกัน แต่ผลลัพธ์ต่างกันราวฟ้ากับดิน
ปัญหาอยู่ที่ไหน?
ผมเพิ่งอ่านบทความจาก OpenAI, Anthropic, Martin Fowler และ Phil Schmid มาหลายชิ้น และพบว่าพวกเขากำลังพูดถึงสิ่งเดียวกัน
พวกเขาเรียกมันว่า Harness Engineering
พูดง่ายๆ คือการสร้าง "ระบบปฏิบัติการ" ให้ Agent ของคุณ
ก่อนอื่น มาทำความเข้าใจว่า Harness คืออะไร
Phil Schmid ได้เปรียบเทียบไว้อย่างดีในบล็อกโพสต์ของ HuggingFace
ลองนึกถึงระบบ Agent เหมือนคอมพิวเตอร์
โมเดลคือ CPU, ให้พลังการประมวลผลดิบ หน้าต่างบริบทคือ RAM, เก็บสิ่งต่างๆ ชั่วคราว Agent คือแอปพลิเคชันที่ทำงานอยู่บนนั้น
แล้วอะไรคือระบบปฏิบัติการ?
Harness คือระบบปฏิบัติการ
หากไม่มี OS, CPU ที่ทรงพลังที่สุดก็เป็นแค่ชิป คุณไม่สามารถพิมพ์งานบนชิปได้
เช่นเดียวกัน หากไม่มี Harness, โมเดลที่ฉลาดที่สุดก็เป็นแค่กล่องแชท ถ้าคุณปล่อยให้มันทำงานที่ซับซ้อนเป็นเวลาหนึ่งชั่วโมง จะเกิดอะไรขึ้นถ้ามันลืมบริบท? ใครจะหยุดมันไม่ให้เขียนโค้ดขยะ? จะเกิดอะไรขึ้นถ้ามันทำผิดพลาดและไม่รู้ตัวด้วยซ้ำ?
สิ่งเหล่านี้ไม่ใช่ปัญหาที่คุณแก้ได้ด้วย "การเปลี่ยนไปใช้โมเดลที่ฉลาดกว่า"
Martin Fowler พูดบางอย่างที่ติดอยู่ในใจผม: Harnesses อาจกลายเป็น "เทมเพลตบริการ" ในอนาคต เช่นเดียวกับที่คุณเริ่มโปรเจกต์ใหม่วันนี้ด้วยเทมเพลตบริการ คุณจะเริ่ม Agent ใหม่ด้วยเทมเพลต Harness
ผมคิดว่าการคาดการณ์นี้มีแนวโน้มจะเป็นจริง
ทำไมจู่ๆ มันถึงระเบิดในปี 2026?
เพราะตอนนี้โมเดลแข็งแกร่งพอแล้ว
ในปี 2024 ทุกคนแข่งขันกันว่าโมเดลของใครฉลาดกว่า มาถึงปี 2026 ช่องว่างระหว่างโมเดลระดับท็อปนั้นแคบมาก ถ้าคุณให้ Claude และ GPT แก้ปัญหาเดียวกัน คะแนนของพวกเขาจะต่างกันเพียงไม่กี่แต้ม
แต่ถ้าคุณปล่อยให้พวกเขาทำงานต่อเนื่อง 8 ชั่วโมง ช่องว่างจะปรากฏขึ้น
ช่องว่างนี้ไม่ได้อยู่ที่ตัวโมเดล แต่อยู่ที่ "harness" ที่ล้อมรอบมัน
ทีม Codex ของ OpenAI มีสถิติที่น่าทึ่ง พวกเขาใช้ Codex สร้างผลิตภัณฑ์ที่สมบูรณ์—5 เดือน, โค้ด 1 ล้านบรรทัด, เขียนด้วยมือเป็นศูนย์บรรทัด ตลอดกระบวนการ พวกเขาพบว่าคอขวดไม่ใช่ "โมเดลเขียนโค้ดได้หรือไม่" อีกต่อไป
คอขวดคือมนุษย์สามารถตรวจสอบโค้ดได้เร็วพอหรือไม่
ความเร็วในการส่งออกของโมเดลแซงหน้าความเร็วในการตรวจสอบของมนุษย์ ณ จุดนี้ การปรับแต่งโมเดลให้ดีขึ้นมีประโยชน์อะไร? คุณควรปรับแต่งกระบวนการตรวจสอบ การควบคุมคุณภาพ และข้อจำกัดทางสถาปัตยกรรม
นั่นคือสิ่งที่ Harness ทำ
สามเสาหลัก
แล้ว Harness จริงๆ แล้วประกอบด้วยอะไร?
หลังจากอ่านบทความเหล่านี้ ผมพบว่าแม้คำศัพท์จะแตกต่างกัน แต่มีสามเสาหลักหลัก
1. วงจรปิดการประเมินผล
นี่คือสิ่งที่ Anthropic เน้นมากที่สุด
แนวคิดหลักนั้นง่าย: Agent ไม่สามารถให้คะแนนตัวเองได้
ลองคิดดู: ถ้าฝึกงานทำรายงานเสร็จแล้วคุณถามว่าทำได้ดีไหม พวกเขาจะบอกว่า "ก็โอเค" คุณต้องมีคนอื่นมาประเมิน
Anthropic เรียกสิ่งนี้ว่า "Evaluation-Driven Development" ขั้นแรกกำหนดว่า "ทำได้ดี" เป็นอย่างไร จากนั้นให้ Agent ทำ และสุดท้ายให้ผู้ประเมินอิสระให้คะแนน
Evaluation-Driven Development คือเวอร์ชัน Agent ของ TDD เขียนเทสต์ก่อน แล้วค่อยเขียนโค้ด ยกเว้นว่าที่นี่ "เทสต์" คือสำหรับ Agent
ผู้ประเมินไม่ได้แค่ดูโค้ด แต่ลงมือใช้งานผลิตภัณฑ์จริง—ใช้ Playwright คลิกปุ่ม กรอกฟอร์ม และรันเทสต์—แล้วตัดสินตามมาตรฐานที่ชัดเจน
มีกรณีศึกษาที่น่าสนใจตรงนี้
Opus 4.5 ของ Anthropic พบช่องโหว่ในนโยบายการจองระหว่างการทดสอบการจองเที่ยวบิน โดยพบวิธีแก้ปัญหาที่ดีกว่าคำตอบมาตรฐาน
แต่ผู้ประเมินให้คะแนนว่า "ล้มเหลว"
ทำไม? เพราะผู้ประเมินไม่ได้คาดหวังวิธีแก้ปัญหาที่สร้างสรรค์ขนาดนั้น มีเพียงคำตอบมาตรฐานเดียว และเพราะ Agent หาวิธีที่ดีกว่าได้ มันจึงถูกลงโทษ
เรื่องนี้แสดงให้เห็นสองสิ่ง: หนึ่ง, Agents ฉลาดพอที่จะหาวิธีแก้ที่มนุษย์ไม่เคยคิด สอง, วงจรการประเมินไม่ได้แค่ตรวจสอบ Agent; มันยังตรวจสอบการประเมินด้วย ถ้าผู้ประเมินของคุณเข้มงวดเกินไป มันจะกลายเป็นคอขวด
ข้อมูลอีกชิ้น: Opus 4.5 ได้คะแนน 42% ใน CORE-Bench ตอนแรก หลังจากพวกเขาแก้ไขบั๊กการให้คะแนนและผ่อนคลายข้อจำกัดของ scaffold คะแนนพุ่งไปที่ 95%
บ่อยครั้ง ไม่ใช่โมเดลไม่ดีพอ แต่ Harness ของคุณมีปัญหา
ด้วยวิธีนี้ Anthropic ให้ Agent สร้างเกมที่สมบูรณ์ใน 6 ชั่วโมงด้วยราคา $200
2. ข้อจำกัดทางสถาปัตยกรรม
นี่คือความถนัดของทีม OpenAI Codex
คุณบอกฝึกงานว่า "โค้ดต้องมีเลเยอร์" พวกเขาพยักหน้า แล้วเขียน UI logic ลงใน database layer ทันที
การพูดไม่มีประโยชน์
แนวทางของ OpenAI คือ บังคับใช้โดยอัตโนมัติผ่าน linter และ CI โค้ดที่ละเมิดกฎสถาปัตยกรรมจะถูกปฏิเสธทันที โดยไม่ต้องผ่านการตรวจสอบด้วยซ้ำ
การแบ่งเลเยอร์โค้ดของพวกเขาเป็นแบบนี้: Types → Config → Service → UI แต่ละเลเยอร์สามารถพึ่งพาเลเยอร์ที่อยู่เหนือกว่าเท่านั้น ไม่ใช่ในทางกลับกัน กฎนี้ไม่ได้แค่เขียนในเอกสาร แต่เขียนใน linter เพื่อตรวจสอบอัตโนมัติ
ยิ่งไปกว่านั้น linter เหล่านี้ถูกสร้างโดย Codex เอง
Agent เขียนกฎของตัวเองแล้วปฏิบัติตาม
Martin Fowler พูดหลังจากอ่านบทความของ OpenAI:
"การเพิ่มความไว้วางใจและความน่าเชื่อถือต้องจำกัดพื้นที่ของโซลูชัน ซึ่งหมายถึงการสละความยืดหยุ่นบางส่วนในการ 'สร้างอะไรก็ได้'"
ยิ่งมีข้อจำกัดมากเท่าไหร่ ยิ่งน่าเชื่อถือมากขึ้นเท่านั้น
ฟังดูขัดกับสัญชาตญาณ แต่ข้อมูลพูดได้ LangChain ทดลอง: โดยไม่เปลี่ยนโมเดล แค่เปลี่ยน Harness อัตราผ่านของ Terminal Bench 2.0 พุ่งจาก 52.8% เป็น 66.5% Vercel ไปไกลกว่านั้น โดยลบเครื่องมือ Agent ออก 80% ส่งผลให้มีขั้นตอนน้อยลง เร็วขึ้น และผลลัพธ์ดีขึ้น
เครื่องมือน้อยลงมักนำไปสู่ประสิทธิภาพที่ดีขึ้น—ข้อสรุปนี้ได้รับการยืนยันซ้ำแล้วซ้ำเล่าในวงการ Agent
3. การจัดการความทรงจำ
เสาหลักนี้ถูกพูดถึงน้อยกว่า แต่ผมคิดว่าสำคัญที่สุดในระยะยาว
PrismerCloud ได้ทำงานเชิงลึกในทิศทางนี้
ปัญหาคือ: เมื่อ Agents หลายตัวแชร์ฐานความรู้ร่วมกัน Agent A เขียนประสบการณ์ และ Agent B อ่านเป็นความจริง แต่ถ้า Agent A ผิดล่ะ?
ภาพหลอนของ Agent หนึ่งตัวสามารถปนเปื้อน Agents ทั้งหมดผ่านฐานความรู้ที่แชร์กัน
แนวทางของ PrismerCloud คือการสร้าง "Evolution Engine" ทุกประสบการณ์ของ Agent จะถูกบันทึกเป็น "สัญญาณ" ก่อน เมื่อได้รับการยืนยัน สัญญาณจะถูกกลั่นเป็น "ยีน" ซึ่งได้รับการปรับปรุงอย่างต่อเนื่องตามผลลัพธ์จริง
พูดง่ายๆ ยีนคือความรู้ที่ได้รับการยืนยันและมีประสิทธิภาพ ถ้าไม่ได้รับการยืนยัน ก็ไม่นับ
มีสถิติที่น่าสนใจ: พรอมต์ 3 บรรทัดบวกกับระบบความจำทำงานได้ดีพอๆ กับพรอมต์ผู้เชี่ยวชาญที่ออกแบบอย่างพิถีพิถัน 200 บรรทัด ยิ่งไปกว่านั้น แบบแรกสามารถพัฒนาได้ ในขณะที่แบบหลังเป็นแบบคงที่
นั่นหมายความว่าถ้าระบบความจำของคุณดี คุณไม่จำเป็นต้องมีพรอมต์ที่ซับซ้อน Agent จะพัฒนาขึ้นเองตามธรรมชาติเมื่อเวลาผ่านไป
โบนัส: การต้านทานเอนโทรปี
นี่ไม่ใช่เสาหลักเดี่ยว แต่ควรค่าแก่การกล่าวถึง
ระบบ Agent เสื่อมลงตามธรรมชาติเมื่อเวลาผ่านไป เอกสารหมดอายุ สถาปัตยกรรมถูกเลี่ยง ฐานความรู้เต็มไปด้วยข้อมูลที่ล้าสมัย
แนวทางของ OpenAI คือการรัน "Refactoring Agent" เป็นระยะเพื่อสแกนหาความไม่สอดคล้องของเอกสารและการละเมิดสถาปัตยกรรม พวกเขาพูดได้ดีที่สุด:
"เมื่อ Agent มีปัญหา เราถือว่ามันเป็นสัญญาณ: ค้นหาว่าขาดอะไร ป้อนกลับเข้าไปในโค้ดเบส และให้ Codex เขียนการแก้ไขเสมอ"
เมื่อ Agent มีปัญหา อย่าแค่แก้ที่ Agent—ให้แก้ที่ Harness กรอบความคิดนี้คือกุญแจสำคัญ
ใครกำลังทำสิ่งนี้อยู่?
วงการนี้แบ่งออกเป็นสองเส้นทาง: โปรเจกต์โอเพนซอร์สที่คุณใช้ได้วันนี้ และแนวทางปฏิบัติภายในของบริษัทการค้าที่คุณทำได้แค่เรียนรู้วิธีการ
โปรเจกต์โอเพนซอร์ส: พร้อมใช้งาน
LangChain DeepAgents: น่าจะเป็นโปรเจกต์โอเพนซอร์สที่ใกล้เคียงกับ "Claude Code สากล" มากที่สุด การวางแผน, การจัดการไฟล์, การมอบหมายงานให้ sub-agent, การบีบอัดบริบทอัตโนมัติ—พร้อมใช้งานทันที 115k ดาวบน GitHub
DeerFlow 2.0: จาก ByteDance เปิดซอร์สในเดือนมีนาคม ถึง 39k ดาวในหนึ่งเดือน มันเรียกตัวเองว่า "SuperAgent Harness" เป็นการเขียนใหม่ทั้งหมดจาก v1 พร้อม sandbox execution, persistent memory และระบบทักษะที่ใช้ LangGraph
OpenHands: เชี่ยวชาญด้าน coding Agents ทำคะแนน 77.6% บน SWE-bench Verified เป็น model-agnostic และใช้ Laminar สำหรับการสังเกตการณ์ ติดตามทุกการกระทำของ Agent
SWE-agent: จาก Princeton และ Stanford มุ่งเน้นการทำให้ "evaluation-driven" พัฒนาสมบูรณ์แบบ
Goose: เปิดซอร์สโดย Block (Square/Cash App) Agent ทั่วไปบนเครื่องที่สามารถติดตั้ง dependencies, รันเทสต์ และจัดการไฟล์
PrismerCloud: มุ่งเน้นการจัดการความทรงจำและ evolution engine เป็นโซลูชันที่โตเต็มที่ที่สุดในการป้องกันการปนเปื้อนของภาพหลอนในระบบ multi-agent
Cognee: เอ็นจิ้นความจำที่ขับเคลื่อนด้วย knowledge graph สำหรับ Agents ที่ช่วยสร้างการเชื่อมต่อเชิงความหมายระหว่างข้อมูล
แนวทางปฏิบัติเชิงพาณิชย์: เรียนรู้วิธีการ
Claude Code + Agent SDK: มาตรฐานของ Anthropic สำหรับ Harness ทั่วไป ไม่ใช่แค่สำหรับการเขียนโค้ด พวกเขาใช้มันสำหรับการวิจัย การสร้างวิดีโอ และการจดบันทึก
OpenAI Codex: แนวทางปฏิบัติสูงสุดในข้อจำกัดทางสถาปัตยกรรม โค้ด 1 ล้านบรรทัดโดยไม่เขียนด้วยมือ อาศัย linter ที่สร้างอัตโนมัติและการตรวจสอบโดยเพื่อนของ Agent
บทเรียนที่ติดอยู่ในใจผม
Rich Sutton เขียนบทความคลาสสิกชื่อ "The Bitter Lesson" สรุปคือ วิธีการทั่วไปที่ใช้ประโยชน์จากการคำนวณจะเอาชนะวิธีการเฉพาะที่มนุษย์ออกแบบได้ในระยะยาว
บทเรียนนี้กำลังถูกพิสูจน์อีกครั้งในวงการ Agent
Manus ปรับโครงสร้าง Harness 5 ครั้งใน 6 เดือน LangChain ปรับสถาปัตยกรรมใหม่ 3 ครั้งในหนึ่งปี Vercel ลบเครื่องมือออก 80%
สร้างเพื่อลบทิ้ง
"ตรรกะอันชาญฉลาด" ที่คุณเขียนวันนี้อาจล้าสมัยในวันพรุ่งนี้เมื่อโมเดลอัปเกรด สถาปัตยกรรมของคุณต้องเป็นแบบโมดูลาร์และพร้อมที่จะถูกทิ้ง
Phil Schmid พูดบางอย่างที่น่าจดจำ:
"ความได้เปรียบทางการแข่งขันไม่ใช่พรอมต์อีกต่อไป มันคือ trajectories ที่ Harness ของคุณบันทึกไว้ ทุกความสำเร็จและความล้มเหลวคือข้อมูลสำหรับฝึกฝนรุ่นต่อไป"
ยิ่ง Harness ของคุณทำงานนานและสะสม trajectories มากเท่าไหร่ Agent ของคุณก็ยิ่งแข็งแกร่งขึ้น คุณไม่สามารถตามทันได้เพียงแค่เปลี่ยนโมเดล
สามขั้นตอน
ลองนึกถึงตำแหน่งของ Harness ในวิศวกรรม AI แบบนี้
Prompt Engineering แก้ปัญหา "จะพูดอะไร" ปฏิสัมพันธ์ครั้งเดียว
Context Engineering แก้ปัญหา "จะรู้อะไร" ให้ข้อมูลอ้างอิงและประวัติ
Harness Engineering แก้ปัญหา "จะทำงานอย่างต่อเนื่อง เสถียร และในวงกว้างได้อย่างไร" วงจรการประเมินรับประกันคุณภาพ ข้อจำกัดทางสถาปัตยกรรมรับประกันกฎเกณฑ์ และการจัดการความทรงจำรับประกันการสะสมประสบการณ์
หากไม่มี Harness Agent อาจจำสิ่งต่างๆ ได้ แต่ไม่มีผู้ควบคุม นำไปสู่ความโกลาหล เมื่อทั้งสามชั้นทำงานร่วมกัน คุณจะมีตัวละครที่สามารถทำงานระยะยาวได้อย่างแท้จริง
OpenAI, Anthropic และ LangChain กำลังทำสิ่งนี้อยู่แล้ว
แหล่งที่มา: OpenAI Harness Engineering, Anthropic Demystifying Evals, Phil Schmid (HuggingFace) The Importance of Agent Harness in 2026, Martin Fowler Harness Engineering, LangChain Agent Frameworks.
