ฮาร์เนสเอนจิเนียริง (Harness Engineering) คือแนวปฏิบัติในการสร้างกลไกเชิงโครงสร้างเพื่อป้องกันการเกิดซ้ำของข้อผิดพลาดที่ AI agent ก่อขึ้น ผ่านการออกแบบเอกสาร เครื่องมือ และข้อจำกัดทางสถาปัตยกรรม แนวคิดนี้แพร่หลายอย่างรวดเร็ว เมื่อการเผยแพร่ของ Mitchell Hashimoto และกรณีศึกษาจากทีมวิศวกรรมของ OpenAI ปรากฏขึ้นในช่วงเวลาใกล้เคียงกัน และได้รับการกล่าวถึงโดย Martin Fowler อีกด้วย

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

แทนที่จะเขียน prompt ใหม่แล้วหวังให้ดีขึ้น ให้สร้างกลไกที่ป้องกันไม่ให้เกิดข้อผิดพลาดเดิมซ้ำอีกในเชิงโครงสร้าง——นั่นคือแก่นแท้ของ harness engineering

หากจะยืมสำนวนของ OpenAI ก็คือแนวคิด "ไม่ใช่การพยายามให้หนักขึ้น แต่คือการเพิ่มความสามารถที่ขาดหายไป" เมื่อ output ของ agent ไม่เป็นไปตามที่คาดหวัง การเพิ่มข้อความเตือนลงใน prompt เป็นเพียงการแก้ปัญหาเฉพาะหน้าเท่านั้น harness engineering มุ่งเปลี่ยนแปลงฝั่ง environment ให้ถึงระดับที่ความล้มเหลวนั้นไม่สามารถเกิดขึ้นซ้ำได้อีกในทางกายภาพ

Prompt engineering คือการปรับให้เหมาะสมในแง่ "จะสื่อสารอะไร" การปรับแต่งโครงสร้างของข้อความ input ความชัดเจนของคำสั่ง และการยกตัวอย่างแบบ few-shot ช่วยยกระดับคุณภาพ output ของ model ในทางกลับกัน harness engineering คือการออกแบบ "สภาพแวดล้อมที่ agent ทำงานอยู่" โดยตรง เป็นแนวทางที่ครอบคลุมตั้งแต่ document, tool, linter, test ไปจนถึง CI/CD pipeline โดย prompt เป็นเพียงองค์ประกอบหนึ่งในนั้นเท่านั้น

ทั้งสองแนวทางไม่ได้แยกขาดจากกัน แต่มีความสัมพันธ์แบบเสริมซึ่งกันและกัน prompt ที่ดีเป็นส่วนหนึ่งของ harness ที่ดี แต่ก็มีความล้มเหลวบางอย่างที่ prompt เพียงอย่างเดียวไม่สามารถป้องกันได้ ตัวอย่างเช่น กฎที่ว่า "ห้ามรัน DROP TABLE กับ DB production" นั้น การบล็อกด้วยกลไกผ่าน pre-commit hook มีความน่าเชื่อถือมากกว่าการเขียนไว้ใน prompt

Context Engineering คือสาขาเทคนิคที่มุ่งเพิ่มประสิทธิภาพของ context (ข้อมูลอ้างอิง คำสั่ง และนิยามของเครื่องมือ) ที่ส่งให้กับโมเดล Tobi Lutke ซีอีโอของ Shopify อธิบายสิ่งนี้ว่าเป็น "ศิลปะแห่งการจัดเตรียม context ทั้งหมดให้ครบถ้วน เพื่อให้ LLM สามารถแก้ไขงานได้" ในขณะที่ Harness Engineering ครอบคลุมแนวคิดดังกล่าว และยังขยายขอบเขตการออกแบบออกไปนอกเหนือ context ไปสู่สิ่งที่อยู่ภายนอก ได้แก่ ข้อจำกัดจาก linter การตรวจสอบด้วย test และ quality gate ผ่าน CI/CD หาก Context Engineering คือ "สิ่งที่แสดงให้ agent เห็น" แล้ว Harness Engineering ก็คือการกำหนดในระดับสภาพแวดล้อมว่า "agent ทำอะไรได้และทำอะไรไม่ได้"

