Agent Observability: Làm sao biết AI Agent đã làm gì, sai ở đâu và tốn bao nhiêu?

Một AI Agent có thể đọc email, tra cứu CRM, gọi API, tạo báo giá và gửi đề xuất chỉ trong vài phút. Khi kết quả sai, câu hỏi khó nhất không phải là mô hình đã trả lời gì, mà là hệ thống đã dùng dữ liệu nào, gọi công cụ nào, ai cấp quyền và chi phí phát sinh ở bước nào.

Agent Observability có thể hiểu là khả năng quan sát toàn bộ quá trình làm việc của AI Agent. Hệ thống ghi lại đường đi của nhiệm vụ, đầu vào và đầu ra quan trọng, công cụ đã gọi, lỗi xảy ra, thời gian xử lý, chi phí và các lần con người phê duyệt.

Khả năng này khác với việc chỉ lưu đoạn trò chuyện cuối cùng. Một câu trả lời tưởng đúng có thể được tạo từ tài liệu hết hiệu lực; một nhiệm vụ thất bại có thể do API hết thời gian chờ chứ không phải do mô hình suy luận kém. Nếu không nhìn được từng chặng, đội vận hành dễ sửa sai chỗ.

Ví dụ, Agent hỗ trợ bán hàng tạo báo giá cao hơn mức được phép. Nhật ký đầy đủ phải cho biết Agent đã đọc bảng giá phiên bản nào, có áp dụng sai chiết khấu hay không, công cụ nào đã ghi dữ liệu vào CRM và bước gửi email đã được người có thẩm quyền duyệt chưa.

Ba nhóm tín hiệu cần theo dõi gồm chất lượng kết quả, hành vi của quy trình và nguồn lực tiêu thụ. Doanh nghiệp phải biết câu trả lời có đúng không, Agent có đi đúng luồng và đúng quyền không, đồng thời mỗi nhiệm vụ mất bao lâu và tiêu tốn bao nhiêu.

AI có thể hỗ trợ phát hiện vòng lặp, gom sự cố tương tự, tóm tắt nguyên nhân và đề xuất bước khắc phục. Tuy nhiên, AI không nên tự xóa log, tự thay đổi chính sách quyền hoặc kết luận trách nhiệm của nhân viên chỉ từ một dấu vết kỹ thuật.

Quan sát cũng phải đi cùng bảo mật. Log có thể chứa dữ liệu khách hàng, nội dung hợp đồng hoặc khóa truy cập, nên cần che thông tin nhạy cảm, phân quyền người xem và có thời hạn lưu phù hợp thay vì ghi lại mọi thứ vô điều kiện.

Một Agent đáng tin cậy không phải là Agent chưa từng lỗi. Đó là hệ thống có thể phát hiện lỗi sớm, giải thích được tác động, khôi phục có kiểm soát và cung cấp đủ bằng chứng để con người chịu trách nhiệm cho quyết định cuối cùng.

MỤC LỤC

PHẦN I — HIỂU ĐÚNG NỀN TẢNG

1. 1. Agent Observability thực chất là gì
2. 2. Doanh nghiệp cần quan sát những lớp nào
3. 3. Observability khác logging và monitoring như thế nào
4. 4. AI có thể giúp ở đâu và không nên làm gì
5. 5. Con người có bị thay thế không

PHẦN II — NHỮNG ỨNG DỤNG THỰC TẾ

6. 6. Theo dõi đường đi của một nhiệm vụ
7. 7. Phát hiện vòng lặp công cụ
8. 8. Đo token và chi phí theo nhiệm vụ
9. 9. Tách lỗi mô hình và lỗi công cụ
10. 10. Kiểm tra nguồn được truy xuất
11. 11. Theo dõi Human Approval
12. 12. Phát hiện chất lượng suy giảm theo phiên bản
13. 13. Cảnh báo hành động vượt quyền
14. 14. Theo dõi độ trễ từng chặng
15. 15. Nhóm sự cố theo nguyên nhân
16. 16. Đánh giá an toàn và chất lượng
17. 17. Điều tra sự cố end-to-end

PHẦN III — AI AGENT, DỮ LIỆU VÀ KIỂM SOÁT

18. AI Assistant và AI Agent khác nhau thế nào
19. Dữ liệu nào cần được đưa vào ngữ cảnh
20. Vai trò của ERP, CRM, Data Warehouse và Data Platform
21. Data Quality, quyền truy cập và bảo mật
22. Đánh giá chất lượng ngữ cảnh trước khi vận hành

PHẦN IV — TRIỂN KHAI TRONG DOANH NGHIỆP

23. Bắt đầu từ một quyết định có giá trị
24. Ba use case đầu tiên ít rủi ro
25. Roadmap triển khai 90 ngày
26. KPI cần đo
27. Những sai lầm phổ biến
28. Điều kiện để mở rộng

PHẦN V — TÌNH HUỐNG TỔNG THỂ VÀ TƯƠNG LAI

29. Tình huống doanh nghiệp tổng thể
30. Trước và sau khi triển khai
31. Công việc sẽ thay đổi ra sao
32. Kết luận

PHẦN I — HIỂU ĐÚNG NỀN TẢNG

1. Agent Observability thực chất là gì?

Agent Observability, có thể hiểu là khả năng quan sát AI Agent, là hệ thống dấu vết giúp theo dõi một nhiệm vụ từ lúc nhận yêu cầu đến khi kết thúc. Dấu vết gồm lệnh gọi mô hình, dữ liệu truy xuất, công cụ được dùng, kết quả từng bước, thời gian chờ, token, chi phí, lỗi và quyết định chuyển cho con người.

Hãy coi mỗi nhiệm vụ là một hồ sơ vận hành. Hồ sơ phải trả lời ai yêu cầu, Agent phiên bản nào chạy, dữ liệu nào được xem, công cụ nào được gọi, kết quả trung gian ra sao, ai duyệt và tổng chi phí bao nhiêu. Khi thiếu một mắt xích, việc điều tra dễ chuyển thành phỏng đoán.

2. Doanh nghiệp cần quan sát những lớp nào?

Doanh nghiệp phải gắn một trace ID, tức mã theo dõi xuyên suốt, cho mỗi nhiệm vụ. Mỗi bước tạo span, tức đoạn thực thi, chứa thời gian, trạng thái và metadata cần thiết. Metric tổng hợp cho biết tỷ lệ thành công, độ trễ và chi phí; log giữ chi tiết; eval chấm chất lượng đầu ra.

Yêu cầu đi qua cổng nhận diện người dùng, bộ điều phối, mô hình, lớp truy xuất và công cụ nghiệp vụ. Dấu vết phải nối được các phần này mà không ghi lộ dữ liệu nhạy cảm. Khi lỗi, đội vận hành đi từ trace tổng thể xuống đúng span gây vấn đề.

3. Observability khác logging và monitoring như thế nào?

Logging ghi sự kiện chi tiết; monitoring theo dõi một số chỉ số và cảnh báo; observability cho phép suy ra nguyên nhân từ nhiều tín hiệu khi xảy ra tình huống chưa dự đoán trước. Với Agent, còn cần đánh giá chất lượng vì một nhiệm vụ có thể hoàn tất kỹ thuật nhưng đưa khuyến nghị sai.

Nhóm nhỏ có thể bắt đầu bằng trace cho lời gọi mô hình và công cụ, dashboard latency–token–error, cùng bộ eval định kỳ. Khi Agent có quyền ghi, cần thêm nhật ký phê duyệt, thay đổi trạng thái và khả năng phát lại ở môi trường an toàn.

4. AI có thể giúp ở đâu và không nên làm gì?

AI có thể đọc hàng nghìn trace để tìm mẫu: vòng lặp gọi công cụ, prompt phình to, nguồn hay gây lỗi, hoặc một phiên bản mô hình làm tăng từ chối. Nó cũng có thể tạo bản tóm tắt sự cố kèm liên kết tới bằng chứng.

AI không nên tự xóa trace, sửa lịch sử hay kết luận nguyên nhân nếu dữ liệu quan sát thiếu. Cơ chế giám sát phải có quyền tách biệt với Agent được giám sát để tránh hệ thống vừa hành động vừa kiểm soát bằng cùng một danh tính.

5. Con người có bị thay thế không?

Đội sản phẩm định nghĩa thành công; kỹ sư gắn instrumentation, tức điểm đo; người nghiệp vụ đánh giá chất lượng; an toàn quyết định dữ liệu nào được ghi; FinOps theo dõi chi phí. Con người duyệt thay đổi quyền, ngưỡng và quy tắc xử lý sự cố.

Mục tiêu không phải loại con người khỏi quy trình mà chuyển thời gian từ việc thu thập và kiểm tra lặp lại sang xử lý ngoại lệ, cân nhắc đánh đổi và chịu trách nhiệm. Quyền tự động hóa chỉ nên tăng sau khi hệ thống chứng minh chất lượng trên dữ liệu vận hành.

PHẦN II — NHỮNG ỨNG DỤNG THỰC TẾ

6. Theo dõi đường đi của một nhiệm vụ

Bài toán. Kết quả cuối không cho biết Agent đã chọn những bước nào. AI xử lý thế nào. Trace nối yêu cầu, lần gọi mô hình, truy xuất, công cụ và phê duyệt bằng một mã chung.

Ví dụ. Yêu cầu hoàn tiền có 14 span, từ xác minh đơn đến tạo bản nháp. Giá trị và giới hạn. Điều tra nhanh và tái hiện được. Trace thiếu chuẩn đặt tên sẽ thành danh sách khó đọc.

Mỗi nhiệm vụ nên có một mã trace duy nhất nối yêu cầu ban đầu với các bước suy luận, lần truy xuất dữ liệu, lệnh gọi công cụ và kết quả cuối. Khi một báo giá sai, đội vận hành có thể lần từ email đã gửi về chính sách và bảng giá đã dùng. Trace không cần lưu toàn bộ suy nghĩ nội bộ của mô hình; điều cần thiết là bằng chứng vận hành có thể kiểm tra.

7. Phát hiện vòng lặp công cụ

Bài toán. Agent gọi tìm kiếm hoặc API nhiều lần mà không tiến gần mục tiêu. AI xử lý thế nào. Hệ thống nhận diện chuỗi hành động lặp với cùng tham số hoặc kết quả.

Ví dụ. Agent kiểm tra tồn 18 lần vì không xử lý trạng thái “đang đồng bộ”. Giá trị và giới hạn. Giảm latency và chi phí. Không tự dừng mọi lần lặp; một số retry là cần thiết khi dịch vụ tạm lỗi.

Vòng lặp xảy ra khi Agent gọi cùng công cụ nhiều lần mà không tiến gần mục tiêu, thường do kết quả mơ hồ hoặc trạng thái không được cập nhật. Hệ thống cần giới hạn số bước, thời gian và chi phí, đồng thời phát hiện chuỗi hành động lặp. Dừng có kiểm soát và chuyển cho người xử lý tốt hơn việc để Agent tiếp tục tiêu token hoặc tạo tác động trùng.

8. Đo token và chi phí theo nhiệm vụ

Bài toán. Hóa đơn mô hình chỉ cho tổng chi phí, khó biết workflow nào gây tốn. AI xử lý thế nào. Gắn usage của từng lời gọi vào trace, cộng thêm phí công cụ, lưu trữ và hạ tầng.

Ví dụ. Tóm tắt hợp đồng tốn gấp bốn vì nạp toàn bộ tài liệu ở mỗi bước. Giá trị và giới hạn. Tối ưu đúng điểm. Chỉ giảm token có thể làm chất lượng giảm; phải xem cost cùng success rate.

Chi phí cần được quy về nhiệm vụ kinh doanh, không chỉ tổng token trong tháng. Doanh nghiệp nên biết một hồ sơ hợp đồng, một lead hay một ticket tiêu tốn bao nhiêu cho mô hình, tìm kiếm, API và hạ tầng. Số liệu này phải đặt cạnh tỷ lệ hoàn thành và thời gian tiết kiệm; nhiệm vụ rẻ nhưng sai nhiều vẫn là phương án đắt.

9. Tách lỗi mô hình và lỗi công cụ

Bài toán. Agent báo thất bại nhưng nguyên nhân có thể từ API, quyền, dữ liệu hoặc suy luận. AI xử lý thế nào. Span có loại lỗi, mã phản hồi và đầu vào đã che nhạy cảm.

Ví dụ. Không tạo được PO vì ERP từ chối quyền, không phải mô hình hiểu sai. Giá trị và giới hạn. Giao đúng đội xử lý. Thông báo lỗi công cụ có thể chứa dữ liệu bí mật, cần lọc trước khi lưu.

Lỗi mô hình gồm hiểu sai yêu cầu, chọn sai dữ liệu hoặc tạo kết luận thiếu căn cứ; lỗi công cụ có thể là API trả 500, thiếu quyền hoặc hết thời gian chờ. Hai nhóm cần cách xử lý khác nhau. Nếu gom tất cả thành thông báo 'Agent thất bại', đội kỹ thuật khó xác định nên sửa prompt, dữ liệu, tích hợp hay chính sách retry.

10. Kiểm tra nguồn được truy xuất

Bài toán. Câu trả lời có vẻ đúng nhưng dùng tài liệu hết hiệu lực. AI xử lý thế nào. Trace lưu ID tài liệu, phiên bản, điểm xếp hạng và đoạn đã đưa vào context.

Ví dụ. Agent dùng bảng giá tháng trước dù bảng mới có điểm tìm kiếm thấp hơn. Giá trị và giới hạn. Đánh giá retrieval riêng khỏi generation. Không lưu toàn bộ nội dung nhạy cảm nếu chỉ cần mã và hash.

Hệ thống nên ghi tài liệu, phiên bản, thời điểm hiệu lực và đoạn bằng chứng đã dùng cho mỗi kết luận quan trọng. Một nguồn được truy xuất thành công chưa chắc là nguồn đúng. Khi chính sách mới thay thế chính sách cũ, Agent phải ưu tiên bản có hiệu lực và cảnh báo nếu các tài liệu mâu thuẫn thay vì tự chọn theo mức tương đồng.

11. Theo dõi Human Approval

Bài toán. Doanh nghiệp không biết ai đã duyệt hành động và dựa trên thông tin nào. AI xử lý thế nào. Nhật ký ghi người duyệt, thời điểm, thay đổi so với đề xuất và lý do.

Ví dụ. Quản lý sửa số tiền hoàn trước khi ERP ghi nhận. Giá trị và giới hạn. Rõ trách nhiệm và tạo dữ liệu học. Không dùng log để chấm điểm nhân sự máy móc ngoài mục đích đã thông báo.

Human Approval cần lưu ai đã duyệt, duyệt nội dung nào, vào thời điểm nào và dữ liệu có thay đổi sau đó không. Một nút 'Approve' thiếu bản chụp trạng thái sẽ không đủ cho kiểm toán. Những hành động như gửi báo giá, hoàn tiền hoặc sửa dữ liệu chuẩn nên yêu cầu phê duyệt theo vai trò và hạn mức, không dựa vào tên người dùng tự khai.

12. Phát hiện chất lượng suy giảm theo phiên bản

Bài toán. Đổi model hoặc prompt có thể cải thiện một loại nhiệm vụ nhưng làm hỏng loại khác. AI xử lý thế nào. So metric và eval theo version, segment và độ khó.

Ví dụ. Phiên bản mới nhanh hơn nhưng bỏ sót điều khoản gia hạn tự động. Giá trị và giới hạn. Rollback có bằng chứng. Trung bình toàn hệ thống che nhóm ít gặp nhưng rủi ro cao.

Sau khi đổi mô hình, prompt hoặc nguồn dữ liệu, chất lượng có thể giảm dù hệ thống vẫn chạy bình thường. Bộ test cố định và lưu lượng thật đã ẩn danh giúp so sánh theo phiên bản. Cảnh báo nên tập trung vào sai số có ý nghĩa kinh doanh, chẳng hạn tăng tỷ lệ chuyển nhầm ticket, thay vì chỉ theo một điểm trung bình khó hành động.

13. Cảnh báo hành động vượt quyền

Bài toán. Agent cố gọi công cụ hoặc truy cập trường ngoài phạm vi. AI xử lý thế nào. Policy engine chặn, đồng thời tạo sự kiện bảo mật trong trace.

Ví dụ. Agent CSKH cố đọc giá vốn khi xử lý đổi trả. Giá trị và giới hạn. Phát hiện thiết kế quyền sai hoặc prompt injection. Không đưa dữ liệu bị chặn trở lại thông báo lỗi cho Agent.

Quan sát quyền phải dựa trên hành động thực tế, không chỉ câu trả lời bằng văn bản. Agent có thể nói rằng nó không được phép xóa dữ liệu nhưng vẫn gọi nhầm công cụ có quyền xóa. Hệ thống cần chặn ở lớp thực thi, ghi lại yêu cầu bị từ chối và cảnh báo khi mẫu vượt quyền lặp lại hoặc xuất hiện ở nhiệm vụ rủi ro cao.

14. Theo dõi độ trễ từng chặng

Bài toán. Người dùng thấy chậm nhưng không biết do model, retrieval hay ERP. AI xử lý thế nào. Span timing phân rã thời gian chờ và thời gian xử lý.

Ví dụ. 80% thời gian nằm ở API hợp đồng, không phải mô hình. Giá trị và giới hạn. Tối ưu đúng dịch vụ. Sampling quá thấp có thể bỏ qua sự cố hiếm.

Độ trễ tổng có thể đến từ mô hình, tìm kiếm, công cụ nội bộ, bước chờ phê duyệt hoặc hàng đợi. Tách thời gian từng chặng giúp biết chỗ nào cần tối ưu. Không nên tăng tốc bằng cách bỏ kiểm tra an toàn; với tác vụ tài chính, thêm vài giây xác minh thường hợp lý hơn một phản hồi nhanh nhưng khó kiểm soát.

15. Nhóm sự cố theo nguyên nhân

Bài toán. Hàng nghìn lỗi riêng lẻ làm đội trực bị ngập cảnh báo. AI xử lý thế nào. AI gom trace có chuỗi lỗi và phụ thuộc giống nhau, rồi xếp theo tác động.

Ví dụ. 600 thất bại cùng xuất phát từ token API hết hạn. Giá trị và giới hạn. Giảm nhiễu và MTTR. Nhóm sai có thể che sự cố khác; người trực phải xem mẫu đại diện.

Một trăm cảnh báo có thể bắt nguồn từ cùng một API đổi cấu trúc hoặc một tài liệu lỗi. AI có thể nhóm sự cố theo dấu hiệu chung và chỉ ra tài sản bị ảnh hưởng, giúp giảm nhiễu cho đội trực. Kết luận nguyên nhân gốc vẫn cần được xác nhận bằng log và thay đổi hệ thống, vì các lỗi tương quan chưa chắc cùng nguyên nhân.

16. Đánh giá an toàn và chất lượng

Bài toán. HTTP 200 không có nghĩa nhiệm vụ đúng hoặc an toàn. AI xử lý thế nào. Grader chấm dẫn nguồn, tuân thủ chính sách, kết quả nghiệp vụ và khả năng biết dừng.

Ví dụ. Agent hoàn thành nhưng tự suy diễn địa chỉ giao hàng nên bị đánh fail. Giá trị và giới hạn. Đưa chất lượng vào vận hành. Grader dùng mô hình cũng có sai số; cần mẫu con người và tiêu chí xác định.

Chất lượng gồm độ đúng, đầy đủ, nhất quán và khả năng dẫn nguồn; an toàn gồm quyền, dữ liệu nhạy cảm và hành động bị cấm. Hai nhóm phải được kiểm tra riêng. Một Agent trả lời rất hay vẫn không đạt nếu tiết lộ dữ liệu, trong khi Agent an toàn nhưng luôn từ chối cũng không tạo được giá trị kinh doanh.

17. Điều tra sự cố end-to-end

Bài toán. Khi có thiệt hại, các đội giữ log rời rạc và mốc thời gian khác nhau. AI xử lý thế nào. Trace ID liên kết Agent, gateway, dữ liệu, công cụ và hệ thống đích.

Ví dụ. Đội điều tra truy từ email gửi sai về tài liệu, prompt và người duyệt. Giá trị và giới hạn. Rút ngắn điều tra và hỗ trợ audit. Retention trace phải cân bằng yêu cầu kiểm toán với quyền riêng tư.

Điều tra end-to-end cần nối phiên bản mô hình, prompt, dữ liệu truy xuất, công cụ, quyết định phê duyệt và tác động cuối. Sau sự cố, đội phụ trách phải tái hiện được điều kiện, khoanh vùng người dùng bị ảnh hưởng và xác định cách phục hồi. Báo cáo hậu kiểm nên tập trung vào lỗ hổng hệ thống và biện pháp ngăn tái diễn, không chỉ tìm người để quy trách nhiệm.

PHẦN III — AI AGENT, DỮ LIỆU VÀ KIỂM SOÁT

18. AI Assistant và AI Agent khác nhau thế nào?

AI Assistant là trợ lý: nhận câu hỏi, tìm thông tin và chuẩn bị câu trả lời để một người sử dụng. AI Agent là hệ thống có thể theo đuổi một mục tiêu qua nhiều bước, chẳng hạn xác định dữ liệu cần lấy, gọi công cụ tìm kiếm nội bộ, kiểm tra quyền, so sánh kết quả rồi tạo một đề xuất trong phần mềm vận hành. Khác biệt quan trọng không nằm ở cách trò chuyện mà ở quyền hành động và khả năng duy trì trạng thái của công việc.

Agent vận hành observability có thể đọc telemetry, xác định trace bất thường, liên kết dependency và mở ticket kèm bằng chứng. Nó có thể tự tạm dừng một workflow khi vi phạm ngưỡng đã phê duyệt. Việc xóa log, thay đổi quyền, phát lại hành động hoặc kết luận sự cố nghiêm trọng phải có Human Approval.

19. Dữ liệu nào cần được đưa vào ngữ cảnh?

Cần trace ID, session và task ID; phiên bản model, prompt và công cụ; token input–output; latency; status; tài liệu truy xuất; action; approval; cost; feedback và kết quả nghiệp vụ. PII, bí mật, nội dung hợp đồng và credential phải được che, băm hoặc không ghi.

Dữ liệu quan sát phải có schema ổn định và thời gian đồng bộ. Sampling có thể giảm chi phí nhưng nên giữ 100% sự kiện lỗi, hành động có rủi ro và mẫu đại diện cho nhiệm vụ thành công. Trace không nên trở thành kho sao chép vô hạn mọi prompt.

20. Vai trò của ERP, CRM, Data Warehouse và Data Platform

ERP, tức hệ thống hoạch định nguồn lực doanh nghiệp, giữ giao dịch như đơn hàng, tồn kho, hóa đơn và sổ cái. CRM, tức hệ thống quản lý quan hệ khách hàng, giữ lịch sử tương tác và cơ hội bán hàng. Data Warehouse là kho dữ liệu được tổ chức cho báo cáo và phân tích; Data Platform là tập hợp rộng hơn gồm kết nối, lưu trữ, xử lý, danh mục dữ liệu, kiểm tra chất lượng, bảo mật và các giao diện phục vụ AI.

CRM và ERP cung cấp kết quả nghiệp vụ để biết hành động có thật sự hoàn tất; Data Warehouse hợp nhất telemetry với chi phí và outcome; Data Platform quản lý pipeline, retention, catalog và quyền. Semantic layer giúp định nghĩa cùng một khái niệm “thành công” hay “chi phí nhiệm vụ” cho nhiều dashboard.

21. Data Quality, quyền truy cập và bảo mật

Data Quality nghĩa là chất lượng dữ liệu. Dữ liệu phải đủ, đúng, nhất quán, hợp lệ và đến đúng lúc. Một bảng doanh thu chính xác vào cuối tháng vẫn có thể vô dụng cho quyết định giao hàng cần đưa ra trong mười phút. Mỗi trường dữ liệu đưa cho AI phải có nguồn, thời điểm cập nhật và chủ sở hữu; trường nhạy cảm cần được che hoặc loại bỏ nếu nhiệm vụ không cần đến.

Quyền của Agent phải theo nguyên tắc tối thiểu: chỉ đọc đúng nguồn cần thiết, chỉ ghi vào đúng hệ thống và chỉ trong phạm vi nhiệm vụ. Nhật ký cần ghi dữ liệu nào đã được truy cập, công cụ nào đã được gọi, kết quả trung gian và ai phê duyệt. Prompt không phải hàng rào bảo mật; quyền phải được kiểm soát bằng tài khoản dịch vụ, chính sách truy cập và bước phê duyệt trong hệ thống.

22. Đánh giá chất lượng ngữ cảnh trước khi vận hành

Test set phải gồm thành công đơn giản, công cụ lỗi, nguồn mâu thuẫn, vòng lặp, vượt quyền, prompt injection, dữ liệu chậm và trường hợp cần chuyển người. Mỗi case xác định trace tối thiểu phải xuất hiện và kết quả nghiệp vụ mong đợi.

Sau mỗi thay đổi, chạy regression eval và so latency, cost, quality, safety. Trong production, dùng online evaluation trên mẫu có kiểm soát; kết quả của grader phải được hiệu chỉnh bằng đánh giá người thật.

PHẦN IV — TRIỂN KHAI TRONG DOANH NGHIỆP

23. Bắt đầu từ một quyết định có giá trị

Bắt đầu với một Agent đang có người dùng thật và một workflow 5–10 bước. Gắn trace cho model, retrieval và tool call trước; sau đó nối outcome nghiệp vụ và approval.

Đề bài một trang nên nêu hiện trạng, người ra quyết định, dữ liệu đang có, dữ liệu còn thiếu, rủi ro nếu sai và tiêu chuẩn thành công. Cách làm này buộc nhóm dự án giải quyết bài toán kinh doanh trước khi chọn công cụ.

24. Ba use case đầu tiên ít rủi ro

Ba use case đầu là điều tra task lỗi, đo chi phí theo loại nhiệm vụ và phát hiện vòng lặp công cụ. Chúng ít rủi ro vì quan sát trước khi tự động can thiệp.

Cả ba nên chạy ở chế độ đề xuất, chưa tự thực hiện hành động khó đảo ngược. Người duyệt cần ghi lý do chấp nhận hoặc từ chối; chính dữ liệu phản hồi này giúp cải thiện hệ thống và phát hiện những ngoại lệ mà nhóm kỹ thuật chưa biết.

25. Roadmap triển khai 90 ngày

Ngày 1–30 dành cho việc chốt một quy trình, đo đường cơ sở, lập bản đồ dữ liệu và quyền, đồng thời thu thập các tình huống bình thường lẫn tình huống xấu. Ngày 31–60 xây phiên bản tối thiểu, kết nối một số nguồn có kiểm soát và chạy lại các tình huống lịch sử. Mỗi lỗi phải được phân loại: thiếu dữ liệu, sai định nghĩa, lấy nhầm nguồn, suy luận sai hay hành động sai.

Ngày 61–90 hệ thống chạy song song với cách cũ trong một đơn vị đại diện. Nhóm dự án theo dõi chất lượng, thời gian xử lý, chi phí và số lần con người phải sửa. Kết thúc 90 ngày phải có quyết định mở rộng, điều chỉnh hoặc dừng; pilot không đạt vẫn có giá trị nếu giúp doanh nghiệp tránh mở rộng một thiết kế sai.

26. KPI cần đo

Đo task success rate, quality pass rate, p50/p95 latency, tool error, retry và loop rate, token và tổng cost/task, tỷ lệ có trace đầy đủ, MTTR, policy violation, human override và outcome nghiệp vụ. Phân tách theo version và risk tier.

KPI phải có đường cơ sở trước triển khai và được chia theo loại nhiệm vụ, mức rủi ro, bộ phận và phiên bản hệ thống. Tổng số câu trả lời hoặc số lượt dùng không đủ chứng minh giá trị nếu người dùng vẫn phải kiểm tra lại từ đầu.

27. Những sai lầm phổ biến

Sai lầm gồm chỉ ghi câu trả lời cuối, log quá nhiều dữ liệu nhạy cảm, không version prompt, không gắn outcome, chỉ nhìn trung bình, cho Agent tự sửa log và dùng một dashboard kỹ thuật cho mọi đối tượng. Một lỗi khác là không tính chi phí ngoài token như search, API và hạ tầng.

Sai lầm chung là đánh giá bằng một buổi trình diễn đẹp, dùng dữ liệu mẫu sạch và bỏ qua trường hợp ngoại lệ. Một hệ thống đáng tin phải biết nói “không đủ dữ liệu”, biết dừng và chuyển cho đúng người thay vì luôn tạo ra câu trả lời trôi chảy.

28. Điều kiện để mở rộng

Mở rộng khi taxonomy nhiệm vụ ổn định, trace coverage đủ, retention được phê duyệt và alert có tỷ lệ hữu ích cao. Với Agent quyền cao, cần replay sandbox, kill switch và trực sự cố rõ.

Mỗi lần chỉ nên mở rộng một chiều: thêm người dùng, thêm miền dữ liệu hoặc tăng quyền hành động. Tăng cả ba cùng lúc khiến đội vận hành không thể xác định nguyên nhân khi chất lượng giảm.

PHẦN V — TÌNH HUỐNG TỔNG THỂ VÀ TƯƠNG LAI

29. Tình huống doanh nghiệp tổng thể

Giả sử doanh nghiệp dùng Agent xử lý 20.000 yêu cầu hoàn tiền mỗi tháng. Có khách phản ánh được hoàn hai lần, nhưng log ban đầu chỉ ghi câu trả lời cuối và mã HTTP thành công.

Nhóm triển khai gắn trace cho xác minh danh tính, tìm đơn, đọc chính sách, tính tiền, phê duyệt và ghi ERP. Họ phát hiện Agent retry sau timeout: ERP đã ghi lần đầu nhưng trả lời chậm, lần hai tạo giao dịch mới. Idempotency key được bổ sung; cảnh báo nhận diện hai lần ghi cùng đơn; hành động hoàn trên ngưỡng vẫn cần quản lý duyệt.

30. Trước và sau khi triển khai

Trước observability, đội hỗ trợ xem nhiều log, hỏi nhiều nhóm và không tái hiện được đường đi. Chi phí tăng chỉ được thấy ở hóa đơn cuối tháng.

Sau triển khai, mỗi nhiệm vụ có hồ sơ, sự cố được khoanh vùng theo span và chi phí gắn với workflow. Người nghiệp vụ thấy outcome và override; kỹ thuật thấy lỗi và latency; lãnh đạo thấy giá trị và rủi ro.

31. Công việc sẽ thay đổi ra sao?

Quan sát Agent sẽ hội tụ với chuẩn telemetry phần mềm nhưng bổ sung context, evaluation và policy. Công việc đọc log thủ công giảm; nhu cầu về AI reliability engineer, evaluator và product owner chất lượng tăng.

AI có thể điều tra sơ bộ và đề xuất sửa, nhưng hệ thống kiểm soát phải độc lập và con người vẫn chịu trách nhiệm với ngưỡng, quyền và quyết định khắc phục có hậu quả.

32. Kết luận

Agent Observability biến AI Agent từ hộp đen thành một quy trình có thể kiểm tra. Trace, metric, log, eval và outcome phải được nhìn cùng nhau; thiếu một lớp sẽ tạo điểm mù.

Câu hỏi chiến lược là: nếu Agent gây ra một hành động sai vào sáng mai, doanh nghiệp có thể chỉ ra chính xác dữ liệu, quyết định, công cụ, chi phí và người duyệt trong bao lâu? Quan sát tốt không ngăn mọi lỗi, nhưng giúp lỗi được phát hiện, giới hạn và sửa bằng bằng chứng.

Bài viết liên quan

Để mở rộng chủ đề, có thể đọc thêm bộ dữ liệu đánh giá AI Agent, chi phí cho mỗi AI Agent và AI trong phát hiện gian lận.

Tài liệu tham khảo

1. Microsoft — Agent tracing overview
2. Microsoft — Observability in generative AI
3. Microsoft — Set up tracing for AI agents
4. Microsoft — Configure tracing for agent frameworks
5. OpenTelemetry — Generative AI semantic conventions
6. OpenAI — Agents SDK tracing
7. OpenAI — Usage API
8. OpenAI — Evals API

TechData.AI - Leading the Future.

Tham khảo các khoá học theo link: https://techdata.ai/techdata-ai-course/

Hoàng Minh.