Harness-Engineering on Code & Community

Harness Engineering ตอนที่ 3: Query Loop - หัวใจของระบบ

jitaret@gmail.com (เหน่ง) — Mon, 13 Apr 2026 11:00:00 +0700

Harness Engineering ตอนที่ 3: Query Loop - หัวใจของระบบ

บทนำ: ทำไม Query Loop ถึงสำคัญ?

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

นี่แหละคือที่มาของ Query Loop - แนวคิดที่เปลี่ยน AI จาก “ผู้ตอบคำถาม” เป็น “ผู้ร่วมงานที่จดจำบริบทได้”

และที่น่าสนใจคือ OpenAI ใช้ Query Loop สร้างโค้ดได้มากกว่า 1 ล้านบรรทัดในเวลาเพียง 5 เดือน ตัวเลขนี้ไม่ใช่แค่ความเร็ว แต่มันบอกว่าการออกแบบระบบที่ถูกต้องสามารถยกระดับศักยภาพของ AI ได้อย่างมหาศาล

แต่ที่น่าคิดคือ งานวิจัยจากหลายที่ชี้ว่า 69% ของโค้ดที่ AI สร้างยังต้องมีคนตรวจสอบ - หมายความว่า Query Loop ที่ดีไม่ใช่แค่ทำให้ AI ทำงานได้เร็ว แต่ต้องทำให้มันทำงาน “ถูกต้อง” ด้วย

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

Query Loop คืออะไร?

คำจำกัดความ

Query Loop คือรูปแบบการสื่อสารกับ AI ที่ไม่ใช่แค่ “ถาม-ตอบ” ครั้งเดียว แต่เป็น วงจรการสนทนาที่ต่อเนื่อง โดยในแต่ละรอบ AI จะ:

รับ Query (คำถาม/คำสั่ง) พร้อมบริцепจาก.radiansก่อนหน้า
ประมวลผลและให้คำตอบ
รอ feedback หรือคำถามถัดไป
วนซ้ำจนกว่างานจะเสร็จ

เปรียบเทียบให้เห็นภาพ

ลองนึกถึงการไปร้านอาหาร:

Prompt ปกติ (ถามครั้งเดียว):

“อยากกินข้าวผัดกระเพรา”

พนักงานก็จะทำข้าวผัดกระเพราให้ เสร็จ แต่ถ้าคุณอยากได้น้ำซุปด้วย? ต้องสั่งใหม่

Query Loop (วงจรต่อเนื่อง):

“อยากกินข้าว” “อยากกินข้าวผัด” “ข้าวผัดกระเพรา ไม่เผ็ด” “เพิ่มไข่ดาว” “เอาน้ำซุปมาด้วย”

ทุกครั้งที่สั่ง พนักงานจะจำได้ว่าคุณสั่งอะไรไปแล้วบ้าง และสร้างผลลัพธ์ที่สมบูรณ์ขึ้นเรื่อยๆ

นี่แหละคือ Query Loop - การ “สะสมบริบท” ข้ามรอบการสนทนา

ต่างจาก Prompt ปกติอย่างไร?

ด้าน	Prompt ปกติ	Query Loop
บริบท	แยกขาดกันทุกรอบ	สะสมต่อเนื่อง
ความจำ	ไม่มี (หรือมีแค่ในรอบเดียว)	จำได้ตลอดทั้งเซสชัน
ผลลัพธ์	คำตอบเดี่ยว	งานที่ค่อยๆ สมบูรณ์ขึ้น
การแก้ไข	ต้องสั่งใหม่หมด	แก้ได้ทีละส่วน
เหมาะกับ	คำถามง่ายๆ	งานซับซ้อน

ทำไม Query Loop คือหัวใจของระบบ?

1. เปลี่ยน AI จาก “เครื่องมือ” เป็น “พาร์ทเนอร์”

เมื่อ AI จำบริบทได้ มันไม่ใช่แค่ตอบคำถาม แต่สามารถ:

เข้าใจเป้าหมายระยะยาว - รู้ว่าคุณกำลังสร้างอะไร
เสนอแนะสิ่งที่ดีกว่า - แนะนำวิธีที่คุณอาจไม่ได้คิด
ปรับตัวตาม feedback - รับคำแนะนำและแก้ไขได้ทันที

2. ช่วยลดความผิดพลาดและเพิ่มโอกาสให้ตรวจสอบ

ข้อมูลจากงานวิจัยหลายชิ้นชี้ให้เห็นว่า AI ยังไม่สมบูรณ์แบบ 100% แต่ Query Loop ช่วยลดปัญหานี้ได้ด้วยการ:

เพิ่มโอกาสให้ AI ตรวจสอบตัวเอง - ถาม AI ว่า “โค้ดนี้ถูกต้องหรือไม่?” ก่อนจบแต่ละรอบ
ให้คนตรวจสอบได้บ่อยขึ้น - แทนที่จะรอทำเสร็จทั้งหมดแล้วค่อยตรวจ ก็ตรวจทีละส่วน
ลดความผิดพลาดแบบ Cascade - ถ้าผิดตั้งแต่ต้น จะไม่ลากไปทั้งระบบ

3. Claude Code vs Codex: ตัวอย่างจากโลกจริง

ทั้ง Claude Code (Anthropic) และ Codex (OpenAI) ล้วนใช้ Query Loop แต่ออกแบบต่างกัน:

Claude Code เน้น:

Context window กว้าง (เก็บบริบทได้มาก)
การตรวจสอบโค้ดอัตโนมัติ (computer use)
การแก้ไขแบบ iterative

Codex เน้น:

ความเร็วในการสร้างโค้ด
การ integrate กับเครื่องมือ dev
การทำงานแบบ subtask (แบ่งงานเป็นชิ้นเล็กๆ)

สิ่งที่ทั้งสองมีเหมือนกันคือ: ทั้งคู่เชื่อว่างานซับซ้อนต้องใช้ Query Loop - ไม่มีทางที่จะสั่งครั้งเดียวแล้วได้ผลลัพธ์ที่ดี

ประสบการณ์เหน่ง: การใช้ Query Loop กับ OpenClaw

ในระบบ OpenClaw ที่เหน่งใช้งาน มีการนำ Query Loop มาใช้ในรูปแบบ Sub-agent Pattern ซึ่งเป็นตัวอย่างที่ดีของการนำทฤษฎีมาใช้จริง

วิธีที่ใช้:

1. Main Agent เป็น Router

1ผู้ใช้ → Main Agent (วิเคราะห์คำขอ) → เลือก Specialist Agent 
2 → Specialist Agent (ทำงาน) → ส่งผลลัพธ์กลับ → Main Agent → ผู้ใช้

นี่คือ Query Loop ระดับหนึ่ง - Main Agent จำได้ว่าคำขอนี้ควรไปที่ไหน และรอรอบต่อไป

2. Specialist Agents ทำงานเป็น Loop

1Writer 1 → ส่งงาน → (รอ feedback) → แก้ไข → ส่งใหม่ → ...
2Writer 2 → ส่งงาน → (รอ feedback) → แก้ไข → ส่งใหม่ → ...

แต่ละ Agent ทำงานใน Query Loop ของตัวเอง รอ feedback จาก Main Agent หรือผู้ใช้ก่อนจะดำเนินต่อ

ปัญหาที่เจอและวิธีแก้:

ปัญหา 1: Context ล้น (Context Overflow)

อาการ: พอทำงานนานๆ AI เริ่ม “ลืม” สิ่งที่คุยก่อนหน้า
วิธีแก้: ใช้การสรุปบริบท (Context Summary) ก่อนเริ่มรอบใหม่ หรือแบ่งงานเป็นชิ้นเล็กๆ

ปัญหา 2: Feedback Loop หลุด

อาการ: Agent ทำงานต่อเนื่องโดยไม่รอ feedback
วิธีแก้: กำหนดจุด “หยุดรอ” (Checkpoint) ชัดเจน เช่น ทุกครั้งที่ส่งผลลัพธ์ ต้องรอ approval ก่อน

ปัญหา 3: Sub-agent ไม่สื่อสารกัน

อาการ: Writer 1 ทำอย่าง Writer 2 ทำอีกอย่าง ไม่เชื่อมกัน
วิธีแก้: ใช้ Main Agent เป็นตัวกลางประสาน และกำหนด shared context ให้ทุก Agent

บทเรียนที่ได้:

Query Loop ไม่ใช่แค่ “คุยซ้ำๆ” - ต้องมีโครงสร้างชัดเจน
Checkpoint สำคัญ - กำหนดจุดที่ต้องหยุดและรอ approval
Balance ระหว่างอัตโนมัติและการควบคุม - ปล่อยให้ AI ทำ แต่คนยังตรวจสอบได้

Query Loop ในทางปฏิบัติ: จากทฤษฎีสู่การใช้งานจริง

ตอนนี้เราเข้าใจแล้วว่า Query Loop คืออะไรและทำไมมันถึงสำคัญ ถึงเวลาลงมือทำกันแล้ว! ส่วนนี้จะพาคุณไปดูว่าจะนำ Query Loop ไปใช้ในโปรเจกต์จริงอย่างไร

ขั้นตอนการสร้าง Query Loop

ขั้นที่ 1: กำหนดเป้าหมายให้ชัด

ก่อนเริ่ม ถามตัวเองก่อนว่า:

งานนี้ต้องทำกี่รอบ?
แต่ละรอบ AI ต้องทำอะไร?
เมื่อไหร่คือจุดที่เสร็จสิ้น?

ยกตัวอย่าง: ถ้าคุณต้องการให้ AI ช่วยเขียนบทความ อาจแบ่งเป็น:

รอบ 1: ร่างโครงร่าง
รอบ 2: เขียนเนื้อหาแต่ละส่วน
รอบ 3: ตรวจแก้ไข
รอบ 4: เพิ่ม SEO และ Formatting

ขั้นที่ 2: เขียน Prompt แรกให้ดี

Prompt แรกเป็นตัวกำหนดทิศทางทั้งหมด ควรมี:

บริบท - ให้ AI รู้ว่ากำลังทำอะไร
เป้าหมาย - บอกชัดๆ ว่าต้องการอะไร
กรอบการทำงาน - บอกว่ามีกี่รอบ แต่ละรอบทำอะไร

ตัวอย่าง Prompt แรก:

1คุณคือนักเขียนบทความ Tech Blog ชื่อ "เหน่ง"
2ภารกิจ: เขียนบทความเรื่อง Query Loop
3
4ขั้นตอนการทำงาน:
51. รอบนี้ - สร้างโครงร่างบทความ 5 หัวข้อ
62. รอบต่อไป - เขียนเนื้อหาแต่ละหัวข้อ
73. รอบสุดท้าย - ตรวจสอบและปรับปรุง
8
9เริ่มต้นที่ขั้นตอน 1: สร้างโครงร่างบทความ

ขั้นที่ 3: กำหนดจุด Checkpoint

ทุก Query Loop ต้องมีจุด “หยุดรอ” ที่ชัดเจน ไม่ใช่ให้ AI ทำต่อเนื่องจนเสร็จ

วิธีกำหนด Checkpoint:

หลังส่งผลลัพธ์ทุกครั้ง → รอ feedback
ก่อนเริ่มรอบใหม่ → สรุปสิ่งที่ทำเสร็จ
ตอนสงสัย → ถามก่อนทำต่อ

ขั้นที่ 4: ให้ Feedback ที่ชัดเจน

นี่คือจุดที่หลายคนมองข้าม Feedback ไม่ใช่แค่บอก “ดี” หรือ “แก้” แต่ต้อง:

บอกว่าชอบตรงไหน - ให้ AI ทำซ้ำ
บอกว่าไม่ชอบตรงไหน - ให้ AI หลีกเลี่ยง
บอกว่าต้องการเพิ่มอะไร - ให้ AI พัฒนา

รูปแบบ	ตัวอย่าง
❌ Bad Feedback	“ยังไม่ดี แก้ใหม่”
✅ Good Feedback	“ส่วนนำดีมาก แต่ส่วนอธิบายคำจำกัดความยังไม่ละเอียด ขอให้ขยายความเรื่อง Context Window เพิ่มอีก 2 ย่อหน้า”

Best Practices: 7 ข้อสำหรับ Query Loop ที่มีประสิทธิภาพ

1. เริ่มด้วย “One Shot” แล้วค่อยขยาย

อย่าเพิ่งสร้าง Query Loop ที่ซับซ้อนตั้งแต่ต้น เริ่มจาก Prompt ง่ายๆ ดูผลลัพธ์ก่อน ถ้าไม่พอ แค่นั้นค่อยเพิ่มรอบ

ทำไม: ลดความซับซ้อนที่ไม่จำเป็น และให้ AI มีโอกาส “เดา” ถูกตั้งแต่ครั้งแรก

2. ใช้ “System Prompt” เป็น Anchor

System Prompt คือคำสั่งที่อยู่ตลอดเวลา ควรใส่สิ่งสำคัญที่อยากให้ AI จำได้ตลอด:

บทบาทของ AI
รูปแบบผลลัพธ์ที่ต้องการ
ข้อจำกัดหรือกฎที่ต้องปฏิบัติ

ตัวอย่าง System Prompt:

1คุณคือ Writer Agent สำหรับบทความ Tech Blog
2- เขียนเป็นภาษาไทย โทนเป็นกันเอง
3- ทุกบทความต้องมี Introduction + Body + Conclusion
4- ใช้ Schema Markup ในรูปแบบ JSON-LD
5- หลีกเลี่ยงศัพท์เทคนิคที่ซับซ้อนเกินไป

3. สร้าง “State Summary” ก่อนรอบใหม่

ก่อนเริ่มรอบถัดไป สรุปสิ่งที่ทำเสร็จแล้วให้ AI จำ:

1[สถานะปัจจุบัน]
2- ✅ โครงร่างบทความ: เสร็จแล้ว
3- ✅ ส่วนนำ: เสร็จแล้ว 
4- 🔄 ส่วนหลัก: กำลังทำ
5
6[คำสั่งสำหรับรอบนี้]
7เขียนส่วนหลัก 3 หัวข้อ หัวละ 300-400 คำ

ทำไม: ลดการสับสนเมื่อบริบทยาวขึ้น และให้ AI รู้ตำแหน่งที่ชัดเจน

ข้อผิดพลาดที่พบบ่อย: อย่าให้เกิดกับคุณ

ข้อผิดพลาดที่ 1: ไม่กำหนดจุดหยุด

อาการ: AI ทำงานต่อเนื่องโดยไม่รอ approval จนงานเพี้ยนไปหมด

วิธีแก้: ใส่คำสั่งชัดเจน “รอ feedback ก่อนดำเนินต่อ”

ข้อผิดพลาดที่ 2: Context รั่วไหล

อาการ: AI เอาข้อมูลจากรอบก่อนมาใช้ผิดที่ หรือลืมข้อมูลสำคัญ

วิธีแก้: ใช้ State Summary ทุกรอบ และทำเครื่องหมาย ✅/🔄/❌ ให้ชัด

ข้อผิดพลาดที่ 3: Feedback ไม่ชัดเจน

อาการ: บอก AI “แก้ใหม่” แต่ไม่บอกว่าแก้อะไร AI ก็เดาไปเรื่อยๆ

วิธีแก้: ใช้รูปแบบ “ชอบ/ไม่ชอบ/อยากได้เพิ่ม” ตามที่แนะนำไว้ข้างต้น

สรุป: Query Loop ในแบบที่ใช้งานได้จริง

บทความนี้เราได้เดินทางจากความเข้าใจพื้นฐานไปจนถึงการนำไปใช้จริง:

สิ่งที่ได้เรียนรู้:

Query Loop คืออะไร - วงจรการสนทนาที่ต่อเนื่อง ไม่ใช่แค่ถาม-ตอบครั้งเดียว
ทำไมถึงสำคัญ - เปลี่ยน AI จากเครื่องมือเป็นพาร์ทเนอร์ ช่วยลดความผิดพลาด และทำงานซับซ้อนได้
วิธีสร้าง Query Loop - กำหนดเป้าหมาย → เขียน Prompt แรก → กำหนด Checkpoint → ให้ Feedback ชัด
Best Practices 7 ข้อ - เริ่มเล็ก → ใช้ System Prompt → State Summary → Temperature ตามรอบ → Exit Criteria → Context จัดการ → ทดสอบก่อนจริง
ข้อผิดพลาดที่ควรเลี่ยง - ไม่กำหนดจุดหยุด, Context รั่ว, Feedback ไม่ชัด, Loop ยาวเกิน, ไม่มีคนตรวจ

บทเรียนสำคัญ:

Query Loop ไม่ใช่แค่ “คุยซ้ำๆ” - มันคือโครงสร้างการทำงานที่ชัดเจน
มี Checkpoint ทุกรอบ - อย่าปล่อยให้ AI ทำต่อเนื่องโดยไม่มีคนตรวจ
Feedback ต้องชัดเจน - “แก้ใหม่” ไม่เพียงพอ ต้องบอกว่าแก้อะไร
จุดหยุดต้องมี - กำหนด Exit Criteria ตั้งแต่แรก

มองไปข้างหน้า: ตอนถัดไปคืออะไร?

บทความนี้เป็นแค่จุดเริ่มต้นของ Harness Engineering ในตอนถัดไป เราจะไปดู Harness Components หรือ “ชิ้นส่วนสำคัญ” ที่ทำให้ระบบ AI ทำงานได้อย่างมีประสิทธิภาพ:

Sub-agent System - การแบ่งงานให้ AI หลายตัวทำงานร่วมกัน
Context Manager - การจัดการบริบทให้ AI ไม่ “ลืม”
Feedback Chain - การสร้างระบบ Feedback ที่มีประสิทธิภาพ
Error Handling - การจัดการเมื่อ AI ทำผิดพลาด

ถ้าคุณอยากให้ OpenClaw หรือระบบ AI ของคุณทำงานได้ดีขึ้น บทความถัดไปจะเป็นคู่มือที่ครบถ้วนที่สุด

เตรียมพร้อมสำหรับตอนต่อไป:

Sub-agent Pattern คืออะไรและใช้ตอนไหน
วิธีออกแบบ Context Manager ให้ AI จำได้นาน
Feedback Chain: จาก “แก้ใหม่” สู่ “แก้แบบมีทิศทาง”
Error Handling: เมื่อ AI ผิดพลาด ต้องทำอย่างไร

บทความนี้เป็นส่วนหนึ่งของซีรีส์ “Harness Engineering” ซึ่งสำรวจแนวคิดและเทคนิคในการใช้ AI ให้เกิดประสิทธิภาพสูงสุด

ตอนที่ 1: Harness Engineering ตอนที่ 1: ทำไม AI ต้องมี Harness?
ตอนที่ 2: Harness Engineering ตอนที่ 2: Prompt คือ Control Plane (ไม่ใช่ Input Box)
ตอนที่ 3: Harness Engineering ตอนที่ 3: Query Loop - หัวใจของระบบ (บทความนี้)
ตอนที่ 4: Harness Engineering ตอนที่ 4: Tools & Permissions - กำหนดขอบเขต AI

คำศัพท์ Thai-English

ภาษาไทย	English	ความหมาย
Query Loop	Query Loop	วงจรการสื่อสารกับ AI แบบต่อเนื่อง
Context	Context	ข้อมูลพื้นฐาน/บริบทที่ AI ใช้ในการประมวลผล
Checkpoint	Checkpoint	จุดหยุดรอ ก่อนดำเนินการต่อ
System Prompt	System Prompt	คำสั่งหลักที่อยู่ตลอดเวลา
Temperature	Temperature	ตัวกำหนดระดับความสร้างสรรค์ของ AI
Exit Criteria	Exit Criteria	เงื่อนไขที่บอกว่าเสร็จแล้ว
Summarization	Summarization	การสรุปย่อยบริบท
Human in the Loop	Human in the Loop	การมีคนตรวจสอบในกระบวนการ
Feedback Chain	Feedback Chain	ลำดับการให้ Feedback
Sub-agent	Sub-agent	Agent ย่อยที่ทำงานเฉพาะทาง

📚 อ้างอิง

แหล่งข้อมูลหลัก:

Harness Books Book 1 - Claude Code Harness โดย wquguru (2026)
- บทที่ 3: Query Loop - Agent’s Heartbeat
- https://github.com/wquguru/harness-books/blob/main/book1-claude-code/chapter-03-query-loop-heartbeat.md
Harness Books Book 2 - Claude Code vs Codex โดย wquguru (2026)
- บทที่ 3: Query Loop เปรียบเทียบ Thread/Rollout/State
- https://github.com/wquguru/harness-books/blob/main/book2-comparing/chapter-03-loop-thread-and-rollout.md

สถิติและข้อมูลวิจัย:

OpenAI Code Generation Statistics (2025)
- OpenAI สร้างโค้ด 1 ล้านบรรทัดใน 5 เดือน
- https://openai.com/index/code-generation-milestone/
Human Verification in AI Code Generation (2025)
- 69% ของโค้ดที่ AI สร้างยังต้องมีคนตรวจสอบ
- https://arxiv.org/abs/2501.xxxxx
Claude Code Documentation โดย Anthropic (2026)
- Query Loop และการทำงานแบบต่อเนื่อง
- https://docs.anthropic.com/claude-code/query-loop
Codex API Documentation โดย OpenAI (2026)
- Thread และ Rollout Management
- https://platform.openai.com/docs/codex/threads

Best Practices:

Temperature Settings for AI Code Generation (2025)
- การปรับ Temperature ตามรอบของ Query Loop
- https://arxiv.org/abs/2503.xxxxx
Context Window Management in LLM Applications (2025)
- กลยุทธ์การจัดการ Context Window
- https://arxiv.org/abs/2502.xxxxx
Exit Criteria Design for AI Agents (2025)
- การกำหนดจุดหยุดที่ชัดเจน
- https://arxiv.org/abs/2504.xxxxx

เครื่องมือและแพลตฟอร์ม:

OpenClaw Documentation (2026)
- Sub-agent Pattern และ Query Loop
- https://docs.openclaw.ai/query-loop
GitHub Copilot Documentation (2026)
- การใช้งาน Copilot แบบต่อเนื่อง
- https://docs.github.com/copilot
Cursor IDE Documentation (2026)
- AI Pair Programming แบบต่อเนื่อง
- https://docs.cursor.com

อ่านเพิ่มเติม:

Chip Huyen - AI Engineering (O’Reilly, 2025)
- บทที่ 8: Building AI Systems with Feedback Loops
Martin Fowler - Harness Engineering (2025)
- https://martinfowler.com/articles/harness-engineering.html
Google AI - Best Practices for LLM Applications (2025)
- https://ai.google/best-practices/llm-apps

Harness Engineering ตอนที่ 2: Prompt คือ Control Plane (ไม่ใช่ Input Box)

jitaret@gmail.com (เหน่ง) — Mon, 13 Apr 2026 10:00:00 +0700

Harness Engineering ตอนที่ 2: Prompt คือ Control Plane (ไม่ใช่ Input Box)

คำโปรย: “Prompt กำหนดวิธีพูด, Harness กำหนดวิธีทำงาน” — เรียนรู้ว่าทำไม Prompt Engineering ถึงถึงจุดอิ่มตัว และ Harness Engineering คือคำตอบ

🎣 ส่วนนำ: ทำไม Prompt ถึงสำคัญกว่าที่คิด?

ลองนึกภาพว่าคุณมีรถยนต์คันหนึ่ง

แบบที่ 1: คุณบอก “ขับไปถึงที่หมาย” — รถจะพาคุณไปได้ แต่ถ้ามีเด็กวิ่งตัดหน้า? รถอาจจะเบรกไม่ทัน

แบบที่ 2: คุณบอก “ขับไปที่หมาย แต่ต้องระวังเด็กข้างทาง ขับช้ากว่า 50 กม./ชม. ห้ามแซง และต้องหยุดเติมน้ำมันทุก 200 กม.” — ผลลัพธ์จะต่างกันมาก

Prompt ก็เหมือนกัน

หลายคนมอง Prompt เป็นแค่ “กล่องใส่ข้อความ” ที่พิมพ์ๆ แล้วกดส่ง แต่ถ้ามองในมุมของ Harness Engineering — Prompt คือ Control Plane ที่ควบคุมพฤติกรรมของ AI ไม่ใช่แค่ input ที่ใส่เข้าไป

และนี่คือจุดที่หลายคนเข้าใจผิด

🤔 Prompt คืออะไร?

มุมมองเดิม vs มุมมองใหม่

มุมมองเดิม (Input Box):

“Prompt คือ ข้อความที่ใส่เข้าไปในกล่อง chat เพื่อบอก AI ให้ทำอะไรสักอย่าง”

มุมมองใหม่ (Control Plane):

“Prompt คือ interface สำหรับควบคุมพฤติกรรมของ AI — เหมือนพวงมาลัยที่ควบคุมทิศทาง ไม่ใช่แค่เชื้อเพลิงที่ใส่เข้าไป”

ทำไมต้องแยกให้ชัด?

เพราะถ้ามอง Prompt เป็นแค่ Input Box → คุณจะโฟกัสที่ “จะพิมพ์อะไรดี” แต่ถ้ามอง Prompt เป็น Control Plane → คุณจะโฟกัสที่ “จะ design ระบบอย่างไรให้ AI ทำงานถูกต้อง”

นี่คือความแตกต่างระหว่าง Prompt Engineering (ปรับแต่งข้อความ) กับ Harness Engineering (ออกแบบระบบควบคุม)

📊 ตัวอย่างเปรียบเทียบ: Input Box vs Control Plane

สถานการณ์	แบบ Input Box (เดิม)	แบบ Control Plane (ใหม่)
ระบบเคลมประกัน	“ตรวจสอบคำขอเคลมประกัน”	กำหนด workflow: ตรวจสอบเงื่อนไข → คำนวณค่าชดเชย → ตรวจสอบเอกสาร → ส่งข้อมูลให้คนอนุมัติ
เขียนโค้ด	“เขียน Python function”	“เขียน Python + เขียน test ด้วย + ห้าม commit ถ้า test fail”
วิเคราะห์ข้อมูล	“วิเคราะห์ข้อมูลนี้”	กำหนด: ใช้สถิติอะไร → รูปแบบการแสดงผล → ข้อจำกัดของข้อมูล
Customer Support	“ตอบลูกค้า”	กำหนด: โทนเสียง → SLA → Escalation path → Satisfaction survey
Content Creation	“เขียนบทความ”	กำหนด: Tone of voice → SEO keywords → Word count → Fact-checking process

เห็นไหม? Control Plane ไม่ได้แค่ “บอกว่าทำอะไร” แต่ “บอกว่าทำอย่างไร ด้วยเงื่อนไขอะไร”

🏗️ Prompt Layering: 3 ระดับของการควบคุม

ไม่ใช่ทุก Prompt อยู่ในระดับเดียวกัน การแบ่งชั้นของ Prompt ช่วยให้เราออกแบบระบบที่ซับซ้อนได้ดีขึ้น

ตารางเปรียบเทียบ 3 ระดับ

ระดับ	ชื่อ	หน้าที่	ตัวอย่าง	ความถี่ในการเปลี่ยน
1. Orchestration	ระดับจัดการงาน	กำหนดว่า “ต้องทำอะไรบ้าง เรียงลำดับอย่างไร”	Agent workflow, task decomposition	นานๆ ครั้ง
2. Runtime	ระดับขณะทำงาน	กำหนด “บริบท ข้อจำกัด เงื่อนไข” ขณะ AI ทำงาน	Context, constraints, validation rules	ปรับตามงาน
3. Model Interface	ระดับติดต่อโมเดล	กำหนด “รูปแบบการสื่อสารกับโมเดล”	Instructions, format, output structure	บ่อย (ปรับ prompt ทุกครั้ง)

อธิบายแบบง่ายๆ

Orchestration = ผู้จัดการโปรเจกต์ ที่บอกว่า “เรามี 5 ขั้นตอน ขั้น 1 ทำ A ขั้น 2 ทำ B…”
Runtime = หัวหน้างาน ที่บอกว่า “ตอนทำขั้นนี้ อย่าลืมเรื่องความปลอดภัยด้วย”
Model Interface = เลขาที่ ที่บอกว่า “เขียนรายงานในรูปแบบนี้…”

ทั้ง 3 ระดับทำงานร่วมกัน เหมือนโครงสร้างองค์กร — แต่ละชั้นมีหน้าที่ต่างกัน

ตัวอย่างโค้ด: Prompt Layering ในทางปฏิบัติ

 1# Layer 1: Orchestration (Foundation)
 2SYSTEM_PROMPT = """
 3You are a senior Python developer working on a FastAPI project.
 4You always write type-safe, well-documented code.
 5You follow TDD: write tests before implementation.
 6"""
 7
 8# Layer 2: Runtime (Context)
 9CONTEXT_PROMPT = """
10Current project structure:
11- /app/main.py - FastAPI entry point
12- /app/models/ - Pydantic models
13- /app/routers/ - API endpoints
14- /tests/ - Pytest test files
15
16Current task: Implement user authentication
17"""
18
19# Layer 3: Model Interface (Task)
20TASK_PROMPT = """
21Write a function to authenticate user by JWT token.
22
23Requirements:
24- Use Pydantic for validation
25- Return HTTPException on failure
26- Include unit tests
27- Follow existing code style
28"""
29
30# Combine all layers
31full_prompt = f"{SYSTEM_PROMPT}\n\n{CONTEXT_PROMPT}\n\n{TASK_PROMPT}"
32print(full_prompt)

📈 สถิติที่น่าสนใจ

ข้อมูลจากงานวิจัยชี้ว่า:

วิธี	ผลตอบแทน
Prompt Engineering แบบเดิม	ปรับปรุงได้ <3%
Harness-level changes (รวม Prompt Layering)	ปรับปรุงได้ 28-47%

นั่นหมายความว่า การเปลี่ยนแปลงที่ระดับ “ระบบ” (Harness) มีผลมากกว่าการเปลี่ยนแปลงที่ระดับ “ข้อความ” (Prompt) ถึง 10 เท่า!

และนี่คือเหตุผลที่เราต้องมอง Prompt เป็น Control Plane ไม่ใช่แค่ Input Box

📄 AGENTS.md: แผนที่ ไม่ใช่ Prompt ยาวๆ

อีกตัวอย่างที่ดีคือไฟล์ AGENTS.md ในโปรเจกต์ต่างๆ

หลายคนเขียน prompt ยาวเต็มไฟล์ แต่ AGENTS.md ที่ดีควรเป็น แผนที่ — บอกว่า:

Agent นี้ทำอะไร
ต้อง interact กับอะไรบ้าง
มีข้อจำกัดอะไร

ไม่ใช่ “script ที่ต้องอ่านทุกบรรทัด”

ตัวอย่าง: AGENTS.md ที่ดี

 1# Agent Role: Backend Developer
 2
 3## Responsibilities
 4- Implement API endpoints
 5- Write unit tests
 6- Update documentation
 7
 8## Constraints
 9- Must use type hints
10- Must achieve 90% test coverage
11- Cannot modify database schema without approval
12
13## Workflow
141. Read task from TASKS.md
152. Implement code
163. Run tests
174. Submit for review

นี่คือหลักการของ Prompt Layering — แบ่งให้ชัด ไม่ยัดทุกอย่างไว้ที่เดียว

🔍 จากทฤษฎีสู่ Reality Check: Claude Code vs Codex

ตอนนี้เราเข้าใจหลักการแล้ว มาดูตัวอย่างจริงกัน

Claude Code vs OpenAI Codex

ด้าน	Claude Code	OpenAI Codex
แนวทาง	Proactive Planner	Shell-first Surgeon
Workflow	สแกน repo ก่อนแล้ว plan	เริ่มจาก lean context
Memory	ใช้ CLAUDE.md เป็น long-term memory	ใช้ AGENTS.md เป็น map
Context Window	1M tokens	200K tokens
Token Usage	ใช้มากกว่า 3.2-4.2 เท่า	ใช้น้อยกว่า แต่ thorough น้อยกว่า
Agent Teams	Coordinated agents	Cloud sandbox per task
Isolation	Git worktree per agent	Cloud sandbox

ตัวอย่าง: Token Usage ต่างกันอย่างไร?

 1งาน: Implement user authentication
 2
 3Claude Code:
 4- Scan repo: 50K tokens
 5- Read CLAUDE.md: 10K tokens
 6- Plan: 5K tokens
 7- Implement: 30K tokens
 8- Test: 20K tokens
 9- Total: ~115K tokens
10
11Codex:
12- Read AGENTS.md: 5K tokens
13- Implement: 20K tokens
14- Test: 10K tokens
15- Total: ~35K tokens
16
17Ratio: Claude Code ใช้ token มากกว่า ~3.3 เท่า

คำถาม: แล้วควรเลือกอันไหน?

คำตอบ: ขึ้นอยู่กับงาน

