Agent Tool Latency Disclosure Specification: Tài liệu hóa Response Time SLAs cho AI Agent Tools

TL;DR

Các AI agents hiện đang thực thi các lệnh gọi công cụ mà không có dữ liệu định lượng về độ trễ kỳ vọng, dẫn đến các rủi ro hệ thống như timeouts, bão thử lại (retry storms), và lãng phí token. Đặc tả này tiêu chuẩn hóa một khối latency_disclosure — tương thích với mọi định dạng tool manifest (MCP, OpenAI function calling, OpenAPI, độc quyền) — nhằm khai báo các mốc p50/p95/p99, chính sách timeout, tính không đổi (idempotency). Đồng thời, hành vi hệ thống khi suy giảm hiệu năng. Các nhà phát hành công cụ trích xuất dữ liệu này từ telemetry môi trường production. Các agents sẽ đọc dữ liệu trước mỗi lần gọi để lập kế hoạch về thời hạn (deadlines), phân phối tải (fan-out). Đồng thời, kịch bản dự phòng (fallback paths).

1. Tầm quan trọng của việc công bố độ trễ (Latency Disclosure)

Các tool manifests hiện hành thường tập trung mô tả chi tiết các lược đồ tham số (parameter schemas) và cấu trúc dữ liệu trả về, nhưng bỏ qua hoàn toàn các số liệu về hiệu suất thời gian. Đặc tả Model Context Protocol định nghĩa inputSchema, outputSchema và các chú thích cấu trúc (structured annotations), nhưng không yêu cầu trường dữ liệu cho thời gian phản hồi. OpenAI và Anthropic function calling cũng gặp hạn chế tương tự. Hệ quả là, khi đối mặt với hai công cụ có chức năng tương đương — một dựa trên truy vấn bộ nhớ tốc độ cao và một gọi đến API có độ trễ lớn — agent không có cơ sở dữ liệu nào để tối ưu hóa quyết định định tuyến.

Hạn chế này biểu hiện thành các vấn đề nghiêm trọng trong môi trường production:

• API của OpenAI thường xuyên ngắt kết nối (time out) các lệnh gọi MCP tool kéo dài hơn 60 giây mà không cung cấp cấu hình kiểm soát từ phía agent.
• Khung giám sát agent của Microsoft Foundry quy định bất kỳ độ trễ công cụ nào vượt mốc 10 giây đều là dấu hiệu cảnh báo của việc bóp băng thông (throttling), tải xử lý phức tạp, hoặc sự cố mạng. Tuy nhiên, agent chỉ nhận diện được điều này sau khi quá trình gọi đã bắt đầu.
• Quá trình xử lý function-calling đôi khi ghi nhận thời gian phản hồi từ 20 đến 40 giây, ngay cả đối với các lược đồ dữ liệu đã được tối giản hóa.
• Đề xuất AgentSLA (arXiv 2025) chỉ ra rằng SLAs cho agent cần một mô hình chất lượng có thể đọc bằng máy (machine-readable) theo chuẩn ISO/IEC 25010, nhưng lại bỏ ngỏ việc tiêu chuẩn hóa định dạng công bố ngay tại lớp manifest.

Công bố độ trễ (Latency disclosure) giải quyết trực tiếp khoảng trống này. Nó định chuẩn thời gian phản hồi (response time) như một yếu tố thuộc tính cốt lõi của hợp đồng công cụ (tool contract), thay vì một yếu tố bị động mà agent phải tự thăm dò rủi ro trong mỗi lần gọi.

2. Phạm vi và giới hạn đặc tả (Scope and Non-goals)

Trong phạm vi (In scope):

• Thời gian phản hồi trên mỗi lần gọi (Per-invocation) đối với một tác vụ công cụ đơn lẻ.
• Cơ chế timeout được áp đặt bởi máy chủ (Server-imposed timeout semantics).
• Thời gian trễ đến byte đầu tiên (Time-to-first-byte) cho các kết nối streaming.
• Các trạng thái suy giảm (Degradation modes) làm biến đổi hồ sơ độ trễ.
• Phương pháp luận đo lường và tính cập nhật của dữ liệu khai báo.

Ngoài phạm vi (Non-goals):

• Các SLAs liên quan đến tính khả dụng hoặc thời gian hoạt động (uptime SLAs) (được định nghĩa ở một đặc tả riêng biệt).
• Các SLAs về chất lượng đầu ra, ranh giới độ chính xác, hoặc tỷ lệ ảo giác (hallucination rates).
• Cấu trúc chi phí hoặc ngân sách token.
• Độ trễ toàn trình của agent (End-to-end agent latency), vốn là tổng hợp của độ trễ mô hình, độ trễ công cụ, và độ trễ điều phối (orchestration latency).

3. Khối latency_disclosure

Đặc tả này là một đối tượng duy nhất. Các nhà phát hành công cụ CÓ THỂ bao gồm nó trực tiếp (inline) trong một manifest hoặc tham chiếu tới nó qua một URL. Tất cả các trường thời gian đều là số nguyên tính bằng mili-giây (milliseconds).

[[CODE_FENCE_LANG=yaml]]

latency_disclosure:

version: "1.0"

observed_at: "2026-04-22T00:00:00Z"

measurement_window_days: 7

sample_size: 12483

region: "us-east-1"

p50_ms: 180

p95_ms: 720

p99_ms: 1850

cold_start_ms: 1200

timeout_ms: 30000

idempotent: true

retry_safe: true

streaming: false

time_to_first_byte_ms: null

degradation_modes:

• trigger: "queue_depth>50"

behavior: "queue and serve"

expected_p95_ms: 4500

• trigger: "downstream_dependency_unavailable"

behavior: "fail fast with 503"

expected_p95_ms: 200

methodology_url: "https://example.com/latency-methodology"

[[/CODE_FENCE]]

3.1 Cấu trúc trường dữ liệu (Field Reference)

• version (chuỗi, bắt buộc) — Phiên bản Semver của lược đồ công bố. Tài liệu này định nghĩa chuẩn 1.0.
• observed_at (chuỗi ngày tháng theo chuẩn ISO-8601, bắt buộc) — Dấu thời gian kết thúc của cửa sổ đo lường.
• measurement_window_days (số nguyên, bắt buộc) — Độ dài của cửa sổ đo lường theo mô hình cuốn (rolling window). Giá trị KHUYẾN NGHỊ: 7 hoặc 30.
• sample_size (số nguyên, bắt buộc) — Tổng số lượng truy vấn được sử dụng để tính toán các phân vị (percentiles). PHẢI đạt tối thiểu 1,000 để giá trị p99_ms được công nhận tính hợp lệ.
• region (chuỗi, tùy chọn) — Định danh địa lý cụ thể của hệ thống server, đặc biệt cần thiết khi độ trễ có sự biến động lớn giữa các khu vực.
• p50_ms, p95_ms, p99_ms (số nguyên, bắt buộc) — Các phân vị thời gian phản hồi: trung vị (50%), 95%. Đồng thời, 99% tính bằng mili-giây, được đo lường tại phía máy chủ từ lúc tiếp nhận yêu cầu đến khi trả về byte dữ liệu cuối cùng.
• cold_start_ms (số nguyên, tùy chọn) — Giá trị độ trễ gia tăng bổ sung trong kịch bản khởi động lạnh (cold start). Bỏ qua trường này nếu công cụ duy trì trạng thái luôn khả dụng (warm-state only).
• timeout_ms (số nguyên, bắt buộc) — Ngưỡng ngắt kết nối tuyệt đối do máy chủ áp đặt (hard server-side cutoff). Các truy vấn vượt quá ngưỡng này BẮT BUỘC bị nhà phát hành hủy bỏ và trả về một mã lỗi timeout chuẩn hóa.
• idempotent (boolean, bắt buộc) — Khai báo về tính lũy đẳng: xác nhận việc thực thi lặp lại cùng một truy vấn có sinh ra cùng một hệ quả (side-effects) hay không.
• retry_safe (boolean, bắt buộc) — Xác nhận việc agent CÓ THỂ thực hiện thử lại (retry) một cách an toàn khi gặp lỗi giao thức truyền tải. Trường này có thể khác biệt với idempotent trong các kiến trúc đọc-sau-khi-ghi (read-after-write).
• streaming (boolean, bắt buộc) — Khai báo liệu công cụ có phản hồi dữ liệu theo định dạng luồng (streaming) hay không.
• time_to_first_byte_ms (số nguyên, bắt buộc có điều kiện) — Bắt buộc nếu streaming: true. Đại diện cho độ trễ p95 tính từ thời điểm gửi yêu cầu cho đến khi nhận được byte dữ liệu đầu tiên.
• degradation_modes (mảng, tùy chọn) — Danh mục các trạng thái hệ thống gây tác động tiêu cực đến cấu hình độ trễ. Mỗi đối tượng cấu trúc bao gồm trigger (tác nhân kích hoạt), behavior (hành vi hệ thống), và expected_p95_ms (độ trễ dự kiến).
• methodology_url (URL, tùy chọn) — Liên kết URL cung cấp tài liệu mô tả chi tiết phương pháp luận đo lường, bao gồm các tiêu chí cấu hình lọc và loại trừ (filtering/exclusion rules).

3.2 Bộ quy tắc xác thực (Validation Rules)

• p50_ms <= p95_ms <= p99_ms <= timeout_ms.
• Giá trị p99_ms * 1.2 NÊN thấp hơn timeout_ms. Mục đích là đảm bảo ngưỡng ngắt kết nối do nhà phát hành quy định không can thiệp vào biên độ phương sai vận hành tiêu chuẩn.
• Các bản khai báo có thời gian observed_at vượt quá 90 ngày so với thời gian vận hành hiện tại của agent BẮT BUỘC PHẢI bị coi là lỗi thời và vô hiệu (missing).
• Khi streaming: true, hệ thống BẮT BUỘC PHẢI cung cấp đồng thời cả time_to_first_byte_ms và p95_ms, trong đó yêu cầu tính logic: time_to_first_byte_ms <= p95_ms.

4. Nhúng khối này vào các bề mặt công cụ hiện tại

Khối dữ liệu này không phụ thuộc vào giao thức truyền tải. Các nhà áp dụng nhúng nó vào nơi mà chính công cụ đó được mô tả.

4.1 Model Context Protocol

MCP định nghĩa các chú thích (annotations) trên mỗi công cụ. Thêm khối này dưới dạng một chú thích có cấu trúc. Máy chủ MCP trả về nó trong phản hồi tools/list.

[[CODE_FENCE_LANG=json]]

{

"name": "search_docs",

"description": "Search documentation for a query.",

"inputSchema": { "...": "..." },

"annotations": {

"latencyDisclosure": {

"version": "1.0",

"p50_ms": 180,

"p95_ms": 720,

"p99_ms": 1850,

"timeout_ms": 30000,

"idempotent": true,

"retry_safe": true,

"streaming": false,

"observed_at": "2026-04-22T00:00:00Z",

"measurement_window_days": 7,

"sample_size": 12483

}

}

}

[[/CODE_FENCE]]

Việc này nhất quán với mẫu chú thích hiện có của MCP và không yêu cầu thay đổi giao thức nào.

4.2 OpenAI / Anthropic function calling

Lược đồ function-calling là JSON Schema. Hãy sử dụng một khóa mở rộng của nhà cung cấp (vendor extension key).

[[CODE_FENCE_LANG=json]]

{

"type": "function",

"function": {

"name": "search_docs",

"parameters": { "...": "..." },

"x-latency-disclosure": {

"version": "1.0",

"p95_ms": 720,

"...": "..."

}

}

}

[[/CODE_FENCE]]

Các khóa mở rộng của nhà cung cấp sẽ bị bỏ qua bởi những clients không hiểu chúng, điều này giữ cho công bố tương thích ngược.

4.3 OpenAPI

Đối với các công cụ có giao diện HTTP, đính kèm khối này dưới trường x-latency-disclosure ở mức độ hoạt động (operation level). Trường này nằm cạnh bất kỳ gợi ý hiệu suất hiện có nào trong các trường x-.

4.4 HTTP response header

Đối với các trường hợp hạng nhẹ (lightweight) khi một manifest là không thực tế, cùng một đối tượng JSON CÓ THỂ được trả về trong một tiêu đề phản hồi (response header) X-Tool-Latency-Disclosure được mã hóa base64 trong mỗi lần gọi. Điều này cho phép cập nhật động mà không cần phải lấy lại manifest.

5. Ứng dụng khai báo đối với Agent

Một agent tương tác hệ thống NÊN tận dụng cấu trúc khai báo này trong bốn kịch bản cốt lõi:

Tối ưu hóa định tuyến (Routing). Khi hệ thống ghi nhận nhiều công cụ thỏa mãn cùng một ý định (intent) truy vấn, agent sẽ ưu tiên chỉ định công cụ sở hữu thông số p95_ms thấp hơn. Đối với các luồng công việc khắt khe về thời gian thực, agent có quyền bỏ qua các công cụ có p99_ms vượt quá ngân sách độ trễ cho phép của người dùng.

Tính toán ngân sách thử lại (Retry Budgeting). Cấu hình thời hạn tối đa (deadline) cho mỗi lần gọi ở ngưỡng p99_ms * 1.2 thay vì phụ thuộc hoàn toàn vào timeout_ms của nhà phát hành. Chỉ cấp phát tài nguyên thử lại đối với các công cụ khai báo retry_safe: true. Ngăn chặn hoàn toàn các vòng lặp thử lại vô hạn đối với các công cụ cấu hình idempotent: false.

Xử lý song song (Parallelization). Khi phân bổ đồng thời (fanning out) các lệnh gọi công cụ độc lập, agent sử dụng p95_ms làm căn cứ ước tính thời gian hoàn tất tồi tệ nhất (worst-case fan-in time) của luồng xử lý. Kỹ thuật chạy song song là một thực hành tiêu chuẩn. Khối khai báo này sẽ hỗ trợ việc chuyển đổi các giả định song song hóa thành các dữ liệu định lượng chính xác.

Dự phóng độ trễ cho người dùng (User Latency Hinting). Giao diện tương tác CÓ THỂ hiển thị thời gian chờ dự kiến dựa trên p95_ms. Mục đích là thiết lập kỳ vọng trực quan minh bạch đối với người dùng cuối.

6. Phương pháp luận đo lường (Measurement Methodology)

Các nhà phát hành BẮT BUỘC PHẢI trích xuất các phân vị từ hệ thống đo lường từ xa trong môi trường vận hành thực tế (production telemetry), tuyệt đối không dùng các chỉ số benchmark giả lập tổng hợp. Quy trình đo lường được khuyến nghị:

