ประเภทของ AI agent มีอะไรบ้าง สรุปครบทุกรูปแบบการทำงาน

ประเภทของ AI agent

ประเภทของ AI agent มาจากอนุกรมวิธานชุดเดียว ได้แก่ simple reflex, model-based reflex, goal-based, utility-based และ learning agents ชื่อแต่ละชื่ออธิบายสิ่งเดียวคือ agent จดจำข้อมูลได้มากน้อยเพียงใดและวางแผนล่วงหน้าไกลแค่ไหนก่อนที่จะดำเนินการ นอกจากนี้ยังมีอีกสองคำคือ multi-agent และ hierarchical ซึ่งอธิบายถึงวิธีการเชื่อมโยง agent หลายตัวเข้าด้วยกัน แทนที่จะอธิบายว่า agent ตัวใดตัวหนึ่งตัดสินใจอย่างไร

รายการดังกล่าวเก่าแก่กว่าทุกโมเดลที่คุณเคยใช้งาน มันมาจากตำรามาตรฐานด้าน AI และยังคงอยู่รอดมาได้หลังจากการมาถึงของ large language models เพราะมันตั้งคำถามที่ยังคงเป็นตัวตัดสินการออกแบบของคุณว่า: สิ่งนี้จำเป็นต้องรู้อะไรบ้างก่อนที่จะดำเนินการ หากคุณยังคงแยกไม่ออกว่าจุดสิ้นสุดของ agent และจุดเริ่มต้นของ chat assistant อยู่ตรงไหน ให้อ่าน ความแตกต่างระหว่าง AI agent กับ LLM ที่รันอยู่ ก่อน หน้านี้คือจุดเริ่มต้นหลังจากบรรทัดนั้น

Simple reflex agents: เงื่อนไขเดียว การกระทำเดียว

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

คุณคงเคยใช้งานเอเจนต์ประเภทนี้มาแล้วอย่างแน่นอน Webhook ที่เรียกใช้งาน n8n workflow เพื่ออ่านข้อมูลจากฟอร์มแล้วเขียนลงในฐานข้อมูล คือตัวอย่างของ simple reflex agent และมันยังคงเป็นเช่นนั้นแม้จะมี language model คอยทำหน้าที่จัดหมวดหมู่ให้กับข้อมูลแถวนั้นอยู่ตรงกลางก็ตาม หากคุณถามมันว่าเมื่อหนึ่งชั่วโมงที่แล้วมันทำอะไรไปบ้าง มันจะไม่สามารถตอบคุณได้ เพราะไม่มีส่วนใดที่เก็บคำตอบนั้นไว้

เอเจนต์ประเภทนี้ให้ผลลัพธ์ที่ถูกต้องบ่อยกว่าที่คนส่วนใหญ่คาดคิด มีต้นทุนการทำงานต่ำ และความผิดพลาดของมันก็ตรวจสอบได้ง่าย: คือเงื่อนไขตรงหรือไม่ตรงเท่านั้น เมื่อเนื้องานคือ "เมื่อ X มาถึง ให้ทำ Y" การเพิ่มหน่วยความจำเข้าไปมีแต่จะเพิ่มโอกาสให้เกิดความผิดพลาดโดยไม่ได้รับประโยชน์ใดๆ n8n agent ที่ทำงานผ่าน webhook คือตัวอย่างของเอเจนต์ประเภทนี้ในระดับชั้นของอนุกรมวิธานที่มีส่วนติดต่อผู้ใช้ครอบอยู่ด้านบน

มันจะเริ่มทำงานผิดพลาดทันทีที่การกระทำที่ถูกต้องขึ้นอยู่กับประวัติการทำงาน บอทตอบกลับที่ไม่มีการเก็บสถานะของเธรด (thread state) จะตอบโต้ขัดแย้งกับตัวเองในข้อความที่สาม เพราะข้อความสองข้อความแรกไม่เคยถูกรวมเป็นส่วนหนึ่งของข้อมูลนำเข้าของมันเลย

Model-based reflex agents: การรักษาข้อมูลสถานะระหว่างเหตุการณ์

