
Cloudflare bổ sung tính năng truy vết tác nhân (Agent Tracing), với giới hạn cắt ngắn và mặc định tải trọng không đồng đều.
Cloudflare đã ra mắt tính năng theo dõi tác nhân (agent tracing), bổ sung các "span" (khoảng thời gian hoạt động) cho các lệnh gọi tác nhân, cuộc gọi mô hình, hoạt động công cụ và phê duyệt vào các dấu vết Workers hiện có. Các phiên được phát lại từng bước, mặc dù tài liệu cảnh báo rằng các dấu vết không hoàn hảo và tải trọng (payload) có thể bị cắt bớt. Việc ghi lại tải trọng mặc định khác nhau tùy theo từng framework và kể từ ngày 1/10/2026, mỗi "span" sẽ được tính là một sự kiện có thể lập hóa đơn. Theo Steef-Jan Wiggers
InfoQ Trang chủ
Tin tức
Cloudflare bổ sung tính năng Agent Tracing, với giới hạn cắt bớt và mặc định tải trọng không đồng đều
Điện toán đám mây
Cloudflare bổ sung tính năng Agent Tracing, với giới hạn cắt bớt và mặc định tải trọng không đồng đều
Ngày 15/8/2026
4 phút đọc
Bởi
Steef-Jan Wiggers
Theo dõi chúng tôi trên
Youtube 232K người theo dõi
Linkedin 26K người theo dõi
Instagram Mới
RSS 19K người đọc
X 57.1k người theo dõi
Facebook 21K lượt thích
Bluesky Mới
Nghe bài viết này - 0:00
Âm thanh sẵn sàng phát
Trình duyệt của bạn không hỗ trợ phần tử âm thanh.
0:00
0:00
Bình thường 1.25x 1.5x
Thích
Danh sách đọc
Cloudflare đã ra mắt tính năng truy vết tác nhân (agent tracing), thành phần đầu tiên của Cloudflare Agents, một giao diện bảng điều khiển tập hợp các phiên tác nhân đã triển khai tại một nơi. Bản phát hành này bổ sung các phạm vi (span) cấp tác nhân vào tính năng truy vết Workers hiện có và đi kèm với một ngày áp dụng giá: tính năng truy vết miễn phí trong giai đoạn thử nghiệm (beta), và từ ngày 01/10/2026, nó sẽ thuộc chính sách giá Workers Observability.
Phần hữu ích là tuyên bố vấn đề. Một tác nhân có thể trả về HTTP 200 nhưng vẫn thất bại. Nó có thể chọn sai công cụ, chuyển ngữ cảnh lỗi thời cho một tác nhân phụ (subagent), hoặc tiêu tốn token trong một vòng lặp thử lại, và dữ liệu đo từ xa của ứng dụng sẽ hiển thị yêu cầu API hoặc truy vấn cơ sở dữ liệu mà không cho thấy hành vi của tác nhân đã gây ra lỗi đó.
Tính năng truy vết Workers đã đo lường lớp hạ tầng, bao gồm các lệnh gọi fetch, đọc KV và truy vấn D1. Cho đến nay, các dấu vết cho các tác nhân chạy trên Workers chỉ mang các phạm vi hạ tầng đó mà không có gì xung quanh chúng. Tính năng truy vết tác nhân bổ sung các phạm vi cho các lệnh gọi tác nhân, lệnh gọi mô hình, thực thi công cụ và phê duyệt, với việc sử dụng mô hình và token được đính kèm dưới dạng siêu dữ liệu. Mỗi lượt tạo ra một dấu vết:
invoke_agent {lớp tác nhân}
├── chat {mô hình}
└── execute_tool {công cụ}
└── tool_approval {công cụ}
Công việc của tác nhân phụ được lồng dưới hoạt động đã gọi nó, vì vậy một tác nhân cha ủy quyền cho một tác nhân phụ gọi một mô hình, chạy một công cụ, truy vấn D1 và ghi vào KV sẽ xuất hiện dưới dạng một thác nước duy nhất trên cả hai lớp. Ba trường liên kết các phạm vi với bảng điều khiển: tên tác nhân cho việc triển khai logic, ID tác nhân cho phiên bản và ID cuộc trò chuyện. Cloudflare cảnh báo không nên lấy tên tác nhân từ một yêu cầu hoặc định danh người dùng, điều này sẽ làm tăng số lượng tác nhân riêng biệt trong chế độ xem.
Sự liền kề đó là điều mà các nhà phát triển đã phản hồi. Trả lời thông báo của Cloudflare trên X, Mykyta Pavlenko đã viết:
tôi sẽ thử cái này trên hermes chỉ để xem thác nước truy vết - nhìn thấy lệnh gọi mô hình ngay phía trên một đối số công cụ sai là chế độ xem gỡ lỗi mà tôi muốn
Một cảnh báo nằm trong phạm vi phê duyệt. Tài liệu lưu ý rằng những điều này đại diện cho các sự kiện vòng đời trong một lệnh gọi Worker và không đo lường thời gian một người chờ đợi trước khi phản hồi giữa các lệnh gọi. Độ trễ của con người trong vòng lặp (human-in-the-loop latency), có lẽ là con số thú vị nhất trong quy trình làm việc phê duyệt, không phải là thứ mà phạm vi ghi lại.
Cùng với chế độ xem dấu vết, tính năng phát lại phiên (session replay) tập hợp lại cuộc trò chuyện đã ghi lại qua các lượt: tin nhắn, lý do, lệnh gọi công cụ với các đối số và kết quả, và hoạt động của tác nhân phụ. Cloudflare nêu rõ rằng điều này phát lại dữ liệu đã ghi chứ không phải thực thi lại tác nhân.
Ghi lại tải trọng (payload recording) là nơi các nhóm cần chú ý, vì các cài đặt mặc định không nhất quán. Think không lưu trữ tải trọng tin nhắn hoặc công cụ trừ khi storeMessages và storeTools được đặt trên lớp tác nhân, và wrapAISDK() hoạt động tương tự. Flue lưu trữ tin nhắn, hướng dẫn hệ thống, định nghĩa công cụ, đối số và kết quả theo mặc định, yêu cầu content: false để dừng. Do đó, cùng một tính năng nền tảng được phát hành với các cài đặt mặc định về quyền riêng tư đối lập tùy thuộc vào công cụ mà một nhóm đã chọn, và tải trọng tin nhắn thường chứa dữ liệu cá nhân hoặc bí mật.
Các giới hạn được ghi lại xứng đáng được chú ý tương đương. Cloudflare tuyên bố rằng các dấu vết không phải là một bản ghi hoàn chỉnh hoặc không mất mát của một cuộc trò chuyện, rằng dữ liệu tải trọng tuân theo giới hạn kích thước phạm vi nên các tin nhắn dài, lý do, đối số công cụ và kết quả có thể bị cắt bớt, và rằng phát lại phiên không hiển thị hình ảnh. Các nhóm coi phát lại là một nhật ký kiểm toán hơn là một công cụ gỡ lỗi sẽ thấy.
và nó không mang trọng lượng đó.
Thiết lập thay đổi tùy theo ngăn xếp công nghệ. Các công cụ Think và Flue phiên bản 2 trở lên tự động đo lường. Các lệnh gọi trực tiếp đến AI SDK cần một trình bao bọc `wrapAISDK()`, hỗ trợ phiên bản 6 và 7 và yêu cầu các trường định danh trong mỗi lệnh gọi vì không có phiên bản Agent để suy luận chúng. Các bộ công cụ tùy chỉnh sử dụng API `Workers custom spans`, tuân theo các triển khai tham chiếu GenAI của OpenTelemetry, bởi vì Workers chưa hỗ trợ trực tiếp API OpenTelemetry. Cloudflare cho biết họ đang nỗ lực bổ sung tính năng này, điều này sẽ cho phép các framework phát ra các span tiêu chuẩn tích hợp mà không cần đo lường thủ công. Các thuộc tính span tuân theo các quy ước ngữ nghĩa Generative AI của OpenTelemetry, và các dấu vết xuất sang bất kỳ điểm cuối OTLP nào.
Chi tiết về giá cả đòi hỏi phải đọc kỹ, vì đơn vị đo lường không phải là thứ hiển thị trên giao diện Agents. Mỗi span được tính là một sự kiện quan sát, bao gồm các span từ nội bộ SDK và các hoạt động cấp Worker khác mà giao diện không hiển thị. Từ ngày 1/10, Workers Free bao gồm 200.000 sự kiện mỗi ngày với thời gian lưu giữ ba ngày, và Workers Paid bao gồm 20 triệu sự kiện mỗi tháng với thời gian lưu giữ bảy ngày với chi phí 0,60 USD cho mỗi triệu sự kiện bổ sung. Một bộ công cụ chi tiết sẽ tốn kém hơn so với những gì bảng điều khiển gợi ý, và ba đến bảy ngày là quá ngắn đối với bất kỳ ai đang tìm kiếm một mô hình thay vì một sự cố.
Bản phát hành này phù hợp với một xu hướng rõ ràng trên các nhà cung cấp trong quý này. Bộ công cụ Agent Framework của Microsoft đã được xuất xưởng với OpenTelemetry được bật theo mặc định, và cấp độ AI Gateway của
Nguồn tin: InfoQ AI — Tác giả: Steef-Jan Wiggers. Bản dịch tiếng Việt do AI thực hiện, có thể có sai sót.