ปูพื้นทฤษฎี · 0·2 · Anatomy & the Loop
กายวิภาคของ Harness: ลูปที่เต้นเป็นหัวใจ + ชิ้นส่วนที่ตั้งชื่อได้
ถ้า harness คือ “ทุกอย่างรอบเครื่องยนต์” แล้วมันประกอบด้วยอะไรบ้าง? หน้านี้กางมันออกให้ดู —
เริ่มจาก หัวใจที่ทำให้มันเป็น agent (ลูปคิด-ทำ-ตรวจ) แล้วไล่ชิ้นส่วนที่ตั้งชื่อได้ทีละชิ้น
ซึ่งแต่ละชิ้นจะกลายเป็นหนึ่งบทในส่วนที่ 2 ของคอร์ส
หัวใจ: ลูป gather → act → verify → repeat
จุดที่แยก “AI agent” ออกจาก “การเรียกโมเดลครั้งเดียว” ไม่ใช่ว่าโมเดลฉลาดกว่า — แต่คือมันวิ่งอยู่ใน
ลูป: รวบรวมบริบท → ลงมือ (เรียกเครื่องมือ) → ตรวจผลกับของจริง → แล้ววนกลับไปคิดใหม่
จนกว่างานจะเสร็จหรือชนเงื่อนไขหยุด
1 · Gatherรวบรวม context: คำถาม + ผลเครื่องมือ + ความจำ
→
2 · Actตัดสินใจแล้วลงมือ — เรียกเครื่องมือหนึ่งครั้ง
→
3 · Verifyตรวจผลกับ สภาพแวดล้อมจริง ไม่ใช่กับคำพูดของตัวเอง
→
4 · Repeatยังไม่เสร็จ? วนกลับไปข้อ 1 พร้อมสิ่งที่เพิ่งรู้
ขั้นที่ 3 (Verify) คือพระเอกตัวจริง
การตรวจสอบต้องมาจาก สภาพแวดล้อม — ผลการรันจริง สถานะในฐานข้อมูล ภาพหน้าจอ ตัวตรวจความถูกต้อง —
ไม่ใช่จากการที่โมเดลบอกเองว่า “เรียบร้อยแล้ว” ถ้าตัดขั้นนี้ออก ลูปจะวนทำผิดอย่างมั่นใจไปเรื่อย ๆ
(เราจะลงมือพิสูจน์เรื่องนี้กันในบทที่ 03 และ 07)
ชิ้นส่วนที่ตั้งชื่อได้ — และ failure ที่แต่ละชิ้นแก้
รอบ ๆ ลูปนั้น มี scaffolding อยู่หลายชิ้น วิธีที่ดีที่สุดในการเข้าใจมันคือดูว่า แต่ละชิ้นเกิดมาเพื่อแก้ความพังแบบไหน
คอร์สนี้จะสร้างมันทีละชิ้นในส่วนที่ 2 (บท 04–10) — คลิกแต่ละชิ้นด้านล่างเพื่อดูว่ามันคืออะไรและบทไหนสร้างมัน:
กิจกรรม · คลิกสำรวจ
Anatomy of a Harness
คลิกชิ้นส่วนแต่ละชิ้นรอบ ๆ ลูป เพื่อดู ความพังที่มันแก้ · การเปรียบเทียบแบบบ้าน ๆ และ
บทที่ลงมือสร้างมัน — นี่คือแผนที่ของส่วนที่ 2 ทั้งหมดในที่เดียว
คลิกชิ้นส่วนเพื่อกางรายละเอียด
บันไดความซับซ้อน — ปีนขึ้นเฉพาะเมื่อขั้นล่าง “พิสูจน์แล้วว่าไม่พอ”
“harness” ไม่ได้แปลว่าต้องอลังการเสมอไป มันมีระดับความซับซ้อนเป็นบันได และมืออาชีพจะ
เริ่มจากขั้นล่างสุดเสมอ แล้วปีนขึ้นทีละขั้น ก็ต่อเมื่อวัดได้ว่าขั้นล่างไม่พอจริง ๆ:
ขั้น 0 · ไม่ใช้ AIquery / dashboard / สูตรคำนวณ — ตอบได้แน่นอน ถูกที่สุด
→
ขั้น 1 · เรียกครั้งเดียวโมเดลเรียกครั้งเดียวสำหรับงานภาษาตรง ๆ
→
ขั้น 2 · workflowหลายขั้นตามเส้นทางที่เรากำหนดไว้ล่วงหน้า
→
ขั้น 3 · agentโมเดลกำหนดเส้นทาง/จำนวนรอบเอง (ลูปเต็มตัว)
→
ขั้น 4 · multi-agentหลาย agent แยก context กัน — แพงสุด ใช้เมื่อจำเป็นจริง
กฎที่มืออาชีพไม่ยอมข้าม: พิสูจน์ขั้นที่ง่ายกว่าก่อนเสมอ
~70% ของสิ่งที่คนเรียกว่า “งานของ AI agent” จริง ๆ แล้วอยู่ที่ ขั้น 0 — เป็น query หรือ dashboard ที่ไม่ต้องใช้ LLM เลย
(ตัวเลข ~70% เป็นข้อสรุปเชิงออกแบบจากการยึดดีไซน์กับโค้ดจริง ไม่ใช่สถิติที่วัดเป๊ะ)
การกระโดดไป multi-agent เพราะ “ดูเท่” คือจ่ายแพงขึ้น ช้าลง ดีบักยากขึ้น แลกกับความยืดหยุ่นที่ไม่ได้ใช้
(เจาะลึกบันไดนี้ในบทที่ 03 และ 15)
ทำพลาด vs ทำถูก
⚠️ แย่ · เริ่มจากขั้นบนสุด
multi-agent ให้กับงานที่เป็นแค่การค้น
เลือกสถาปัตยกรรมที่ซับซ้อนที่สุดก่อนพิสูจน์ว่าขั้นล่างไม่พอ — ได้ระบบที่ แพง ช้า เปราะ และดีบักยาก
โดยไม่ได้ความถูกต้องเพิ่มขึ้นเลย
⚠️ แย่ · ลูปที่ไม่มี Verify
ให้โมเดล “ตรวจงานตัวเอง” ด้วยคำพูด
ปล่อยให้ลูปวนโดยเชื่อคำว่า “สำเร็จแล้ว” ของโมเดลเอง — มันจะ มั่นใจในคำตอบที่ผิด
และวนทับความผิดนั้นไปเรื่อย ๆ โดยไม่มีอะไรดึงกลับ
✅ ดี · เริ่มต่ำ ตรวจกับของจริง
ขั้นต่ำสุดที่ได้ผล + verify จาก environment
เริ่มที่ขั้นที่ง่ายที่สุดที่ยังตอบโจทย์ ปีนขึ้นเมื่อวัดได้ว่าจำเป็น และทำให้ทุกรอบของลูป
ตรวจกับสภาพแวดล้อมจริง ไม่ใช่กับความมั่นใจของโมเดล
มองไปข้างหน้า — ชิ้นส่วนเหล่านี้มี “ชื่อสนาม” ของมัน
ชิ้นส่วนที่คุณเพิ่งสำรวจมีศัพท์เฉพาะที่ทั้งวงการใช้ร่วมกัน — context engineering, MCP, Skills, tools,
orchestration, evaluation, security หน้า 0·3 — ภูมิทัศน์สนามปี 2026 จะจับคู่
“ความพัง” แต่ละอย่างกับคำศัพท์และบทที่ลงลึก เพื่อให้คุณมีแผนที่คำศัพท์ครบก่อนเริ่มเรื่องเล่า
สรุปหน้า 0·2
- หัวใจของ harness คือ ลูป gather → act → verify → repeat — และ verify ต้องมาจาก สภาพแวดล้อม
- ชิ้นส่วนที่ตั้งชื่อได้ — Tools · Context · Memory · Grounding/Verify · Permissions · Observability — แต่ละชิ้นแก้ failure แบบหนึ่ง (= บท 04–10)
- มีบันไดความซับซ้อน: ไม่ใช้ AI → เรียกครั้งเดียว → workflow → agent → multi-agent
- กฎเหล็ก: พิสูจน์ขั้นที่ง่ายกว่าก่อนเสมอ ปีนขึ้นเมื่อวัดได้ว่าจำเป็น