AI & Generative AI

A Practical Guide to Building Agents

คู่มือปฏิบัติ: การสร้าง Agent ด้วย LLM โดย OpenAI

26 May 202528 min readAI AgentDashboard

A Practical Guide to Building Agents

คู่มือปฏิบัติ: การสร้าง Agent ด้วย LLM โดย OpenAI

📌 Connect with me and follow our journey: Linkedin, Facebook

บทความนี้สรุปเนื้อหาสำคัญจากหนังสือ “A practical guide to building agents” โดย OpenAI สำหรับผู้ที่สนใจสามารถดาวน์โหลดเอกสารฉบับเต็มได้ที่: Link

Large Language Models (LLMs) มีความสามารถเพิ่มขึ้นอย่างต่อเนื่องในการจัดการงานที่ซับซ้อนและมีหลายขั้นตอน ความก้าวหน้าในด้าน reasoning, การรองรับข้อมูลหลายรูปแบบ (multimodality) และการใช้เครื่องมือ (tool use) ได้นำไปสู่การเกิดขึ้นของระบบใหม่ที่เรียกว่า Agent ซึ่งขับเคลื่อนด้วย LLM

คู่มือนี้ออกแบบมาสำหรับทีม Product และ Engineering ที่ต้องการเริ่มต้นสร้าง Agent โดยเน้นแนวทางปฏิบัติจริง ตั้งแต่การเลือก use case การออกแบบ logic ไปจนถึงการวางระบบให้ Agent ทำงานได้อย่างปลอดภัยและมีประสิทธิภาพ

1) Agent คืออะไร?

Agent คือระบบที่สามารถดำเนินการตาม workflow แทนผู้ใช้งานได้อย่างอิสระ โดยใช้ความสามารถของ LLM (Large Language Model) เพื่อ:

ดำเนินขั้นตอนต่างๆ ใน workflow อย่างเป็นระบบ
ตัดสินใจเอง ตามสถานการณ์ที่เกิดขึ้น
ตรวจสอบความถูกต้อง ของการทำงานของตนเอง
หยุดการทำงาน หรือส่งต่อกลับให้ผู้ใช้ในกรณีที่ล้มเหลว

1.1) สิ่งที่ไม่ใช่ Agent

แอปพลิเคชันเหล่านี้ไม่ถือเป็น Agent:

Chatbot ธรรมดา
ระบบที่ตอบกลับเพียงครั้งเดียว (single-turn LLM)
Classifier ต่างๆ ที่ทำงานแบบเดียว

1.2) ส่วนประกอบหลักของ Agent

Agent ประกอบด้วย 3 ส่วนหลัก:

Model — LLM สำหรับ reasoning และ decision-making
Tools — API หรือฟังก์ชันภายนอกที่ใช้ดำเนิน action หรือดึงข้อมูล
Instructions — กฎระเบียบหรือ guardrails ที่ควบคุมพฤติกรรม agent

ตัวอย่างการสร้าง Agent พื้นฐาน โดยใช้ OpenAI’s Agents SDK

weather_agent = Agent(
name="Weather agent",
instructions="You are a helpful agent who can talk to users about the weather.",
tools=[get_weather],
)

อธิบายโค้ด:

สร้าง instance ชื่อ weather_agent จากคลาส Agent
ตั้งชื่อ agent ว่า “Weather agent”
ให้คำแนะนำกับ LLM ว่า “คุณเป็น agent ที่ให้ความช่วยเหลือและสามารถพูดคุยกับผู้ใช้เกี่ยวกับสภาพอากาศได้”
ระบุ tools ที่ agent ใช้ได้ คือฟังก์ชัน get_weather ซึ่งน่าจะใช้ดึงข้อมูลสภาพอากาศจากแหล่งข้อมูลภายนอก

1.3) ควรสร้าง Agent เมื่อใด?

การสร้าง Agent เหมาะสมเมื่อ automation แบบเดิม ที่ใช้กฎหรือ logic แบบตายตัวล้มเหลว เช่น:

การตัดสินใจที่ซับซ้อน เช่น การอนุมัติคืนเงินที่มีข้อยกเว้นหรือเงื่อนไขเฉพาะ
ระบบ rule-based ที่ยุ่งยาก เช่น การตรวจสอบความปลอดภัยของ vendor
ข้อมูลไม่มีโครงสร้าง เช่น การอ่านเอกสารหรือสนทนากับผู้ใช้

หากปัญหาสามารถแก้ด้วยระบบ deterministic (เชิงกำหนดแน่นอน, rule-based) ได้ ควรใช้วิธีนั้นก่อน

2) การเลือก Model ✅

หลักการพื้นฐาน

ไม่จำเป็นต้องใช้โมเดลที่ใหญ่ที่สุดกับทุกงาน

งานง่าย เช่นการดึงข้อมูลหรือแยก intent ใช้โมเดลขนาดเล็กก็พอ
งานที่ซับซ้อน เช่น ตัดสินใจคืนเงิน ควรใช้โมเดลที่มีความสามารถสูง

แนวทางแนะนำ

เริ่มต้นด้วยโมเดลที่ดีที่สุด → เพื่อให้ได้ baseline
ค่อยๆ ลองโมเดลเล็กลง → เพื่อประหยัด latency และต้นทุน
ใช้การ evaluate อย่างเป็นระบบ → เพื่อวัดผลอย่างแม่นยำ

Note:
- สามารถใช้หลาย model ได้ใน workflow เดียว (e.g., classification ด้วย model เล็ก, decision ด้วย model ใหญ่)
- อ่านเพิ่มเติมได้ที่ https://platform.openai.com/docs/guides/model-selection

3) การกำหนด Tools 🔨

Tools คือช่องทางที่ Agent ใช้เพื่อกระทำบางอย่างในโลกภายนอก เช่น เรียก API, อ่าน PDF, ส่งข้อความ, สั่งคืนเงิน

ประเภทของ Tools

Data tools: ดึงข้อมูลจากแหล่งต่าง ๆ (e.g., databases, PDFs, web search)
Action tools: ส่งข้อมูล, อัปเดตระบบ (e.g., ส่งอีเมล, ปรับข้อมูล CRM)
Orchestration tools: Agent อื่น ๆ ที่ทำหน้าที่เฉพาะ (e.g., refund agent, research agent)

แนะนำให้เขียน Tools แบบ reusable และมี spec ที่ชัดเจน
→ ป้องกันการซ้ำซ้อนและง่ายต่อการจัดการเวอร์ชัน

ตัวอย่างการนิยาม Agent และ Tool ด้วย Python:

นำเข้า class และฟังก์ชันที่จำเป็นจาก agents SDK

- Agent: สำหรับสร้าง agent

- WebSearchTool: เครื่องมือสำหรับค้นหาข้อมูล

- function_tool: แปลงฟังก์ชันให้ agent เรียกใช้เป็น tool ได้

from agents import Agent, WebSearchTool, function_tool

ใช้ decorator เพื่อให้ฟังก์ชันนี้กลายเป็นเครื่องมือที่ agent ใช้ได้

@function_tool
def save_results(output):
# บันทึกผลลัพธ์ลงใน database พร้อม timestamp
db.insert({"output": output, "timestamp": datetime.time()})
return "File saved" # ส่งข้อความยืนยันกลับ

นิยาม agent ชื่อ "Search agent"

search_agent = Agent(
name="Search agent", # ตั้งชื่อ agent
instructions="Help the user search the internet and save results if asked.", # คำอธิบายหน้าที่ของ agent
tools=[ # รายชื่อเครื่องมือที่ agent ใช้ได้
WebSearchTool(), # เครื่องมือค้นหาข้อมูลจากอินเทอร์เน็ต
save_results # ฟังก์ชันสำหรับบันทึกผลลัพธ์
],
)

“หากเครื่องมือที่ต้องใช้มีจำนวนมาก ควรพิจารณาแยก agent ออกเป็นหลายตัว (ดูหัวข้อ Orchestration)”

4) การกำหนดคำสั่ง (Instructions) 🧭

ทำไม Instructions สำคัญ?

Instructions ที่เขียนดีคือหัวใจของแอปพลิเคชันที่ใช้ LLM โดยเฉพาะเมื่อเป็น Agent เพราะช่วยให้:

เข้าใจหน้าที่ตนเอง อย่างชัดเจน
ลดความคลุมเครือ (ambiguity) ในการตัดสินใจ
ลดข้อผิดพลาด ในการดำเนินงาน
ทำงานตาม workflow ได้อย่างราบรื่น

แนวทางปฏิบัติที่ดี

อ้างอิงจากเอกสารที่มีอยู่: เช่น knowledge base, SOPs
แบ่ง task ให้ชัดเจน: ลดความกำกวมจากข้อมูลที่ซับซ้อน
กำหนด action ชัดเจน: ทุกขั้นควรมีเป้าหมายชัดเจน เช่น “ดึงข้อมูล order” หรือ “ถามชื่อผู้ใช้”
จัดการ edge cases: เช่น ถ้าผู้ใช้ตอบไม่ครบ ให้ระบุวิธีรับมือใน instruction

Tip: ใช้ model อย่าง o1 หรือ o3-mini เพื่อแปลงเอกสารเป็น instruction อัตโนมัติ

ตัวอย่าง Prompt

English version

"You are an expert in writing instructions for an LLM agent. Convert the
following help center document into a clear set of instructions, written in
a numbered list. The document will be a policy followed by an LLM. Ensure
that there is no ambiguity, and that the instructions are written as
directions for an agent. The help center document to convert is the
following {{help_center_doc}}"

Thai version

"คุณเป็นผู้เชี่ยวชาญในการเขียนคำแนะนำสำหรับ LLM agent.
โปรดแปลงเอกสาร help center ด้านล่างให้กลายเป็นชุดคำแนะนำที่ชัดเจน
โดยใช้รูปแบบลำดับหมายเลข (numbered list). เอกสารนี้จะเป็นนโยบายที่ LLM ต้องปฏิบัติตาม.
โปรดแน่ใจว่าไม่มีความกำกวม และเขียนคำแนะนำในรูปแบบที่เป็นคำสั่งสำหรับ agent.
เอกสาร help center ที่จะแปลงคือ {{help_center_doc}}"

5) Orchestration

เมื่อคุณมีองค์ประกอบพื้นฐานของ Agent แล้ว ขั้นต่อไปคือการวางโครงสร้างการทำงาน (Orchestration) เพื่อให้ Agent จัดการ workflow ได้อย่างมีประสิทธิภาพ

🎯 หลักการสำคัญ

แม้จะน่าดึงดูดใจที่จะเริ่มด้วยระบบซับซ้อนแบบ full-autonomy แต่ลูกค้าส่วนใหญ่ประสบความสำเร็จมากกว่าเมื่อเริ่มแบบค่อยเป็นค่อยไป

รูปแบบของ Orchestration

Single-agent systems: ใช้ Agent เดียว จัดการทุกอย่างใน loop เดียว โดยมี tools และ instructions ที่จำเป็น
Multi-agent systems: แบ่งงานออกให้ Agent หลายตัวร่วมกันทำงาน โดยแต่ละตัวรับผิดชอบ task หรือ domain ที่ต่างกัน

5.1) Single-agent systems

Agent เดียวสามารถรับผิดชอบ task ได้มากมาย โดยแค่เพิ่ม tools ทีละตัว ช่วยควบคุมความซับซ้อนและทำให้ประเมินผลง่าย

ข้อดี

ควบคุมง่าย — Agent เดียวสามารถรับผิดชอบ task ได้มากมาย
ประเมินผลง่าย — ไม่ซับซ้อนในการติดตาม
เพิ่ม tools ทีละตัว — ช่วยควบคุมความซับซ้อน

การทำงาน

Agent ทำงานเป็น loop จนกว่าเงื่อนไขสิ้นสุดจะเกิดขึ้น:

ได้คำตอบสุดท้าย
ไม่มีการเรียกใช้ tools เพิ่ม
เกิดข้อผิดพลาด

ตัวอย่างการเรียกใช้ Agent:

เรียกใช้งาน agent โดยส่งข้อความจากผู้ใช้เข้าไป

Agents.run(agent, [UserMessage("What's the capital of the USA?")])

Agents.run(...): สั่งให้ agent ทำงาน โดยใช้ข้อความจากผู้ใช้เป็น input

