QuotaCheap Playbook

AI Agent Logging: Nên Theo Dõi Gì Trước Khi Người Dùng Phàn Nàn

Playbook tiếng Việt cho developer xây AI agent production: log request ID, prompt, model, token, latency, tool call, lỗi, quota, cost và feedback người dùn…

Một playbook thực tế cho developer đang đưa AI agent vào production: log đúng thứ, debug nhanh hơn, kiểm soát chi phí tốt hơn.

Bài viết hướng dẫn các nhóm phát triển AI agent xây dựng hệ thống logging trước khi có sự cố: theo dõi request ID, prompt, model, token, latency, lỗi, quota, cost, routing và phản hồi người dùng. Mục tiêu là giúp agent dễ debug, dễ vận hành và dễ kiểm soát khi chạy thật.

AI agent trong môi trường demo thường trông rất ổn: một prompt sạch, một vài tool call, một câu trả lời hợp lý.

Nhưng khi đưa vào production, vấn đề thường không xuất hiện ngay trong code.

Nó xuất hiện dưới dạng câu hỏi của người dùng: “Sao hôm nay agent trả lời chậm?”, “Vì sao câu trả lời này sai?”, “Tại sao bill tăng?”, “Request này có chạy tool không?”.

Nếu lúc đó bạn mới bắt đầu thêm log, thường đã muộn.

Logging cho AI agent nên được thiết kế trước khi người dùng phàn nàn, không phải sau khi sự cố xảy ra.

Mục tiêu không phải là ghi mọi thứ, mà là ghi đủ để tái hiện, giải thích và cải thiện hành vi của agent.

Luôn có request ID cho từng lượt chạy Mỗi lần người dùng gọi agent nên có một request id hoặc trace id duy nhất.

ID này cần đi xuyên suốt toàn bộ vòng đời: request từ frontend, backend, lần gọi model, tool call, retry, lỗi và response cuối cùng.

Khi người dùng báo “agent trả lời sai lúc 10:32”, bạn không muốn tìm trong hàng nghìn dòng log bằng email hoặc timestamp mơ hồ.

Bạn muốn mở đúng một trace và thấy toàn bộ câu chuyện.

Tối thiểu nên log: request id user id hoặc tenant/workspace ID nếu có thời điểm bắt đầu và kết thúc endpoint hoặc workflow được gọi trạng thái cuối cùng: success, failed, timeout, cancelled Không cần đưa mọi dữ liệu cá nhân vào log.

Với dữ liệu nhạy cảm, hãy dùng ID nội bộ, hash hoặc cơ chế redaction phù hợp.

Log input, nhưng phải có chiến lược bảo mật AI agent phụ thuộc rất nhiều vào ngữ cảnh đầu vào.

Nếu không biết người dùng đã hỏi gì, system prompt là gì, memory nào được chèn vào, tài liệu nào được retrieve, bạn rất khó giải thích vì sao model trả lời như vậy.

Tuy nhiên, log prompt thô có thể chứa dữ liệu cá nhân, token truy cập, nội dung khách hàng hoặc thông tin bí mật.

Vì vậy, thay vì “log tất cả”, hãy phân tầng: log metadata mặc định: độ dài prompt, loại workflow, số message, nguồn context log nội dung đã redacted cho môi trường production chỉ cho phép xem prompt đầy đủ trong môi trường có quyền kiểm soát nghiêm ngặt, nếu chính sách sản phẩm cho phép Một format hữu ích là tách rõ: Điểm quan trọng: khi debug, bạn cần biết agent đã nhìn thấy gì, nhưng không nên biến log thành nơi lưu trữ dữ liệu nhạy cảm không kiểm soát.

Theo dõi model, tham số và phiên bản prompt Nhiều lỗi AI agent không đến từ code, mà đến từ thay đổi model, prompt hoặc tham số chạy.

Nếu tuần trước agent ổn nhưng tuần này bắt đầu trả lời dài hơn, chậm hơn hoặc kém chính xác hơn, bạn cần biết có gì đã thay đổi.

Hãy log: model slug hoặc model name thực tế được gọi temperature, max output nếu ứng dụng có truyền prompt version agent version hoặc workflow version tool schema version Nếu dùng QuotaCheap làm lớp API OpenAI compatible, hãy dùng model slug đúng như trong Model catalog.

Các model public hiện được nêu trong support knowledge gồm gpt 5.5, gpt 5.4 mini, gpt 5.3 codex, gpt oss 120b và deepseek v4 flash.

Với giới hạn context window hoặc max output tokens, nên kiểm tra danh sách mới nhất trong dashboard thay vì hard code giả định.

Log token, latency và cost cho từng bước Production AI agent thường có nhiều bước: phân tích yêu cầu, gọi tool, đọc dữ liệu, tạo câu trả lời, đôi khi retry.

Nếu chỉ log tổng thời gian, bạn sẽ không biết chậm ở đâu.

Nên ghi theo từng span: thời gian gọi model thời gian gọi từng tool input tokens, output tokens, cache read tokens nếu có chi phí ước tính hoặc chi phí thực tế nếu hệ thống gateway cung cấp số lần retry Ví dụ, một request mất 12 giây có thể do model tạo output quá dài, tool database chậm, provider latency cao hoặc retry ngầm.