Bài 8 — Vận hành production: quan sát, đánh giá, versioning

Agent chạy được trên máy bạn khác xa với agent chạy tin cậy cho hàng nghìn người dùng. Bài cuối gom các thực hành vận hành: quan sát (observability), đánh giá (eval), quản lý phiên bản, và kiểm soát chi phí.

Observability: nhìn thấy mọi tool call

Bạn không sửa được thứ không đo được. Với mỗi tool call, ghi log có cấu trúc:

{
  "trace_id": "abc123",
  "user_id": "u_42",
  "tool": "refund_order",
  "args": { "order_id": "ORD-000123", "amount": 500000 },
  "result": "ok",
  "latency_ms": 340,
  "retries": 0,
  "tokens": 1200
}

Trace_id nối tất cả tool call trong một phiên, cho bạn tái dựng đúng những gì agent đã làm khi có sự cố. Che dữ liệu nhạy cảm trong log (Bài 6).

Các số liệu cần theo dõi

• Tỷ lệ chọn đúng tool (so với nhãn kỳ vọng trên tập test).
• Tỷ lệ lỗi tool theo từng tool — tool nào hay hỏng?
• Độ trễ p95 mỗi tool và toàn phiên.
• Số bước trung bình mỗi tác vụ (tăng đột biến = model đang loanh quanh).
• Chi phí token mỗi phiên và mỗi người dùng.

Eval: bộ kiểm thử cho agent

Agent thay đổi hành vi khi bạn đổi model, prompt, hay schema. Không có eval, bạn ship mù. Xây tập eval:

• Thu thập ~30–100 tình huống thật (kèm tool kỳ vọng và kết quả đúng).
• Chạy agent trên tập này sau mỗi thay đổi.
• Đo: đúng tool? đúng tham số? hoàn thành tác vụ? chi phí?

cases = load_eval_cases()
for c in cases:
    trace = run_agent(c.input)
    assert c.expected_tool in trace.tools_called, c.id
    check_task_success(trace, c.expected_result)

Chạy eval này trong CI, không cho merge nếu tụt điểm.

Versioning tool và schema

Schema là hợp đồng (Bài 2); đổi nó có thể phá agent đang chạy:

• Thêm field tùy chọn: an toàn (backward compatible).
• Đổi/xóa field, đổi enum, đổi required: breaking. Ra tool version mới (create_order_v2) hoặc migrate có kiểm soát.
• Ghi changelog schema: mỗi thay đổi có lý do và ngày, để lần ngược khi eval tụt điểm.
• Ghim phiên bản model: nâng cấp model có thể đổi hành vi chọn tool; nâng cấp có chủ đích và chạy eval trước.

Kiểm soát chi phí và giới hạn tốc độ

• Ngân sách mỗi người dùng: chặn user gọi quá N tác vụ/giờ.
• Cache read tool: kết quả get_weather trong 10 phút có thể cache, khỏi gọi API và tốn token lại.
• Cắt gọn context: định kỳ tóm tắt lịch sử dài để giữ token thấp.
• Cảnh báo: đặt alert khi chi phí/lỗi vượt ngưỡng.

Khung tư duy: vòng đời cải tiến liên tục

Đo (log + số liệu) → Phát hiện (tool nào sai/chậm/đắt)
   → Sửa (schema/prompt/retry) → Eval (CI chặn hồi quy)
   → Ship có version → Đo lại...

Agent tốt không phải sản phẩm một lần; nó là vòng lặp cải tiến dựa trên dữ liệu vận hành thật.

Checklist go-live

• [ ] Mọi tool call có structured log + trace_id, đã che PII.
• [ ] Dashboard theo dõi tỷ lệ lỗi, độ trễ p95, chi phí, số bước.
• [ ] Tập eval ≥30 case chạy trong CI, chặn merge khi tụt điểm.
• [ ] Schema có versioning + changelog; model được ghim phiên bản.
• [ ] Read tool được cache; có ngân sách/rate limit mỗi user.
• [ ] Alert chi phí và tỷ lệ lỗi đã bật.
• [ ] Có runbook xử lý sự cố (agent lặp, tool sập, chi phí tăng vọt).

Sai lầm thường gặp

• Ship không có eval. Đổi prompt/model rồi phát hiện agent hỏng qua khiếu nại người dùng, không phải qua test.
• Log thiếu trace_id. Có sự cố nhưng không tái dựng được chuỗi tool call thì không debug nổi.
• Đổi schema breaking mà không version, phá các phiên đang chạy và agent phụ thuộc.
• Nâng model "tự động" lên bản mới rồi ngạc nhiên vì hành vi chọn tool đổi — luôn ghim và eval trước.
• Không cache read tool, trả tiền lặp lại cho cùng một truy vấn.
• Không giới hạn chi phí mỗi user, để một vòng lặp lỗi hoặc lạm dụng đốt sạch ngân sách.
• Coi launch là đích đến thay vì điểm bắt đầu của vòng lặp đo–sửa–eval.