DEV Community

Cover image for Đại Lý Liên Tục Nói Dối Tôi. Cho Đến Khi Tôi Dùng Trình Gỡ Lỗi AI Agent Apidog.
Sebastian Petrus
Sebastian Petrus

Posted on • Originally published at apidog.com

Đại Lý Liên Tục Nói Dối Tôi. Cho Đến Khi Tôi Dùng Trình Gỡ Lỗi AI Agent Apidog.

Một buổi chiều thứ Ba, tác nhân AI của tôi khẳng định endpoint /users phản hồi trong 47 giây. Số đúng là 47 mili giây.

Thử Apidog ngay hôm nay

Tôi mất hai ngày để lần theo lỗi này. Tôi thêm log vào MCP server, chỉnh system prompt, đọc từng token phản hồi của mô hình. Mỗi thay đổi làm câu trả lời nghe hợp lý hơn, nhưng vẫn sai.

Thứ tôi chưa làm là mở trace thực thi thực tế để xem chính xác dữ liệu nào được truyền giữa mô hình và tool. Đó là lúc AI Agent Debugger của Apidog hữu ích. Tôi đã cài nó từ ba tuần trước nhưng chưa dùng. Mất khoảng mười hai phút để tìm ra lỗi.

Lỗi tôi đang tìm

Thiết lập ban đầu:

  • Một agent dùng GPT-5.5
  • Một MCP server tự viết
  • Tool: get_response_time(endpoint)
  • System prompt khoảng 40 từ
  • User prompt: “Điểm cuối /users nhanh đến mức nào?”

Agent trả lời nhanh, tự tin, nhưng không ổn định:

  • “Endpoint đang phản hồi trong 47 giây”
  • “Khoảng 0.05 giây”
  • “Hiệu suất chấp nhận được”

Tôi đã thử các cách debug quen thuộc:

  1. Thêm logging vào MCP server
  2. So sánh nhiều phiên bản system prompt
  3. Đọc phản hồi mô hình từng token
  4. Ghi lại giả thuyết lỗi trong Notion
  5. Mở nhiều terminal để kiểm tra dữ liệu

Vấn đề khi debug agent là lỗi có thể nằm ở nhiều lớp:

  • System prompt
  • Lựa chọn mô hình
  • Tool schema
  • Tham số mô hình truyền vào tool
  • Dữ liệu tool trả về
  • Cách mô hình diễn giải dữ liệu đó

console.log thường chỉ cho bạn thấy một phần.

Bảng Traces hiển thị những gì

AI Agent Debugger của Apidog chia giao diện thành ba phần:

  • Sessions ở bên trái
  • Turns ở giữa
  • Traces ở bên phải

Khi chọn một session, bạn thấy toàn bộ hội thoại: user message, model response, tool call, tool result và model response tiếp theo.

Khi chọn một turn, bảng Traces mở cây thực thi chi tiết theo thứ tự:

  • System prompt như mô hình nhận được
  • User prompt như mô hình nhận được
  • Tên tool và tham số gọi tool, dạng JSON
  • Dữ liệu tool trả về, dạng JSON
  • Phản hồi mô hình, kèm thời gian và token

Trong session lỗi, tool call trông đúng:

get_response_time(endpoint="/users")
Enter fullscreen mode Exit fullscreen mode

Mô hình đã chọn đúng tool và đúng đối số.

Nhưng tool result là:

{
  "value": 47,
  "p95": 89,
  "samples": 1240
}
Enter fullscreen mode Exit fullscreen mode

Đây là lỗi: hệ thống metrics trả về giá trị theo mili giây, nhưng response không ghi rõ đơn vị. Mô hình giả định 47 là giây và trả lời “47 giây”.

Tool đúng. Mô hình diễn giải sai. System prompt cũng không có hướng dẫn về đơn vị.

Sửa lỗi bằng cách làm rõ schema

Tôi sửa response của MCP server để đơn vị trở thành một phần của dữ liệu:

{
  "value": {
    "amount": 47,
    "unit": "ms"
  },
  "p95": {
    "amount": 89,
    "unit": "ms"
  },
  "samples": 1240
}
Enter fullscreen mode Exit fullscreen mode

Sau đó thêm một câu vào system prompt:

Kết quả tool trả về đơn vị một cách rõ ràng. Hãy đọc kỹ chúng.
Enter fullscreen mode Exit fullscreen mode

Tôi chạy lại cùng prompt /users ba lần. Cả ba session đều trả lời đúng:

Endpoint đang phản hồi khoảng 47 ms.
Enter fullscreen mode Exit fullscreen mode

Chi phí token thấp hơn khoảng 18% so với các lần chạy lỗi, có thể vì mô hình không còn tạo thêm văn bản để xử lý giả định sai của chính nó.

Tôi cũng chạy cùng prompt với Claude Opus 4.7 trong một session khác. Kết quả đúng, chi phí cao hơn và phản hồi dài hơn. Đây là lý do việc so sánh model trong cùng một cấu hình rất hữu ích.

Điều tôi đã làm sai

Sai lầm của tôi là coi AI Agent Debugger như một công cụ log.

Log cho bạn biết một phần của hệ thống đã làm gì. Debugger cho bạn thấy mô hình và tool thật sự đã trao đổi gì.

Nếu bạn chỉ đọc output cuối cùng của mô hình rồi đoán nguyên nhân, bạn không debug agent. Bạn đang debug giả thuyết của mình về agent.

Một agent thường là hệ thống gồm bốn phần:

  1. Mô hình
  2. Prompt
  3. Tool
  4. Tool response

Lỗi thường nằm ở ranh giới giữa các phần này. Nếu nhìn được cả bốn cùng lúc, bạn tìm lỗi nhanh hơn nhiều.

Một lỗi khác cũng lộ ra khi tôi chạy lại cùng prompt nhiều lần: tính không xác định.

Sau khi sửa lỗi đơn vị, tôi chạy cùng prompt năm lần:

  • Ba lần agent gọi get_response_time một lần
  • Hai lần agent gọi tool hai lần
  • Một lần gọi với endpoint có khác biệt chữ hoa/chữ thường

Tool schema của tôi phân biệt chữ hoa chữ thường. Trước đó tôi không phát hiện vì test case đều dùng chữ thường.

Bài học: chạy cùng một prompt nhiều lần. Nếu hành vi thay đổi giữa các lần chạy, đó là điểm yếu cần kiểm tra.

Tự thiết lập một phiên debug agent

Dưới đây là quy trình từ cài đặt mới đến một phiên debug đang chạy.

Bước 1: Tạo phiên AI Agent Debugger mới

Mở Apidog và chọn AI Agent Debugger trên thanh tab trên cùng.

Thiết lập model:

  • Chọn provider, ví dụ OpenAI hoặc Anthropic
  • Chọn model cụ thể, ví dụ gpt-5.5
  • Base URL sẽ tự điền theo provider
  • Nhấn Run để bắt đầu session

Tab AI Agent Debugger với bộ chọn nhà cung cấp mô hình và mô hình ở trên cùng, URL cơ sở tự động điền, và nút Run ở phía trên bên phải.

Bước 2: Cấu hình prompt

Trong tab Prompts, nhập hai phần:

  • System Prompt: vai trò, mục tiêu, ràng buộc và quy tắc dùng tool
  • User Prompt: input test cho session này

Ví dụ:

System Prompt:
Bạn là trợ lý kỹ thuật. Khi đọc kết quả tool, luôn kiểm tra đơn vị đo trước khi trả lời.

User Prompt:
Điểm cuối /users nhanh đến mức nào?
Enter fullscreen mode Exit fullscreen mode

Sau khi cấu hình xong, nhấn Run.

Nếu muốn xóa input sau mỗi lần gửi, bật Clear after Send.

Bước 3: Cấu hình tools

Tab Tools liệt kê các tool agent có thể gọi trong runtime.

Các tool tích hợp sẵn gồm:

Tool Chức năng
bash Thực thi lệnh trong một shell session liên tục
web_fetch Lấy nội dung web và chuyển thành Markdown, text hoặc HTML
read Đọc file text, hình ảnh hoặc PDF
edit Thay thế chuỗi chính xác trong file
write Tạo hoặc ghi đè file
grep Tìm kiếm nội dung file bằng regex
glob Tìm file bằng glob pattern
kill_shell Reset shell session hiện tại

