02กายวิภาคของ Agent Loop

ก่อนจะออกแบบระบบรอบโมเดล ต้องเห็นก่อนว่าโมเดล "เปล่า ๆ" ทำอะไรได้บ้าง · คำตอบโหดกว่าที่คิด: มันไม่มีมือ — โมเดลภาษารับข้อความเข้า แล้วพ่นข้อความออก จบแค่นั้น มันเปิดไฟล์ไม่ได้ รันคำสั่งไม่ได้ ต่อเน็ตไม่ได้ แม้แต่จำอะไรข้ามรอบยังไม่ได้ (เล่ม #07 บทที่ 1 ปูเรื่องนี้ไว้แล้ว)

แล้ว agent ที่ "ทำงานเองเป็นชั่วโมง" มาจากไหน? มาจาก harness ที่เอาความสามารถเดียวของโมเดล (พ่นข้อความ) มาวนอยู่ใน loop ง่าย ๆ อันเดียว — วงจรที่เรียบง่ายจนน่าตกใจ แต่ทั้งวงการตั้งอยู่บนมัน

2.1 วงจรพื้นฐาน — โค้ดไม่ถึง 15 บรรทัด

▸ pseudocode: agent loop ทั้งตัว

history = [system_prompt, tool_schemas, งานจากผู้ใช้]  # สิ่งที่โมเดล "เห็น"

loop:
    response = model(history)             # โมเดลทำได้แค่นี้: พ่นข้อความ

    if response คือข้อความธรรมดา:          # ไม่ขอใช้เครื่องมือแล้ว
        return response                   # → ถือว่าจบงาน ตอบผู้ใช้

    call = response.tool_call             # เช่น read_file("app.py")
    if not allowed(call):                 # ด่าน guardrails (บท 6)
        result = ask_human(call)          # เสี่ยงไป → ให้คนตัดสิน
    else:
        result = execute(call)            # harness เป็นคนรันจริงเสมอ

    history += [call, result]             # ผลกลายเป็น context รอบถัดไป

ไล่ตามทีละขั้น: harness รวบ context (ทุกอย่างที่โมเดลควรเห็น) → ส่งเข้าโมเดล → โมเดลตอบได้ 2 แบบ: ข้อความธรรมดา (แปลว่าจบงานหรือมีคำถาม) หรือ tool call (คำขอใช้เครื่องมือ เป็นข้อความรูปแบบ JSON) → harness ตรวจสิทธิ์แล้วรันเครื่องมือให้จริง → ยัดผลลัพธ์กลับเข้า context → วนใหม่ จนกว่าโมเดลจะเลิกขอใช้เครื่องมือ

จุดที่คนเข้าใจผิดบ่อยสุด: โมเดลไม่ได้รันเครื่องมือเอง — มันแค่ "เขียนคำขอ" ออกมาเป็นข้อความ · คนกดปุ่มจริงคือ harness เสมอ และตรงนี้แหละคือที่มาของอำนาจทั้งหมด: harness จะรันตามคำขอ, ขอคำยืนยันจากคนก่อน, หรือปฏิเสธเลยก็ได้ (บทที่ 6) — โมเดลบังคับอะไรไม่ได้เลย

2.2 อะไรถูกประกอบเข้า context ทุกรอบ

บรรทัดแรกของ pseudocode ซ่อนเรื่องใหญ่ไว้ — ทุกรอบที่เรียกโมเดล harness เป็นคนประกอบสิ่งที่โมเดลเห็นขึ้นมาใหม่ทั้งชุด:

• system prompt ที่ harness เขียนเอง — ชิ้นส่วนที่ทรงพลังที่สุดของทั้งระบบ · Claude Code ที่พี่ใช้ไม่ใช่ "Claude เปล่า ๆ" — ก่อนข้อความแรกของพี่จะถึงโมเดล harness แนบ "จดหมายงาน" ยาวหลายพันคำที่ทีมผู้สร้างเขียนไว้: คุณคือใคร ทำงานสไตล์ไหน ใช้เครื่องมือแต่ละตัวเมื่อไหร่ ข้อห้ามความปลอดภัยอะไรบ้าง · มันกำหนดบุคลิกและกติกาของ agent ทั้งตัว — และเป็นจุดเดียวกับที่ instructions ถาวรอย่าง CLAUDE.md ถูกเสียบเข้ามา (บทที่ 9)
• tool schemas — "เมนูเครื่องมือ" ที่บอกว่ามีอะไรให้ใช้ ใช้ยังไง (บทที่ 4)
• ประวัติการคุย + ผล tool ทุกรอบที่ผ่านมา — ส่วนเดียวที่โตขึ้นเรื่อย ๆ และจะกลายเป็นปัญหาหลักของบทที่ 3

2.3 แผนที่ของทั้งเล่ม — ทุกบทยึดจุดใดจุดหนึ่งของ loop

ความลับของเล่มนี้: ทุกบทที่เหลือคือการปรับแต่งจุดใดจุดหนึ่งของวงจรข้างบน · ดูรูปนี้ค้างไว้ — มันคือแผนที่ที่เราจะเดินตลอดเล่ม:

🧭 คุณคือ harness — หลักการเล่มนี้ในเวอร์ชัน chat — ตอนใช้แชตธรรมดา ไม่มี harness มาช่วย เพราะพี่นั่นแหละคือ harness ที่ทำทุกหน้าที่ด้วยมือ: เปิดแชตใหม่พร้อมสรุปงานที่ค้าง = compaction (บท 3) · แปะไฟล์เฉพาะตอนถึงจังหวะใช้ ไม่ยัดทั้งหมดแต่แรก = just-in-time context (บท 3) — และตัวพี่เองคือ "tool" ที่ไปหยิบข้อมูลมาให้ (บท 4) · ให้เกณฑ์แล้วสั่ง "ตรวจงานตัวเองตามเกณฑ์นี้ก่อนส่ง" = feedback loop (บท 5) · รู้ตัวว่า AI วนแก้ที่เดิม 3 รอบไม่หลุดสักที เลิกแล้วเปิดแชตใหม่ = stop condition (บท 8) · Custom Instructions / Projects ที่ตั้งค้างไว้ = memory (บท 9) · ส่วน permissions, observability, subagents, evals ไม่ต้องมี — เพราะพี่นั่งอ่านอยู่ทุกข้อความ อนุมัติเองทุกจังหวะ · ศาสตร์นี้จึงไม่ใช่เรื่องของคนสร้าง agent เท่านั้น — เข้าใจแล้ววิธีใช้ AI ประจำวันเปลี่ยนได้ทันที

✅ สรุปบทที่ 2 — โมเดลไม่มีมือ — รับข้อความ พ่นข้อความ จบ · agent เกิดจาก harness วน loop: รวบ context → โมเดลตอบ (ข้อความ/tool call) → harness ตรวจสิทธิ์แล้วรันจริง → ผลกลับเข้า context → วนจนจบ · โมเดลแค่ "เขียนคำขอ" — คนกดปุ่มจริงคือ harness เสมอ · ทุกรอบ harness ประกอบ context ใหม่: system prompt ของ harness (ชิ้นทรงพลังสุด) + tool schemas + ประวัติ + ผล tool · ทุกบทที่เหลือของเล่ม = ปรับแต่งจุดใดจุดหนึ่งของ loop นี้