Harness: มันไม่ใช่ Tool และไม่ได้ทำให้ Agent เก่งขึ้น — มันทำให้ Agent ไปได้เฉพาะทางที่เรายอมให้ไป

บทคัดย่อ

คำว่า harness ถูกใช้กว้างจนเกือบทุกอย่างรอบ LLM ถูกเรียกว่า harness ทั้ง tool, MCP, memory, context, prompt, skill, orchestration และ UI ผมเถียงว่าการใช้คำแบบนั้นทำให้เราพลาดความหมายทางวิศวกรรมของมัน Harness ไม่ใช่ tool และไม่ได้เพิ่ม capability ให้ model เพราะ model มี capability อยู่แล้ว harness คือสิ่งที่จำกัดและจัดช่องทางว่า capability นั้นจะเดินไปถึง outcome อย่างไร ผมไล่จาก harness ของม้า การแยก model / tool / harness งานของ Mitchell Hashimoto และ OpenAI ไปจนถึงเหตุผลที่ workflow และ guardrail ยังไม่ใช่ harness สิ่งที่คุณจะได้กลับไปคือเกณฑ์แยกว่าอะไรคือ instruction และอะไรคือ control structure ที่ทำให้ agent ข้าม step ไม่ได้

---

🔍 คลิกเพื่อขยายภาพเต็ม คลิกที่ใดก็ได้เพื่อปิด

ช่วงหลังคำว่า AI harness, agent harness และ harness engineering ถูกใช้บ่อยขึ้นมาก จนเริ่มเกิดปัญหาว่าแทบทุกอย่างที่อยู่รอบ LLM ถูกเรียกว่า “harness” ไม่ว่าจะเป็น tools, MCP, memory, context, prompt, skills หรือ orchestration

การใช้คำแบบนั้นอาจสะดวกในเชิง umbrella term แต่มีอันตรายอย่างหนึ่งคือ มันทำให้เราพลาดความหมายทางวิศวกรรมที่สำคัญที่สุดของคำว่า harness

สิ่งสำคัญที่สุดคือ:

Harness ≠ Tool
Harness ≠ การเพิ่ม capability ให้ model

ภาพที่ตรงกว่าคือ:

Model มี capability อยู่แล้ว → Harness จำกัดและจัดช่องทางว่า capability นั้นจะถูกใช้ไปทางไหน จนถึง outcome

Harness ไม่ได้มีหน้าที่ทำให้ agent “ฉลาดขึ้น”

มันมีหน้าที่ทำให้ agent ที่มีความสามารถอยู่แล้ว สามารถเคลื่อนที่ภายในระบบได้เฉพาะในลักษณะที่เรายอมรับ

1. กลับไปที่ความหมายดั้งเดิมของคำว่า Harness

คำว่า harness มีอยู่ก่อน AI หลายร้อยปี

ภาพที่ง่ายที่สุดคือ harness ของม้า

Harness ไม่ได้ทำให้ม้า:

• วิ่งเร็วขึ้น
• แข็งแรงขึ้น
• มองเห็นดีขึ้น
• ฉลาดขึ้น

ม้ามีพลังของมันอยู่แล้ว

สิ่งที่ harness ทำคือ ควบคุมและถ่ายทอดพลังนั้นไปในทิศทางที่ต้องการ

ม้าอาจมีความสามารถวิ่งไปทางซ้าย ขวา หน้า หลัง หรือวิ่งหนีออกจากถนนก็ได้

แต่เมื่ออยู่ใน harness พลังของมันถูกนำเข้าสู่ระบบที่มีทิศทาง มีข้อจำกัด และมี outcome ที่มนุษย์ต้องการ

นี่คือ metaphor ที่สำคัญมากสำหรับ AI agent

Model คือแหล่งความสามารถ

ส่วน Harness คือระบบควบคุมการใช้ความสามารถนั้น

2. Model, Tool และ Harness เป็นคนละเรื่องกัน

ลองแยกสามสิ่งนี้ออกจากกัน

Model = สิ่งที่ “ทำได้”

ตัว model มี capability เช่น

• reasoning
• coding
• planning
• summarization
• decision making
• understanding language

นี่คือศักยภาพของตัว model

Tool = สิ่งที่เปิดให้ “ลงมือทำ”

ถ้าเราให้ browser แก่ agent มันสามารถเข้าถึงเว็บได้

ถ้าเราให้ shell มันสามารถ execute commands ได้

ถ้าเราให้ GitHub access มันสามารถเปิด PR ได้

ถ้าเราให้ database connector มันสามารถ query database ได้

Tool จึงมักจะ เพิ่ม action surface ของ agent

จากเดิม agent “คิดได้” แต่ทำไม่ได้ ตอนนี้มันสามารถทำ action ในโลกภายนอกได้มากขึ้น

นั่นคือ capability expansion

ไม่ใช่ harness

Harness = สิ่งที่กำหนดว่า “มันได้รับอนุญาตให้เดินอย่างไร”

สมมติ agent สามารถ:

read code
edit code
run tests
commit
push
deploy

การให้เครื่องมือเหล่านี้ทั้งหมดแก่ agent ไม่ได้แปลว่าเรามี harness ที่ดี

Agent อาจทำ:

edit
→ deploy

โดยไม่ test

หรือ:

edit
→ test failed
→ ignore
→ merge

หรือ:

guess
→ modify production

Capability มีครบ

แต่ trajectory ไม่มีการควบคุม

Harness เริ่มเกิดขึ้นเมื่อระบบบอกว่า:

และที่สำคัญคือ agent ไม่สามารถข้าม transition ที่ระบบไม่อนุญาตได้

นั่นคือ harness

3. Harness ไม่ได้บอก Agent แค่ว่า “ควรทำอะไร”

นี่เป็น distinction ที่สำคัญมาก

Prompt อาจบอกว่า:

“Please run the tests before deploying.”

แต่ agent ยังสามารถไม่ทำตามได้

นี่เป็น instruction

ยังไม่ใช่ harness ที่แข็งแรง

Harness ที่แท้จริงพยายามเปลี่ยนจาก:

“คุณควรทำ X ก่อน Y”

เป็น:

“Y เกิดขึ้นไม่ได้จนกว่า X จะผ่าน”

เช่น:

test failed
→ deploy unavailable

แทนที่จะเป็น:

test failed
→ model is reminded not to deploy

นี่คือความแตกต่างระหว่าง instruction กับ control structure

Harness ที่ดีไม่ได้หวังเพียงว่า agent จะ “จำกฎได้”

มันออกแบบ environment ให้ เส้นทางผิดเดินยากหรือเดินไม่ได้

4. The Agent May Think Freely, but It Cannot Act Freely

นี่อาจเป็นประโยคที่สรุป harness ได้ดีที่สุด:

The agent may reason over many possible paths, but the harness controls which paths can become actions.

Model อาจเสนอ solution ได้ 100 แบบ

ไม่จำเป็นต้องไปจำกัด reasoning ของมันทั้งหมด

สิ่งที่ harness ควบคุมคือ transition จาก

reasoning → action → state change

ตัวอย่างเช่น agent สามารถคิดได้ว่า:

A. patch code
B. delete table
C. bypass test
D. migrate schema
E. ask human

แต่ harness อาจเปิดเส้นทางจริงเพียง:

A → test → review → merge
D → dry-run → validation → approval → migrate
E → human escalation

ส่วน B และ C ไม่มี transition ที่ executable

นี่คือ control

5. Mitchell Hashimoto และ “Harness Engineering”

วันที่ 5 กุมภาพันธ์ 2026 Mitchell Hashimoto เขียนบทความ My AI Adoption Journey และมีหัวข้อสำคัญชื่อ “Step 5: Engineer the Harness.”

Hashimoto ไม่ได้อ้างว่าเขาเป็นผู้คิดคำว่า harness และไม่ได้อ้างว่าเป็นผู้คิดแนวคิด agent harness ขึ้นมา

สิ่งที่เขาพูดอย่างระมัดระวังคือ เขายังไม่รู้ว่ามีคำมาตรฐานของวงการหรือไม่ แต่เขาเริ่มเรียกวิธีคิดนี้ว่า “harness engineering.”

แนวคิดของเขามีสาระสำคัญมาก:

เมื่อ agent ทำผิด อย่าจบแค่

“ครั้งหน้าจำไว้ว่าห้ามทำแบบนี้”

แต่ถามว่า:

เราสามารถเปลี่ยนระบบอย่างไร เพื่อไม่ให้ความผิดแบบเดิมเกิดซ้ำได้อีก?

ถ้า agent ใช้ command ผิดซ้ำ ๆ
→ encode knowledge เข้าไปใน environment

ถ้า agent ไม่รู้ว่าผลลัพธ์ผิด
→ สร้าง feedback ที่บอกมันได้อย่างรวดเร็ว

สองข้อนี้เป็นของ Hashimoto โดยตรง รูปธรรมที่เขายกไว้ใน Step 5 คือ implicit context ที่ดีขึ้น เช่นไฟล์ AGENTS.md กับ tool ที่เขียนขึ้นมาจริง ๆ เช่น script ถ่าย screenshot หรือคำสั่ง test ที่กรองผลลัพธ์มาให้แล้ว ประโยคที่ใกล้ที่สุดของเขาคือ ถ้าเราให้วิธีตรวจงานของตัวเองแก่ agent มันมักจะแก้ความผิดพลาดของตัวเองและกัน regression ได้ — นั่นคือ verification ในฐานะ feedback ไม่ใช่ในฐานะสิ่งที่ block

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

Hashimoto อธิบาย harness engineering ว่าเป็นการเอาความผิดพลาดของ agent แต่ละครั้งมาสร้างระบบเพื่อป้องกันความผิดพลาดแบบเดิมในอนาคต

นี่ไม่ใช่แค่ prompt engineering

ในภาษาของบทความนี้ มันคือ environment engineering + feedback engineering + control engineering — โดยคำสุดท้ายเป็นส่วนที่บทความนี้เติมเข้าไปเอง ไม่ใจ่คำของเขา

6. Tool สามารถเป็น “ส่วนหนึ่ง” ของ Harness ได้ แต่ Tool ไม่ได้เท่ากับ Harness

ตรงนี้เป็นจุดที่ทำให้คนสับสนที่สุด

สมมติเราเพิ่ม screenshot tool ให้ agent

ถ้าเหตุผลคือ:

“ตอนนี้ agent มอง UI ได้แล้ว”

เราเพิ่ม capability

แต่ถ้าเราใช้ screenshot tool ภายในวงจร:

implement UI
 ↓
capture screenshot
 ↓
visual evaluator
 ↓
does it satisfy acceptance criteria?
 ├─ No → revise
 └─ Yes → continue

ตอนนี้ screenshot/evaluator กำลังทำหน้าที่ ภายใน harness

ดังนั้นคำที่แม่นกว่าคือ:

A tool can participate in a harness.
But a tool is not a harness merely because the agent can use it.

ความแตกต่างอยู่ที่ บทบาทใน control loop

ไม่ใช่อยู่ที่ชื่อของ technology

7. OpenAI เองก็ชี้ไปในทิศทางของ Control มากกว่า “แค่มี Tools”

วันที่ 11 กุมภาพันธ์ 2026 OpenAI เผยแพร่บทความ Harness engineering: leveraging Codex in an agent-first world

ประเด็นที่น่าสนใจคือทีมบอกเองว่า ช่วงแรกงานคืบหน้าช้ากว่าที่คาดไว้ ไม่ใช่เพราะ Codex ทำไม่ได้ แต่เพราะ environment ยัง underspecified

งานของ engineer จึงเปลี่ยนจากเขียน implementation เอง ไปเป็นการสร้าง environment, feedback loops, constraints และโครงสร้างที่ทำให้ agent สามารถทำงานได้อย่าง reliable

หนึ่งในตัวอย่างที่สำคัญที่สุดคือ architecture ของ codebase

ต้องบอกก่อนว่า OpenAI ไม่ได้เลิกทำ documentation ตรงกันข้ามเลย พวกเขา inject AGENTS.md สั้น ๆ ราว 100 บรรทัดเข้าไปใน context และมองมันเป็น table of contents ของ codebase ไม่ใช่สารานุกรม ส่วนแหล่งความจริงที่ลึกกว่านั้นคือ design documentation ที่ถูก catalogue และ index ไว้ และมี agent คอยทำหน้าที่ดูแลเอกสารให้สดอยู่เสมอ

สิ่งที่ custom linters และ structural tests เข้าไปแทนที่ จึงไม่ใช่ documentation แต่คือ documentation ในฐานะ กลไกบังคับ ของ layer boundary

แทนที่จะปล่อยให้กฎเรื่อง layer อยู่ในรูปข้อความที่ agent ถูก “ขอ” ให้ทำตาม — ประโยคทำนองที่ผมสมมติขึ้นมาเองว่า

กรุณาอย่า import ข้าม layer

OpenAI เลือก enforce มันด้วยเครื่องจักรแทน คือใช้ custom linters และ structural tests เพื่อ enforce permitted dependency directions

กล่าวอีกอย่างคือ

ไม่ใช่:

Agent, please follow this architecture.

แต่เป็น:

These edges are permitted.
Everything else is mechanically rejected.

OpenAI อธิบายตรง ๆ ว่า architecture ถูกสร้างให้มี fixed layers, limited permissible edges และ constraints เหล่านี้ถูก enforce ด้วยระบบ

นี่คือ harness thinking อย่างแท้จริง

8. Workflow ก็ยังไม่เท่ากับ Harness

อีกคำที่มักปนกันคือ workflow

Workflow บอกว่า:

A → B → C → D

แต่ harness ถามต่อว่า:

ถ้า agent พยายามไปจาก A → D จะเกิดอะไรขึ้น?

ถ้าคำตอบคือ

“เราหวังว่ามันจะไม่ทำ”

เรามี workflow

แต่ยังไม่มี control มากพอ

ถ้าคำตอบคือ

“transition A → D ไม่มีอยู่ในระบบ”

นั่นใกล้ harness มากขึ้น

ดังนั้น:

Workflow describes the intended path.
Harness governs the allowable paths.

สองอย่างสามารถอยู่ด้วยกันได้ แต่ไม่ใช่สิ่งเดียวกัน

9. Guardrail ก็ไม่ใช่ Harness ทั้งหมด

Guardrail คือ constraint หนึ่งตัว

เช่น:

ห้าม deploy production โดยไม่มี approval

Harness คือระบบใหญ่กว่านั้น:

state
→ permitted actions
→ execution
→ observation
→ evaluation
→ state transition
→ recovery
→ escalation
→ outcome

Guardrail จึงอาจเป็น component ของ harness

เช่นเดียวกับ:

• evaluator
• state machine
• test
• permission boundary
• approval gate
• feedback loop
• rollback
• retry rule
• invariant
• escalation condition

แต่สิ่งใดสิ่งหนึ่งเพียงอย่างเดียวไม่จำเป็นต้องเป็น harness ทั้งหมด

10. ทำไมคนสมัยนี้ถึงเริ่มเข้าใจคำว่า Harness ผิด

ปัญหาเกิดขึ้นเมื่อ definition ถูกขยายจนกลายเป็น:

“ทุกสิ่งที่ไม่ใช่ model คือ harness”

definition แบบนี้มีประโยชน์เวลาพูด architecture แบบกว้าง ๆ แต่ถ้าเอามาใช้ใน engineering conversation ทุกครั้ง คำว่า harness จะเริ่มสูญเสียความหมาย

ถ้า:

• tool = harness
• memory = harness
• prompt = harness
• MCP = harness
• context = harness
• skill = harness
• orchestration = harness
• UI = harness

สุดท้ายคำว่า harness จะหมายถึงเพียง:

“everything around the model.”

ซึ่งไม่ช่วยตอบคำถามทางวิศวกรรมที่สำคัญกว่า:

อะไรเป็นตัวควบคุม agent?

อะไรทำให้มันข้าม step ไม่ได้?

อะไรเป็นตัวตัดสิน state transition?

อะไรทำให้ failure กลับเข้าสู่ correction loop?

อะไรทำให้ forbidden path เป็น impossible path?

อะไรทำให้ outcome ที่เราต้องการเป็น terminal state ที่ agent สามารถไปถึงได้อย่าง reliable?

นี่ต่างหากคือคำถามของ harness

11. Harness ที่ดีไม่ได้ลด Intelligence — มันลด Degrees of Freedom ที่ไม่จำเป็น

บางคนอาจคิดว่า ถ้าเราจำกัด agent มากเกินไป เราก็ทำลายความสามารถของมัน

แต่ harness ที่ดีไม่จำเป็นต้อง micromanage ทุก action

ตรงกันข้าม หลักที่ดีกว่าคือ:

Constrain invariants, not implementations.

กำหนดสิ่งที่ห้ามละเมิด

แต่ปล่อยให้ agent เลือกวิธีแก้ปัญหาเองภายในพื้นที่ที่ปลอดภัย

เช่น:

You may implement this feature however you want.

But:

- tests must pass
- architecture boundaries cannot be violated
- no schema migration without validation
- security checks must pass
- acceptance criteria must be demonstrated

ภายในกรอบนี้ agent ยังคงมี autonomy สูงมาก

Harness จึงไม่ได้มีไว้เพื่อทำให้ agent กลายเป็น deterministic script

มันมีไว้เพื่อให้:

Autonomy exists inside controlled boundaries.

12. วิธีคิด Harness ที่ผมใช้

ผมมอง agent system ผ่านสี่ชั้น ชั้นแรกคือ MODEL — มันเข้าใจและ reason เกี่ยวกับอะไรได้บ้าง ถัดมาคือ TOOLS — มันทำ action อะไรได้บ้าง ถัดมาคือ HARNESS — action ไหนได้รับอนุญาต ในสถานะไหน ภายใต้เงื่อนไขอะไร ต้องตรวจสอบด้วยอะไร และหลังจากนั้นเกิดอะไรต่อ และชั้นสุดท้ายคือ OUTCOME — สถานะที่สังเกตได้แบบไหนถึงจะนับว่าสำเร็จ

ส่วนตัว harness เองก็คิดในรูป state machine ได้ คือ current state เปิดชุดของ allowed actions ออกมา agent เลือก action หนึ่งไปทำ ระบบ observe result แล้ว evaluate ถ้า pass ก็เดินต่อไปยัง next state ถ้า fail ก็เข้าสู่ repair หรือ retry แล้ววนกลับมาที่ loop เดิม จนสุดท้ายจบลงที่ outcome

นี่ทำให้ definition ของ harness ชัดขึ้นทันที

13. ประโยคเดียวที่ควรจำ

ถ้าจะจำบทความทั้งหมดเพียงประโยคเดียว ให้จำว่า:

Tools determine what an agent can do.
A harness determines how the agent is allowed to get to the outcome.

หรือในภาษาไทย:

Tool เพิ่มสิ่งที่ Agent ทำได้
Harness ควบคุมว่า Agent จะใช้สิ่งที่ทำได้นั้น เดินไปถึง Outcome ผ่านทางไหนได้บ้าง

และ harness ที่ดีที่สุดไม่ได้พยายามบอก agent ทุกวินาทีว่าต้องทำอะไร

มันออกแบบโลกของ agent จน:

ทางที่ถูกคือทางที่เดินได้
ทางที่ผิดถูก block, redirected, corrected หรือ escalated
และ agent ไม่สามารถประกาศความสำเร็จได้จนกว่า outcome ที่ตรวจสอบได้จะเกิดขึ้นจริง

นี่คือเหตุผลที่คำว่า harness มีความหมาย

ไม่ใช่เพราะมันทำให้ AI มีพลังมากขึ้น

แต่เพราะมันทำให้เราสามารถ ควบคุมพลังที่ AI มีอยู่แล้ว ให้ไปถึงผลลัพธ์ที่ต้องการอย่าง reliable

นั่นคือ Harness Engineering.

References

1. Mitchell Hashimoto. My AI Adoption Journey — หัวข้อ “Step 5: Engineer the Harness” (5 กุมภาพันธ์ 2026)
2. OpenAI (Ryan Lopopolo). Harness engineering: leveraging Codex in an agent-first world (11 กุมภาพันธ์ 2026)