Validate agent — khi đúng không còn một đáp án duy nhất

Hệ thống agent production-ready không nhờ model xịn mà nhờ lớp validate đứng bên ngoài. Bài này giải thích cách nghĩ về correctness trong thế giới non-deterministic.

Bạn deploy agent lên CI, thứ Ba xanh lè, thứ Tư đỏ lòm — không ai đụng code. Nếu bạn từng trải qua cảnh này, bài này dành cho bạn.

Vấn đề không nằm ở agent làm sai. Vấn đề nằm ở cách bạn định nghĩa "đúng" đang quá cứng cho một hệ thống vốn dĩ non-deterministic — tức mỗi lần chạy có thể đi đường khác nhau mà vẫn ra kết quả hợp lệ.

Correctness trong agent: khái niệm builder hay bỏ qua

Với software truyền thống, test đơn giản: input A cho output B, lặp lại y hệt mỗi lần. Nhưng agent hoạt động khác. Một coding agent có thể mở file bằng hotkey hoặc bằng menu, gặp loading screen hoặc không, xử lý task theo 3 bước hoặc 5 bước — tất cả đều hợp lệ.

Dịch sang tiếng người: correctness của agent không phải "đi đúng đường" mà là "đến đúng chỗ".

GitHub vừa publish nghiên cứu về Trust Layer cho Copilot Coding Agent, dùng một kỹ thuật từ compiler theory gọi là dominator analysis — phân tích điểm thống trị. Ý tưởng cốt lõi: trong đồ thị thực thi, có những state bắt buộc phải đi qua (essential) và những state xuất hiện hay không đều được (optional). Thay vì kiểm tra agent có đi đúng từng bước không, ta chỉ kiểm tra nó có chạm đủ các milestone bắt buộc hay không.

Hiểu nôm na: thay vì yêu cầu đầu bếp phải cắt hành trước cắt tỏi, bạn chỉ cần xác nhận lúc món lên bàn thì hành và tỏi đều đã vào nồi.

Tại sao builder cần quan tâm ngay bây giờ

Nhiều team Việt Nam đang build agent — từ chatbot nội bộ đến coding assistant, research workflow — nhưng phần validate thường rơi vào một trong hai thái cực:

1. Không validate gì cả: tin agent self-report ("task completed successfully"). Dữ liệu từ GitHub cho thấy agent tự đánh giá chỉ đạt 82% accuracy, và recall chỉ 60% — nghĩa là 4/10 lần agent báo thành công mà thực tế thất bại, bạn không biết.

1. Validate quá cứng: ghi script từng bước rồi assert chính xác. Kết quả là false negative liên tục — agent làm đúng nhưng test báo sai vì đường đi khác script.

Cả hai đều tạo ra "trust gap": team không tin kết quả CI, bắt đầu bỏ qua alert, và dần dần agent trở thành demo đẹp nhưng không ai dám dùng thật.

Hai kịch bản thực tế

Kịch bản 1 — Team 5 người, research agent nội bộ:

Giả sử team bạn build một agentic research assistant dùng LangGraph với tool calling (gọi công cụ bên ngoài), sub-agent delegation (chia việc cho agent con), và long-term memory (bộ nhớ dài hạn qua nhiều phiên). Workflow: user đặt câu hỏi → agent search web → fetch trang → tổng hợp → lưu kết quả.

Nếu validate bằng script cứng ("bước 1 phải gọi DuckDuckGo, bước 2 phải fetch đúng URL X"), test sẽ fail mỗi khi agent chọn nguồn khác hoặc skip một bước không cần thiết. Cách đúng: định nghĩa essential states — "phải có kết quả search", "phải có nội dung trang được fetch", "phải có summary cuối cùng" — rồi validate theo thứ tự logic, bỏ qua các bước phụ.

Kịch bản 2 — Team product, agent xử lý UI automation:

Agent dùng Computer Use để test flow đăng ký trên web app. Có lúc popup cookie xuất hiện, có lúc không. Có lúc CAPTCHA delay 3 giây, có lúc load ngay. Test truyền thống sẽ flaky đến mức vô dụng. Nhưng nếu bạn model execution thành đồ thị và chỉ assert essential milestones ("form đã submit", "confirmation page đã hiện"), agent được tự do xử lý noise mà không bị phạt oan.

Bẫy mà team nào cũng từng bước vào

Bẫy 1: Để agent tự chấm điểm chính mình.

Nghiên cứu của GitHub chỉ ra: khi dùng agent self-assessment để phát hiện lỗi thuộc loại "not a bug" (agent stumble do môi trường, không phải lỗi product), F1-score là 0%. Không phải thấp — là zero. Agent không thể đáng tin khi tự đánh giá output của chính nó trong môi trường non-deterministic.

Nói thẳng: để agent tự validate giống như để đầu bếp tự review món mình nấu rồi tuyên bố "ngon rồi" — bạn cần một người nếm thử độc lập.

Bẫy 2: Đổ tiền vào model mới thay vì fix validation.

Đây là hiểu lầm phổ biến nhất. Team thấy agent fail → upgrade model → agent vẫn fail kiểu khác → kết luận "AI chưa đủ tốt". Thực tế: vấn đề nằm ở lớp validate đang quá brittle, không phải model thiếu năng lực. Framework validate đúng sẽ giúp bạn phân biệt được "agent lỗi thật" vs "test lỗi" — tiết kiệm hàng tuần debug mù.

Bẫy 3: Không tách essential khỏi optional từ đầu.

Nếu không định nghĩa rõ đâu là milestone bắt buộc trước khi build, bạn sẽ viết test cho mọi thứ agent làm, bao gồm cả những bước incidental. Kết quả: mỗi lần agent thay đổi hành vi (điều hoàn toàn bình thường), test suite vỡ hàng loạt.

Framework mang về: Essential → Graph → Dominator

Nếu bạn đang build agent cho production, đây là ba bước tư duy:

1. Liệt kê essential states: Task này thành công khi và chỉ khi những milestone nào xảy ra? Viết ra trước khi code.

1. Model execution thành graph, không phải script: Chấp nhận rằng agent sẽ đi nhiều đường. Dùng Prefix Tree Acceptor (đồ thị chấp nhận tiền tố) — gom 2-10 lần chạy thành công thành một đồ thị tổng hợp.

1. Dùng dominator analysis để tự động tách essential khỏi noise: State nào mọi đường đều phải đi qua → essential. State nào chỉ xuất hiện ở một số đường → optional. Validate chỉ dựa trên essential.

Không cần train model riêng, không cần thousands of examples. Chỉ cần vài lần chạy thành công là đủ build ground truth.

Về tooling: nếu team dùng LangGraph hoặc framework multi-agent tương tự, hãy bắt đầu bằng việc log execution trace có cấu trúc — đó là nguyên liệu thô để build validation graph sau này. Open-source framework như LangSmith (tracing) hoặc Braintrust (eval) có thể giúp bước đầu, dù chưa có tool nào implement đầy đủ dominator analysis cho agent.

Một câu đúc kết: agent giỏi mà không có lớp validate độc lập thì cũng chỉ là demo — production cần bằng chứng, không cần lời hứa.

---

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