Thanawat Wongchai

Posted on Jun 4 • Originally published at apidog.com

เอไอ เอเจนต์ ดีบักเกอร์ คืออะไร

AI Agent Debugger คือเครื่องมือดีบักแบบภาพสำหรับนักพัฒนาที่สร้าง AI Agent โดยช่วยให้เห็นการทำงานของ Agent ตั้งแต่พรอมต์ การเรียกโมเดล การเรียกเครื่องมือ อินพุต/เอาต์พุต ข้อผิดพลาด ไปจนถึงผลลัพธ์สุดท้าย แทนที่จะดูแค่ input/output ของโมเดล คุณสามารถไล่ trace ได้ว่า Agent ตัดสินใจอะไรในแต่ละขั้นตอน

ลองใช้ Apidog วันนี้

ถ้าคุณเคยถามว่า ทำไม Agent ถึงเรียกเครื่องมือนั้น?, ทำไม response ช้า?, หรือ ทำไมใช้ token เยอะ? AI Agent Debugger คือเครื่องมือที่ช่วยตอบคำถามเหล่านี้ด้วยข้อมูลจริงจากแต่ละ session

ทำไม AI Agent จึงดีบักยาก

AI Agent ดีบักยากกว่าโค้ดทั่วไป เพราะ workflow ไม่ได้เป็นเส้นตรงและผลลัพธ์ไม่ได้ deterministic เสมอไป

1. พฤติกรรมที่ไม่แน่นอน (Non-Deterministic Behavior)

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

แนวทางดีบัก: รันงานเดียวกันหลายครั้ง แล้วเปรียบเทียบ trace, token usage, latency และลำดับ tool calls

2. ห่วงโซ่การให้เหตุผลที่ยาวนาน (Long Reasoning Chains)

Agent สมัยใหม่ไม่ได้สร้างข้อความอย่างเดียว แต่ยังวางแผน เรียก API ใช้เครื่องมือ และวนซ้ำหลาย step ข้อผิดพลาดใน step ต้นๆ อาจไปแสดงผลลัพธ์ผิดใน step ท้ายๆ

แนวทางดีบัก: ตรวจลำดับ execution trace จากบนลงล่าง โดยดูว่า step ไหนเริ่ม diverge จากพฤติกรรมที่คาดไว้

3. ปัญหา Black Box

คุณไม่สามารถตั้ง breakpoint ในโมเดลได้เหมือนโค้ดทั่วไป สิ่งที่ตรวจสอบได้คือ input, output, tool calls และ metadata รอบการรัน

แนวทางดีบัก: บันทึก prompt, model response, tool input/output และ error message ของทุก step

4. ความซับซ้อนในการใช้งานเครื่องมือ

Agent อาจเรียกเครื่องมือผิด ส่งพารามิเตอร์ผิด หรือเจอ error จาก API ภายนอก หากไม่มี trace ของ tool calls จะยากมากที่จะระบุสาเหตุ

แนวทางดีบัก: ตรวจทุก tool call ว่า:

เรียกเครื่องมือถูกตัวหรือไม่
เรียงลำดับถูกต้องหรือไม่
arguments ถูก schema หรือไม่
response/error จากเครื่องมือคืออะไร

5. การระบุแหล่งที่มาของข้อผิดพลาด

เมื่อ Agent ล้มเหลว สาเหตุอาจอยู่ที่ prompt, model, tool, MCP server, auth หรือ orchestration logic

AI Agent Debugger ช่วยลดการคาดเดาด้วยการทำให้ทุก step มองเห็นได้

AI Agent Debugger ทำอะไร?

AI Agent Debugger แสดง execution trace แบบมีโครงสร้าง เพื่อให้คุณตรวจสอบ session ของ Agent ได้แบบ step-by-step

การติดตามการทำงานที่สมบูรณ์ (Complete Execution Trace)

โดยทั่วไป trace จะประกอบด้วย:

User prompt และ system prompt — ตรวจสอบบริบทที่ส่งเข้าโมเดลจริง
Model calls — request/response ของ LLM ทุกครั้ง
Thinking process — หากโมเดลรองรับ เช่น Claude
Tool calls — เครื่องมือ MCP หรือ built-in functions ที่ Agent เรียกใช้
Tool input/output — arguments และผลลัพธ์ที่ส่งกลับ
Errors/exceptions — จุดที่ล้มเหลวและรายละเอียด error
Final output — ผลลัพธ์สุดท้ายของ Agent

เมตริกเซสชัน (Session Metrics)

ใช้วิเคราะห์ performance และ cost ได้ เช่น:

Response time — แต่ละ step ใช้เวลานานเท่าใด
Token usage — input tokens, output tokens, cached tokens
Estimated cost — ค่าใช้จ่ายโดยประมาณของ session
Conversation turns — จำนวนรอบโต้ตอบ
Execution steps — จำนวน actions ที่ Agent ทำ

การเปรียบเทียบโมเดล

คุณสามารถรันงานเดียวกันด้วยหลายโมเดลแล้วเปรียบเทียบ:

โมเดลใดจบงานใน step น้อยกว่า
โมเดลใดเลือกเครื่องมือได้แม่นยำกว่า
โมเดลใด latency ต่ำกว่า
โมเดลใดใช้ token และ cost น้อยกว่า

กรณีการใช้งานหลักสำหรับ AI Agent Debugger

1. ดีบักห่วงโซ่การเรียกใช้เครื่องมือ

เมื่อ Agent เรียกเครื่องมือผิดหรือให้ผลลัพธ์ไม่ตรงคาด ให้ตรวจ:

เครื่องมือใดถูกเรียก และเรียกตามลำดับใด
arguments ที่ส่งให้แต่ละเครื่องมือ
response ที่เครื่องมือส่งกลับ
step ที่เริ่มเกิดผลลัพธ์ผิด

กรณีนี้สำคัญมากสำหรับ Agent ที่ใช้เซิร์ฟเวอร์ MCP (Model Context Protocol) เพราะปัญหามักเกิดจากการเชื่อมต่อเครื่องมือ, auth หรือ schema ของ tool input

2. เปรียบเทียบประสิทธิภาพของโมเดล

ไม่ใช่ทุกโมเดลเหมาะกับทุกงาน ให้ใช้ AI Agent Debugger เพื่อ:

รัน prompt เดียวกันกับหลายโมเดล
เปรียบเทียบ token usage และ cost
ตรวจคุณภาพ response
ดูว่าโมเดลใดเรียกเครื่องมือได้ถูกต้องกว่า

3. ปรับปรุงการใช้โทเค็น

เมื่อค่าใช้จ่ายขึ้นกับ token visibility จึงสำคัญมาก ให้ตรวจ:

system prompt ยาวเกินจำเป็นหรือไม่
context ที่ส่งเข้าโมเดลมีข้อมูลซ้ำหรือไม่
output ยาวเกินไปหรือไม่
cached tokens ช่วยลด cost ได้หรือไม่

ตัวอย่างการปรับ prompt ให้กระชับ:

ก่อน:
You are a helpful assistant. You should always think carefully, explain every step,
include all possible alternatives, and provide a long detailed answer...

หลัง:
You are an API debugging assistant. Return concise, actionable steps.
Use tools only when needed. Prefer bullet points.

4. ตรวจสอบการรวมเซิร์ฟเวอร์ MCP

MCP ช่วยให้ Agent เชื่อมต่อกับเครื่องมือภายนอกและ data sources ได้ ให้ตรวจ:

MCP server เชื่อมต่อสำเร็จหรือไม่
tools ถูก expose ถูกต้องหรือไม่
auth ทำงานหรือไม่
tool response ถูก parse ถูกต้องหรือไม่

5. ปรับปรุง System Prompt อย่างต่อเนื่อง

การเปลี่ยน prompt เล็กน้อยอาจเปลี่ยนพฤติกรรมของ Agent ได้มาก ใช้ debugger เพื่อ:

ทดสอบ system prompt หลายเวอร์ชัน
ดูผลต่อ tool selection และ reasoning path
ลดคำสั่งที่ทำให้ Agent เรียก tool มากเกินจำเป็น
บันทึก config ที่ทำงานได้ดีที่สุด

คู่มือทีละขั้นตอน: การใช้ AI Agent Debugger ของ Apidog

Apidog มี AI Agent Debugger ในตัวสำหรับตรวจสอบ session, trace, tool calls, token usage และ model performance

ขั้นตอนที่ 1: สร้างเซสชันดีบัก Agent ใหม่

เปิด Apidog desktop client
ไปที่ AI Agent Debugger จากแถบแท็บด้านบน
กำหนดค่าโมเดลในส่วนบนของหน้าจอ

ค่าที่ต้องตั้ง:

Provider: เลือกผู้ให้บริการโมเดล เช่น OpenAI หรือ Anthropic
Model: เลือกโมเดล เช่น gpt-4o หรือ claude-sonnet-4-6
Base URL: ระบบจะจับคู่ตาม provider ที่เลือก

ขั้นตอนที่ 2: กำหนดค่าพรอมต์

คลิกแท็บ Prompts แล้วตั้งค่า input ของ Agent

Clear after Send: ล้างช่อง input อัตโนมัติหลังส่ง
User Prompt: ใส่คำสั่งทดสอบสำหรับ session นี้

ตัวอย่าง:

Why is my POST /users endpoint returning 500 when I send a valid JSON payload?

System Prompt: กำหนดบทบาท เป้าหมาย ข้อจำกัด และกฎการใช้เครื่องมือ

ตัวอย่าง:

You are a code assistant that helps developers debug API issues.
Use the available tools to fetch API responses, search documentation,
and provide actionable solutions.

ควรเขียน system prompt ให้ชัดเจนว่า Agent ควรใช้เครื่องมือเมื่อใด เช่น:

Use web_fetch only when documentation lookup is required.
Use bash only for local command execution.
Do not call tools if the answer can be derived from the provided context.

ขั้นตอนที่ 3: กำหนดค่าเครื่องมือที่มีอยู่

คลิกแท็บ Tools เพื่อเลือกเครื่องมือที่ Agent ใช้ได้

เครื่องมือในตัว

Apidog มีเครื่องมือพร้อมใช้งานดังนี้:

เครื่องมือ	หน้าที่
`bash`	เรียกใช้คำสั่งใน shell session แบบคงอยู่
`web_fetch`	ดึงเนื้อหาเว็บและแปลงเป็น Markdown, text หรือ HTML
`read`	อ่านไฟล์ข้อความ รูปภาพ หรือ PDF
`edit`	แทนที่ string ในไฟล์แบบแม่นยำ
`write`	สร้างหรือเขียนทับไฟล์
`grep`	ค้นหาเนื้อหาไฟล์ด้วย regular expressions
`glob`	ค้นหาไฟล์ด้วย glob patterns
`kill_shell`	รีเซ็ต shell session ปัจจุบัน

เปิดเฉพาะเครื่องมือที่จำเป็นเพื่อลดความเสี่ยงที่ Agent จะเลือก tool ผิด

เครื่องมือ MCP

หากต้องการเชื่อมต่อเครื่องมือภายนอกผ่าน MCP:

คลิก Add MCP Server ในแท็บ Tools
เลือกวิธีเชื่อมต่อ:
- STDIO: เปิด MCP server เป็น local process
- HTTP: เชื่อมต่อผ่าน Streamable HTTP
- SSE: เชื่อมต่อผ่าน Server-Sent Events
ตั้งค่า authentication หากจำเป็น:
- Request headers
- OAuth 2.0 authorization
หลังเชื่อมต่อสำเร็จ ให้เลือก tools ที่ต้องการ expose ให้ Agent

ขั้นตอนที่ 4: กำหนดค่าทักษะ (ทางเลือก)

คลิกแท็บ Skills เพื่อเพิ่มทักษะที่นำกลับมาใช้ซ้ำได้