UserMessage(...): แปลงข้อความผู้ใช้ให้อยู่ในรูปแบบที่ agent เข้าใจและนำไปประมวลผลได้

Prompt templates: ใช้ template ที่มีตัวแปรแทนค่าต่าง ๆ ซึ่งช่วยให้เราสามารถใช้โครงสร้างเดิมซ้ำได้ โดยเพียงเปลี่ยนค่าตัวแปร เช่น

ใช้ prompt template สำหรับ agent ในงาน call center

ใช้ตัวแปร (เช่น {{user_first_name}}) แทนข้อมูลเฉพาะเคส เพื่อให้สามารถนำไป reuse ได้ในหลาย context

'''You are a call center agent. You are interacting with {{user_first_name}}
who has been a member for {{user_tenure}}. The user's most common complains are about
{{user_complaint_categories}}. Greet the user, thank them for being a loyal customer,
and answer any questions the user may have!'''

เมื่อใดควรใช้หลาย Agent?

แนวทางแนะนำ: ใช้ Agent เดียวให้ถึงขีดสุดก่อน เพราะแม้การแยกหลาย Agent จะช่วยแบ่งงานได้ดี แต่มันก็เพิ่มความซับซ้อน

เหตุผลที่ควรพิจารณา Multi-Agent:

Logic ซับซ้อนเกินไป: เช่น Prompt มีหลาย if-else จน template ขยายไม่ไหว
Tool overload:

จำนวนไม่ใช่ปัญหาเสมอไป
แต่ถ้า tool ซ้ำซ้อนหรือคล้ายกันมาก ควรแยกออกให้ชัด
ตั้งชื่อให้ดี และระบุ parameter ชัดเจน

6) Multi-agent Patterns

มี 2 รูปแบบหลักจากการใช้งานจริง:

6.1) Manager Pattern (Agent เป็นตัวจัดการ Tool)

โครงสร้าง

มี Agent กลาง (Manager) ที่ควบคุม agents ย่อยผ่านการเรียกใช้ tools
Agent ย่อยกลายเป็น tools ที่ Manager เรียกใช้

ตัวอย่าง: Manager ควบคุม

Spanish Agent
French Agent
Italian Agent

นำเข้า Agent และ Runner จาก agents SDK

from agents import Agent, Runner

นิยาม agent ตัวกลางชื่อ "manager_agent"

มีหน้าที่จัดการการแปลภาษา โดยเรียกใช้ agent เฉพาะทางผ่าน tools

manager_agent = Agent(
name="manager_agent", # ชื่อ agent
instructions="If asked for multiple translations, you call the relevant tools.", # คำสั่งให้ agent รู้ว่าต้องเลือก tool ที่เหมาะสม
tools=[
# ผูก agent ย่อยให้เป็น tools ที่สามารถเรียกใช้ได้
spanish_agent.as_tool(
tool_name="translate_to_spanish", # ชื่อเรียกของ tool
tool_description="Translate the user's message to Spanish", # คำอธิบาย tool
),
french_agent.as_tool(
tool_name="translate_to_french",
tool_description="Translate the user's message to French",
),
italian_agent.as_tool(
tool_name="translate_to_italian",
tool_description="Translate the user's message to Italian",
),
],
)

ฟังก์ชันหลักแบบ async สำหรับรับ input และรัน agent

async def main():
# รับข้อความจากผู้ใช้
msg = input("Translate 'hello' to Spanish, French and Italian for me!")

# รัน manager_agent โดยใช้ข้อความจากผู้ใช้เป็น input  
orchestrator_output = await Runner.run(  
    manager_agent, msg)  

# วนลูปเพื่อแสดงผลลัพธ์การแปลจากแต่ละ agent  
for message in orchestrator_output.new_messages:  
    print(f" - Translation step: {message.content}")

ข้อดี

ควบคุมการทำงานได้ชัดเจน
เหมาะกับงานที่ต้องการการจัดการแบบรวมศูนย์

6.2) Decentralized Pattern (Agent ส่งงานต่อกัน)

โครงสร้าง

Agent ทำงานเป็น peer (ไม่มี agent ตัวใดเป็นหัวหน้า)
สามารถ handoff (ส่งต่อ) งานให้กันเอง
ใช้โครงสร้างแบบ Graph ได้ โดยมี Agent เป็น node

