Debug AI Agent trong môi trường Production: Tại sao file log lại trở nên vô dụng?

Chúng tôi đã đưa một AI Agent vào vận hành (production). Ban đầu, nó hoạt động hoàn hảo... cho đến khi không còn như vậy.

Điều tồi tệ nhất là gì? Hệ thống log của chúng tôi cho thấy mọi thứ vẫn bình thường. Các cuộc gọi API thành công, các công cụ (tools) trả về kết quả hợp lệ và không có ngoại lệ nào xuất hiện.

Tuy nhiên, Agent vẫn liên tục đưa ra các quyết định sai lầm.

Đó là lúc chúng tôi nhận ra: Chúng ta không đang debug quá trình thực thi. Chúng ta đang debug quyết định tiềm ẩn (latent decision-making).

Hệ thống (Những gì chúng tôi thực sự xây dựng)

Đừng nhầm lẫn, đây không chỉ là một lớp bao bọc xung quanh LLM. Nó là một vòng lặp Agent hoàn chỉnh:

Truy vấn người dùng → Quy hoạch (Planner) → Chọn công cụ → Thực thi → Bộ nhớ → Bước tiếp theo

Trên lý thuyết, quy trình này rất gọn gàng. Nhưng thực tế, mỗi bước đều tiềm ẩn những rủi ro riêng:

• Planner có thể ảo tưởng về các hành động.
• Việc chọn công cụ có thể bị sai lệch.
• Thực thi có thể thành công nhưng kết quả lại không liên quan.
• Bộ nhớ có thể làm hỏng các quyết định trong tương lai.

Hệ thống không thất bại ở một điểm duy nhất. Nó sụp đổ qua sự tương tác của nhiều lớp.

Agent Loop

Sự cố đã "đánh gục" chúng tôi

Agent có một mục tiêu đơn giản:

1. Gọi một API.
2. Đánh giá phản hồi.
3. Dừng lại khi nhiệm vụ hoàn thành.

Thay vào đó, nó cứ lặp đi lặp lại mãi. Cùng một công cụ, cùng một hành động, lặp lại liên tục.

Triệu chứng

• Độ trễ (latency) ngày càng tăng.
• Lượng tiêu thụ token tăng vọt.
• Hệ thống không bao giờ kết thúc.

Từ bên ngoài, nó trông giống như một vòng lặp vô hạn kinh điển.

Những gì file log cho chúng tôi thấy

Mọi thứ đều trông chính xác:

• Các cuộc gọi công cụ thành công.
• Phản hồi hợp lệ.
• Không có lỗi hệ thống nào.

Vì vậy, chúng tôi đã kiểm tra các "thủ phạm" thông thường:

• Hạ tầng → Ổn định.
• API → Hoạt động tốt.
• Thực thi công cụ → Đúng.

Không có gì bị hỏng cả.

Vấn đề thực sự

Thất bại không nằm ở việc thực thi. Nó nằm ở lớp quyết định.

Agent nhận được một phản hồi hợp lệ. Nhưng nó không diễn giải đó là "nhiệm vụ hoàn thành". Vì vậy, nó tiếp tục hành động.

Đây là sự thay đổi tư duy mà nhiều người bỏ qua:

👉 Trong các hệ thống Agent, tính chính xác của đầu ra không đảm bảo tính chính xác của hành vi.

Mô hình không thất bại trong việc thực thi. Nó thất bại trong việc chuyển đổi trạng thái đúng cách.

Tại sao ghi log truyền thống thất bại

Ghi log tiêu chuẩn cung cấp cho bạn:

• Đầu vào.
• Đầu ra.
• Lỗi.

Nhưng nó hoàn toàn bỏ qua:

• Tại sao một quyết định được đưa ra?
• Agent tin gì về trạng thái hiện tại?
• Nó có coi nhiệm vụ đã hoàn thành chưa?

Bạn có khả năng quan sát quá trình thực thi. Nhưng không có khả năng quan sát lý do. Và đó chính xác là nơi thất bại tồn tại.

Why Traditional Logging Fails

Giải pháp thực sự đã khắc phục vấn đề

Chúng tôi phải suy nghĩ lại về cách quan sát hệ thống. Không phải như một chuỗi các lời gọi hàm, mà như một đồ thị quyết định phát triển theo thời gian.

1. Truy vết quyết định, không chỉ hành động

Thay vì chỉ ghi lại những gì đã xảy ra, chúng tôi bắt đầu theo dõi:

• Agent quyết định cái gì.
• Tại sao nó chọn một công cụ cụ thể.
• Trạng thái nội bộ của nó thay đổi như thế nào sau mỗi bước.

Điều này đã phơi bày một khoảng cách quan trọng: Sự hiểu biết nội bộ của Agent về nhiệm vụ đang phân kỳ với thực tế.

2. Làm cho đầu ra công cụ trở nên rõ ràng

Các phản hồi từ công cụ về mặt kỹ thuật là đúng. Nhưng chúng mơ hồ. Một phản hồi như "success" không cho Agent biết:

• Nhiệm vụ có hoàn thành không?
• Nó nên dừng lại?
• Có cần thêm bước nào nữa không?

Vì vậy, Agent mặc định là tiếp tục.

Giải pháp đơn giản nhưng mạnh mẽ: Làm cho mọi phản hồi công cụ định nghĩa rõ ràng trạng thái tiếp theo. Không cần sự diễn giải.

3. Giới hạn xác định (Deterministic Boundaries)

Các hệ thống Agent vốn dĩ là xác suất (probabilistic). Nhưng không phải mọi lớp đều nên như vậy. Chúng tôi đã đưa ra các ràng buộc xác định:

• Điều kiện kết thúc rõ ràng.
• Chuyển đổi trạng thái tường minh.
• Các rào chắn (guardrails) để ngăn chặn vòng lặp vô hạn.

Điều này làm giảm sự phụ thuộc của hệ thống vào "phán xét của mô hình" cho luồng điều khiển.

4. Tách biệt trạng thái tiềm ẩn khỏi trạng thái hệ thống

Đây là bước đột phá lớn nhất. Chúng tôi bắt đầu xử lý hai trạng thái riêng biệt:

• Trạng thái hệ thống → Những gì thực sự xảy ra.
• Trạng thái tiềm ẩn → Những gì Agent tin là đã xảy ra.

Khi hai trạng thái này phân kỳ, hệ thống sẽ hoạt động không thể đoán trước.

Debugging Gap

Vì vậy, chúng tôi đã làm cho trạng thái trở nên rõ ràng và liên tục củng cố nó. Ít mơ hồ hơn nghĩa là ít quyết định sai hơn.

Bài học thực sự

Hầu hết các kỹ sư tiếp cận việc debug với tư duy:

Nếu hệ thống chạy mà không có lỗi, thì nó đang hoạt động.

Giả định đó bị phá vỡ với các Agent. Bởi vì Agent không chỉ thực thi logic. Chúng diễn giải kết quả và quyết định việc cần làm tiếp theo. Và những quyết định đó có thể sai - ngay cả khi mọi thứ khác đều đúng.

Bạn nên làm gì thay vào đó

Nếu bạn đang xây dựng các hệ thống dạng Agent:

• Ngừng chỉ dựa vào file log.
• Bắt đầu theo dõi các luồng quyết định.
• Thiết kế đầu ra công cụ với ý nghĩa rõ ràng.
• Coi luồng điều khiển là một phần xác định.
• Liên tục đồng bộ trạng thái hệ thống với sự hiểu biết của mô hình.

Bạn không còn debug các hàm nữa. Bạn đang debug hành vi theo thời gian.

Suy nghĩ cuối cùng

Những lỗi khó sửa nhất mà chúng tôi thấy trong các hệ thống Agent không hiển thị trong log. Chúng tồn tại trong khoảng cách giữa:

• Những gì thực sự xảy ra.
• Những gì mô hình nghĩ là đã xảy ra.

Cho đến khi bạn có thể quan sát được khoảng cách đó, bạn thực sự không đang debug. Bạn chỉ đang đoán mò.