Cách theo dõi nhật ký AI Agent để phát hiện lỗi và điều tra sự cố

Khi AI Agent trả lời sai hoặc tạo trùng một bản ghi, câu hỏi đầu tiên luôn là: chuyện gì đã xảy ra, và ở bước nào. Nếu hệ thống chỉ lưu câu hỏi và câu trả lời cuối cùng, đội kỹ thuật gần như phải đoán.

Với chatbot hỏi đáp đơn giản, thiếu nhật ký chỉ làm việc cải thiện chất lượng chậm lại. Với Agent có quyền ghi vào CRM, ERP hay gửi email cho khách, thiếu nhật ký nghĩa là không thể giải thích một sự cố cho khách hàng, cho kế toán hay cho kiểm soát nội bộ.

Bài viết trình bày nhật ký cần những trường nào, cách triển khai, và cách dùng log để phát hiện lỗi sớm thay vì chỉ mở ra khi đã có chuyện.

1. Bản chất của nhật ký AI Agent

Nhật ký AI Agent khác log ứng dụng thông thường ở chỗ phải ghi lại cả chuỗi quyết định và hành động, không chỉ lỗi kỹ thuật. Một yêu cầu của người dùng có thể dẫn tới nhiều bước: tìm tài liệu, gọi công cụ tra cứu, gọi thêm công cụ ghi, rồi mới trả lời. Mỗi bước là một sự kiện cần ghi và phải nối được với nhau.

Mức chi tiết nên tăng theo loại việc Agent làm. Với hỏi đáp từ kho kiến thức, cần biết đoạn tài liệu nào được dùng làm căn cứ. Với tra cứu thời gian thực, cần thêm hệ thống được gọi, thời điểm gọi và kết quả trả về. Với hành động ghi như tạo đơn, đổi trạng thái hay gửi thư, nhật ký phải trả lời được ai yêu cầu, ai duyệt, dữ liệu trước và sau thay đổi là gì, và hoàn tác bằng cách nào.

2. Các yếu tố cần thiết kế

1. Mã yêu cầu và người dùng

Mỗi yêu cầu cần một mã duy nhất sinh ra ngay khi nhận, rồi đi theo mọi sự kiện phía sau: truy xuất, gọi công cụ, phê duyệt, phản hồi. Kèm theo là định danh người dùng đã xác thực, hoặc mã phiên nếu là khách ẩn danh, và kênh gửi đến. Thiếu mã chung, đội vận hành phải ghép các dòng log rời rạc bằng giờ, rất dễ nhầm khi nhiều yêu cầu chạy cùng lúc.

2. Nguồn dữ liệu đã truy xuất

Khi Agent trả lời dựa trên tài liệu, nhật ký nên ghi mã tài liệu, phiên bản và đoạn được chọn, không cần chép toàn văn. Đây là cách để biết câu trả lời sai do mô hình diễn giải lệch hay do tài liệu đã cũ. Ví dụ Agent báo sai thời hạn đổi trả: log cho thấy nó dùng bản chính sách năm trước, vậy việc cần sửa là kho tài liệu chứ không phải prompt.

3. Công cụ đã gọi

Ghi tên công cụ, thứ tự gọi và lý do chọn nếu hệ thống có cung cấp. Một số lỗi chỉ lộ ra khi xem cả chuỗi: Agent tra cứu tồn kho hai lần liền, hoặc gọi công cụ ghi trước khi tra cứu xong.

4. Tham số và kết quả

Tham số truyền vào công cụ và kết quả trả về là phần giá trị nhất khi điều tra, vì đó là chỗ cách hiểu của mô hình trở thành dữ liệu thật. Nên lưu ở dạng có cấu trúc để lọc được, ví dụ tìm mọi lần gọi tạo đơn có số lượng bằng không. Trường nhạy cảm trong tham số phải được che trước khi ghi, theo chính sách ở mục 8.

5. Quyết định phê duyệt

Với hành động cần duyệt, nhật ký ghi ai được đề nghị duyệt, ai thực sự bấm, lúc nào, duyệt hay từ chối, và bản đề xuất họ đã nhìn thấy. Phần cuối hay bị bỏ qua nhưng rất quan trọng: nếu người duyệt chỉ thấy bản tóm tắt thiếu một trường, lỗi nằm ở giao diện duyệt chứ không ở người duyệt.

6. Thời gian và độ trễ

Mỗi sự kiện cần mốc thời gian theo cùng một múi giờ và một nguồn đồng hồ, cộng thời lượng của từng bước: truy xuất, gọi mô hình, gọi API. Khi người dùng phàn nàn Agent chậm, số liệu theo bước cho biết nên tối ưu chỗ nào. Độ trễ tăng bất thường ở một API cũng thường báo trước sự cố tích hợp.

7. Lỗi và lần thử lại

Lỗi cần được ghi kèm loại, như hết thời gian chờ, bị từ chối quyền, dữ liệu không hợp lệ hay lỗi mô hình, cùng số lần thử lại và kết quả cuối cùng. Mỗi lần thử lại một thao tác ghi phải mang cùng khóa chống lặp, để log chứng minh được hệ thống không tạo hai bản ghi.

8. Chính sách che dữ liệu

Nhật ký rất hữu ích nhưng cũng dễ thành nơi gom dữ liệu nhạy cảm nếu ghi bừa. Cần một danh sách trường phải che hoặc băm trước khi ghi: số điện thoại, số tài khoản, giấy tờ tùy thân, mật khẩu, token. Việc che nên làm ở tầng ghi log, không trông vào việc mô hình tự bỏ bớt, và phải được kiểm thử bằng dữ liệu mẫu có chứa đúng các trường đó.

3. Quy trình triển khai thực tế

Bước 1: Xác định phạm vi và kết quả cần đo

Liệt kê các loại sự cố mà nhật ký phải giúp trả lời: câu trả lời sai, thao tác trùng, hành động vượt quyền, phản hồi chậm. Từ đó suy ra những trường tối thiểu cần ghi cho từng loại yêu cầu. Đầu ra là bảng sự kiện và trường dữ liệu, được chủ nghiệp vụ và đội kỹ thuật cùng thống nhất.

Bước 2: Chuẩn hóa dữ liệu cùng quyền truy cập

Thống nhất định dạng sự kiện, múi giờ, cách đặt mã yêu cầu và danh sách trường cần che. Song song, quyết định ai được xem log ở mức nào: người vận hành xem nội dung đã che, kỹ thuật xem chi tiết tích hợp, chỉ vài người được xem dữ liệu gốc khi điều tra. Đầu ra là tài liệu định dạng log và ma trận quyền xem, do bộ phận an toàn thông tin xác nhận.

Bước 3: Thiết kế tích hợp ngoại lệ và phê duyệt

Gắn việc ghi log vào mọi điểm Agent chạm tới hệ thống: cổng gọi công cụ, bước duyệt, webhook nhận và gửi. Thiết lập cảnh báo cho các mẫu bất thường như tỷ lệ lỗi tăng đột ngột, thao tác ghi bị từ chối quyền, hay một mã yêu cầu gọi cùng công cụ quá nhiều lần. Đầu ra là danh sách cảnh báo kèm người nhận.

Bước 4: Kiểm thử vận hành rồi cải thiện theo log

Tạo sự cố có chủ đích trên môi trường thử: ngắt API, gửi trùng webhook, gửi yêu cầu vượt quyền. Kiểm tra xem một người không tham gia xây dựng, chỉ nhìn log, có tái hiện được chuyện đã xảy ra không. Sau khi vận hành, định kỳ đọc lại yêu cầu thất bại để bổ sung trường log còn thiếu.

4. Ví dụ giả định

Một đơn CRM được tạo hai lần. Nhật ký cho thấy webhook gửi lại sau timeout và luồng thiếu mã idempotency. Đội kỹ thuật sửa cơ chế chống lặp, chạy lại ca thử và giữ log liên kết hai sự kiện.

Từ sự cố này có thể rút ra vài ca thử cố định: webhook gửi lại sau khi hết thời gian chờ, hai yêu cầu giống hệt nhau đến gần như cùng lúc, và API CRM báo lỗi dù thực tế đã ghi thành công. Với mỗi ca, kết quả mong đợi là chỉ một đơn được tạo và log cho thấy rõ lần gọi sau bị chặn nhờ khóa chống lặp. Bài học rộng hơn: nếu hai sự kiện không mang chung một mã yêu cầu, đội kỹ thuật đã không nối được chúng để tìm ra nguyên nhân.

5. Rủi ro và giới hạn

• Không lưu bí mật hoặc toàn bộ dữ liệu không cần thiết
• Đồng bộ thời gian giữa hệ thống
• Giới hạn người xem log
• Đặt thời hạn lưu theo mục đích

Nhật ký là bản sao một phần của nhiều hệ thống, nên nó có thể thành điểm rò rỉ lớn nhất nếu không được bảo vệ. Chỉ ghi mã tham chiếu thay cho toàn văn tài liệu, không ghi mật khẩu hay token. Đồng hồ lệch giữa các máy chủ có thể làm đảo thứ tự sự kiện và dẫn tới kết luận sai khi điều tra. Log cũng là công cụ chính để phát hiện những lần thử chèn lệnh qua nội dung đầu vào, được trình bày ở bài prompt injection trong AI Agent.

6. Phân chia trách nhiệm vận hành

Đội kỹ thuật chịu trách nhiệm để log được ghi đủ, đúng định dạng, có cảnh báo và không làm chậm hệ thống. Người vận hành Agent đọc log định kỳ, phân loại yêu cầu thất bại và chuyển đúng người: sai tài liệu thì báo chủ nội dung, sai tích hợp thì báo kỹ thuật. Chủ sở hữu nghiệp vụ quyết định sự việc nào được coi là sự cố và mức độ nghiêm trọng của nó.

Bộ phận an toàn thông tin hoặc kiểm soát nội bộ nên là bên duy nhất cấp quyền xem log chưa che, và mỗi lần xem cũng được ghi lại. Khi có sự cố, cần một người có quyền tạm dừng công cụ ghi của Agent, giữ nguyên log liên quan và lập biên bản gồm nguyên nhân, phạm vi ảnh hưởng, cách khắc phục. Mỗi lần đổi prompt, mô hình hay quyền, log nên ghi phiên bản cấu hình để so sánh trước và sau.

7. Chỉ số nên theo dõi

• Tỷ lệ hoàn thành đúng theo tiêu chí đã duyệt
• Tỷ lệ từ chối đúng và chuyển người phụ trách
• Lỗi tích hợp, độ trễ và số thao tác phải sửa
• Chi phí cùng tác động kinh doanh của quy trình

Với nhật ký, câu hỏi không phải là ghi được bao nhiêu dòng mà là có giúp trả lời sự cố hay không. Nên đo thời gian từ lúc phát hiện đến lúc xác định được nguyên nhân, tỷ lệ yêu cầu có đủ chuỗi sự kiện từ đầu đến cuối, và số cảnh báo đúng so với cảnh báo nhiễu. Tách theo loại yêu cầu và theo công cụ để thấy lỗi đang tập trung ở đâu.

8. Checklist trước khi vận hành

• Nguồn dữ liệu và chủ sở hữu đã xác nhận
• Quyền đọc ghi đã thử với nhiều vai trò
• Có phương án khi hệ thống lỗi hoặc thiếu dữ liệu
• Có log, phê duyệt và cơ chế chống thao tác trùng
• Có bộ kiểm thử hồi quy và người vận hành

9. Câu hỏi thường gặp

Có nên bật nhật ký AI Agent ngay từ bản thử đầu tiên không? Nên, vì nhật ký thêm vào sau thường thiếu đúng những sự kiện cần nhất khi điều tra. Tuy vậy cần chốt trước danh sách trường phải che và người được xem log, để giai đoạn thử không vô tình lưu dữ liệu thật mà không ai kiểm soát.

Nên bắt đầu ghi nhật ký AI Agent từ đâu? Bắt đầu với mã yêu cầu chung và nhật ký của các thao tác ghi, vì đó là chỗ sự cố gây hậu quả thật. Khi phần này đã ổn, bổ sung nguồn tài liệu đã truy xuất và độ trễ từng bước để phục vụ cải thiện chất lượng.

Khi nào nhật ký phải ghi lại bước người duyệt? Với mọi hành động ảnh hưởng tiền, quyền, dữ liệu nhạy cảm hoặc cam kết với khách: log cần cho biết ai duyệt, lúc nào và dựa trên nội dung nào. Việc mở xem log chưa che dữ liệu cũng nên cần phê duyệt và được ghi lại như một thao tác riêng.

Nên lưu nhật ký AI Agent trong bao lâu? Không có một mốc chung cho mọi loại log. Log gỡ lỗi chi tiết thường chỉ cần giữ ngắn, còn log thao tác ghi và phê duyệt giữ theo yêu cầu kiểm soát nội bộ và quy định áp dụng cho doanh nghiệp. Quan trọng là thời hạn được ghi thành chính sách và việc xoá chạy tự động.

Kết luận

Nhật ký tốt biến một sự cố từ chuyện đoán mò thành một chuỗi sự kiện có thể đọc lại. Hãy thiết kế log cùng lúc với Agent, bắt đầu từ mã yêu cầu chung và các thao tác ghi, rồi kiểm thử bằng cách tự điều tra những sự cố dựng có chủ đích.

Log chỉ bảo vệ được doanh nghiệp khi đi cùng quyền truy cập hợp lý, cả quyền của Agent lẫn quyền xem log. Phần này được trình bày ở bài phân quyền AI Agent theo vai trò và chi nhánh.

Trao đổi với Naventic để khảo sát quy trình và thiết kế nhật ký cho AI Agent. Đọc thêm: AI Workflow Automation.