ตัวอย่าง Workflow

ลูกค้าถามเรื่อง order
triage_agent ตรวจสอบว่าเป็นเรื่อง "ติดตาม order"
ส่งต่อไปยัง order_management_agent
หรือถ้าเป็นเรื่องเทคนิค → ส่งไป technical_support_agent

นำเข้า Agent และ Runner จาก Agents SDK

from agents import Agent, Runner

สร้าง agent สำหรับให้ความช่วยเหลือด้านเทคนิค

technical_support_agent = Agent(
name="Technical Support Agent", # ชื่อ agent
instructions="ช่วยแก้ปัญหาทางเทคนิค เช่น การใช้งานระบบหรือปัญหาอื่น ๆ", # คำอธิบายหน้าที่ของ agent
tools=[search_knowledge_base] # ใช้ tool สำหรับค้นหาข้อมูลจาก knowledge base
)

สร้าง agent สำหรับช่วยงานขาย

sales_assistant_agent = Agent(
name="Sales Assistant Agent",
instructions="แนะนำสินค้า ช่วยในการสั่งซื้อ", # อธิบายว่า agent นี้เน้นเรื่องการขาย
tools=[initiate_purchase_order] # ใช้ tool สำหรับเปิดคำสั่งซื้อ
)

สร้าง agent สำหรับจัดการคำสั่งซื้อ

order_management_agent = Agent(
name="Order Management Agent",
instructions="ติดตามคำสั่งซื้อ, คืนสินค้า, ตรวจสอบสถานะการส่ง", # หน้าที่ของ agent คือดูแลคำสั่งซื้อ
tools=[track_order_status, initiate_refund_process] # tools ที่ใช้ติดตามสถานะและดำเนินการคืนสินค้า
)

สร้าง agent ตัวแรกที่ทำหน้าที่คัดกรองคำถาม แล้วส่งต่อไปยัง agent ที่เหมาะสม

triage_agent = Agent(
name="Triage Agent",
instructions="เป็นด่านแรกของระบบ รับคำถามลูกค้าและส่งไปยัง agent ที่เหมาะสม", # เป็นคนคัดกรองคำถาม
handoffs=[technical_support_agent, sales_assistant_agent, order_management_agent] # รายชื่อ agent ที่สามารถส่งต่อได้
)

เรียกใช้ triage_agent โดยให้รับ input จากผู้ใช้

await Runner.run(
triage_agent,
input("Could you please provide an update on delivery?") # คำถามจากผู้ใช้เกี่ยวกับการส่งของ
)

ใช้ดีในกรณีที่ต้องการให้ agent เฉพาะด้านจัดการ task โดยตรง เช่น แยก conversation ตามประเภท

ข้อดี

เหมาะกับ workflow ที่แยกเป็นส่วนชัดเจน
ยืดหยุ่นในการส่งต่องาน
Handoff จะถ่ายโอนสถานะการสนทนาไปยัง agent ใหม่ทันที

7) การออกแบบระบบ: Declarative vs Non-declarative

7.1) Declarative Systems

“กำหนดล่วงหน้าว่า agent ไหนทำอะไรบ้าง”

ลักษณะ

ต้องกำหนดทุกขั้นของ workflow ล่วงหน้า
แสดงเป็นโครงสร้าง (graph): node = agent, edge = ทางเดิน/handoff
ใช้ tools อย่าง GUI หรือ DSL ในการวาง flow

ข้อดี/ข้อเสีย

✅ เหมาะกับภาพรวมที่ชัดเจน และระบบที่ “ตายตัว”
❌ ยุ่งยากมากเมื่อ workflow ซับซ้อน
❌ ต้องเรียน DSL (domain-specific language)

7.2) Non-declarative Systems

“เขียน logic เป็นโค้ดเพื่อบอก agent ต้องทำอะไรเมื่อไร”

ลักษณะ

ใช้แนวทาง code-first → เขียน logic เป็นโค้ด Python ตรงๆ
ยืดหยุ่นสูง ปรับเปลี่ยน runtime ได้
ไม่ต้องวางแผนเส้นทางทั้งหมดล่วงหน้า

