Agent as Bounded Context — ออกแบบ​ระบบ AI Agent ด้วย DDD

ความคืบหน้า0 / 8 บทเรียน

เส้น​ทางการ​เรียน

1. ●01ทำไม agent ต้องมีขอบเขตเริ่มตรงนี้
   • Agentระบบซอฟต์แวร์ที่รับเป้าหมายแล้ววางแผน-ตัดสินใจ-เรียกใช้ tool ได้เองหลายรอบ (agentic loop) โดยไม่ต้องมีมนุษย์กำกับทุกก้าว ต่างจากโปรแกรมทั่วไปที่รันตามลำดับคำสั่งตายตัว — ในคอร์สนี้มองแต่ละ agent เหมือน1 Bounded Context ที่ต้องมีขอบเขต ภาษา และหน้าที่ของตัวเองชัดเจน
   • Context Rotอาการที่คุณภาพการตอบของ agent เสื่อมลงเมื่อ context window ยาวขึ้นและสะสมสิ่งไม่เกี่ยวข้องมากขึ้นเรื่อย ๆ ระหว่างวน agentic loop หลายรอบ — เป็นเหตุผลเชิงเทคนิคข้อหนึ่งที่ agent ควรมีขอบเขตหน้าที่แคบ (เหมือน Bounded Context) แทนที่จะยัดทุกอย่างไว้ใน agent เดียวที่ context ยาวขึ้นเรื่อย ๆ
   • Bounded Contextขอบเขตที่ ubiquitous language และ model หนึ่งชุดมีความหมายคงเส้นคงวา นอกขอบเขตนี้คำเดียวกันอาจหมายถึงคนละอย่าง — เมื่อออกแบบระบบ agent ให้คิดว่าแต่ละ agent (หรือกลุ่ม agent ที่ทำงานร่วมกัน) ควรรับผิดชอบ Bounded Context เดียว ไม่ใช่ยัดทุกหน้าที่ไว้ใน agent เดียว หรือกระจาย agent ตามอำเภอใจ
2. ○02Subdomain → ขอบเขตของ agent (บันไดการยกระดับ)
   • Subdomainส่วนย่อยของปัญหาทางธุรกิจ (problem space) แบ่งเป็น core, supporting, generic — ก่อนจะออกแบบว่าจะมี agent กี่ตัวและแต่ละตัวทำอะไร ต้องวิเคราะห์ subdomain ของธุรกิจก่อนเสมอ ไม่ใช่เริ่มจากอยาก 'มี agent' แล้วค่อยหาเรื่องให้มันทำ
   • Workflow vs Agentความต่างสำคัญที่มักถูกมองข้าม: workflow คือ code ที่กำหนดลำดับขั้นตอนตายตัวไว้ล่วงหน้า (คาดเดาได้ ทดสอบง่าย) ส่วน agent คือระบบที่ตัดสินใจเส้นทางเองแบบไดนามิกผ่าน agentic loop (ยืดหยุ่นกว่าแต่คาดเดายากกว่า) — โจทย์ส่วนใหญ่ไม่ต้องการ agent เต็มรูปแบบ workflow ที่ออกแบบดีมักพอเพียงและเชื่อถือได้กว่า
   • Agentic Loopวงจรที่ agent ทำซ้ำจนกว่าจะบรรลุเป้าหมาย: รับ input → วางแผน/ตัดสินใจ → เรียก tool → สังเกตผลลัพธ์ → วนกลับไปตัดสินใจใหม่ — ต่างจากโปรแกรมทั่วไปที่รันเส้นทางเดียวจบ วงจรนี้เองที่ทำให้ agent ยืดหยุ่น แต่ก็เสี่ยง context rot ถ้าวนนานเกินไปโดยไม่มีขอบเขต
3. ○03Ubiquitous Language → system prompt + tools
   • Ubiquitous Languageภาษากลางที่ทีมและผู้เชี่ยวชาญธุรกิจใช้ร่วมกัน อิงกับ model โดยตรง — สำหรับ agent แล้ว ภาษานี้คือคำศัพท์ที่ปรากฏใน system prompt ชื่อ tool และ schema ของมันด้วย ถ้าคำใน code agent ไม่ตรงกับคำที่ผู้เชี่ยวชาญธุรกิจใช้ แปลว่ากำลังหลงทาง
   • System Promptชุดคำสั่งที่ฝังไว้ล่วงหน้าเพื่อกำหนดบทบาท ขอบเขตหน้าที่ ภาษา และกติกาของ agent ก่อนเริ่มสนทนาจริง เทียบได้กับสัญญา (contract) ที่ประกาศว่า Bounded Context นี้รับผิดชอบอะไร และปฏิเสธคำขอที่อยู่นอกขอบเขต
   • Toolfunction หรือ API ภายนอกที่ agent เรียกใช้ได้เพื่อกระทำสิ่งที่ model ภาษาเองทำไม่ได้ เช่น ค้นเว็บ อ่าน file เรียกฐานข้อมูล — ขอบเขตของชุด tool ที่ agent หนึ่งถืออยู่ก็คือส่วนหนึ่งที่นิยาม Bounded Context ของ agent นั้น ยิ่ง tool set กว้างเกินหน้าที่ ยิ่งเสี่ยงให้ agent ล้ำขอบเขต
4. ○04Bounded Context → agent หนึ่งตัว (memory + guardrails)
   • Bounded Contextขอบเขตที่ ubiquitous language และ model หนึ่งชุดมีความหมายคงเส้นคงวา นอกขอบเขตนี้คำเดียวกันอาจหมายถึงคนละอย่าง — เมื่อออกแบบระบบ agent ให้คิดว่าแต่ละ agent (หรือกลุ่ม agent ที่ทำงานร่วมกัน) ควรรับผิดชอบ Bounded Context เดียว ไม่ใช่ยัดทุกหน้าที่ไว้ใน agent เดียว หรือกระจาย agent ตามอำเภอใจ
   • Agent Memoryกลไกที่ agent เก็บข้อมูลข้ามรอบของ agentic loop หรือข้าม session เช่น สรุปบทสนทนาเก่า บันทึกข้อเท็จจริงระยะยาว หรือผลลัพธ์ก่อนหน้าที่ต้องอ้างอิงต่อ — ออกแบบให้ดีต้องเลือกว่าอะไรควรเก็บ อะไรควรทิ้ง ไม่ใช่ยัดประวัติทั้งหมดกลับเข้า context ทุกครั้งจนเกิด context rot
   • Guardrailกติกาที่ควบคุมไม่ให้ agent ทำเกินขอบเขตหรือก่อความเสียหาย เช่น จำกัด tool ที่เรียกได้ ตรวจ output ก่อนส่งออก บังคับ human approval สำหรับการกระทำที่ย้อนกลับไม่ได้ — เป็นสิ่งที่รักษาขอบเขตของ Bounded Context ของ agent ให้ไม่ล้ำเส้น
5. ○05Context Map → multi-agent เป็นข้อยกเว้นที่ต้องมีเหตุผล
   • Context Mapแผนภาพที่วาดทุก Bounded Context และความสัมพันธ์ระหว่างกัน — ในระบบ multi-agent คือแผนภาพที่วาดว่า agent ไหนคุยกับ agent ไหน ใครเป็นต้นน้ำ (กำหนดรูปแบบข้อมูล) ใครเป็นปลายน้ำ ก่อนจะปล่อยให้ agent เรียกกันเองมั่ว ๆ
   • Multi-agentระบบที่มี agent มากกว่าหนึ่งตัวทำงานร่วมกัน แต่ละตัวควรมี Bounded Context ของตัวเองชัดเจนและเชื่อมกันผ่าน context map/handoff ที่ออกแบบไว้ — ไม่ใช่คำตอบสำเร็จรูปสำหรับทุกปัญหา หลายงานทำด้วย agent เดียวหรือ workflow ธรรมดาก็เพียงพอและเชื่อถือได้กว่า
   • Orchestrator-Workersโทโพโลยีที่ agent ตัวหนึ่ง (orchestrator) แตกงานใหญ่เป็นงานย่อยแล้วมอบหมายให้ agent ลูกทีม (worker) แต่ละตัวที่มี Bounded Context แคบและชัดเจนของตัวเอง ก่อนรวมผลลัพธ์กลับ — ต่างจากการปล่อยให้ agent หลายตัวคุยกันเองแบบไม่มีใครคุมภาพรวม
6. ○06Anti-Corruption Layer → ต่อ tool/API ภายนอก
   • Anti-Corruption Layer (ACL)ชั้นแปลภาษา/model ที่กั้นระหว่าง context สองอัน ไม่ให้ model ของอีกฝ่ายรั่วเข้ามาปนเปื้อน — เมื่อ agent เรียก tool หรือ agent อื่นจากภายนอก ควรมีชั้นแปลผลลัพธ์กลับมาเป็นภาษาของ agent เราเอง ไม่ปล่อยให้ schema แปลก ๆ ของฝั่งนู้นไหลเข้ามาปนใน context ของเรา
   • Toolfunction หรือ API ภายนอกที่ agent เรียกใช้ได้เพื่อกระทำสิ่งที่ model ภาษาเองทำไม่ได้ เช่น ค้นเว็บ อ่าน file เรียกฐานข้อมูล — ขอบเขตของชุด tool ที่ agent หนึ่งถืออยู่ก็คือส่วนหนึ่งที่นิยาม Bounded Context ของ agent นั้น ยิ่ง tool set กว้างเกินหน้าที่ ยิ่งเสี่ยงให้ agent ล้ำขอบเขต
7. ○07Integration & handoffs → agent คุยกันยังไง
   • Handoffการส่งต่อการควบคุมบทสนทนา/งานจาก agent หนึ่งไปอีก agent หนึ่งอย่างมีสัญญาชัดเจนว่าส่งอะไรไปพร้อมบริบทเท่าไหร่ — คือจุดที่ Published Language ระหว่าง2 Bounded Context ถูกใช้งานจริง ถ้า handoff ไม่ชัด บริบทจะหายหรือปนกันระหว่างทาง
   • Delegationการที่ agent หนึ่งมอบหมายงานย่อยให้ agent หรือ tool อื่นทำแทน โดยตัวเองยังถือความรับผิดชอบต่อผลลัพธ์รวม ต่างจาก handoff ตรงที่ผู้มอบหมายไม่ได้ปล่อยการควบคุมทั้งหมด แต่รอผลกลับมาประกอบต่อ
   • Published Languageภาษากลางที่เอกสารไว้ชัดเจนสำหรับแลกเปลี่ยนข้อมูลข้าม context — คือ schema ของ tool call ข้อความ handoff และ output format ที่ agent หนึ่งส่งให้อีก agent หนึ่ง ต้องนิ่งและมีสัญญาชัดเจนเหมือน API ระหว่างทีม ไม่ใช่ข้อความธรรมชาติที่ตีความเอาเอง
8. ○08เมื่อไรไม่ควรใช้ agent (+ eval)
   • Evalการวัดผลอย่างเป็นระบบว่า agent ทำงานตรงตามที่ออกแบบไว้จริงหรือไม่ ด้วยชุดกรณีทดสอบและเกณฑ์ที่ชัดเจน แทนการดูจากความรู้สึกว่า 'ตอบดูดี' — จำเป็นเพราะ agentic loop มีความไม่แน่นอนสูงกว่า code ทั่วไป ต้องมี eval ก่อนเชื่อว่า Bounded Context ของ agent ทำงานถูกต้องตามสัญญา
   • Human-in-the-loopการออกแบบให้มนุษย์เข้ามาตรวจสอบหรืออนุมัติในจุดที่การกระทำของ agent มีความเสี่ยงสูงหรือย้อนกลับไม่ได้ เช่น ก่อนโอนเงินหรือลบข้อมูลจริง — เป็น guardrail ชนิดหนึ่งที่ยังจำเป็นแม้ agent จะฉลาดขึ้นเรื่อย ๆ เพราะบางการตัดสินใจไม่ควรปล่อยให้ agent ตัดสินใจเองทั้งหมด
   • Workflow vs Agentความต่างสำคัญที่มักถูกมองข้าม: workflow คือ code ที่กำหนดลำดับขั้นตอนตายตัวไว้ล่วงหน้า (คาดเดาได้ ทดสอบง่าย) ส่วน agent คือระบบที่ตัดสินใจเส้นทางเองแบบไดนามิกผ่าน agentic loop (ยืดหยุ่นกว่าแต่คาดเดายากกว่า) — โจทย์ส่วนใหญ่ไม่ต้องการ agent เต็มรูปแบบ workflow ที่ออกแบบดีมักพอเพียงและเชื่อถือได้กว่า