Kiến Trúc AI Agent Sống Sót Ở Production: 6 Pattern Cốt Lõi

Agent bạn build chạy mượt trong 5 lần demo, planning rõ ràng, gọi tool đúng thứ tự. Rồi lên production, nó lặp lại một action lỗi suốt 40 phút, hoặc "nhiệt tình" gửi email cho khách hàng mà không ai yêu cầu. Bài này tổng hợp 6 pattern kiến trúc giúp agent sống sót ở production — không phải bằng cách giới hạn autonomy của model, mà bằng cách kiểm soát nó đúng chỗ.

Vấn đề: demo che giấu đúng phần nguy hiểm nhất

Một kỹ sư từng viết thẳng: sự khác biệt giữa agent demo-ware và agent production-ware nằm ở chỗ hệ thống production dành phần lớn ngân sách thiết kế để giới hạn autonomy mà demo hay khoe khoang. Không phải loại bỏ autonomy — mà kiểm soát nó, có chủ đích, tại từng điểm nối cụ thể. Demo mạnh vì nó lược bỏ đúng những case gây đau đầu nhất: bước thứ ba trả về kết quả rỗng và agent tự bịa dữ liệu thay thế, hoặc vòng lặp chạy 40 phút không dừng.

Pattern 1 — Bounded Loop: đặt trần cho mọi trục có thể "chạy trốn"

Vòng lặp observe–decide–act–repeat chỉ nên lên production khi được bọc trong ngân sách rõ ràng. Một cấu hình thực tế: max_steps = 12 hành động mỗi task, max_tokens = 150.000 làm trần chi phí, max_wall_clock = 300 giây, tối đa 3 lỗi tool liên tiếp trước khi đầu hàng, và max_repeats = 2 để bắt lỗi gọi lại đúng tool với đúng tham số vô hạn lần.

Một ghi chú hiệu chỉnh từ thực tế production: phần lớn task hữu ích hội tụ ở số bước bất ngờ thấp, khoảng 5–15 bước. Nếu agent của bạn thường xuyên cần đến 40 bước, vấn đề không nằm ở autonomy — mà nằm ở việc bạn chưa decompose task đủ nhỏ.

Pattern 2 & 3 — Workflow skeleton và Tool Authorization Tiers

Quyết định cấu trúc có giá trị cao nhất: dùng một workflow skeleton xác định (deterministic) với từng stage bên trong mang tính agentic. Skeleton đóng góp thứ mà model làm kém — thứ tự đảm bảo, quyền truy cập tool theo từng stage, gate xác định giữa các stage. Các stage agentic đóng góp thứ mà pipeline cứng làm kém — xử lý sự đa dạng bên trong một bước.

Toàn bộ tool phải được phân tầng theo mức độ hậu quả, và việc phân tầng phải nằm trong tool executor chứ không phải trong prompt. Bốn tier cụ thể: Tier 0 — Observe (read, search, fetch, list, luôn sẵn sàng); Tier 1 — Reversible acts (draft, stage, tạo trong sandbox); Tier 2 — Consequential acts (send, merge, deploy-to-staging — cần kiểm tra điều kiện xác định trước khi thực thi); Tier 3 — Irreversible (thanh toán, xoá dữ liệu, deploy production — bắt buộc qua human gate hoặc không cho agent chạm tới).

Pattern 4 & 5 — Checkpoint/Resume và Critic Loop giới hạn

Task production kéo dài từ vài phút đến vài giờ, gặp tool chập chờn, bị restart khi deploy. Pattern ở đây là externalize toàn bộ state của agent — plan, các bước đã hoàn thành, kết quả tool, ý định đang chờ — vào một durable store tại mỗi step boundary, biến vòng lặp thành stateless và có thể resume.

Với critic loop — một model thứ hai review lại output của model đầu theo rubric — điểm mấu chốt là giới hạn ở đúng một vòng. Generate rồi critique rồi revise hội tụ trong một lần lặp với hầu hết task thực tế; thêm vòng nữa chỉ tạo dao động (bản sửa lại làm hỏng thứ vòng trước vừa sửa) với chi phí tuyến tính.

Pattern 6 — Human gate đặt đúng chỗ, không phá hỏng giá trị

Nguyên tắc: gate tại ranh giới hậu quả, không phải tại ranh giới từng bước. Một lần phê duyệt cho toàn bộ tập hành động đề xuất — kiểu "gửi 3 email này, tạo 2 ticket này — duyệt không?" — tốt hơn năm lần micro-approval liên tiếp, cả về throughput lẫn chất lượng chú ý của người duyệt.

Verify và eval: agent không chỉ cần kiến trúc, còn cần bằng chứng

Hệ thống generative fail khác phần mềm thông thường — nó không crash, nó tạo ra thứ nghe hợp lý, trôi chảy, và đôi khi sai, với vẻ mặt tự tin tuyệt đối. Vì vậy mọi claim tự động phải kèm bằng chứng có cấu trúc, không phải cảm tính — ví dụ một evidence gate ghi rõ URL, thời điểm fetch, loại kiểm tra, và verdict.

Về phía eval, một pipeline text lớn hiện chạy khoảng 3.900 test case mỗi lần thay đổi, với số lỗi kỳ vọng bằng đúng 0 — con số 0 này không thương lượng. Khi cần LLM-as-judge cho case không có đáp án đúng duy nhất, mỗi cặp được chấm hai lần với thứ tự A/B đảo ngược; chỉ verdict sống sót qua lần đảo mới được ghi nhận — và khoảng 11% không sống sót qua bài kiểm tra đó.

Áp dụng cho team VN đang build agent

Nếu team bạn đang dùng Claude Code, MCP, hoặc LangGraph để build agent nội bộ, hãy bắt đầu từ pattern rẻ nhất trước: thêm bounded loop và repeat detection vào vòng lặp hiện có, rồi mới tính đến tool tiering và checkpoint. Đừng chờ đến khi agent gây sự cố thật mới thêm ngân sách bước và cơ chế đầu hàng — chi phí thêm vào lúc thiết kế luôn rẻ hơn lúc production đang cháy.