1. Đo lường thời gian thực (wall-clock time) tại máy chủ, từ khoảnh khắc tiếp nhận yêu cầu đến khi xuất byte phản hồi cuối cùng.
2. Triển khai phương pháp cửa sổ cuốn (rolling window) với chu kỳ 7 hoặc 30 ngày, chốt dữ liệu tại thời điểm observed_at.
3. Yêu cầu tệp mẫu chứa tối thiểu 1,000 lượt truy vấn để đảm bảo tính hợp lệ của khai báo. Nếu không đủ mẫu, nhà phát hành phải kéo dài thời gian đo lường hoặc loại bỏ tham số p99_ms.
4. Lọc bỏ các cuộc gọi bị hủy do chạm mốc timeout_ms khỏi các phép tính p95_ms và p99_ms. Tỷ lệ hủy này nên được minh bạch trong tài liệu phương pháp luận nếu chiếm tỷ trọng đáng kể.
5. Loại trừ độ trễ đường truyền từ phía client. Bản công bố là một thỏa thuận dịch vụ (SLA) từ nhà phát hành; các yếu tố mạng nội bộ thuộc phạm vi giám sát của agent.
6. Phân vùng cấu hình theo khu vực địa lý (region) nếu ghi nhận mức chênh lệch p95_ms giữa các cụm máy chủ vượt mức 50%. Xây dựng các bản khai báo độc lập cho mỗi khu vực.

Các nhà phát hành NÊN cung cấp URL tĩnh (methodology_url) để tài liệu hóa quy trình tính toán, cụ thể hóa các luật lọc và loại bỏ số liệu. Khung chuẩn hóa mô hình chất lượng từ đề xuất AgentSLA là một khuôn mẫu chuẩn mực để xây dựng tài liệu này.

7. Phân loại trạng thái suy giảm hiệu năng (Degradation Mode Taxonomy)

Mảng degradation_modes cung cấp minh bạch về các kịch bản hành vi hệ thống thứ cấp. Các biến số trigger (tác nhân kích hoạt) tiêu chuẩn bao gồm:

• queue_depth>N — Khối lượng lệnh gọi đồng thời vượt quá ngưỡng giới hạn cấu hình.
• downstream_dependency_unavailable — Một dịch vụ nền tảng cấp thấp (upstream service) mất kết nối hoặc phản hồi lỗi.
• rate_limit — Cấu hình giới hạn tần suất (rate limiter) của nhà phát hành đã bị kích hoạt.
• cold_start — Hệ thống máy chủ đang khởi động lại từ trạng thái chưa sẵn sàng (cold state).
• large_payload — Quy mô dữ liệu đầu vào/đầu ra vượt quá giới hạn tải tối ưu.

Ứng với mỗi chế độ suy giảm, nhà phát hành cần khai báo hệ quả behavior (xếp hàng/queue, báo lỗi nhanh/fail fast, giảm chất lượng nội dung) và dự phóng expected_p95_ms trong điều kiện tương ứng. Đây là cơ sở dữ liệu quan trọng để agents quy hoạch chiến lược retry trong các sự cố hệ thống cục bộ (partial outages).

8. Quản lý phiên bản và tính toàn vẹn dữ liệu

• Tham số version phải tuân thủ chuẩn SemVer. Các bản cập nhật cấu trúc (như thay đổi tên/loại bỏ tham số) BẮT BUỘC PHẢI gia tăng phiên bản chính (major version).
• Các nhà phát hành NÊN làm mới (re-publish) dữ liệu khai báo với tần suất tối thiểu 30 ngày/lần. Đặc tả quy định một giới hạn vòng đời tuyệt đối (freshness ceiling) là 90 ngày. Quá thời hạn này, agents BẮT BUỘC PHẢI coi dữ liệu bị thiếu sót hoặc vô hiệu (missing).
• Các bản công bố NÊN tích hợp chữ ký số (signed) hoặc qua cơ chế xác thực toàn vẹn nếu chúng tham gia vào các quyết định định tuyến liên quan đến bảo mật (mặc dù chuẩn ký số hiện nằm ngoài phạm vi phiên bản 1.0).
• Khi một agent ghi nhận độ trễ thực tế liên tục cao hơn 50% so với mức p95_ms khai báo trong một chu kỳ đo lường đủ lớn, agent đó NÊN áp dụng hình phạt định tuyến (routing penalty) đối với công cụ đó cho đến khi xuất hiện một bản khai báo được cập nhật.

9. Mối quan hệ với các tiêu chuẩn hiện tại

Đặc tả này cố tình tái sử dụng, thay vì thay thế, các nền tảng xung quanh nó.

• ISO/IEC 25010 — Hiệu năng (Performance efficiency). Khối dữ liệu cung cấp điểm nạp cho nhánh đặc tính time-behaviour bằng những số liệu đo lường cụ thể.
• Tiện ích mở rộng của nhà cung cấp OpenAPI (OpenAPI vendor extensions). Cơ chế OpenAPI hỗ trợ thêm phần thuộc tính cho nhà cung cấp vốn dĩ đã là vùng vận tải tự nhiên (natural transport) cho các công cụ dạng HTTP.
• MCP annotations. MCP vốn đã cho phép đánh dấu chú thích (annotations) có cấu trúc bất kỳ trên các công cụ, nên chẳng đòi hỏi việc thay đổi nguyên tắc cơ bản ở phía protocol.
• AgentSLA quality model. AgentSLA vốn vạch ra các đặc tính chất lượng cấp cao. Đặc tả của bản này lại đóng vai như một giao diện vận chuyển thực tiễn trên mạng lưới (on-the-wire implementation) đại diện cho một mảng của thứ đó.
• OpenTelemetry / observability conventions. Các nhà phân phối giải pháp quan trắc (observability vendors) dẫu sao cũng đã nắm bắt con số độ trễ trên mỗi công cụ ở nhánh agent phía họ. Khối công bố (disclosure block) này châm ngòi cầu nối cho các nhà cung cấp nền tảng cùng với kẻ tiêu thụ rắp tay đếm so số theo một quy chiếu ngôn từ phân vị chung xài mượt.

10. Danh sách kiểm tra triển khai (Adoption Checklist)

Yêu cầu đối với nhà phát hành công cụ (Tool Publishers):

• Tích hợp khối latency_disclosure vào mọi công cụ được triển khai ra công chúng (public tool manifests).
• Trích xuất dữ liệu phân vị dựa trên chu kỳ lưu trữ tối thiểu 7 ngày, sử dụng tệp dữ liệu đạt ít nhất 1,000 mẫu đo lường từ môi trường production.
• Cấu hình chỉ số timeout_ms ở mức bằng hoặc cao hơn p99_ms * 1.2.
• Tài liệu hóa minh bạch các chế độ suy giảm hiệu năng (degradation modes) đối với các kịch bản quá tải hàng đợi (queue depth), giới hạn tỷ lệ (rate limit). Đồng thời, độ trễ khởi động lạnh (cold start) nếu có.
• Thiết lập quy trình tự động cập nhật (re-publish) khai báo với tần suất tối thiểu 30 ngày/lần.

Yêu cầu đối với đội ngũ phát triển Agent và Hệ thống điều phối (Agent & Orchestrator Authors):

• Phân tích khối khai báo ngay tại giai đoạn khám phá công cụ (tool discovery), không lặp lại truy vấn ở mỗi lệnh gọi độc lập.
• Thiết lập ngưỡng thời hạn (deadline) cho mỗi lần gọi dựa trên tỷ lệ p99_ms * 1.2.
• Tuân thủ chặt chẽ các giới hạn rủi ro từ cờ retry_safe và idempotent khi quy hoạch chiến lược thử lại (retries).
• Xử lý các bản khai báo có observed_at vượt quá 90 ngày như dữ liệu không tồn tại hoặc lỗi thời (missing).
• Tận dụng thông số p95_ms để hiển thị gợi ý dự kiến (latency hints) trên các giao diện người dùng.

FAQ

Q: Tại sao đặc tả yêu cầu các mốc phân vị p50, p95, và p99 thay vì sử dụng chỉ số trung bình (average)?

A: Thông số trung bình (average) làm ẩn đi các vấn đề độ trễ theo mô hình đuôi dài (long-tail latency), vốn là nguyên nhân chính gây lỗi trên kiến trúc agent. Chỉ số p95 cung cấp cái nhìn thực tế về trải nghiệm của 5% truy vấn tồi tệ nhất. Trong khi p99 là thông số quan trọng nhằm thiết lập cơ chế timeout an toàn để tránh hiệu ứng sụp đổ dây chuyền (cascade failures). p50 (trung vị) cung cấp dự phóng cơ bản (baseline expectations) cho người dùng, nhưng để tối ưu hóa quyết định định tuyến thì các mốc p95 và p99 là cơ sở hạ tầng thiết yếu.

Q: Các chỉ số này nên được lấy từ hệ thống đo lường nào?

A: Dữ liệu BẮT BUỘC phải được tổng hợp từ telemetry trong môi trường vận hành thực tế (production) do phía máy chủ của nhà phát hành ghi nhận. Các báo cáo đo kiểm giả lập (synthetic benchmarks) không phản ánh đầy đủ tác động tiêu cực của các yếu tố hệ thống thực tế như độ tải hàng đợi (queue depth), hiệu suất bộ nhớ đệm (cache misses), hoặc ảnh hưởng từ độ trễ mạng (noisy neighbors). Nhà phát hành NÊN công bố URL phương pháp luận đo lường để làm rõ khung thời gian tính toán, các tham số loại trừ. Đồng thời, độ lớn của tập dữ liệu mẫu.

Q: Khối khai báo này tích hợp với giao thức Model Context Protocol như thế nào?

A: Bản công bố này hoạt động như một chú thích có cấu trúc (structured annotation) được đính kèm vào cấp độ công cụ bên trong MCP. Giao thức MCP hỗ trợ mở rộng thông qua các tệp metadata tùy biến mà không gây phá vỡ khả năng tương thích ngược (backward-compatibility), do đó việc áp dụng chuẩn này không yêu cầu thay đổi cốt lõi trong kiến trúc giao thức MCP hiện tại.

Q: Nếu một công cụ gần như không có độ trễ thay đổi (latency variance) thì triển khai như thế nào?

A: Nhà phát hành vẫn tiếp tục duy trì cấu trúc khai báo với đầy đủ p50_ms, p95_ms, và p99_ms. Đối với các công cụ có thời gian phản hồi ổn định (essentially constant), ba giá trị phân vị này sẽ hội tụ lại với nhau (cluster together). Ngay cả kết quả định lượng về sự hội tụ này cũng là một tín hiệu giá trị, xác nhận tính ổn định cao của công cụ đối với các agents đang tiêu thụ.

Q: Liệu đặc tả này có thay thế các tài liệu SLA về tính sẵn sàng (Availability) không?

A: Không. Độ khả dụng (Availability) và tính sẵn sàng phải được xử lý ở một đặc tả kỹ thuật riêng biệt. Một hệ thống công cụ có tính khả dụng cao có thể vẫn đi kèm độ trễ phản hồi quá ngưỡng, hoặc một công cụ có tốc độ phản hồi tối ưu lại thiếu độ ổn định thời gian hoạt động (uptime). Agents cần theo dõi độc lập cả hai hệ quy chiếu này để giải quyết các cấu trúc điều phối và phân mảnh tài nguyên khác nhau.

Q: Các nhà phát hành nên cập nhật khối khai báo này với tần suất bao lâu?

A: Khuyến nghị chuẩn mực là tự động làm mới số liệu 30 ngày/lần. Đồng thời, cập nhật ngay lập tức nếu có thay đổi kiến trúc hạ tầng làm dịch chuyển vĩnh viễn cấu hình hiệu năng. Một bản khai báo có dữ liệu lịch sử vượt quá 90 ngày tự động bị phân loại là hết hạn (missing) theo quy định định tuyến của đặc tả này.