Những việc bạn nhất định phải làm để đánh giá và kiểm tra an toàn trước khi AI Agent ra mắt

Một startup chuyên làm về Agent chăm sóc khách hàng vừa ra mắt được ba tuần thì lượng khiếu nại không giảm mà lại tăng. Họ vô cùng bối rối—rõ ràng khi thử nghiệm mọi thứ đều chạy đúng. Sau đó, khi trích xuất lại lịch sử trò chuyện, họ mới phát hiện ra: đối với một loại câu hỏi nào đó, Agent lúc nào cũng tự tin trích dẫn "Điều khoản số 7 về chính sách hoàn tiền của công ty", trong khi bộ chính sách đó hoàn toàn không có điều khoản số 7. Nó không phải là không biết, mà là bịa ra những thứ không có thật một cách quá mức chân thực, và đợt test trước khi lên sóng lại vô tình bỏ sót nhóm trường hợp này.

Đây chính là dạng thất bại nguy hiểm nhất của Agent — nó không báo lỗi đỏ, không throw exception. Nó âm thầm, lịch sự, mạch lạc làm sai, và rồi người dùng của bạn tin sái cổ.

Tại sao Agent lại gặp tình trạng "thất bại thầm lặng"

Phần mềm truyền thống khi xảy ra lỗi thường sẽ "nổ tung" cho bạn thấy: bung lỗi, trả về mã 500, stack trace chỉ thẳng đến dòng mấy. Agent thì khác. Đầu ra của nó là được "sinh ra" (generated), ngôn ngữ lúc nào cũng trôi chảy, thế nên lỗi được đóng gói trông y hệt như đáp án đúng.

Phiền phức hơn nữa là quy trình nhiều bước (multi-step). Một chuỗi Agent chạy có thể gọi công cụ 5, 6 lần, bất kỳ bước nào ở giữa bị lệch hướng — tra sai dữ liệu, truyền sai tham số, bỏ sót một điều kiện — thì các bước sau sẽ tiếp tục suy luận dựa trên sai số đó, và cuối cùng đưa ra cho bạn một kết quả "tự hợp lý hóa nhưng lại sai". Nhìn vào đáp án cuối cùng, bạn hoàn toàn không nhận ra chỗ nào bị chệch choạc.

Chính vì thế, việc đảm bảo chất lượng (QA) cho Agent không thể dựa vào việc kiểm tra ngẫu nhiên thủ công, hay kiểu "tôi chạy thử vài lần thấy ổn phết". Bạn cần một cơ chế có thể định lượng, có thể phát lại (replay), và có thể giám sát liên tục trên môi trường production. Đây chính là lúc ba tầng gồm đánh giá (evaluation), bảo mật và khả năng quan sát (observability) được nhắc đến trong bài viết 〈Muốn tự làm một AI Agent, cần chuẩn bị những công cụ nào〉 thực sự phát huy tác dụng ở giai đoạn lên sóng.

Điểm trọng tâm: Bốn việc cần kiểm soát trước khi đưa lên production

• Đánh giá ngoại tuyến (Offline Eval): Dùng một bộ câu hỏi cố định để định lượng xem chất lượng có bị sụt giảm sau mỗi lần thay đổi hay không.
• Kiểm thử đối kháng (Red Teaming): Chủ động tìm kiếm điểm yếu của nó — kiểu dữ liệu đầu vào nào sẽ khiến nó vượt ranh giới,aém gió, hoặc rò rỉ thông tin.
• Gỡ lỗi nhiều bước (Multi-step Debugging): Khi xảy ra lỗi có thể phát lại toàn bộ đường đi thực thi (execution trace), định vị xem bước nào bị lệch.
• Giám sát trực tuyến và Guardrails: Tiếp tục theo dõi chất lượng và chi phí sau khi lên sóng, đồng thời thiết lập các bộ lọc chặn trước các thao tác nguy hiểm.

Bốn điều này, thiếu một điều nào thì việc bạn đưa sản phẩm lên production chẳng khác nào đánh bạc.

Cách kiểm thử: Promptfoo

Tinh thần cốt lõi của đánh giá ngoại tuyến là thay thế "tôi thấy đã tốt hơn" bằng "các con số nói cho tôi biết nó đã tốt hơn".Promptfoo giúp bạn thiết lập một bộ ca kiểm thử (test cases) — đầu vào, hành vi mong đợi, tiêu chuẩn phán đoán — và sau đó mỗi khi thay đổi prompt, đổi mô hình (model), điều chỉnh tham số, bạn chỉ cần chạy lại toàn bộ để xem điểm số thay đổi ra sao.