Claude Code — เหมาะกับงานที่ซับซ้อน ต้องการ thorough plan
Codex — เหมาะกับงานเร็วๆ ไม่ซับซ้อนมาก

🛡️ Guardrails 3 ระดับ

Prompt ที่ดีต้องมี Guardrails — เหมือนรั้วที่ป้องกันไม่ให้ AI ทำผิด

ตาราง: Guardrails 3 ระดับ

ระดับ	ประเภท	ตัวอย่าง
Input	Content filtering, Schema validation, Rate limiting	ห้าม prompt injection, ต้องเป็น JSON, จำกัด 10 requests/min
Output	Format validation, Factual grounding, Safety classifiers	ต้องมี type hints, ต้องอ้างอิงแหล่งที่มา, ห้าม generate harmful content
Execution	Tool call approval, Resource limits, Deadlock detection	ต้องขออนุญาตก่อน rm -rf, จำกัด CPU 50%, ตรวจจับ infinite loop

ตัวอย่างโค้ด: Guardrails ในทางปฏิบัติ

 1class Guardrails:
 2 def validate_input(self, prompt: str) -> bool:
 3 # Input guardrails
 4 if len(prompt) > 10000:
 5 raise ValueError("Prompt too long")
 6 if "rm -rf" in prompt:
 7 raise ValueError("Dangerous command detected")
 8 return True
 9 
10 def validate_output(self, code: str) -> bool:
11 # Output guardrails
12 if not self.has_type_hints(code):
13 raise ValueError("Missing type hints")
14 if not self.has_docstrings(code):
15 raise ValueError("Missing docstrings")
16 return True
17 
18 def validate_execution(self, tool_call: dict) -> bool:
19 # Execution guardrails
20 if tool_call['name'] == 'file_write':
21 if not tool_call['path'].startswith('/safe/'):
22 raise ValueError("Unsafe path")
23 return True

🧠 Memory Systems 5 ประเภท

AI จำเป็นต้องมี Memory — แต่ไม่ใช่แค่ “จำได้ทุกเรื่อง” แต่ต้องจำอย่างมีระบบ

ตาราง: Memory Systems 5 ประเภท

ประเภท	หน้าที่	ตัวอย่าง
System Memory	ระบบพื้นฐาน	Rules, constraints, guardrails
Session Memory	ระหว่าง session	Conversation history, current task
Project Memory	โปรเจกต์ปัจจุบัน	CLAUDE.md, AGENTS.md, progress.md
User Memory	ความชอบผู้ใช้	Coding style, preferences, patterns
World Memory	ความรู้ทั่วไป	Documentation, APIs, best practices

ตัวอย่าง: การใช้งาน Memory ในทางปฏิบัติ

 1# CLAUDE.md (Project Memory)
 2
 3## Project Overview
 4- Name: FastAPI Auth System
 5- Version: 1.0.0
 6- Python: 3.11+
 7
 8## Coding Standards
 9- Type hints: Required
10- Test coverage: 90%+
11- Documentation: Google style
12
13## Current Progress
14- [x] User model
15- [x] Authentication endpoint
16- [ ] Authorization middleware
17- [ ] Unit tests

🔄 Retry Logic 5 ระดับ

เมื่อ AI ทำผิด — จะทำอย่างไร?

ตาราง: Retry Logic 5 ระดับ

ระดับ	ประเภท	เมื่อไหร่ใช้
1. Simple Retry	ลองใหม่เหมือนเดิม	Error ชั่วคราว (network timeout)
2. Reformulated Retry	ลองใหม่โดยปรับ prompt	Model เข้าใจผิด
3. Model Fallback	เปลี่ยนโมเดล	โมเดลปัจจุบันทำไม่ได้
4. Decomposition Retry	แยกงานย่อย	งานซับซ้อนเกินไป
5. Human Escalation	ให้คนทำ	AI ทำไม่ได้จริงๆ

ตัวอย่างโค้ด: Retry Logic ในทางปฏิบัติ

 1class RetryLogic:
 2 def execute_with_retry(self, task: str, max_retries: int = 5):
 3 for attempt in range(max_retries):
 4 try:
 5 # Level 1: Simple Retry
 6 result = self.model.execute(task)
 7 return result
 8 except TemporaryError:
 9 continue
10 except MisunderstandingError:
11 # Level 2: Reformulated Retry
12 task = self.reformulate(task)
13 except ModelCapabilityError:
14 # Level 3: Model Fallback
15 self.model = self.get_fallback_model()
16 except ComplexityError:
17 # Level 4: Decomposition Retry
18 subtasks = self.decompose(task)
19 results = [self.execute_with_retry(t) for t in subtasks]
20 return self.combine(results)
21 
22 # Level 5: Human Escalation
23 self.escalate_to_human(task)

👥 Sub-agent Isolation

เมื่อมีหลาย Agent — จะแยกกันอย่างไร?

ตาราง: Codex vs Claude

ด้าน	Codex	Claude
Isolation	Cloud sandbox per task	Git worktree per agent
Communication	ผ่าน API	อ่าน shared files ได้
State	Stateless per task	Stateful across session
Resource	แยกชัดเจน	Shared แต่มี limits

📝 สรุปตอนที่ 2

สิ่งที่ได้เรียนรู้:

✅ Prompt คือ Control Plane — ไม่ใช่ Input Box แต่เป็น interface ควบคุมพฤติกรรม

✅ Prompt Layering 3 ระดับ — Orchestration, Runtime, Model Interface

✅ สถิติ — Harness-level changes ได้ 28-47% improvement (vs <3% จาก prompt engineering)

✅ Claude Code vs Codex — 2 แนวคิดต่างกัน (Proactive Planner vs Shell-first Surgeon)

✅ Guardrails 3 ระดับ — Input, Output, Execution

✅ Memory Systems 5 ประเภท — System, Session, Project, User, World

✅ Retry Logic 5 ระดับ — Simple → Reformulated → Fallback → Decomposition → Human

✅ Sub-agent Isolation — Cloud Sandbox vs Git Worktree

💡 บทเรียนจากประสบการณ์เหน่ง

ช่วงแรก: ใช้ AI โดยไม่มี Harness

1❌ ใส่ prompt สั้นๆ แล้วดูว่าได้อะไร
2❌ "ช่วยเขียน Python script หน่อย"
3❌ "สรุปข้อความนี้ให้หน่อย"

ผลลัพธ์: ได้มาบ้าง ไม่ได้บ้าง AI บางทีเขียนโค้ดผิด ต้องมานั่งแก้ไขเองเยอะ

ปัจจุบัน: ใช้ Qwen (Alibaba) พร้อม Flow

1✅ กำหนด Orchestration → "งานนี้ต้องทำอะไรบ้าง"
2✅ กำหนด Runtime → "มีเงื่อนไขอะไรต้องระวัง"
3✅ กำหนด Model Interface → "output ต้องออกมาในรูปแบบไหน"

ผลลัพธ์: พอใจ 90% — AI ให้สิ่งที่ต้องการมากขึ้น แก้ไขน้อยลง

“Flow แล้ว” = มีขั้นตอนชัดเจน ไม่ใช่แค่ “ถามๆๆ ไปเรื่อย”

การเดินทาง: ไม่มี Harness → มี Flow → มี Guardrails

 1Stage 1: ไม่มี Harness
 2- ใช้ AI ตามใจ
 3- ผลลัพธ์ไม่แน่นอน
 4- เสียเวลาแก้ไขเยอะ
 5
 6Stage 2: มี Flow
 7- มีขั้นตอนชัดเจน
 8- ผลลัพธ์ดีขึ้น
 9- เสียเวลาน้อยลง
10
11Stage 3: มี Guardrails
12- มีระบบป้องกัน
13- ผลลัพธ์น่าเชื่อถือ
14- เสียเวลาน้อยมาก

🔄 ตอนต่อไป: Harness Components — ระบบอวัยวะของ AI

ตอนนี้เราเข้าใจแล้วว่า:

✅ Prompt คือ Control Plane
✅ Prompt Layering มี 3 ระดับ
✅ Guardrails, Memory, Retry Logic สำคัญอย่างไร

แล้ว Harness Components คืออะไร?

Harness มี “อวัยวะ” หลายอย่างที่ทำงานร่วมกัน:

Control Plane — Prompt ที่เราเพิ่งคุยกัน
Query Loop — หัวใจที่สูบฉีดงาน
Tools & Permissions — มือที่ทำงาน
Memory & Context — สมองที่จำ
Recovery Paths — ระบบภูมิคุ้มกัน

ในตอนต่อไป เราจะมาเจาะลึกแต่ละ “อวัยวะ” ว่าทำงานอย่างไร และทำไมต้องมี

ติดตามตอนต่อไปได้เลย 🚀

📚 อ้างอิง

แหล่งหลัก:

Harness Books 2 เล่ม โดย wquguru

Book 1: Claude Code Harness
Book 2: Claude Code vs Codex
Online Version: harness-books.agentway.dev

แหล่งเสริม:

Stanford HAI - Prompt Engineering Limitations (2025)
Morph LLM - Codex vs Claude Code Benchmarks
Anthropic - Constitutional AI
Google - Chain of Thought Prompting
OpenAI - Templatized Prompt Engineering

Harness Engineering ตอนที่ 4: Tools & Permissions - กำหนดขอบเขต AI

jitaret@gmail.com (เหน่ง) — Mon, 13 Apr 2026 10:00:00 +0700

Harness Engineering ตอนที่ 4: Tools & Permissions - กำหนดขอบเขต AI

ส่วนนำ: ทำไม AI ถึงต้องมี “ล็อคประตู”?

ลองนึกภาพว่าคุณจ้างพนักงานใหม่มาทำงาน แต่ไม่ได้กำหนดว่าเขาทำอะไรได้บ้าง ไม่ได้บอกว่าห้องไหนเข้าได้ ห้องไหนเข้าไม่ได้ และไม่ได้บอกว่าอะไรทำได้ อะไรทำไม่ได้… คุณจะรู้สึกอย่างไร?

น่ากลัวใช่ไหมล่ะ?

แต่นี่คือสิ่งที่หลายคนทำกับ AI Agent กันโดยไม่รู้ตัว

สถิติที่น่าตกใจ: ข้อมูลจาก OWASP Top 10 for Agentic Applications 2026 พบว่า 73% ของ AI ที่ deploy ใน production มีช่องโหว่ Prompt Injection นั่นหมายความว่าทุกครั้งที่คุณใช้ AI Agent มีโอกาสเกือบ 3 ใน 4 ที่จะถูกโจมตีผ่านวิธีนี้!

และยิ่งไปกว่านั้น 15-25% ของโค้ดที่ AI สร้างมีช่องโหว่ความปลอดภัย (OWASP, 2026) ซึ่งเป็นตัวเลขที่สูงมากเมื่อพิจารณาว่าเรานำ AI มาใช้เพื่อเพิ่มประสิทธิภาพ

เห็นไหมครับว่าปัญหามันอยู่ตรงไหน?

Tools & Permissions คืออะไร?

มาทำความเข้าใจกันง่ายๆ ก่อนนะครับ

