Agents — ให้ AI วางแผน ลงมือ และวนซ้ำจนงานเสร็จ

ก่อนหน้านี้ (Lv3) เราให้ LLM เรียกเครื่องมือ (tool use) ได้ 1 ครั้ง เช่น "ถามอากาศ → เรียก getWeather() → เอาผลมาตอบ" แต่ในงานจริง งานส่วนใหญ่ ทำเสร็จในสเต็ปเดียวไม่ได้ มันต้องลองทำ ดูผล แล้วตัดสินใจสเต็ปต่อไปเอง — นี่แหละคือหัวใจของ agent (เอเจนต์)

Agent คืออะไร

Agent คือระบบที่ให้ LLM วนลูป: วางแผน → ลงมือ (ใช้ tool) → ดูผล → คิดต่อ ทำซ้ำไปเรื่อยๆ จนกว่าจะบรรลุเป้าหมาย ต่างจากการเรียก LLM ธรรมดาตรงที่ ตัวโมเดลเองเป็นคน "ตัดสินใจ" ว่าจะทำอะไรต่อในแต่ละรอบ ไม่ใช่เราเขียน flow ตายตัวไว้ล่วงหน้า

ต่างจาก chatbot ยังไง

หลายคนคิดว่า agent ก็คือ chatbot (แชตบอต) ที่เก่งขึ้น แต่จริงๆ มันคนละแนวคิด chatbot ตอบ "ครั้งเดียวจบ" ต่อ 1 ข้อความ ส่วน agent จะทำงาน "หลายสเต็ปเอง" กว่าจะได้คำตอบ

ประเด็น	Chatbot	Agent
จำนวนสเต็ป	ตอบครั้งเดียวต่อ 1 ข้อความ	วนหลายสเต็ปเองจนงานเสร็จ
เครื่องมือ (tools)	มักไม่มี / เรียกครั้งเดียว	เรียก tool ได้หลายครั้ง หลายตัว
ความจำ (memory)	จำแค่ในบทสนทนาปัจจุบัน	มี memory เก็บผลระหว่างสเต็ป/ข้ามงาน
การตัดสินใจ	เราถามอะไร มันตอบอันนั้น	มันเลือกเองว่าสเต็ปถัดไปคืออะไร
ตัวอย่าง	ถาม-ตอบ FAQ	"เคลียร์ inbox ให้หน่อย" แล้วมันจัดการเอง

ส่วนประกอบของ agent

agent ที่ใช้งานได้จริงมักประกอบด้วย 5 ชิ้นนี้ ลองมองเป็น checklist ตอนออกแบบ:

• เป้าหมาย (goal): โจทย์ที่ต้องทำให้สำเร็จ เขียนให้ชัดว่า "เสร็จ" หน้าตาเป็นยังไง
• เครื่องมือ (tools): function ที่ agent เรียกได้ เช่น ค้น DB, เรียก API, ส่งอีเมล — นี่คือ "มือ" ของมัน
• ความจำ (memory): ที่เก็บผลลัพธ์และสิ่งที่ทำไปแล้ว เพื่อไม่ให้ทำซ้ำหรือลืมบริบท
• ลูป (loop): ตัวขับ plan → act → observe ให้วนต่อ โดยยัดผลของรอบก่อนกลับเข้า context
• เงื่อนไขหยุด (stop condition): กติกาว่าเมื่อไหร่ต้องหยุด — บรรลุเป้า, ครบจำนวนรอบ, หรือใช้งบเกิน

ต่อยอดจาก Lv3 (tool use) ยังไง

จำ Lv3 ได้ไหม — เราให้ LLM เรียก tool ได้ 1 ครั้งแล้วเอาผลมาตอบ agent ก็คือการเอา tool use อันเดิมนั้นมาใส่ในลูป แล้วป้อนผลกลับเข้าไปให้โมเดลคิดต่อ:

// Lv3: tool use = ยิงครั้งเดียวจบ
const res = await callLLM(prompt, tools);
if (res.toolCall) result = await runTool(res.toolCall);
// ...แล้วจบ ไม่คิดต่อ

// Lv5: agent = เอา tool use มาใส่ลูป + memory + stop condition
let memory = [goal];
for (let step = 0; step < MAX_STEPS; step++) {   // 🛑 ลิมิตรอบ
  const res = await callLLM(memory, tools);   // PLAN
  if (res.done) break;                       // 🛑 บรรลุเป้า → หยุด
  const obs = await runTool(res.toolCall);  // ACT
  memory.push(res, obs);                       // OBSERVE → เก็บเข้า memory
}

หัวใจอยู่ที่บรรทัด memory.push(res, obs) — การเอา "ผลของรอบก่อน" กลับเข้า context นี่แหละที่ทำให้โมเดลตัดสินใจสเต็ปถัดไปได้ฉลาดขึ้นเรื่อยๆ

ความเสี่ยงที่ dev ต้องคุม

พลังของ agent มาพร้อมความเสี่ยง เพราะมันตัดสินใจเองและทำหลายสเต็ป ถ้าไม่ใส่ guardrail (การ์ดเรล) ไว้ มันพังได้จริง:

ความเสี่ยง	เกิดอะไรขึ้น	ทางคุม
วนไม่จบ (infinite loop)	agent ติดวน แก้ปัญหาไม่ได้ ทำรอบเดิมซ้ำๆ	ตั้ง MAX_STEPS / timeout
Cost บาน	ทุกรอบ = ยิง LLM 1 ครั้ง วนเยอะ = จ่ายเยอะ	จำกัดจำนวนรอบ + งบ token ต่อ task
Action อันตราย	ลบ DB, ส่งอีเมลผิด, จ่ายเงินจริง	ให้คน approve ก่อน (human-in-the-loop — ให้คนมาอยู่ในลูปคอยอนุมัติ), จำกัดสิทธิ์ tool
Tool พังเงียบ	tool error แต่ agent เดินหน้าต่อบนข้อมูลผิด	ตรวจ error ทุก tool + ป้อน error กลับเข้า memory

ตัวอย่างจริง: agent ช่วยจัดการ ticket

สมมติทีม support มี ticket เข้ามาเยอะทุกวัน เราอยากได้ agent ที่ช่วย triage (คัดกรอง) ให้:

Goal: "อ่าน ticket ใหม่ทั้งหมดวันนี้ จัดหมวดหมู่ ตั้ง priority และ assign ให้ทีมที่เกี่ยว"

วงลูปของมันอาจเดินแบบนี้:

• PLAN: "ต้องดึง ticket ใหม่ก่อน" → ACT: เรียก listTickets(status:"new") → OBSERVE: ได้ 12 ใบ
• PLAN: "อ่านใบแรก จัดหมวด" → ACT: เรียก getTicket(id) → OBSERVE: เป็นปัญหาเรื่องบิล
• PLAN: "ตั้ง priority + assign" → ACT: updateTicket(id, {team:"billing", priority:"high"})
• วนซ้ำจนครบทั้ง 12 ใบ → STOP: ไม่มี ticket ใหม่เหลือ → รายงานสรุปแล้วหยุด