Tiêu chuẩn phán đoán có thể là so khớp chuỗi, biểu thức chính quy (regex), hoặc dùng một mô hình khác làm trọng tài (LLM-as-judge) để đánh giá "câu trả lời này có trích dẫn đúng nguồn hay không". Startup ở phần đầu bài nếu có một khẳng định (assertion) rằng "số điều khoản chính sách được đề cập trong câu trả lời bắt buộc phải có thật", thì cái điều khoản số 7 kia tuyệt đối không bao giờ được phép lên sóng.

Kiểm thử đối kháng (Red Teaming) cũng được thực hiện ở tầng này. Promptfoo có thể chạy một loạt các đầu vào mang tính đối kháng, nhằm mục đích khiến Agent làm rò rỉ system prompt, vượt qua giới hạn, thực hiện những hành động không nên làm. Nếu bạn không chủ động tấn công nó, người dùng (hoặc kẻ có ý đồ xấu) sẽ làm thay bạn. Thà tự mình đánh úp nó trước vẫn hơn.

Cách gỡ lỗi: AgentOps

Đánh giá cho bạn biết "câu trả lời đã sai", nhưng không nói cho bạn biết "sai ở bước thứ mấy". Gỡ lỗi nhiều bước cần phải nhờ đến AgentOps.

Công cụ này kết nối toàn bộ chuỗi thực thi của một vòng đời Agent thành một dòng thời gian có thể phát lại: bước đầu tiên gọi công cụ gì, truyền tham số nào, nhận lại kết quả gì, tốn bao nhiêu token, bước thứ hai dựa vào đâu để quyết định bước tiếp theo… Toàn bộ đều được phơi bày rõ ràng. Ví dụ về chính sách hoàn tiền ở trên, nếu nhìn vào AgentOps, bạn sẽ thấy rất rõ ràng — một đoạn tài liệu được truy xuất về ở bước nào đó đã bị sai từ trước, và mọi thứ phía sau đều là suy luận hợp lý dựa trên dữ liệu sai lệch đó. Nếu không có chuỗi vết tích (trace) này, bạn sẽ chỉ biết trừng mắt nhìn đáp án cuối cùng trong bất lực.

Cách giám sát: Langfuse

Production không phải là điểm dừng, mà là một điểm khởi đầu khác. Dữ liệu đầu vào trong môi trường thực tế vô cùng muôn hình vạn trạng, người dùng sẽ đặt ra những câu hỏi mà bạn nằm mơ cũng không nghĩ tới trong lúc test. Langfuse chịu trách nhiệm ghi lại lâu dài mọi cuộc trò chuyện trực tuyến, chi phí token của từng giao dịch, và độ trễ của từng câu trả lời, giúp bạn theo dõi xem chất lượng có bị trôi dạt (drift) theo thời gian hay không, nhóm câu hỏi nào trả lời tệ nhất, hoặc chi phí có bị vượt tầm kiểm soát không.

Sự phân công công việc giữa nó và AgentOps đại khái là: AgentOps nghiêng về gỡ lỗi sâu mang tính đơn lẻ trong giai đoạn phát triển, còn Langfuse nghiêng về giám sát tập thể lâu dài trên môi trường production. Trong thực tế, rất nhiều đội ngũ sử dụng cả hai. Điều quan trọng là — bạn phải có một nơi sẵn sàng trả lời câu hỏi: "Agent của tôi tuần này hoạt động ra sao?". Không trả lời được, tức là bạn đang "cởi truồng chạy rông" trên mạng.

Hàng rào bảo vệ (Guardrails): Lớp chặn cuối cùng

Đánh giá, gỡ lỗi, giám sát đều mang tính chất "biết trước hoặc biết sau", còn Guardrails (hàng rào bảo vệ) là "chặn lại ngay tại thời điểm đó". Trước khi Agent thực hiện các hành động nguy hiểm — thanh toán, xóa dữ liệu, gửi thông tin ra ngoài, thực thi lệnh hệ thống — hãy gắn thêm một lớp kiểm tra quy tắc hoặc xác nhận thủ công.

Những gì Guardrails nên chặn: che khuất (masking) khi đầu ra chứa thông tin cá nhân hoặc bí mật; chuyển sang nhân viên con người khi số tiền vượt ngưỡng; tạm dừng khi phát hiện prompt injection. Tầng này được kết hợp sử dụng cùng với hộp cát thực thi (execution sandbox) trong chuỗi công cụ (ví dụ như Blaxel) — sandbox giới hạn việc nó "có thể chạy cái gì", còn Guardrails giới hạn việc nó "được làm cái gì".

Trọng tâm kiểm soát dành cho ba loại nhóm phát triển

