AI Agent ทำงานยังไง: จาก LLM ที่แค่ตอบ สู่ระบบที่ลงมือทำงานเอง

ถ้าคุณเคยใช้ ChatGPT หรือ Claude ถามคำถามแล้วได้คำตอบกลับมา นั่นคือ LLM ที่ “ตอบ” แต่ปี 2026 คำที่ทุกบริษัทพูดถึงคือ AI Agent — ระบบที่ไม่ได้แค่ตอบ แต่ “ลงมือทำ” ได้เอง: ค้นข้อมูล เรียก API กรอกฟอร์ม ส่งอีเมล แล้วตรวจงานตัวเองก่อนส่งกลับ คำถามที่คนเพิ่งเริ่มสงสัยคือ แล้วข้างในมันทำงานต่างจากแชตบอตธรรมดายังไง?

สรุปสั้น ๆ: AI Agent = LLM + ความจำ + การวางแผน + เครื่องมือ (tool) ที่ผูกเข้าด้วยกันด้วย “วงวน” (loop) — โมเดลคิดว่าจะทำอะไร ลงมือทำ ดูผลลัพธ์ แล้วคิดต่อ วนแบบนี้จนงานเสร็จ ตัวโมเดลเองไม่ได้เก่งขึ้น สิ่งที่เปลี่ยนคือ “โครงรอบ ๆ โมเดล” ที่ทำให้มันทำงานหลายขั้นได้ — และนั่นคือจุดที่มันพังบ่อยที่สุดด้วย

Agent ต่างจากแชตบอตยังไง

คำตอบตรง ๆ: แชตบอตตอบครั้งเดียวจบ ส่วน agent วนทำหลายรอบจนบรรลุเป้าหมาย โดยตัดสินใจเองว่าแต่ละรอบจะทำอะไร ความต่างไม่ได้อยู่ที่โมเดลฉลาดกว่า แต่อยู่ที่ “โครงสร้าง” ที่ครอบโมเดลไว้

โดยทั่วไปนักพัฒนามองว่า agent ประกอบด้วย 4 ชิ้นส่วนหลักที่ทำงานร่วมกัน:

• LLM (สมอง) — ตัวคิดและตัดสินใจ ว่ารอบนี้ควรทำอะไรต่อ
• เครื่องมือ (tools) — “มือ” ที่ให้โมเดลไปดึงข้อมูลจริงหรือลงมือกระทำในโลกภายนอก
• ความจำ (memory) — เก็บว่าทำอะไรไปแล้ว ได้ผลอะไร เพื่อไม่วนซ้ำที่เดิม
• การวางแผน (planning) — ย่อยงานใหญ่เป็นขั้นย่อย ๆ แล้วไล่ทำ

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

หัวใจคือ “agent loop”: คิด → ทำ → สังเกต → คิดต่อ

สิ่งที่ทำให้ agent เป็น agent คือ วงวน (loop) ที่ทำงานซ้ำ ๆ ไม่ใช่เส้นตรงจบในครั้งเดียว หนึ่งรอบของวงวนนี้มีสี่จังหวะ:

รับรู้ (ประกอบ context ที่โมเดลจะเห็น) → ตัดสินใจ (จะตอบเลย หรือขอเรียกเครื่องมือ) → ลงมือ (ระบบรันเครื่องมือนั้นจริง) → สังเกตผล (ป้อนผลกลับเข้า context) → แล้ววนกลับไปคิดต่อจากผลที่ได้

รูปแบบ “คิดสลับกับทำ” แบบนี้รู้จักกันในชื่อ ReAct (ย่อจาก Reasoning + Acting) วงวนจะหมุนไปเรื่อย ๆ จนกว่าโมเดลจะตอบกลับ โดยไม่ขอเรียกเครื่องมือเพิ่ม — นั่นคือสัญญาณว่ามันถือว่างานจบแล้ว (หรือจนกว่าจะชนเพดานรอบ/งบที่เราตั้งไว้)

ตัวอย่างให้เห็นภาพ: ถ้าถาม agent ว่า “สรุปยอดขายไตรมาสล่าสุดเทียบกับปีก่อนให้หน่อย” มันอาจ (1) คิด ว่าต้องดึงข้อมูลจากฐานข้อมูลก่อน → (2) ลงมือ เรียกเครื่องมือ query ยอดขาย → (3) สังเกต ว่าได้ตัวเลขมาแล้วแต่ยังไม่มีข้อมูลปีก่อน → (4) คิดต่อ ว่าต้อง query อีกรอบ → วนจนครบแล้วค่อยเรียบเรียงคำตอบ

จุดสำคัญที่คนมักเข้าใจผิดคือ “ความคิด” ในแต่ละรอบไม่ได้มาจากเวทมนตร์ — มันมาจากการที่เราออกแบบ prompt และ context ให้โมเดลรู้ว่ามีเครื่องมืออะไรบ้างและควรใช้เมื่อไร นี่คือเหตุผลที่ทักษะ เขียน prompt ให้ได้ผล ยังเป็นรากฐานของงาน agent อยู่ดี เพราะคำสั่งที่คลุมเครือทำให้ทุกก้าวใน loop เพี้ยนตามกันหมด

Tool use: “มือ” ของ agent ที่หลายคนเข้าใจผิด

คำตอบตรง ๆ ของเรื่องนี้สำคัญมาก: โมเดลไม่ได้เรียก API เองโดยตรง มันแค่ “บอกว่าอยากเรียก” เครื่องมือไหนด้วยค่าอะไร แล้ว โค้ดของเรา เป็นคนเรียกฟังก์ชันจริงและส่งผลกลับเข้าไปในบทสนทนา

เปรียบเหมือนพนักงานซัพพอร์ตที่รับคำถาม “ออร์เดอร์ผมไปถึงไหนแล้ว” พนักงาน (โมเดล) ไม่ได้ลุกไปเช็กเอง แต่เขียนใบสั่งงานว่า “ช่วยเรียกฟังก์ชัน get_order_status ด้วยเลข ORD-98765” แล้วส่งให้ระบบ (โค้ดของเรา) ไปทำจริง เมื่อได้สถานะกลับมา พนักงานจึงเรียบเรียงเป็นคำตอบให้ลูกค้า โมเดลไม่ได้ “โทรเอง” — มัน “ขอให้โทร”

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

ในปี 2026 เรื่องนี้ก้าวไปอีกขั้นด้วย MCP (Model Context Protocol) — มาตรฐานกลางที่ให้ agent เชื่อมกับเครื่องมือและระบบภายนอกได้แบบไม่ต้องเขียนโค้ดต่อเฉพาะทีละอัน ตอนนี้ MCP ถูกดาวน์โหลดไปกว่า 97 ล้านครั้งและมีผู้เล่นใหญ่อย่าง Anthropic, OpenAI, Google, Microsoft และ AWS รองรับพร้อมกัน จนกลายเป็น “ปลั๊กมาตรฐาน” ให้ agent เสียบเข้ากับเครื่องมือได้ทั่วโลก อนึ่ง การดึงข้อมูลด้วย RAG ก็คือเครื่องมือประเภทหนึ่งที่ agent เรียกใช้ในวงวนนี้เช่นกัน

Planning: จากทำทีละก้าว สู่วางแผนทั้งงาน

ไม่ใช่ทุกงานที่เหมาะกับการคิดทีละก้าวแบบ ReAct ปี 2026 นักพัฒนาแยกรูปแบบการวางแผนเป็นสองขั้วหลักที่เหมาะกับงานคนละแบบ:

• ReAct (คิดสลับทำทีละก้าว) — เหมาะกับงานปลายเปิดที่ต้องสำรวจ เช่น งานวิจัย งานไล่แก้ปัญหา (troubleshooting) เพราะ agent ปรับทิศได้ทุกก้าวตามสิ่งที่เจอ แต่จะอ่อนกับงานที่ต้องทำตามลำดับเป๊ะ ๆ
• Plan-and-Execute (วางแผนทั้งหมดก่อน แล้วค่อยลงมือ) — แยกเป็นสองเฟส: ตัว “วางแผน” ร่างขั้นตอนทั้งชุดก่อน แล้วตัว “ลงมือ” ไล่ทำทีละขั้น เหมาะกับงานยาวที่มีโครงสร้างชัด และงานที่ “หลุดทิศกลางทาง” แล้วเสียหาย

นอกจากสองตัวนี้ ยังมี pattern อื่นที่ปี 2026 ถือเป็นความรู้พื้นฐานของคนสร้าง agent เช่น Reflection (ให้ agent ตรวจงานตัวเองแล้วแก้ก่อนส่ง), Multi-Agent (แบ่งงานให้ agent หลายตัวที่เชี่ยวเฉพาะด้านช่วยกัน), Memory Management (จัดการความจำระยะยาว) และ Human-in-the-Loop (ให้คนอนุมัติจังหวะสำคัญ) เลือกใช้ให้เข้ากับงาน ไม่ใช่ใช้ทุกอันเสมอไป

ทำไม agent ถึงพังบ่อยในงานจริง

นี่คือส่วนที่คนเพิ่งเริ่มมักไม่ทันคิด: ยิ่ง agent ทำงานหลายก้าว โอกาสพลาดยิ่งทบต้น เพราะความผิดพลาดเล็ก ๆ ในก้าวแรกจะลามไปทั้งสาย

Anthropic ยกตัวอย่างที่เห็นภาพชัดด้วยการวัดสองแบบที่บอกคนละเรื่อง: agent ที่ทำงานสำเร็จ 75% ต่อรอบ ฟังดูดี แต่ถ้าต้องทำงาน 3 รอบติดให้ถูกทั้งหมด (วัดแบบ pass^3) โอกาสสำเร็จเหลือแค่ 0.75³ ≈ 42% — แปลว่าเกินครึ่งของงานจะมีอย่างน้อยหนึ่งก้าวที่พัง นี่คือเหตุผลที่ทีมที่เอาจริงจะ อ่าน transcript ทุกครั้ง ไม่ใช่ดูแค่ผ่าน/ไม่ผ่าน เพราะบางทีก้าวกลางพังทั้งที่ผลลัพธ์สุดท้ายดูเหมือนถูก

ประเด็นที่น่าคิดที่สุดจากงานปี 2024–2026 คือ ความล้มเหลวของ agent ส่วนใหญ่ในระดับ production เป็นปัญหาเชิงสถาปัตยกรรม ไม่ใช่คุณภาพของโมเดล — ไม่ใช่ว่าโมเดลโง่ แต่เป็นเรื่องการออกแบบ loop, การจัดการ context, การกู้คืนเมื่อก้าวใดก้าวหนึ่งล้ม และการกันไม่ให้ error สะสม นี่คือสาเหตุที่การเปลี่ยนโมเดลเป็นตัวใหม่กว่าไม่ได้ช่วยเสมอไป ถ้าโครงรอบ ๆ ยังเปราะ

พูดง่าย ๆ: การทำให้ agent “ทำงานได้ครั้งเดียวใน demo” ไม่ยาก แต่การทำให้มัน “ทำงานได้ซ้ำ ๆ อย่างเชื่อถือได้ในของจริง” คือคนละโจทย์ และเป็นโจทย์เชิงวิศวกรรมล้วน ๆ

จากสร้าง agent สู่ “จัดการ” agent

ถ้าจับใจความทั้งหมดได้ จะเห็นว่า agent ที่ทำงานจริงไม่ได้ต่างกันที่ “โมเดลตัวไหน” แต่ต่างกันที่ ชั้นควบคุมและประสาน (orchestration) — ตัวที่คอยส่งงานระหว่างเครื่องมือและ agent ย่อย จัดการความจำที่ต้องคงอยู่ กู้คืนเมื่อพลาด และคุมไม่ให้หลุดกรอบ นักวิเคราะห์อย่าง Gartner คาดว่าภายในสิ้นปี 2026 แอปพลิเคชันองค์กรราว 40% จะฝัง AI agent เข้าไป (จากไม่ถึง 5% ในปี 2025) และองค์กรที่นำหน้าไม่ใช่คนที่มีโมเดลใหญ่สุด แต่เป็นคนที่ทำ “การประสาน agent” ได้ดีที่สุด

นี่คือทิศทางที่งาน AI Engineering กำลังขยับไป — จากคำถาม “จะสร้าง agent ให้ทำงานได้ยังไง” ไปสู่ “จะควบคุมและจัดการ agent ให้ทำงานอย่างเชื่อถือได้ ปลอดภัย และคุมต้นทุนได้ยังไง” ซึ่งเป็นทักษะที่ต่อยอดตรงจากการ ออกแบบสถาปัตยกรรมระบบ AI เพราะมันคือการมองภาพรวมทั้งระบบ ไม่ใช่แค่เขียน prompt ให้เก่งขึ้น

ถ้าคุณเพิ่งเข้าใจว่า agent loop ทำงานยังไงจากบทความนี้ ก้าวถัดไปที่คุ้มค่าที่สุดไม่ใช่การไล่ตามโมเดลใหม่ทุกสัปดาห์ แต่คือการฝึกคิดเชิง “โครงรอบ ๆ โมเดล” — วงวน การจัดการ context การกู้คืน และการวางกรอบให้ agent ทำงานได้จริง เพราะนั่นคือส่วนที่แยกระหว่าง agent ที่เท่ใน demo กับ agent ที่ใช้งานได้จริงในโลกที่วุ่นวายกว่ามาก