Skills เหมาะกับ:

workflow ที่ใช้ซ้ำภายในโปรเจกต์
ขั้นตอนมาตรฐานสำหรับงานซ้ำๆ
ลดความยาวของ system prompt

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

ขั้นตอนที่ 5: กำหนดค่า Authentication และ Model Parameters

ในแท็บ Authentication ให้เพิ่ม credentials ที่บริการโมเดลหรือ MCP server ต้องการ

ในแท็บ Settings ให้กำหนด model runtime parameters เช่น:

Temperature: ควบคุมความสุ่ม (0 = deterministic มากขึ้น, 1 = สร้างสรรค์มากขึ้น)
Max Tokens: จำกัดความยาว response
Top P: ควบคุม nucleus sampling
พารามิเตอร์อื่นๆ ขึ้นกับ provider

สำหรับงานดีบัก ควรเริ่มด้วย temperature ต่ำเพื่อลดความแปรปรวน เช่น:

temperature = 0
max_tokens = 1000

ขั้นตอนที่ 6: รันและสังเกตผล

คลิก Run ที่มุมขวาบนเพื่อเริ่มดีบัก

หลังรันเสร็จ ให้ตรวจ 3 ส่วนหลัก:

รายการเซสชัน (แผงด้านซ้าย)

แต่ละ run จะสร้าง session เช่น:

Session 3
1 turn · 1 step · 10s · 3.1k tokens · $0.02
gpt-4o

ใช้ส่วนนี้เพื่อเปรียบเทียบหลาย runs หรือหลายโมเดล

แผงรอบการสนทนา (ตรงกลาง)

แสดง conversation turns ของ Agent หากมีการโต้ตอบหลายรอบ ให้คลิกแต่ละ turn เพื่อดู trace เฉพาะรอบนั้น

แผงการติดตาม (ด้านขวา)

แผง Traces คือจุดหลักสำหรับดีบัก โดยแสดง:

Prompts: user/system prompt ที่ส่งจริง
Model calls: request และ response จาก LLM
Thinking process: reasoning ของโมเดล หากรองรับ
Tool calls: เครื่องมือ MCP หรือ custom skills ที่ถูกเรียก
Tool details: input parameters, output, time, error
Final output: ผลลัพธ์สุดท้ายของ Agent

ขั้นตอนที่ 7: ดีบัก Tool Call ที่ล้มเหลว

เมื่อ Agent ทำงานผิด ให้เริ่มจาก trace:

หา step ที่ล้มเหลว
ตรวจ input parameters ว่า schema ถูกต้องหรือไม่
ตรวจ output/error จาก tool
ตรวจว่า Agent เลือก tool ถูกตัวหรือไม่
ตรวจว่า auth และ connection ยังใช้งานได้หรือไม่

สาเหตุที่พบบ่อย:

MCP server ไม่ได้เชื่อมต่อหรือหลุด
parameter format ไม่ตรงกับ tool schema
OAuth, API key หรือ headers ตั้งค่าผิด
คำสั่งเริ่ม STDIO server ไม่ถูกต้อง
system prompt ไม่ระบุเงื่อนไขการใช้ tool ชัดเจน

ขั้นตอนที่ 8: เปรียบเทียบประสิทธิภาพของโมเดล

เพื่อหาโมเดลที่เหมาะกับ use case:

ใช้ prompt และ tools ชุดเดียวกัน
รันด้วย Model A เช่น GPT-4o
รันงานเดียวกันด้วย Model B เช่น Claude Sonnet
เปรียบเทียบ session metrics:
- จำนวน steps
- tool selection accuracy
- latency
- token usage
- estimated cost
- final output quality

AI Agent Debugger vs การดีบักแบบดั้งเดิม

ด้าน	การดีบักแบบดั้งเดิม	AI Agent Debugger
จุดเน้น	logic โค้ด, variables, call stack	model calls, tool calls, prompts
การมองเห็น	ไล่โค้ดทีละบรรทัด	ดู execution trace ทั้งหมด
ความไม่แน่นอน	โค้ดทำซ้ำได้	เปรียบเทียบหลาย runs เพื่อหารูปแบบ
Black box	ตรวจตัวแปรภายในได้	ตรวจ input/output ของโมเดล ไม่ใช่ weights ภายใน
การรวมเครื่องมือ	ดีบักแต่ละ API แยกกัน	ดู tool calls ทั้งหมดใน trace เดียว
ค่าใช้จ่าย	โดยทั่วไปไม่มี token visibility	เห็น token usage และ cost โดยประมาณ

Checklist สำหรับดีบัก AI Agent

ใช้ checklist นี้เมื่อ Agent ทำงานผิด:

[ ] Prompt ชัดเจนหรือไม่
[ ] System prompt ระบุบทบาทและข้อจำกัดหรือไม่
[ ] Model รองรับ tool calling หรือไม่
[ ] Tool ที่ต้องใช้เปิดใช้งานอยู่หรือไม่
[ ] MCP server เชื่อมต่อสำเร็จหรือไม่
[ ] Auth/API key/headers ถูกต้องหรือไม่
[ ] Tool input ตรง schema หรือไม่
[ ] Tool output มี error หรือไม่
[ ] Token usage สูงผิดปกติหรือไม่
[ ] รันซ้ำแล้ว behavior เสถียรหรือไม่

คำถามที่พบบ่อย

ทำไม Agent ของฉันไม่เรียกใช้เครื่องมือที่คาดไว้?

ตรวจสิ่งเหล่านี้:

เครื่องมือเปิดใช้งานในแท็บ Tools หรือไม่
System prompt อธิบายชัดเจนหรือไม่ว่าเมื่อใดควรใช้เครื่องมือ
MCP server เชื่อมต่ออยู่หรือไม่
มี thinking log หรือ tool call log ใน trace หรือไม่
โมเดลที่ใช้รองรับ tool calling หรือไม่

Tool call ของ MCP ล้มเหลวตลอด ควรตรวจอะไร?

ในแผง Traces ให้ตรวจ:

Input parameters: format ตรงกับ schema หรือไม่
Output: tool ส่ง error อะไรกลับมา
Connection status: MCP server ยังเชื่อมต่ออยู่หรือไม่
Authentication: API keys, OAuth tokens หรือ headers ถูกต้องหรือไม่
STDIO command: คำสั่งเริ่ม local server ถูกต้องหรือไม่

ทำไมต้องรันงานเดียวกันหลายครั้ง?

เพราะ Agent มีพฤติกรรมไม่แน่นอน การรันหลายครั้งช่วยให้คุณ:

เห็น variation ของ reasoning path
เปรียบเทียบ tool calls และผลลัพธ์
ตรวจว่า config ไหนเสถียรกว่า
ปรับสมดุลระหว่าง temperature, prompt และ tools

เริ่มต้นใช้งาน

AI Agent Debugger มีอยู่ใน Apidog ซึ่งเป็นแพลตฟอร์มพัฒนา API แบบครบวงจร หากต้องการเริ่มดีบัก AI Agent:

ดาวน์โหลด Apidog desktop client เวอร์ชันล่าสุด
เปิดแท็บ AI Agent Debugger
กำหนดค่า model, prompt และ tools
รัน Agent
ตรวจ trace, token usage, tool calls และ final output

สรุป

AI Agent Debugger เปลี่ยนการดีบัก Agent จากการคาดเดาให้เป็น workflow เชิงวิศวกรรมที่ตรวจสอบได้ คุณสามารถเห็นทุก prompt, model call, tool call, error, token และ cost ของแต่ละ session

เมื่อ AI Agent มี workflow ซับซ้อนขึ้นและเชื่อมต่อเครื่องมือภายนอกมากขึ้น trace-level visibility จึงเป็นสิ่งจำเป็นสำหรับการสร้าง Agent ที่เชื่อถือได้ ดีบักได้ และควบคุมค่าใช้จ่ายได้จริง