Khi các mô hình AI chuyển từ dự đoán sang hành động, các giả định giám sát truyền thống của MLOps bắt đầu sai lệch, khiến hệ thống báo xanh trong khi agent thất bại. Bài viết phân tích năm giả định chính bị phá vỡ và đề xuất khung quyết định để xây dựng chiến lược giám sát AgentOps hiệu quả, từ việc đo lường pass^k đến kiểm soát chi phí trajectory.

AgentOps Không Phải Là MLOps: Những Gì Sụp Đổ Trong Hệ Thống Giám Sát Khi Agent Vào Sản Xuất

Trong nhiều năm, giữ cho một mô hình hoạt động tốt trong sản xuất đồng nghĩa với việc giữ nó gần với phiên bản bạn đã triển khai. Bạn theo dõi độ lệch (drift) so với cửa sổ tham chiếu, đo độ trễ theo SLO, kiểm tra độ chính xác trên tập dữ liệu holdout. Một con số thay đổi, bạn huấn luyện lại.

Điều đó ngừng hoạt động hiệu quả khi các mô hình bắt đầu gọi công cụ. Phản ứng của ngành rất nhanh chóng — Gartner dự đoán hơn 40% dự án AI tác nhân sẽ bị hủy trước cuối năm 2027. Mọi nhà cung cấp quan sát đều trang bị tính năng truy vết agent. Nhưng điều chưa được xem xét kỹ là cách các đội ngũ thực sự thực hiện quá trình chuyển đổi này.

Hình ảnh minh họa về quá trình chuyển đổi giám sát

Năm Giả Định Bị Phá Vỡ

Quá trình chuyển đổi sang agent thường được thực hiện như một phép cộng: thêm các span mới lên trên ngăn xếp cũ, không gỡ bỏ gì cả. Các tín hiệu kế thừa vẫn kích hoạt, và một số giờ đây báo cáo "khỏe mạnh" cho các lần chạy thất bại. Có năm giả định chính của MLOps bị phá vỡ:

Đầu ra có thể so sánh giữa các lần chạy. Hệ thống giám sát truyền thống giả định rằng cùng một đầu vào sẽ cho ra đầu ra tương tự, nên sự khác biệt có ý nghĩa. Nhưng với agent, cùng một yêu cầu hỗ trợ có thể thành công vào thứ Hai và thất bại vào thứ Năm. Nghiên cứu Tau-bench đo lường điều này bằng chỉ số pass^k — xác suất tất cả k lần thử của một tác vụ đều thành công. Một lần thử gpt-4o đạt khoảng 61% tác vụ bán lẻ, nhưng chạy cùng tác vụ 8 lần, tỷ lệ cả 8 lần đều thành công giảm xuống dưới 25%.

Suy luận không trạng thái. Giả định này cho rằng mỗi yêu cầu là một đơn vị công việc độc lập. Nhưng agent là một vòng lặp — lỗi ở bước đầu tiên sẽ lan truyền và khuếch đại qua các bước tiếp theo. Anthropic ghi nhận trong hệ thống nghiên cứu đa agent của họ: "một bước thất bại có thể khiến các agent khám phá các quỹ đạo hoàn toàn khác nhau."

Một ranh giới quyết định. Một ngưỡng đơn giả định rằng có một nơi duy nhất để đặt ngưỡng. Nhưng một lần chạy 10 bước chỉ thành công nếu mọi bước đều thành công. Với tỷ lệ thành công mỗi bước là 85% — con số trông khỏe mạnh trên dashboard — xác suất cả 10 bước thành công chỉ còn khoảng 20%.

Biểu đồ minh họa sự khác biệt giữa giám sát từng bước và tổng thể

Ground truth đến sau hành động. Với mô hình dự đoán, một người có thể gán nhãn nhanh chóng. Nhưng khi đầu ra là một hành động (ghi vào CRM, gửi email), người đánh giá duy nhất là con người kiểm tra kết quả nhiều ngày sau — hoặc không bao giờ. Nghiên cứu MAST phát hiện "nhiều bộ kiểm tra hiện có chỉ thực hiện kiểm tra bề ngoài", như xác nhận mã biên dịch thay vì xác nhận tính đúng đắn.

Con người đứng giữa mô hình và hậu quả. Giả định này đắt nhất, vì agent không chỉ dự đoán mà còn hành động. Loại bỏ con người khỏi vòng lặp, trace trở thành bằng chứng duy nhất về tính đúng đắn. Nhưng trace có thể bị giả mạo — một tài liệu CrewAI mô tả các agent viết ra chuỗi hành động giả nhưng thuyết phục, mô tả kết quả công cụ mà không thực sự chạy chúng.

Thay Thế Bằng Cách Đo Lường Quỹ Đạo

Thay vì giữ nguyên các tín hiệu cũ, cần chuyển sang đo lường quỹ đạo (trajectory) của agent. Bảng dưới đây tóm tắt cách chuyển đổi:

Giả định cũ	Tín hiệu cũ	Những gì tín hiệu cũ không thấy	Thay thế bằng
Đầu ra so sánh được	Độ chính xác mỗi lần gọi	Sự không nhất quán giữa các lần chạy cùng đầu vào	pass^k qua nhiều lần thử
Suy luận không trạng thái	Độ trễ, tỷ lệ thành công cấp yêu cầu	Khiếm khuyết trong đường dẫn nhưng trả về sạch	Phát lại quỹ đạo với trạng thái từng bước
Một ranh giới quyết định	Tỷ lệ thành công mỗi bước	Lỗi cộng dồn trên toàn bộ đường dẫn	Tỷ lệ hoàn thành quỹ đạo
Ground truth đến	Drift so với cửa sổ tham chiếu	Thay đổi prompt làm thay đổi chính sách	Cấu hình agent được version hóa, diff mỗi lần chạy
Con người ở giữa	Cảnh báo ngưỡng đơn	Hành động không an toàn trong lần chạy điểm cao	Cổng chặn trước mọi side effect

Chi phí cho mỗi quỹ đạo thành công. Một lần chạy đốt 40 cuộc gọi công cụ và thất bại tốn kém hơn lần chạy 12 cuộc gọi và thành công. Dashboard tính theo cuộc gọi sẽ xếp hạng ngược lại vì chúng tính số cuộc gọi, không tính kết quả. Hệ thống đa agent đã sử dụng gấp 15 lần token so với tương tác chat.

Giới hạn cứng thay vì giới hạn đệ quy. Hầu hết framework cho phép agent thử lại tối đa 20 lần với giả định mỗi lần thử là tiến bộ. Nhưng agent có thể lặp vô hạn vào cùng một lỗi công cụ, đốt token mà không có tầm nhìn. Giải pháp là gắn cờ sau 3-5 lần thử giống hệt nhau, không phải chờ đến 20.

Cấu hình như bề mặt được giám sát. Trace hành vi ghi lại agent đã làm gì, không ghi lại việc ai đó sửa một dòng trong system prompt một giờ trước. Cần coi toàn bộ cấu hình (prompt, công cụ, mô hình, tham số) như một đơn vị diff, version hóa cùng nhau.

Khi Ngăn Xếp Cũ Vẫn Là Lựa Chọn Đúng

Không phải hệ thống LLM nào cũng là agent. Một lời gọi mô hình đơn lẻ, không công cụ, không bộ nhớ vẫn là dịch vụ chấm điểm không trạng thái — tất cả giả định trên vẫn đúng. LLMOps đủ để theo dõi một wrapper đơn giản.

Nhưng kể cả khi agent phức tạp, không phải lúc nào cũng cần hạ tầng mới. Marc Klingen, đồng sáng lập Langfuse, viết trên Hacker News: "Observability không cần phải được phát minh lại để có trace/metrics/logs chi tiết cho phần LLM của ứng dụng." Về mặt hạ tầng, ông đúng — transport, span model, lưu trữ đều là OpenTelemetry.

Hình ảnh minh họa khung quyết định

Khung Quyết Định: Hai Câu Hỏi Trước Khi Mua Trace Vendor

Hai câu hỏi quyết định hầu hết các trường hợp:

Hệ thống có quyết định mà không có con người giữa quyết định và hậu quả không? Nếu một người xem xét đầu ra trước khi mọi thứ xảy ra, phạm vi ảnh hưởng bị giới hạn và giám sát cấp đầu ra bao phủ hầu hết rủi ro.

Các quyết định có tạo ra side effect bên ngoài không? Ghi vào datastore, thanh toán, tin nhắn gửi đi, triển khai kích hoạt — side effect biến vấn đề chất lượng thành sự cố.

Nếu hệ thống nằm giữa hai nhánh, hãy chọn hướng thận trọng hơn. Hạ tầng quỹ đạo không cần chỉ tốn chi phí lưu trữ; giám sát cấp đầu ra không đủ tốn một sự cố mà khách hàng báo trước khi dashboard của bạn phát hiện.

Bắt Đầu Với Agent Có Quyền Ghi

Hãy áp dụng theo một hướng thay vì tất cả cùng lúc. Chọn một agent duy nhất có quyền ghi, đo lường toàn bộ quỹ đạo của nó, đặt giới hạn lặp cứng, và chặn side effect. Giữ các agent chỉ đọc trên ngăn xếp hiện tại cho đến khi agent đầu tiên trở nên nhàm chán.

Việc tracing là nửa rẻ của quá trình di cư này. Nửa đắt là quyết định tín hiệu kế thừa nào ngừng tin tưởng — và làm điều đó trước khi một agent thực hiện hành động mà dashboard xanh lè bảo bạn rằng mọi thứ đều ổn.