Harness Engineering: การสร้างระบบล้อมรอบ AI Agent (2026)

TL;DR

Harness Engineering คืออะไร?

Harness engineering คือศาสตร์ในการสร้างระบบ, เครื่องมือ, ข้อจำกัด และลูปการตอบกลับ (feedback loops) ไว้รอบๆ AI coding agents เพื่อทำให้พวกมันทำงานได้อย่างน่าเชื่อถือและมีประสิทธิภาพ

คำนี้ถูกบัญญัติขึ้นโดย Mitchell Hashimoto (ผู้ร่วมก่อตั้ง HashiCorp) และได้รับความสนใจอย่างกว้างขวางเมื่อ OpenAI เผยแพร่บทความ Codex เกี่ยวกับหัวข้อนี้ในช่วงต้นปี 2026

แนวคิดหลักนั้นเรียบง่าย:

Agent = Model + Harness

โมเดลให้ความฉลาด (intelligence) ส่วน harness ทำให้ความฉลาดนั้น ใช้งานได้จริง บ่อยครั้งที่ harness ที่ดีกว่ามีความสำคัญมากกว่าตัวโมเดลที่ฉลาดกว่าด้วยซ้ำ

ทำไมถึงสำคัญในตอนนี้

ในปี 2025 ทุกทีมเริ่มนำ AI coding agents มาใช้ แต่ในปี 2026 ทีมที่เป็นผู้ชนะคือทีมที่ ทำวิศวกรรมสภาพแวดล้อมของ agent (engineered their agent environments) ไม่ใช่แค่เพียงทีมที่เลือกโมเดลที่ดีที่สุด

หลักการชี้นำของ Mitchell Hashimoto คือ:

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

นี่ไม่ใช่ prompt engineering แต่มันคือ วิศวกรรมระบบ (systems engineering) สำหรับ AI

หลักฐานยืนยัน: Harness > Model

LangChain ได้ทำการทดลองแบบควบคุมบน Terminal Bench 2.0 โดยที่ไม่มีการเปลี่ยนโมเดลพื้นฐานเลย พวกเขาเพิ่มความแม่นยำของ coding agent จาก 52.8% เป็น 66.5% ซึ่งคิดเป็นการพัฒนาขึ้นถึง 26% เพียงแค่การปรับปรุง harness เท่านั้น

การเปลี่ยนแปลงประกอบด้วย:

• ไฟล์บริบทที่ดีขึ้น (AGENTS.md)


• ข้อจำกัดของ output ที่มีโครงสร้างชัดเจน (Structured output constraints)


• ลูปการตรวจสอบด้วยตนเอง (Self-verification loops)


• การเพิ่มประสิทธิภาพของเครื่องมือ (Tool optimization)

7 ส่วนประกอบของ Harness

1. Context Engineering

Context engineering คือรากฐาน มันคือที่ที่คุณจะมอบแผนที่ของ codebase, ข้อตกลงร่วมกัน (conventions) และข้อจำกัดต่างๆ ให้กับ agent

• ไฟล์ CLAUDE.md / AGENTS.md ที่ root ของ repo
• แผนผัง directory และภาพรวมสถาปัตยกรรม (architecture overviews)
• กฎสไตล์การเขียนโค้ดและหลักการตั้งชื่อ

# ตัวอย่าง CLAUDE.md
## Architecture
- src/app/ — หน้าเพจ Next.js app router
- src/lib/ — utilities ส่วนกลาง และ API clients
- src/components/ — React components (จัดวางสไตล์ไว้ในที่เดียวกัน)

## Rules
- ใช้ server components เป็นค่าเริ่มต้น
- ห้าม import จาก node_modules โดยตรงใน components
- การเรียก API ทั้งหมดต้องผ่าน src/lib/api.ts

2. Architectural Constraints

แทนที่จะหวังว่า agent จะเลือกสถาปัตยกรรมที่ถูกต้อง ให้คุณ บังคับใช้มัน

• สถาปัตยกรรมแบบเลเยอร์ที่เข้มงวดซึ่งตรวจสอบโดย linters
• Structural tests ที่จะ fail หากมีการละเมิดรูปแบบ (patterns)
• ข้อจำกัดการ import ผ่านกฎ ESLint หรือ custom scripts

3. Tools & MCP Servers

Agent ต้องการเครื่องมือเพื่อให้ทำงานได้อย่างมีประสิทธิภาพ Harness ที่ดีที่สุดจะเปิดเผยเครื่องมือภายในผ่าน:

• CLI wrappers — แนะนำให้ใช้ CLI ที่เป็นที่รู้จักดี (git, docker, npm) มากกว่าเครื่องมือที่สร้างขึ้นเองโดยไม่มีมาตรฐาน
• MCP (Model Context Protocol) servers — ให้ agent สามารถเรียกใช้ API ภายใน, ฐานข้อมูล และบริการต่างๆ ของคุณได้
• File system access — จำกัดขอบเขตเฉพาะ directory ที่กำหนดเพื่อป้องกันความเสียหายที่ไม่ได้ตั้งใจ

4. Sub-Agents & Context Firewalls

เซสชันของ agent ที่ทำงานยาวนานจะสะสมบริบทจนในที่สุดประสิทธิภาพจะลดลง — สิ่งนี้เรียกว่า context rot (การเสื่อมถอยของบริบท)

วิธีแก้คือ: sub-agents พร้อมด้วย context firewalls

• แบ่งงานที่ซับซ้อนออกเป็นงานย่อยๆ (discrete sub-tasks)
• แต่ละงานย่อยทำงานในเซสชันของตัวเองพร้อมบริบทที่สดใหม่
• ส่งผ่านเฉพาะผลลัพธ์ที่มีโครงสร้าง (structured results) ระหว่าง agent ไม่ใช่บทสนทนาดิบๆ

1. Initializer Agent — วางแผนงาน, สร้างรายการฟีเจอร์
2. Coding Agent — ดำเนินการสร้างแต่ละฟีเจอร์แยกจากกัน

5. Hooks & Back-Pressure

ลูปการตอบกลับอัตโนมัติที่จะตรวจจับข้อผิดพลาดก่อนที่มันจะบานปลาย:

• Pre-commit hooks — การตรวจเช็ค type, linting, formatting
• Test runners — Agent ควรทำการรัน test หลังจากการเปลี่ยนแปลงทุกครั้ง
• Build verification — แจ้งเตือนความล้มเหลวทันที (fail fast) หาก build พัง

6. Self-Verification Loops

บังคับให้ agent ตรวจสอบงานของตัวเองก่อนที่จะทำเครื่องหมายว่างานเสร็จสิ้น:

• รันชุดการทดสอบ (test suite) หลังการเปลี่ยนแปลง
• ตรวจสอบว่าการ build ผ่าน
• ตรวจสอบว่า output ตรงกับข้อกำหนด (specification)
• ถ่ายภาพหน้าจอและเปรียบเทียบ (สำหรับงาน UI)

7. Progress Documentation

สำหรับงานที่ใช้เวลานาน (30 นาทีขึ้นไป):

• รักษาไฟล์ความคืบหน้า (progress file) ที่ติดตามขั้นตอนที่เสร็จสมบูรณ์แล้ว
• คอมมิตงานบ่อยๆ เพื่อให้เซสชันถัดไปสามารถทำงานต่อได้

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

ผลลัพธ์ในโลกแห่งความเป็นจริง

ทีม OpenAI Codex

วิศวกร 3 คน ผลิต codebase ขนาดล้านบรรทัด โดยไม่มีโค้ดที่เขียนด้วยมือเลยตลอด 5 เดือน พวกเขาทำค่าเฉลี่ย 3.5 merged PRs ต่อวิศวกรต่อวัน — ซึ่งเป็นประสิทธิภาพที่เป็นไปไม่ได้เลยหากไม่มี harness ที่สมบูรณ์

Harness ของพวกเขาประกอบด้วย: ข้อตกลงการคอมมิตที่เข้มงวด, การทดสอบอัตโนมัติในทุก PR และ agent-aware CI/CD pipelines

Stripe's "Minions"

ระบบภายในของ Stripe ผลิต 1,000+ merged PRs ต่อสัปดาห์ โดยใช้ AI agents Harness ของพวกเขาประกอบด้วย:

• การกำหนดขอบเขตงานที่ชัดเจนและแคบ (tightly scoped task definitions)
• การตรวจสอบโค้ด (code review) โดยมนุษย์ซึ่งเป็นขั้นตอนบังคับ
• การทดสอบ regression อัตโนมัติ
• ระบบ rollback อัตโนมัติ

สถาปัตยกรรม Agent คู่ของ Anthropic

Anthropic เผยแพร่วิธีการสร้าง harness ที่มีประสิทธิภาพสำหรับ agent ที่ทำงานยาวนาน:

• รายการฟีเจอร์ที่มีโครงสร้าง เป็นรูปแบบการส่งต่องานระหว่าง agent
• การติดตามความคืบหน้าผ่าน Git เพื่อให้ agent สามารถกลับมาทำงานต่อได้หลังจากการขัดจังหวะ
• เกณฑ์การจบงานที่ชัดเจน (Explicit exit criteria) เพื่อให้ agent รู้ว่าควรหยุดเมื่อใด

วิธีเริ่มต้นสร้าง Harness ของคุณ

ขั้นตอนที่ 1: สร้างไฟล์บริบทของคุณ

เพิ่ม CLAUDE.md (หรือ AGENTS.md) ไว้ที่ root ของโปรเจกต์:

# Project: [ชื่อโปรเจกต์ของคุณ]

## Stack
[Framework, language, database, hosting]

## Architecture
[โครงสร้าง directory พร้อมคำอธิบายสั้นๆ หนึ่งบรรทัด]

## Rules
[กฎเหล็ก 5-10 ข้อที่ agent ต้องปฏิบัติตาม]

## Common Tasks
[วิธีรัน tests, build, deploy]

ขั้นตอนที่ 2: เพิ่มข้อจำกัดทางโครงสร้าง

# ตัวอย่าง: กฎ ESLint ป้องกันการ import DB โดยตรงใน components
# .eslintrc — no-restricted-imports rule

ตั้งค่า pre-commit hooks ที่บังคับใช้กฎของคุณโดยอัตโนมัติ

ขั้นตอนที่ 3: สร้าง Build Verification Loops

ทำให้แน่ใจว่า agent ของคุณสามารถ:

1. รันการทดสอบ (npm test, pytest, ฯลฯ)


2. ตรวจสอบ types (tsc --noEmit, mypy)


3. Lint (eslint ., ruff check)

ขั้นตอนที่ 4: จำกัดขอบเขตของ Agent Sessions

อย่าให้ agent เห็น backlog ทั้งหมดของคุณ แต่ให้:

• หนึ่งฟีเจอร์ต่อหนึ่งเซสชัน
• หนึ่งการแก้บั๊กต่อหนึ่งเซสชัน
• เกณฑ์การยอมรับ (acceptance criteria) ที่ชัดเจนสำหรับแต่ละงาน

ขั้นตอนที่ 5: พัฒนา Harness อย่างต่อเนื่อง

ทุกครั้งที่ agent ทำผิดพลาด:

1. ระบุสาเหตุที่แท้จริง (root cause)
2. เพิ่มกฎ, ข้อจำกัด หรือ hook ที่ป้องกันสิ่งนั้น
3. ทดสอบการแก้ไข

Harness Engineering vs. Prompt Engineering

Prompt engineering ยังคงมีประโยชน์ แต่มันเป็นเพียงส่วนเล็กๆ ของภาพรวม Harness engineering คือตัวคูณประสิทธิภาพที่แท้จริง

บทบาทที่กำลังมาแรง: Harness Engineer

วิศวกรรมกำลังถูกแบ่งออกเป็นสองส่วน:

1. การสร้างสภาพแวดล้อม (Environment Building) — สร้างโครงสร้าง, เครื่องมือ, ข้อจำกัด และลูปการตอบกลับ
2. การบริหารจัดการงาน (Work Management) — วางแผน, ตรวจสอบ และประสานงานเซสชันของ agent ที่ทำงานขนานกัน

ข้อควรระวัง: อย่าสับสนกับ Harness.io

หากคุณค้นหา "Harness Engineering" เพื่อมองหาแพลตฟอร์ม DevOps — Harness.io เป็นคนละเรื่องกันเลย มันคือแพลตฟอร์ม CI/CD ที่ขับเคลื่อนด้วย AI ซึ่งมีมูลค่า 5.5 พันล้านดอลลาร์ (ข้อมูล ณ ธันวาคม 2025) ที่ให้บริการ continuous integration, delivery, feature flags, การจัดการต้นทุนคลาวด์ และการทดสอบความปลอดภัย

แม้ว่า Harness.io และ harness engineering จะใช้ชื่อเหมือนกัน แต่พวกเขากำลังแก้ปัญหาคนละอย่างกัน อย่างไรก็ตาม มีจุดที่น่าสนใจคือ: DevOps ที่ขับเคลื่อนด้วย AI ของ Harness.io ก็นับได้ว่าเป็นการนำหลักการของ harness engineering มาประยุกต์ใช้กับ deployment pipeline นั่นเอง

สรุปส่งท้าย

โมเดลคือเครื่องยนต์ Harness คือตัวรถ ไม่มีใครชนะการแข่งขันได้ด้วยแค่เครื่องยนต์เพียงอย่างเดียว

หากคุณกำลังใช้ AI coding agents ในปี 2026 โดยไม่ลงทุนใน harness ของคุณ แสดงว่าคุณกำลังทิ้งคุณค่าส่วนใหญ่ไป เริ่มต้นด้วยไฟล์บริบท, เพิ่มข้อจำกัด, สร้างลูปการตรวจสอบ และปรับปรุงทุกครั้งที่มีอะไรผิดพลาด

ทีมที่ส่งมอบงานได้เร็วที่สุดไม่ใช่ทีมที่ใช้โมเดลที่ดีกว่า แต่เป็นทีมที่ใช้ harness ที่ดีกว่า