ข้อดี

✅ เหมาะกับระบบ dynamic
✅ ยืดหยุ่นและง่ายต่อการเปลี่ยนแปลง
✅ เขียน if/else, await, และ for เพื่อควบคุมการทำงาน

ทบทวน

8) Guardrails: ระบบป้องกันความเสี่ยง 🛡️

Guardrails คืออะไร?

กลไกเพื่อป้องกัน LLM จากการประมวลผลข้อมูลผิด หรือตอบโต้ในลักษณะที่ไม่ปลอดภัย

การรั่วไหลของข้อมูล
การตอบสนองที่ไม่เหมาะสม
การโจมตีด้วย prompt injection

ประเภทของ Guardrails

Guardrails ที่ดีควรมีหลายชั้นเพื่อป้องกันในหลายระดับ:

1. Input Protection: เน้นการป้องกันตั้งแต่ ก่อน agent ประมวลผล

Relevance classifier: กรอง input ที่ไม่เกี่ยวข้องกับ scope ของ agent
Safety classifier: ป้องกัน prompt injection หรือ jailbreak
PII filter: กรองข้อมูลส่วนตัว (เช่น อีเมล, เบอร์โทร)
Rules-based protections: การป้องกันพื้นฐาน เช่น blocklist, regex, ขนาด input

🧠 แนวคิด: “ไม่ให้ของอันตรายเข้าไปใน agent”

2. Processing Protection: เน้นที่การควบคุม กระบวนการทำงานภายใน

Moderation: ป้องกันไม่ให้ agent ประมวลผลหรือโต้ตอบกับเนื้อหาที่ไม่เหมาะสม เช่น ความรุนแรง, hate speech
Tool safeguards: ประเมินและจำกัดการใช้งาน tools ที่มีความเสี่ยง เช่น เขียนข้อมูล, ทำธุรกรรม (low, medium, high)

🧠 แนวคิด: “แม้ input ผ่านแล้ว ก็ต้องระวังเวลาทำงาน”

3. Output Protection: ตรวจสอบ ผลลัพธ์ก่อนส่งกลับให้ผู้ใช้

Output validation: ตรวจสอบให้คำตอบเหมาะสม สอดคล้องกับ brand หรือมาตรฐานองค์กร

🧠 แนวคิด: “ตรวจให้แน่ใจก่อนส่งออก ว่าไม่มีเนื้อหาที่เสี่ยง”

แนวทางสร้าง Guardrails ที่ดี

เริ่มจากสิ่งที่เสี่ยงที่สุด เช่น ความปลอดภัยของข้อมูล
ปรับปรุงตาม feedback จาก real-world failures
หาจุดสมดุลระหว่างการปกป้องและประสบการณ์ผู้ใช้

ตัวอย่างการตั้งค่า Guardrail ใน Agents SDK:

Churn Detection Guardrail ด้วย Agents SDK

Import class และฟังก์ชันที่เกี่ยวข้องจาก agents SDK

from agents import (
Agent,
GuardrailFunctionOutput,
InputGuardrailTripwireTriggered,
RunContextWrapper,
Runner,
TResponseInputItem,
input_guardrail,
Guardrail,
GuardrailTripwireTriggered
)

ใช้ pydantic เพื่อ define schema ของ output

from pydantic import BaseModel

Define รูปแบบผลลัพธ์ของ agent ตรวจจับ churn

class ChurnDetectionOutput(BaseModel):
is_churn_risk: bool # บอกว่าเป็นความเสี่ยงจะ churn ไหม
reasoning: str # เหตุผลที่ model ประเมินแบบนั้น

นิยาม agent สำหรับตรวจจับ churn

churn_detection_agent = Agent(
name="Churn Detection Agent",
instructions="Identify if the user message indicates a potential customer churn risk.",
output_type=ChurnDetectionOutput,
)

Guardrail function: ใช้ agent ตรวจจับ churn แล้วส่งผลกลับ

@input_guardrail
async def churn_detection_tripwire(
ctx: RunContextWrapper[None],
agent: Agent,
input: str | list[TResponseInputItem]
) -> GuardrailFunctionOutput:
result = await Runner.run(churn_detection_agent, input, context=ctx.context)
return GuardrailFunctionOutput(
output_info=result.final_output,
tripwire_triggered=result.final_output.is_churn_risk, # trigger ถ้าเสี่ยง churn
)

