บทที่ 15 · Context · เชื่อถือ · สเกล · Orchestration

Orchestration & บันไดความซับซ้อน

บทเรียนที่ติดตัวกลับไปแน่ ๆ ของทั้งคอร์ส: เมื่อไหร่ที่ “ไม่ควรใช้ agent เลย” single call → workflow → agent → multi-agent — ขึ้นบันไดทีละขั้น เฉพาะเมื่อขั้นล่างพังให้เห็น ๆ ตัวอย่างนำ: ตัวหาห้องว่างที่จริง ๆ แล้วเป็นแค่ query ฐานข้อมูล ไม่ใช่ AI

พูดแบบเข้าใจง่าย

บันไดมี 4 ขั้น — ยิ่งขึ้น ยิ่งทรงพลังแต่ยิ่งคาดเดายาก แพง และดีบักลำบาก:

1 · LLM call เดียว — prompt เข้า คำตอบออก ไม่มี tool ไม่มีลูป
2 · workflow ตายตัว — โค้ด/cron ร้อยขั้นที่รู้ล่วงหน้า อาจเรียก LLM ที่ หนึ่งขั้นที่รู้
3 · agent เดี่ยว — LLM ในลูปที่เลือกเองว่าจะเรียก tool อะไรและหยุดเมื่อไร
4 · multi-agent — หลาย agent ประสานกัน

คำถามชี้ขาด: “ระบุ control flow ล่วงหน้าได้ไหม” — ถ้าขั้นตอนและลำดับรู้ล่วงหน้า นั่นคือโค้ด (ขั้น 2) แม้จะมีขั้นหนึ่งบังเอิญเรียกโมเดล · agent (ขั้น 3) คุ้มก็ต่อเมื่อเส้นทาง เดาล่วงหน้าไม่ได้จริง ๆ · multi-agent (ขั้น 4) คุ้มก็ต่อเมื่อ context หรือความเร็วของ agent เดียวเป็นคอขวด — และมัน กิน token ราว 15 เท่า อิ่มตัวที่ราว ~4 ตัว และพังบ่อยเพราะการประสานงานระหว่าง agent

สำหรับ multi-agent: spawn prompt คือสัญญาทั้งหมดระหว่างพ่อ→ลูก (subagent เริ่มด้วย context ว่างเปล่า เห็นแค่ข้อความที่ส่งให้) · แตกงานเมื่อ อ่านหนัก + แยกชิ้นได้ แล้วค่อยรวบเป็นนักเขียนเดียว · อยู่ agent เดียวเมื่อ เขียนหนัก + ต้องสอดคล้องกัน

เปรียบเทียบ: เลือกพาหนะตามทริป จักรยาน = LLM call เดียว (ฮอปสั้น ๆ) · รถบนเส้นทางประจำ = workflow (ทุกเลี้ยวรู้ล่วงหน้า ไม่ต้องมีนำทาง) · รถตู้มีคนขับ = agent เดี่ยว (บอกปลายทาง คนขับตัดสินใจแต่ละเลี้ยว — ใช้เมื่อเส้นทางไม่รู้ล่วงหน้า) · ขบวนรถตู้มี dispatcher = multi-agent (ทรงพลังแต่จ่ายหลายเงินเดือนและต้องแก้รถติดระหว่างคัน) · ไม่มีใครส่งขบวน 4 คันไปซื้อกาแฟแก้วเดียว และไม่มีใครสั่งจักรยานให้ “ข้ามประเทศ หาทางเอาเอง”

ในระบบของเรา — เลือกขั้นที่ต่ำสุดที่ทำงานได้

งาน	ขั้นที่ใช้จริง	ทำไม
ดึงค่าฝุ่น AQI ทุก 30 นาที	2 · workflow (ไม่มี LLM)	ทุกขั้นรู้ล่วงหน้า — cron ก็พอ
ออโต้เกรดตามเวลา + แจ้งครู	2 + LLM กั้นหนึ่งขั้น	มีแค่ “ตรวจเรียงความ” ที่ไม่แน่นอน — กั้นไว้ขั้นเดียว
หาห้องว่างที่ลงตัว	code tool (เลขคณิตช่วงเวลา)	เป็น set arithmetic ไม่ใช่การตัดสินใจ — ไม่ต้องมี LLM
กรอก+ส่ง TQF3 ผ่าน portal สด	3 · agent เดี่ยว	แต่ละขั้นขึ้นกับสิ่งที่ portal ตอบ — ระบุล่วงหน้าไม่ได้

