Agent báo “xong” nhưng việc chưa xong: Giám sát kết quả AI Agent 2026

Tóm tắt cốt lõi: AI Agent chạy hết workflow không đồng nghĩa với hoàn thành đúng công việc; doanh nghiệp cần kiểm chứng trạng thái nghiệp vụ độc lập với lời tự báo của mô hình. Kiến trúc thực dụng gồm ba tầng: sức khỏe dịch vụ, trace từng bước và đối soát kết quả. Với SME, ưu tiên hợp đồng đầu ra, cảnh báo có người chịu trách nhiệm và khả năng phục hồi an toàn trước khi tăng mức tự chủ.

Một agent nhận nhiệm vụ cập nhật khách hàng vào CRM. Dashboard xanh, API trả HTTP 200, workflow kết thúc với trạng thái success. Nhưng một phần hồ sơ không xuất hiện trong CRM vì agent đọc thiếu trang dữ liệu hoặc hiểu nhầm phản hồi của công cụ. Không có exception. Không ai nhận thông báo.

Đây là khoảng cách giữa completed và correct: chương trình đã dừng, nhưng mục tiêu chưa đạt. Trong vận hành, khoảng cách này nguy hiểm hơn một lỗi làm hệ thống ngừng hẳn, bởi nó tiếp tục tạo dữ liệu thiếu, báo cáo sai và quyết định sai.

Ở góc nhìn kiến trúc của Cường Nguyễn tại AI Ops Solutions, câu hỏi cần đặt không phải “agent có chạy không?”, mà là: bằng chứng nào chứng minh công việc đã hoàn tất, và ai sửa nếu bằng chứng không khớp?

Giám sát kết quả AI Agent là gì, khác gì theo dõi uptime?

Trả lời nhanh: Giám sát kết quả AI Agent là kiểm tra trạng thái nghiệp vụ sau khi agent hành động, thay vì chỉ đọc trạng thái chạy. Một triển khai tối thiểu cần ba tầng: sức khỏe dịch vụ, trace từng bước và đối soát đầu vào với đầu ra. Chỉ đánh dấu hoàn tất khi tiêu chí nghiệp vụ đã được xác nhận.

Uptime trả lời hệ thống có sẵn sàng phục vụ hay không. Trace giải thích hệ thống đã làm gì. Outcome observability kiểm tra những hành động đó có tạo ra kết quả được yêu cầu hay không. Ba lớp bổ sung cho nhau, không thay thế nhau.

Ví dụ, một phản hồi API hợp lệ chỉ chứng minh yêu cầu được xử lý theo giao thức. Nó không chứng minh agent chọn đúng khách hàng, đọc đủ dữ liệu, điền đúng trường hay hoàn thành giao dịch ở hệ thống đích.

• Thành công kỹ thuật: Không timeout, không exception, lời gọi công cụ kết thúc.
• Thành công dữ liệu: Đủ bản ghi, đúng schema, đúng khóa và đúng phiên bản.
• Thành công nghiệp vụ: Trạng thái đích đáp ứng yêu cầu thực tế, chẳng hạn đơn hàng được xác nhận chứ không chỉ được tạo nháp.

Không nên giao cả ba phán quyết cho một mô hình. Agent tạo câu trả lời rồi tự xác nhận câu trả lời đó đúng dễ lặp lại cùng một giả định sai. Những điều kiểm tra được bằng truy vấn, schema hoặc quy tắc xác định nên được kiểm tra bên ngoài agent.

Một câu “đã hoàn thành” là lời khai. Một bản ghi được đối soát với hệ thống đích mới là bằng chứng vận hành.

Toán học độ tin cậy: vì sao 99% mỗi bước vẫn chưa đủ?

Giả sử workflow có n bước bắt buộc, mỗi bước thành công với xác suất p, các bước độc lập và chưa tính cơ chế sửa lỗi. Khi đó, xác suất toàn bộ chuỗi thành công là P = pⁿ. Đây là mô hình minh họa, không phải công thức dự báo chính xác cho mọi agent production.

Với 10 bước ở mức 99%, khoảng 9,6% lần chạy không thành công trọn vẹn trong mô hình này. Không thể lấy độ chính xác của một lời gọi rồi gán cho cả quy trình.

Thực tế còn phức tạp hơn: cùng một nguồn dữ liệu lỗi có thể làm nhiều bước cùng sai. Ngược lại, một nhánh kiểm tra và sửa lỗi tốt có thể cứu workflow. Vì vậy, phải đo cả tỷ lệ đúng lần đầu lẫn tỷ lệ hoàn tất sau phục hồi.

Hàm ý kiến trúc không phải “cấm workflow dài”, mà là giảm những quyết định xác suất nối tiếp không cần thiết. Phân trang, tính tổng, kiểm tra khóa và ghi database nên dùng logic xác định. Dành mô hình cho phần thực sự cần hiểu ngôn ngữ hoặc xử lý mơ hồ.

Với multi-agent, mỗi lần bàn giao còn thêm nguy cơ mất ngữ cảnh và lệch hợp đồng đầu ra. Bài khi nào cần multi-agent và cách điều phối có kiểm soát giúp xác định lúc nào phân vai tạo giá trị, thay vì chỉ kéo dài chuỗi lỗi.

Bốn nguồn gốc của lỗi im lặng trong production

Công cụ trả kết quả hợp lệ nhưng không đầy đủ

API có thể trả trang đầu tiên, một tập con được phép xem hoặc kết quả chưa đồng bộ. Agent nhìn thấy danh sách hợp lệ và tiếp tục. Nếu không có kiểm tra pagination, watermark và số lượng kỳ vọng, dữ liệu thiếu trở thành đầu vào “đúng” của bước sau.

Chỉ kiểm tra status code là chưa đủ. Cần phân biệt phản hồi transport thành công với phản hồi nghiệp vụ thành công, bao gồm các trường lỗi nằm trong body.

Context cũ hoặc thiếu

Agent có thể trả lời hợp lý từ bảng giá cũ, chính sách hết hiệu lực hoặc dữ liệu retrieval thiếu tài liệu bắt buộc. Vì câu trả lời trôi chảy, lỗi không tạo dấu hiệu kỹ thuật rõ ràng. Log phải ghi được phiên bản nguồn, thời điểm cập nhật và bộ lọc truy xuất, không chỉ prompt cuối.

Bàn giao giữa các agent bị lệch nghĩa

Agent đầu đánh dấu “đã xác minh” theo nghĩa kiểm tra định dạng; agent sau hiểu thành đã xác minh danh tính khách hàng. Trường dữ liệu giống nhau nhưng ngữ nghĩa khác nhau.

Nghiên cứu MAST về phân loại lỗi hệ thống đa agent mô tả các nhóm vấn đề liên quan đến thiết kế, phối hợp giữa agent và kiểm tra hoàn thành. Giá trị thực dụng là dùng taxonomy để phân loại sự cố, không suy diễn thành tỷ lệ lỗi mặc định cho doanh nghiệp.

Agent tự tuyên bố hoàn tất quá sớm

False success xuất hiện khi agent kết luận từ ý định hoặc từ hành động vừa gọi, thay vì xác minh trạng thái cuối. “Đã gửi yêu cầu tạo hóa đơn” không đồng nghĩa “hóa đơn đã được phát hành”. Với tác vụ bất đồng bộ, phải kiểm tra trạng thái cuối hoặc nhận sự kiện xác nhận đáng tin cậy.

Kiến trúc ba tầng: từ hạ tầng đến bằng chứng nghiệp vụ

Tầng 1: Sức khỏe dịch vụ

Theo dõi availability, timeout, lỗi API, rate limit, queue depth và độ trễ. Đây là nơi phát hiện sự cố diện rộng, xác định nguồn nghẽn và bảo vệ ngân sách. Tuy nhiên, hệ thống hoàn toàn khỏe vẫn có thể xử lý sai khách hàng.

Tầng 2: Trace theo từng lần chạy

Mỗi tác vụ cần một run_id xuyên suốt orchestrator, công cụ và bộ kiểm tra kết quả. Với n8n, giữ execution ID để điều tra, đồng thời dùng mã nghiệp vụ ổn định để nối nhiều execution thuộc cùng một vụ việc.

• Danh tính tác vụ: run_id, business_key, workflow_version, thời điểm nhận và hạn xử lý.
• Ngữ cảnh thực thi: model_version, prompt_version, tool_version và nguồn dữ liệu.
• Dấu vết từng bước: parent_span, thời gian, số lần thử, mã lỗi và số bản ghi đọc/ghi.
• Kết quả kiểm chứng: expected_count, actual_count, rejected_count, outcome_status và mã lý do.
• Khả năng phục hồi: checkpoint, input snapshot tham chiếu và replay_of_run_id.

OpenTelemetry GenAI semantic conventions là điểm tham chiếu để chuẩn hóa telemetry. Cần kiểm tra trạng thái ổn định của từng convention ở phiên bản đang dùng, khóa phiên bản instrumentation và tránh phụ thuộc cứng vào tên trường có thể thay đổi.

Không đồng nghĩa với việc ghi toàn bộ prompt hoặc hồ sơ khách hàng. Ưu tiên metadata, mã tham chiếu, hash và snapshot được kiểm soát truy cập. Trace cũng là dữ liệu cần bảo vệ.

Tầng 3: Bộ kiểm tra outcome độc lập

Đặt một validator sau bước ghi và, nếu cần, một bộ đối soát chạy theo lịch. Validator đọc lại hệ thống đích, không chỉ đọc nội dung agent báo cáo.

Với quy trình CRM giả định nhận 200 hồ sơ, hợp đồng có thể là: 188 hợp lệ + 12 bị loại có lý do = 200 đầu vào; cả 188 hồ sơ phải có định danh ở CRM. Đây là số minh họa, nhưng nguyên tắc bảo toàn đầu vào có thể triển khai ngay.

Dùng ít nhất bốn trạng thái: pending, verified, failed, unknown. Nếu chưa truy vấn được hệ thống đích, trạng thái phải là unknown, không tự nâng thành thành công.

Phát hiện agent báo thành công nhưng làm sai bằng cách nào?

Trả lời nhanh: Bắt đầu bằng đối soát số lượng, khóa nghiệp vụ và trạng thái ở hệ thống đích. Theo dõi tám tín hiệu: thiếu đầu ra, đầu ra rỗng, retry bị che, dữ liệu downstream giảm, độ trễ tăng, bước chạy hoặc chi phí bất thường, người dùng sửa nhiều và chất lượng trôi. Mỗi cảnh báo phải có owner.

Watchlist Completed-vs-Correct dưới đây phù hợp với SME vì tận dụng dữ liệu execution sẵn có. Các ngưỡng phải lấy từ baseline của workflow, không sao chép giữa mọi doanh nghiệp.

• 1. Input-output gap: Có đầu vào nhưng không có kết quả hoặc lý do loại bỏ. Với quy trình cần bảo toàn dữ liệu, mọi khoảng trống chưa giải thích đều phải được điều tra.
• 2. Output rỗng bất thường: Agent trả danh sách rỗng dù đầu vào có dữ liệu hợp lệ. Phân biệt “không có kết quả” với “không đọc được dữ liệu”.
• 3. Retry che lỗi: Run cuối cùng xanh nhưng một công cụ liên tục thử lại. Theo dõi cả retry count và việc mỗi lần thử có tạo side effect hay không.
• 4. Downstream hụt dữ liệu: Kho dữ liệu hoặc CRM nhận ít bản ghi hơn nguồn sau khi đã tính độ trễ đồng bộ và các trường hợp loại hợp lệ.
• 5. Độ trễ tăng: P95 kéo dài có thể báo hiệu agent đi vòng hoặc chờ dependency. Độ trễ không chứng minh lỗi, nhưng là tín hiệu để khoanh vùng.
• 6. Bước chạy hoặc chi phí đổi đột ngột: Tăng có thể là vòng lặp; giảm có thể là bỏ bước. So sánh trong cùng nhóm tác vụ và độ phức tạp.
• 7. Tỷ lệ người sửa tăng: Đo số kết quả bị sửa đáng kể trên số kết quả đã review, kèm tỷ lệ lấy mẫu để tránh đọc sai mẫu số.
• 8. Quality drift: Sau đổi model, prompt hoặc retrieval, chạy lại bộ test cố định và kiểm tra mẫu production theo nhóm rủi ro.

Cảnh báo phải kèm run_id, sai lệch kỳ vọng–thực tế, mức ảnh hưởng, owner và hành động đầu tiên. Với hóa đơn hoặc thanh toán, ưu tiên dừng ghi tiếp. Với gợi ý nội dung, chuyển sang review có thể hợp lý hơn đánh thức người trực.

Triage theo năm lớp: đừng đổi model khi tool đang lỗi

Khi outcome sai, cách nhanh nhất thường là kiểm tra từ lớp cụ thể nhất, thay vì yêu cầu một LLM khác đọc cả trace rồi đoán nguyên nhân.

• Infrastructure: Queue tồn đọng, timeout, thiếu tài nguyên hoặc lỗi kết nối?
• Tool: Sai tham số, thiếu phân trang, phản hồi nghiệp vụ thất bại hoặc quyền truy cập làm thiếu dữ liệu?
• Retrieval: Sai tài liệu, sai phiên bản, thiếu nguồn hay bộ lọc quá chặt?
• Planning: Bỏ bước, sai thứ tự, dừng sớm hoặc lặp lại hành động?
• Output: Sai schema, thiếu trường hoặc nội dung không đáp ứng tiêu chí?

Ví dụ, agent đặt chuyến bay nhận “không còn chỗ”. Đây có thể là kết quả nghiệp vụ hợp lệ, không phải lỗi model. Nhưng nếu adapter chuyển lỗi timeout thành danh sách trống, agent đang đưa ra kết luận sai từ phản hồi bị biến dạng.

Tạo fingerprint xác định: tool_name, mã lỗi, schema_version, trạng thái pagination và outcome_reason. Sau đó nhóm các run cùng dấu vết. LLM có thể hỗ trợ tóm tắt, nhưng không nên là trọng tài duy nhất xác định bước gây lỗi.

Với bản sửa, một bộ 5 ca tái hiện chạy đúng 5/5 chỉ là cổng kiểm tra tối thiểu được đề xuất, không chứng minh độ tin cậy production. Tiếp tục chạy regression, trường hợp biên và canary; kiểm tra cả dữ liệu cuối lẫn nguy cơ ghi trùng.

Khi agent làm thiếu hoặc ghi sai, nên Backfill, Replay hay Rollback?

Trả lời nhanh: Dùng Backfill khi thiếu dữ liệu nguồn, Replay khi cần chạy lại xử lý từ đầu vào đã lưu, và Rollback khi phải hoàn tác thay đổi sai. Trước mọi lần phục hồi, xác định phạm vi ảnh hưởng, kiểm tra side effect và áp dụng idempotency key. Không tự động gửi lại email hoặc thanh toán.

Backfill: lấy lại phần dữ liệu bị bỏ sót

Chọn khi ingestion mất một khoảng thời gian, thiếu trang hoặc bỏ lỡ sự kiện. Chốt phạm vi bằng watermark, ID hoặc timestamp; đọc bổ sung từ nguồn; đối soát trước khi kích hoạt workflow phụ thuộc. Nếu nguồn đã đổi, lưu rõ dữ liệu được phục hồi là phiên bản nào.

Replay: chạy lại với đầu vào đã biết

Replay cần snapshot hoặc tham chiếu đầu vào có thể tái lập, cấu hình và phiên bản workflow. Chạy lại bằng model mới không phải tái hiện nguyên trạng; đó là một lần xử lý mới và phải được ghi nhận như vậy.

Tách compute khỏi commit: tính toán lại trong vùng staging, so sánh chênh lệch, rồi mới ghi ra hệ thống thật. Không phát lại toàn bộ side effect chỉ vì muốn tái tạo lỗi phân loại.

Rollback: hoàn tác hoặc bù trừ thay đổi

Rollback phù hợp khi có lịch sử phiên bản hoặc giao dịch có thể đảo ngược. Với nhiều SaaS, cần compensating action thay vì rollback database. Email đã gửi không thể thu hồi như một dòng dữ liệu; thanh toán có thể cần hoàn tiền và quy trình thông báo.

Idempotency key nên biểu diễn một hành động nghiệp vụ, chẳng hạn tenant + order_id + action_type + business_version. Không dùng execution ID mới làm khóa duy nhất cho cùng một hành động retry. Khi API đích hỗ trợ, dùng cơ chế idempotency chính thức; nếu không, cần operation ledger và ràng buộc duy nhất.

Timeout sau khi gửi yêu cầu là trạng thái mơ hồ: thao tác có thể đã được thực hiện. Hãy tra trạng thái trước khi gửi lại. Cũng phải kiểm tra thời hạn lưu khóa của nhà cung cấp; idempotency không mặc nhiên tồn tại vĩnh viễn.

Phục hồi tốt không chỉ đưa dữ liệu về đúng. Nó phải tránh tạo thêm sai sót và không che giấu những tác động khách hàng đã nhìn thấy.

Chi phí cho SME: đo kết quả đúng trước khi chọn API hay tự host

Cost per verified outcome bằng tổng chi phí phục vụ chia số kết quả đã được xác minh đúng trong cùng kỳ. Tử số gồm inference, công cụ, hạ tầng, quan sát, review và phục hồi; mẫu số không phải số lần agent báo success.

Ví dụ giả định: chi 3 triệu đồng cho 1.000 tác vụ, trong đó 800 kết quả được xác minh đạt yêu cầu. Chi phí là 3.750 đồng/kết quả đúng, không phải 3.000 đồng. Nếu review và sửa lỗi tốn thêm 2 triệu đồng, con số thành 6.250 đồng.

API thường thuận lợi khi tải biến động, đội vận hành nhỏ và cần thay model nhanh. Self-host đáng cân nhắc khi tải ổn định, yêu cầu dữ liệu rõ ràng và có năng lực vận hành. Không so giá GPU thô với giá endpoint đã bao gồm phục vụ rồi kết luận phương án thắng.

RAM đủ nạp trọng số cũng chưa chứng minh hệ thống phục vụ tốt: còn quantization, context, KV cache, concurrency và latency. Trước quyết định mua hạ tầng, chạy cùng một bộ workload, cùng tiêu chí chất lượng và cùng cách tính chi phí con người.

Giảm giá token không sửa được pagination sai hoặc replay gây ghi trùng. Với SME, sửa những lỗi này thường đáng ưu tiên hơn tối ưu vài phần trăm chi phí inference.

Lộ trình 30 ngày: từ dashboard xanh đến kết quả có bằng chứng

Tuần 1: kiểm kê và chốt hợp đồng kết quả

Chọn một workflow có giá trị và dữ liệu đối soát được. Ghi rõ đầu vào, đầu ra, tiêu chí loại bỏ, thời hạn và side effect. Gán business owner định nghĩa “đúng”, cùng technical owner chịu trách nhiệm phát hiện và phục hồi.

Tuần 2: nối trace với dữ liệu nghiệp vụ

Truyền run_id, thêm outcome_status và truy vấn xác minh ở hệ thống đích. Với n8n, không chỉ dựa vào Error Trigger: workflow không ném lỗi vẫn cần nhánh kiểm tra đầu ra. Lưu dữ liệu kiểm chứng ở nơi có retention phù hợp.

Tuần 3: bật watchlist và kiểm tra bản phát hành

Ưu tiên ba tín hiệu: input-output gap, output rỗng và retry bất thường. Chạy cảnh báo ở chế độ quan sát để đo nhiễu; đặt ngưỡng theo baseline. Mỗi thay đổi model hoặc prompt phải đi qua regression và canary.

Tuần 4: diễn tập phục hồi

