บทที่ 03 · ปัญหา & คำศัพท์ · The Agentic Loop
Loop → Agent
ให้ผู้ช่วยขอข้อมูล เห็นผล แล้วตัดสินใจใหม่ได้ — gather → act → verify → repeat
จังหวะที่มัน “ลงมือแล้วตอบสนองต่อผลได้มากกว่าหนึ่งรอบ” คือจังหวะที่มันกลายเป็น agent จริง ๆ
แต่ระวังหมัดเด็ดของบทนี้: ลูปอย่างเดียวยังไม่พอ — ถ้าขั้น verify ไม่ได้มาจากโลกจริง
ลูปก็เป็นแค่วิธี “ตอบผิดอย่างมั่นใจให้เร็วขึ้น”
พูดแบบเข้าใจง่าย
Agentic loop คือสี่ขั้นที่ทำซ้ำจนกว่าจะเสร็จ:
gather (รวบรวมบริบท) → act (ลงมือ เช่นเรียกเครื่องมือ) →
verify (ตรวจผลกับโลกจริง) → repeat (เอาผลที่ตรวจได้ป้อนกลับเข้าไปแล้ววนใหม่)
หัวใจอยู่ที่ขั้น verify — และมันต้องมาจาก “นอกตัวโมเดล”:
ระบบจองตอบจริงว่าจองได้/ชน, เครื่องมือคืนค่าจริงหรือคืน error, การทดสอบรันแล้วผ่าน/ไม่ผ่าน
สิ่งที่ ไม่ใช่ การ verify คือการที่โมเดลพูดเองว่า “เรียบร้อยแล้ว” — นั่นคือการรายงานตัวเอง
ซึ่งโกหก (hallucinate) ได้ และการให้โมเดล “อ่านงานตัวเองซ้ำ” ก็ยังอยู่ในหัวมันอยู่ดี ไม่ใช่การตรวจ
เปรียบเทียบ: หุ่นยนต์ส่งของที่มีกล้อง vs หุ่นที่หลับตาเล่าเส้นทาง
หุ่นที่ดี มองทุกครั้งหลังขยับ — “ยังห่างประตูอีก 2 เมตร” แล้วปรับ
ส่วนหุ่นที่หลับตาคำนวณเส้นทางครั้งเดียว ประกาศ “ส่งของสำเร็จ!” แล้วเดินชนกำแพง — ยังรายงานว่าสำเร็จอยู่เลย
กล้องที่มองโลกจริง = ขั้น verify จากสภาพแวดล้อม การที่หุ่น “อ่านแผนของตัวเองซ้ำแล้วบอกว่าถูก” ก็ยังหลับตาอยู่ดี
ในระบบของเรา — ลูปที่ verify จาก “ระบบจริง”
เมื่อมีคนขอให้ผู้ช่วย “ขยับการจองไม่ให้ชนคาบเรียน” มันไม่ตอบรวดเดียวจบ แต่เดินเป็นลูป
และจุดสำคัญคือ ผลของแต่ละ act มาจากระบบจอง ไม่ใช่จากความมั่นใจของโมเดล:
Gatherอ่านการจอง + ตารางสอน
→
Actลองจอง 13:00
→
Verifyระบบจริงตอบ: “ชนคาบเรียน — FAIL”
→
Repeatเห็น FAIL → เลื่อนเป็น 15:00 → ระบบยืนยัน OK
เปรียบกับลูปที่ ข้าม verify: มัน act แล้วกระโดดไปประกาศ “จองให้แล้ว!” โดยไม่เคยถามระบบเลย —
หน้าตาเหมือนสำเร็จ แต่ห้องอาจถูกจองทับคาบสอนอยู่ ความต่างทั้งหมดอยู่ที่ “ใครเป็นคนตัดสินว่าเสร็จ”:
| ตัวตัดสินว่า “เสร็จ” | ผลเมื่อ act ผิด |
|---|
| ลูปที่ verify จากสภาพแวดล้อม | ระบบจอง (โลกจริง) | เห็น FAIL → วนแก้เอง → สำเร็จจริง |
| ลูปที่ให้โมเดลตรวจเอง | โมเดล (อ่านคำตอบตัวเอง) | บอก “โอเค” ทั้งที่ผิด → ส่งคำโกหก |
| ไม่มี verify เลย | ไม่มีใคร — แค่ประกาศจบ | “Done!” ที่ไม่จริง ไม่มีใครรู้ |
เส้นแบ่งระหว่าง “agent” กับ “การเรียกครั้งเดียว”
สิ่งที่ทำให้ของในบทที่ 02 กลายเป็น agent ไม่ใช่โมเดลที่ฉลาดกว่า แต่คือ ลูปที่ปิดด้วย verify จากโลกจริง
จังหวะที่มันเห็นผลจริงแล้วตัดสินใจขั้นต่อไปได้ คือจังหวะที่มันเลิก “เดาแล้วหวัง” กลายเป็น “ลงมือแล้วปรับ”
ทำพลาด vs ทำถูก
⚠️ แย่ · ลูปที่ไม่มี verify จริง
“ทดสอบผ่านหมดแล้ว — เสร็จ”
agent เขียนแก้แล้วประกาศ “รันเทสต์แล้ว ผ่านทั้งหมด เสร็จ” ทั้งที่ ไม่เคยรันเทสต์จริง
คำว่า “ผ่านทั้งหมด” เป็นแค่ token ที่น่าจะตามมาหลังการแก้โค้ด — ไม่ใช่ผลจากการรันจริง
merge เข้าไปแล้วอีกไม่กี่นาที CI ก็แดง
⚠️ แย่ · ให้โมเดล “ตรวจงานตัวเอง”
reflection ≠ verification
เพิ่มขั้น “ช่วยอ่านคำตอบตัวเองอีกรอบว่าถูกไหม” ฟังดูดี แต่การตรวจนั้น ยังอยู่ในหัวโมเดล
มันแชร์จุดบอดเดียวกับตอนตอบครั้งแรก — อ่านการบ้านตัวเองซ้ำ ไม่เท่ากับเอาไปรันจริง
✅ ดี · verify จากสภาพแวดล้อม
ปล่อยให้โลกจริงตัดสิน
ระบบจองตอบกลับว่า “ชน” หรือ “OK”, เครื่องมือคืน error จริง, เทสต์คืน exit code จริง —
ผลนั้นถูกป้อนกลับเข้าลูปเป็นบริบทใหม่ โมเดลตัวเดิม แต่ตอนนี้มันแก้ตัวเองได้
เพราะมันตอบสนองต่อ “ความจริง” ไม่ใช่ความมั่นใจของตัวเอง
ลองเอง — เปิด VERIFY แล้วลองถอดออก
กิจกรรม · กดสลับแล้วดูผล
Verify the Loop
งานเดียวกันทุกครั้ง: “ขยับการจองไม่ให้ชนคาบเรียน” ลองรันโดย เปิด VERIFY (ตรวจจากระบบจริง)
แล้วลอง ปิด ดู และลองกับดัก “ให้โมเดลตรวจเอง” — ลูปหน้าตาเดิมเป๊ะ
แต่ผลลัพธ์ต่างกันคนละโลก
สลับสวิตช์แล้วอ่าน transcript ของลูป
มองไปข้างหน้า — โครงมีแล้ว แต่ยังพังได้อีกหลายแบบ
ลูปคือ “โครงกระดูก” ของ agent แต่มันยังพังเฉพาะจุดอยู่: มัน เดาชื่อห้องที่ไม่มีจริง,
ไม่รู้จักวันหยุด/ช่วงซ่อมบำรุง, ไปจองทั้งที่คุณแค่ถามว่าว่างไหม, ค้างไม่จบ, และตอบผิดแล้วดูไม่ออกว่าทำไม
ส่วนที่ 2 ทั้งส่วนคือการอุดรอยรั่วเหล่านี้ทีละชิ้น — และทุกชิ้นรวมกันจะมีชื่อว่า harness
สรุปบทที่ 03
- Agentic loop = gather → act → verify → repeat ทำซ้ำจนเสร็จ
- สิ่งที่เปลี่ยน one-shot call ให้เป็น agent คือ ลูปที่ปิดด้วย verify ไม่ใช่โมเดลที่ฉลาดกว่า
- verify ต้องมาจากนอกโมเดล (ระบบจริง/เทสต์) — การรายงานตัวเองและการอ่านงานตัวเองซ้ำ ไม่ใช่ verification
- ลูปที่ไม่มี verify จริง = วิธีตอบผิดอย่างมั่นใจให้เร็วขึ้น
Harness Scorecard · มิติของบทนี้: “verify มาจากสภาพแวดล้อมหรือไม่?”
ผู้ช่วยจัดการแล็บ ✅ ผ่าน (เมื่อเราออกแบบให้ผลการ act มาจากระบบจอง) — แต่จำไว้ว่านี่คือ หลักการ
ที่เราต้องบังคับใช้เอง ไม่ใช่ของแถมจากโมเดล
📋 build-your-harness checklist · บรรทัดที่ 3
“ลูปที่มีขั้น verify จากสภาพแวดล้อม — เชื่อโลกจริง ไม่เชื่อคำว่า ‘เสร็จแล้ว’ ของโมเดล”