หัวใจ: ของที่คนเรียกว่า “งานของ AI agent” ราว 70% จริง ๆ คือ SQL view / dashboard / tool ตายตัว — AI คุ้มเฉพาะตอนต้อง สังเคราะห์ · ใช้ภาษา · ตัดสินเชิงคุณภาพ และมืออาชีพจะ “พิสูจน์ขั้นที่ง่ายกว่าก่อนเสมอ” (การแตก subagent ~14 ตัวเพื่อสร้างเนื้อหาคู่มือนี้คือ fan-out ที่ถูกต้อง: อ่านหนัก แยกชิ้นได้ แล้วรวบเป็นเว็บเดียว)

ทำพลาด vs ทำถูก

⚠️ แย่ · over-engineer

ฝูง agent ไปดึง AQI

ทำ AQI ที่เป็น cron ง่าย ๆ ให้เป็น 4 agent ประสานกัน — ทุก tick จ่าย token หลายเท่า ช้าลง และ “Validator” บางทีไปแก้ค่าจริงให้ “ดูสมเหตุสมผล” = สร้างข้อมูลผิดที่ขั้น 2 ไม่มีวันทำ

⚠️ แย่ · under-engineer (และแตกงานผิด)

prompt เดียว “ทำ TQF3 ทั้งหมด”

ขอ call เดียวให้ล็อกอิน portal กรอกทุกหมวดและส่ง — มันลงมือกับ portal สดไม่ได้ คืน “เสร็จแล้ว!” ที่มั่ว · และการแตกงาน “เขียนสอดคล้องกัน” ให้หลาย subagent = เข้าโซนพังเรื่องประสานงาน

✅ ดี · เลือกขั้นให้ถูก

ต่ำสุดที่ทำงานได้ + fan-out ถูกที่

ระบุ control flow ได้ → เขียนเป็นโค้ด; เส้นทางไม่แน่นอนจริง → agent; อ่านหนัก/แยกชิ้นได้ → fan-out แล้วรวบเป็นนักเขียนเดียว ขึ้นบันได เฉพาะเมื่อขั้นล่างพังให้เห็น ๆ

ลองเอง — วางงานบนบันไดให้ถูกขั้น

กิจกรรม · คลิกจัดลงขั้น

Pick the Right Rung

วางงาน 5 อย่างลงบันได 4 ขั้น แล้วกดตรวจ — คุณจะรู้สึกทั้งสองด้านของความผิด: over-engineer (AQI ขึ้นขั้น 4 แดง) และ under-engineer (TQF3 ลงขั้น 1 แดง) และมีงานที่ ไม่ต้องใช้ LLM เลย

คลิกเลือกการ์ด แล้วคลิกขั้น · ดูมิเตอร์ต้นทุน

มองไปข้างหน้า — เลือกโครงถูกแล้ว แต่มัน “ได้ผลจริง” ไหม? บทนี้ช่วยเลือกโครงสร้างที่เหมาะ แต่จะรู้ได้ยังไงว่า agent ที่สร้างมา ตอบถูกจริง? บทที่ 16 ว่าด้วย การประเมินผล (evaluation)

สรุปบทที่ 15

บันได 4 ขั้น — ขึ้นทีละขั้น เฉพาะเมื่อขั้นล่างพังให้เห็น
คำถามชี้ขาด: ระบุ control flow ล่วงหน้าได้ไหม → ถ้าได้ เขียนเป็นโค้ด
multi-agent กิน ~15× token อิ่มตัว ~4 ตัว · spawn prompt คือสัญญาทั้งหมด · fan-out เมื่ออ่านหนัก/แยกชิ้นได้
~70% ของ “งาน AI” จริง ๆ คือ SQL/dashboard/tool ตายตัว — พิสูจน์ขั้นที่ง่ายกว่าก่อนเสมอ

Harness Scorecard · มิติ: “เลือกขั้นที่ถูก ไม่ใช่ autonomy สูงสุด?” ระบบเรา: ✅ แข็ง — เลือกขั้นต่ำสุดที่ทำงานได้อย่างมีวินัย (AQI=cron, slot-finder=code, TQF3=agent)

📋 build-your-harness checklist · บรรทัดที่ 14 “เลือกขั้นบันไดต่ำสุดที่ทำงานได้ · ขึ้นเฉพาะเมื่อขั้นล่างพัง · บางงานไม่ต้องใช้ LLM เลย”

หมายเหตุข้อมูล: การจับคู่ “งาน → ขั้นบันได” อ้างอิงสถาปัตยกรรมจริงของระบบเรา (AQI puller, autograde scheduler, slot-finder, curriculum agent) มิเตอร์ต้นทุนเป็นภาพเชิงสาธิต · ตัวเลข ~15× token / อิ่มตัว ~4 อ้างอิงงานวิจัย multi-agent ที่เผยแพร่