สิ่งที่ต้องระวังคือ context window ที่ใหญ่ขึ้นไม่ได้หมายความว่าประสิทธิภาพจะดีขึ้นเสมอไป งานวิจัยของ Chroma พบแนวโน้มว่าประสิทธิภาพของโมเดลจะลดลงเมื่อความยาวของ context เพิ่มขึ้น การสะสมของนิยามเครื่องมือและคำสั่งต่าง ๆ กลายเป็น noise ทำให้ agent ตกอยู่ในสภาวะที่ "รู้ทุกอย่างแต่ทำอะไรได้ดีสักอย่างไม่ได้" ซึ่งเรียกว่า Dumb Zone ในการออกแบบ Harness จึงให้ความสำคัญกับโครงสร้างของ context มากกว่าปริมาณ และแนวทาง Progressive Disclosure ที่เปิดเผยข้อมูลที่จำเป็นตามความต้องการในแต่ละช่วงเวลาถือว่ามีประสิทธิผล

ยิ่ง AI Agent มีความสามารถสูงขึ้นเท่าใด ความเสี่ยงที่จะ "พังเป็นครั้งคราว" ก็ยิ่งเพิ่มมากขึ้นเท่านั้น การพัฒนาความสามารถและกลไกการควบคุมจำเป็นต้องวิวัฒนาการไปพร้อมกัน

การสาธิต AI agent นั้นดูน่าประทับใจ เมื่อได้เห็นขั้นตอนการเขียนโค้ด รันเทสต์ และสร้าง PR ต่อเนื่องกัน ก็อยากนำมาใช้งานทันที แต่เมื่อเริ่มใช้งานจริงในทีม จะพบว่า 8 ใน 10 ครั้งทำงานได้ตามที่คาดหวัง แต่อีก 2 ครั้งที่เหลืออาจลบไฟล์ที่ไม่ควรลบ หรือทำการเปลี่ยนแปลงที่ละเลย architecture ที่มีอยู่เดิม

สภาวะ "สำเร็จ 80% · พัง 20%" นี้แก้ไขได้ยากด้วยการปรับปรุง prompt เพียงอย่างเดียว เนื่องจากรูปแบบความล้มเหลวของ agent จะแตกต่างกันในแต่ละ session และการระบุสิ่งที่ห้ามทำอย่างครอบคลุมใน prompt นั้นไม่ใช่เรื่องที่ทำได้จริงในทางปฏิบัติ

Hashimoto ได้เผยแพร่หลักการ "สร้างกลไกทุกครั้งที่เกิดข้อผิดพลาด" จากประสบการณ์การพัฒนา agent ของตนเอง ในช่วงเวลาใกล้เคียงกัน ทีม engineering ของ OpenAI ก็ได้เปิดเผยความรู้ที่ได้รับจากการใช้งาน agent ภายในองค์กรเช่นกัน เบื้องหลังที่ทั้งสองฝ่ายต่างสรุปผลได้เหมือนกันโดยอิสระนั้น มาจากสถานการณ์ที่การนำ agent ไปใช้งานจริงได้ก้าวข้ามเกณฑ์ระดับหนึ่ง และ "การสร้างเสถียรภาพด้านคุณภาพ" กลายเป็น bottleneck ร่วมกัน การที่ Martin Fowler ได้กล่าวถึงเรื่องนี้ทำให้การรับรู้แพร่กระจายไปสู่ชุมชด software engineering โดยรวม

องค์ประกอบของ Harness Engineering นั้นมีการจำแนกประเภทที่แตกต่างกันไปตามแต่ละผู้เชี่ยวชาญ แต่โดยทั่วไปสามารถจัดระเบียบได้เป็น 3 เลเยอร์หลัก

