Bốn tác nhân AI tự hành hiện đã có thể phát hiện lỗi phần mềm, chỉnh sửa mã nguồn gây lỗi và xác nhận bản sửa lỗi—tất cả chỉ trong chưa đầy một phút, nhờ vào một quy trình làm việc dựa trên khả năng quan sát (observability) mới được xây dựng cho cuộc thi SigNoz hackathon.
Hệ thống này, được đặt tên là AgentOps, theo dõi SigNoz để tìm các đợt tăng vọt lỗi, thu thập các log và trace liên quan, xác định chính xác tệp và dòng mã gây lỗi, chỉnh sửa mã nguồn trong một môi trường sandbox, sau đó thực hiện lại yêu cầu để chứng minh lỗi đã được khắc phục. Mỗi chu kỳ đầy đủ hoàn tất trong 30-60 giây, và toàn bộ quá trình diễn ra mà không cần bất kỳ câu lệnh (prompt) nào từ con người.
Tại sao khả năng quan sát lại quan trọng đối với các tác nhân AI
Thực hành SRE truyền thống coi log, metric và các truy vết phân tán (distributed traces) là "đôi mắt" của một dịch vụ. Khi một yêu cầu thất bại, kỹ sư sẽ theo dõi trace để tìm đến thành phần gây lỗi. Nguyên tắc tương tự hiện đang vận hành AgentOps, nhưng "dịch vụ" đang được quan sát chính là bản thân tác nhân AI đó.
Mọi công cụ mà tác nhân gọi—cho dù là một lệnh gọi mô hình ngôn ngữ, chỉnh sửa hệ thống tệp hay trình chạy thử nghiệm (test runner)—đều tạo ra một span trong trace. Một span ghi lại thời gian bắt đầu, thời lượng và trạng thái thành công, nhờ đó tác nhân có thể thấy mỗi bước suy luận mất bao lâu và liệu nó có thành công hay không. Bằng cách kết nối các span đó lại với nhau, tác nhân xây dựng một bức tranh hoàn chỉnh về quá trình tư duy của chính mình, giống như cách con người thực hiện khi gỡ lỗi thủ công.
Sự chuyển dịch then chốt là từ "khả năng quan sát như một lớp báo cáo" sang "khả năng quan sát như một sự nhận thức". AgentOps đưa dữ liệu trace ngược lại cho các tác nhân, cho phép chúng suy luận về các hành động của chính mình trong thời gian thực. Kết quả là một vòng lặp nơi AI không chỉ đưa ra giả thuyết mà còn xác thực giả thuyết đó dựa trên chính dữ liệu telemetry mà nó dùng để phát hiện vấn đề.
Quy trình làm việc bốn bước
- Giám sát (Monitor) – Một trình theo dõi nhẹ nhàng quét SigNoz để tìm các lỗi mới được báo cáo.
- Chẩn đoán (Diagnose) – Tác nhân thu thập các log và trace liên quan, trích xuất stack, và cô lập tệp nguồn cùng số dòng đã gây ra lỗi.
- Sửa lỗi (Fix) – Sử dụng một máy chủ hệ thống tệp trong môi trường sandbox, tác nhân viết một bản vá cho dòng mã đã xác định. Sandbox thực thi các quyền nghiêm ngặt và tự động hoàn tác nếu việc chỉnh sửa vi phạm chính sách.
- Xác minh (Verify) – Tác nhân thực hiện lại yêu cầu ban đầu đối với mã đã được vá. Nếu trace cho thấy quá trình chạy trơn tru, bản sửa lỗi sẽ được commit; nếu không, tác nhân sẽ lặp lại quy trình.
Tất cả các bước đều được điều phối bởi cùng một nhóm tác nhân, mỗi tác nhân đóng vai trò như một micro-service tự hành. Toàn bộ chuỗi này có thể quan sát được thông qua các span tương thích với OpenTelemetry, mà SigNoz tiếp nhận và trực quan hóa.
Những bài học xương máu về độ tin cậy
Sự rõ ràng của lỗi
Một trạng thái "thất bại" chung chung sẽ không cung cấp thông tin gì. Nhóm đã thêm các lý do thất bại chi tiết—ví dụ: "giả thuyết sai" hoặc "bản vá làm hỏng quy trình"—để các tác nhân ở các bước sau có thể quyết định xem nên thử lại, quay lại bước trước hoặc hủy bỏ. Điều này mô phỏng cách con người dán nhãn các nguyên nhân gốc rễ trong các báo cáo sau sự cố (post-mortems).
Độ trễ dữ liệu
Dữ liệu telemetry không xuất hiện ngay lập tức. Các tác nhân hiện bao gồm một khoảng dừng ngắn và một bước kiểm tra tính hợp lý (sanity check) để đảm bảo các log cần thiết đã được gửi đến trước khi chúng khẳng định một bản sửa lỗi. Nếu không có chốt chặn này, một tác nhân có thể hành động dựa trên dữ liệu không đầy đủ và đưa ra kết quả dương tính giả.
Ranh giới bảo mật
Cho phép AI viết mã là một rủi ro leo thang đặc quyền. Sandbox chạy đằng sau một máy chủ hệ thống tệp chuyên dụng nhằm giới hạn phạm vi ghi trong kho lưu trữ (repository) mục tiêu và tự động khôi phục trạng thái trước đó nếu bài kiểm tra thất bại. Mô hình cô lập này giúp kiểm soát quyền năng của AI.
Giới hạn token
Các mô hình ngôn ngữ lớn tiêu thụ token API, và hạn mức hàng ngày có thể bị cạn kiệt ngay giữa quá trình điều tra. AgentOps theo dõi việc sử dụng token cho mỗi sự cố và giới hạn (throttle) các lệnh gọi tiếp theo khi đạt đến một ngưỡng nhất định, ngăn chặn tình trạng hàng loạt bản sửa lỗi thất bại khi hết hạn mức.
Những gì bản demo đã chứng minh
Nhóm đã đưa vào một lỗi hoàn toàn mới chưa từng xuất hiện trong mã nguồn. AgentOps đã phát hiện sự bất thường, truy vết đến chính xác dòng mã, tạo ra một bản chỉnh sửa khắc phục, áp dụng bản vá trong sandbox và xác minh yêu cầu đã thành công—tất cả đều không cần bất kỳ thay đổi mã thủ công hay câu lệnh mới nào. Thời gian thực hiện từ đầu đến cuối vẫn dưới một phút, khớp với thời lượng 30-60 giây đã báo cáo.
Quan điểm ngược lại: tự hành không phải là "chiếc đũa thần"
Những điều cần theo dõi tiếp theo
- Telemetry không phụ thuộc mô hình – Khi ngày càng có nhiều nhà cung cấp cung cấp các span tương thích với OpenTelemetry, phương pháp này có thể trở nên trung lập với nhà cung cấp, giúp việc áp dụng trên các ngăn xếp (stack) không đồng nhất trở nên dễ dàng hơn.
- Rào chắn dựa trên chính sách – Việc nhúng các chính sách có thể cấu hình để quy định những tệp nào một agent có thể chỉnh sửa, hoặc những bộ kiểm thử (test suite) nào phải vượt qua trước khi commit, sẽ giải quyết được các lo ngại về quản trị.
- Lập ngân sách token có tính đến chi phí – Việc phân bổ token linh hoạt dựa trên mức độ nghiêm trọng của sự cố có thể ngăn chặn tình trạng cạn kiệt hạn mức (quota) trong khi vẫn duy trì khả năng xử lý các lỗi có tác động lớn.
AgentOps cho thấy chu kỳ sửa lỗi có thể mất từ 30-60 giây. Thí nghiệm này chứng minh một mô hình thử nghiệm (proof-of-concept) rằng khả năng quan sát (observability) có thể được sử dụng bởi các trợ lý phần mềm tự hành.