Bài 8 — Vận hành production
Agent demo và agent production khác nhau ở chỗ: production phải quan sát được, kiểm soát chi phí, và chịu lỗi. Bài này gói mọi thứ đã học vào một agent chạy thật đáng tin.
1. Observability: nhìn thấy mọi lượt
Mỗi request agent nên sinh một trace gồm: input, từng tool call (name + input + output + thời gian), số vòng loop, token dùng, kết quả cuối, guardrail có tripwire không.
import time, logging
log = logging.getLogger("agent")
def chay_tool_co_log(name, args):
t0 = time.time()
try:
out = chay_tool(name, args)
log.info("tool=%s ok dt=%.2fs args=%s", name, time.time()-t0, args)
return out
except Exception as e:
log.error("tool=%s FAIL dt=%.2fs err=%s", name, time.time()-t0, e)
raise
OpenAI Agents SDK có tracing tích hợp; bạn có thể xem luồng run, tool, handoff trên dashboard. Dù dùng gì, nguyên tắc là: không có trace = không debug được production. Khi khách báo "agent trả lời sai đơn ORD-1234", bạn cần mở đúng trace đó để thấy: model đã gọi tool nào, truyền input gì, tool trả về gì, guardrail có chặn không. Không có dữ liệu này, bạn chỉ đoán mò. Gắn một request_id xuyên suốt mọi log của một request để truy vết dễ dàng.
2. Kiểm soát chi phí
- Đặt
max_vongcho loop — chặn agent kẹt đốt token (đã làm ở bài 4). - Chọn model theo việc: model nhỏ/rẻ cho phân loại và guardrail, model mạnh cho suy luận khó.
- Giới hạn
max_tokenshợp lý; câu trả lời không cần dài vô tận. - Theo dõi token mỗi run, đặt cảnh báo khi vượt ngưỡng bất thường (dấu hiệu loop lỗi).
- Cache kết quả tool tra cứu lặp lại trong cùng phiên nếu dữ liệu ít đổi.
3. Độ tin cậy: chịu lỗi
def goi_model_retry(**kwargs):
for lan in range(3):
try:
return client.messages.create(**kwargs)
except anthropic.RateLimitError:
time.sleep(2 ** lan) # backoff lũy thừa
except anthropic.APIStatusError as e:
if e.status_code >= 500 and lan < 2:
time.sleep(2 ** lan) # lỗi server -> thử lại
else:
raise
raise RuntimeError("Hết lượt thử lại")
Retry với backoff cho lỗi tạm thời (429, 5xx); không retry lỗi 4xx do sai request (sửa code, không lặp lại). Tool ghi dữ liệu phải idempotent hoặc có khóa chống trùng, vì retry có thể chạy lại.
Các bước đưa lên production
- Bọc mọi lệnh gọi model bằng retry + timeout.
- Log trace đầy đủ mỗi request, gắn
request_idxuyên suốt. - Đặt trần chi phí: max_vong, max_tokens, cảnh báo token.
- Bật guardrail input/output (bài 6) trước khi mở cho người dùng thật.
- Chuẩn bị đường lui về người thật khi agent bí hoặc gặp việc rủi ro cao.
- Chạy thử tải và ca lỗi (tool timeout, model 429) trước khi go-live.
- Theo dõi sau khi live: tỉ lệ thành công, độ trễ p95, token/run, tần suất tripwire.
Checklist go-live
- [ ] Retry + timeout quanh mọi call model và tool.
- [ ] Trace/log đầy đủ, truy được theo request_id.
- [ ] Trần vòng lặp, token, và cảnh báo chi phí đã bật.
- [ ] Guardrail input & output đã kiểm thử.
- [ ] Tool ghi dữ liệu idempotent / chống trùng.
- [ ] Có cơ chế fallback sang người thật.
- [ ] Đã diễn tập ca lỗi (429, 5xx, tool chết, timeout).
Sai lầm thường gặp
- Không trace → sự cố production thành hộp đen, không sửa được.
- Retry cả lỗi 4xx → lặp lại request sai vô ích, có khi nhân đôi tác dụng phụ.
- Tool ghi dữ liệu không idempotent + retry → tạo trùng (hoàn tiền hai lần!).
- Không giới hạn vòng/token → một bug loop đốt sạch ngân sách trong đêm.
- Bỏ guardrail vì "demo chạy tốt" → người dùng thật luôn tìm ra ca bạn chưa nghĩ tới.
- Không có đường lui về người thật → agent bí là khách hàng bị bỏ rơi.