OpenAI อธิบายโดยใช้ 4 แกนหลัก ได้แก่ Context / Constraints / Feedback / Cleanup ในขณะที่ผู้ปฏิบัติงานรายอื่นใช้แกน Tools / Docs / Feedback loops เป็นต้น ซึ่งแสดงให้เห็นว่า framework ยังไม่มีมาตรฐานที่เป็นหนึ่งเดียว ในที่นี้จะอธิบายโดยจัดระเบียบเป็น 3 ชั้นที่ง่ายต่อการนำไปใช้ในงานจริง ได้แก่ เอกสาร (Document), เครื่องมือ (Tools) และข้อจำกัด (Constraints)

ในเอกสารที่ Agent ใช้อ้างอิง ควรระบุ invariants ของ repository และ coding conventions ที่ใช้งาน โดย OpenAI ใช้ไฟล์ชื่อ AGENTS.md และ Claude Code ใช้ CLAUDE.md เพื่อทำหน้าที่นี้

อย่างไรก็ตาม ดังที่ Martin Fowler ได้ชี้ให้เห็น เป้าหมายไม่ใช่ "การ maintain markdown จำนวนมาก" แนวปฏิบัติของ OpenAI คือการแยก index file ขนาดประมาณ 100 บรรทัดออกจากเอกสารรายละเอียดที่มีโครงสร้างชัดเจน (เช่น design document, specification, execution plan) สิ่งสำคัญคือการออกแบบโครงสร้างที่ให้ Agent เข้าถึงข้อมูลที่ต้องการได้ด้วยเส้นทางที่สั้นที่สุด

Ryan Lopopolo วิศวกรจาก OpenAI ได้แนะนำแนวคิดที่เรียกว่า "Taste Invariants (invariants แห่งรสนิยม)" แนวคิดนี้มองว่า เมื่อรู้สึกระหว่าง code review ว่า "ไม่ชอบอะไรบางอย่างโดยไม่แน่ใจว่าทำไม" หากสามารถอธิบายเหตุผลนั้นออกมาเป็นคำพูดได้ ก็สามารถเขียนมันออกมาเป็น rule ได้เช่นกัน ตัวอย่างเช่น ความรู้สึกไม่พอใจที่ว่า "helper function สำหรับ concurrency ถูก define ซ้ำกันหลายที่" สามารถแปลงเป็น custom ESLint rule ที่ว่า "ห้าม define function นั้นในที่อื่นนอกจาก official definition location" การเปลี่ยนความชอบส่วนตัวให้กลายเป็น constraint ที่ชัดเจน คือการฝัง "sense" ให้กับ Agent

ทางบริษัทเองก็ใช้งาน CLAUDE.md เช่นกัน และไม่ใช่เรื่องแปลกที่การเพิ่ม rule เพียงบรรทัดเดียวจะยกระดับคุณภาพของทั้ง session ที่ตามมา ในทางกลับกัน เราก็เคยพบว่าเมื่อ rule เกิน 500 บรรทัด อัตราการปฏิบัติตามของ Agent เริ่มลดลง ทำให้ตระหนักว่า "ปริมาณที่เขียน" สำคัญน้อยกว่า "การออกแบบโครงสร้าง"

แทนที่จะสั่งให้ Agent "ตรวจสอบด้วยตาเปล่า" ให้มอบเครื่องมือที่ช่วยทำการตรวจสอบโดยอัตโนมัติแทน ไม่ว่าจะเป็นการจับภาพหน้าจอ, test runner, linter หรือ MCP server

MCP (Model Context Protocol) คือโปรโตคอลมาตรฐานสำหรับให้ Agent เชื่อมต่อกับเครื่องมือภายนอกและแหล่งข้อมูลต่าง ๆ และถือเป็นเทคโนโลยีพื้นฐานในการสร้าง tool layer ของ harness ตัวอย่างเช่น หากเชื่อมต่อ Supabase MCP Agent จะสามารถตรวจสอบ DB schema โดยตรงก่อนเขียน query ซึ่งช่วยลดข้อผิดพลาดประเภท "SELECT column ที่ไม่มีอยู่จริง" ได้อย่างเป็นระบบ

ใน tool layer ยังมีกลไกที่มีประสิทธิภาพอีก 3 อย่าง ได้แก่ Hooks (ฮุก) คือ control flow แบบ deterministic ที่แทรกเข้าไปในเหตุการณ์ lifecycle ของ Agent (เช่น หลังเรียกใช้เครื่องมือ หรือเมื่อทำงานเสร็จสิ้น) โดยจะไม่แสดงผลลัพธ์ใด ๆ เมื่อสำเร็จ (เพื่อไม่ให้ context รก) และจะแสดง error เฉพาะเมื่อล้มเหลวเท่านั้น Sub-Agents (ซับเอเจนต์) คือการมอบหมายงานแต่ละชิ้นให้กับ child agent ที่แยกออกมาต่างหาก ทำหน้าที่เป็น "context firewall" เพื่อปกป้อง context ของ parent agent และ Back-Pressure (แบ็คเพรสเชอร์) คือกลไกที่เสริมความสามารถในการตรวจสอบตัวเองของ Agent โดยจะกลืนผลลัพธ์เมื่อ test ผ่าน และแสดงผลเฉพาะเมื่อล้มเหลว เพื่อเพิ่มประสิทธิภาพการใช้ context ให้สูงสุด

ทิศทางการพึ่งพาระหว่างเลเยอร์จะถูกตรวจสอบโดยอัตโนมัติด้วย custom linter เพื่อป้องกันไม่ให้ agent ทำการ commit การเปลี่ยนแปลงที่ทำลายโครงสร้างได้อย่างสิ้นเชิง แนวทางที่อ่านได้จากแนวปฏิบัติของ OpenAI คือการให้ความสำคัญกับการลงทุนใน linter, test และ pre-commit hook ที่ให้ผลลัพธ์แน่นอน มากกว่าคำสั่ง prompt ที่ไม่แน่นอน

แนวคิดนี้สอดคล้องกับแนวคิดของ guardrail เช่นกัน หาก AI guardrail คือ "กลไกในการตรวจสอบและควบคุม output ของโมเดล" แล้ว constraint layer ของ harness ก็คือ "กลไกในการกำหนดขอบเขตการกระทำของ agent ไว้ล่วงหน้า" การจำกัดการกระทำก่อนที่จะเกิดขึ้นมีต้นทุนต่ำกว่าการตรวจสอบ output ภายหลัง

โดยไม่เปลี่ยนโมเดลแต่ปรับปรุงเฉพาะ harness นั้นจะให้ผลลัพธ์ได้มากเพียงใด ผลการทดสอบของ LangChain บน Terminal Bench 2.0 นั้นชวนให้คิด ด้วยโมเดลเดิมที่ไม่มีการเปลี่ยนแปลงใดๆ เพียงแค่ปรับปรุงในชั้น harness ได้แก่ loop detection middleware (ที่จะกระตุ้นให้ทบทวนแนวทางเมื่อมีการแก้ไขไฟล์เดิมเกิน N ครั้ง), pre-completion checklist middleware (ที่บังคับให้ผ่านการตรวจสอบก่อนที่ agent จะสิ้นสุดการทำงาน) และการสลับระดับความเข้มข้นของการอนุมาน (reasoning cost สูงในช่วง planning phase, ระดับกลางในช่วง implementation phase และสูงอีกครั้งในช่วง verification phase) ก็ทำให้คะแนนเพิ่มขึ้นจาก 52.8% เป็น 66.5% โดยไม่ได้แตะต้องโมเดลแม้แต่น้อย

Anthropic ก็นำเสนออีกแนวทางหนึ่งเช่นกัน ในรูปแบบ Generator-Evaluator pattern นั้น agent ที่รับผิดชอบการ implement และ agent ที่ทำหน้าที่ประเมินคุณภาพจะถูกแยกออกจากกัน โครงสร้างนี้ได้รับแรงบันดาลใจจาก GAN (Generative Adversarial Network) เนื่องจากเมื่อ agent ประเมินผลลัพธ์ของตัวเองจะเกิด bias ที่ "ชื่นชมผลงานที่ธรรมดาอย่างมั่นใจ" ดังนั้นการแยกการประเมินออกมาเป็นอิสระจึงช่วยรับประกันความเป็นกลางได้ โดยก่อนเริ่ม implement จะมีการกำหนด sprint contract (เกณฑ์การยอมรับที่ชัดเจน) และ evaluation agent จะทำการให้คะแนนตามเกณฑ์ดังกล่าว

การวิศวกรรม Harness ไม่จำเป็นต้องเริ่มต้นด้วยการวางโครงสร้างพื้นฐานขนาดใหญ่ แต่สามารถค่อยๆ สะสมได้ทีละขั้น เริ่มจากการแก้ไขข้อผิดพลาดทีละจุด

ทุกครั้งที่ agent ล้มเหลว ให้บันทึกสิ่งที่เกิดขึ้น สาเหตุ และวิธีป้องกันไว้ในบรรทัดเดียว รูปแบบไม่สำคัญ จะเป็น GitHub Issue, Notion หรือไฟล์ข้อความก็ได้ สิ่งสำคัญคือการมีเกณฑ์ตัดสินใจว่า "หากพบความผิดพลาดเดิมซ้ำสองครั้ง นั่นคือปัญหาที่ต้องป้องกันด้วยระบบ"

เลือกความล้มเหลวที่เกิดขึ้นบ่อยที่สุดจาก error log แล้วเพิ่มเป็น rule ใน CLAUDE.md (หรือ AGENTS.md)

เพียงบรรทัดเดียวนี้ จะช่วยลดโอกาสที่ agent จะทำผิดพลาดซ้ำในทุก session ถัดไปได้อย่างมีนัยสำคัญ การสะสม rule ทีละ 1 ความผิดพลาด ต่อ 1 rule มีประสิทธิผลมากกว่าการพยายามออกแบบระบบเอกสารที่สมบูรณ์แบบตั้งแต่ต้น

กฎที่เขียนไว้ในเอกสารซึ่งสามารถตรวจสอบได้โดยอัตโนมัติ ควรย้ายไปไว้ใน pre-commit hook หรือ custom linter แทน กฎในเอกสารนั้นเป็นเพียง "แนวทางที่อยากให้ปฏิบัติตาม" แต่ linter จะกลายเป็น "กำแพงที่บล็อกการละเมิดได้จริงในทางกายภาพ" แนวคิดนี้เหมือนกับ "shift left" ในบริบทของ DevOps นั่นคือการเลื่อนจังหวะการตรวจจับปัญหาให้เร็วขึ้นมากที่สุดเท่าที่จะทำได้

เมื่อ Agent แพร่หลายมากขึ้น งานของวิศวกรกำลังเปลี่ยนทิศทางจาก "การเขียนโค้ด" ไปสู่ "การจัดเตรียมสภาพแวดล้อมที่ช่วยให้ Agent ทำงานได้อย่างถูกต้อง"

จากแนวปฏิบัติของ OpenAI สามารถอ่านทิศทางได้ว่างานของวิศวกรกำลังเคลื่อนน้ำหนักไปสู่การดูแลให้ระบบพื้นฐาน (CI/CD · telemetry) ทำงานได้อย่างเสถียร การวางโครงสร้าง repository และ documentation รวมถึงการขยายขีดความสามารถของแรงงานมนุษย์ผ่าน AI นับเป็นการเปลี่ยนผ่านจากยุคที่วัดผลิตภาพด้วยจำนวนบรรทัดโค้ด สู่ยุคที่วัดด้วยคุณภาพของ output ที่ agent สร้างขึ้น

