12 agent chạy cùng lúc — ai canh?

Dựng agent AI thì ai cũng hào hứng. Nhưng khi cả tá agent chạy production mà không ai giám sát, bạn đang chơi roulette với tiền thật.

Một tuyên bố không ai muốn nghe

Giả sử team bạn vừa dựng xong 3 agent xử lý đơn hàng, trả lời khách, và đối soát thanh toán. Demo chạy mượt. Sếp vỗ tay. Lên production tuần đầu — mọi thứ vẫn ổn. Tuần thứ hai, agent đối soát âm thầm bỏ qua các giao dịch không khớp format mới, không ai biết cho đến khi kế toán phát hiện lệch số cuối tháng.

Đây không phải kịch bản giả tưởng. Rede Mater Dei de Saúde — một trong những mạng lưới bệnh viện lớn nhất Brazil, hơn 45 năm hoạt động — đã triển khai 12 agent AI xử lý toàn bộ revenue cycle, từ xác minh bảo hiểm đến xuất hóa đơn. Bài học lớn nhất họ rút ra không phải về model hay prompt, mà về một thứ ít sexy hơn nhiều: observability — khả năng theo dõi agent đang làm gì, đúng hay sai, và khi nào cần can thiệp.

Hiểu nôm na: bạn không sợ agent ngu, bạn sợ agent sai mà tự tin.

Sân bóng 12 người nhưng không có trọng tài

Hình dung thế này: multi-agent system giống một đội chạy tiếp sức — mỗi agent một chặng, tốc độ từng người có thể rất nhanh, nhưng nếu không ai theo dõi lúc chuyền gậy thì chỉ cần một pha hụt tay là cả đội về đích với thành tích bằng không.

Rede Mater Dei đối mặt đúng bài toán này. Trước khi có hệ thống monitoring, các agent chạy độc lập — mỗi con một logic, một nguồn dữ liệu, và khi output sai thì phải debug ngược cả chuỗi mới tìm ra lỗi ở đâu. Trong ngành y tế Brazil, tỷ lệ từ chối bồi thường bảo hiểm toàn ngành tăng từ khoảng 12% lên gần 16% năm 2024 theo Anahp (Hiệp hội Bệnh viện Tư nhân Quốc gia), nghĩa là mỗi sai sót của agent có thể quy ra tiền thật — hàng tỷ real.

Họ chọn Amazon Bedrock AgentCore để giải quyết, nhưng điều đáng bàn nằm ở kiến trúc giám sát chứ không phải tool cụ thể. Ba lớp bạn cần suy nghĩ:

• Trace: mỗi request đi qua agent nào, gọi tool gì, trả về gì
• Metrics: latency, error rate, token usage theo từng agent
• Governance: ai approve output cuối cùng, khi nào cần human-in-the-loop

Kịch bản team Việt Nam: 3 agent, 3 kiểu "im lặng mà sai"

Ví dụ cụ thể: giả sử bạn đang build cho một sàn thương mại điện tử Việt Nam, team 5 người. Bạn có:

• Agent A: trả lời chat khách hàng, dùng RAG trên knowledge base sản phẩm
• Agent B: tự động tạo ticket nội bộ khi phát hiện khiếu nại nghiêm trọng
• Agent C: đối soát đơn hoàn trả với hệ thống kho

Ba agent này nối với nhau qua message queue. Tuần đầu ngon lành. Tuần thứ hai, Agent A trả lời sai chính sách hoàn trả vì knowledge base chưa cập nhật đợt khuyến mãi mới. Agent B nhận khiếu nại nhưng gắn nhầm mức ưu tiên vì prompt thiếu context về loại sản phẩm. Agent C xử lý hoàn trả nhưng không ghi log chi tiết — đến khi cần audit thì trắng tay.

