AI Agent Observability: Making Silent Production Failures Visible and Actionable

Salesforce · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài phỏng vấn dạng hỏi–đáp (series Engineering Energizers) về một tính năng sản phẩm; không có sơ đồ chi tiết hay số liệu sự cố. Mọi nhận định là theo Salesforce.

Bối cảnh

• Agentforce Health Monitoring (AHM) giúp người dựng agent và người vận hành của khách phát hiện sự cố về khả dụng của agent ở production, điều tra, và định tuyến alert theo quy trình của tổ chức họ.
• Theo Salesforce, metric "xanh" đánh lừa: agent trông khoẻ trong khi request không tới được nó, kết nối upstream hỏng, hay gateway LLM sập làm nó không trả lời; monitoring thông thường không cho người vận hành biết người dùng đã không còn nhận được câu trả lời trọn vẹn.

Thay đổi chính

• Metric khả dụng của agent đo theo đầu–cuối, kèm alert tự động, cho đúng ca "hỏng âm thầm"; cùng hơn 16 metric có sẵn (tỉ lệ lỗi, tỉ lệ trả lời/chuyển người, mức tương tác, latency). Lộ trình: chi phí, TTFT/TTLT, độc hại, phản hồi người dùng, nối với giám sát chất lượng RAG.
• Gộp telemetry rời rạc: một phiên agent sinh dữ liệu ở tương tác, bước suy luận, gọi tool, lỗi, chuyển người, nằm ở khoảng năm, sáu chỗ khác nhau; không sự kiện nào một mình giải thích được chuyện gì xảy ra. Phải ghép thành một biểu diễn mạch lạc của hành trình phiên trước khi tính metric. Theo Salesforce, phần khó nhất không phải tạo một alert mà là nối alert với ngữ cảnh để hiểu nó.
• Rút ngắn độ trễ alert: ban đầu khoảng 20 phút từ sự kiện làm metric vượt ngưỡng tới lúc người quản trị nhận alert. Chuyển ingest của Data 360 sang streaming và đơn giản hoá query để đánh giá alert thường hơn; còn vài phút. Mục tiêu điều tra: dưới 120 giây từ lúc bấm link trong alert tới lúc thấy trang phiên liên quan. Theo bài, đủ cho phản hồi bằng người; phản hồi bằng agent sau này sẽ cần gần thời gian thực hơn.
• Alert dẫn tới phiên bị ảnh hưởng: drill-down từ alert tới các phiên lỗi và tới bước, trường liên quan, để thấy nguyên nhân là ngữ cảnh sai, bài kiến thức thiếu, gọi tool lỗi hay flow thiết kế kém. Khách tự định nghĩa metric và alert (ví dụ phiên vượt ngưỡng token).
• Phát hiện chất lượng còn dở: ảo giác, mất ngữ cảnh, grounding kém cần tổ hợp tín hiệu khác nhau theo use case, và mỗi khách định nghĩa "không chấp nhận được" khác nhau; team làm cùng các team sinh tín hiệu và kỹ sư triển khai tại khách để lấy đúng dữ liệu nguồn, việc này vẫn đang tiếp tục.
• Hướng tiếp: vòng đời sự cố gồm phát hiện, báo, chẩn đoán, sửa; AHM mới làm hai bước đầu. Đang thử một agent trả lời "vì sao alert này bắn" và gợi ý cách sửa, rồi tự sửa khi khách duyệt; cân nhắc heartbeat, retry và chuyển cho người mà giữ ngữ cảnh phiên.

Vì sao

• Với agent, "process còn sống, request trả 200" không đồng nghĩa người dùng được phục vụ; phải đo từ phía kết quả đầu–cuối.

Bài học cho SWE

• Hỏng âm thầm cần metric khả dụng đo đầu–cuối, không chỉ metric sức khoẻ của từng thành phần.
• Telemetry của một phiên nằm rải nhiều hệ thì phải ghép thành một hành trình trước khi alert có nghĩa.
• Độ trễ alert là tổng của ingest và chu kỳ đánh giá; chuyển ingest sang streaming và làm query rẻ để đánh giá thường hơn.
• Đo thời gian từ alert tới ngữ cảnh chẩn đoán như một metric riêng.

Liên quan

• Observability và monitoring · Xử lý sự cố và on-call
• Cùng công ty: Salesforce 2026 · Salesforce 2017 · Salesforce 2019
• Cùng bài toán: Nubank 2022 (model sai mà không lỗi) · Anthropic 2025 (lỗi chất lượng vẫn trả 200)