AI Agent ไม่ได้ฉลาดเพราะมีหลาย Agent: สิ่งที่ทำให้ Agentic System ใช้งานจริงได้

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

ในงานที่ลำดับแน่นอน เช่น validate input → เรียก API → ตรวจ schema → บันทึกผล deterministic workflow อาจอ่านง่าย ถูกกว่า และแกะรอยง่ายกว่า agent การเพิ่ม agent เข้าไปไม่ควรเป็น default เพียงเพราะทำได้

START HEREงานต้องวางแผนและเลือกเส้นทางระหว่างทางหรือไม่?

DETERMINISTICใช้ codeขั้นตอนแน่นอน, ทดสอบง่าย, side effect ชัด

BOUNDEDใช้ LLM หนึ่ง stepมีความไม่แน่นอนเฉพาะจุด แต่ไม่ต้องวนค้น

AGENTICใช้ agentต้องวางแผน, ใช้ tools, มี state และ stop condition

ความเป็นอิสระที่เพิ่มขึ้นต้องแลกกับ permission, evidence และ failure handling ที่ชัดขึ้น

เริ่มจาก code เมื่อขั้นตอนแน่นอน ใช้ agent เมื่อการวางแผนและการวนค้นเพิ่มคุณค่าจริง

เมื่อ agent มีประโยชน์

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

สิ่งที่ควรกำหนดก่อนสร้าง loop ได้แก่:

tool ที่เรียกได้และ schema ของ input/output
permission ของแต่ละ tool
จำนวนรอบและเวลาสูงสุด
state ที่เก็บไว้ระหว่างรอบ
หลักฐานที่ต้องแนบกับผลลัพธ์
เงื่อนไขหยุดและเงื่อนไขส่งต่อให้คน

Tool boundary สำคัญกว่าคำว่า autonomous

อย่าให้ agent มีสิทธิ์กว้างเท่าผู้ใช้หรือ service account ทั้งระบบ ตัวอย่างเช่น tool สำหรับอ่านรายงานอาจปลอดภัยกว่า tool ที่แก้ไขข้อมูล แต่ทั้งคู่ควรตรวจ input, identity และขอบเขตของ resource ทุกครั้ง

const tool = {
  name: 'approve_refund',
  input: refundSchema,
  permission: 'human-approved-only',
  sideEffect: 'irreversible',
};

ถ้า agent เสนอ action ที่มี side effect ระบบควรเปลี่ยนสถานะเป็น pending approval ไม่ใช่แอบเรียก tool ต่อ การมี supervisor อีกตัวไม่ได้ทำให้ permission หายไป ต้องตรวจที่ boundary ของ tool อยู่ดี

Multi-agent มีค่าใช้จ่ายของมันเอง

หลาย agent เพิ่ม message passing, state synchronization, latency, token cost และจุดที่ต้อง monitor ถ้า agent หนึ่งตีความงานผิด อีกตัวอาจรับ assumption นั้นต่อโดยไม่รู้ที่มา การแบ่งงานมากขึ้นจึงไม่ได้แปลว่าคุณภาพมากขึ้น

เริ่มจาก single workflow ที่ trace ได้ก่อน แล้วถามว่าปัญหาจริงต้องการ specialization หรือ parallelism หรือไม่ ถ้าไม่ต้องการ การใช้ function ปกติอาจเป็นคำตอบที่ซื่อสัตย์กว่า

Supervisor ไม่ควรเป็นกล่องวิเศษ

pattern supervisor ช่วยจัด route ไปยัง worker ที่เหมาะ แต่ supervisor เองก็ต้องมี contract เช่น worker ต้องคืน status, evidence และ error type ไม่ใช่คืนข้อความอย่างเดียว

supervisor
  -> worker: retrieve
  <- evidence + status
  -> worker: summarize
  <- answer + source_ids
  -> validator
  -> answer / escalate

ถ้า worker คืนผลลัพธ์ที่ไม่มีหลักฐาน supervisor ควรรู้ว่า workflow ยังไม่จบ การแยกสถานะนี้ทำให้ failure ไม่ถูกกลบด้วยประโยคสุดท้ายที่อ่านดี

สรุป

agentic system ที่ใช้งานจริงไม่ได้วัดจากจำนวน agent แต่วัดจากความชัดของเครื่องมือ ขอบเขตสิทธิ์ state หลักฐาน failure mode และต้นทุนที่ยอมรับได้

สิ่งที่ควรจำมีสามข้อ:

ใช้ deterministic code เมื่อโจทย์มีลำดับและเงื่อนไขที่ระบุได้
agent ควรมี tool boundary, retry budget, stop condition และ evidence contract
multi-agent เพิ่มความสามารถได้ แต่เพิ่มต้นทุนและจุดเสียหายด้วย

References

Anthropic — Building effective agents (2024): แยก workflow กับ agent และเสนอให้เริ่มจากรูปแบบที่เรียบง่ายก่อน
OpenAI — A practical guide to building agents: ครอบคลุม model, tools, orchestration และ guardrails สำหรับ agent
OWASP GenAI Security Project — Agentic AI: Threats and Mitigations (2025): threat-model ของความเสี่ยงเฉพาะ agentic systems
OWASP GenAI Security Project — Securing Agentic Applications Guide 1.0 (2025): คำแนะนำเชิงปฏิบัติสำหรับออกแบบและ deploy agentic applications
NIST — Generative AI Profile (2024): มุมมอง risk management และ oversight สำหรับ generative AI

เลือก autonomy ตามความไม่แน่นอนและขอบเขต