Không có tracing xuyên suốt, bạn chỉ biết "khách hàng phàn nàn nhiều hơn" mà không biết lỗi bắt nguồn từ agent nào. Như đội tiếp sức thua mà không có camera slow-motion để xem gậy rơi ở chặng nào.

Bẫy kinh điển: "Agent chạy được rồi, lo gì"

Mình từng thấy một team dựng xong hệ thống 4 agent, chạy staging mượt mà, push production, rồi... quên. Không dashboard, không alert, không log tập trung. Ba tháng sau, agent tóm tắt hợp đồng bắt đầu hallucinate tên đối tác — nhưng vì output vẫn "trông có vẻ đúng", người dùng cứ duyệt. Đến khi phát hiện thì đã gửi hơn 200 email sai tên công ty đối tác.

Bẫy ở đây là tâm lý "nó chạy được rồi thì chắc ổn" — giống y việc tuyển nhân viên mới rồi không bao giờ review performance. Agent không phàn nàn, không xin nghỉ phép, nên bạn quên mất nó cũng cần được đánh giá định kỳ.

Bẫy thứ hai: quá nhiều agent cho bài toán đơn giản. Không phải cứ 12 agent là hay hơn 3 agent. Mỗi agent thêm vào là thêm một điểm cần monitor, thêm một chỗ có thể silent fail. Nếu một agent đủ giải quyết, đừng tách ra ba con rồi ngồi khóc vì không debug nổi.

Thử ngay chiều nay: observability tối thiểu cho multi-agent

Bạn không cần Bedrock AgentCore hay hạ tầng phức tạp để bắt đầu. Đây là setup đủ dùng:

Bước 1 — Structured logging cho mỗi agent. Mỗi agent khi nhận request và trả response, log ra JSON gồm ít nhất: agent_id, request_id, timestamp, input_summary, output_summary, tools_called, latency_ms.

Bước 2 — Trace ID xuyên suốt. Gắn một trace_id duy nhất cho mỗi request từ user, truyền qua tất cả agent trong chuỗi. Khi cần debug, filter theo trace_id là thấy toàn bộ hành trình.

Bước 3 — Alert đơn giản. Dùng bất kỳ tool nào bạn đã có — Grafana, Datadog, thậm chí một script Python chạy cron — để cảnh báo khi: error rate vượt ngưỡng, latency tăng đột biến, hoặc output trống bất thường.

Bước 4 — Sample review hàng tuần. Random lấy 20–30 trace để human review. Không cần đọc hết, chỉ cần đủ phát hiện drift — dấu hiệu agent bắt đầu trả lời lệch so với kỳ vọng.

Về phía open-source: Weaviate đang phát triển mạnh concept "agent memory" — cho agent khả năng nhớ context qua các session, giúp giảm lỗi lặp lại. Qdrant vừa release tính năng "Skills" giúp agent hiểu sâu hơn cách query vector database thay vì gọi API một cách mù quáng. Còn nếu bạn đang dùng LangChain hoặc smolagents của Hugging Face — cả hai đều hỗ trợ callback hooks để gắn tracing. Việc của bạn là thật sự gắn vào, đừng chỉ biết có rồi bỏ qua.

Không phải build thêm agent — mà là canh agent đã có

Ngành đang chạy đua dựng agent mới, thêm tính năng, thêm tool. Nhưng bài học từ Rede Mater Dei — và từ bất kỳ team nào đã đưa agent lên production thật — là giá trị lớn nhất không nằm ở agent thứ 13, mà ở khả năng biết agent thứ 3 đang âm thầm sai.

Như mình đã chia sẻ trong bài về demo vs production — khoảng cách giữa "chạy được" và "chạy đúng" luôn xa hơn bạn nghĩ. Monitoring không glamorous, không có demo ấn tượng để show sếp, nhưng nó là thứ quyết định agent của bạn là tài sản hay là nợ.

Plot twist: agent giỏi nhất không phải agent thông minh nhất — mà là agent bạn biết nó đang sai lúc nào.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng