ตัวแทนโกหกผม จนกระทั่งผมเปิด Apidog AI Agent Debugger

บ่ายวันอังคาร ฉันวนดีบักไปแล้ว 12 รอบ และเอเจนต์ยังตอบอย่างมั่นใจว่า endpoint /users ตอบสนองใน 47 วินาที ทั้งที่ค่าจริงคือ 47 มิลลิวินาที

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

ฉันเสียเวลาไล่บั๊กนี้อยู่สองวัน เพิ่ม logging ใน MCP server ก็แล้ว แก้ system prompt ก็แล้ว อ่าน output ของโมเดลทีละรอบก็แล้ว แต่คำตอบยังดู “สมเหตุสมผล” มากขึ้นโดยที่ยังผิดเหมือนเดิม

สิ่งที่ทำให้เจอสาเหตุจริงคือการเปิดดู trace ว่าโมเดลส่งอะไรไปให้ tool และ tool ส่งอะไรกลับมา นั่นคือจุดที่ AI Agent Debugger ของ Apidog ช่วยได้: มันทำให้เห็นทั้ง prompt, tool call, tool result, token, latency และ output ของโมเดลในมุมมองเดียว

ข้อผิดพลาดที่ฉันตามหา

เซ็ตอัปของฉันมีส่วนประกอบไม่มาก:

• เอเจนต์ที่ใช้ GPT-5.5
• MCP server ที่เขียนเอง
• tool ชื่อ get_response_time(endpoint)
• system prompt สั้น ๆ
• user prompt: ปลายทาง /users ทำงานเร็วแค่ไหน?

tool ทำหน้าที่ query metrics pipeline แล้วส่งค่ากลับมาให้โมเดล

ผลลัพธ์ที่ได้กลับไม่เสถียร:

• “ปลายทางตอบสนองภายใน 47 วินาที”
• “ประมาณ 0.05 วินาที”
• “ประสิทธิภาพเป็นที่ยอมรับได้”

ปัญหาของการดีบักเอเจนต์คือ error อาจอยู่ได้หลายจุด:

1. system prompt
2. user prompt
3. การเลือกโมเดล
4. schema หรือ description ของ tool
5. argument ที่โมเดลส่งเข้า tool
6. payload ที่ tool ส่งกลับ
7. การตีความผลลัพธ์ของโมเดล

ถ้าดูแค่ console log คุณมักเห็นแค่บางส่วนของ flow เท่านั้น

แผง Traces แสดงอะไรบ้าง

AI Agent Debugger ของ Apidog แบ่งหน้าจอเป็นสามส่วน:

• Sessions: รายการการรันแต่ละครั้ง
• Turns: ลำดับบทสนทนาและการเรียก tool ใน session นั้น
• Traces: รายละเอียด execution ทั้งหมดในแต่ละ turn

ในแผง Traces คุณจะเห็นข้อมูลตามลำดับจริง เช่น:

• system prompt ที่โมเดลได้รับ
• user prompt ที่โมเดลได้รับ
• tool name และ parameters ที่โมเดลส่งออกมา
• payload ที่ tool ส่งกลับมา
• response ของโมเดล
• latency, token และ cost ของ turn นั้น

ฉันเปิด session ที่ตอบผิด แล้วเห็นว่า tool call ถูกต้อง:

get_response_time(endpoint="/users")

โมเดลเลือก tool ถูก และส่ง argument ถูก

จากนั้นฉันขยาย tool result:

{
  "value": 47,
  "p95": 89,
  "samples": 1240
}

นี่คือบั๊กจริง

metrics pipeline ส่งค่ากลับมาเป็น มิลลิวินาที แต่ payload ไม่ระบุหน่วย โมเดลจึงตีความ 47 เป็นวินาที แล้วตอบอย่างมั่นใจว่า “47 วินาที”

สรุปคือ:

• tool ทำงานถูก
• argument ถูก
• data ถูก
• แต่ payload ไม่ self-descriptive
• system prompt ไม่บอกให้ระวังเรื่อง unit

การแก้ไขใช้เวลาหกบรรทัด

ฉันแก้ schema ของ response ให้มีหน่วยชัดเจน:

{
  "value": { "amount": 47, "unit": "ms" },
  "p95": { "amount": 89, "unit": "ms" },
  "samples": 1240
}

แล้วเพิ่มกฎใน system prompt:

ผลลัพธ์ของเครื่องมือจะส่งคืนหน่วยอย่างชัดเจน โปรดอ่านอย่างระมัดระวัง

จากนั้นรัน prompt เดิมอีกสามครั้ง:

ปลายทาง /users ทำงานเร็วแค่ไหน?

ทั้งสาม session ตอบถูกว่า endpoint ตอบสนองประมาณ 47 มิลลิวินาที และอธิบาย p95 เป็นมิลลิวินาทีเช่นกัน

ฉันยังลองรัน prompt เดียวกันกับ Claude Opus 4.7 เพื่อเปรียบเทียบ session แบบเคียงข้างกัน ผลลัพธ์ถูกเหมือนกัน แต่มี cost สูงกว่าและตอบยาวกว่าเล็กน้อย จุดนี้ทำให้ตัดสินใจเลือกโมเดลสำหรับ production ได้ง่ายขึ้น

สิ่งที่มีประโยชน์ไม่ใช่แค่การหา root cause แต่คือการเปรียบเทียบโมเดลบน config เดียวกัน โดยดู metrics จากแผง session:

• จำนวน turn
• จำนวน step
• latency
• token usage
• cost

สิ่งที่ฉันเข้าใจผิด

ตอนแรกฉันคิดว่า AI Agent Debugger เป็น logging tool แต่จริง ๆ แล้วมันต่างกัน

logging บอกว่า “เกิดอะไรขึ้น” ในบางจุดของระบบ

debugger แสดงว่า “โมเดลกับ tool แลกเปลี่ยนอะไรกันจริง ๆ”

สำหรับเอเจนต์ สิ่งนี้สำคัญมาก เพราะ error มักเกิดระหว่าง:

• prompt
• model reasoning
• tool selection
• tool input
• tool output
• final answer

ถ้าคุณอ่านแค่คำตอบสุดท้ายของโมเดลแล้วเดาสาเหตุ คุณไม่ได้ดีบักเอเจนต์โดยตรง แต่กำลังดีบักสมมติฐานของตัวเองเกี่ยวกับเอเจนต์

อีกสิ่งที่ debugger ช่วยเผยให้เห็นคือความไม่เสถียรของพฤติกรรมเอเจนต์ ฉันรัน prompt เดียวกันห้าครั้งหลังแก้ unit แล้วพบว่า:

• สามครั้งเรียก get_response_time ครั้งเดียว
• สองครั้งเรียก tool สองครั้ง
• ครั้งหนึ่งส่ง endpoint path ที่ case ต่างกัน

tool ของฉัน case-sensitive และฉันไม่เคยเห็นบั๊กนี้มาก่อน เพราะ test case เดิมใช้ lowercase ทั้งหมด

วิธีตรวจแบบง่ายคือ:

1. รัน prompt เดิม 5 ครั้ง
2. เปิดดู session ทั้งหมด
3. เทียบ tool call, argument, output และ final answer
4. จุดที่แตกต่างกันระหว่าง run คือจุดที่เอเจนต์เปราะบาง

ลองด้วยตัวเอง: ตั้งค่า AI Agent Debugger

ด้านล่างคือ flow การตั้งค่าจากโปรเจกต์ใหม่ไปจนถึง session ดีบักที่รันได้

ขั้นตอนที่ 1: สร้าง debug session ใหม่

เปิด Apidog แล้วคลิก AI Agent Debugger ที่แถบด้านบน จากนั้นตั้งค่าโมเดล:

• เลือก model provider เช่น OpenAI หรือ Anthropic
• เลือก model เช่น gpt-5.5
• Base URL จะถูกเติมให้อัตโนมัติหลังเลือก provider
• คลิก Run เพื่อเริ่ม session

ขั้นตอนที่ 2: กำหนดค่า prompt

ไปที่แท็บ Prompts แล้วกรอกสองส่วนหลัก:

• System Prompt: ระบุ role, goal, constraint และกฎการใช้ tool
• User Prompt: prompt ที่ต้องการทดสอบ เช่น Apidog คืออะไร?

ตัวอย่าง system prompt สำหรับกรณี tool ที่มีหน่วย:

คุณเป็นเอเจนต์สำหรับวิเคราะห์ metric ของ API
เมื่อเรียก tool แล้ว ให้ตรวจสอบ unit ในผลลัพธ์เสมอ
ห้ามเดาหน่วยเองหาก tool ไม่ได้ส่งมา

ตัวอย่าง user prompt:

ปลายทาง /users ทำงานเร็วแค่ไหน?

เมื่อตั้งค่าเสร็จ คลิก Run

ถ้าต้องการล้าง input หลังรันแต่ละครั้ง ให้เปิด Clear after Send

ขั้นตอนที่ 3: กำหนดค่า tools

แท็บ Tools แสดงรายการความสามารถที่เอเจนต์เรียกใช้ได้ระหว่าง runtime

Built-in tools

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

MCP tools

สำหรับ tool ที่มาจาก MCP server สามารถเชื่อมต่อได้สามแบบ:

• STDIO: เปิด MCP server เป็น local process
• HTTP: เชื่อมต่อ MCP server ที่รองรับ Streamable HTTP
• SSE: เชื่อมต่อ MCP server ผ่าน Server-Sent Events

ถ้า MCP server ต้อง authentication ให้ตั้ง request headers หรือ OAuth 2.0 ตามที่ระบบรองรับ เมื่อเชื่อมต่อสำเร็จ ให้เลือก tools ที่ต้องการ expose ให้เอเจนต์ใช้งาน

ขั้นตอนที่ 4: กำหนดค่า Skills, Authentication และ Settings

มีแท็บย่อยที่ควรตรวจสอบก่อนรันจริง:

• Skills: workflow ที่นำกลับมาใช้ซ้ำได้ เหมาะกับขั้นตอนประจำของโปรเจกต์ หรือกฎที่ไม่อยากใส่ซ้ำใน system prompt
• Authentication: credentials สำหรับ model provider หรือ MCP service
• Settings: runtime parameters เช่น Temperature, Max Tokens และ Top P

พารามิเตอร์ที่รองรับขึ้นอยู่กับ provider และ model ที่เลือก ควรตรวจสอบก่อนรัน benchmark หรือเปรียบเทียบโมเดล

ขั้นตอนที่ 5: อ่านข้อมูลจากสามแผงหลัก

หลังคลิก Run session ใหม่จะปรากฏในแผงซ้าย พร้อม summary เช่น:

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

วิธีอ่านแต่ละแผง:

• Sessions ซ้าย: ประวัติการรันทั้งหมด พร้อม metrics สรุป
• Turns กลาง: ลำดับ user/model/tool ใน session นั้น
• Traces ขวา: execution chain แบบละเอียด รวมถึง prompt, model call, tool call, tool input, tool output, latency, error และ final answer

เมื่อ tool call ล้มเหลว หรือโมเดลตอบผิด ให้เริ่มจาก Traces:

1. ตรวจว่าโมเดลเลือก tool ถูกหรือไม่
2. ตรวจ argument ที่ส่งเข้า tool
3. ตรวจ payload ที่ tool ส่งกลับ
4. ตรวจว่า payload มี field, type และ unit ชัดเจนหรือไม่
5. เทียบ final answer กับ tool result

ขั้นตอนที่ 6: เปรียบเทียบโมเดล

ใช้ prompt และ tool config เดิม แล้วเปลี่ยนเฉพาะ model

แต่ละ run จะกลายเป็น session ใหม่ในแผงซ้าย ทำให้เทียบได้โดยตรงว่าโมเดลไหนเหมาะกับงานมากกว่า

metrics ที่ควรดู:

• จำนวน step ที่ใช้เพื่อทำงานเดียวกัน
• ความแม่นยำในการเลือก tool
• latency
• token usage
• cost
• ความสม่ำเสมอของ output เมื่อรัน prompt เดิมหลายครั้ง

แนวทางที่ฉันใช้:

รัน prompt เดิม 5 ครั้งต่อโมเดล
เทียบ tool call และ final answer
เลือกโมเดลที่ตอบถูก ใช้ step น้อย latency ต่ำ และ cost คาดเดาได้

Checklist สำหรับดีบักเอเจนต์ที่ตอบผิด

เมื่อเอเจนต์ให้คำตอบผิด แต่ดูเหมือนมั่นใจ ให้ไล่ตรวจตามนี้:

• [ ] system prompt มี constraint ที่จำเป็นครบหรือไม่
• [ ] tool description ชัดเจนพอให้โมเดลเลือกถูกหรือไม่
• [ ] tool input schema บังคับ field สำคัญหรือไม่
• [ ] โมเดลส่ง argument ถูกต้องหรือไม่
• [ ] tool output มีหน่วยและ type ชัดเจนหรือไม่
• [ ] payload มี field ที่คลุมเครือ เช่น value, data, result โดยไม่มี context หรือไม่
• [ ] final answer ตรงกับ tool result หรือโมเดลตีความผิด
• [ ] prompt เดิมรันหลายครั้งแล้วได้ tool call เหมือนกันหรือไม่
• [ ] cost และ token usage คงที่พอสำหรับ production หรือไม่

ประเด็นสำคัญ

บั๊กนี้ไม่ได้เกิดจากโมเดลไม่เก่ง หรือ tool คำนวณผิด แต่เกิดจาก contract ระหว่าง tool กับโมเดลไม่ชัดเจนพอ

สิ่งที่ควรทำเมื่อสร้าง tool ให้เอเจนต์:

• ส่ง output แบบ self-descriptive
• ใส่ unit ใน payload เสมอเมื่อเป็นตัวเลข
• หลีกเลี่ยง field name ที่กำกวม
• เขียน system prompt ให้บอกวิธีอ่าน tool result
• รัน prompt เดิมหลายครั้งเพื่อหา nondeterministic behavior
• เปรียบเทียบโมเดลด้วย config เดียวกันก่อนเลือกใช้จริง

ถ้าคุณกำลังสร้างเอเจนต์ที่เรียก tool หรือ MCP server การดูแค่ final answer ไม่พอ คุณต้องเห็น trace ระหว่างโมเดลกับ tool ด้วย

ดาวน์โหลด Apidog แล้วลองเปิด AI Agent Debugger กับเอเจนต์ตัวถัดไปที่ตอบผิดอย่างมั่นใจ อาจใช้เวลาไม่กี่นาทีในการเจอว่าปัญหาอยู่ตรงไหน: ใน prompt, tool call, payload หรือการตีความของโมเดล

อ่านรายละเอียดฟีเจอร์เพิ่มเติม รวมถึงการตั้งค่า MCP transport และ availability ของแผนบริการได้ที่ Apidog AI Agent Debugger: ความพร้อมใช้งาน, ขอบเขตครอบคลุม และการตั้งค่า