Gỡ lỗi AI Agent: Bảng điều khiển của bạn biết chi phí nhưng không biết nguyên nhân

Gỡ lỗi tác nhân AI bắt đầu từ nơi bảng điều khiển quan sát của bạn kết thúc. Khi một tác nhân mã AI làm hỏng thứ gì đó và phiên chạy đã kết thúc, bảng điều khiển có thể cho bạn biết phiên chạy đó tiêu tốn bao nhiêu (token, đô la, độ trễ), nhưng sẽ im lặng trước câu hỏi duy nhất bạn thực sự quan tâm: tại sao tác nhân đó lại thay đổi tập tin kia? Công cụ trả lời câu hỏi này là một bản ghi trace đã được lưu lại mà bạn có thể mở, đọc và phát lại, vì nó trả lại phiên chạy cho bạn thay vì chỉ mô tả nó từ bên ngoài.

Việc này không còn là chuyện hiếm gặp kể từ khi các tác nhân bắt đầu làm việc thực sự. Một tác nhân sẽ quét qua kho mã nguồn, sửa nhiều tệp, chạy kiểm tra và báo cáo thành công, tất cả chỉ giữa hai lần nhắc mà bạn gõ cách nhau vài phút. Nếu một trong những chỉnh sửa đó sai, bạn sẽ phát hiện ra muộn hơn: sau khi cửa sổ terminal đã đóng, sau khi vùng cuộn lại đã biến mất, sau khi tiến trình đáng lẽ có thể tự giải thích đã thoát. Điều xảy ra tiếp theo phụ thuộc hoàn toàn vào thứ bạn giữ lại. Nếu câu trả lời là một bảng điều khiển chi phí, bạn sắp phải khai quật. Nếu câu trả lời là một bản ghi, bạn sắp phải đọc.

Lỗi bạn không thể tái hiện

Đại loại là thế này. Bạn quay lại kho lưu trữ và một tệp bạn chưa bao giờ nhờ ai đụng tới đã bị viết lại, bị xóa, hoặc bị rút sạch hàm mà mọi thứ khác phụ thuộc vào. Bạn hỏi tác nhân đã xảy ra chuyện gì; phiên làm việc đã đóng, và ngay cả khi bản ghi còn tồn tại, lời tường thuật của tác nhân về chính phiên chạy của nó cũng chỉ là sự dựng lại, không phải bản ghi thực. Thế là bạn làm điều hiển nhiên và chạy lại, rồi bạn nhận được một phiên chạy khác. Các lời gọi công cụ khác, các chỉnh sửa khác, thậm chí có thể chẳng có lỗi nào, vì quỹ đạo ban đầu phụ thuộc vào việc lấy mẫu, vào trạng thái của kho lưu trữ, vào thời điểm. Phiên chạy bạn cần kiểm tra không còn tồn tại nữa.

Nó còn tệ hơn việc không thể tái tạo được. Nó không chỉ không thể tái tạo được, mà còn được đánh dấu là thành công. Một lần chạy thoát với mã 0 khi agent thoát với mã 0, ngay cả khi một bước kiểm tra bên trong lần chạy đó thoát với mã 1: pipeline có thể vẫn xanh trong khi một bước xác minh bên trong lần chạy đã thất bại, và mã thoát mà bạn đương nhiên tin tưởng lại chẳng cho bạn biết điều gì cả.

Không quan trọng router đã chọn mô hình nào để chạy (GLM 5.3 Flash hay bất kỳ loại nào khác): một khi tiến trình kết thúc, suy luận cũng biến mất theo. Bằng chứng chỉ tồn tại trong lúc lần chạy còn hoạt động: lời nhắc, lời gọi công cụ, kết quả đầu ra, các bản diff. Nếu không thứ gì ghi lại chúng, câu hỏi "tại sao nó lại thay đổi tệp đó" sẽ không có câu trả lời — chỉ có giả thuyết.

Đây là dạng thất bại phân biệt các AI agent viết mã với mọi công cụ đã có trước chúng: cả thiệt hại lẫn lời giải thích đều xảy ra ở cùng một nơi, và nơi đó đóng lại.

Dashboard đo lường điều gì, và nó bỏ qua điều gì?

Bản năng sau một lần chạy không tốt là mở bảng điều khiển quan sát, và bảng điều khiển đó sẽ thực sự làm tốt công việc của mình. Công việc của nó là lưu lượng truy cập: số token mỗi ngày, chi phí theo từng mô hình, độ trễ, tỷ lệ lỗi. Đối với việc lập kế hoạch công suất và tính phí, đó chính xác là công cụ phù hợp, và nếu bạn vận hành agent trong môi trường production, bạn nên giữ nó luôn mở.

Nhưng câu hỏi của bạn không phải là câu hỏi tổng hợp. Nó là câu hỏi số ít và nhân quả: tại sao lần chạy này lại thay đổi tập tin này? Phép tổng hợp bỏ qua chính xác mức độ chi tiết có thể trả lời câu hỏi đó. Khi lấy trung bình qua nhiều lần chạy, lần chạy bạn quan tâm chỉ là nhiễu; trong lần chạy đó, lời gọi công cụ bạn quan tâm lại cũng chỉ là nhiễu.

Bảng điều khiển mô tả một lần chạy từ bên ngoài: rằng nó đã xảy ra, nó nặng bao nhiêu, nó tốn bao nhiêu. Nó không thể trao cho bạn lần chạy đó, và “tại sao” không phải là một thuộc tính của sự mô tả. Nó là một thuộc tính của chuỗi.

• Lần chạy này tốn bao nhiêu? — Bảng điều khiển chi phí trả lời điều đó so với dấu vết được ghi lại trả lời điều đó

• Tại sao agent lại sửa tệp tin đó? — Bảng tổng quan chi phí Không có câu trả lời so với trace đã được ghi lại Bản chỉnh sửa, theo đúng trình tự, kèm diff của nó

• Kiểm tra nào đã thất bại trong một lần chạy xanh? — Bảng điều khiển chi phí: Không có phản hồi so với Dấu vết đã ghi lại. Kiểm tra, với mã thoát của nó.

• Tôi có thể chạy lại chính xác lỗi đó không? — Cost dashboard: Không; Recorded trace: Có — ngoại tuyến, miễn phí.

Lớp trả lời cho vấn đề đó nằm ngay bên dưới: nhật ký yêu cầu đã được ghi lại, được thu thập ngay khi quá trình chạy diễn ra, với từng lời nhắc được gửi đi, từng lệnh gọi công cụ được thực hiện, từng phản hồi nhận về, theo đúng thứ tự. Không phải là bản tóm tắt của quá trình chạy. Mà chính là quá trình chạy đó.

Đọc một lần chạy như một dòng thời gian

Khi có bản ghi, việc gỡ lỗi không còn là khảo cổ nữa mà trở thành việc đọc. Khảo cổ là thứ bạn làm khi không có nó: git reflog, các mục stash, lịch sử shell, và ký ức riêng của bạn về những gì bạn đã yêu cầu hồi đầu ngày. Đọc là thứ bạn làm khi có nó: mở dòng thời gian và cuộn.

Dòng thời gian trình bày toàn bộ tiến trình theo đúng thứ tự diễn ra: lời nhắc khởi động, từng lời gọi công cụ, từng thay đổi tệp kèm phần diff, từng lần kiểm tra, từng mã thoát. Một bản chụp hệ thống tệp được tạo mỗi lượt thay vì mỗi lần gọi công cụ — như vậy là đủ để thấy trạng thái của kho lưu trữ tại từng bước của cuộc trò chuyện mà không bị nhấn chìm trong nhiễu từ từng lời gọi. Điều khiến việc này mang tính gỡ lỗi chứ không phải duyệt thông thường là tính liền kề: thao tác chỉnh sửa và lần kiểm tra phát hiện ra nó nằm cạnh nhau, theo đúng thứ tự, không có gì xen giữa để phải suy đoán. "Tại sao" về cơ bản là một thuộc tính của tính liền kề.

Một ví dụ cụ thể, đọc từ bản ghi của một phiên sửa lỗi: 14 sự kiện, gồm thay đổi tệp được in ra dạng +1 -3 và một bước kiểm tra thất bại với mã thoát 1. Bước chỉnh sửa rồi đến bước kiểm tra thất bại vì chính nó, nằm cạnh nhau trong bản ghi. Đó là toàn bộ sự khác biệt giữa việc dựng lại một lần chạy từ các mảnh rời và việc đọc trọn vẹn một lần chạy. Điều này quan trọng nhất đối với các tác nhân lập trình trên terminal, nơi làm việc của họ là một terminal đóng lại ngay khi công việc hoàn tất: dòng thời gian chính là phần scrollback còn sót lại.

Được ghi lại hay được suy ra: những gì trace biết so với những gì nó suy luận được

Dòng thời gian cho bạn biết điều gì đã xảy ra theo thứ tự. Biểu đồ nhân quả cho bạn biết điều gì dẫn đến điều gì, và khoảng cách giữa hai thứ đó chính là nơi lòng tin cần được tạo dựng.

Đồ thị kết nối các sự kiện: bản sửa này, rồi đến lần kiểm tra thất bại này. Một số cạnh là các dữ kiện được ghi lại: lời gọi công cụ tạo ra diff nằm ngay trong trace. Những cạnh khác được suy ra: kết luận của đồ thị rằng lần kiểm tra thất bại là do diff đó. orca graph gắn nhãn mọi cạnh là đã ghi lại hoặc được suy ra, đồng thời nêu tên quy tắc nó đã dùng dù theo cách nào, để bạn luôn biết mình đang xem thứ do lần chạy thực hiện hay thứ mà công cụ đã suy luận về lần chạy.

Sự phân biệt đó được thực thi, chứ không chỉ là khát vọng: các cạnh được suy ra không bao giờ được ghi ngược vào trace. Trace vẫn là một bản ghi trung thực về những gì đã xảy ra; suy luận chỉ là một góc nhìn bên trên nó, mà bạn có thể kiểm tra, chất vấn và phản đối. Điều này đặc biệt quan trọng khi có nhiều hơn một tác nhân tham gia. Khi một tác nhân refactor và một tác nhân viết test cùng thao tác trên những tệp tin giống nhau, "tác nhân nào đã gây ra điều này" chính là câu hỏi mà sự quy kết đa tác nhân tồn tại để trả lời. Một cạnh âm thầm tự nâng mình từ suy luận thành sự thật chính là cách bạn cuối cùng phải gỡ lỗi một câu chuyện thay vì một lần chạy.

Sao chép nó bao nhiêu lần tùy thích mà không mất phí.

Đọc thì giải thích được. Phát lại thì chứng minh được. Một khi bạn đã có một giả thuyết (lần kiểm tra thất bại vì thao tác sửa đổi đã xóa lời gọi reset), bạn sẽ muốn chạy lại và quan sát điều đó xảy ra. Chạy lại agent trực tiếp sẽ mang lại cho bạn một quỹ đạo mới và một hóa đơn mới.

Phát lại bản ghi sẽ mang lại cho bạn đúng cùng một lần chạy: lần phát lại chạy với mạng bị chặn, nên không tốn token và không có sai khác. Các sự kiện giống hệt nhau, mỗi lần, đều ngoại tuyến. Đó chính là đặc tính biến việc gỡ lỗi agent từ một canh bạc thành kỹ thuật: lỗi đã trở thành tất định, và các lỗi tất định sẽ được khắc phục.

Bộ công cụ này cũng không phải là hộp đen. OrcaReplay là mã nguồn mở theo Apache-2.0 và định dạng trace được cấp phép CC BY 4.0, vì vậy bất kỳ ai cũng có thể triển khai lại nó: bản ghi của bạn không bị ràng buộc bởi định dạng độc quyền, kể cả bản ghi của chúng tôi. Và nó được kiểm chứng, không phải chỉ trình diễn: 1393 bài kiểm tra trên Node 20 và Node 22. Bạn có thể đọc mã nguồn, kiểm tra định dạng, và tự chạy bộ kiểm thử trước khi tin tưởng giao phó bất kỳ phần nào của nó cho các phiên chạy của nhóm bạn.

Bài học rút ra

Một dashboard chính là một hóa đơn. Một trace được ghi lại chính là lần chạy. Nếu kế hoạch gỡ lỗi agent AI của bạn chỉ dừng lại ở một dashboard chi phí, thì bạn không hề có kế hoạch gỡ lỗi: bạn chỉ có một hệ thống thanh toán. Dashboard sẽ luôn cho bạn biết một lần chạy tốn bao nhiêu tiền, nhưng sẽ không bao giờ cho bạn biết vì sao agent xóa file của bạn, bởi "vì sao" nằm trong chuỗi hành động, và chuỗi đó chỉ tồn tại nếu bạn đã giữ lại nó.

Toàn bộ phương pháp gồm bốn bước:

• Ghi lại các lần chạy.

• Đọc dòng thời gian. PHẦN 1: Chiến lược cho hacker ngày nay

• Kiểm tra các cạnh của đồ thị.

Phát lại những thứ khiến bạn sợ hãi, miễn phí, bao nhiêu lần tùy thích.

Ghi chú về nguồn: Mọi số liệu trong bài viết này đều do nhà cung cấp báo cáo, từ sản phẩm của chúng tôi và từ kho lưu trữ OrcaReplay cùng tài liệu của nó: hành vi mã thoát của một lần chạy, bản ghi sửa lỗi 14 sự kiện với diff +1 -3 và kiểm tra mã thoát 1 của nó, việc gắn nhãn cạnh trong đồ thị orca, nhịp chụp nhanh mỗi lượt một lần, phát lại ngoại tuyến với mạng bị chặn, và bộ kiểm thử 1393 bài trên Node 20 và Node 22. Không có phép đo nào của bên thứ ba được trích dẫn ở bất kỳ đâu trong bài viết này. Bộ kiểm thử 1393 bài là nhận định duy nhất bạn có thể tự xác minh bằng cách sao chép kho lưu trữ và chạy nó. Tất cả các mục đã được kiểm tra lần cuối vào ngày 04-09-2026.