Agent ตัวหลักที่ให้บริการลูกค้า และใช้ guardrail ตรวจจับข้อความเสี่ยง

customer_support_agent = Agent(
name="Customer support agent",
instructions="You are a customer support agent. You help customers with their questions.",
input_guardrails=[
Guardrail(guardrail_function=churn_detection_tripwire),
],
)

ทดสอบข้อความปกติ

async def main():
# This should be ok
await Runner.run(customer_support_agent, "Hello!")
print("Hello message passed")

ทดสอบข้อความที่น่าจะทำให้ guardrail ทำงาน

This should trip the guardrail

try:
await Runner.run(customer_support_agent, "I think I might cancel my subscription")
print("Guardrail didn't trip – this is unexpected")
except GuardrailTripwireTriggered:
print("Churn detection guardrail tripped")

การทำงานของ Guardrails

Agent SDK ใช้แนวคิด Optimistic Execution คือให้ Agent ทำงานไปเลย แล้วให้ Guardrail ทำงานขนานกัน หากพบปัญหา (เช่น violation หรือความเสี่ยง) จะ throw exception ขึ้นมา

Guardrail สามารถเขียนเป็นฟังก์ชัน หรืออีก agent ก็ได้ เพื่อทำงานอย่างเช่น:

ป้องกัน jailbreak
ตรวจสอบความเกี่ยวข้องของ input
กรอง keyword หรือคำต้องห้าม
ป้องกันข้อมูลอันตราย

การวางแผนรองรับ Human Intervention

Human-in-the-loop เป็นวิธีสำคัญในการปรับปรุง Agent ให้ดีขึ้น โดยไม่ลดคุณภาพประสบการณ์ของผู้ใช้ โดยเฉพาะในช่วงแรกของการ deploy

กรณีที่ควรให้คนเข้ามาช่วย

เกิดความล้มเหลวเกินจำนวนครั้งที่กำหนด (Exceeding Failure Thresholds)
เช่น Agent พยายามเข้าใจเจตนาผู้ใช้หลายรอบแล้วยังไม่สำเร็จ
ต้องทำ Action ที่เสี่ยงหรือมีผลกระทบสูง (High-risk actions)
เช่น ยกเลิกออเดอร์, อนุมัติเงินคืน, จ่ายเงิน

ตัวอย่างการใช้งาน

ฝ่ายบริการลูกค้า → escalate ปัญหาให้เจ้าหน้าที่จริง
Agent เขียนโค้ด → ส่งต่อให้ผู้ใช้ดูแลเอง

9) บทสรุป (Conclusion)

Agent: จุดเปลี่ยนของ Automation

Agent คือจุดเปลี่ยนใหม่ของการทำ Automation แบบมีความสามารถ:

คิด วิเคราะห์
จัดการงานหลายขั้นตอนแบบอัตโนมัติ

ความแตกต่างจากแอปทั่วไป

ต่างจากแอปที่ใช้ LLM แบบง่าย (เช่น Chatbot), Agent สามารถควบคุม Workflow แบบ end-to-end

เหมาะกับงานประเภท

การตัดสินใจซับซ้อน
ข้อมูลไม่เป็นโครงสร้าง
ระบบกฎที่เปราะบาง

สิ่งสำคัญในการสร้าง Agent ที่เชื่อถือได้

1. พื้นฐานที่แข็งแกร่ง

ใช้ model ที่เหมาะสม
เครื่องมือ (Tools) ที่นิยามไว้ชัดเจน
ออกแบบ instructions ที่มีโครงสร้าง

2. การขยายตัวอย่างมีระบบ

เริ่มจาก Single-agent แล้วค่อยขยายไป Multi-agent
มี Guardrails ครอบคลุมตั้งแต่ input → output → human fallback

3. การพัฒนาแบบค่อยเป็นค่อยไป

เริ่มต้นจากสิ่งเล็กๆ
ทดสอบกับผู้ใช้จริง
แล้วค่อยๆ ขยาย