Model-based reflex agent จะเก็บภาพจำลองภายในของสภาพแวดล้อมและอัปเดตภาพจำลองนั้นเมื่อได้รับข้อมูลนำเข้าใหม่ คำว่า "model" ในที่นี้หมายถึงแบบจำลองของโลก ไม่ใช่ neural network คำนี้ถูกใช้มาก่อนความหมายในปัจจุบันประมาณสี่สิบปี ซึ่งมักทำให้เกือบทุกคนสับสนเมื่ออ่านครั้งแรก

กฎระบบอัตโนมัติในบ้านที่สั่งปิดไฟหลังจากไม่มีการเคลื่อนไหวเป็นเวลา 20 นาทีถือเป็น model-based เพราะจำเป็นต้องเป็นเช่นนั้น สำหรับ simple reflex agent แล้ว "ไม่มีการเคลื่อนไหวในขณะนี้" และ "ไม่มีการเคลื่อนไหวตั้งแต่ 21:40" ถือเป็นข้อมูลนำเข้าชุดเดียวกัน ดังนั้นมีเพียงข้อมูลสถานะที่จัดเก็บไว้เท่านั้นที่ช่วยให้แยกแยะความแตกต่างได้

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

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

เอเจนต์แบบเน้นเป้าหมาย: การวางแผนเพื่อมุ่งสู่สถานะที่ตรวจสอบได้

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

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

ต้นทุนจะเกิดขึ้นในส่วนนี้ ทุกขั้นตอนการวางแผนคือการเรียกใช้งานโมเดลอีกครั้งซึ่งต้องส่งประวัติการทำงานทั้งหมดที่ผ่านมาไปด้วย ดังนั้นงานที่มี 10 ขั้นตอนจึงไม่ได้มีราคาเป็น 10 เท่าของขั้นตอนเดียว แต่จะมีราคาสูงกว่านั้น วิศวกรรมที่สำคัญคือรูปแบบของลูปและเงื่อนไขที่ใช้หยุดลูป ซึ่งเป็นหัวข้อของ วิศวกรรมลูป

Utility-based agents: การเลือกคำตอบที่ดีที่สุดจากหลายทางเลือก

เป้าหมายมีสถานะเป็นเลขฐานสอง (สำเร็จหรือไม่สำเร็จ) แต่ Utility คือคะแนน Utility-based agent จะเผชิญกับผลลัพธ์ที่ยอมรับได้หลายรูปแบบ และเลือกผลลัพธ์ที่ได้คะแนนสูงสุดตามฟังก์ชันที่คุณกำหนดไว้

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

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

เอเจนต์การเรียนรู้: ประเภทที่คนส่วนใหญ่เข้าใจผิดว่าตนเองมีอยู่แล้ว

เอเจนต์การเรียนรู้ (learning agent) จะปรับเปลี่ยนพฤติกรรมของตนเองโดยอาศัยผลตอบรับจากผลลัพธ์ในอดีต ระบบนี้จำเป็นต้องมีส่วนที่ทำหน้าที่ประเมินผลลัพธ์และส่วนที่ปรับเปลี่ยนนโยบายการทำงานเพื่อตอบสนองต่อผลลัพธ์นั้น

มีระบบที่โฮสต์ด้วยตนเอง (self-hosted) เพียงไม่กี่ระบบเท่านั้นที่เข้าข่ายนี้ เอเจนต์ที่อ่านบันทึกที่ตนเองเขียนไว้เมื่อสัปดาห์ก่อนถือเป็นเอเจนต์แบบจำลองที่มีไฟล์หน่วยความจำ (memory file) ซึ่งค่าน้ำหนัก (weights) และนโยบายการทำงานยังคงเหมือนเดิมทุกประการ การดึงข้อมูลไม่ใช่การเรียนรู้ และความแตกต่างนี้มีความสำคัญในทางปฏิบัติ กล่าวคือ ระบบที่ใช้หน่วยความจำจะทำผิดพลาดซ้ำเดิมตลอดไปจนกว่าจะมีสิ่งใดไปแก้ไขหน่วยความจำนั้น ในขณะที่ระบบการเรียนรู้ควรจะหยุดทำผิดพลาดดังกล่าว

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

ระบบแบบหลายเอเจนต์และแบบลำดับชั้น: การจัดวาง ไม่ใช่ประเภท

สิ่งเหล่านี้ไม่ใช่ประเภทที่หกหรือเจ็ด แต่เป็นการอธิบายวิธีการจัดวางเอเจนต์

ระบบแบบหลายเอเจนต์ (multi-agent system) คือการรันเอเจนต์หลายตัวพร้อมกันภายในสภาพแวดล้อมที่ใช้ร่วมกัน เช่น คิวหรือ git repository เนื่องจากสภาพแวดล้อมถูกใช้ร่วมกัน เอเจนต์จึงเกิดการชนกันภายในนั้น การที่เอเจนต์สองตัวแก้ไขไฟล์เดียวกันเป็นความล้มเหลวมาตรฐาน ซึ่งวิธีแก้ไขคือการใช้ lock หรือ work queue โดยไม่มี prompt ใดที่แก้ปัญหานี้ได้

ระบบแบบลำดับชั้น (hierarchical system) คือการวาง supervisor ไว้เหนือ worker โดย supervisor จะแบ่งงาน แจกจ่ายส่วนประกอบต่างๆ และรวมผลลัพธ์ที่ได้กลับมา ระบบนี้เป็นที่นิยมเพราะสอดคล้องกับวิธีที่มนุษย์แบ่งงานกันทำ และมีค่าใช้จ่ายสูงเนื่องจากบริบทของ supervisor จะเพิ่มขึ้นตามรายงานทุกฉบับที่อ่าน A multi-agent harness แสดงให้เห็นถึงการเชื่อมต่อระบบดังกล่าวในทางปฏิบัติ

เอเจนต์หนึ่งตัวที่ทำงานได้จริง ย่อมดีกว่าเอเจนต์สี่ตัวที่ทำงานได้บ้างไม่ได้บ้าง

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

เหตุใดระบบจริงเกือบทุกระบบจึงเป็นแบบไฮบริด

ลองพิจารณา deployment agent ที่คุณอาจใช้งานด้วยตนเอง ระบบนี้เริ่มทำงานด้วย webhook ซึ่งเป็นแบบ reflex จากนั้นระบบจะอ่านสถานะของ release ปัจจุบัน ซึ่งเป็นแบบ model-based ต่อมาจะวางแผนขั้นตอนการเปลี่ยนจากเวอร์ชันที่กำลังทำงานอยู่ไปสู่เวอร์ชันเป้าหมาย ซึ่งเป็นแบบ goal-based และเลือกช่วงเวลาในการ rollout ตามโหลดปัจจุบัน ซึ่งเป็นแบบ utility-based ระบบนี้ไม่เคยแก้ไขนโยบายของตนเอง จึงไม่ใช่ระบบที่เรียนรู้ได้ (learning)

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

ประเภทใดเหมาะกับงานใด

• ทริกเกอร์คงที่ การตอบสนองคงที่ ไม่ต้องใช้ประวัติ: simple reflex
• การตอบสนองที่ถูกต้องขึ้นอยู่กับสิ่งที่เกิดขึ้นก่อนหน้า: model-based reflex
• สถานะปลายทางตรวจสอบได้แต่ไม่ทราบเส้นทางล่วงหน้า: goal-based
• มีผลลัพธ์ที่ยอมรับได้หลายทางโดยต้องแลกเปลี่ยนข้อดีข้อเสียระหว่างกัน: utility-based
• ต้องการให้ผลลัพธ์ดีขึ้นตามกาลเวลา: สร้าง eval loop และยอมรับว่าคุณคือส่วนประกอบของการเรียนรู้

คุณสามารถโฮสต์เอเจนต์เหล่านี้ด้วยตนเองได้หรือไม่ และมีค่าใช้จ่ายเท่าไร

ได้ และค่าใช้จ่ายจะแบ่งออกเป็นสองส่วน ส่วนการจัดการ (orchestration) นั้นมีราคาถูก อินสแตนซ์ n8n หรือลูปของเอเจนต์ที่เขียนด้วย Python ส่วนใหญ่จะใช้เวลาไปกับการรอการเรียกเครือข่าย ดังนั้นการใช้ 2 vCPU และ 4 GB RAM ก็เพียงพอแล้ว ส่วนค่าใช้จ่ายหลักจะอยู่ที่ตัวโมเดล

หากเอเจนต์เรียกใช้ API ที่โฮสต์ไว้ เซิร์ฟเวอร์แทบจะไม่ต้องใช้ทรัพยากรใดๆ และค่าใช้จ่ายจะแปรผันตามจำนวนโทเค็น สำหรับเอเจนต์ที่ทำงานตามเป้าหมาย (goal-based agent) หมายความว่าค่าใช้จ่ายจะแปรผันตามจำนวนขั้นตอนการวางแผนที่คุณอนุญาต ดังนั้นควรจำกัดจำนวนลูปไว้ด้วย

หากคุณรันโมเดลบนฮาร์ดแวร์ของคุณเอง RAM จะเป็นตัวกำหนดว่าคุณสามารถรันอะไรได้บ้าง ตัวเลขด้านล่างนี้คือขนาดไฟล์ทั่วไปของน้ำหนักโมเดล (weights) แบบ 4-bit quantised ณ เดือนสิงหาคม 2026 โดยระบุคู่กับตัวเลขประมาณการสำหรับ RAM รวมที่ต้องใช้ เนื่องจากทั้ง context window และ runtime จำเป็นต้องมีพื้นที่เหลือมากกว่าแค่ขนาดของน้ำหนักโมเดล

[
  {
    "label": "3B model",
    "weights_gb": 2,
    "ram_needed_gb": 6
  },
  {
    "label": "8B model",
    "weights_gb": 4.9,
    "ram_needed_gb": 10
  },
  {
    "label": "14B model",
    "weights_gb": 9,
    "ram_needed_gb": 16
  },
  {
    "label": "32B model",
    "weights_gb": 20,
    "ram_needed_gb": 32
  },
  {
    "label": "70B model",
    "weights_gb": 43,
    "ram_needed_gb": 64
  }
]

โมเดลขนาด 8B ที่ 4-bit จะมีขนาดน้ำหนักประมาณ 4.9 GB และเครื่องที่มี RAM 10 GB จะสามารถรันได้โดยไม่เกิดการ swapping ส่วนโมเดลขนาด 70B ที่การ quantisation ระดับเดียวกันจะมีขนาดน้ำหนัก 43 GB และต้องการ RAM ประมาณ 64 GB โปรดสังเกตสิ่งที่ตัวเลขเหล่านี้ไม่ได้ระบุไว้ คือความเร็ว บน VPS ที่ไม่มี GPU โมเดลขนาด 8B ที่ 4-bit จะสร้างโทเค็นได้เพียงหลักเดียวต่อวินาที ซึ่งถือว่ายอมรับได้สำหรับเอเจนต์ที่ทำงานผ่านคิวในช่วงข้ามคืน แต่จะช้าเกินไปสำหรับงานที่ต้องรอผลลัพธ์แบบโต้ตอบ ควรเก็บการรัน inference ในเครื่องไว้สำหรับงานแบบ batch และใช้ GPU หรือ API สำหรับส่วนที่ต้องการการโต้ตอบ รายชื่อเอเจนต์ AI ที่สามารถโฮสต์เองได้ จะครอบคลุมถึงโปรเจกต์ที่คุ้มค่าแก่การติดตั้ง และ เส้นทางการเรียนรู้สำหรับเอเจนต์ในปี 2026 จะครอบคลุมถึงสิ่งที่ควรเรียนรู้ตามลำดับ

จุดที่การจำแนกประเภทไม่ได้ช่วยอะไร