Birgitta Bockeler ผู้ร่วมเขียนงานกับ Martin Fowler ได้จัดระเบียบรูปแบบความสัมพันธ์ระหว่างมนุษย์กับ agent ออกเป็น 3 โหมด Outside the Loop (vibe coding) คือโหมดที่ระบุแค่ผลลัพธ์แล้วมอบหมายทุกอย่างให้ agent โดยมีความเสี่ยงที่วิธีแก้ปัญหาที่ไม่มีประสิทธิภาพจะสะสมพอกพูน In the Loop คือโหมดที่มนุษย์ตรวจสอบ output ทีละขั้นตอน แต่เกิด bottleneck เมื่อความเร็วในการสร้างของ agent แซงหน้าความสามารถในการ review ของมนุษย์ โหมดที่แนะนำคือ On the Loop ซึ่งเป็นโหมดที่มุ่งเน้นการปรับปรุง harness มากกว่า output โดยตรง เมื่อรู้สึกไม่พอใจ แทนที่จะแก้ไข deliverable โดยตรง ให้เปลี่ยน harness เพื่อยกระดับ output ทั้งหมดในอนาคต การรักษาวินัยนี้ได้หรือไม่คือปัจจัยชี้ขาดว่า harness engineering จะหยั่งรากได้หรือเปล่า

แนวคิดนี้สอดคล้องกับ HITL (Human-in-the-Loop) ด้วย แทนที่มนุษย์จะดำเนินการทุกขั้นตอนด้วยตนเอง บทบาทจะเปลี่ยนไปสู่การกำกับดูแล ตรวจสอบ และอนุมัติงานของ agent แทน harness engineering คือการลงทุนเพื่อลดต้นทุนในการกำกับดูแลนี้

หากปล่อยทิ้งไว้ คุณภาพของผลงานที่ AI สร้างขึ้นจะค่อยๆ เสื่อมลงทีละน้อย OpenAI รับมือกับปัญหานี้ด้วยการกำหนด Golden Principles (หลักการที่ต้องยึดถือ) การให้คะแนนเป็นระยะ และการสร้าง PR สำหรับการแก้ไขอัตโนมัติ สิ่งที่น่าสนใจคือ ผลจากการนำ harness engineering มาใช้ ทำให้ OpenAI เพิ่มการประชุม daily standup มากขึ้น ยิ่ง agent สร้างงานได้เร็วเท่าไร architectural pattern ก็ยิ่งอาจเปลี่ยนแปลงได้มากระหว่างการ check-in แต่ละครั้ง จึงมีการกำหนดการ sync รายวัน 30 นาทีเพื่อตรวจจับ direction drift ได้ตั้งแต่เนิ่นๆ ด้วยระบบนี้ มีรายงานว่าสามารถจัดการ PR ได้มากกว่า 1,500 รายการในระยะเวลา 5 เดือน และผลิตภาพต่อคนเพิ่มขึ้นจากเดิมที่เทียบเท่า 1 ใน 4 ของวิศวกร ไปสู่ระดับ 3 ถึง 10 เท่า

harness ไม่ใช่สิ่งที่สร้างครั้งเดียวแล้วจบ แต่ควรออกแบบโดยตั้งสมมติฐานว่าจะต้องสร้างใหม่ทุกครั้งที่ความสามารถของ agent เพิ่มขึ้น การตรวจสอบของ Anthropic ก็ยืนยันเช่นกันว่า สมมติฐานของ harness เปลี่ยนแปลงไปตามวิวัฒนาการของโมเดล เช่น การอัปเกรดโมเดล (Sonnet → Opus) ทำให้การ reset context ที่เคยจำเป็นก่อนหน้านี้กลายเป็นสิ่งที่ไม่จำเป็นอีกต่อไป

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

เมื่อ CLAUDE.md มีความยาวเกิน 1,000 บรรทัด จะส่งผลให้ context window ของ agent ถูกใช้งานอย่างหนัก และยิ่งทำให้กฎสำคัญต่างๆ ถูกฝังจนหาได้ยาก แนวปฏิบัติของ OpenAI เองก็แนะนำให้รักษาขนาดของ index ไว้ที่ประมาณ 100 บรรทัด และแยกรายละเอียดออกไปไว้ในไฟล์แยกต่างหาก หัวใจสำคัญของการออกแบบจึงไม่ใช่ "การเขียนทุกอย่างลงในไฟล์เดียว" แต่คือ "การสร้างโครงสร้างที่ช่วยให้เข้าถึงข้อมูลที่จำเป็นได้อย่างรวดเร็วที่สุด"