Lập trình viên cá nhân tại Đài Loan: Ít nhất hãy tích hợp Promptfoo vào quy trình. Dù chỉ có hai mươi ca kiểm thử, vẫn còn hơn là mỗi lần sửa xong lại dựa vào cảm tính. Với kiểm thử đối kháng, chỉ cần chọn ra vài mặt trận tấn công nguy hiểm nhất để chạy, đừng theo đuổi sự toàn diện hoàn hảo.

Đội ngũ Startup: Nên đưa AgentOps và Langfuse vào sử dụng sớm. Sản phẩm của bạn vẫn đang lặp lại và phát triển nhanh chóng, nếu không có khả năng quan sát (observability), mỗi lần xảy ra sự cố là cả đội lại cùng nhau mò kim đáy bể trong đống log, thời gian mò mẫm đó đủ để bạn làm thêm được hai tính năng mới. Ưu tiên bảo vệ các hành động "tốn tiền" và "không thể đảo ngược" bằng Guardrails.

Doanh nghiệp: Kiểm thử đối kháng và Guardrails là ranh giới tuân thủ (compliance) cơ bản. Các câu hỏi mà bộ phận an toàn thông tin và pháp chế sẽ đặt ra như "dữ liệu có bị rò rỉ không", "có kiểm toán được mọi quyết định ở từng bước hay không" — câu trả lời đều ẩn giấu trong lịch sử kiểm thử đối kháng của Promptfoo và vết tích thực thi của AgentOps. Việc lưu giữ những hồ sơ này đồng thời cũng là chuẩn bị sẵn các bằng chứng kiểm toán.

Checklist trước khi lên sóng

Hãy làm theo đúng những mục sau:

• Có sẵn một bộ câu hỏi kiểm thử ít nhất bao phủ được các tình huống thông thường và ngoại biên (edge cases), chạy trên Promptfoo.
• Mỗi khi thay đổi prompt hoặc đổi model, đều phải chạy qua toàn bộ quá trình đánh giá, điểm số không bị sụt giảm mới được phát hành.
• Đã thực hiện ít nhất một vòng kiểm thử đối kháng, thử nghiệm prompt injection, vượt ranh giới,aém gió.
• Đối với các câu trả lời thuộc dạng "tuyên bố sự thật", phải có các câu khẳng định (assertion) kiểm tra tính có thật của nguồn tin.
• Quy trình nhiều bước đã được kết nối với AgentOps để khi xảy ra lỗi có thể phát lại và định vị đến đúng bước đó.
• Đã tích hợp Langfuse trên môi trường production để theo dõi sự trôi dạt chất lượng và chi phí.
• Trước các thao tác nguy hiểm (thanh toán, xóa dữ liệu, gửi đi bên ngoài) đều có hàng rào bảo vệ hoặc sự xác nhận thủ công.
• Đã thiết lập hạn mức token và chi phí để tránh việc các Agent chạy ngầm "đốt tiền".
• Việc thực thi mã nguồn nguy hiểm được chạy bên trong môi trường sandbox.
• Có sẵn một người phụ trách, khi xảy ra sự cố sẽ biết ngay lập tức đâu là nơi cần phải xem xét đầu tiên.

Tổng kết và Nhận định từ TheAI學院

Rủi ro lớn nhất khi đưa Agent lên môi trường production chưa bao giờ là công nghệ chưa đủ mạnh, mà là "bạn không biết khi nào nó làm sai". Đánh giá giúp bạn biết trước, khả năng quan sát giúp bạn tra cứu sau sự cố, hàng rào bảo vệ giúp bạn chặn lại ngay tại thời điểm đó — giá trị của ba việc này có thể bình thường bạn không cảm nhận được, nhưng vào cái ngày xảy ra sự cố, nó sẽ cứu mạng bạn.

"Một Agent mà bạn không thể nhìn thấy bên trong, không thể định lượng được chất lượng, thì dù chạy mượt mà đến đâu cũng chỉ là một quả bom hẹn giờ; sự tầm thường có thể kiểm tra được, vượt trội hơn hẳn sự thông minh mà bạn chẳng thể nhìn thấy."

Gợi ý cụ thể dành cho độc giả: Trước khi lên sóng, hãy tự ép mình trả lời một câu hỏi — "Nếu ngày mai nó làm sai một việc trước mặt khách hàng, tôi mất bao lâu để tìm ra đó là bước nào và tại sao?". Nếu không trả lời được là "trong vòng mười phút", thì đừng vội đưa lên production, hãy quay lại hoàn thiện ba tầng Promptfoo, AgentOps và Langfuse. Về cách xây dựng một chuỗi công cụ hoàn chỉnh, bạn có thể xem lại bài viết 〈Sơ đồ toàn tập chuỗi công cụ cho lập trình viên 2026〉.