การจำแนกประเภทนี้ไม่ได้กล่าวถึงเครื่องมือหรือสิทธิ์การเข้าถึงเลย ตัวแทน (agent) ในตำราเรียนนั้นรับรู้และลงมือทำ แต่ไม่มีใครในบทนั้นกังวลเรื่องตัวแทนที่ถือครอง production API token ตัวแทนที่ขับเคลื่อนด้วยเป้าหมาย (goal-based agent) ซึ่งเข้าถึง shell ได้ กับตัวแทนที่เข้าถึงฐานข้อมูลได้แบบอ่านอย่างเดียว ทั้งคู่ถูกจัดอยู่ในแถวเดียวกันของตาราง แต่มีความเสี่ยงที่แตกต่างกันโดยสิ้นเชิง คุณควรตัดสินใจก่อนว่าตัวแทนสามารถเข้าถึงส่วนใดได้บ้าง ก่อนที่จะตัดสินใจว่ามันควรจะฉลาดเพียงใด และโปรดอ่าน วิธีป้องกันไม่ให้ AI agent เข้าถึงข้อมูลลับ ก่อนที่คุณจะมอบ credential ให้กับมัน

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

FAQ

AI agent มี 5 ประเภทอะไรบ้าง

ประกอบด้วย Simple reflex, model-based reflex, goal-based, utility-based และ learning agents โดยเรียงลำดับตามปริมาณความรู้ที่ agent มีก่อนเริ่มดำเนินการ Simple reflex agent จะมองเห็นเฉพาะข้อมูลนำเข้าปัจจุบันเท่านั้น Model-based agent จะเก็บสถานะของสภาพแวดล้อมเอาไว้ Goal-based agent จะวางแผนเพื่อมุ่งสู่สถานะเป้าหมาย Utility-based agent จะให้คะแนนผลลัพธ์ที่ยอมรับได้หลายทางแล้วเลือกทางที่ได้คะแนนสูงสุด ส่วน Learning agent จะปรับเปลี่ยนนโยบายของตนเองจากผลตอบรับ ซึ่งแทบไม่มีการตั้งค่าแบบ self-hosted ใดที่ทำเช่นนี้จริง

ควรใช้ AI agent ประเภทใดสำหรับระบบอัตโนมัติแบบง่าย

ควรใช้ Simple reflex agent ซึ่งในทางปฏิบัติหมายถึง webhook หรือตารางเวลาที่สั่งให้ทำงานตามลำดับที่กำหนดไว้ตายตัว หากการตอบสนองที่ถูกต้องขึ้นอยู่กับข้อมูลนำเข้าที่เพิ่งได้รับมาเท่านั้น การเพิ่มหน่วยความจำจะทำให้เกิดจุดบกพร่องโดยไม่เพิ่มขีดความสามารถใดๆ ให้ขยับไปใช้การออกแบบแบบ model-based ก็ต่อเมื่อคุณสามารถระบุการตัดสินใจที่จำเป็นต้องทราบเหตุการณ์ที่เกิดขึ้นก่อนหน้านี้ได้

สามารถรัน AI agent ของตนเองบน VPS ได้หรือไม่

ได้ ชั้นการจัดการ (orchestration layer) มีน้ำหนักเบา ดังนั้น 2 vCPU และ 4 GB of RAM ก็เพียงพอต่อการรัน workflow engine หรือ agent loop ได้อย่างสบาย การตัดสินใจที่แท้จริงคือตำแหน่งที่โมเดลจะรัน หากใช้ hosted API จะช่วยให้เซิร์ฟเวอร์มีขนาดเล็กและเปลี่ยนค่าใช้จ่ายไปอยู่ที่จำนวน tokens แทน แต่หากใช้โมเดลในเครื่อง (local model) จะต้องใช้ RAM ตามสัดส่วนของจำนวนพารามิเตอร์ และหากไม่มี GPU จะสร้าง tokens ได้เพียงหลักหน่วยต่อวินาที ซึ่งเหมาะกับงานแบบ batch ที่เข้าคิวไว้มากกว่าหน้าต่างแชท

Large language model ถือเป็น AI agent ในตัวมันเองหรือไม่

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

จำเป็นต้องใช้ระบบ multi-agent หรือไม่

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