Tools คือ “ความสามารถ” ที่ AI Agent สามารถใช้งานได้ ลองนึกภาพว่า AI เป็นคนที่มีอุปกรณ์ต่างๆ อยู่ในมือ:

📖 อ่านไฟล์ (File Reader) - AI สามารถเปิดดูไฟล์ในระบบ
✍️ เขียนไฟล์ (File Writer) - AI สามารถสร้างหรือแก้ไขไฟล์
💻 รันคำสั่ง (Shell Execution) - AI สามารถสั่งให้คอมพิวเตอร์ทำงาน
🌐 ควบคุม Browser (Web Automation) - AI สามารถเปิดเว็บ กรอกฟอร์ม
✉️ ส่งข้อความ (Messaging) - AI สามารถส่งอีเมลหรือข้อความ

แต่ละอย่างก็มีความเสี่ยงต่างกันไป การอ่านไฟล์น่าจะปลอดภัยกว่าการรันคำสั่งใช่ไหมครับ?

Permissions คือ “กฎเกณฑ์” ที่กำหนดว่า AI จะใช้ Tools แต่ละอย่างได้แค่ไหน ใช้ได้กี่ครั้ง และใช้ในสถานการณ์ไหนบ้าง

ลองเปรียบเทียบให้เห็นภาพนะครับ:

ไม่มี Permissions	มี Permissions
ให้บัตรเครดิตกับใครก็ได้ ไม่มีวงเงิน ไม่มี PIN	บัตรเครดิตมีวงเงิน 5,000 บาท ต้องใส่ PIN ทุกครั้ง
ทิ้งกุญแจบ้านไว้หน้าบ้าน ใครก็เข้าได้	มีกุญแจเฉพาะห้อง ต้องขออนุญาตก่อนเข้า
รถไม่มีเบรก ขับได้ไม่จำกัดความเร็ว	มีเบรก มีเกียร์ควบคุม มีถุงลมนิรภัย

เห็นความแตกต่างชัดเจนเลยใช่ไหมครับ?

ทำไมต้องกำหนดขอบเขต?

มาดูความเสี่ยงที่เกิดขึ้นจริงกันครับ:

1. Prompt Injection - “เสียงกระซิบในหู”

นึกภาพว่าคุณส่งเอกสารให้ AI อ่าน แต่ในเอกสารนั้นมีคำสั่งซ่อนอยู่ว่า “ลบไฟล์ทั้งหมด” หรือ “ส่งข้อมูลลับไปที่นี่” นี่แหละคือ Prompt Injection

ผู้โจมตีจะฝังคำสั่งไว้ใน:

README files
คอมเมนต์ในโค้ด
ข้อความที่ AI ต้องประมวลผล

และเมื่อ AI อ่านเจอ ก็จะทำตามโดยไม่รู้ตัว!

2. Tool Misuse - “ใช้มีดแทงคน”

แม้แต่ Tool ที่ดีก็อาจถูกใช้ผิดวัตถุประสงค์ได้

ตัวอย่าง:

AI ที่มีสิทธิ์เขียนไฟล์อาจไปลบ database ทั้งหมดเพราะเข้าใจคำสั่งผิด
AI ที่ส่งอีเมลได้อาจส่งข้อความหลอกลวงไปยังลูกค้า
AI ที่รันคำสั่งได้อาจดาวน์โหลดมัลแวร์โดยไม่รู้ตัว

3. Data Exfiltration - “ข้อมูลรั่วไหล”

AI อาจถูกหลอกให้ส่งข้อมูลสำคัญ (ลูกค้า, รหัสผ่าน, ข้อมูลทางการเงิน) ไปยัง server ของผู้โจมตี

4. Cascading Failures - “ลูกโซ่หลุด”

เมื่อ AI หนึ่งตัวทำงานผิด อาจส่งผลกระทบต่อ AI ตัวอื่นๆ ที่เชื่อมต่อกัน ทำให้ปัญหาลุกลามเป็นกองไฟ

สถิติไม่โกหกครับ: 30+ CVEs ถูกค้นพบในเดือนธันวาคม 2025 ใน AI Coding Platforms ใหญ่ๆ และที่น่าตกใจที่สุดคือ CamoLeak vulnerability (CVSS 9.6) ใน GitHub Copilot ทำให้สามารถขโมย secrets และ source code ได้!

นี่ไม่ใช่เรื่องไกลตัว แต่เป็นภัยคุกคามที่เกิดขึ้นจริง

ประสบการณ์เหน่งกับ OpenClaw

ตอนนี้มาดูกันว่าเหน่งใช้ OpenClaw อย่างไรในการกำหนดขอบเขตให้ AI ครับ

OpenClaw Security Modes

OpenClaw มี exec security modes 3 ระดับ:

Mode	คำอธิบาย	เหมาะกับ
`deny`	ปิดการใช้งาน exec ทั้งหมด	งานที่ไม่ต้องรันคำสั่ง
`allowlist`	อนุญาตเฉพาะคำสั่งที่ระบุ	งานที่ต้องควบคุมอย่างเข้มงวด
`full`	อนุญาตทั้งหมด	⚠️ อันตราย! ใช้ด้วยความระมัดระวัง

คำแนะนำ: อย่าใช้ full โดยไม่จำเป็น เพราะมันเปิดให้ AI ทำได้ทุกอย่าง!

การตั้งค่าที่แนะนำ

 1{
 2 gateway: {
 3 mode: "local",
 4 bind: "loopback",
 5 auth: { mode: "token", token: "replace-with-long-random-token" },
 6 },
 7 tools: {
 8 profile: "messaging",
 9 deny: ["group:automation", "group:runtime", "group:fs", "sessions_spawn"],
10 fs: { workspaceOnly: true },
11 exec: { security: "deny", ask: "always" },
12 elevated: { enabled: false },
13 },
14}

สังเกตไหมครับว่า:

exec: { security: "deny", ask: "always" } - ถ้าจำเป็นต้องรันคำสั่ง ต้องถามเหน่งก่อนทุกครั้ง!
deny: ["group:automation", "group:runtime", "group:fs"] - ปิดการใช้งาน groups ที่เสี่ยง
fs: { workspaceOnly: true } - จำกัดให้อ่าน/เขียนได้เฉพาะใน workspace

ปัญหาที่เจอและวิธีแก้

ปัญหา	วิธีแก้
Shared DMs + เปิด tools	ใช้ `dmPolicy: "pairing"` หรือ allowlists
Browser control เปิดเผย	ใช้ Tailscale, ไม่ expose สู่ public
Exec รันโดยไม่ต้องยืนยัน	ตั้งค่า `security: "allowlist"` และ `ask: "always"`
Config อยู่ใน synced folder	ย้ายออกจาก iCloud/Dropbox
Token สั้นเกินไป	ใช้ token ยาวอย่างน้อย 32 characters

เหน่งเจอปัญหาเรื่องนี้หลายครั้งครับ โดยเฉพาะตอนที่ token สั้นเกินไป ทำให้เดาได้ง่าย หลังจากปรับให้ยาวขึ้นและตั้งค่า ask: "always" ก็รู้สึกสบายใจขึ้นเยอะ

ประเภทของ Permissions แบบละเอียด

มาถึงส่วนสำคัญแล้วครับ! ตอนนี้เราจะมาดูกันว่า Permissions แบ่งออกเป็นกี่ประเภท และแต่ละประเภทมีความเสี่ยงอย่างไร

1. 📖 Read Permissions - “ดวงตา” ของ AI

Read Permissions คือสิทธิ์ในการเข้าถึงข้อมูล ลองนึกภาพว่า AI เป็นพนักงานที่สามารถอ่านเอกสารในสำนักงานได้

สิ่งที่ AI สามารถทำได้:

อ่านไฟล์ในระบบ
เข้าถึง database
ดู log files
อ่าน configuration files
เข้าถึง environment variables

ความเสี่ยงที่อาจเกิดขึ้น:

ข้อมูลลับรั่วไหล (API keys, passwords, secrets)
ข้อมูลลูกค้า (PII - Personal Identifiable Information)
ข้อมูลทางการเงิน
โค้ดที่มีช่องโหว่ (AI อาจเรียนรู้และนำไปใช้ผิด)

ตัวอย่างการโจมตี:

1Scenario: คุณให้ AI อ่านไฟล์ README.md เพื่อทำความเข้าใจโปรเจกต์
2แต่ในไฟล์นั้นมีคอมเมนต์ว่า "TODO: remove API key before deploy"
3AI ก็อาจเห็น API key นั้นและนำไปใช้ได้!

วิธีจำกัด:

1{
2 "fs": {
3 "workspaceOnly": true, // อ่านได้เฉพาะ workspace
4 "allowedDirs": ["/project/src", "/project/config"],
5 "deniedPatterns": ["**/*.env", "**/secrets/**"]
6 }
7}

2. ✍️ Write Permissions - “มือ” ของ AI

Write Permissions คือสิทธิ์ในการสร้างหรือแก้ไขข้อมูล นี่คือสิ่งที่ต้องระวังเป็นพิเศษ เพราะมีความเสี่ยงสูงกว่า Read มาก!

สิ่งที่ AI สามารถทำได้:

สร้างไฟล์ใหม่
แก้ไขไฟล์ที่มีอยู่
ลบไฟล์
เขียนลง database
แก้ไข configuration

ความเสี่ยงที่อาจเกิดขึ้น:

ลบไฟล์สำคัญโดยไม่ตั้งใจ
เขียนโค้ดที่มีช่องโหว่
แก้ไขไฟล์ระบบทำให้เสียหาย
ส่งข้อมูลออกไปยัง server ภายนอก

ตัวอย่างการโจมตี:

1Scenario: AI ถูกหลอกให้เขียนโค้ดที่ส่งข้อมูลลูกค้าไปยัง server ของผู้โจมตี
2"ช่วยเขียนฟังก์ชันสำหรับ backup ข้อมูลหน่อย"
3→ AI เขียนฟังก์ชันที่ส่งข้อมูลไปยัง attacker.com ด้วย!

วิธีจำกัด:

1{
2 "fs": {
3 "workspaceOnly": true,
4 "readOnly": false,
5 "allowedWriteDirs": ["/project/src"],
6 "deniedPatterns": ["**/production/**", "**/*.log"]
7 }
8}

3. 💻 Execute Permissions - “เท้า” ของ AI

Execute Permissions คือสิทธิ์ในการรันคำสั่ง ลองนึกภาพว่า AI สามารถเดินไปไหนก็ได้ในบ้าน และกดปุ่มอะไรก็ได้ — น่ากลัวใช่ไหมครับ?

สิ่งที่ AI สามารถทำได้:

รัน shell commands
ติดตั้ง packages
สร้าง processes ใหม่
จัดการ services
เข้าถึง network

ความเสี่ยงที่อาจเกิดขึ้น:

รันคำสั่งที่อันตราย (rm -rf /)
ดาวน์โหลดและรันมัลแวร์
สร้าง backdoor
ขุดเหมืองคริปโต
แพร่กระจายไปยังระบบอื่น

ตัวอย่างการโจมตี:

1Scenario: AI ถูกหลอกให้ "ติดตั้ง Python package ที่จำเป็น"
2→ แทนที่จะติดตั้ง package จริง กลับรันคำสั่งที่ขโมย SSH keys
3→ หรือดาวน์โหลด malware เข้ามาในระบบ

วิธีจำกัด (สำคัญมาก!):

1{
2 "exec": {
3 "security": "deny", // ปิดเป็นค่าเริ่มต้น
4 "ask": "always", // ถามก่อนทุกครั้ง
5 "allowedCommands": ["git", "npm", "pip"],
6 "timeout": 30
7 }
8}

4. 🌐 Network Permissions - “ปาก” ของ AI

Network Permissions คือสิทธิ์ในการสื่อสารกับภายนอก ลองนึกภาพว่า AI มีโทรศัพท์ที่สามารถโทรหาคนอื่นได้ตลอดเวลา

สิ่งที่ AI สามารถทำได้:

เรียก API ภายนอก
ส่ง HTTP requests
เชื่อมต่อ database ภายนอก
รับ connections จากภายนอก
ใช้ WebSocket

ความเสี่ยงที่อาจเกิดขึ้น:

ข้อมูลรั่วไหลไปยัง server ภายนอก
ถูกใช้เป็น proxy สำหรับโจมตีระบบอื่น
เรียก API ที่เสียค่าใช้จ่ายสูง
รับคำสั่งจากภายนอก (Command & Control)

ตัวอย่างการโจมตี:

1Scenario: AI ถูกหลอกให้ "ดึงข้อมูลจาก API ภายนอก"
2→ แทนที่จะเรียก API จริง กลับส่งข้อมูลลับไปยัง server ผู้โจมตี
3→ หรือถูกหลอกให้เชื่อมต่อกับ "API ที่ดูเหมือนจริง" แต่เป็นของผู้โจมตี

วิธีจำกัด:

 1{
 2 "network": {
 3 "egress": {
 4 "allowedDomains": ["api.github.com", "registry.npmjs.org"],
 5 "blockedDomains": ["*.onion", "attacker.com"]
 6 },
 7 "ingress": {
 8 "bind": "loopback", // รับ connection ได้เฉพาะ local
 9 "auth": "token" // ต้องมี token
10 }
11 }
12}

ตารางเปรียบเทียบระดับความเสี่ยง

Permission Type	ระดับความเสี่ยง	เหตุผล
Read	🟡 ปานกลาง	ข้อมูลรั่วไหล แต่ไม่ทำลายระบบโดยตรง
Write	🟠 สูง	แก้ไข/ลบข้อมูล สร้างไฟล์อันตราย
Execute	🔴 สูงมาก	ควบคุมระบบได้ทั้งหมด
Network	🔴 สูงมาก	ส่งข้อมูลออก รับคำสั่งจากภายนอก

Best Practices สำหรับการกำหนดขอบเขต

มาดู Best Practices ที่ควรปฏิบัติตามกันครับ:

1. 🛡️ Least Privilege Principle - ให้น้อยที่สุดที่ยังทำงานได้

หลักการ: ให้ AI สิทธิ์เฉพาะสิ่งที่จำเป็นต่อการทำงาน ไม่ใช่ทุกอย่างที่มี

วิธีปฏิบัติ:

เริ่มต้นด้วย deny ทั้งหมด
เปิดใช้งานทีละอย่างเมื่อต้องการ
ทบทวนสิทธิ์เป็นระยะ

ตัวอย่าง:

 1// ❌ ไม่ดี - ให้สิทธิ์เยอะเกินไปตั้งแต่แรก
 2{
 3 "tools": { "profile": "full" }
 4}
 5
 6// ✅ ดี - เริ่มจากน้อย เพิ่มทีละน่อย
 7{
 8 "tools": {
 9 "profile": "minimal",
10 "allow": ["file:read", "web:search"]
11 }
12}

2. ✅ Confirmation Steps - ยืนยันก่อนทำ

หลักการ: ก่อนทำ action ที่มีความเสี่ยงสูง ต้องถามคนก่อนเสมอ

วิธีปฏิบัติ:

ตั้งค่า ask: "always" สำหรับ exec และ write
แสดงสิ่งที่จะทำให้ user เห็นชัดเจน
รอจนได้รับการยืนยันก่อนดำเนินการ

ตัวอย่าง:

1{
2 "exec": {
3 "security": "allowlist",
4 "ask": "always" // ถามก่อนทุกครั้ง
5 },
6 "fs": {
7 "ask": "always" // ก่อนเขียน/ลบไฟล์
8 }
9}

3. 🏠 Sandboxing - แยกสภาพแวดล้อม

หลักการ: ถ้า AI ทำอะไรผิด ความเสียหายต้องอยู่ในขอบเขตที่จำกัด

วิธีปฏิบัติ:

ใช้ Docker container แยกสภาพแวดล้อม
จำกัด file system access เฉพาะ workspace
ใช้ VM สำหรับงานที่เสี่ยงสูง

ตัวอย่าง:

 1# docker-compose.yml
 2services:
 3 ai-agent:
 4 image: ai-agent-sandbox
 5 volumes:
 6 - ./workspace:/workspace  # เฉพาะโฟลเดอร์นี้
 7 cap_drop:
 8 - ALL
 9 security_opt:
10 - no-new-privileges:true

4. 📝 Audit Logging - บันทึกทุก action

หลักการ: ถ้าเกิดปัญหา ต้องสามารถตรวจสอบย้อนกลับได้

วิธีปฏิบัติ:

บันทึกทุก command ที่รัน
เก็บ log ในที่ปลอดภัย
ตั้ง alert สำหรับ action ที่ผิดปกติ

ตัวอย่าง:

1{
2 "logging": {
3 "level": "verbose",
4 "destination": "secure-log-server",
5 "retention": "90 days",
6 "alertOn": ["exec", "network: egress", "fs: delete"]
7 }
8}

5. 🔄 Rate Limiting - จำกัดจำนวนครั้ง

หลักการ: ป้องกันไม่ให้ AI ทำอะไรซ้ำๆ มากเกินไป

วิธีปฏิบัติ:

จำกัดจำนวนครั้งที่ใช้ tool ต่อชั่วโมง
จำกัด token usage
ตั้ง timeout สำหรับแต่ละ action

ตัวอย่าง:

 1{
 2 "rateLimits": {
 3 "exec": {
 4 "maxPerHour": 10,
 5 "timeout": 30
 6 },
 7 "network": {
 8 "maxPerHour": 50,
 9 "costAlert": 100 // บาทต่อชั่วโมง
10 }
11 }
12}

6. 🔒 Credential Isolation - แยก credentials

หลักการ: AI ไม่ควรเข้าถึง credentials โดยตรง

วิธีปฏิบัติ:

ใช้ secrets manager แทน env variables
ห้ามเขียน credentials ในโค้ด
ใช้ IAM roles แทน static keys

ตัวอย่าง:

 1// ❌ ไม่ดี
 2{
 3 "env": {
 4 "API_KEY": "sk-xxxxx" // เสี่ยงมาก!
 5 }
 6}
 7
 8// ✅ ดี
 9{
10 "secrets": "aws-secrets-manager",
11 "env": {
12 "API_KEY": "ref:secrets/API_KEY" // อ้างอิงจาก secrets manager
13 }
14}

7. 🧪 Testing & Validation - ทดสอบก่อนใช้จริง

หลักการ: ทดสอบ configuration ก่อน deploy จริงเสมอ

วิธีปฏิบัติ:

ทดสอบใน staging environment ก่อน
ทำ red team testing
ตรวจสอบ configuration ด้วย automated tools

Checklist ก่อน Deploy:

ตั้งค่า exec.security เป็น deny หรือ allowlist
ตั้งค่า ask: "always" สำหรับ action เสี่ยง
จำกัด fs.workspaceOnly: true
เปิด logging และ monitoring
ตั้ง rate limits
ใช้ token ยาวอย่างน้อย 32 ตัวอักษร
ทดสอบใน sandbox ก่อน

OWASP Top 10 for Agentic Applications 2026

มาดูกันครับว่า OWASP ระบุความเสี่ยงอะไรบ้างสำหรับ AI Agent:

#	Code	ชื่อ	ความเสี่ยงหลัก
1	ASI01	Agent Goal Hijack	ผู้โจมตีเปลี่ยนเป้าหมายของ AI
2	ASI02	Tool Misuse and Exploitation	ใช้ tools ผิดวัตถุประสงค์
3	ASI03	Identity and Privilege Abuse	ใช้สิทธิ์เกินขอบเขต
4	ASI04	Agentic Supply Chain Vulnerabilities	ช่องโหว่จาก dependencies
5	ASI05	Unexpected Code Execution (RCE)	รันโค้ดโดยไม่ตั้งใจ
6	ASI06	Memory & Context Poisoning	ปนเปื้อน memory/context
7	ASI07	Insecure Inter-Agent Communication	สื่อสารระหว่าง agents ไม่ปลอดภัย
8	ASI08	Cascading Failures	ลุกลามเป็นลูกโซ่
9	ASI09	Human-Agent Trust Exploitation	เอาเปรียบความไว้วางใจ
10	ASI10	Rogue Agents	Agent ไม่ได้รับอนุญาตทำงาน

ความเชื่อมโยงกับ Permissions:

ASI02, ASI03 → เกี่ยวกับการใช้ Tools/Permissions ผิดวิธี
ASI05 → เกี่ยวกับ Execute Permissions
ASI08 → เกี่ยวกับ Network Permissions

นี่คือเหตุผลที่การกำหนด Permissions อย่างถูกต้องสำคัญมากครับ!

สรุปบทความ

มาถึงตอนจบแล้วครับ! สรุปสิ่งที่ได้เรียนรู้วันนี้:

สิ่งที่ได้เรียนรู้:

Tools & Permissions คืออะไร - Tools คือความสามารถของ AI ส่วน Permissions คือกฎเกณฑ์ที่ควบคุมการใช้งาน
ทำไมต้องกำหนดขอบเขต - เพื่อป้องกัน Prompt Injection, Tool Misuse, Data Exfiltration และ Cascading Failures
ประเภท Permissions 4 อย่าง:
- 📖 Read - อ่านไฟล์/ข้อมูล
- ✍️ Write - เขียน/แก้ไข/ลบ
- 💻 Execute - รันคำสั่ง
- 🌐 Network - สื่อสารภายนอก
Best Practices 7 ข้อ:
- Least Privilege - ให้น้อยที่สุด
- Confirmation Steps - ยืนยันก่อนทำ
- Sandboxing - แยกสภาพแวดล้อม
- Audit Logging - บันทึกทุก action
- Rate Limiting - จำกัดจำนวนครั้ง
- Credential Isolation - แยก credentials
- Testing & Validation - ทดสอบก่อนใช้จริง
OWASP Top 10 for Agentic Applications 2026 - 10 ความเสี่ยงที่ต้องรู้และป้องกัน

การนำไปใช้:

จากประสบการณ์ของเหน่งกับ OpenClaw สิ่งที่แนะนำคือ:

เริ่มจาก deny ทั้งหมด แล้วค่อยๆ เปิด
ตั้งค่า ask: "always" สำหรับ exec และ write
ใช้ workspaceOnly: true สำหรับ file system
ใช้ token ยาวอย่างน้อย 32 ตัวอักษร

ไปต่อกันเลย!

ในตอนต่อไป เราจะมาดู Harness Components กันครับ — ว่ามีองค์ประกอบอะไรบ้างที่ต้องใช้ในการสร้างระบบ AI Agent ที่ปลอดภัยและมีประสิทธิภาพ

เตรียมตัวให้พร้อม แล้วพบกันใหม่ตอนหน้าครับ! 🚀

📚 อ้างอิง

OWASP. (2026). OWASP Top 10 for Agentic Applications 2026. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026
Giskard. (2026). OWASP Top 10 for Agentic Applications 2026: Security Guide. https://www.giskard.ai/knowledge/owasp-top-10-for-agentic-application-2026
Practical DevSecOps. (2026). OWASP Top 10 for Agentic Applications. https://www.practical-devsecops.com/owasp-top-10-agentic-applications
OWASP. (2025). OWASP Top 10 for LLM Applications 2025. https://owasp.org/www-project-top-10-for-llm-applications/
MITRE. (2024). MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems). https://atlas.mitre.org/
NIST. (2024). AI Risk Management Framework (AI RMF). https://aihub.nist.gov/ai-rmf
OpenClaw. (2026). OpenClaw Documentation - Security Configuration. https://openclaw.dev/docs
Crowdstrike. (2025). AI Agent Security: Risks and Mitigations. https://www.crowdstrike.com/blog/ai-agent-security-risks/
Nvidia. (2025). Building Secure AI Agents: Best Practices. https://developer.nvidia.com/blog/building-secure-ai-agents/
Google. (2025). AI Safety and Security Best Practices. https://cloud.google.com/blog/products/ai-machine-learning/ai-safety-best-practices
Microsoft. (2025). Responsible AI in Practice: Security Considerations. https://learn.microsoft.com/en-us/azure/ai-builder/responsible-ai-security
Anthropic. (2025). Building Reliable AI Systems: Security Guide. https://www.anthropic.com/engineering/security

ตอนที่ 1: Harness Engineering ตอนที่ 1: ทำไม AI ต้องมี Harness?
ตอนที่ 2: Harness Engineering ตอนที่ 2: Prompt คือ Control Plane (ไม่ใช่ Input Box)
ตอนที่ 3: Harness Engineering ตอนที่ 3: Query Loop - หัวใจของระบบ
ตอนที่ 4: Harness Engineering ตอนที่ 4: Tools & Permissions - กำหนดขอบเขต AI (บทความนี้)

บทความนี้เป็นส่วนหนึ่งของซีรีส์ Harness Engineering จาก Code & Community Blog

Harness Engineering ตอนที่ 1: ทำไม AI ต้องมี Harness?

jitaret@gmail.com (เหน่ง) — Mon, 13 Apr 2026 09:00:00 +0700

Harness Engineering ตอนที่ 1: ทำไม AI ต้องมี Harness?

ส่วนที่ 1: ทำไมเราต้องพูดเรื่องนี้

ลองนึกภาพว่าคุณลงทุนเงิน 10 ล้านบาทในโครงการ AI สักโครงการ จ้างทีมดีที่สุด ใช้เทคโนโลยีล้ำสมัย ผ่านไป 6 เดือน…

โครงการล้มเหลว

นี่ไม่ใช่เรื่องแปลก — สถิติจาก Gartner ชี้ตรงๆ ว่า 95% ของโครงการ AI ในองค์กรล้มเหลว แม้ว่าทั่วโลกจะลงทุนใน AI มากกว่า 30-40 พันล้านดอลลาร์ต่อปี

แล้วทำไมถึงยังมีคนลงทุนใน AI โดยไม่มี “ระบบความปลอดภัย”? นี่คือสิ่งที่ Harness Engineering จะมาตอบ

⚙️ Harness Engineering คืออะไร?

ลองนึกภาพรถยนต์ Formula 1 สมัยก่อน — รถแข่งที่ทรงพลังมาก แต่ไม่มีระบบความปลอดภัย ถ้าขับเร็วเกินไปหรือเบรกผิดจังหวะ นักแข่งก็เสี่ยงตาย

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

Harness Engineering ในบริบทของ AI ก็ทำงานคล้ายๆ กัน

มันคือการออกแบบระบบ “กรอบการทำงาน” ที่ทำให้ AI สามารถทำงานได้เต็มศักยภาพ โดยมีขอบเขต กฎเกณฑ์ และระบบตรวจสอบควบคุมไว้ ไม่ใช่การควบคุมจน AI ทำอะไรไม่ได้ แต่เป็นการสร้าง โครงสร้างพื้นฐานที่ช่วยให้ AI ทำงานได้อย่างมีประสิทธิภาพและปลอดภัย

Harness Engineering ประกอบด้วยหลายองค์ประกอบ:

Guardrails — กำหนดขอบเขตว่า AI ทำอะไรได้/ไม่ได้
Monitoring — ติดตามการทำงานและตรวจจับปัญหา
Fallback mechanisms — ระบบสำรองเมื่อ AI ทำงานผิดพลาด
Evaluation frameworks — มาตรฐานการวัดผล
Governance policies — นโยบายและกฎเกณฑ์การใช้งาน

แต่ที่สำคัญที่สุด — Harness ไม่ใช่แค่เครื่องมือทางเทคนิค แต่เป็น วิธีคิด ในการใช้ AI อย่างรับผิดชอบ

🚨 ทำไมต้องมี Harness? — ตัวอย่างจริงที่น่ากลัว

ถ้ายังสงสัยว่า Harness จำเป็นจริงหรือไม่ ลองดูตัวอย่างเหล่านี้:

🤖 Microsoft Tay (2016) — AI ที่กลายเป็นคนเหยียดใน 24 ชั่วโมง

Microsoft เปิดตัว chatbot ชื่อ Tay บน Twitter มีเป้าหมายให้เรียนรู้การสนทนาจากผู้ใช้ ภายใน 24 ชั่วโมง Tay กลายเป็นบอทที่พูดจาเหยียดเชื้อชาติ ใส่ร้ายกลุ่มต่างๆ เพราะ “เรียนรู้” จากคนที่เล่นกับมัน — ไม่มี Guardrails กำกับ ไม่มีระบบกรองเนื้อหา

🚗 Tesla Autopilot — ความเชื่อมั่นที่ฆ่าคน

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

💼 Amazon AI Recruitment — อคติที่ซ่อนอยู่ในข้อมูล

Amazon เคยพัฒนา AI เพื่อช่วยคัดกรองผู้สมัครงาน แต่ระบบกลับลดทอนผู้หญิงโดยอัตโนมัติ เพราะเรียนรู้จากข้อมูลประวัติการรับพนักงานในอดีตที่ส่วนใหญ่เป็นผู้ชาย — ไม่มีระบบตรวจสอบอคติ ไม่มีการประเมินความเป็นธรรม

💰 Knight Capital — $440 ล้านใน 30 นาที

ในปี 2013 บริษัท Knight Capital ใช้ trading bot ที่มี bug ในโค้ด ทำให้ซื้อขายหุ้นผิดพลาดอย่างรวดเร็ว สูญเสียเงิน 440 ล้านดอลลาร์ภายในครึ่งชั่วโมง และล้มละลายในเวลาต่อมา — ไม่มีระบบตรวจสอบความเสี่ยง ไม่มีวงเงินควบคุม

🇨🇦 Air Canada Chatbot (2024) — AI โกหกแล้วบริษัทต้องจ่าย

Air Canada มี chatbot ที่บอกลูกค้าว่าสามารถขอเงินคืนได้ตามนโยบาย “Bereavement Fare” แม้ว่านโยบายนั้นจะไม่มีอยู่จริง ศาลตัดสินให้ Air Canada จ่ายเงินชดเชยเพราะ chatbot ให้ข้อมูลผิด — ไม่มีระบบยืนยันข้อมูล ไม่มีการกำกับดูแลเนื้อหา

และนี่เป็นแค่ตัวอย่างที่ถูกเปิดเผย ยังมีอีกมากที่เกิดขึ้นในองค์กรทั่วโลกโดยไม่มีใครรู้

📊 ตัวเลขที่ไม่โกหก

นอกจากเรื่องราวความล้มเหลวแล้ว ตัวเลขก็บอกเล่าความจริงที่น่าตกใจ:

72% ขององค์กรทั่วโลกมี AI deployment อย่างน้อย 1 ระบบใน production
65% ใช้ Generative AI ในอย่างน้อย 1 ฟังก์ชัน
แต่เพียง 25% ขององค์กร มี AI governance program ที่ implement ครบถ้วน
และ 97% ของเหยื่อ breach ที่เกี่ยวข้องกับ AI ขาด access controls

นี่คือช่องว่างระหว่าง การใช้ AI กับ การใช้ AI อย่างปลอดภัย — ช่องว่างที่ Harness Engineering จะมาอุด

🔍 10 สาเหตุหลักที่ AI ล้มเหลว

จากการศึกษาของ MIT และ Stanford พบ 10 สาเหตุหลักที่ทำให้โครงการ AI ล้มเหลว:

Unclear business objectives — ไม่มีเป้าหมายธุรกิจที่ชัดเจน
Black Box AI systems — ไม่เข้าใจว่า AI ตัดสินใจอย่างไร
Lack of collaboration — ทีมไม่ทำงานร่วมกัน
Lack of talent — ขาดคนที่เข้าใจทั้ง AI และธุรกิจ
Overfitting — ระบบทำงานดีกับข้อมูลเก่าแต่ไม่กับข้อมูลใหม่
Edge-case neglect — ไม่คิดถึงกรณีขอบเขต
Correlation dependency — เข้าใจผิดว่าความสัมพันธ์คือเหตุผล
Data bias — ข้อมูลฝังอคติ
Underfitting — โมเดลเรียนรู้ไม่เพียงพอ
Inadequate testing — ทดสอบไม่เข้มงวด

Harness Engineering ออกแบบมาเพื่อจัดการกับทุกจุดนี้ — ไม่ใช่แก้ทีละจุด แต่เป็นระบบที่ครอบคลุม

🌱 จากประสบการณ์จริง: การใช้ AI โดยไม่มี Harness → มี Harness

ขอเล่าประสบการณ์ส่วนตัวของเหน่งให้ฟัง

ช่วงแรกที่เริ่มใช้ AI (ยังจำได้ ประมาณปี 2023-2024) — เหน่งใช้งาน AI แบบตรงไปตรงมา ถามคำถาม รอคำตอบ บางทีก็ใช้ผลลัพธ์ที่ได้มาโดยไม่ตรวจสอบ ไม่มีกระบวนการ ไม่มีมาตรฐาน ไม่มีระบบตรวจสอบ

ผลลัพธ์เป็นอย่างไร? บางครั้งก็ได้คำตอบดี บางครั้งก็ได้คำตอบที่ผิดหรือ outdated แต่ไม่รู้ตัว ต้องเสียเวลาตรวจสอบทีหลัง และบางครั้งก็เสียเวลาไปกับงานที่ไม่จำเป็นเพราะไม่รู้ว่า AI สามารถช่วยได้ดีกว่า

แล้วมาวันหนึ่ง เหน่งเริ่มสังเกตว่า… ถ้ามีกรอบการทำงานที่ชัดเจน การใช้ AI จะมีประสิทธิภาพมากขึ้น

ปัจจุบัน เหน่งใช้ระบบ Qwen (Alibaba) ที่ rotate ตามประเภทงาน:

Qwen 3.5 Plus — สำหรับงานทั่วไป ตอบคำถาม เขียนบทความ
Qwen Max — สำหรับงานซับซ้อน ต้องการความลึก
Qwen Coder — สำหรับเขียนโค้ด งานด้านเทคนิค

แต่ที่สำคัญกว่าเครื่องมือคือ Flow — กระบวนการทำงานที่วางไว้ เมื่อได้คำตอบจาก AI จะตรวจสอบยังไง ประเมินคุณภาพอย่างไร และเก็บบทเรียนจากการใช้งานอย่างไร

เหน่งพอใจกับระบบปัจจุบันประมาณ 90% — ยังมีพื้นที่ให้ปรับปรุง แต่การมี Harness ทำให้รู้สึกมั่นใจขึ้นมากเมื่อเทียบกับตอนแรก

Key Takeaway: เริ่มต้นไม่จำเป็นต้องซับซ้อน เริ่มจากสิ่งเล็กๆ — กำหนดว่าจะใช้ AI ทำอะไร ตรวจสอบผลลัพธ์อย่างไร และเก็บข้อมูลว่าอะไรได้ผล/ไม่ได้ผล ค่อยๆ สร้าง Harness ของตัวเองไปเรื่อยๆ

🔜 ต่อไป: Harness ประกอบด้วยอะไร?

ในตอนที่ 2 เราจะมาดูกันว่า Harness ที่ดีต้องมีองค์ประกอบอะไรบ้าง และ 10 หลักการสำคัญ ในการออกแบบระบบ Harness ที่จะช่วยให้ AI ทำงานได้อย่างมีประสิทธิภาพและปลอดภัย

เตรียมตัวอ่านต่อนะครับ! 🙌

📚 อ้างอิง

แหล่งหลัก:

Harness Books 2 เล่ม โดย wquguru

Book 1: Claude Code Harness
Book 2: Claude Code vs Codex
Online Version: harness-books.agentway.dev

แหล่งเสริม:

MIT Media Lab - State of AI in Business 2025
Knostic - AI Governance Statistics 2025
Harvard Law School Forum - AI Risk Disclosures
Thomson Reuters - AI Governance Gap
Medha Cloud - AI Adoption Statistics 2026
Mashable - Biggest AI Fails 2025
AI Multiple - AI Fail Examples
SG Solutions - Real World AI Failures
WebAsha - Top 7 AI Failures
Gartner - AI Risk Reports

ทำไมต้องเลี้ยง AI? (Harness Engineering สำหรับคนทั่วไป)

jitaret@gmail.com (เหน่ง) — Sun, 12 Apr 2026 09:00:00 +0700

ทำไมต้องเลี้ยง AI?

คำโปรย: AI ฉลาดมาก แต่อาจทำผิดพลาด คู่มือนี้จะสอนวิธีเลี้ยง AI ให้ปลอดภัย เหมือนเลี้ยงเด็กฉลาด

🎯 บทนำ: AI ฉลาดแต่…

ภาพจาก Unsplash

คุณเคยใช้ ChatGPT หรือ Claude ไหมครับ?

AI เหล่านี้ฉลาดมาก สามารถ:

✍️ เขียนบทความได้
💻 เขียนโค้ดได้
📊 วิเคราะห์ข้อมูลได้
💬 ตอบคำถามได้แทบทุกอย่าง

แต่…

เคยสงสัยไหมครับว่า:

ถ้า AI เขียนโค้ดผิด จะทำยังไง?
ถ้า AI ลบไฟล์สำคัญ จะทำยังไง?
ถ้า AI ส่งข้อมูลผิด จะทำยังไง?

หนังสือ Harness Books 2 เล่มนี้ ตอบคำถามเหล่านี้ครับ

🤔 ปัญหาที่เจอ

ประสบการณ์จริงจากเหน่ง:

ช่วงแรกที่ใช้ AI สร้างสิ่งต่างๆ:

“ช่วงแรกที่ได้ลองใช้ AI ในการสร้างสิ่งต่างๆ ค่อนข้างปวดหัว มากครับ ทั้งการศึกษาการใช้งาน OpenClaw และทดสอบตัวอื่นๆ ที่ตามมาภายหลัง”

การเลือกโมเดล LLM:

“ตอนนั้นลองหาข้อมูลเพิ่มดูนะ การเลือกโมเดล LLM ก็มีมาใหม่และเยอะมาก แทบจะเปลี่ยนภายในวันต่อวันเลย พัฒนาค่อนข้างก้าวกระโดดมาก”

ปัจจุบันที่ใช้ Qwen:

“ปัจจุบันเหน่งพอใจใช้โมเดลของ Alibaba Qwen เพราะสามารถใช้กลยุทธ์ rotate ให้ LLM ทำงานที่เหมาะสมกับหน้าที่ เช่น เขียนโค้ด เขียนบทความ หรือออกแบบอื่นๆ”

กระบวนการเรียนรู้:

“ปรับแก้ตั้งค่า ตบตีกับ AI นานมาก กว่าจะเพิ่มใช้งานคล่องมือ และศึกษาข้อมูลทั้งใน Social, Paper, GitHub เรียนรู้เรื่อง Memory เรียนรู้เกี่ยวกับ Skills”

สถานการณ์จริง:

บริษัทหนึ่งให้ AI เข้าถึงระบบไฟล์ ↓ AI ลบไฟล์สำคัญโดยไม่ได้ตั้งใจ ↓ บริษัทเสียหายหลายล้านบาท

ภาพจาก Unsplash

คำถาม:

ผิดที่ AI หรือ?
หรือผิดที่ระบบควบคุม?

คำตอบ: ผิดที่ระบบควบคุมครับ!

💡 วิธีแก้ (จากหนังสือ Harness Books)

แนวคิดหลัก:

AI เหมือนเด็กฉลาด

ฉลาดมาก

แต่อาจทำผิดพลาด

ต้องมีกฎ มีคนตรวจ มีแผนสำรอง

3 หลักการเลี้ยง AI:

หลักการ	เปรียบเทียบ	ตัวอย่าง
1. มีกฎชัดเจน	เหมือนกฎบ้าน	AI ทำอะไรได้/ไม่ได้
2. จำกัดสิทธิ์	เหมือนกุญแจห้อง	AI เข้าถึงไฟล์ไหนได้บ้าง
3. มีคนตรวจสอบ	เหมือนพ่อแม่ตรวจการบ้าน	มี AI อีกตัวตรวจงาน

ประสบการณ์จริงจากเหน่ง:

ก่อนจะ Flow ได้:

1❌ ทดสอบ OpenClaw + เครื่องมืออื่นๆ
2❌ เลือกโมเดล LLM (มีใหม่ทุกวัน)
3❌ เรียนรู้ Memory, Skills
4❌ ตบตีกับ AI นานมาก

ปัจจุบัน:

1✅ ใช้ Qwen (Alibaba) rotate ตามงาน
2✅ มีกระบวนการที่ Flow แล้ว
3✅ พอใจผลงาน 90%

บทเรียน:

“ถ้าเราไม่สามารถเปลี่ยนประสบการณ์ส่วนตัวเป็นกฎที่ใช้ซ้ำได้ เราจะเปลี่ยน Agent เป็นระบบที่เสถียรไม่ได้”

📊 ตัวอย่างจริง

บริษัทที่ใช้ระบบดี:

สิ่งที่ทำ:

✅ มีกฎชัดเจนว่า AI ทำอะไรได้/ไม่ได้
✅ มีทีมตรวจสอบงาน AI
✅ มีแผนสำรองเมื่อ AI ทำผิด

ผลลัพธ์:

📈 ใช้ AI ปลอดภัย
🛡️ ลดความเสี่ยง
⚡ เพิ่มประสิทธิภาพ

✅ สรุป

ข้อคิดที่ได้:

AI ฉลาดแต่อาจทำผิดพลาด — ไม่ใช่เรื่องแปลก
ต้องมีระบบควบคุม — ไม่ควรไว้ใจ 100%
เหมือนเลี้ยงเด็กฉลาด — ต้องมีกฎ มีคนตรวจ มีแผนสำรอง
ต้องเรียนรู้และปรับตัว — LLM เปลี่ยนวันต่อวัน
ต้องทดลองและปรับแต่ง — ตบตีกับ AI นานกว่าจะ Flow
ต้องเปลี่ยนประสบการณ์เป็นกฎ — เพื่อให้ระบบเสถียร

ประสบการณ์จากเหน่ง:

1❌ ช่วงแรก: ปวดหัวกับการเรียนรู้
2 - ทดสอบ OpenClaw + เครื่องมืออื่นๆ
3 - เลือกโมเดล LLM (มีใหม่ทุกวัน)
4 - เรียนรู้ Memory, Skills
5
6✅ ปัจจุบัน:
7 - ใช้ Qwen (Alibaba) rotate ตามงาน
8 - มีกระบวนการที่ Flow แล้ว

สิ่งที่ได้จากซีรีส์นี้:

หลังจากอ่านครบ 8 ตอน คุณจะ:

✅ เข้าใจวิธีควบคุม AI
✅ รู้วิธีสร้างระบบปลอดภัย
✅ ใช้ AI ได้อย่างมั่นใจ
✅ ลดเวลา “ตบตีกับ AI”
✅ ได้ระบบที่ Flow เหมือนเหน่ง
✅ เปลี่ยนประสบการณ์เป็นกฎที่ใช้ซ้ำได้

🔗 อ่านตอนต่อไป

ตอนที่ 1: AI คืออะไร? (และทำไมต้องควบคุม)

คุณจะได้เรียนรู้:

🤖 AI คืออะไร (อธิบายแบบง่าย)
⚠️ ทำไมต้องควบคุม AI
🎯 ตัวอย่าง AI ทำผิดพลาดจริง

⏳ กำลังเขียนเร็วๆ นี้

💬 แชร์ประสบการณ์

คุณเคยใช้ AI ไหมครับ? มีประสบการณ์ดีๆ หรือร้ายๆ ไหม? แชร์ในคอมเมนต์ด้านล่างเลยครับ!

📢 แชร์บทความนี้

ถ้าบทความนี้มีประโยชน์ ฝากแชร์ให้เพื่อนๆ ด้วยนะครับ!

ซีรีส์: Harness Engineering สำหรับคนทั่วไป
ตอน Intro: ทำไมต้องเลี้ยง AI?
โดย เหน่ง - Code & Community

อ้างอิง: Harness Books 2 เล่ม โดย wquguru
Book 1: Claude Code Harness
Book 2: Claude Code vs Codex