Với MCP tools, bạn có thể kết nối hệ thống bên ngoài qua MCP server bằng một trong ba cách:

  • STDIO: chạy một MCP server cục bộ
  • HTTP: kết nối tới MCP server hỗ trợ Streamable HTTP
  • SSE: kết nối tới MCP server dùng Server-Sent Events

Nếu MCP server cần xác thực, cấu hình request headers hoặc OAuth 2.0. Sau khi kết nối thành công, chọn các tool mà server expose cho agent.

Bước 4: Cấu hình Skills, Authentication và Settings

Ba tab này hoàn thiện runtime.

Skills

Skills là các workflow tái sử dụng cho agent. Chúng phù hợp với:

  • Quy trình dự án cố định
  • Quy tắc thao tác lặp lại
  • Việc giảm prompt dài trong system prompt

Skills được tải khi cần trong runtime.

Authentication

Authentication lưu thông tin xác thực cho model provider hoặc MCP service.

Settings

Settings cấu hình tham số runtime của model, ví dụ:

  • Temperature
  • Max Tokens
  • Top P

Mỗi provider hỗ trợ tham số khác nhau, vì vậy hãy kiểm tra model của bạn thật sự nhận những tham số nào.

Bước 5: Đọc Sessions, Turns và Traces

Sau khi nhấn Run, session mới sẽ xuất hiện ở panel bên trái.

Ví dụ summary:

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

Cách đọc ba panel:

  • Sessions panel: lịch sử các lần chạy, kèm số turn, số step, thời gian, token và chi phí
  • Turns panel: từng vòng hội thoại giữa user và model
  • Traces panel: chuỗi thực thi đầy đủ của agent

Trong Traces, bạn có thể kiểm tra:

  • System prompt
  • User prompt
  • Model call
  • Tool call
  • MCP tool input
  • MCP tool output
  • Skill execution
  • Thời gian thực thi
  • Error message
  • Output cuối cùng

Nếu tool call thất bại hoặc model trả lỗi, bước lỗi sẽ hiện trực tiếp trong Traces cùng input và output tương ứng.

Bước 6: So sánh hiệu suất model

Để so sánh model, giữ nguyên:

  • Prompt
  • Tool configuration
  • MCP server
  • Settings quan trọng

Sau đó đổi model và chạy lại.

Các chỉ số nên theo dõi:

  • Số step để hoàn thành cùng một tác vụ
  • Model nào chọn đúng tool ổn định hơn
  • Model nào phản hồi nhanh hơn
  • Token và chi phí có dễ dự đoán không
  • Output có nhất quán qua nhiều lần chạy không

Đây là cách tôi phát hiện model nào phù hợp hơn để đưa vào production.

Bài học rút ra

Lỗi không nằm ở endpoint /users. Lỗi cũng không nằm trong MCP tool. Lỗi nằm ở format dữ liệu giữa tool và mô hình: thiếu đơn vị.

Nếu chỉ nhìn output cuối cùng, tôi có thể tiếp tục sửa prompt trong nhiều ngày. Khi mở trace, lỗi xuất hiện ngay trong tool result.

Khi debug agent, hãy kiểm tra theo thứ tự:

  1. Mô hình nhận system prompt nào?
  2. Mô hình nhận user prompt nào?
  3. Mô hình gọi tool nào?
  4. Tham số tool call có đúng không?
  5. Tool trả về JSON gì?
  6. Mô hình diễn giải JSON đó như thế nào?
  7. Kết quả có ổn định qua nhiều lần chạy không?

Nếu bạn đang xây agent dùng MCP tools, hãy dùng debugger sớm, trước khi lỗi xuất hiện trong production.

Tải Apidog và mở nó trong lần tiếp theo agent của bạn trả lời sai với giọng điệu rất tự tin.

Tài liệu đầy đủ về tính năng, bao gồm thiết lập MCP transport và phạm vi khả dụng, có tại Apidog AI Agent Debugger: khả năng khả dụng, phạm vi bao phủ và thiết lập.

Top comments (0)