Agent không giống app truyền thống: đầu vào là ngôn ngữ tự do, đầu ra không xác định, chi phí thay đổi theo token. Vì vậy nền tảng phải trả lời được ba câu hỏi mọi lúc: Agent đang làm gì? (trace) — Tốn bao nhiêu? (cost) — Chất lượng ra sao? (eval).
1. Tracing: nhìn xuyên chuỗi hành động
Mỗi lần chạy agent tạo một trace gồm nhiều span: gọi LLM, gọi tool, quyết định của planner. Chuẩn hóa theo OpenTelemetry để dùng chung công cụ.
{
"trace_id": "a1b2", "agent": "support-summarizer", "team": "cskh",
"spans": [
{"type": "llm", "model": "claude-sonnet", "tokens_in": 1200, "tokens_out": 300, "ms": 900},
{"type": "tool", "name": "lookup_customer", "scopes": ["crm:read"], "ms": 40},
{"type": "guardrail", "name": "pii_output", "result": "redacted"}
],
"cost_usd": 0.011, "outcome": "success"
}
Khi agent trả lời sai trong production, trace cho bạn xem đúng chuỗi tool/prompt để tái hiện lỗi.
2. Chi phí: gắn token vào chủ sở hữu
Vì mọi request qua gateway có team_id và agent, bạn dựng được dashboard chi phí theo team/agent, đặt budget alert và hard cap.
if team.month_spend > team.budget * 0.8:
notify(team, "đã dùng 80% ngân sách AI tháng này")
if team.month_spend > team.budget:
gateway.throttle(team) # hạ về model rẻ hoặc chặn
Mẹo giảm chi phí: cache câu hỏi lặp, định tuyến tác vụ đơn giản sang model nhỏ, cắt context thừa.
3. Evals: đo chất lượng liên tục
Eval là bộ kiểm thử cho agent. Hai loại cần có:
- Offline eval (golden set): chạy trước khi deploy trên tập câu hỏi có đáp án chuẩn; điểm tụt thì chặn merge.
- Online eval: chấm mẫu output thật trong production bằng LLM-as-judge + phản hồi người dùng (thumbs up/down).
# eval trong CI: chặn nếu điểm tụt
score = run_evals(agent, golden_set) # 0..1
assert score >= 0.85, f"eval tụt còn {score}, chặn deploy"
Các bước dựng observability tối thiểu
- Ép mọi call qua gateway để thu token/latency tự động (đã làm ở Bài 2).
- Chuẩn trace_id xuyên suốt từ request tới mọi span tool/LLM.
- Dashboard 3 trục: cost theo team, latency/lỗi theo agent, eval score theo thời gian.
- Cảnh báo: chi phí vượt ngưỡng, tỉ lệ lỗi tăng, eval tụt, guardrail bị kích hoạt tăng đột biến.
- Vòng phản hồi: gom output bị người dùng chấm xấu vào golden set để lần eval sau bắt được.
Vì sao agent cần loại observability khác app thường
Với một API truyền thống, bạn giám sát ba thứ quen thuộc: có lỗi không, chậm không, tốn tài nguyên không. Agent thêm hai chiều mới mà công cụ APM cũ không nắm được. Thứ nhất là tính đúng đắn về ngữ nghĩa: một request có thể trả về HTTP 200, độ trễ tốt, chi phí thấp — nhưng câu trả lời hoàn toàn sai. Không có mã lỗi nào bắt được điều này; chỉ có eval và phản hồi người dùng mới phát hiện. Thứ hai là chi phí biến thiên: cùng một endpoint nhưng request này tốn 200 token, request kia tốn 8.000 token tùy độ dài context, khiến chi phí khó dự đoán và dễ bị một agent lỗi đốt sạch ngân sách.
Hệ quả thực tế: đừng bê nguyên dashboard giám sát app thường sang cho agent rồi tưởng là đủ. Một hệ thống "toàn màu xanh" theo tiêu chuẩn cũ vẫn có thể đang làm người dùng thất vọng mỗi ngày vì câu trả lời kém. Đó là lý do eval score được đặt ở đỉnh kim tự tháp bên dưới: nó là chỉ số khó đo nhất nhưng lại phản ánh trực tiếp giá trị mà agent mang lại.
Khung tư duy: kim tự tháp quan sát
[Eval score] ← chất lượng (khó nhất, quan trọng nhất)
[Cost & Token] ← tiền
[Latency & Error rate] ← vận hành
[Trace & Log] ← nền móng, phải có trước
Checklist
- [ ] Mọi run có trace_id, team_id, token, cost.
- [ ] Dashboard chi phí theo team + budget alert + hard cap.
- [ ] Golden set chặn deploy khi eval tụt.
- [ ] Online eval + kênh feedback người dùng.
- [ ] Output xấu chảy ngược về golden set.
Sai lầm thường gặp
- Chỉ log chi phí, không đo chất lượng: agent rẻ nhưng trả lời sai còn hại hơn.
- Eval một lần lúc ra mắt rồi thôi: model/prompt đổi, chất lượng trôi mà không ai biết (drift).
- Không gắn cost vào owner: không ai chịu trách nhiệm tối ưu.
- Log toàn bộ prompt chứa PII: vi phạm bảo mật; hãy sample và redact.
- Đo latency/lỗi nhưng bỏ eval: hệ thống "xanh" mà người dùng vẫn bỏ đi vì câu trả lời tệ.