เมื่อวางพื้นฐานถูกต้อง Agent จะช่วยธุรกิจได้มากกว่าแค่ “ทำงานแทน”
— มันจะ “คิดและปรับตัวได้” ด้วย

Key Takeaways

Agent คือระบบที่ใช้ LLM จัดการ workflow แบบอัตโนมัติและยืดหยุ่น เหมาะกับงานที่ rule-based automation ธรรมดาไม่สามารถจัดการได้ดี
องค์ประกอบหลักของ Agent ได้แก่ Model, Tools และ Instructions ที่ต้องทำงานร่วมกันอย่างเป็นระบบ
ควรเริ่มด้วยโมเดลที่มีประสิทธิภาพสูงเพื่อวาง baseline แล้วค่อยปรับให้ประหยัดต้นทุนภายหลัง
Tools ควรแบ่งตามหน้าที่ ได้แก่ data access, action execution และ orchestration สำหรับควบคุม agent อื่น ๆ
Instructions ที่เขียนดีช่วยให้ Agent ตัดสินใจแม่นยำ ลด error และ handle edge cases ได้ดียิ่งขึ้น
เริ่มจากระบบ Single-agent เพื่อความเรียบง่าย และใช้ Prompt Templates เพื่อบริหารจัดการคำสั่งได้สะดวกขึ้น
หาก workflow ซับซ้อนเกินไป ควรแยกเป็น Multi-agent system โดยเลือกใช้ Manager หรือ Decentralized pattern ตามลักษณะงาน
Decentralized orchestration ช่วยให้ agents สื่อสารและ handoff งานให้กันได้อย่างยืดหยุ่น
Guardrails คือกลไกสำคัญที่ช่วยให้ agent ปลอดภัยและป้องกันการใช้งานผิดพลาด เช่น prompt injection หรือการรั่วข้อมูล
Human intervention เป็นทางเลือกสำรองที่จำเป็นเมื่องานมีความเสี่ยงสูงหรือ agent ตัดสินใจผิดพลาดบ่อย

Terminology (ศัพท์สำคัญ)

Agent — ระบบที่ใช้ LLM ทำงานแทนมนุษย์โดยอัตโนมัติ
LLM (Large Language Model) — โมเดลภาษาขนาดใหญ่ที่สามารถเข้าใจและวิเคราะห์ข้อมูล
Workflow — ลำดับขั้นตอนที่ต้องดำเนินเพื่อให้บรรลุเป้าหมาย
Model — โมเดล LLM ที่ใช้ในการตัดสินใจของ Agent
Tools — ฟังก์ชันหรือ API ที่ Agent ใช้ในการกระทำบางอย่าง
Instructions — คำแนะนำหรือคำสั่งที่กำหนดพฤติกรรมของ Agent
Prompt Template — โครงร่างข้อความที่ใช้สร้างคำสั่งแบบ dynamic
Orchestration — การจัดการ workflow ด้วยการประสานงานระหว่าง agent
Single-agent system — ระบบที่ใช้ agent ตัวเดียวในการจัดการทั้ง workflow
Multi-agent system — ระบบที่แบ่งงานให้หลาย agent ทำงานร่วมกัน
Manager pattern — รูปแบบที่มี agent กลางควบคุม agent อื่น ๆ
Decentralized pattern — รูปแบบที่ agent handoff งานให้กันโดยตรง
Handoff — การส่งต่อการควบคุมและ context ไปยัง agent อื่น
Guardrails — ข้อจำกัดหรือกลไกควบคุมความปลอดภัยของ agent
Tripwire — กลไกตรวจจับ input/output ที่เสี่ยงหรือผิดปกติ
Prompt Injection — เทคนิคการโจมตีโดยใช้ข้อความเพื่อหลอก model
Optimistic Execution — ให้ agent ทำงานทันทีพร้อมตรวจสอบความปลอดภัยควบคู่
Classifier — ระบบที่ใช้จำแนกประเภทของ input เช่น relevant หรือ unsafe
PII (Personally Identifiable Information) — ข้อมูลส่วนบุคคล เช่น อีเมล หมายเลขโทรศัพท์
Human Intervention — การให้มนุษย์เข้ามาช่วยเมื่อ agent ตัดสินใจผิดหรือเกิดความเสี่ยงสูง