Chủ động tạo ca thiếu dữ liệu, timeout sau ghi và đầu ra sai schema. Đo thời gian phát hiện, thời gian khoanh vùng và thời gian phục hồi; kiểm tra rằng replay không gửi lại thông báo hoặc tạo giao dịch trùng.

Nếu chưa biết chọn tác vụ đầu tiên, tham khảo các workflow agent có kiểm soát và đo được chất lượng. Ưu tiên quy trình có tiêu chí hoàn tất rõ trước tác vụ mở khó đánh giá.

Về tuân thủ, lưu ý log có thể chứa dữ liệu cá nhân và cần chính sách truy cập, lưu trữ, xóa dữ liệu. Không coi thông tin về việc hoãn nghĩa vụ pháp lý là lý do ngừng xây khả năng truy vết; mọi mốc pháp lý EU cần đối chiếu văn bản chính thức và phạm vi áp dụng trước khi sử dụng.

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

Có thể dùng một LLM khác để xác nhận agent đã làm đúng không?

Có, nhưng chỉ như một lớp đánh giá bổ sung, đặc biệt với tiêu chí ngữ nghĩa. Với số lượng, số tiền, trạng thái giao dịch hoặc sự tồn tại của bản ghi, hãy dùng truy vấn và quy tắc xác định. Hai mô hình vẫn có thể đồng ý với cùng một giả định sai. LLM judge cũng cần bộ kiểm thử, theo dõi phiên bản và cơ chế chuyển người review khi thiếu bằng chứng.

MAST có giúp tự động tìm chính xác bước gây lỗi không?

MAST hữu ích để chuẩn hóa cách phân loại lỗi đa agent, không phải bảo đảm tự động tìm đúng nguyên nhân. Muốn xác định bước gây lỗi, vẫn cần trace, hợp đồng đầu ra từng bước và khả năng tái hiện. Đặc biệt phải phân biệt bước đầu tiên tạo dữ liệu sai với bước cuối cùng phát hiện hậu quả; hai vị trí này thường khác nhau.

SME ít dữ liệu có cần xây hệ thống observability lớn không?

Không. Có thể bắt đầu bằng bảng run trong database, execution log, truy vấn đối soát theo lịch và kênh cảnh báo có owner. Điều kiện tối thiểu là nối được tác vụ với đầu ra, biết tại sao một bản ghi bị loại và phục hồi không ghi trùng. Mua nền tảng lớn trước khi định nghĩa “kết quả đúng” thường chỉ tạo thêm dashboard.

Làm sao đo tỷ lệ false success mà không đọc thủ công mọi kết quả?

Định nghĩa tỷ lệ là số run agent báo hoàn thành nhưng bị xác minh không đạt, chia cho số run báo hoàn thành đã được kiểm tra. Tự động kiểm tra toàn bộ tiêu chí xác định; lấy mẫu phân tầng cho chất lượng ngữ nghĩa, ưu tiên nhóm rủi ro cao. Công bố cả độ phủ kiểm tra và cách lấy mẫu, vì tỷ lệ đo trên một nhóm nhỏ không tự đại diện cho toàn bộ production.

Khi nào nên dừng agent thay vì tiếp tục retry?

Dừng khi không xác định được side effect đã xảy ra chưa, vượt ngân sách thử lại, dữ liệu nguồn không đáng tin hoặc hành động tiếp theo có rủi ro khó đảo ngược. Chuyển sang trạng thái cần xử lý, lưu checkpoint và giao owner quyết định. Retry chỉ phù hợp với lỗi có khả năng tạm thời và hành động đủ an toàn khi thực hiện lại.

Kết luận: Đừng tăng quyền tự chủ khi chưa đo được kết quả. Một agent đáng tin cần biết khi nào chưa đủ bằng chứng để nói “xong”; một hệ thống đáng tin cần phát hiện được điều đó ngay cả khi agent không biết.

Tác giả: Cường Nguyễn — Founder AI Ops Solutions | Verified n8n Creator. Kết nối: Facebook · LinkedIn · YouTube · TikTok