AI Agent Glossary 02: Goal, Tools, Memory และ Loop ใน Agent

Agent ตอบคําถามวันลาได้ถูกต้องในรอบแรก แต่พอผู้ใช้ถามต่อว่า “แล้วกรณีของพนักงานสัญญาจ้างล่ะ” ระบบกลับตอบจากเงื่อนไขของพนักงานประจําเหมือนเดิม ทีมจึงพูดว่า “memory ไม่ดี” ทั้งที่ปัญหาอาจเป็น state, retrieval หรือคําสั่งที่ไม่ได้บอกให้ตรวจประเภทการจ้างใหม่

คําว่า Agent ไม่ได้อธิบายกลไกภายในทั้งหมด การเปิดดูว่า Agent ทํางานเป็นวงจรอย่างไรและข้อมูลชนิดใดอยู่ตรงไหน ช่วยให้เราแก้ปัญหาได้ตรงชั้นกว่าเดิม

Agent คือระบบที่ควบคุม workflow ผ่านผลจากสภาพแวดล้อม

ในบทความนี้ Agent หมายถึงระบบที่ให้โมเดลเลือกและควบคุมขั้นตอนบางส่วนของงาน โมเดลอาจเลือก tool, อ่านผลที่ tool คืนมา แล้วตัดสินใจว่าจะตอบ เรียก tool เพิ่ม หยุด หรือขอความช่วยเหลือจากคน

Agentic system เป็นคํากว้างกว่า ครอบคลุมทั้ง workflow ที่ code กําหนดทางไว้มากและ Agent ที่ให้โมเดลเลือกทางแบบไดนามิก การใช้คํานี้ช่วยไม่ให้ทีมต้องเถียงว่าเส้นแบ่งของ Agent อยู่ตรงไหน แต่เวลาสร้างระบบจริงยังต้องระบุว่าใครเป็นผู้เลือกแต่ละขั้น

Goal บอกปลายทาง ไม่ได้เขียนทุกก้าว

Goal คือผลลัพธ์ที่ระบบพยายามทําให้สําเร็จ เช่น “ตอบคําถามนโยบาย HR จากเอกสารที่อนุมัติ พร้อมหลักฐาน หรือส่งต่อ HR เมื่อหลักฐานไม่พอ”

Goal ไม่ใช่ instructions ทั้งหมด Instructions ยังต้องกําหนดข้อจํากัด แหล่งข้อมูล รูปแบบผลลัพธ์ และเงื่อนไขหยุด ถ้าเขียน goal ว่า “ช่วยพนักงานให้ดีที่สุด” ระบบไม่มีเกณฑ์พอตัดสินว่าเมื่อไรควรตอบหรือหยุด

Goal ที่ตรวจได้ควรมีสามส่วน: สิ่งที่ต้องส่งมอบ หลักฐานที่ต้องใช้ และสภาพที่ต้องหยุดหรือส่งต่อ

Agent loop ทําให้ระบบใช้ผลจริงเป็น feedback

Agent loop คือวงจรทํางานที่ประกอบด้วยการเลือก action, ลงมือ, รับผลจากสภาพแวดล้อม และเลือกขั้นถัดไป

ตัวอย่างหนึ่ง run ของ HR Agent:

1. รับคําถามเรื่องการลาครอบครัว
2. เลือก tool ค้นนโยบาย โดยส่งประเภทพนักงานและประเทศเป็น argument
3. รับผลค้นที่มีเอกสารสองฉบับ
4. ตรวจ metadata แล้วตัดฉบับเก่าออก
5. สร้างคําตอบพร้อมชื่อเอกสารและข้อที่อ้าง
6. พบว่าเคสผ่าตัดไม่ระบุชัด จึงส่งต่อ HR แทนการเดา

ความต่างระหว่าง loop ที่ดีและการเรียกโมเดลซ้ําไม่ได้อยู่ที่จํานวนรอบ แต่อยู่ที่แต่ละรอบได้รับ observation หรือหลักฐานใหม่จากสภาพแวดล้อมหรือไม่

Tool, tool call และ tool result เป็นคนละสิ่ง

Tool คือความสามารถภายนอกที่ application เปิดให้ Agent ใช้ เช่น search_policy, get_employee_type หรือ create_hr_ticket

Tool call คือคําขอของโมเดลที่ระบุชื่อ tool และ arguments เช่น search_policy(country="TH", employee_type="contractor") มันยังไม่ใช่การทํางานสําเร็จ application ต้องตรวจและเรียก function จริงอีกชั้น

Tool result หรือ observation คือข้อมูลที่ระบบภายนอกคืน เช่น “พบ 0 เอกสาร” หรือ “ticket HR-1042 ถูกสร้างแล้ว” Agent ใช้ข้อมูลนี้เพื่อเลือกขั้นถัดไป

การแยกสามคํานี้สําคัญมาก ถ้า trace แสดง tool call แต่ไม่มี tool result เรารู้เพียงว่าโมเดลขอทํา ไม่ได้พิสูจน์ว่า action เกิดขึ้นจริง

State บอกว่างานอยู่ที่ไหน

State คือข้อมูลที่อธิบายสถานะปัจจุบันของ workflow เช่น คําถามเดิม ประเภทพนักงาน เอกสารที่เลือก ขั้นตอนที่ผ่านแล้ว ticket ที่สร้าง และจํานวนรอบที่ใช้

State อาจอยู่ในตัวแปร workflow, database หรือ event record โดยไม่จําเป็นต้องแสดงทั้งหมดให้โมเดลเห็น สิ่งที่โมเดลต้องใช้จึงควรถูกเลือกมาใส่ context ไม่ใช่เท state ทุกอย่างลง prompt

ในเคสคําถามต่อเนื่อง ถ้าระบบยังใช้ employee_type=permanent หลังผู้ใช้เปลี่ยนเป็นพนักงานสัญญาจ้าง ปัญหาอาจเป็น state update ที่ไม่เกิด ไม่ใช่ memory ของโมเดล

Memory คือกลไกเก็บและเรียกข้อมูลกลับ

คําว่า memory ควรระบุขอบเขตทุกครั้ง เพราะอาจหมายถึงคนละอย่าง:

• Working context: ข้อมูลที่อยู่ใน request ปัจจุบัน
• Session state: ข้อมูลที่เก็บระหว่างบทสนทนาหรือ run เดียวกัน
• Persistent memory: ข้อมูลที่เก็บข้าม session และดึงกลับมาใช้ภายหลัง

Persistent memory เพิ่มความสะดวก แต่เพิ่มคําถามเรื่องความถูกต้อง อายุข้อมูล ความเป็นส่วนตัว และสิทธิ์ในการลบ ไม่ควรบันทึกทุกอย่างเพียงเพราะแพลตฟอร์มทําได้

สําหรับ HR Agent การจําว่าผู้ใช้ชอบคําตอบสั้นอาจเป็นประโยชน์ แต่การจํารายละเอียดสุขภาพของสมาชิกครอบครัวข้าม session ต้องมีเหตุผลและ control ที่เข้มกว่ามาก

Autonomy คือระดับการตัดสินใจ ไม่ใช่สวิตช์เปิดปิด

Autonomy คือระดับที่ Agent เลือกว่า “ทําอะไร” และ “ทําอย่างไร” โดยไม่ต้องให้คนกํากับทีละขั้น

Agent ตัวเดียวกันอาจมี autonomy ต่างกันตาม action:

การมี human approval ไม่ได้ทําให้ระบบ “ไม่เป็น Agent” มันเพียงวางขอบเขต autonomy ให้สอดคล้องกับผลกระทบ

Single-agent, multi-agent, handoff และ subagent

Single-agent system ใช้ Agent เดียวควบคุม workflow และ tools ชุดหนึ่ง เป็นจุดเริ่มต้นที่ตรวจง่าย

Multi-agent system แบ่งความรับผิดชอบระหว่าง Agent หลายตัว ต้องมีสัญญาการมอบงาน context ที่ส่งต่อ และวิธีรวมผล การเรียก LLM หลายครั้งไม่ได้แปลว่าเป็น multi-agent ถ้าทุก call ยังอยู่ใน workflow เดียวโดยไม่มีบทบาทและการควบคุมแยกกัน

Handoff คือการโอนการควบคุม workflow ไปยัง Agent หรือมนุษย์อีกฝ่ายพร้อม context ที่จําเป็น เช่น HR Agent ส่งเคสสวัสดิการต่างประเทศให้ Specialist Agent

Subagent คือ Agent ย่อยที่รับงานเฉพาะจาก Agent หลักแล้วส่งผลกลับ เช่น Agent หลักมอบหมายให้ subagent ตรวจความสอดคล้องของ citation โดยยังคงเป็นผู้คุยกับผู้ใช้เอง

ก่อนเพิ่ม Agent ตัวที่สอง ให้ถามว่าปัญหาแก้ด้วย tool หรือ workflow step ที่ชัดกว่าหรือไม่ Multi-agent เพิ่มเส้นทาง failure และภาระสังเกตการณ์ จึงควรมีเหตุผลที่ตรวจได้ ไม่ใช่ใช้เพื่อให้ architecture ดูล้ํา

วินิจฉัยปัญหาจาก trace สั้น ๆ

สมมติ trace แสดงว่า:

user: ถ้าเป็นพนักงานสัญญาจ้างล่ะ
state.employee_type: permanent
tool_call: search_policy(employee_type="permanent")
tool_result: leave-policy-permanent-2026.pdf
answer: พนักงานประจําสามารถ...

อาการนี้ไม่ควรเริ่มแก้ด้วยการเพิ่ม persistent memory หลักฐานชี้ว่า state ไม่อัปเดตประเภทพนักงานก่อนสร้าง tool call วิธีทดสอบคือเพิ่ม case ที่ผู้ใช้เปลี่ยนเงื่อนไขกลางบทสนทนา แล้วตรวจทั้ง state และ arguments ของ tool call

นี่คือคุณค่าของศัพท์ที่แม่น: มันเปลี่ยนคําว่า “Agent จําไม่ได้” ให้เป็นสมมติฐานที่ตรวจได้

แบบฝึกหัด: วาด loop ที่พิสูจน์ได้

เลือก Agent หนึ่งตัว แล้วเขียนหนึ่ง run เป็นตารางห้าคอลัมน์: state ก่อนทํางาน, decision, tool call, tool result และ state หลังทํางาน ทําต่อจนถึงจุดจบ

งานผ่านเมื่อคนอีกคนสามารถตอบได้จากตารางว่า:

• แต่ละ action เกิดจริงหรือเป็นเพียงคําขอ
• Agent ใช้หลักฐานใดเลือกขั้นต่อไป
• เมื่อไร loop ต้องหยุด
• action ใดต้องรอมนุษย์
• ข้อมูลใดเป็น state และข้อมูลใดถูกเก็บเป็น memory

ตอนถัดไปจะตามเส้นทางเอกสาร ตั้งแต่ knowledge base และ chunking ไปจนถึง retrieval, RAG, grounding และ provenance

แหล่งอ้างอิง

• Anthropic: Building effective agents
• OpenAI: A practical guide to building agents
• Anthropic: Trustworthy agents in practice

ตรวจสอบแหล่งอ้างอิงล่าสุด: 17 สิงหาคม 2026