วิศวกรรม Agent Harness

เอเจนต์เขียนโค้ดคือโมเดลบวกกับทุกสิ่งที่สร้างขึ้นรอบๆ วิศวกรรมฮาร์เนส (Harness Engineering) ถือว่าโครงสร้างนั้นเป็นสิ่งมีชีวิตที่ปรับปรุงได้ทุกครั้งที่เอเจนต์ทำผิด

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

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

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

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

ตอนนี้สาขาวิชานั้นมีชื่อแล้ว @Vtrivedy10 บัญญัติคำว่า "วิศวกรรมฮาร์เนส" (harness engineering) พร้อมให้รายละเอียดที่ชัดเจนว่าฮาร์เนสคืออะไรและแต่ละส่วนมีไว้ทำไม เสียงอื่นๆ ในอุตสาหกรรม เช่น @dexhorthy ที่ติดตามรูปแบบที่เกิดขึ้นใหม่, HumanLayer ที่มองว่าความล้มเหลวของเอเจนต์เป็น "ปัญหาทักษะ" ในการกำหนดค่า, ทีมวิศวกรรมของ Anthropic ที่เผยแพร่คู่มือการออกแบบแอปที่ทำงานยาวนาน, และ Birgitta Böckeler ที่สำรวจประสบการณ์ฝั่งผู้ใช้ — ล้วนมาบรรจบกันที่แนวคิดเดียวกัน

โพสต์นี้รวบรวมแนวคิดเหล่านั้นเข้าด้วยกัน

ฮาร์เนสคืออะไรกันแน่?

คำจำกัดความหลักของ Trivedy ทำหน้าที่ส่วนใหญ่:

เอเจนต์ = โมเดล + ฮาร์เนส ถ้าคุณไม่ใช่โมเดล แสดงว่าคุณคือฮาร์เนส

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

โดยรูปธรรม ฮาร์เนสประกอบด้วย:

• พรอมต์ระบบ, CLAUDE.md, AGENTS.md, ไฟล์ทักษะ, และคำแนะนำของซับเอเจนต์
• เครื่องมือ, ทักษะ, เซิร์ฟเวอร์ MCP, และคำอธิบายทางเทคนิค
• โครงสร้างพื้นฐานที่รวมมา เช่น ระบบไฟล์, แซนด์บ็อกซ์, และเบราว์เซอร์ไร้หัว
• ตรรกะการประสานงานสำหรับสร้างซับเอเจนต์, จัดการการส่งต่อ, และกำหนดเส้นทางโมเดล
• ฮุคและมิดเดิลแวร์สำหรับการทำงานที่แน่นอน เช่น การตรวจสอบ lint หรือการบีบอัดบริบท
• เครื่องมือสังเกตการณ์สำหรับบันทึก, ร่องรอย, ต้นทุน, และการวัดเวลาแฝง

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

แม้สิ่งนี้จะครอบคลุมพื้นที่ขนาดใหญ่ แต่มันคือพื้นที่ของคุณ ไม่ใช่ของผู้ให้บริการโมเดล Claude Code, Cursor, Codex, Aider, และ Cline ล้วนเป็นฮาร์เนส โมเดลพื้นฐานอาจเหมือนกันข้ามแพลตฟอร์ม แต่พฤติกรรมที่คุณพบนั้นถูกกำหนดโดยฮาร์เนส

มาปรับกรอบ "ปัญหาทักษะ" กันใหม่

เป็นเรื่องปกติที่จะเห็นวิศวกรโทษโมเดลเมื่อเอเจนต์ทำอะไรไร้สาระ และมักจะเก็บปัญหาไว้รอ "เวอร์ชันถัดไป" เพื่อแก้ไข

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

ตามที่ HumanLayer กล่าว: "มันไม่ใช่ปัญหาโมเดล มันเป็นปัญหาการกำหนดค่า" ลองพิจารณาเกณฑ์วัดประสิทธิภาพ: โมเดลชั้นนำที่รันภายในเฟรมเวิร์กสำเร็จรูปมักจะได้คะแนนต่ำกว่าโมเดลเดียวกันที่รันในฮาร์เนสที่ปรับแต่งเองอย่างมาก การย้ายโมเดลไปยังสภาพแวดล้อมที่มีเครื่องมือจัดการโค้ดที่ดีกว่า พรอมต์ที่กระชับกว่า และแรงดันย้อนกลับที่เฉียบคมกว่า สามารถปลดล็อกความสามารถที่การตั้งค่าเดิมทิ้งไว้

