Quan sát hệ thống agent ở quy mô lớn

Với một API thường, một yêu cầu là một dòng log. Với agent, một câu hỏi của người dùng có thể thành mười lần gọi model, hai chục lần gọi tool, ba subagent và một lần chờ người duyệt. Khi kết quả sai, log phẳng chỉ cho bạn một đống dòng rời rạc, không cho biết bước nào dẫn tới bước nào.

Bài này giúp bạn trả lời: quan sát hệ thống agent ở quy mô lớn khó ở đâu, cần thu thập gì, và triển khai cho cả tổ chức ra sao?

Ví dụ xuyên suốt: công ty phần mềm kế toán

Một công ty phần mềm kế toán có hai nơi dùng Claude:

• 200 kỹ sư dùng Claude Code hằng ngày.
• Một agent hỗ trợ viết bằng Agent SDK, phục vụ 1.500 doanh nghiệp khách hàng; agent gọi subagent tra sổ sách và tool xuất báo cáo.

Ban giám đốc hỏi: tháng này mỗi nhóm tốn bao nhiêu? Khách hàng X phàn nàn agent trả lời sai hôm thứ Ba, vì sao? Đội bảo mật hỏi: agent có từng chạy lệnh bị chặn nào không?

Vì sao agent khó quan sát

• Không xác định: cùng một câu hỏi, mỗi lần chạy agent có thể đi một đường khác. Bài viết về hệ thống nghiên cứu nhiều agent của Anthropic nói họ phải ghi vết toàn bộ luồng quyết định để gỡ lỗi được.
• Nhiều tầng lồng nhau: một lượt gồm lời gọi model, lời gọi tool, subagent, có khi chờ người duyệt quyền. Log phẳng mất quan hệ cha con giữa các bước.
• Dữ liệu nhạy cảm: prompt và kết quả tool chứa dữ liệu khách hàng. Bài viết trên nói họ theo dõi mẫu quyết định và cấu trúc tương tác mà không theo dõi nội dung hội thoại, để giữ riêng tư.

Lời giải chung là trace: mỗi lượt là một cây span, mỗi span là một bước có thời gian bắt đầu, kết thúc và thuộc tính.

Mỗi nền tảng xuất được gì

Metrics của Claude Code gồm số phiên, token (claude_code.token.usage), chi phí (claude_code.cost.usage), số dòng code thay đổi, số commit và pull request. Docs nói metrics chi phí là ước tính; số liệu hoá đơn chính thức phải lấy từ nhà cung cấp API.

Ghi gì để truy được lỗi

Để trả lời "vì sao agent trả lời sai hôm thứ Ba", mỗi bước phải ghi đủ:

• Model nào, phiên bản nào đã chạy lượt đó.
• Mã liên kết (correlation ID) theo từng yêu cầu, truyền xuyên qua agent, subagent và tool, để nối các bước thành một trace.
• Token và độ trễ của từng span.
• Kết quả gọi tool, đã che các trường nhạy cảm.

Triển khai cho cả tổ chức

Cấu hình tập trung. Docs của Claude Code nói quản trị viên đặt cấu hình OpenTelemetry cho mọi người qua file managed settings. Repository không tự bật telemetry hay chọn nơi gửi được. Lưu ý: khoá endpoint trong managed settings đổi nơi gửi, nhưng các biến chọn exporter (metrics, logs, traces) chỉ bị khoá nếu bạn cũng đặt chúng trong managed settings.

Gắn nhãn theo nhóm và khách hàng. Đặt OTEL_RESOURCE_ATTRIBUTES, ví dụ department=finance,team.id=platform,cost_center=eng-123; với agent phục vụ nhiều khách hàng, docs Agent SDK gợi ý gắn tenant.id và enduser.id. Mỗi khoá tự thêm thành một nhãn trên mọi chuỗi metrics, nên giá trị càng nhiều thì càng tốn lưu trữ.

Kiểm soát số chuỗi metrics (cardinality). Docs có các cờ bật tắt thuộc tính trên metrics. Mã phiên và mã tài khoản bật mặc định; phiên bản ứng dụng tắt mặc định. Với 200 kỹ sư, mỗi người nhiều phiên mỗi ngày, mã phiên làm số chuỗi tăng vọt; tắt nếu dashboard không dùng tới.

Kiểm soát nội dung. Docs nói telemetry mặc định chỉ có cấu trúc: span không chứa nội dung prompt, chi tiết đầu vào tool hay nội dung tool. Muốn có phải bật từng cờ: OTEL_LOG_USER_PROMPTS, OTEL_LOG_TOOL_DETAILS, OTEL_LOG_TOOL_CONTENT, OTEL_LOG_RAW_API_BODIES. Trên Claude API, đích telemetry có chế độ chỉ metadata (mặc định) hoặc đầy đủ nội dung; tổ chức có ràng buộc HIPAA chỉ xuất được metadata.

Đội bảo mật. Docs liệt kê các event hợp để đưa vào hệ thống SIEM: quyết định cấp quyền tool, kết quả tool, sự kiện an toàn, kết nối MCP server và đổi chế độ quyền. Trả lời được câu "agent có chạy lệnh bị chặn không".

Độ tin cậy của dữ liệu. Đích telemetry của Claude API giao ít nhất một lần, nên phải loại trùng theo mã trace và mã span; docs cũng nói span xuất ra không bảo đảm là bản ghi đầy đủ. Đối soát chi phí thì dùng số liệu sử dụng chính thức, không dùng trace.