การเพิ่มข้อห้ามอย่างไม่มีขีดจำกัดจะทำให้ agent ไม่สามารถดำเนินการที่ปลอดภัยได้เลย ควรจำกัดข้อจำกัดไว้เฉพาะ "ข้อผิดพลาดที่เกิดขึ้นบ่อยและมีผลกระทบสูง" เท่านั้น ส่วนที่เหลือให้อยู่ในรูปแบบคำแนะนำในเอกสารแทน การแยกแยะการใช้งานระหว่าง constraint และ guidance เป็นสิ่งสำคัญ และไม่จำเป็นต้องทำให้ทุกอย่างเป็น hard block

Prompt Engineering คือเทคนิคในการปรับแต่ง "input ที่ส่งให้โมเดล" ส่วน Harness Engineering คือแนวปฏิบัติในการออกแบบ "สภาพแวดล้อมทั้งหมดที่ agent ทำงานอยู่" โดย prompt นั้นเป็นส่วนหนึ่งของ harness และทั้งสองไม่ได้แยกขาดจากกัน แต่มีความสัมพันธ์เชิงเสริมซึ่งกันและกัน

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

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

ในการตรวจสอบของ Anthropic พบว่าการสร้าง Full Harness (รูปแบบ Generator-Evaluator + Sprint Contract + การประเมินแบบ Calibration) ใช้เวลาประมาณ 6 ชั่วโมงและค่าใช้จ่าย 200 ดอลลาร์ ในขณะที่ Agent แบบ Standalone ที่ไม่มี Harness ใช้เวลาเพียง 20 นาทีและค่าใช้จ่าย 9 ดอลลาร์ อย่างไรก็ตาม คุณภาพของผลลัพธ์ที่ได้มีความแตกต่างกันอย่างมีนัยสำคัญ การตัดสินใจด้านต้นทุนนั้นแปรผันตามความสำคัญของ "สิ่งที่มอบหมายให้ Agent ดำเนินการ" หาก Script นั้นเป็นแบบใช้แล้วทิ้ง ก็ไม่จำเป็นต้องใช้ Full Harness แต่สำหรับการสร้าง Production Code อย่างต่อเนื่อง การลงทุนดังกล่าวถือว่าคุ้มค่า

Harness Engineering คือแนวปฏิบัติเพื่อทำให้คุณภาพของ AI Agent มีความเสถียรด้วย "โครงสร้าง" ไม่ใช่ "การอธิษฐาน" โดยค่อยๆ สร้างขึ้นทีละชั้น ได้แก่ ฐานความรู้จากเอกสาร การตรวจสอบอัตโนมัติด้วยเครื่องมือ (รวมถึง Hooks, Sub-Agents และ Back-Pressure) และการจำกัดพฤติกรรมด้วยข้อจำกัดทางสถาปัตยกรรม จากการทดสอบของ LangChain พบว่าการปรับปรุง Harness เพียงอย่างเดียวทำให้คะแนนเพิ่มขึ้นจาก 52.8% เป็น 66.5% ซึ่งแสดงให้เห็นว่าการออกแบบสภาพแวดล้อมสามารถเปลี่ยนแปลงคุณภาพได้อย่างมีนัยสำคัญ โดยไม่จำเป็นต้องเปลี่ยน Model เลย

ก้าวแรกนั้นเล็กน้อยมาก เพียงแค่บันทึกข้อผิดพลาดของ Agent หนึ่งรายการ และเพิ่มกฎหนึ่งบรรทัดใน CLAUDE.md จากจุดเริ่มต้นนั้น หากค่อยๆ นำความล้มเหลวที่เกิดขึ้นบ่อยไปทำให้เป็นอัตโนมัติด้วย Linter หรือ Pre-commit Hook คุณภาพการดำเนินงาน Agent ของทั้งทีมก็จะดีขึ้นอย่างต่อเนื่อง สิ่งสำคัญคือการรักษาท่าทีแบบ "On the Loop" ที่ Fowler และคณะแนะนำ นั่นคือแทนที่จะแก้ไข Output โดยตรง ให้ปรับปรุง Harness เพื่อยกระดับ Output ทั้งหมดที่จะตามมาในอนาคต