AI Agent ทำงานยังไง: Single Agent
📚 บทความนี้เป็นส่วนหนึ่งของ series Multi-Agent Foundation แนะนำให้อ่านตามลำดับ Level 0 → 1 → 2 → 3 ถ้ายังไม่รู้ว่า AI Agent คืออะไร แนะนำให้อ่าน Level 0 — AI Foundation ก่อนนะ
AI Agent ทำงานยังไง — Single Agent Foundation
สมมติว่าคุณจ้างผู้ช่วยส่วนตัวคนใหม่มาทำงาน
วันแรก คุณบอกเขาว่า “ช่วยหาข้อมูลเรื่องตลาด EV ในไทย แล้วสรุปให้หน่อยนะ”
ผู้ช่วยคนนี้ไม่ได้แค่ตอบว่า “โอเคครับ” แล้วนั่งรอ — เขาลงมือทำเลย
เปิด browser ค้นข้อมูล, จดโน้ตระหว่างทาง, คิดว่าต้องหาอะไรเพิ่ม, แล้วสรุปให้คุณตอนสุดท้าย
AI Agent ตัวเดียวทำงานแบบเดียวกันนั้นแหละ
ต่างกันแค่ว่า แทนที่จะเป็นคน — มันเป็นโปรแกรมที่ขับเคลื่อนด้วย LLM
บทความนี้จะพาคุณเข้าใจว่า Agent ตัวเดียวทำงานยังไง ประกอบด้วยอะไรบ้าง และออกแบบยังไงให้ดี
1. ส่วนประกอบของ Agent — มีอะไรบ้างใน “ตัว” ของ Agent?
ก่อนจะพูดถึง Agent Loop ขอให้เข้าใจก่อนว่า Agent ประกอบด้วยอะไร
ลองนึกภาพผู้ช่วยส่วนตัวคนนั้นอีกที:
- สมุดโน้ต — เขาจดทุกอย่างที่คุณบอก ทุก task ที่รับมา ทุก context ที่จำเป็น
- คู่มือ — กฎที่คุณวางไว้ว่าเขาควรทำอะไร ไม่ควรทำอะไร ทำแบบไหน
- สมอง — ใช้คิดว่าแต่ละ step ควรทำยังไง
Agent ก็มีครบแบบนั้น แต่เรียกชื่อต่างออกไป:
┌──────────────────────────────────────────────────────────────┐
│ AI AGENT │
│ │
│ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │
│ │ CODE │ │ INSTRUCTIONS │ │ LLM │ │
│ │ (Agent Loop) │ │ (Sys. Prompt) │ │ (สมอง Agent) │ │
│ │ │ │ │ │ │ │
│ │ ควบคุมการ │ │ กำหนดว่า │ │ ตัดสินใจ │ │
│ │ ทำงานทั้ง │ │ Agent เป็น │ │ ในแต่ละ │ │
│ │ หมด │ │ ใคร ทำอะไร │ │ step │ │
│ │ │ │ ได้บ้าง │ │ │ │
│ └───────────────┘ └───────────────┘ └───────────────┘ │
└──────────────────────────────────────────────────────────────┘มาทำความเข้าใจแต่ละส่วน:
🔧 Code — ร่างกายของ Agent
Code คือโปรแกรมที่ควบคุมการทำงานของ Agent ทั้งหมด
สิ่งสำคัญที่ต้องเข้าใจ: Agent Loop เป็น Code ไม่ใช่ LLM
LLM แค่ “คิด” ว่าจะทำอะไร — แต่ Code คือตัวที่ลงมือทำจริง เรียก Tool จริง ส่งผลลัพธ์กลับจริง
Code หน้าที่:
- วนซ้ำ Agent Loop
- เรียก LLM ให้คิด
- รัน Tool ตามที่ LLM สั่ง
- จัดการ Context Window
- ตัดสินใจว่าจะหยุด หรือวนต่อ📋 Instructions (System Prompt) — บุคลิกและกฎของ Agent
Instructions คือ “คู่มือ” ที่บอก Agent ว่า:
- เป็นใคร (Role)
- ทำอะไรได้บ้าง (Capabilities)
- ห้ามทำอะไร (Constraints)
- ต้องทำงานแบบไหน (Behavior)
เราจะพูดถึง Instructions Design ให้ลึกขึ้นในหัวข้อถัดไป
🧠 LLM — สมองของ Agent
LLM คือตัวคิด ตัวตัดสินใจ ในแต่ละ Step ของ Agent Loop
มันตอบคำถาม: “ขั้นตอนต่อไปที่ควรทำคืออะไร?”
สิ่งที่ LLM ทำได้:
- อ่าน context ที่มีอยู่
- ตัดสินใจว่า step ต่อไปคืออะไร
- เลือกใช้ Tool ที่เหมาะสม
- สรุปผลลัพธ์ให้ผู้ใช้
สิ่งที่ LLM ทำไม่ได้:
- ลงมือเรียก Tool เอง (Code ทำแทน)
- จำสิ่งที่เกิดขึ้นนอก Context Window
- ทำงานสองอย่างพร้อมกัน
2. Agent Loop — หัวใจของ Agent ทำงานยังไง?
ลองนึกถึงตอนที่คุณทำโปรเจกต์คนเดียว:
- รับ task — อ่านโจทย์ เข้าใจว่าต้องทำอะไร
- คิดแผน — วางขั้นตอนในหัว
- ลงมือทำ step แรก — หาข้อมูล, เขียน, คำนวณ
- ดูผล — ได้ข้อมูลมาแล้ว ต้องทำอะไรต่อ?
- ทำ step ถัดไป — วนซ้ำจนเสร็จ
- ส่งงาน — สรุปผลให้คนที่สั่ง
Agent Loop ทำงานแบบเดียวกันนั้น เรียกว่า Think → Act → Observe loop
Agent Loop: Diagram
┌──────────────────────────────────┐
│ USER INPUT │
│ "หาข้อมูลตลาด EV ในไทย" │
└──────────────┬───────────────────┘
│
▼
┌──────────────────────────────────┐
┌───▶│ THINK (LLM) │
│ │ "ต้องค้นหาอะไรก่อน? │
│ │ ขอใช้ web_search tool" │
│ └──────────────┬───────────────────┘
│ │
│ ▼
│ ┌──────────────────────────────────┐
│ │ ACT (Code) │
│ │ เรียก Tool: web_search │
│ │ query: "ตลาด EV ไทย 2025" │
│ └──────────────┬───────────────────┘
│ │
│ ▼
│ ┌──────────────────────────────────┐
│ │ OBSERVE (Code) │
│ │ ได้ผลลัพธ์: ข้อมูล 5 บทความ │
│ │ ใส่กลับเข้า Context Window │
│ └──────────────┬───────────────────┘
│ │
│ ┌─────────▼──────────┐
│ │ งานเสร็จหรือยัง? │
│ └──┬──────────────┬──┘
│ │ ยัง │ เสร็จแล้ว
└────────────┘ │
▼
┌──────────────────────────┐
│ FINAL RESPONSE │
│ สรุปข้อมูลตลาด EV ไทย │
└──────────────────────────┘แต่ละรอบของ loop เรียกว่า 1 Turn หรือ 1 Step
Agent จะวนซ้ำ loop นี้ไปเรื่อยๆ จนกว่า:
- งานจะเสร็จ
- LLM ตัดสินใจว่าพร้อมตอบ user แล้ว
- เจอ error ที่แก้ไม่ได้
- ถึง step limit ที่กำหนดไว้
ตัวอย่างจริง: Agent ค้นหาและสรุปข้อมูล
Step 1 — THINK: "user อยากรู้เรื่อง EV ไทย ต้องหาข้อมูลก่อน"
Step 1 — ACT: เรียก web_search("ตลาด EV ไทย 2025")
Step 1 — OBS: ได้บทความ 5 ชิ้น
Step 2 — THINK: "มีข้อมูลบางส่วนแล้ว ต้องการตัวเลขยอดขาย"
Step 2 — ACT: เรียก web_search("ยอดขายรถ EV ไทย Q1 2025")
Step 2 — OBS: ได้ตัวเลขยอดขายเพิ่ม
Step 3 — THINK: "มีข้อมูลพอสรุปได้แล้ว"
Step 3 — ACT: ไม่ใช้ Tool แล้ว — สรุปเป็น Final Response3. Context Window Management — Agent “จำ” อะไรได้แค่ไหน?
ลองนึกว่า LLM คือนักเรียนที่กำลังทำข้อสอบ — แต่นักเรียนคนนี้จำอะไรไม่ได้เลย เขาต้องพึ่ง กระดาษทด บนโต๊ะ 100%
กระดาษทดนั้นคือ Context Window
ทุกอย่างที่ LLM “รู้” ในขณะนั้น ต้องอยู่บนกระดาษทดผืนนั้น:
- คำสั่งของ user
- Instructions ของ Agent
- ผลลัพธ์จาก Tool ที่ผ่านมา
- ประวัติการสนทนา
- ข้อมูลที่โหลดมา
ปัญหา: กระดาษทดมีขนาดจำกัด — ถ้าเต็ม ต้องลบอะไรบางอย่างออก
┌─────────────────────────────────────────────────────────┐
│ CONTEXT WINDOW │
│ (เช่น 200,000 tokens) │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ System │ │ Conversation │ │ Tool Results │ │
│ │ Prompt │ │ History │ │ & Documents │ │
│ │ │ │ │ │ │ │
│ │ ~2,000 tok │ │ ~50,000 tok │ │ ~100,000 tok │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ ████████████████████████████████░░░░░░░░░░ 75% used │
└─────────────────────────────────────────────────────────┘สิ่งที่ต้องจัดการใน Context Window
1. ความยาวของ Conversation History
ถ้า Agent คุยกับ user ยาวมาก ประวัติสนทนาจะกินพื้นที่มาก ต้องมีกลยุทธ์ว่าจะเก็บแค่ไหน:
กลยุทธ์ที่ใช้บ่อย:
- Sliding Window — เก็บแค่ N messages ล่าสุด
- Summarization — สรุป history เก่าๆ แทนเก็บทั้งหมด
- Selective Keep — เก็บเฉพาะ message สำคัญ2. ขนาดของ Tool Results
บาง Tool คืนข้อมูลเยอะมาก เช่น อ่านไฟล์ขนาดใหญ่ หรือค้นเว็บได้ผลมา 20 หน้า
ต้องมีการ filter / compress ก่อนใส่เข้า Context:
ก่อนใส่ Tool Result เข้า Context:
- ตัดข้อมูลที่ไม่เกี่ยวออก
- ย่อให้สั้นที่สุดที่ยังมีข้อมูลพอ
- ใส่แค่ส่วนที่ LLM ต้องใช้จริงๆ3. System Prompt Efficiency
System Prompt อยู่ทุก request — ถ้ายาวเกินไปจะกิน token แบบ fixed cost ตลอดเวลา
4. Memory System — Agent จำได้นานแค่ไหน?
คนเรามีความจำสองแบบ:
- Working Memory — สิ่งที่อยู่ในหัวตอนนั้น จำได้แค่ตอนทำงานอยู่
- Long-term Memory — สิ่งที่เขียนลงสมุด ปิดสมุดแล้วก็ยังอยู่
Agent ก็มี Memory สองแบบเหมือนกัน:
┌───────────────────────────────────────────────────────────────┐
│ MEMORY SYSTEM │
│ │
│ ┌───────────────────────┐ ┌───────────────────────────┐ │
│ │ SHORT-TERM MEMORY │ │ LONG-TERM MEMORY │ │
│ │ (Context Window) │ │ (External Storage) │ │
│ │ │ │ │ │
│ │ ✅ เร็ว │ │ ✅ ถาวร │ │
│ │ ✅ ใช้ได่ทันที │ │ ✅ ไม่มีขีดจำกัด │ │
│ │ ❌ จำกัดขนาด │ │ ✅ ข้ามเซสชันได้ │ │
│ │ ❌ หายเมื่อปิด │ │ ❌ ต้องเรียกมาเอง │ │
│ │ session | │ ❌ ช้ากว่า │ │
│ │ │ │ │ │
│ │ เก็บ: │ │ เก็บ: │ │
│ │ - conversation │ │ - user preferences │ │
│ │ - tool results │ │ - project state │ │
│ │ - current task │ │ - learned facts │ │
│ │ │ │ - document summaries │ │
│ └──────────────────────┘ └────────────────────────────┘ │
└───────────────────────────────────────────────────────────────┘ตัวอย่างการใช้งาน
Short-term Memory ทำงานยังไง:
User: "ช่วยวิเคราะห์ไฟล์ sales_data.csv ให้หน่อย"
[Agent อ่านไฟล์ → ใส่ไว้ใน Context Window]
[ทุก Step ต่อจากนี้ LLM "รู้" เนื้อหาไฟล์นั้นตลอด]
[แต่พอปิด session → หายไปหมด]Long-term Memory ทำงานยังไง:
User: "จำไว้ด้วยนะว่าฉันชอบรายงานแบบสั้นๆ"
[Agent บันทึก preference ลง external DB]
[เซสชันหน้า Agent โหลด preference มาก่อน]
[รู้ว่า user ชอบรายงานสั้น → ปรับพฤติกรรมได้]วิธีออกแบบ Memory ที่ดี
สิ่งที่ต้องตัดสินใจเวลาออกแบบ Agent:
คำถาม: ข้อมูลชิ้นนี้ต้องใช้ข้ามเซสชันไหม?
ใช่ → เก็บใน Long-term Memory (DB, Vector Store, ฯลฯ)
ไม่ → ใช้ Context Window พอ
คำถาม: ข้อมูลชิ้นนี้ต้อง search/retrieve ด้วย semantic search ไหม?
ใช่ → Vector Store (เช่น embeddings)
ไม่ → Key-value DB หรือ SQL ธรรมดา
คำถาม: ต้องโหลดข้อมูลทั้งหมดทุก request ไหม?
ไม่ → โหลดเฉพาะที่จำเป็น ประหยัด Context5. System Prompt Design — ออกแบบ “บุคลิก” ของ Agent
ก่อนพนักงานใหม่จะเริ่มงาน HR ต้องเตรียม:
- Job Description — ทำอะไร ไม่ทำอะไร
- Company Policy — กฎที่ต้องปฏิบัติตาม
- Working Style — ต้องทำงานแบบไหน
System Prompt คือ “Job Description” ของ Agent นั่นเอง
โครงสร้าง System Prompt ที่ดี
## Role & Identity
บอกว่า Agent เป็นใคร มีความสามารถอะไร
## Objective
บอก goal หลักว่าต้องทำอะไรให้สำเร็จ
## Capabilities
Tools ที่ใช้ได้ มีอะไรบ้าง ใช้เมื่อไหร่
## Constraints
ห้ามทำอะไร ขีดจำกัดอะไรบ้าง
## Behavior Guidelines
ต้องทำงานแบบไหน สไตล์อะไร
## Output Format
output ที่ดีหน้าตาเป็นยังไงตัวอย่าง System Prompt จริง
# Research Assistant Agent
## Role
คุณคือ Research Assistant ที่เชี่ยวชาญด้านการค้นหาและสรุปข้อมูล
## Objective
ช่วย user ค้นหาข้อมูล วิเคราะห์ และสรุปเป็นรายงานที่ใช้งานได้จริง
## Capabilities
- ใช้ web_search เพื่อค้นหาข้อมูลล่าสุด
- ใช้ read_file เพื่ออ่านเอกสาร
- ใช้ save_note เพื่อบันทึกข้อมูลสำคัญ
## Constraints
- ห้ามสรุปโดยไม่มีแหล่งอ้างอิง
- ห้ามแต่งข้อมูลที่ไม่มีจริง
- ถ้าไม่แน่ใจ ให้บอกว่าไม่แน่ใจ ไม่ใช่เดา
## Behavior
- ค้นหาจาก 2-3 แหล่งก่อนสรุป
- แยกแยะ fact กับ opinion ให้ชัด
- ถ้า task ไม่ชัด ให้ถามก่อนลงมือ
## Output Format
- ขึ้นต้นด้วย TL;DR 2-3 ประโยค
- แยกหัวข้อชัดเจน
- ลงท้ายด้วย Sourcesหลักการเขียน System Prompt ที่ดี
ชัดเจน ไม่คลุมเครือ
❌ "ทำงานได้หลายอย่าง"
✅ "ค้นหาข้อมูลจากเว็บ, อ่านไฟล์ PDF, และสรุปเป็นรายงาน"ระบุพฤติกรรมที่ต้องการ ไม่ใช่แค่บอกห้าม
❌ "ห้ามตอบสั้นเกินไป"
✅ "ทุก response ต้องมีคำอธิบายอย่างน้อย 3 ประโยค พร้อมตัวอย่าง"ให้ตัวอย่าง output ที่ดี
✅ "ตัวอย่าง output ที่ต้องการ: ..."
(LLM เรียนรู้จากตัวอย่างได้ดีมาก)6. Tool Design — ออกแบบ “มือ” ของ Agent
ช่างไม้ที่ดีต้องมีเครื่องมือที่เหมาะกับงาน:
- ค้อน — สำหรับตอกตะปู ไม่ใช่สำหรับขัน
- ไขควง — สำหรับขันสกรู ไม่ใช่สำหรับตัด
- เลื่อย — สำหรับตัด ไม่ใช่สำหรับเจาะ
Tool ของ Agent ก็เหมือนกัน — แต่ละ Tool ควรทำหน้าที่เดียวให้ดีที่สุด
ส่วนประกอบของ Tool ที่ดี
Tool = Name + Description + Parameters + Return Value# ตัวอย่าง Tool Definition (pseudo-code)
tool = {
"name": "web_search",
"description": """
ค้นหาข้อมูลจากอินเทอร์เน็ต
ใช้เมื่อต้องการข้อมูลล่าสุดที่ไม่อยู่ใน context
ไม่ใช้สำหรับข้อมูลที่รู้อยู่แล้ว
""",
"parameters": {
"query": {
"type": "string",
"description": "คำค้นหา ควรเฉพาะเจาะจง เช่น 'Tesla ยอดขาย Q1 2025 ไทย'"
},
"num_results": {
"type": "integer",
"description": "จำนวนผลลัพธ์ที่ต้องการ (1-10)",
"default": 5
}
},
"returns": "list of {title, url, snippet}"
}หลักการออกแบบ Tool ที่ดี
1. Single Responsibility — Tool หนึ่งทำหนึ่งหน้าที่
❌ tool: "search_and_summarize_and_save"
✅ tool: "search" → ค้นหาข้อมูล
✅ tool: "summarize" → สรุปข้อมูล
✅ tool: "save_note" → บันทึกข้อมูล2. Description ต้องบอกให้ได้ว่า “ใช้เมื่อไหร่”
LLM ตัดสินใจเลือก Tool จาก Description ถ้า description คลุมเครือ LLM จะใช้ Tool ผิด
❌ description: "ค้นหาข้อมูล"
✅ description: "ค้นหาข้อมูลจากอินเทอร์เน็ต ใช้เมื่อต้องการข้อมูลล่าสุด
หรือข้อมูลที่ไม่แน่ใจว่าถูกต้อง ไม่ใช้เมื่อรู้คำตอบอยู่แล้ว"3. Error Handling ที่ชัดเจน
Tool ต้องบอก LLM ได้ว่าเกิดอะไรขึ้นเมื่อ error ไม่ใช่แค่ return ว่าง
# แย่
return None
# ดี
return {
"success": False,
"error": "Network timeout after 10s",
"suggestion": "ลองใหม่อีกครั้ง หรือใช้ query ที่ต่างออกไป"
}4. ไม่ให้ Tool ทำงานหนักเกินไป
ถ้า Tool return ข้อมูลเยอะมาก จะกิน Context Window — ควรมี filter หรือ pagination
# แย่: return ข้อมูลทั้งหมด 500 หน้า
return all_documents
# ดี: return แค่ที่เกี่ยวข้อง
return top_k_relevant_documents(query, k=5)7. Permission & Safety Model — Agent ขออนุญาตอะไรบ้าง?
พนักงานในบริษัทมีสิทธิ์ต่างกัน:
- Intern — อ่านเอกสารได้ แต่ลบไม่ได้
- Employee — แก้ไขงานตัวเองได้ ลบของคนอื่นไม่ได้
- Manager — อนุมัติได้ แต่ต้องมี checkpoint บางอย่าง
- Admin — ทำได้ทุกอย่าง แต่มีการ audit
Agent ก็ต้องมีระดับสิทธิ์และ checkpoint แบบเดียวกัน
Permission Levels ของ Agent
┌───────────────────────────────────────────────────────────┐
│ PERMISSION LEVELS │
│ │
│ READ ONLY → อ่านข้อมูล ไม่แก้ไข │
│ ────────────────────────────────────────────────────── │
│ READ + WRITE → แก้ไขได้ แต่ไม่ลบ ไม่ส่ง │
│ ────────────────────────────────────────────────────── │
│ FULL ACCESS → ทำได้ทุกอย่าง │
│ (ต้องระวัง!) │
└───────────────────────────────────────────────────────────┘Human-in-the-Loop — เมื่อไหรต้องให้คนยืนยัน?
ไม่ใช่ทุก action ที่ Agent ควรทำได้เลย บาง action ต้องให้ user ยืนยันก่อน:
ทำได้เลย (ไม่ต้องถาม):
✅ อ่านไฟล์
✅ ค้นหาข้อมูล
✅ คำนวณ
✅ สร้าง draft
ต้องขออนุญาตก่อน:
⚠️ ส่ง email
⚠️ แก้ไขไฟล์สำคัญ
⚠️ เรียก API ที่มีค่าใช้จ่าย
⚠️ ลบข้อมูลMinimal Permission Principle
หลักการสำคัญ: ให้ Agent มีสิทธิ์น้อยที่สุดที่ต้องการ
❌ อย่าให้ Agent มี full admin access ถ้าจริงๆ แค่ต้องการ read access
✅ ให้เฉพาะ permission ที่ task นั้นต้องใช้จริงๆทำไมถึงสำคัญ? เพราะ:
- ถ้า Agent ถูก manipulate (Prompt Injection) — ความเสียหายจำกัด
- ถ้า bug ในโค้ด — ไม่ทำพังทั้งระบบ
- ง่ายต่อการ audit ว่า Agent ทำอะไรไปบ้าง
Safety Patterns ที่ควรใส่ใน Agent
1. Confirmation Gate สำหรับ Destructive Actions
def delete_file(path: str) -> dict:
# ก่อนลบ — ต้องได้รับ confirmation จาก user ก่อน
if not user_confirmed(f"ยืนยันลบไฟล์ {path}?"):
return {"success": False, "reason": "User cancelled"}
# ลบจริง
os.remove(path)
return {"success": True}2. Rate Limiting — ป้องกัน Agent วนซ้ำไม่รู้จบ
MAX_STEPS = 20 # หยุดถ้าเกิน 20 steps
if current_step > MAX_STEPS:
return "หยุดทำงาน: เกิน step limit กรุณาตรวจสอบ task"3. Scope Guard — ป้องกัน Agent ออกนอก scope
ALLOWED_DIRECTORIES = ["/workspace/project"]
def read_file(path: str) -> str:
# ตรวจว่า path อยู่ใน allowed directory
if not path.startswith(tuple(ALLOWED_DIRECTORIES)):
return "Error: Access denied — ไม่อนุญาตอ่านไฟล์นอก project directory"
return open(path).read()✅ Check Your Understanding
ลองตอบคำถามเหล่านี้ดูนะ — ถ้าตอบได้ทั้งหมด แสดงว่าเข้าใจ Level 1 แล้ว
1. ส่วนประกอบ
Agent Loop เป็น Code หรือ LLM? และทำไมถึงสำคัญที่ต้องแยกความเข้าใจนี้ออกจากกัน?
2. Agent Loop
ถ้า Agent กำลัง download ไฟล์ขนาดใหญ่แล้ว network หลุด จะเกิดอะไรขึ้นใน Loop? Agent ควรทำอะไรต่อ?
3. Context Window
Agent กำลังสรุปเอกสาร 50 ไฟล์ แต่ Context Window จุได้แค่ 10 ไฟล์ในครั้งเดียว คุณจะออกแบบให้ Agent จัดการยังไง?
4. Memory System
User บอก preference ว่า “ชอบรายงานแบบสั้น” — ควรเก็บใน Short-term หรือ Long-term Memory? ทำไม?
5. Tool Design
Tool
summarize_and_send_emailทำสองหน้าที่พร้อมกัน มีปัญหาอะไร และจะแก้ยังไง?
6. Permission & Safety
Agent ที่ทำหน้าที่ช่วย user จัดการ email — ควรมี permission อะไรบ้าง และ action ไหนต้องให้ user confirm ก่อน?
📌 Summary — Key Takeaways
ก่อนไป Level 2 ขอให้จำสิ่งเหล่านี้ติดไป:
1. Agent = Code + Instructions + LLM
- Code คือร่างกาย (ควบคุมการทำงาน)
- Instructions คือบุคลิก (กำหนดพฤติกรรม)
- LLM คือสมอง (ตัดสินใจในแต่ละ step)
2. Agent Loop = Think → Act → Observe (วนซ้ำจนเสร็จ)
- LLM คิด → Code รัน Tool → LLM ดูผล → คิดต่อ
3. Context Window = กระดาษทดที่มีขีดจำกัด
- ทุกอย่างที่ LLM "รู้" ต้องอยู่ใน Context
- ถ้าเต็ม ต้องมีกลยุทธ์ว่าจะตัดอะไรออก
4. Memory มีสองระดับ
- Short-term: ใน Context Window (หายเมื่อปิด session)
- Long-term: External Storage (ข้ามเซสชันได้)
5. System Prompt = Job Description ของ Agent
- ต้องชัดเจน ระบุ capabilities + constraints + behavior
6. Tool Design: Single Responsibility
- Tool หนึ่งทำหนึ่งหน้าที่
- Description ต้องบอก "ใช้เมื่อไหร่"
7. Safety: Minimal Permission
- ให้ Agent มีสิทธิ์น้อยที่สุดที่ต้องการ
- Destructive actions ต้องให้ user confirmพร้อมแล้วสำหรับ Level 2? ใน Level 2 เราจะเอา Agent หลายตัวมาทำงานด้วยกัน — มี 1 Lead ที่ควบคุม Subagents ซึ่งทุกตัวมี Context Window ของตัวเองแยกจากกัน
❓ FAQ
Q: ทำไม Agent Loop ถึงต้องเป็น Code ไม่ใช่ให้ LLM ควบคุมเอง?
เพราะ LLM ไม่สามารถ “รัน” อะไรได้ด้วยตัวเอง — มันทำได้แค่ “คิด” และ “แนะนำ” ว่าควรทำอะไร Code ต้องเป็นตัวที่รับคำสั่งจาก LLM แล้วลงมือทำจริง เช่น เรียก API, อ่านไฟล์, หรือส่ง HTTP request ถ้าให้ LLM ควบคุมทุกอย่าง จะไม่มีทางรัน code จริงๆ ได้
Q: Context Window กับ Memory ต่างกันยังไง?
Context Window คือ “สิ่งที่ LLM รู้อยู่ตอนนี้” — ทุกอย่างที่อยู่ใน window นี้ LLM สามารถอ้างอิงได้ทันที ส่วน Memory (Long-term) คือ storage ภายนอกที่เก็บข้อมูลถาวร — จะใช้ได้ก็ต่อเมื่อ Agent โหลดมาใส่ใน Context Window ก่อน พูดง่ายๆ คือ Context Window คือ RAM และ Long-term Memory คือ Hard Drive
Q: System Prompt ควรยาวแค่ไหน?
ไม่มีคำตอบตายตัว แต่หลักคือ “ยาวเท่าที่จำเป็น” System Prompt กินพื้นที่ Context Window ทุก request ถ้ายาวเกินไปจะเปลือง token และอาจทำให้ LLM สับสน ระบุแค่สิ่งที่จำเป็นจริงๆ และทดสอบว่า Agent ทำงานถูกต้องไหม ปกติ 500-2,000 tokens มักพอเพียง
Q: ควรให้ Agent มี Tool เยอะๆ ดีไหม?
ไม่จำเป็น Tool เยอะเกินไปทำให้ LLM สับสนว่าควรใช้อันไหน และเพิ่มความซับซ้อนในการ maintain ควรเริ่มจาก Tool น้อยๆ ที่จำเป็นจริงๆ แล้วเพิ่มเมื่อมีความต้องการชัดเจน หลักการ “ถ้าไม่รู้ว่าต้องใช้ Tool นี้เมื่อไหร่ อย่าเพิ่ม” ใช้ได้ดีมาก
Q: ข้อผิดพลาดที่พบบ่อยในการออกแบบ Agent ตัวเดียวคืออะไร?
ข้อผิดพลาดที่พบบ่อยที่สุดคือ ให้ Agent มี permission มากเกินความจำเป็น เขียน System Prompt คลุมเครือทำให้ Agent ทำงานไม่ตรงที่ต้องการ ไม่มี step limit ทำให้ Agent วนซ้ำไม่รู้จบ และไม่มี error handling ใน Tool ทำให้เมื่อเกิด error แล้ว Agent ไม่รู้จะทำอะไรต่อ
Q: Single Agent ทำอะไรได้บ้าง และขีดจำกัดอยู่ที่ไหน?
Single Agent เหมาะกับงานที่มี workflow ชัดเจน ทำ step-by-step ได้ ไม่ต้องการทำงานหลายอย่างพร้อมกัน เช่น research, summarize, draft, analyze ขีดจำกัดคือทำ parallel tasks ไม่ได้ และถ้างานซับซ้อนมาก Context Window อาจไม่พอ ซึ่งนั่นคือจุดที่ต้องใช้ Agent Team ใน Level 2
