Model Context Protocol, Multi-Agent Systems, LangGraph, CrewAI — AI ที่ทำงานเองได้
Agentic AI = AI ที่สามารถ วางแผน → ตัดสินใจ → ลงมือทำ → ตรวจสอบ ได้ด้วยตัวเอง
AI แบบเดิม: เหมือนพนักงานที่ต้องถามคุณทุกครั้งว่า "ทำขั้นตอนต่อไปได้ไหม?"
Agentic AI: เหมือนพนักงานที่คุณบอกว่า "จัดทำรายงานให้เสร็จ" แล้วเขาก็ไปวางแผน หาข้อมูล เขียน ตรวจสอบ และส่งให้คุณเอง — ถามกลับมาเฉพาะเมื่อติดปัญหาจริงๆ
| แบบเดิม (Chat) | Agentic AI (2026) |
|---|---|
| ถาม 1 คำถาม → ได้ 1 คำตอบ | ให้เป้าหมาย → AI ทำจนเสร็จ |
| ต้องสั่งทีละขั้น | AI วางแผนเอง |
| ไม่ใช้เครื่องมือ | ใช้ Tools (search, code, API) |
| ไม่ตรวจสอบตัวเอง | Self-check & iterate |
MCP (Model Context Protocol) คือมาตรฐานเปิดสำหรับเชื่อมต่อ AI กับ Tools และ Data sources แบบ universal — เปรียบเหมือน "USB-C สำหรับ AI"
เริ่มต้นโดย Anthropic (ปลายปี 2024) และได้รับการสนับสนุนเป็นมาตรฐานเปิดในวงกว้าง — ผู้ให้บริการรายใหญ่ (OpenAI, Google, AWS, Microsoft) ทยอยรองรับในปี 2025–2026
🎯 ทำไมต้องรู้: เหมือนก่อนมี USB-C ทุกอุปกรณ์ใช้สายชาร์จคนละแบบ — MCP ทำให้ AI ทุกยี่ห้อสามารถเชื่อมต่อกับเครื่องมือต่างๆ ได้โดยไม่ต้องพัฒนา connector แยกสำหรับแต่ละ AI
| Primitive | คำอธิบาย | ตัวอย่าง |
|---|---|---|
| Resources | ข้อมูลที่ AI อ่านได้ | Files, Database records, API responses |
| Tools | ฟังก์ชันที่ AI เรียกใช้ได้ | search(), query_db(), send_email() |
| Prompts | Template สำหรับ interaction | Pre-built prompt flows |
| มิติ | MCP | Function Calling |
|---|---|---|
| มาตรฐาน | เปิด, universal (ทุก AI/tool ใช้ได้) | provider-specific (OpenAI, Anthropic ต่างกัน) |
| ความยืดหยุ่น | เปลี่ยน AI model โดยไม่ต้องแก้ tools | ต้องแก้ integration ทุกครั้งที่เปลี่ยน model |
| ตลาด tools | ecosystem เติบโตเร็ว มี server/tool สำเร็จรูปจำนวนมาก | จำกัดในระบบของ provider |
| เหมาะกับ | production, long-term, multi-model | prototype เร็ว, single-provider system |
เริ่มด้วย Function Calling ถ้าต้องการ prototype เร็ว → migrate เป็น MCP เมื่อต้องการ production-grade และ model portability
| Protocol | Provider | จุดประสงค์ | สถานะ 2026 |
|---|---|---|---|
| MCP | Anthropic (มาตรฐานเปิด) | AI ↔ Tools/Data | ได้รับการรองรับในวงกว้าง |
| A2A | Agent ↔ Agent (ข้ามระบบ) | มีพาร์ทเนอร์หลายราย | |
| ANP | Community | Agent Network (large scale) | Early stage |
| # | Pattern | คำอธิบาย | เหมาะกับ |
|---|---|---|---|
| 1 | Tool Use | AI เรียกใช้เครื่องมือ | งานที่ต้องข้อมูลภายนอก |
| 2 | ReAct | Think → Act → Observe → Repeat | งานค้นหา/วิจัย |
| 3 | Planning | วางแผนก่อนทำ | งานซับซ้อนหลายขั้นตอน |
| 4 | Reflection | ทำ → ประเมินตัวเอง → ปรับปรุง | งานที่ต้องการคุณภาพสูง |
| 5 | Multi-Agent | หลาย Agent ทำงานร่วมกัน | งานหลายความเชี่ยวชาญ |
| 6 | Orchestrator-Worker | 1 สั่ง, หลายตัวทำ | งานขนาดใหญ่ |
| 7 | Evaluator-Optimizer | สร้าง → ประเมิน → ปรับ → วนซ้ำ | งาน Creative/Writing |
| 8 | Debate | หลาย Agent ถกเถียง → Judge ตัดสิน | การตัดสินใจสำคัญ |
| Framework | ประเภท | จุดแข็ง | เหมาะกับ |
|---|---|---|---|
| OpenAI Agents SDK | Official | Simple, GPT-5.5 integration | เริ่มต้น, Quick prototype |
| LangGraph | Graph-based | State management, Complex flows | Production, Regulated env |
| CrewAI | Role-based | Intuitive, Fast prototype | Multi-agent, Team simulation |
| Dapr Agents | Cloud-native | Kubernetes, Enterprise | Enterprise production |
| Mastra | TypeScript | Type-safe, Modern DX | TypeScript teams |
| n8n | No-code | Visual, Self-hosted | Non-technical, Automation |
DSPy (Declarative Self-improving Python) คือ framework ที่แทนที่การเขียน prompt ด้วยมือ โดยให้ AI เรียนรู้จาก input/output examples แล้วสร้าง prompt ที่ดีที่สุดเอง — เหมาะเมื่อมี training examples ที่ชัดเจนและต้องการลด manual prompt tuning
DSPy ต่างจาก Prompt Engineering ปกติ — แทนที่จะบอก AI ว่า "ตอบแบบนี้" ให้บอกว่า "Input นี้ควรได้ Output นี้" แล้วให้ DSPy หา prompt เอง | เรียนละเอียด: Module 11
| Metric | ความหมาย | เป้าหมาย / สัญญาณปัญหา |
|---|---|---|
| Task Success Rate | % ของงานที่ได้ผลลัพธ์ผ่านเกณฑ์โดยไม่ต้องแก้ซ้ำ | >80% = ดี | <50% = prompt/agent ต้องปรับ |
| QA Rounds (รอบแก้ไข) | จำนวนครั้งที่ Reviewer ส่งกลับแก้ก่อนผ่าน | <2 รอบ = ดี | >5 รอบ = scope หรือ constraints ไม่ชัด |
| Token Cost per Result | จำนวน token เฉลี่ยต่อผลลัพธ์ที่ผ่าน QA | ลดได้ด้วย Compress/Select | สูงผิดปกติ = context ฟุ่มเฟือย |
| Stability (ความเสถียร) | ผลลัพธ์สม่ำเสมอเมื่อเปลี่ยน model version | ควรทดสอบทุก model upgrade | ถ้า unstable = prompt ยึดติด model-specific feature |
เก็บ metrics ทุกครั้งที่รัน — ถ้า QA Rounds > 3 บ่อยๆ ให้กลับไปปรับ Constraints หรือ Fallback Rules ก่อนปรับ model
Pattern 3 บทบาทนี้ใช้ได้กับ Single-session prompting ไม่ต้องตั้ง multi-agent system จริง — เหมาะเป็นจุดเริ่มต้นก่อน build full agentic system
[Planner] เป้าหมาย: [Goal] แตกงานเป็น [3-7] งานย่อย พร้อมลำดับและเกณฑ์ผ่านแต่ละขั้น เกณฑ์ผ่านรวม: [define — เช่น ทุกข้อต้องมีหลักฐานอ้างอิง] [Worker] ทำงานย่อยทีละข้อ รอคำสั่ง "ต่อ" ก่อนขึ้นข้อถัดไป ส่งผลลัพธ์ในรูปแบบ: งานย่อย | ผลลัพธ์ | ความเสี่ยง | สิ่งที่ต้องการเพิ่ม [Reviewer] หลังได้ผลครบทุกข้อ ตรวจ: - ครบถ้วนตามเป้าหมาย? - ตัวเลข/ข้อมูลสอดคล้องกัน? - ผลลัพธ์เป็นไปได้จริง? ถ้าไม่ผ่าน: ระบุ feedback รายข้อ และสั่งแก้เฉพาะจุด รูปแบบส่งมอบสุดท้าย: 1) Final Output 2) QA Report (สรุปจุดที่ตรวจและผลการตรวจ) 3) Next Actions (สิ่งที่ต้องทำต่อ)
เริ่มจาก [Worker] รอ → แล้วค่อยขึ้น [Reviewer] — การแยก 2 รอบนี้ดีกว่าให้ AI ทำและตรวจในคำสั่งเดียว เพราะช่วยให้ตรวจจับข้อผิดพลาดได้มากกว่า
[Planner] เป้าหมาย: จัดทำแผนปราบปรามเครือข่ายหลอกลวงออนไลน์ ไตรมาส 3/2568 แตกงาน 5 ขั้นตอน: 1. รวบรวมสถิติคดีออนไลน์ ไตรมาส 1-2 (จำนวน มูลค่า ประเภท) 2. วิเคราะห์ MO ที่พบบ่อยสุด 5 อันดับ 3. ระบุพื้นที่/ช่องทางเสี่ยงสูง 4. เสนอมาตรการเชิงรุก 5 ข้อ พร้อมงบประมาณโดยประมาณ 5. ร่าง KPI วัดผลสำเร็จ 4 ข้อ เกณฑ์ผ่าน: ทุกข้อต้องอ้างอิงข้อมูลจริง ห้ามเดา [Worker] ทำทีละข้อ ส่งผลลัพธ์รูปแบบ: งานย่อย | ผลลัพธ์ | ความเสี่ยง | สิ่งที่ต้องการเพิ่ม เริ่มข้อ 1 ก่อน รอ "ต่อ" ก่อนขึ้นข้อถัดไป [Reviewer] ตรวจหลังได้ผลครบ: - ตัวเลขสถิติสอดคล้องระหว่างข้อ 1-2? - มาตรการข้อ 4 เป็นไปได้จริงในงบที่มี? - KPI ข้อ 5 วัดผลได้จริง? ถ้าไม่ผ่าน ให้ feedback รายข้อ สั่งแก้เฉพาะจุด รูปแบบส่งมอบ: 1) แผนปฏิบัติการฉบับสมบูรณ์ 2) QA Report: คะแนนแต่ละส่วน + ประเด็นที่แก้แล้ว 3) Next Actions: ขั้นตอนที่ต้องขออนุมัติผู้บังคับบัญชา
# Agent: [ชื่อ Agent] # Role: [บทบาท] # Version: 1.0 ## Identity คุณเป็น [บทบาท] ที่เชี่ยวชาญ [ความเชี่ยวชาญ] ## Capabilities คุณสามารถ: 1. [ความสามารถ 1] 2. [ความสามารถ 2] 3. [ความสามารถ 3] ## Tools Available - tool_name: คำอธิบาย - tool_name: คำอธิบาย ## Workflow 1. รับ task จาก user/orchestrator 2. วางแผนขั้นตอน 3. ดำเนินการทีละขั้น (ใช้ tools ตามจำเป็น) 4. ตรวจสอบผลลัพธ์ 5. ส่งผลลัพธ์กลับ ## Constraints - [ข้อจำกัด] - หากไม่แน่ใจ ให้ถามก่อนทำ ## Output Format [กำหนดรูปแบบ]
Planner/Worker/Reviewer (9.7.1) เพียงพอสำหรับงานส่วนใหญ่ แต่เมื่องานยาวและซับซ้อนขึ้น การใช้ Agent ตัวเดียวทำทุกอย่างจะทำให้คุณภาพลดลง (context ยาวเกิน, ปนบทบาท, ตรวจงานตัวเองไม่เห็นจุดบอด)
เหตุผล: ยิ่งขั้นตอนเยอะ context ยิ่งยาว โอกาสที่ Agent จะลืมเงื่อนไขต้นทางหรือปนบทบาทยิ่งสูง การแยกบทบาทช่วยให้แต่ละตัว "โฟกัสแคบ ทำได้ลึก"
เมื่อต้องแตกทีม Multi-Agent จริง ให้จัดโครงสร้างตาม 7 บทบาทมาตรฐาน — แต่ละบทบาทมีหน้าที่เดียวชัดเจน ลดการทับซ้อนและช่องโหว่
| # | บทบาท | หน้าที่หลัก | ส่งต่อให้ |
|---|---|---|---|
| 1 | Researcher (นักวิจัย) | รวบรวมข้อมูล/ค้นหาข้อเท็จจริงจากแหล่งต่างๆ | Drafter |
| 2 | Drafter (ผู้ร่าง) | สร้างผลลัพธ์ฉบับแรกจากข้อมูลที่ได้ | Auditor |
| 3 | Auditor (ผู้ตรวจสอบ) | ตรวจข้อเท็จจริง/ตัวเลข/ความถูกต้องเชิงเทคนิค | Reviewer |
| 4 | Reviewer (ผู้ทบทวน) | ตรวจคุณภาพรวม โทน ความครบถ้วนตามเป้าหมาย | Deployer / Router |
| 5 | Deployer (ผู้ส่งมอบ) | จัดรูปแบบสุดท้าย ส่งมอบ/เผยแพร่ผลลัพธ์ | ผู้ใช้/ระบบปลายทาง |
| 6 | Router (ผู้คัดแยก) | ตัดสินว่างานควรไปบทบาท/สายไหนต่อ | บทบาทที่เหมาะสม |
| 7 | Escalator (ผู้ส่งต่อ) | ยกงานที่เกินขอบเขต/มีความเสี่ยงสูงให้มนุษย์ | Human-in-the-Loop |
8 Patterns = "รูปแบบการทำงาน" (เช่น ReAct, Reflection) ส่วน 7 Roles = "การแบ่งหน้าที่ในทีม" — ใช้ร่วมกันได้ เช่น Auditor ภายในใช้ Reflection, Router ใช้ Planning
จุดที่ Multi-Agent พังบ่อยที่สุดคือ "การส่งต่องาน" — ถ้าส่งเป็นข้อความยาวๆ Agent ปลายทางจะตีความพลาด ต้องส่งในรูปแบบ structured (JSON) ที่ตายตัว เพื่อให้ทุกตัวอ่านตรงกัน
// ทุก Agent ต้องส่งมอบงานในรูปแบบนี้เท่านั้น (ห้ามส่งเป็นข้อความยาว)
{
"from_role": "Drafter",
"to_role": "Auditor",
"task_id": "case-2026-0731",
"status": "completed", // completed | needs_revision | escalate
"payload": {
"result": "<ผลลัพธ์ที่ทำเสร็จ>",
"assumptions": ["สมมติฐานที่ใช้ ..."],
"sources": ["อ้างอิง/แถวข้อมูลที่ใช้ ..."]
},
"open_questions": ["จุดที่ยังไม่แน่ใจ ต้องให้ผู้รับตรวจ"],
"confidence": "medium", // high | medium | low
"next_action": "ตรวจตัวเลขในตาราง X กับแหล่งอ้างอิง"
}
status = "escalate" หรือ confidence = "low" ในงานผลกระทบสูง → ส่งเข้า Escalator ให้มนุษย์ตัดสินneeds_revision พร้อมระบุ field ที่ขาด| # | ❌ ข้อผิดพลาด | ✅ วิธีที่ถูกต้อง |
|---|---|---|
| 1 | ให้ Agent ทำงานทั้งหมดในครั้งเดียว → loop ไม่สิ้นสุด หรือ ผลลัพธ์ไม่ตรงต้องการ | แบ่งงานเป็น Planner/Worker/Reviewer และมี max_iterations limit |
| 2 | System Prompt ไม่ชัด → Agent เดาเองว่าต้องใช้ tool ไหน | ระบุชัด: "มี tools อะไรบ้าง", "ใช้เมื่อไหร่", "output format อย่างไร" |
| 3 | ไม่มี Fallback → Agent ติดเมื่อ tool error หรือข้อมูลไม่พอ | ระบุ Fallback Rules เช่น "ถ้า tool fail ให้ขอข้อมูลเพิ่ม ไม่ใช่เดา" |
| 4 | ไม่วัด metrics → ไม่รู้ว่า agent ทำงานดีแค่ไหน | วัด Success Rate, QA Rounds, Token Cost ทุกครั้งที่รัน |
| 5 | Planner/Worker ทำพร้อมกัน → ข้ามขั้น QA → ผลลัพธ์มี error | แยกเป็น 2 รอบ: Worker รอ → Reviewer ตรวจ → กลับไปแก้ถ้า fail |
| 6 | ใช้ MCP โดยไม่เข้าใจ 3 Primitives → integrate ผิด | เข้าใจก่อนว่า Resources (data) / Tools (actions) / Prompts (templates) ต่างกันอย่างไร |
| 7 | QA Rounds > 5 บ่อยๆ → Constraints หรือ Scope ไม่ชัด | ถ้าเกิดซ้ำ กลับไปปรับ Constraints/Fallback ไม่ใช่ปล่อยให้ agent retry ต่อ |
โจทย์: มีงาน 3 อย่าง:
ควรใช้ pattern/framework ไหน?