แกนกลาง — Context → Spec → Loop → Gate → Verify

2.1 หลักการ 5 ข้อ

1. ความถูกต้องต้องมาจากเครื่อง ไม่ใช่จากโมเดล

LLM ประเมินงานตัวเองได้ไม่น่าเชื่อถือ มันมีแนวโน้มบอกว่า “เสร็จแล้วครับ ทดสอบผ่านหมด” โดยไม่ได้รัน test จริง หลักการนี้แปลว่าทุก claim ของ agent ต้องมี artifact รองรับ ไม่ว่าจะเป็น exit code, test output, diff หรือ log ถ้า agent บอกว่าผ่านแต่ไม่มี output ให้ถือว่าไม่ผ่าน

2. State อยู่ในไฟล์ ไม่ใช่ใน context window

Context window คือหน่วยความจำชั่วคราวที่หายเมื่อจบ session และเสื่อมคุณภาพเมื่อยาวขึ้น ทุกอย่างที่ต้องคงอยู่ ทั้งกติกา การตัดสินใจ และสิ่งที่ลองแล้วไม่ได้ผล ต้องเขียนลงไฟล์ทันที เป้าหมายคือ session ใหม่ที่ไม่มีประวัติเลย ควรทำงานต่อได้ทันทีจากการอ่าน repo

3. งานต้องเล็กพอที่ loop จะปิดได้

งานที่ดีสำหรับหนึ่ง loop คืองานที่มีเกณฑ์ผ่านชัดเจนและใช้เวลา agent 5–30 นาที “สร้างระบบ payment” ไม่ใช่งานเดียว แต่คือ 8 งาน ถ้า loop ปิดไม่ได้ภายในเวลาที่คาด แปลว่างานใหญ่เกินหรือสเปกไม่ชัด ให้หยุดแล้วซอย ไม่ใช่ปล่อยให้ agent วนต่อ

4. ทุก loop ต้องมีเพดานและเงื่อนไขหยุด

agent ที่วนแก้ error โดยไม่มีเพดานจะเผา token ทำลายโค้ดที่เคยดี และบางครั้งจะ “แก้ปัญหา” ด้วยการลบ test ที่ fail ต้องมี max iterations, การตรวจจับว่าไม่คืบหน้า, และ tripwire สำหรับพฤติกรรมต้องห้าม เช่น แก้ test เพื่อให้ผ่าน ใส่ skip หรือลด threshold

5. มนุษย์เป็นเจ้าของสามสิ่งเสมอ

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

2.2 ภาพรวมของ loop

มนุษย์ทำ
  SPEC     docs/specs/xxx.md    กติกาธุรกิจ + เคสที่ต้อง reject
  CONTEXT  AGENTS.md, skills/   สถาปัตยกรรม + convention + ข้อห้าม
  GATE     scripts/verify.sh    นิยามของคำว่า "ผ่าน" ที่รันซ้ำได้
     │
     ▼
AGENT LOOP — วนได้เองโดยไม่ต้องมีคนอยู่ด้วย
  1  อ่าน spec และ context ที่เกี่ยวข้อง
  2  เขียน test จาก spec แล้วรัน ต้องแดง
     ถ้าเขียวตั้งแต่แรก แปลว่า test ไม่ได้ทดสอบอะไร
  3  เขียน implementation ให้น้อยที่สุดที่ทำให้ผ่าน
  4  รัน verify.sh
     แดง → อ่าน error → แก้ → วนกลับข้อ 3 (เพดาน N รอบ)
     เขียว → ไปข้อ 5
  5  GREEN — gate ผ่านทั้งชุด พร้อม output จริง
  6  บันทึกบทเรียนลง memory/pitfalls.md และ ADR
  7  เปิด PR พร้อมแนบ gate output
     │
     ▼
มนุษย์ทำ
  REVIEW   ตรวจ spec / คุณภาพ test / blast radius — ไม่ใช่ทุกบรรทัด
  SHIP     canary → เฝ้า guardrail metric → rollout หรือ rollback

2.3 หนึ่งรอบของ loop ประกอบด้วยอะไร

ส่วนประกอบ	หน้าที่	ถ้าขาดจะเกิดอะไร
Goal	สิ่งที่ต้องเป็นจริงเมื่อจบ เขียนเป็นประโยคเดียว	agent ทำงานเกินขอบเขต แก้ไฟล์ที่ไม่เกี่ยว
Context	ไฟล์ที่เกี่ยวข้อง convention และข้อห้าม	agent สร้าง pattern ใหม่ทับของเดิม
Action space	คำสั่งที่ทำได้ และไฟล์ที่แตะได้	agent รันคำสั่งอันตราย หรือแก้ config ที่ไม่ควรแตะ
Feedback	ผลลัพธ์ที่อ่านได้ด้วยเครื่อง เช่น exit code, stderr	agent เดาว่าตัวเองทำถูก วนไปเรื่อย ๆ
Stop condition	เขียว หรือชนเพดาน หรือไม่คืบหน้า	เผา token ไม่จำกัด และโค้ดเสื่อมลงทุกรอบ
Persistence	บันทึกผลและบทเรียนลงไฟล์	รอบหน้าพลาดเรื่องเดิมซ้ำ

กฎ feedback ที่สำคัญที่สุด

คุณภาพของ agent loop ถูกกำหนดโดยคุณภาพของ feedback ไม่ใช่ความฉลาดของโมเดล error message ที่บอกว่า AssertionError เฉย ๆ ทำให้ agent เดา แต่ expected discount=90.00 (10% of 900) got 100.00 — tax applied after discount? ทำให้ agent แก้ถูกในรอบเดียว การลงทุนที่คุ้มที่สุดในงาน agentic คือการทำให้ test error พูดเก่งขึ้น

สรุปบทนี้

ห้าหลักการนี้เป็นชุดเดียวกัน เครื่องเป็นผู้ตัดสิน ความรู้อยู่ในไฟล์ งานเล็กพอที่จะปิดได้ ทุก loop มีเพดาน และคนถือสเปก เกณฑ์ และการอนุมัติไว้เสมอ ถ้าขาดข้อใดข้อหนึ่ง loop จะกลายเป็นการเผา token แทนที่จะเป็นการทำงาน

บทถัดไปว่าด้วยโครงสร้าง repo ที่ทำให้ agent ซึ่งเพิ่งเปิด session ใหม่ ทำงานถูกได้ทันทีโดยไม่ต้องมีใครอธิบาย