ช่องว่างระหว่างสิ่งที่โมเดลในปัจจุบันสามารถทำได้ในทางทฤษฎีกับสิ่งที่คุณเห็นจริงๆ ส่วนใหญ่เป็นช่องว่างของฮาร์เนส

กลไกเฟือง: ทุกความผิดพลาดกลายเป็นกฎ

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

ถ้าเอเจนต์ส่ง PR ที่มี test ที่ถูกคอมเมนต์ไว้และถูก merge โดยไม่ได้ตั้งใจ นั่นคืออินพุต AGENTS.md รุ่นถัดไปต้องระบุว่า: "ห้ามคอมเมนต์ test; ให้ลบหรือแก้ไข" ฮุคก่อน commit ถัดไปควรแฟล็ก .skip( ใน diff โดยอัตโนมัติ ซับเอเจนต์ผู้ตรวจสอบต้องถูกอัปเดตให้บล็อก test ที่ถูกคอมเมนต์

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

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

การทำงานย้อนกลับจากพฤติกรรม

วิธีที่มีประสิทธิภาพที่สุดในการออกแบบฮาร์เนสคือเริ่มจากพฤติกรรมที่ต้องการแล้วสร้างส่วนประกอบที่ส่งมอบมัน: พฤติกรรมที่เราต้องการ → การออกแบบฮาร์เนสเพื่อให้บรรลุ

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

ระบบไฟล์และ Git — สถานะที่คงทน

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

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

Bash และการรันโค้ด: เครื่องมืออเนกประสงค์

เอเจนต์ส่วนใหญ่ทำงานบนลูป ReAct: คิด, กระทำผ่านการเรียกเครื่องมือ, สังเกต, ทำซ้ำ แทนที่จะสร้างเครื่องมือล่วงหน้าสำหรับทุกการกระทำที่คิดได้ การให้เอเจนต์เข้าถึง bash ทำให้มันสามารถสร้างสิ่งที่ต้องการได้ทันที

เอเจนต์โดยทั่วไปเก่งเรื่องคำสั่ง shell ทำให้ bash และการรันโค้ดเป็นกลยุทธ์เริ่มต้นสำหรับการแก้ปัญหาอัตโนมัติ

แซนด์บ็อกซ์และเครื่องมือเริ่มต้น

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

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

หน่วยความจำและการค้นหา: การเรียนรู้ต่อเนื่อง

โมเดลไม่มีความรู้เกินกว่าน้ำหนักการฝึกและบริบทปัจจุบัน ฮาร์เนสเชื่อมช่องว่างนี้โดยใช้ไฟล์หน่วยความจำ (เช่น AGENTS.md) ที่ฉีดความรู้เข้าไปในทุกเซสชัน

สำหรับข้อมูลเรียลไทม์ เช่น เวอร์ชันไลบรารีใหม่หรือข้อมูลสด การค้นหาเว็บและเครื่องมือ MCP ถูกฝังโดยตรงในฮาร์เนส

การต่อสู้กับบริบทเสื่อม

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

• การบีบอัด: สรุปและถ่ายบริบทเก่าอย่างชาญฉลาดเพื่อป้องกันข้อผิดพลาดของ API
• การถ่ายการเรียกเครื่องมือ: เก็บผลลัพธ์เครื่องมือขนาดใหญ่ (เช่น log 2,000 บรรทัด) ในระบบไฟล์ ในขณะที่เก็บเฉพาะส่วนหัวและส่วนท้ายที่จำเป็นในบริบท
• การเปิดเผยแบบค่อยเป็นค่อยไป: เปิดเผยคำแนะนำและเครื่องมือเมื่องานต้องการอย่างชัดเจนเท่านั้น แทนที่จะโหลดทุกอย่างตั้งแต่เริ่มต้น

การทำงานระยะยาว

งานอัตโนมัติที่ใช้เวลานานประสบปัญหาการหยุดก่อนกำหนดและการ分解ปัญหาไม่ดี ฮาร์เนสตอบโต้ด้วยการออกแบบโครงสร้าง:

• ลูป: สกัดกั้นความพยายามของโมเดลที่จะออกและบังคับให้มันดำเนินการต่อตามเป้าหมายที่สำเร็จในหน้าต่างบริบทใหม่
• การวางแผน: บังคับให้โมเดล分解เป้าหมายเป็นไฟล์แผนทีละขั้นตอน, ตรวจสอบงานผ่านฮุคยืนยันตนเองหลังจากแต่ละขั้นตอน
• การแยก: แยกการสร้างและการประเมินเป็นเอเจนต์ที่แตกต่างกัน, ป้องกันอคติเชิงบวกที่โมเดลมีเมื่อให้คะแนนงานของตัวเอง

ฮุคคือชั้นบังคับใช้ของคุณ

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

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

นี่คือกฎและตัวเลือกเครื่องมือ

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

หลักการเดียวกันใช้กับเครื่องมือ เครื่องมือที่เน้นเฉพาะสิบตัวจะดีกว่าเครื่องมือที่ทับซ้อนกันห้าสิบตัวเสมอ

ยิ่งไปกว่านั้น เนื่องจากคำอธิบายเครื่องมือเติมพรอมต์ การรวมภายนอกที่เป็นอันตรายหรือเลอะเทอะ (เช่น เซิร์ฟเวอร์ MCP ที่ไม่ได้รับการยืนยัน) สามารถฉีดพรอมต์ที่ไม่ดีเข้าไปในเอเจนต์ก่อนที่มันจะเริ่มทำงานด้วยซ้ำ

สิ่งนี้มีลักษณะอย่างไรในระบบผลิต

ภาพสาธารณะที่ชัดเจนที่สุดที่ฉันเคยเห็นของฮาร์เนสที่สมบูรณ์คือการแยกส่วน (โดยประมาณ) ของ สถาปัตยกรรม Claude Code โดย Fareed Khan

เกือบทุกแนวคิดจากส่วนก่อนหน้าปรากฏบนแผนภาพนี้เป็นส่วนประกอบที่มีชื่อ การฉีดบริบทคือชั้นความรู้ สถานะลูปอยู่ในที่เก็บหน่วยความจำและตัวแยก worktree ฮุคการกระทำที่ทำลายล้างอยู่หลังเกตการอนุญาต ไฟร์วอลล์บริบทของซับเอเจนต์คือชั้นหลายเอเจนต์ทั้งหมด ทะเบียนการกระจายเครื่องมือคือที่ที่เซิร์ฟเวอร์ MCP และ bash เสียบเข้าไป เส้นทางของ Claude Code เกี่ยวกับฮาร์เนสอย่างน้อยก็เท่ากับโมเดลที่อยู่ข้างใต้

ฮาร์เนสไม่หดหาย มันเคลื่อนที่

เมื่อโมเดลดีขึ้น ความจำเป็นสำหรับฮาร์เนสไม่ได้หายไป — มันเปลี่ยนไป

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

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

แล้วลูปการฝึกอบรมล่ะ?

มีลูปป้อนกลับที่ทำงานอยู่ระหว่างการออกแบบฮาร์เนสและการฝึกโมเดล

โมเดลในปัจจุบันมักถูกฝึกหลังด้วยฮาร์เนสเฉพาะในลูป ทำให้เกิดการ overfitting ในระดับหนึ่ง โมเดลจะเก่งเป็นพิเศษในการกระทำเฉพาะที่นักออกแบบฮาร์เนสให้ความสำคัญ (เช่น การดำเนินการระบบไฟล์, bash, การกระจายซับเอเจนต์)

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

ฮาร์เนสในฐานะบริการ (HaaS)

อุตสาหกรรมกำลังเปลี่ยนจากการสร้างบน LLM API (ซึ่งให้การเติมเต็ม) ไปสู่การสร้างบน Harness API (ซึ่งให้รันไทม์) SDK ในปัจจุบันมีลูป, เครื่องมือ, การจัดการบริบท, ฮุค, และแซนด์บ็อกซ์พร้อมใช้ทันที

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

นี่คือสิ่งที่ทำให้การแก้ปัญหาเป็น scalable: คุณกำลังปรับแต่งพื้นผิวการกำหนดค่าที่แยกส่วนอย่างดี แทนที่จะคิดค้นสถาปัตยกรรมเอเจนต์ทั้งหมดใหม่

อนาคตจะไปทางไหน

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

ปัญหาที่น่าตื่นเต้นที่สุดกำลังก้าวไปไกลกว่าเอเจนต์เดี่ยว: การประสานงานหลายเอเจนต์แบบขนาน, การทำให้เอเจนต์สามารถวิเคราะห์ร่องรอยของตัวเองเพื่อแก้ไขความล้มเหลวระดับฮาร์เนส, และการสร้างสภาพแวดล้อมที่ประกอบเครื่องมือแบบทันเวลาพอดี

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

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