สรุป 10 ประเภทของ AI Agents: จาก Reactive สู่ Multi-Agent Systems

ทุกวันนี้ AI Agents อยู่รอบตัวเราไปหมดแล้วครับ ไม่ว่าจะเป็น Coding Assistants, รถยนต์ไร้คนขับ, NPC ในเกม หรือระบบ Recommendation ต่างๆ แต่ที่จริงแล้วเอเจนต์แต่ละตัวไม่ได้ถูกสร้างขึ้นมาเหมือนกันซะทีเดียว คำว่า “AI Agent” นั้นครอบคลุมสถาปัตยกรรมที่กว้างมาก ตั้งแต่ตัวควบคุมอุณหภูมิ (Thermostat) ที่แค่ทำงานเมื่ออากาศเย็น ไปจนถึงฝูงเอเจนต์ (Swarm) ที่กำลังเจรจาต่อรองกันแบบ Real-time

การเข้าใจประเภทต่างๆ ของเอเจนต์จะช่วยให้เราเลือกสถาปัตยกรรมที่เหมาะสมกับปัญหาที่เรากำลังแก้ครับ เพราะการใช้ Planning Agent ที่ซับซ้อนมาแก้ปัญหา Automation ง่ายๆ นั้นถือว่าสิ้นเปลืองเกินไป (Over-engineering) ในขณะที่การใช้ Reactive Agent พื้นฐานมาจัดการกับระบบการตัดสินใจที่ซับซ้อนก็อาจจะเปราะบางเกินไป (Under-engineering)

ในโพสต์นี้ ผมขอสรุป 10 ประเภทของ AI Agents ว่าแต่ละแบบทำงานยังไง และนำไปใช้จริงในกรณีไหนได้บ้างครับ

พื้นฐานดั้งเดิม: ประเภทเอเจนต์ของ Russell & Norvig

ก่อนจะลงลึก อยากจะโน้ตไว้นิดนึงครับว่าประเภทของเอเจนต์เหล่านี้ส่วนใหญ่มีต้นกำเนิดมาจากหนังสือเล่มดังอย่าง Artificial Intelligence: A Modern Approach ของ Stuart Russell และ Peter Norvig (บทที่ 2) การแบ่งประเภทของเขา ไม่ว่าจะเป็น Simple Reflex Agents, Model-based Reflex Agents, Goal-based Agents, Utility-based Agents และ Learning Agents ถือเป็นรากฐานที่ชุมชน AI นำมาต่อยอดจนกลายเป็นระบบที่ซับซ้อนในปัจจุบัน

มาลองดูภาพรวมของความซับซ้อนในแต่ละระดับกันครับ:

flowchart LR
    subgraph simple["เรียบง่ายกว่า (Simpler)"]
        direction TB
        A["Reactive Agent"]
        B["Reflex Agent
with Memory"]
    end
    subgraph intermediate["ระดับกลาง (Intermediate)"]
        direction TB
        C["Model-Based Agent"]
        D["Goal-Based Agent"]
        E["Utility-Based Agent"]
    end
    subgraph advanced["ระดับสูง (Advanced)"]
        direction TB
        F["Planning Agent"]
        G["Learning Agent"]
        H["Rational Agent"]
    end
    subgraph specialized["เฉพาะทาง (Specialized)"]
        direction TB
        I["Task-Specific Agent"]
        J["Multi-Agent System"]
    end
    simple --> intermediate --> advanced --> specialized

10 ประเภทของเอเจนต์ (แบบเจาะลึก)

ประเภทที่เรียบง่ายที่สุด Reactive Agent จะตอบสนองต่อ input ปัจจุบันโดยไม่มีหน่วยความจำ (Memory) หรือการเรียนรู้ มันรับรู้สภาพแวดล้อม จับคู่กับกฎที่ตั้งไว้ แล้วก็ลงมือทำทันที ไม่มีประวัติ ไม่มีแผน และไม่มีสถานะภายใน (Internal State)

หลักการทำงาน:

รับ Input จากภายนอก
จับคู่กับกฎ (Rule) ที่กำหนดไว้ล่วงหน้า
เลือกการตอบสนองที่เหมาะสมที่สุด
ประเมินการกระทำที่เป็นไปได้
ลงมือทำ (Execute action)
รอรับ Input ครั้งต่อไป

flowchart LR
    A["Receive
External Input"] --> B["Match with
Predefined Rule"]
    B --> C["Select Best
Match"]
    C --> D["Execute
Action"]
    D --> E["Wait for
Next Input"]
    E --> A

ตัวอย่างในโลกจริง:

หุ่นยนต์ดูดฝุ่นที่หันหลังกลับเมื่อชนกำแพง
เครื่องปรับอากาศที่ทำงานเมื่ออุณหภูมิสูงเกินเกณฑ์
เซนเซอร์เปิดไฟอัตโนมัติเมื่อตรวจพบการเคลื่อนไหว
Chatbot พื้นฐานที่ใช้ตรรกะ if-then ในการตอบ

ควรใช้เมื่อไหร่:

เมื่อต้องการการตอบสนองที่รวดเร็วและคาดเดาได้ในสภาพแวดล้อมที่กำหนดไว้อย่างชัดเจน Reactive Agent ใช้ทรัพยากรน้อยและดูแลรักษาง่าย

ข้อจำกัด:

การไม่มีหน่วยความจำหมายถึงไม่มีการเรียนรู้ เอเจนต์ไม่สามารถปรับตัวเข้ากับสถานการณ์ใหม่ๆ หรือพัฒนาตัวเองเมื่อเวลาผ่านไป หากสภาพแวดล้อมมีความซับซ้อนหรือต้องการบริบทจากอดีต Reactive Agent จะทำงานไม่ได้

เป็นการอัปเกรดจาก Reactive Agent โดยยังคงใช้การตอบสนองตามกฎเหมือนเดิม แต่เพิ่ม **หน่วยความจำ (Memory) ของสถานะในอดีต** เข้ามา ทำให้สามารถตัดสินใจได้ดีขึ้นโดยพิจารณาจากบริบททางประวัติศาสตร์ควบคู่ไปกับ input ปัจจุบัน

หลักการทำงาน:

รับรู้ Input ปัจจุบัน
ตรวจสอบข้อมูลย้อนหลังในหน่วยความจำ
จับคู่กับกฎ (โดยพิจารณาทั้งสถานะปัจจุบันและอดีต)
จัดลำดับความสำคัญตามประสบการณ์ที่ผ่านมา
เลือกทางเลือกที่ดีที่สุด
ลงมือทำ action ที่เลือก

flowchart TD
    A["Sense Current
Input"] --> B["Check
Historical Data"]
    B --> C["Match with Rules
(Current + Past States)"]
    C --> D["Prioritize Based
on Past Experience"]
    D --> E["Choose Best
Option"]
    E --> F["Perform
Selected Action"]
    F --> G["Store in
Memory"]
    G --> A

ตัวอย่างในโลกจริง:

Smart Thermostat ที่ปรับอุณหภูมิตามพฤติกรรมการใช้งานของคุณในสัปดาห์ที่ผ่านมา
ระบบกรองอีเมลขยะ (Spam filter) ที่พัฒนาดีขึ้นตามอีเมลที่คุณเคยทำเครื่องหมายว่าเป็นสแปม
ระบบสัญญาณไฟจราจรที่ใช้ข้อมูลการไหลของรถในช่วงเวลาที่ผ่านมาเพื่อปรับจังหวะไฟ

ควรใช้เมื่อไหร่:

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

ข้อจำกัด:

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

เอเจนต์ประเภทนี้จะสร้างและคงไว้ซึ่ง **โมเดลจำลองโลกภายใน (Internal Model of the World)** มันไม่ได้แค่ตอบสนองต่อสิ่งที่เห็นตอนนี้ แต่มันใช้โมเดลเพื่อทำความเข้าใจว่าโลกทำงานอย่างไร คาดการณ์ผลลัพธ์ และตัดสินใจได้อย่างชาญฉลาดแม้ข้อมูลจากเซนเซอร์จะไม่ครบถ้วน

หลักการทำงาน:

รับรู้สถานะของสภาพแวดล้อม
อัปเดตโมเดลโลกภายใน
จำลองสถานะถัดไปที่เป็นไปได้
ประเมินผลลัพธ์ที่คาดการณ์ไว้
เลือกการกระทำที่ดีที่สุด
ลงมือทำ action

flowchart TD
    A["Percept"] --> B["Sensor Model
(How do my sensors
relate to world state?)"]
    B --> C["Internal Model
(How does the
world work?)"]
    C --> D["Current State
Estimate"]
    D --> E["Condition-Action
Rules"]
    E --> F["Action"]
    F -->|"Transition Model
(How do my actions
affect the world?)"| C

ตัวอย่างในโลกจริง:

รถยนต์ไร้คนขับที่แปลข้อมูลจากเซนเซอร์และคาดการณ์ตำแหน่งของรถคันอื่นในอนาคต
หุ่นยนต์ดูดฝุ่นที่สร้างแผนที่ห้องและวางแผนเส้นทางการทำความสะอาดที่มีประสิทธิภาพ
AI ในวิดีโอเกมที่คาดการณ์การเคลื่อนที่ของผู้เล่น

ควรใช้เมื่อไหร่:

เมื่อสภาพแวดล้อมมีการเปลี่ยนแปลงตลอดเวลา (Dynamic) และรับรู้ได้ไม่ครบถ้วน โมเดลภายในช่วยให้เอเจนต์รับมือกับความไม่แน่นอนและข้อมูลที่ไม่สมบูรณ์ได้อย่างสง่างาม

ข้อจำกัด:

โมเดลจะดีได้เท่ากับข้อสันนิษฐานที่ใช้สร้างมันขึ้นมาเท่านั้น หากโลกจริงต่างจากโมเดล การตัดสินใจจะผิดพลาดทันที นอกจากนี้การสร้างโมเดลที่แม่นยำยังใช้ทรัพยากรการคำนวณสูงมาก

เหนือกว่า Model-based Agent ด้วยการเพิ่ม **เป้าหมาย (Goal)** ที่ชัดเจน แทนที่จะแค่ตอบสนองหรือจำลองโลก เอเจนต์ประเภทนี้จะประเมินการกระทำตามว่าสิ่งนั้นช่วยให้ขยับเข้าใกล้เป้าหมายที่กำหนดไว้หรือไม่

หลักการทำงาน:

รับ Input ปัจจุบัน
ระบุเป้าหมายปัจจุบัน
วางแผนการกระทำที่เป็นไปได้
จำลองเส้นทางสู่เป้าหมาย
เลือกเส้นทางที่เหมาะสมที่สุด
ดำเนินการตามแผน

flowchart TD
    A["Get Current
Input"] --> B["Identify
Current Goal"]
    B --> C["Plan Possible
Actions"]
    C --> D["Simulate
Goal Paths"]
    D --> E{"Does action
move toward goal?"}
    E -->|"Yes"| F["Select
Optimal Path"]
    E -->|"No"| C
    F --> G["Execute
Planned Action"]

ตัวอย่างในโลกจริง:

ระบบนำทาง GPS ที่หาเส้นทางเพื่อไปยังจุดหมายปลายทาง
AI หมากรุกที่ประเมินตาเดินเพื่อนำไปสู่การรุกฆาต (Checkmate)
ระบบ CRM ที่พยายามดึงลูกค้าที่หยุดใช้งานให้กลับมาซื้อซ้ำ

ควรใช้เมื่อไหร่:

เมื่อมีวัตถุประสงค์ที่ชัดเจน และเอเจนต์ต้องวางแผนลำดับการกระทำเพื่อบรรลุเป้าหมายนั้น Goal-based Agent ใช้อัลกอริทึมการค้นหาและวางแผนที่ทำให้ยืดหยุ่นกว่า Reflex หรือ Model-based Agent

ข้อจำกัด:

เป้าหมายมักจะเป็นแบบ Binary (สำเร็จหรือไม่สำเร็จ) เอเจนต์ไม่ได้ถูกออกแบบมาให้จัดการกับการแลกเปลี่ยน (Trade-offs) ระหว่างเป้าหมายที่ขัดแย้งกัน หรือการหาว่าเป้าหมายนั้นสำเร็จ "ดีแค่ไหน" ซึ่งต้องใช้ Utility-based Agent แทน

ต่อยอดจาก Goal-based Agent ด้วยการเพิ่ม **ฟังก์ชันอรรถประโยชน์ (Utility Function)** — ซึ่งเป็นมาตรวัดทางคณิตศาสตร์ว่าผลลัพธ์แต่ละอย่างน่าพึงพอใจแค่ไหน แทนที่จะถามแค่ "ฉันถึงเป้าหมายหรือยัง?" มันจะถามว่า "ผลลัพธ์นี้ดีแค่ไหนเมื่อเทียบกับทางเลือกอื่น?"

หลักการทำงาน:

รับรู้สถานะสภาพแวดล้อม
ลิสต์การกระทำที่เป็นไปได้ทั้งหมด
เปรียบเทียบทางเลือกโดยกำหนดค่าอรรถประโยชน์ (Utility scores)
ประเมินความคุ้มค่าของแต่ละผลลัพธ์
เลือกการกระทำที่ให้ค่าอรรถประโยชน์สูงสุด
ลงมือทำ

flowchart TD
    A["Sense Environment
State"] --> B["List Possible
Actions"]
    B --> C["Action A"]
    B --> D["Action B"]
    B --> E["Action C"]
    C --> F["Utility = 0.7"]
    D --> G["Utility = 0.9"]
    E --> H["Utility = 0.4"]
    F --> I["Compare
All Utilities"]
    G --> I
    H --> I
    I --> J["Choose Max
Utility: Action B"]
    J --> K["Execute"]

ตัวอย่างในโลกจริง:

รถยนต์ไร้คนขับที่ปรับสมดุลระหว่างความเร็ว ความปลอดภัย ความประหยัดน้ำมัน และความสบายของผู้โดยสาร
ระบบแนะนำคอนเทนต์ (Recommendation Engine) ที่จัดอันดับตามความพึงพอใจที่คาดการณ์ไว้ของผู้ใช้
ระบบจัดการพลังงานที่ปรับสมดุลระหว่างต้นทุน ความสะดวกสบาย และผลกระทบต่อสิ่งแวดล้อม
ระบบวินิจฉัยทางการแพทย์ที่แนะนำการรักษาตามผลประโยชน์ที่คาดหวังต่อคนไข้

ควรใช้เมื่อไหร่:

เมื่อมีวัตถุประสงค์ที่ขัดแย้งกันหลายอย่างและเอเจนต์ต้องตัดสินใจแลกเปลี่ยน Utility-based Agent เก่งมากในเรื่องการเพิ่มประสิทธิภาพสูงสุดภายใต้ความไม่แน่นอน (Optimization under uncertainty)

ข้อจำกัด:

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

เอเจนต์ที่ **พัฒนาตัวเองได้เมื่อเวลาผ่านไป** โดยการเรียนรู้จากประสบการณ์ Russell และ Norvig นิยามส่วนประกอบสำคัญ 4 อย่าง: **Performance element** (ลงมือทำ), **Critic** (ประเมินผล), **Learning element** (ปรับเปลี่ยนพฤติกรรม) และ **Problem generator** (เสนอการทดลองใหม่ๆ)

หลักการทำงาน:

รับ Input ใหม่
ประเมินการกระทำก่อนหน้า (ผ่าน Critic)
ปรับโมเดลภายใน (Learning element)
อัปเดตกลยุทธ์การตัดสินใจ
เลือกการกระทำที่ดีที่สุด
เก็บผลลัพธ์เพื่อการเรียนรู้ในอนาคต

flowchart TD
    E["Environment"] --> S["Sensors"]
    S --> PE["Performance
Element"]
    PE --> A["Actuators"]
    A --> E
    S --> C["Critic"]
    C -->|"Feedback"| LE["Learning
Element"]
    LE -->|"Changes"| PE
    PG["Problem
Generator"] -->|"Experiments"| PE
    LE -->|"Goals"| PG

ตัวอย่างในโลกจริง:

AlphaGo ที่เรียนรู้จากเกมหลายล้านเกมเพื่อเป็นสุดยอดฝีมือโกะ
ระบบแนะนำสินค้าที่ขัดเกลาคำแนะนำตามการคลิกและการให้คะแนนของผู้ใช้
ระบบตรวจจับการฉ้อโกงที่ปรับตัวตามพฤติกรรมการโกงรูปแบบใหม่ๆ
โมเดลภาษา (LLM) ที่ถูก Fine-tune ด้วยมนุษย์ (RLHF)

ควรใช้เมื่อไหร่:

เมื่อสภาพแวดล้อมมีความซับซ้อน เปลี่ยนแปลงตลอดเวลา หรือไม่เป็นที่เข้าใจอย่างถ่องแท้ตั้งแต่ต้น Learning Agent เป็นประเภทเดียวที่สามารถพัฒนาได้จริงโดยไม่ต้องเขียนโปรแกรมใหม่

ข้อจำกัด:

การเรียนรู้ต้องใช้ข้อมูล และข้อมูลที่แย่ก็นำไปสู่การเรียนรู้ที่แย่ นอกจากนี้ยังมีเรื่องของ Exploration-Exploitation trade-off คือเอเจนต์ต้องรักษาสมดุลระหว่างการลองสิ่งใหม่ๆ (Exploration) กับการทำสิ่งที่รู้ว่าได้ผลดีอยู่แล้ว (Exploitation)

Rational Agent จะเลือก **การกระทำที่เหมาะสมที่สุดตามตรรกะเสมอ** เมื่อพิจารณาจากความรู้และความสามารถที่มี คำว่า "Rational" ไม่ได้หมายความว่าต้องรู้ทุกอย่าง (Omniscient) แต่หมายถึงการตัดสินใจที่ดีที่สุดเท่าที่จะทำได้ด้วยข้อมูลที่มีอยู่ในมือ

หลักการทำงาน:

วิเคราะห์สภาพแวดล้อมทั้งหมด
ลิสต์ทางเลือกที่มีอยู่ทั้งหมด
ประมาณการผลลัพธ์ของแต่ละทางเลือก
เลือกการกระทำที่เหมาะสมที่สุด (Optimal)
ดำเนินการตามที่เลือก
ประเมินประสิทธิภาพ

flowchart TD
    A["Analyze Full
Environment"] --> B["List All
Available Options"]
    B --> C["Estimate Outcomes
for Each Option"]
    C --> D["Choose Optimal
Action"]
    D --> E["Execute
Choice"]
    E --> F["Evaluate
Performance"]
    F -->|"Performance
Measure"| A

ตัวอย่างในโลกจริง:

ระบบเทรดหุ้นอัตโนมัติที่เพิ่มผลตอบแทนพอร์ตโฟลิโอสูงสุดตามข้อมูลตลาด
ตัวคำนวณโลจิสติกส์ที่หาเส้นทางการจัดส่งที่มีประสิทธิภาพสูงสุด
เอเจนต์ใดๆ ที่ออกแบบมาเพื่อเพิ่มมาตรวัดประสิทธิภาพ (Performance measure) ให้สูงสุด

ควรใช้เมื่อไหร่:

เมื่อคุณสามารถนิยามคำว่า "Optimal" (เหมาะสมที่สุด) ได้ชัดเจนด้วยมาตรวัดประสิทธิภาพ และเอเจนต์มีข้อมูลเพียงพอที่จะให้เหตุผลเกี่ยวกับมัน

ข้อจำกัด:

ความเป็นเหตุเป็นผล (Rationality) ถูกจำกัดด้วยพลังการคำนวณและข้อมูล ในทางปฏิบัติเอเจนต์มักจะต้อง "Satisfice" (เลือกการกระทำที่ "ดีพอ") แทนที่จะคำนวณหาสิ่งที่เหมาะสมที่สุดจริงๆ โดยเฉพาะในสภาพแวดล้อมที่มีข้อจำกัดเรื่องเวลา ซึ่งนี่คือสิ่งที่ Herbert Simon เรียกว่า "Bounded Rationality"

เอเจนต์ที่ถูกสร้างขึ้นเพื่อ **งานเฉพาะเจาะจงเพียงอย่างเดียว** แทนที่จะเป็นเอเจนต์ทั่วไป มันจะมีเครื่องมือ คำแนะนำ และตรรกะที่ออกแบบมาเพื่อโดเมนนั้นๆ โดยเฉพาะ เช่น การเขียน, การสรุปความ, การรีวิวโค้ด, การวิเคราะห์ข้อมูล เป็นต้น

หลักการทำงาน:

รับ Input เฉพาะทาง
ระบุประเภทของงาน
ประมวลผลโดยใช้ตรรกะเฉพาะโดเมน
เรียกใช้เครื่องมือที่จำเป็น
ส่งออกผลลัพธ์ในรูปแบบที่กำหนด
บันทึกการทำงานสำเร็จ

flowchart LR
    A["Receive
Specific Input"] --> B["Identify
Task Type"]
    B --> C["Process Using
Domain Logic"]
    C --> D["Fetch Required
Tools"]
    D --> E["Return Formatted
Output"]
    E --> F["Log Task
Completion"]

ตัวอย่างในโลกจริง:

GitHub Copilot (การเติมโค้ด)
Grammarly (การแก้ไขการเขียน)
CI/CD Bot ที่รันเทสและรายงานผล
Claude Code skills (แต่ละ skill คือ Task-specific agent)

ควรใช้เมื่อไหร่:

เมื่อต้องการความแม่นยำและความน่าเชื่อถือสูงสำหรับงานที่กำหนดไว้ชัดเจน การจำกัดขอบเขตช่วยให้คุณปรับแต่งเครื่องมือ Prompt และ Guardrails ของเอเจนต์ให้เหมาะสมที่สุดสำหรับโดเมนนั้น

ข้อจำกัด:

ไม่มีความสามารถรอบด้าน (Generality) เอเจนต์ที่ทำหน้าที่รีวิวโค้ดไม่สามารถเขียนอีเมลได้ คุณต้องมีเอเจนต์แยกกันสำหรับงานที่ต่างกัน (หรือใช้ Multi-agent system ในการรวบรวมพวกมัน)

เอเจนต์ที่เน้นการสร้าง **แผนระยะยาว** มากกว่าการตอบสนองทันที มันจะย่อยเป้าหมายที่ซับซ้อนให้กลายเป็นแผนงานทีละขั้นตอน (Sub-tasks) ประเมินเส้นทาง และตรวจสอบการดำเนินการ — พร้อมปรับเปลี่ยนแผนเมื่อสถานการณ์เปลี่ยนไป

หลักการทำงาน:

ระบุเป้าหมายสุดท้าย
ย่อยขั้นตอนที่เป็นไปได้
สร้างแผนการกระทำ (Action plan)
ประเมินแต่ละเส้นทาง
ดำเนินการทีละขั้นตอน
ติดตามผลและปรับปรุงแผน

flowchart TD
    A["Complex Goal"] --> B["Task Decomposition"]
    B --> C["Sub-goal 1"]
    B --> D["Sub-goal 2"]
    B --> E["Sub-goal 3"]
    C --> F["Plan Steps"]
    D --> G["Plan Steps"]
    E --> H["Plan Steps"]
    F --> I["Execute & Monitor"]
    G --> I
    H --> I
    I -->|"Replan if needed"| B

ตัวอย่างในโลกจริง:

AI Coding Agent ที่ย่อยงาน "สร้าง REST API พร้อม Auth" เป็นงานย่อย: วางโครงโปรเจกต์, สร้างโมเดล, เพิ่ม Route, ทำ JWT, เขียน Test
หุ่นยนต์ในคลังสินค้าที่วางแผนลำดับการหยิบและวางของ
Agentic AI patterns ของ Andrew Ng ซึ่งการวางแผนถูกระบุว่าเป็นรูปแบบการออกแบบที่สำคัญที่ LLM ตัดสินใจลำดับการกระทำเอง

ควรใช้เมื่อไหร่:

สำหรับงานที่ซับซ้อนและมีหลายขั้นตอน ซึ่งการตอบสนองทันทีนั้นไม่เพียงพอ Planning Agent จะโดดเด่นมากเมื่อต้องประสานงานหลายการกระทำในลำดับที่เฉพาะเจาะจง

ข้อจำกัด:

การวางแผนใช้เวลาและพลังการคำนวณ ในสภาพแวดล้อมที่รวดเร็ว (เช่น การขับรถ หรือการประมูลแบบ Real-time) ความล่าช้าจากการวางแผนอาจเป็นปัญหาได้ และแผนอาจจะล้าสมัยหากสภาพแวดล้อมเปลี่ยนเร็วกว่าที่เอเจนต์จะวางแผนใหม่ได้ทัน

ไม่ใช่แค่เอเจนต์ตัวเดียว แต่เป็น **ระบบของเอเจนต์หลายตัว (System of multiple agents)** ที่ทำงานร่วมกัน — ไม่ว่าจะร่วมมือกัน แข่งขันกัน หรือเจรจากัน — เพื่อแก้ปัญหาที่ซับซ้อนเกินกว่าที่เอเจนต์ตัวเดียวจะรับมือได้

หลักการทำงาน:

สังเกตสภาพแวดล้อมที่ใช้ร่วมกัน
สื่อสารกับเอเจนต์ตัวอื่น
เจรจาเป้าหมายร่วมกัน
แชร์ความรู้เฉพาะส่วน
ทำหน้าที่ตามบทบาทที่ได้รับมอบหมาย
อัปเดตสถานะของระบบ

flowchart TD
    ENV["Shared Environment"] --> A1["Agent 1
(Writer)"]
    ENV --> A2["Agent 2
(Reviewer)"]
    ENV --> A3["Agent 3
(Tester)"]
    A1 <-->|"Communicate"| A2
    A2 <-->|"Communicate"| A3
    A1 <-->|"Communicate"| A3
    A1 --> R1["Write Code"]
    A2 --> R2["Review Code"]
    A3 --> R3["Run Tests"]
    R1 --> OUT["Combined
System Output"]
    R2 --> OUT
    R3 --> OUT

ตัวอย่างในโลกจริง:

ทีม AI Coding Agents ที่ตัวหนึ่งเขียนโค้ด อีกตัวรีวิว และอีกตัวเขียนเทส
Swarm robotics (หุ่นยนต์ฝูงบินที่ประสานงานกันในภารกิจค้นหาและกู้ภัย)
แบบจำลองตลาดการเงินที่มีเอเจนต์ผู้ซื้อและผู้ขาย
เครือข่ายเซนเซอร์แบบกระจายตัวที่แชร์ข้อมูลเพื่อสร้างภาพรวมระดับโลก
Framework อย่าง CrewAI, AutoGen และ LangGraph

ควรใช้เมื่อไหร่:

เมื่อปัญหามีขนาดใหญ่เกินไปหรือกระจายตัวเกินกว่าเอเจนต์เดียวจะจัดการได้ Multi-agent system ช่วยให้ทำงานขนานกันได้ (Parallel processing) มีความเชี่ยวชาญเฉพาะทาง (Specialization) และมีความทนทาน (Resilience) หากตัวหนึ่งพัง ตัวอื่นก็ทำงานแทนได้

ข้อจำกัด:

การประสานงานนั้นยากมาก (Coordination overhead) ทั้งเรื่องการสื่อสาร เป้าหมายที่อาจขัดแย้งกันเอง และพฤติกรรมแปลกๆ ที่คาดไม่ถึงที่อาจเกิดขึ้นได้ การดีบั๊ก Multi-agent system นั้นยากกว่าเอเจนต์เดียวอย่างมหาศาล

ตารางเปรียบเทียบ

ประเภท	มีหน่วยความจำ (Memory)	เรียนรู้ได้ (Learning)	วางแผนได้ (Planning)	เหมาะสำหรับ
Reactive	No	No	No	การตอบสนองที่เรียบง่ายและรวดเร็ว
Reflex + Memory	Yes	No	No	การตอบสนองที่ต้องใช้บริบท
Model-Based	Yes	No	Partial	สภาพแวดล้อมที่รับรู้ได้บางส่วน
Goal-Based	Yes	No	Yes	การไล่ตามเป้าหมายที่ชัดเจน
Utility-Based	Yes	No	Yes	การเพิ่มประสิทธิภาพหลายเป้าหมาย
Learning	Yes	Yes	Varies	การพัฒนาตัวเองเมื่อเวลาผ่านไป
Rational	Varies	Varies	Yes	การตัดสินใจที่สมเหตุสมผลที่สุด
Task-Specific	Varies	Varies	Varies	งานเฉพาะทางในโดเมนที่จำกัด
Planning	Yes	Varies	Yes	งานซับซ้อนที่มีหลายขั้นตอน
Multi-Agent	Yes	Varies	Yes	ปัญหาระดับใหญ่ที่ต้องกระจายงาน

วิธีเลือกประเภทเอเจนต์ที่ใช่

ไม่มีคำว่า “ดีที่สุด” เพียงหนึ่งเดียวครับ ทุกอย่างขึ้นอยู่กับโจทย์ที่คุณกำลังแก้:

สภาพแวดล้อมเรียบง่ายและกำหนดไว้ชัดเจน? เริ่มด้วย reactive agent ก็พอ อย่า Over-engineer
ต้องการบริบทจากการปฏิสัมพันธ์ในอดีต? เพิ่ม Memory เข้าไป — ใช้ reflex agent with memory หรือ model-based agent
มีเป้าหมายที่ชัดเจนต้องทำให้สำเร็จ? ใช้ goal-based agent
มีเป้าหมายหลายอย่างที่ขัดแย้งกันและต้องเลือกทางที่ดีที่สุด? ใช้ utility-based agent
งานซับซ้อนที่มีหลายขั้นตอนต้องทำตามลำดับ? ใช้ planning agent
สภาพแวดล้อมเปลี่ยนไปเรื่อยๆ และคุณต้องการการปรับตัว? ใช้ learning agent
มีหนึ่งโดเมนเฉพาะที่ต้องการ Optimize ให้ดีที่สุด? ใช้ task-specific agent
ปัญหาใหญ่เกินกว่าเอเจนต์ตัวเดียวจะรับไหว? ใช้ multi-agent system

ในทางปฏิบัติ ระบบ AI ในระดับ Production ส่วนใหญ่มักจะเป็น แบบผสม (Hybrids) ครับ เช่น รถยนต์ไร้คนขับจะรวมทั้งส่วนที่เป็น Reactive (การเบรกฉุกเฉิน), การให้เหตุผลแบบ Model-based (การคาดการณ์การจราจร), การตัดสินใจแบบ Utility-based (การรักษาสมดุลความเร็วและความปลอดภัย) และการเรียนรู้แบบ Learning (การปรับปรุงจากข้อมูลการขับขี่จริง) ศิลปะคือการรู้ว่าควรใช้สถาปัตยกรรมไหนกับส่วนใดของระบบครับ

References: