Microsoft’s Foundry team đã bổ sung tính năng truy vết (tracing) dựa trên OpenTelemetry vào framework agent của mình, giúp các nhà phát triển có thể quan sát quá trình thực thi đầu cuối (end-to-end) giữa các agent vận hành bằng LLM không đồng nhất.

Tại sao các hệ thống đa agent cần nhiều hơn là chỉ các tệp nhật ký

Một bài diễn tập ứng phó sự cố dựa trên AI điển hình sử dụng một agent chỉ huy (commander agent) để điều phối nhiều agent chuyên gia: một agent phân tích nhật ký, một agent khác phát hiện các điểm bất thường về chỉ số, agent thứ ba đối chiếu các triệu chứng với các quy trình xử lý (runbooks), và một bộ định tuyến (router) sẽ chọn mô hình ngôn ngữ tốt nhất cho từng tác vụ phụ. Mỗi chuyên gia có thể gọi một mô hình khác nhau—chẳng hạn như một biến thể “gpt-5-mini”—và kích hoạt các công cụ riêng của chúng. Khi có lỗi xảy ra, các kỹ sư chỉ có thể nhìn vào các tệp nhật ký rời rạc cho thấy từng thành phần đã làm gì, nhưng không có cái nhìn tổng thể về cách các phần này kết nối với nhau.

Nếu không có một vết truy vết (trace) thống nhất, nguyên nhân gốc rễ sẽ bị ẩn đi trong quá trình chuyển giao giữa các agent. Agent chỉ huy có thể gửi một yêu cầu mà agent đọc nhật ký xử lý chính xác, nhưng agent chuyên gia về chỉ số lại diễn giải sai dữ liệu và đề xuất sai quy trình xử lý. Việc gỡ lỗi chuỗi này bằng tay sẽ tốn thời gian và dễ dẫn đến sai sót.

Cách OpenTelemetry kết nối quy trình làm việc lại với nhau

OpenTelemetry định nghĩa hai khái niệm cốt lõi: traces và spans. Một trace là một mã định danh duy nhất theo dõi một yêu cầu từ lúc bắt đầu cho đến khi có phản hồi cuối cùng. Một span ghi lại một hoạt động đơn lẻ—chẳng hạn như một lệnh gọi đến mô hình ngôn ngữ hoặc một lần kích hoạt công cụ—trong phạm vi trace đó.

Khi một agent nhận được yêu cầu, nó sẽ lấy Trace ID đi kèm từ metadata của yêu cầu và tạo ra một child span (span con) kế thừa cùng ID đó. Child span sẽ ghi lại thời gian bắt đầu, thời lượng, các thuộc tính (tên mô hình, công cụ được sử dụng) và bất kỳ lỗi nào. Quá trình này lặp lại cho mọi agent hạ nguồn (downstream agent), xây dựng nên một cấu trúc cây phản ánh luồng logic của toàn bộ tác vụ.

OpenTelemetry cũng hỗ trợ Baggage, một phương thức vận chuyển nhẹ nhàng cho các cặp khóa-giá trị (key-value) tùy chỉnh. Bằng cách gắn một “drill-id” hoặc ngữ cảnh kinh doanh khác vào baggage ở đầu trace, mọi span hạ nguồn sẽ tự động kế thừa mã định danh đó. Sau đó, một span processor sẽ chuyển đổi baggage thành các thuộc tính thông thường, giúp dễ dàng truy vấn tất cả các span thuộc về một bài diễn tập sự cố cụ thể.

Giao diện truy vết mới trông như thế nào

Với việc triển khai instrumentation, Azure Monitor (hoặc bất kỳ backend nào tương thích với OpenTelemetry) sẽ hiển thị một hệ thống phân cấp trực quan:

  • Agent name / ID – hiển thị thành phần nào đã thực hiện hoạt động.
  • Tool usage – ghi lại dịch vụ hoặc hàm bên ngoài nào đã được gọi.
  • Model version – ghi lại chính xác LLM đã được sử dụng, hữu ích cho việc theo dõi các lỗi suy giảm hiệu năng (regressions) sau khi nâng cấp mô hình.
  • Token consumption – ghi lại số lượng token đã gửi đến và nhận về từ mô hình, giúp các nhóm quản lý chi phí.
  • Latency / duration – làm nổi bật nơi xuất hiện các điểm nghẽn, cho dù là trong quá trình suy luận mô hình (model inference) hay I/O của công cụ.

Trong ví dụ về diễn tập sự cố, root span của agent chỉ huy sẽ tạo ra các child span cho từng chuyên gia, và mỗi chuyên gia lại tạo ra các child span tiếp theo cho các lệnh gọi mô hình của chúng. Nhấp vào bất kỳ nút nào sẽ hiển thị toàn bộ tập hợp thuộc tính, giúp kỹ sư thấy ngay chi tiết của từng hoạt động.

Tầm quan trọng đối với các hoạt động lấy AI làm trung tâm

  • Tốc độ phân tích nguyên nhân gốc rễ – Các nhóm có thể truy vết một lỗi ngược về đúng span đã gây ra lỗi, giúp giảm thời gian xử lý trung bình (MTTR).
  • Khả năng hiển thị chi phí – Số lượng token được đặt cạnh độ trễ, cho phép bộ phận tài chính phát hiện việc sử dụng vượt mức trước khi hóa đơn đám mây tăng vọt.
  • Tinh chỉnh hiệu suất – Các span có độ trễ cao giữa các agent sẽ chỉ ra nơi mà việc bộ nhớ đệm (caching), lựa chọn mô hình hoặc thiết kế lại công cụ có thể giúp tăng thông lượng (throughput).

Những gì cần theo dõi tiếp theo

Các dự án được xây dựng trên LangChain, OpenAI SDK hoặc các lớp điều phối (orchestration layers) khác có thể áp dụng các quy ước ngữ nghĩa (semantic conventions) tương tự cho GenAI, mở đường cho các vết truy vết có thể luân chuyển giữa các nhà cung cấp đám mây và các triển khai tại chỗ (on-premise).

Các tổ chức chỉ cần kích hoạt OpenTelemetry SDK trong các agent của mình và gửi dữ liệu đến Azure Monitor hoặc một bộ thu thập (collector) mã nguồn mở.

Bài học rút ra

OpenTelemetry cung cấp "chất keo" còn thiếu cho các hệ thống AI đa agent, giúp biến những tệp nhật ký rời rạc thành một câu chuyện mạch lạc. Bằng cách truyền một Trace ID duy nhất qua các LLM, bộ định tuyến và các lệnh gọi công cụ không đồng nhất, các nhà phát triển có thể xác định lỗi, giám sát chi phí và tối ưu hóa hiệu suất mà không cần phải xây dựng lại cơ sở hạ tầng truy vết.