Từ pilot đến vận hành phòng ban ổn định
Đội agent đã chạy, đã đo được (Bài 7). Giờ là bài toán vận hành dài hạn: mở rộng sang phòng khác, kiểm soát chi phí khi tải tăng, và thiết lập vòng cải tiến liên tục để đội ngày càng tốt hơn thay vì thoái hóa.
Chiến lược mở rộng: nhân bản có kỷ luật
Đừng viết lại từ đầu cho mỗi phòng. Tách phần dùng chung và phần đặc thù:
- Dùng chung (khung): router, cơ chế escalation, logging/trace, guardrail engine.
- Đặc thù phòng ban: role prompt, danh sách tool, chính sách, guardrail cụ thể.
# Cùng một khung, cấu hình khác nhau theo phòng
team_framework: shared_v2
departments:
cskh: { agents: [order, refund, escalation], policy: cskh_policy }
hr: { agents: [screening, scheduler, faq], policy: hr_policy }
finance: { agents: [invoice, approval, report], policy: fin_policy }
Kiểm soát chi phí khi tải tăng
- Định tuyến model theo độ khó: việc dễ (router, phân loại) dùng model nhỏ/rẻ; việc khó (phân tích, viết) dùng model lớn.
- Cache câu trả lời lặp lại: FAQ giống nhau → cache, không gọi model mỗi lần.
- Giới hạn số bước (từ Bài 4) để chặn task ngốn token bất thường.
- Batch việc không gấp: gộp báo cáo cuối ngày thay vì chạy real-time.
Vòng cải tiến liên tục (khung PDCA cho agent)
- Plan: chọn 1 metric yếu nhất từ dashboard (ví dụ auto_resolution thấp).
- Do: thử một thay đổi (thêm tool, chỉnh role prompt, thêm nhánh router).
- Check: so metric trước/sau trên tập test cố định + traffic thật.
- Act: giữ nếu tốt hơn, revert nếu tệ hơn; ghi lại bài học.
Ví dụ: một chu kỳ cải tiến thật
Plan : auto_resolution = 61%, muốn 70%. Trace cho thấy 15% ca hỏi "đổi size".
Do : thêm exchange_agent xử lý đổi size.
Check: sau 2 tuần, auto_resolution = 69%, cost_per_task +80đ (chấp nhận được).
Act : giữ lại, thêm vào khung dùng chung cho các phòng bán lẻ khác.
Chống thoái hóa: vì sao đội tốt vẫn tệ dần theo thời gian
Một đội agent không được chăm sóc sẽ tệ dần vì ba nguyên nhân: dữ liệu thay đổi (sản phẩm mới, chính sách mới mà kiến thức chưa cập nhật), phân bố yêu cầu dịch chuyển (khách bắt đầu hỏi loại việc đội chưa xử lý được), và guardrail lỗi thời (hạn mức đặt từ năm ngoái không còn hợp lý). Vòng PDCA đều đặn chính là liều thuốc chống thoái hóa. Đặt lịch review cố định — ví dụ mỗi thứ Sáu xem dashboard 30 phút — để phát hiện xu hướng xấu sớm.
Runbook: tài liệu cứu bạn lúc nửa đêm
Khi đội gặp sự cố ngoài giờ, người trực cần một runbook trả lời nhanh: đội gồm agent nào, tool nào chạm tiền, cách tắt khẩn cấp (kill switch) một agent, cách chuyển toàn bộ về người thật, và ai là người leo thang. Một runbook tốt biến sự cố hoảng loạn thành quy trình vài phút. Đây là khác biệt giữa hệ thống agent "đồ chơi" và hệ thống vận hành nghiêm túc mà nội bộ tin tưởng.
Các bước thiết lập vận hành bền vững
- Tách khung dùng chung khỏi cấu hình đặc thù phòng ban.
- Thiết lập model-routing theo độ khó để tối ưu chi phí.
- Bật cache cho truy vấn lặp và batch cho việc không gấp.
- Lập lịch review metric định kỳ (tuần/tháng).
- Chạy vòng PDCA trên metric yếu nhất mỗi chu kỳ.
- Ghi lại quyết định và bài học thành tài liệu vận hành (runbook).
- Chuẩn hóa quy trình on-call khi đội gặp sự cố ngoài giờ.
Checklist vận hành
- [ ] Khung dùng chung tách khỏi cấu hình phòng ban
- [ ] Có model-routing theo độ khó
- [ ] Có cache + batch cho việc phù hợp
- [ ] Lịch review metric định kỳ
- [ ] Vòng PDCA đang chạy đều
- [ ] Có runbook và quy trình on-call
Sai lầm thường gặp
- Viết lại từ đầu cho mỗi phòng: tốn công gấp bội và mỗi bản lệch nhau, khó bảo trì. Tách khung dùng chung.
- Dùng model lớn cho mọi việc: router chỉ phân loại 3 nhãn mà chạy model đắt → chi phí gấp nhiều lần vô ích.
- Triển khai xong rồi "để đó": không có PDCA → đội thoái hóa khi dữ liệu và nhu cầu thay đổi.
- Thay đổi không đo: chỉnh prompt theo cảm tính, không so metric → không biết tốt hơn hay tệ đi.
- Không có runbook/on-call: sự cố ngoài giờ không ai biết xử lý → mất niềm tin nội bộ vào hệ thống agent.