8.1 Vì sao observability cho agent khác biệt
Agent có thể trông khỏe mạnh trên mọi tín hiệu kinh điển (không exception, phản hồi nhanh, HTTP 200) mà vẫn sai một cách tự tin. Vì vậy log request và response là không đủ. Bạn cần đồ thị quyết định: agent đã thấy gì, đã cân nhắc gì, đã gọi công cụ nào với đối số nào, kết quả trả về là gì, agent kết luận gì, và đã tiêu tốn bao nhiêu. Ngành đang hội tụ về OpenTelemetry GenAI semantic conventions, một schema chung cho lệnh gọi model, span của agent và công cụ, lượng token sử dụng và chi phí. Các nhà cung cấp observability lớn đều tiếp nhận schema này, và các framework agent phổ biến đều phát telemetry theo schema này. Các quy ước cho công việc đa agent (tác vụ, chuyển giao, thao tác memory) vẫn đang được soạn thảo trong nhóm làm việc OpenTelemetry GenAI. Quy tắc khi mua sắm suy ra từ đó. Telemetry của agent theo schema mở nghĩa là bạn có thể mang nó đi nơi khác và kiểm toán được. Telemetry theo định dạng độc quyền sẽ khóa bạn ở đúng lớp mà bạn ít có khả năng chịu đựng nhất. Hãy áp cùng quy tắc đó cho CloudThinker. Hiện tại CloudThinker không xuất trace OpenTelemetry GenAI sang backend của riêng bạn. Những gì bạn có thể lấy ra là CSV Audit Logs (mọi hành động của agent và con người), CSV Approvals → Activity (những gì mỗi Rule đã quyết định), và các góc nhìn trên trang Usage. Bảng ở cuối chương này cho biết từng thứ nằm ở đâu.8.2 Cấu trúc của một trace
Ghi một trace cho mỗi sự cố, với các cấp lồng nhau như sau:
Gán cho trace cùng ID với bản ghi sự cố (Chương 4) và bản ghi audit (Chương 6). Nhờ vậy bạn có ba góc nhìn về một sự kiện, nối với nhau bằng ID chung. Khi đó một kỹ sư có thể đi từ “cái này có vẻ chậm” đến “bước 23 kéo về 400 KB log và gửi lại chúng bốn lần” chỉ trong một truy vấn.
8.3 Metric và SLO cho đội agent
Các KPI chương trình trong Field Guide (§8) đo lường kết quả: MTTD và MTTR, tỷ lệ tự giải quyết, tỷ lệ chấp nhận đề xuất, tỷ lệ rollback và can thiệp, tỷ lệ sự cố lặp lại, tỷ lệ bao phủ, tải trực và chi phí đơn vị của agent. Bên dưới chúng, đội agent cần một lớp kỹ thuật. Hai dòng bên dưới đề cập đến “engine”. Đó là lớp cảm nhận chi phí thấp theo dõi mọi tín hiệu, và bộ giải quyết thực hiện suy luận sâu trên số ít tín hiệu mà lớp cảm nhận đẩy lên (Chương 4).
Đừng đặt SLO cho mọi thứ. Hãy chọn vài chỉ số gánh vác chương trình. Các mục tiêu ví dụ này là điểm khởi đầu để tinh chỉnh theo baseline của riêng bạn:
Với SLO và error budget, nấc thang tin cậy (Field Guide §7.3) không còn là một quyết định cảm tính. Loại sự cố được nâng cấp khi còn nằm trong ngân sách, và bị hạ cấp khi tiêu hết ngân sách.
TRONG THỰC TẾ: AI GIÁM SÁT CÁC AGENT?Câu hỏi chính đáng với bất kỳ nền tảng agent nào: “chúng ta triển khai nó để giảm việc lặp lại, vậy ai vận hành nó?” Câu trả lời nên là phần mềm được đo đạc đầy đủ, tuân theo cùng kỷ luật mà nó mang đến cho hệ thống của bạn. Đây là nơi CloudThinker cho bạn thấy các agent của chính nó:
Xem Audit Logs, Usage, Credit limits và Resolve Insights. Admin Settings là menu của tổ chức, và chỉ Owner và Admin của tổ chức mới thấy nó. Hãy yêu cầu mọi nhà cung cấp, kể cả chúng tôi, cho bạn xem các bản ghi này về agent của chính họ và cách bạn lấy chúng ra.
Thiết lập các kiểm soát agent đầu tiên
1
Giới hạn chi tiêu theo workspace
Vào Admin Settings → Credit limits. Trong When a workspace hits its monthly limit, chọn Throttle cho các workspace sandbox hoặc Notify only cho production. Đặt Default monthly limit per workspace cao hơn khoảng 20% so với chi tiêu hằng tháng của một workspace điển hình, chọn cả hai cảnh báo trong Alert the organization owner at, và nhấn Save.Trạng thái thành công: thanh lưu biến mất, và Per-workspace limits hiển thị mức sử dụng của từng workspace so với hạn mức.
2
Lấy hành động của agent trong một tuần
Vào Admin Settings → Audit Logs. Đặt Actor Type là Agent và khoảng thời gian là Last 7 days, rồi nhấn Export CSV.Trạng thái thành công: trình duyệt tải xuống
audit-trail.csv, với một dòng cho mỗi hành động của agent và một cột agent_name. Đổi tên tệp kèm khoảng thời gian, vì mọi bản xuất đều có cùng tên.Bước tiếp theo
Chương 9 · AgentOps: Vận hành đội agent ngày thứ 2
Quản lý phiên bản thay đổi, di chuyển model, giữ memory sạch và thực hiện postmortem cho agent.
Audit Logs
Lọc, kiểm tra và xuất mọi hành động mà agent và con người thực hiện.