MCP và Agent2Agent (A2A): Hai lớp giao thức bổ trợ cho hệ sinh thái đa tác nhân (multi-agent)

Hệ sinh thái đa tác nhân (multi-agent) chỉ thật sự tạo ra giá trị kinh tế bền vững khi các nhà quản trị công nghệ phân định rạch ròi ba loại quan hệ tương tác cốt lõi. Mối quan hệ thứ nhất là khi một tác nhân AI cần gọi một năng lực nghiệp vụ cụ thể như tra cứu hồ sơ khách hàng, tính toán báo giá, đọc cơ sở tri thức nội bộ hoặc tự động tạo phiếu hỗ trợ; giao thức MCP là lựa chọn tối ưu để chuẩn hóa các công cụ, nguồn tài nguyên, mẫu câu lệnh và cơ chế phân quyền ở tầng này. Mối quan hệ thứ hai là khi một tác nhân AI ủy thác toàn bộ một mục tiêu công việc cho một tác nhân độc lập khác, theo dõi tiến độ trạng thái, cung cấp thêm thông tin đầu vào khi được yêu cầu và tiếp nhận sản phẩm bàn giao cuối cùng; đây chính là không gian vận hành chuyên biệt của giao thức A2A. Mối quan hệ thứ ba là giữa các tác nhân phụ (sub-agent) cùng vận hành trong một môi trường thực thi và chia sẻ chung một ranh giới tin cậy; trường hợp này chỉ cần dùng các khung phần mềm nội bộ thông thường là đủ. Việc lạm dụng A2A cho mọi hàm chức năng sẽ làm phát sinh trạng thái rườm rà và chi phí không cần thiết; ngược lại, việc gượng ép một đối tác tự chủ thành một lượt gọi công cụ đơn thuần sẽ làm triệt tiêu hoàn toàn ngữ nghĩa của việc ủy quyền, quản trị vòng đời và phân định trách nhiệm giải trình.

Đặc tả A2A phiên bản v1.0.0 cấu trúc giao thức thành ba tầng rõ ràng: mô hình dữ liệu, các thao tác trừu tượng và các phương thức gắn kết kỹ thuật (protocol bindings). Thẻ mô tả tác nhân (Agent Card) công bố công khai các giao diện kết nối, năng lực xử lý, danh mục kỹ năng, cơ chế bảo mật và các tiện ích mở rộng được hỗ trợ. Mỗi thông điệp (Message) có thể chứa nhiều phần nội dung (Part) dưới dạng văn bản thuần túy, tệp tin nhị phân hoặc dữ liệu có cấu trúc. Một thao tác gửi thông điệp (SendMessage) có thể trả về ngay một thông điệp phản hồi trực tiếp khi tương tác không đòi hỏi lưu giữ trạng thái, hoặc chủ động khởi tạo một nhiệm vụ (Task) khi khối lượng công việc kéo dài và cần theo dõi tiến độ. Nhiệm vụ sẽ chuyển dịch tuần tự qua các trạng thái xác định, có thể tạm dừng để chờ người dùng cung cấp thêm dữ liệu đầu vào hoặc chờ phê duyệt thẩm quyền, liên tục phát tín hiệu cập nhật qua cơ chế truyền luồng hoặc thông báo đẩy, và bàn giao sản phẩm đầu ra (Artifact). Các giao thức JSON-RPC, gRPC cùng HTTP+JSON/REST chỉ là những phương thức kỹ thuật để hiện thực hóa các ngữ nghĩa nghiệp vụ này; trong đó tệp định nghĩa a2a.proto giữ vai trò là chuẩn mực thẩm quyền cao nhất quy định cấu trúc đối tượng dữ liệu cũng như khuôn dạng yêu cầu và phản hồi.

Kiến trúc công nghệ chuẩn mực của doanh nghiệp nên bố trí giao thức A2A tại tầng tương tác (interaction plane) giữa các hệ thống tác nhân độc lập với nhau, đồng thời đặt giao thức MCP tại tầng năng lực (capability plane) bên dưới phục vụ riêng cho từng tác nhân; trong khi đó các lớp quản trị định danh, chính sách an ninh và đồ thị bằng chứng phải được thiết lập xuyên suốt cả hai tầng này. Lấy ví dụ: một tác nhân phụ trách mua hàng có thể giao nhiệm vụ thẩm định năng lực nhà cung cấp cho tác nhân của đối tác thông qua giao thức A2A; sau đó, tác nhân đối tác sẽ sử dụng MCP để tra cứu quy chế nội bộ, truy xuất các nguồn dữ liệu bảo mật và kích hoạt các công cụ phân tích riêng của họ. Tuyệt đối không có bất kỳ mã khóa truy cập (token) nào được phép chuyển tiếp tùy tiện qua các ranh giới hệ thống. Mỗi chặng kết nối trung gian (hop) đều bắt buộc phải xác thực độc lập về chủ thể thực tế, đối tượng tiếp nhận quyền hạn, không gian khách hàng, phạm vi thao tác, mục đích xử lý hợp pháp và ranh giới bảo vệ dữ liệu riêng biệt. Mã tương quan liên kết giúp kết nối và truy vết toàn bộ chuỗi mắt xích sự vụ, nhưng tuyệt đối không bao giờ được biến mã truy vết (trace ID), mã ngữ cảnh hay mã nhiệm vụ thành thông tin xác thực đăng nhập thay thế.

Rủi ro lớn nhất trong các hệ sinh thái đa tác nhân không nằm ở cú pháp kỹ thuật của giao thức, mà nằm ở sự buông lỏng các ranh giới tin cậy. Một thẻ Agent Card trôi nổi trên mạng chỉ là một khối dữ liệu chưa được kiểm chứng; phần mô tả kỹ năng hấp dẫn không đồng nghĩa với quyền hạn được phép thực thi; và trạng thái báo 'đã hoàn thành' từ một tác nhân từ xa hoàn toàn không phải là bằng chứng cho thấy kết quả nghiệp vụ đã đạt chuẩn. Doanh nghiệp bắt buộc phải thiết lập một danh mục đăng ký tác nhân đã được phê duyệt chính thức, kiểm chứng chặt chẽ đầu mối kết nối và tư cách nhà cung cấp, vận hành máy trạng thái nhiệm vụ chặt chẽ, phân quyền chi tiết tới từng đối tượng dữ liệu, bảo đảm tính chống trùng lặp, cô lập tuyệt đối dữ liệu giữa các khách hàng, kiểm duyệt an toàn nội dung, quy định tiêu chí nghiệm thu sản phẩm đầu ra, thiết lập điểm phê duyệt của con người và đối soát định kỳ với hệ thống sổ sách kế toán cốt lõi. Cơ chế truyền luồng dữ liệu phải có khả năng chống chịu sự cố mất kết nối mạng, xử lý trùng gói tin hoặc dữ liệu đến sai thứ tự; các thông báo đẩy bắt buộc phải có chữ ký số hoặc xác thực qua giao thức mTLS, phòng chống tấn công gửi lại (replay), ngăn chặn tấn công giả mạo yêu cầu từ máy chủ (SSRF) và bảo đảm việc chuyển phát thông báo không bị trùng lặp.

Lộ trình triển khai đúng đắn luôn bắt đầu bằng một mô hình cộng tác có tính chất đọc dữ liệu nhiều và ghi dữ liệu ít, sử dụng bộ dữ liệu giả lập hoặc dữ liệu đã được làm mờ cẩn thận, chỉ áp dụng cho một thẻ Agent Card duy nhất, một luồng xử lý nhiệm vụ cụ thể và sản phẩm bàn giao có cấu trúc dữ liệu gọn nhẹ. Giai đoạn chạy thử nghiệm cần đặt giao thức A2A lên bàn cân so sánh trực tiếp với các giải pháp gọi API thông thường, tích hợp MCP hoặc các luồng tự động hóa truyền thống không dùng AI, dựa trên cùng một hệ tiêu chí đo lường khắt khe: chất lượng đầu ra, thời gian hoàn tất, chi phí tài nguyên, mức độ rủi ro và nỗ lực vận hành thực tế. Doanh nghiệp chỉ nên xem xét mở rộng quy mô khi và chỉ khi tính tự chủ của tác nhân từ xa chứng minh được những lợi ích kinh tế vượt trội so với các chi phí phải bỏ ra để duy trì trạng thái, thiết lập ranh giới tin cậy và bảo đảm tính tương thích giữa các hệ thống. Mọi chỉ tiêu mục tiêu về tỷ suất hoàn vốn (ROI), độ trễ phản hồi hay tỷ lệ tự động hóa được đề cập trong tài liệu này đều chỉ là những giả thuyết làm việc ban đầu cần được đối chiếu với mốc đo thực tế và kiểm chứng độc lập; bản thân một đặc tả kỹ thuật không bao giờ mặc nhiên bảo đảm được sự thành công về mặt kinh tế cho doanh nghiệp.

Mục tiêu tối thượng của kiến trúc doanh nghiệp không phải là tạo ra một mạng lưới nơi các tác nhân AI liên tục trò chuyện qua lại càng nhiều càng tốt. Mục tiêu cốt lõi là xây dựng một hệ thống có các ranh giới kiểm soát rành mạch: tác nhân nào được phép tìm kiếm và kết nối, ai được quyền ủy thác công việc, dữ liệu nào được phép chia sẻ qua lại, công cụ nào được phép kích hoạt, ai là người chịu trách nhiệm pháp lý cuối cùng về kết quả, sản phẩm đầu ra nào đủ tiêu chuẩn được nghiệm thu và chuỗi bằng chứng nào cho phép doanh nghiệp điều tra sự cố hoặc thu hồi quyền hạn kịp thời. Khi những câu hỏi quản trị căn bản này chưa có lời giải đáp rõ ràng, việc vội vàng triển khai A2A sẽ chỉ làm trầm trọng thêm sự hỗn loạn và mất kiểm soát. Ngược lại, một khi tổ chức đã thiết lập vững chắc tầng kiểm soát an ninh và đồ thị bằng chứng toàn trình, thì sự kết hợp hài hòa giữa MCP và A2A sẽ kiến tạo nên một kiến trúc phần mềm dạng mô-đun linh hoạt—nơi mọi năng lực nghiệp vụ đều được tái sử dụng tối đa nhưng quyền lực tự trị của AI luôn bị giới hạn trong hành lang an toàn nghiêm ngặt.

Sai lầm phổ biến hàng đầu là việc lạm dụng nhãn 'tác nhân AI' như một kiểu định danh kỹ thuật chung chung. Một dịch vụ phần mềm đơn giản bọc quanh một hàm tra cứu dữ liệu đôi khi cũng bị gọi nhầm là tác nhân, trong khi một tác nhân AI thực thụ của đối tác lại có khả năng chủ động lập kế hoạch xử lý, yêu cầu cung cấp thêm thông tin và tự lựa chọn công cụ thực thi. Nếu cả hai đối tượng hoàn toàn khác biệt này đều bị nhồi nhét chung vào một giao diện kỹ thuật, ứng dụng máy khách sẽ không thể biết nên chờ đợi một phản hồi tức thì trong vài mili-giây hay một nhiệm vụ phức tạp kéo dài nhiều giờ, việc thử lại yêu cầu khi mất kết nối có an toàn hay không, và kết quả trả về chỉ là thông tin tham khảo thuần túy hay một sản phẩm đầu ra cần con người phê duyệt. Hồ sơ quyết định kiến trúc bắt buộc phải phân loại rõ ràng mức độ tự chủ, khả năng lưu giữ trạng thái, thời gian xử lý dự kiến, năng lực thương lượng, quyền sở hữu, tác động làm thay đổi dữ liệu nghiệp vụ và ranh giới tin cậy trước khi quyết định lựa chọn giao thức MCP, A2A, gọi API trực tiếp hay sử dụng các khung phần mềm nội bộ.

Vấn đề nghiêm trọng thứ hai là việc đánh đồng giữa khả năng tìm kiếm dịch vụ với mức độ tin cậy an toàn. Một thẻ mô tả tác nhân (Agent Card) có thể chứa tên thương hiệu uy tín, danh mục kỹ năng hấp dẫn, đường dẫn URL hợp lệ và cấu hình bảo mật đúng chuẩn cú pháp, nhưng trên thực tế lại xuất phát từ một tên miền đã bị chiếm đoạt, một nhà cung cấp chưa qua thẩm định an ninh mạng hoặc một đầu mối mạng có hành vi chuyển hướng độc hại. Bản thân chiếc thẻ mô tả không bao giờ cấp bất kỳ quyền hạn nào và cũng không thể chứng minh được năng lực thực tế của tác nhân. Danh mục đăng ký tác nhân của doanh nghiệp bắt buộc phải lưu giữ định danh nhà cung cấp chuẩn mực, hồ sơ xác minh quyền sở hữu, hợp đồng dịch vụ ràng buộc, khu vực lưu trữ dữ liệu, số hiệu phiên bản, kết quả đánh giá an toàn thông tin, cam kết hỗ trợ kỹ thuật, danh sách kỹ năng được phép kích hoạt và thời hạn hết hiệu lực. Mọi thẻ Agent Card mới xuất hiện hoặc có sự thay đổi quan trọng đều phải trải qua quy trình cách ly tạm thời, đối chiếu sự khác biệt và rà soát chuyên sâu; các ứng dụng máy khách chỉ được phép kết nối với những tác nhân nằm trong danh mục đã được phê duyệt chính thức.

Vấn đề thứ ba là việc quản lý trạng thái nhiệm vụ bị triển khai một cách cẩu thả như một cột văn bản tự do trong cơ sở dữ liệu. Khi các trạng thái nghiệp vụ như đã gửi yêu cầu, đang xử lý, cần thêm thông tin đầu vào, cần xác thực quyền hạn, đã hoàn thành, đã hủy bỏ, bị từ chối và thất bại không được quản lý bằng một bảng chuyển dịch trạng thái tất định, hai bên hệ thống sẽ xử lý việc thử lại lệnh và hủy bỏ nhiệm vụ theo những cách thức hoàn toàn xung đột nhau. Một thông báo trạng thái đến muộn có thể khiến tiến độ bị kéo lùi về quá khứ một cách vô lý; việc hết thời gian chờ có thể kích hoạt tạo ra hàng loạt nhiệm vụ trùng lặp; và trạng thái hoàn thành có thể bị ghi nhận ngay cả khi tệp sản phẩm bàn giao chưa hề được truyền tải trọn vẹn. Máy trạng thái chuẩn mực đòi hỏi phải ghi nhận rõ tác nhân thực hiện, lý do chuyển dịch, số thứ tự tuần tự của phiên bản, dấu thời gian chính xác, các quy tắc cho trạng thái kết thúc, cơ chế kiểm soát tương tranh và quy trình đối soát dữ liệu. Mọi kịch bản khởi động lại hệ thống, nhận trùng sự kiện, sự kiện đến sai thứ tự, thông báo đến trễ hay thao tác hủy lệnh đồng thời đều bắt buộc phải có các bài kiểm thử tự động chuyên biệt.

Vấn đề thứ tư là tình trạng định danh bị san phẳng một cách nguy hiểm xuyên suốt chuỗi ủy quyền tác vụ. Việc người dùng đăng nhập thành công vào tác nhân A hoàn toàn không đồng nghĩa với việc mã khóa xác thực của họ được phép chuyển tiếp nguyên vẹn sang tác nhân B hoặc máy chủ MCP C phía sau. Lối làm tắt chuyển tiếp mã truy cập tùy tiện sẽ dẫn đến lỗ hổng tấn công lợi dụng ủy quyền (confused deputy) và làm rò rỉ phạm vi đối tượng tiếp nhận quyền hạn (audience). Mỗi ranh giới mạng bắt buộc phải áp dụng cơ chế định danh tải công việc (workload identity) hoặc luồng ủy quyền danh nghĩa (on-behalf-of) được thiết kế bài bản, ràng buộc phạm vi đối tượng đúng với tài nguyên đích, tuân thủ nguyên tắc phân quyền tối thiểu và ghi nhận rành mạch cả tác nhân thực thi lẫn chủ thể ủy quyền thực tế. Cần khẳng định rõ: mã nhiệm vụ, mã ngữ cảnh, đường định tuyến không gian khách hàng, tiêu đề truy vết hay tên thẻ Agent Card thuần túy chỉ là những trường dữ liệu thông tin; tuyệt đối không có bất kỳ đối tượng nào trong số đó có khả năng tự động xác thực danh tính người gọi hay thay thế cho các quyết định thực thi chính sách an ninh tại thời điểm xử lý.

Vấn đề thứ năm là sự chủ quan coi thông điệp (Message), các phần nội dung (Part) và sản phẩm bàn giao (Artifact) mặc nhiên là các tệp văn bản an toàn. Dữ liệu tiếp nhận từ một tác nhân bên ngoài vẫn hoàn toàn có thể cài cắm các câu lệnh tấn công ngầm (prompt injection), chứa tệp mã độc, dẫn chiếu các đường dẫn nguy hiểm gây tấn công giả mạo yêu cầu từ máy chủ (SSRF), phá vỡ cấu trúc dữ liệu, mang theo lượng dữ liệu cá nhân dư thừa hoặc chứa nội dung vi phạm bản quyền. Dữ liệu văn bản từ bên ngoài tuyệt đối không bao giờ được phép tự động nâng cấp thành các mệnh lệnh điều khiển đáng tin cậy; các tệp tin đính kèm bắt buộc phải qua danh sách định dạng cho phép, sử dụng đường dẫn có chữ ký số xác thực, kiểm tra mã băm toàn vẹn, quét mã độc tự động, mở trong môi trường cách ly an toàn và có thời hạn hết hiệu lực cụ thể; dữ liệu có cấu trúc phải được kiểm tra chặt chẽ theo cấu trúc dữ liệu và số hiệu phiên bản. Mỗi sản phẩm bàn giao (Artifact) bắt buộc phải xác định rõ đơn vị sản xuất, nhiệm vụ nguồn phát sinh, chữ ký bảo đảm tính toàn vẹn, mức độ nhạy cảm thông tin, thời hạn lưu giữ và trạng thái nghiệm thu chính thức. Một bản dự thảo do tác nhân AI tạo ra tuyệt đối không bao giờ được phép tự động biến thành một hợp đồng pháp lý, một quyết định cấp tín dụng hay một lệnh mua hàng chính thức khi chưa có sự phê duyệt của con người.

Vấn đề thứ sáu là các cơ chế truyền luồng dữ liệu (streaming) và thông báo đẩy (push) thường chỉ được trình diễn trong các kịch bản lý tưởng hoàn hảo. Trên thực tế vận hành mạng phức tạp, luồng truyền tải dữ liệu rất dễ bị máy chủ ủy thác đệm lại gây gián đoạn, mã truy cập hết hạn giữa chừng, máy khách phải liên tục kết nối lại, và các mảnh dữ liệu nhỏ (chunks) bị gửi trùng lặp hoặc đến sai lệch trật tự thời gian. Cơ chế đẩy thông báo qua webhook rất dễ bị kẻ xấu tấn công gửi lại (replay), chuyển hướng lưu lượng độc hại vào mạng nội bộ hoặc gửi nhầm dữ liệu sang không gian khách hàng khác. Phía hệ thống tiếp nhận bắt buộc phải có thuật toán hợp nhất dữ liệu bảo đảm tính chống trùng lặp dựa trên số thứ tự phiên bản, chủ động truy vấn lại trạng thái nhiệm vụ hiện hành để đối soát và tuyệt đối không bao giờ sử dụng một tệp sản phẩm bàn giao mới tải được một phần như một sản phẩm hoàn thiện. Các đầu mối nhận phản hồi (callback endpoint) bắt buộc phải chạy trên giao thức mã hóa HTTPS, xác minh quyền sở hữu tên miền, đưa vào danh sách cho phép an toàn, xác thực danh tính hai chiều, sử dụng số dùng một lần (nonce) kèm dấu thời gian, thiết lập hàng đợi xử lý lỗi và thử lại, quy định thời hạn hết hạn và trang bị công tắc ngắt khẩn cấp. Cơ chế thăm dò định kỳ an toàn (polling) vẫn luôn là phương án dự phòng bắt buộc phải có khi luồng truyền tải thời gian thực bị tê liệt.

Vấn đề thứ bảy là các doanh nghiệp thường đo lường sai lệch bằng cách đếm tỷ lệ thành công của các yêu cầu kỹ thuật thay vì đo lường mức độ hoàn tất của kết quả kinh doanh thực tế. Một tác nhân AI từ xa có thể báo trạng thái hoàn thành ngay sau khi vừa sinh xong một tệp báo cáo, nhưng trên thực tế người dùng nghiệp vụ chưa hề chấp nhận bản thảo đó, dữ liệu ở các hệ thống phía dưới chưa được ghi nhận chính thức vào cơ sở dữ liệu hoặc giao dịch đã bị hủy đảo chiều sau đó. Các chỉ tiêu cam kết chất lượng dịch vụ (SLO) bắt buộc phải bóc tách độc lập giữa giai đoạn tìm kiếm dịch vụ, xác thực danh tính, tiếp nhận thông điệp, độ tươi mới của tiến độ xử lý, tính toàn vẹn của sản phẩm bàn giao, quyết định nghiệm thu chính thức và việc quyết toán giao dịch cuối cùng. Đồ thị bằng chứng (evidence graph) sẽ kết nối xuyên suốt các tầng này và quy trình đối soát định kỳ sẽ xác nhận kết quả kinh doanh thực tế cuối cùng. Nếu hệ thống giám sát đo lường từ xa chỉ dừng lại ở việc đếm các mã phản hồi HTTP 200 thành công hay các trạng thái kết thúc kỹ thuật, thì mọi tuyên bố về tỷ suất hoàn vốn (ROI) và độ tin cậy của hệ thống đều chứa đựng những lỗ hổng nghiêm trọng.

Vấn đề cuối cùng là sự nóng vội mở rộng quy mô trước khi chứng minh được giá trị thực tế về mặt ngữ nghĩa nghiệp vụ. Nhiều đội ngũ kỹ sư vội vã bật các tính năng định tuyến động phức tạp, phân tán xử lý đồng thời ra hàng loạt luồng và cho phép các tác nhân tự động ủy quyền chéo cho nhau chỉ vì những màn trình diễn công nghệ ấn tượng; để rồi sau đó doanh nghiệp phải gánh chịu những vòng lặp xử lý vô tận, chi phí tài nguyên bùng nổ không giới hạn, rơi vào bẫy phụ thuộc nhà cung cấp công nghệ và đối mặt với hàng loạt sự cố nghiêm trọng không ai đứng ra chịu trách nhiệm. Dự án chạy thử nghiệm ban đầu cần được chủ động thu hẹp phạm vi ở mức tối giản: một đối tác duy nhất, một kỹ năng chuyên biệt, một phương thức kết nối kỹ thuật, một luồng chuyển dịch trạng thái nhiệm vụ rõ ràng và giảm thiểu tối đa các tác động làm thay đổi dữ liệu nghiệp vụ. Luôn so sánh hiệu quả của mô hình này với các giải pháp có mức độ tự chủ thấp hơn. Nếu việc gọi trực tiếp API hoặc sử dụng công cụ MCP thông thường có thể đạt được cùng một kết quả công việc với khả năng kiểm soát an toàn cao hơn, thì hoàn toàn không có bất kỳ lý do kiến trúc chính đáng nào để ép buộc hệ thống phải áp dụng giao thức A2A.

Bốn ranh giới không được làm mờ

• ⦿Khám phá không đồng nghĩa với sự tin cậy hoặc quyền truy cập.
• ⦿Mã tác vụ (Task ID) và mã ngữ cảnh (Context ID) không phải là định danh bảo mật.
• ⦿Tác nhân báo hoàn thành không đồng nghĩa kết quả đầu ra đã được nghiệm thu.
• ⦿Ủy quyền qua A2A không cho phép chuyển tiếp token của người dùng xuống công cụ MCP.

1. Quyết định kiến trúc bắt buộc phải khởi đầu bằng việc phân loại bản chất tương tác nghiệp vụ. Nếu một thành phần phần mềm cung cấp một hàm chức năng có dữ liệu đầu vào và đầu ra xác định, vận hành độc lập trạng thái và không có nhu cầu tự thương lượng quy trình, hãy cấu hình nó như một công cụ hoặc tài nguyên thông qua giao thức MCP. Nếu hệ thống đối tác đại diện cho một năng lực nghiệp vụ độc lập, có quyền từ chối yêu cầu, chủ động hỏi thêm thông tin, thực hiện tác vụ kéo dài nhiều giờ, bàn giao các tệp sản phẩm hoàn chỉnh và tự quản lý vòng đời nhiệm vụ, thì giao thức A2A chắc chắn là lựa chọn phù hợp hơn. Đối với các tác nhân phụ nội bộ cùng chạy trong một môi trường thực thi, doanh nghiệp nên tận dụng các khung phần mềm sẵn có, tránh việc giao thức hóa một cách cứng nhắc cho mọi hàm chức năng. Bảng ma trận phân loại cần ghi nhận rõ: quyền sở hữu, ranh giới tin cậy, mức độ tự chủ, thời gian xử lý, phương thức truyền tải, máy trạng thái, cơ chế xử lý lỗi và nhật ký kiểm tra. Luôn lựa chọn giao thức dựa trên ngữ nghĩa nghiệp vụ thực tế chứ không dựa vào danh xưng 'tác nhân'. Một tác nhân từ xa vẫn có thể công bố một vài thao tác cơ bản qua MCP; điều then chốt là ranh giới kiến trúc phải luôn nhất quán để ứng dụng máy khách không nhầm lẫn giữa một nhiệm vụ kéo dài với một lượt gọi công cụ tức thì.

2. Mô hình phân tầng kiến trúc bóc tách hệ thống thành ba mặt phẳng độc lập. Tầng tương tác A2A kết nối các hệ thống tác nhân theo chiều ngang xuyên suốt ranh giới tổ chức và sản phẩm; tầng năng lực MCP kết nối từng tác nhân theo chiều dọc xuống các công cụ, nguồn tài nguyên và mẫu câu lệnh; trong khi tầng điều phối nội bộ do các khung phần mềm chuyên dụng đảm nhiệm. Các lớp quản trị định danh, chính sách an ninh và đồ thị bằng chứng vận hành xuyên suốt cả ba mặt phẳng này, nhưng các mã khóa truy cập (token), phạm vi đối tượng và bản ghi nhật ký không mặc nhiên tương thích tự động với nhau. Quá trình ủy quyền qua A2A tuyệt đối không được phép chuyển tiếp nguyên vẹn mã khóa của người dùng cuối xuống các máy chủ MCP phía sau. Tác nhân từ xa phải xác thực và phân quyền cho yêu cầu tiếp nhận, sau đó sử dụng thông tin đăng nhập dịch vụ riêng hoặc luồng ủy quyền danh nghĩa (on-behalf-of) được thiết kế bài bản để gọi máy chủ MCP. Mỗi chặng kết nối trung gian (hop) đều phải xác định rõ chủ thể ủy quyền, tác nhân thực thi, mục đích sử dụng và tài nguyên đích. Mã tương quan liên kết chặt chẽ chuỗi sự vụ từ nhiệm vụ, thông điệp, sản phẩm bàn giao đến từng lượt gọi MCP, nhưng tuyệt đối không biến mã truy vết (trace ID) thành chứng thư phân quyền. Mọi sự cố phát sinh tại tầng công cụ MCP phải được tác nhân xử lý nội bộ trước khi phản ánh chính xác lên trạng thái nhiệm vụ và các điều khoản cảnh báo đi kèm.

3. Đặc tả A2A phiên bản v1.0 bao gồm mô hình dữ liệu chuẩn, các thao tác trừu tượng và các phương thức gắn kết giao thức. Tệp a2a.proto là định nghĩa quy chuẩn có thẩm quyền cao nhất cho toàn bộ các đối tượng và khuôn dạng yêu cầu; các tài liệu hướng dẫn chỉ đóng vai trò giải thích ngữ nghĩa. Ba phương thức gắn kết gồm JSON-RPC, gRPC và HTTP+JSON/REST đều ánh xạ chung tới cùng một tập hợp thao tác nghiệp vụ, chứ không phải là ba sản phẩm công nghệ độc lập khác nhau. Đội ngũ triển khai có thể tự do lựa chọn phương thức gắn kết phù hợp với hệ sinh thái nội bộ, nhưng bảng ma trận tương thích và tính toàn vẹn ngữ nghĩa nội dung bắt buộc phải được duy trì nghiêm ngặt. Tuyệt đối không tuần tự hóa dữ liệu rồi tùy tiện loại bỏ các trường thông tin chưa nhận diện được; cần cố định phiên bản thư viện phần mềm (SDK) sinh tự động cùng số hiệu phiên bản proto. Các bài kiểm thử giao ước chéo giữa các phương thức phải đối chiếu tỉ mỉ từ thẻ Agent Card, Nhiệm vụ, Thông điệp, Phần nội dung, Sản phẩm bàn giao, cấu trúc mã lỗi cho đến cơ chế phân trang. Cổng chuyển đổi giao thức phải bảo toàn trọn vẹn mọi mã định danh, trạng thái xử lý, dấu thời gian, siêu dữ liệu và cấu trúc báo lỗi; do ngữ nghĩa truyền luồng dữ liệu có thể khác biệt tùy thuộc vào phương thức truyền tải nên bắt buộc phải kiểm thử toàn trình từ đầu đến cuối. Mọi tuyên bố 'tương thích chuẩn A2A' đều phải công bố minh bạch phiên bản đặc tả, phương thức gắn kết kỹ thuật, bộ SDK sử dụng và các tính năng cụ thể được hỗ trợ.

4. Thẻ mô tả tác nhân (Agent Card) thuần túy là một bản công bố thông tin phục vụ quá trình tìm kiếm dịch vụ, chứ tuyệt đối không phải là một chứng thư bảo đảm sự tin cậy. Thẻ mô tả rõ tên gọi, phần giới thiệu chức năng, nhà cung cấp, phiên bản phát hành, các giao diện kết nối kèm đường dẫn URL, phương thức gắn kết kỹ thuật, phiên bản giao thức và định tuyến không gian khách hàng, năng lực xử lý, danh mục kỹ năng, cơ chế bảo mật cùng các tiện ích mở rộng. Mọi thẻ nhận được qua môi trường mạng công cộng đều phải coi là dữ liệu chưa thể tin cậy: chỉ tải qua giao thức HTTPS, đối chiếu tên miền và quyền sở hữu với danh sách cho phép, kiểm soát dung lượng tải về, xác thực cấu trúc dữ liệu, ngăn chặn hành vi chuyển hướng độc hại và tấn công giả mạo yêu cầu từ máy chủ (SSRF), quản lý thời gian tồn tại trong bộ nhớ đệm (TTL) và kiểm tra chữ ký số xác thực nguồn gốc nếu có. Phần mô tả kỹ năng không bao giờ đồng nghĩa với việc tác nhân được cấp quyền thao tác. Ứng dụng máy khách phải đối soát phiên bản giao diện, các tiện ích mở rộng bắt buộc và cơ chế bảo mật trước khi thiết lập kết nối. Mọi sự thay đổi trên thẻ Agent Card đều phải được so sánh đối chiếu khác biệt, rà soát an ninh và kích hoạt cảnh báo; kiên quyết ngăn chặn việc âm thầm hạ cấp năng lực an toàn. Thẻ mở rộng nhận được sau khi xác thực danh tính có thể chứa nhiều thông tin chi tiết hơn, nhưng việc xác thực danh tính thành công không bảo đảm mọi tuyên bố trên thẻ đều là sự thật. Danh mục đăng ký nội bộ bắt buộc phải gắn rõ người phụ trách, mức độ rủi ro, trạng thái phê duyệt và thời điểm thẩm định gần nhất.

5. Quy trình tìm kiếm tác nhân có thể triển khai qua tệp cấu hình tĩnh, đường dẫn định danh chuẩn hoặc danh mục dịch vụ doanh nghiệp tùy thuộc vào kiến trúc thực tế; bản thân giao thức A2A không thể thực hiện thay công tác thẩm định nhà cung cấp. Danh mục tác nhân doanh nghiệp bắt buộc phải lưu giữ đầy đủ thông tin định danh của nhà cung cấp, quyền sở hữu hợp pháp đối với đầu mối mạng, trạng thái vận hành dịch vụ, phân loại cấp độ dữ liệu và hành động được phép, hợp đồng thương mại ràng buộc, khu vực lưu trữ dữ liệu, cam kết hỗ trợ kỹ thuật, phê duyệt chính thức và lộ trình ngừng sử dụng. Thuật toán tìm kiếm và xếp hạng tác nhân tuyệt đối không để những đoạn văn mô tả do chính AI tự biên soạn quyết định việc tự động lựa chọn đối tác giao dịch. Một chiếc thẻ mô tả bị đầu độc có thể lén lút chuyển hướng lưu lượng người dùng đến một máy chủ giả mạo hoặc quảng bá những năng lực nguy hiểm vượt thẩm quyền. Quy trình tiếp nhận thẻ mới vào danh mục phải kiểm tra tính hợp lệ của dữ liệu, cách ly tạm thời để rà soát, yêu cầu con người trực tiếp phê duyệt đối với các trường hợp rủi ro cao và tái thẩm định định kỳ liên tục. Các tác nhân nội bộ bảo mật tuyệt đối không công khai siêu dữ liệu ra môi trường mạng công cộng. Khóa lưu trong bộ nhớ đệm phải được phân tách rạch ròi theo từng không gian khách hàng và mức độ tin cậy; khi chấm dứt hợp đồng với nhà cung cấp hoặc hủy kích hoạt dịch vụ, toàn bộ quyền truy cập và thẻ mô tả liên quan phải bị xóa bỏ ngay lập tức. Khi quá trình tìm kiếm dịch vụ gặp sự cố gián đoạn, phương án dự phòng chỉ được phép sử dụng bản sao chụp dữ liệu đã được phê duyệt từ trước, tuyệt đối không được tự ý tìm kiếm bừa bãi trên mạng Internet.

6. Thao tác gửi thông điệp (SendMessage) có thể trả về một thông điệp phản hồi trực tiếp đối với các tương tác độc lập trạng thái, hoặc chủ động khởi tạo một nhiệm vụ (Task) đối với các công việc phức tạp đòi hỏi lưu giữ trạng thái. Ứng dụng máy khách không nên gượng ép mọi phản hồi đơn giản thành một nhiệm vụ; ngược lại, máy chủ dịch vụ tuyệt đối không được sử dụng thông điệp trực tiếp cho những hành động nghiệp vụ cần theo dõi tiến độ hoặc đòi hỏi con người phê duyệt. Mỗi yêu cầu gửi đi đều bao gồm nội dung thông điệp, cấu hình tham số và siêu dữ liệu đi kèm; mối quan hệ giữa mã thông điệp, ngữ cảnh và nhiệm vụ bắt buộc phải được kiểm tra tính hợp lệ chặt chẽ. Việc xử lý các yêu cầu trùng lặp hoặc thử lại lệnh đòi hỏi phải thiết lập cơ chế chống xử lý trùng (idempotency) ngay tại tầng ứng dụng hoặc cổng an ninh mạng, bởi vì sự cố hết thời gian chờ trên đường truyền mạng hoàn toàn không chứng minh được rằng máy chủ phía bên kia chưa tiếp nhận và xử lý yêu cầu. Ngay cả một phản hồi trực tiếp tức thì vẫn bắt buộc phải có nguồn gốc xuất xứ rõ ràng, bảo đảm chất lượng và tuân thủ chính sách bảo mật. Quá trình khởi tạo một nhiệm vụ phải được liên kết giao dịch chặt chẽ với yêu cầu gốc phát sinh. Nếu phát hiện phương thức truyền thông điệp, kỹ năng yêu cầu hoặc cơ chế xác thực chưa được hỗ trợ, hệ thống phải trả về mã lỗi rõ ràng, minh bạch. Toàn bộ nội dung dữ liệu đầu vào đều phải được đối xử như nguồn tin chưa thể tin cậy; kiểm tra nghiêm ngặt cấu trúc dữ liệu, giới hạn kích thước, định dạng đa phương tiện và danh sách đường dẫn cho phép. Luôn thực hiện nguyên tắc tối thiểu hóa dữ liệu trước khi gửi thông tin xuyên ranh giới hệ thống; nghiêm cấm việc đưa các nội dung nhạy cảm vào các trường siêu dữ liệu chung.

7. Nhiệm vụ (Task) là đơn vị công việc kéo dài độc lập sở hữu một mã định danh duy nhất và một vòng đời hoàn chỉnh. Các trạng thái nghiệp vụ bao gồm: đã gửi yêu cầu (submitted), đang xử lý (working), cần thêm dữ liệu đầu vào (input-required), cần xác thực quyền hạn (auth-required) cùng các trạng thái kết thúc như đã hoàn thành (completed), đã hủy bỏ (canceled), bị từ chối (rejected) và thất bại (failed); mọi bước chuyển dịch trạng thái đều phải tuân thủ bảng chuyển dịch cho phép, ghi nhận rõ tác nhân thực hiện, dấu thời gian và lý do cụ thể. Máy chủ dịch vụ luôn là nguồn thẩm quyền duy nhất về trạng thái nhiệm vụ; ứng dụng máy khách khi nhận cập nhật qua cơ chế thăm dò, truyền luồng hay thông báo đẩy phải đối soát dựa trên số thứ tự phiên bản, tuyệt đối không tin tưởng một cách mù quáng vào thứ tự nhận gói tin trên mạng. Một khi nhiệm vụ đã bước vào trạng thái kết thúc, bản ghi dữ liệu sẽ không thể thay đổi, trừ khi phát sinh sự kiện đính chính đặc biệt theo đúng chính sách. Thao tác hủy bỏ nhiệm vụ được thực hiện trên nguyên tắc nỗ lực tối đa; những tác động làm thay đổi dữ liệu nghiệp vụ đã trót hoàn thành có thể sẽ đòi hỏi các giao dịch bù trừ để hoàn tác. Thời hạn hết hiệu lực, chu kỳ lưu giữ, lưu trữ hồ sơ và quyền truy cập phải được phân định chi tiết theo từng chủ thể và không gian khách hàng. Chuỗi sở hữu và ủy quyền nhiệm vụ phải luôn minh bạch. Việc thử lại thao tác gửi thông điệp không bao giờ được phép tạo ra các nhiệm vụ trùng lặp nhờ vào cơ chế ánh xạ khóa chống trùng và mã yêu cầu. Máy trạng thái phải được kiểm thử kỹ lưỡng trước các tình huống chuyển dịch trạng thái trái phép, cập nhật đồng thời, hết thời gian chờ, khởi động lại hệ thống và thông báo gửi đến muộn.

8. Mã ngữ cảnh (contextId) đóng vai trò gom nhóm nhiều thông điệp và nhiệm vụ nhằm duy trì tính liền mạch của cuộc hội thoại, nhưng tuyệt đối không phải là một ranh giới bảo mật an toàn hay một giấy phép mặc nhiên cho phép chia sẻ toàn bộ lịch sử trao đổi. Máy chủ dịch vụ bắt buộc phải kiểm tra chủ thể, không gian khách hàng và danh sách các bên tham gia trong mỗi lượt truy cập; tư cách thành viên của một ngữ cảnh phải được khai báo tường minh. Nghiêm cấm việc sử dụng các mã ngữ cảnh có tính quy luật dễ dự đoán. Thời hạn lưu giữ, mục đích sử dụng và quy trình xóa dữ liệu của ngữ cảnh hoàn toàn khác biệt so với từng nhiệm vụ riêng lẻ; khi chuyển giao công việc giữa các tác nhân, chỉ được phép gửi đúng phần thông tin thực sự cần thiết. Thao tác rẽ nhánh hoặc hợp nhất ngữ cảnh phải ghi nhận rõ nguồn gốc xuất xứ. Ứng dụng máy khách tuyệt đối không bao giờ tin tưởng mã ngữ cảnh do tác nhân từ xa cung cấp để tự tiện truy cập vào các cuộc trò chuyện nội bộ cục bộ. Bảng ánh xạ tương quan liên kết phải được bảo vệ nghiêm ngặt. Khi người dùng thay đổi vai trò hoặc chuyển vị trí công tác, hệ thống bắt buộc phải tiến hành phân quyền lại từ đầu. Một ngữ cảnh duy nhất có thể bao gồm nhiều nhiệm vụ có mức độ nhạy cảm dữ liệu khác biệt nhau; giao diện người dùng và cổng chính sách phải chủ động lọc dữ liệu phù hợp. Những câu lệnh tấn công ngầm (prompt injection) có thể ẩn nấp từ những thông điệp gửi trước đó vẫn luôn phải bị coi là dữ liệu chưa thể tin cậy. Hệ thống kiểm toán phải có khả năng tái dựng lại toàn bộ trình tự sự vụ mà không cần phải ghi toàn bộ nội dung dữ liệu nhạy cảm vào nhật ký hệ thống.

9. Mỗi thông điệp (Message) bao gồm vai trò người gửi và danh sách các phần nội dung (Part); mỗi phần nội dung có thể là văn bản, đường dẫn tham chiếu tệp tin hoặc biểu mẫu dữ liệu có cấu trúc. Định dạng MIME, kiểu dữ liệu, cấu trúc dữ liệu, kích thước tệp, mã băm toàn vẹn, nguồn gốc xuất xứ và mức độ nhạy cảm thông tin đều phải được kiểm tra hợp lệ chặt chẽ. Thao tác tải tệp tin từ đường dẫn tham chiếu bắt buộc phải có cơ chế phòng chống tấn công giả mạo yêu cầu từ máy chủ (SSRF), sử dụng đường dẫn có chữ ký số xác thực kèm thời hạn hết hiệu lực, quét mã độc và kiểm duyệt nội dung tự động, đối chiếu danh sách định dạng cho phép, mở trong môi trường cách ly an toàn, kiểm soát việc chuyển hướng mạng và phân giải tên miền (DNS), giám sát lưu lượng dữ liệu đi ra và tuân thủ thời hạn lưu giữ. Giới hạn dung lượng tối đa đối với các tệp đính kèm trực tiếp bên trong thông điệp. Phần nội dung có cấu trúc phải sử dụng cấu trúc dữ liệu có quản lý phiên bản rõ ràng; có quy trình xử lý chuẩn mực cho các trường dữ liệu lạ hoặc các tiện ích mở rộng chưa nhận biết được. Nội dung văn bản thuần túy không bao giờ được mặc nhiên coi là các chỉ dẫn điều khiển đáng tin cậy. Mã hóa dữ liệu đầu ra và bảo đảm giao diện hiển thị an toàn cho người dùng cuối. Các liên kết dẫn đến tệp âm thanh hoặc video phải được thẩm định kỹ lưỡng về bản quyền và quyền riêng tư. Hồ sơ nguồn gốc của thông điệp phải phân định rạch ròi giữa người dùng thật, tác nhân máy khách và tác nhân từ xa; nghiêm cấm việc tác nhân AI giả mạo danh tính con người. Các bản tóm tắt nội dung đã được che mờ hoặc dịch thuật phải giữ nguyên liên kết tham chiếu tới tài liệu nguồn và đính kèm các lưu ý cảnh báo. Mặc định, nhật ký hệ thống chỉ lưu trữ siêu dữ liệu và mã kiểm tra tính toàn vẹn (checksum), tuyệt đối không lưu trữ toàn bộ nội dung dữ liệu nhạy cảm.

10. Sản phẩm đầu ra (Artifact) là kết quả hoàn thành nhiệm vụ được cấu thành từ nhiều phần nội dung khác nhau, nhưng bản thân nó không tự động trở thành một hồ sơ nghiệp vụ đã được nghiệm thu chính thức. Mỗi sản phẩm đều có mã định danh, tên gọi, phần mô tả chức năng cùng ngữ nghĩa bổ sung hoặc cập nhật theo đúng đặc tả kỹ thuật; ứng dụng máy khách phải có khả năng xử lý mượt mà các mảnh dữ liệu gia tăng và thao tác chốt phiên bản cuối cùng. Việc bảo đảm tính toàn vẹn phải dựa trên mã băm an toàn, số hiệu phiên bản, kiểu nội dung, nhiệm vụ nguồn phát sinh, đơn vị tạo lập và dấu thời gian chính xác. Đối với các sản phẩm có dung lượng lớn, cần lưu trữ trên hệ thống chuyên dụng bên ngoài, sử dụng đường dẫn tham chiếu có chữ ký số ràng buộc quyền truy cập, mã hóa toàn trình, quy định thời hạn lưu giữ và quét mã độc định kỳ. Sản phẩm đầu ra bắt buộc phải trải qua quy trình kiểm tra hợp lệ, đánh giá chất lượng và nhận được sự phê duyệt chính thức của con người trước khi kích hoạt bất kỳ hành động nghiệp vụ nào ở các hệ thống phía dưới. Những sản phẩm bị thay thế hoặc đã được đính chính phải bảo tồn trọn vẹn lịch sử dòng đời phát triển. Tuân thủ nghiêm ngặt các quy định về sở hữu trí tuệ, điều khoản cấp phép và bảo mật thông tin khi chia sẻ sản phẩm xuyên tổ chức. Một bản đề xuất dạng tệp PDF do tác nhân tạo ra thuần túy chỉ là bản dự thảo cho đến khi có chữ ký phê duyệt có thẩm quyền; một đơn đặt hàng có cấu trúc tuyệt đối không được tự động gửi đi thanh toán. Các công cụ MCP được huy động để tạo ra sản phẩm đầu ra phải được ghi nhận đầy đủ trong nhật ký truy vết và đồ thị bằng chứng nội bộ, nhưng các khóa bí mật bảo mật và câu lệnh thô tuyệt đối không bao giờ cần phải chuyển giao qua giao thức A2A.

11. Cơ chế truyền luồng dữ liệu (streaming) đảm nhiệm việc truyền tải liên tục các bản cập nhật về nhiệm vụ, tiến độ trạng thái và sản phẩm bàn giao; ứng dụng máy khách bắt buộc phải có khả năng chống chịu sự cố ngắt kết nối mạng, tự động kết nối lại, xử lý các gói tin trùng lặp, dữ liệu đến sai thứ tự và các mảnh tệp tin tải dở dang. Cần sử dụng số thứ tự phiên bản và thuật toán hợp nhất dữ liệu bảo đảm tính chống trùng; tận dụng mã nối lại phiên làm việc (resume token) hoặc sự kiện gần nhất khi phương thức gắn kết kỹ thuật hỗ trợ; đồng thời đối soát trạng thái kết thúc thông qua hàm truy vấn GetTask. Cần thực hiện kiểm thử tải nghiêm ngặt về cơ chế kiểm soát áp lực ngược (backpressure), tín hiệu nhịp tim định kỳ (heartbeat), thời gian sống tối đa của một luồng dữ liệu, hiện tượng máy chủ ủy thác đệm dữ liệu và tình huống máy khách xử lý chậm. Quyền xác thực của luồng dữ liệu phải được thẩm định lại liên tục và xử lý kịp thời khi mã truy cập hết hạn; tuyệt đối không để luồng truyền tải tiếp tục hoạt động vô thời hạn sau khi quyền hạn đã bị thu hồi. Mỗi sự kiện phát đi đều phải kiểm tra quyền truy cập không gian khách hàng và phạm vi nhiệm vụ. Một sản phẩm bàn giao mới tải được một phần tuyệt đối không bao giờ được sử dụng như một sản phẩm hoàn thiện. Phân định rạch ròi giữa hành động chủ động hủy bỏ nhiệm vụ với sự cố mất kết nối mạng đột ngột. Nhật ký hệ thống tránh lưu trữ nội dung dữ liệu thô. Các cam kết chất lượng dịch vụ (SLO) cần bóc tách riêng biệt giữa thời gian phát bản cập nhật đầu tiên, độ tươi mới của tiến độ và thời gian hoàn tất toàn bộ nhiệm vụ. Luôn duy trì cơ chế thăm dò định kỳ dự phòng (polling) kèm thuật toán lùi thời gian thông minh. Cần ghi nhớ rõ: truyền luồng dữ liệu thuần túy là một tính năng tối ưu trải nghiệm người dùng và phương thức truyền tải mạng, chứ không phải là bằng chứng chứng minh tác nhân vẫn đang hoạt động bình thường hay đưa ra kết quả chính xác.

12. Cơ chế thông báo đẩy (push notifications) hỗ trợ đắc lực cho các nhiệm vụ kéo dài mà không đòi hỏi ứng dụng máy khách phải duy trì kết nối liên tục, nhưng đồng thời lại mở ra bề mặt tấn công an ninh mạng rất lớn qua các cổng nhận phản hồi (webhook). Đường dẫn nhận phản hồi (callback URL) bắt buộc phải được đăng ký trước và kiểm tra chặt chẽ đối chiếu với danh sách cho phép an toàn, bắt buộc chạy trên giao thức mã hóa HTTPS, phòng chống các cuộc tấn công giả mạo yêu cầu từ máy chủ (SSRF), tấn công ràng buộc lại DNS (DNS rebinding) và tuân thủ chính sách cô lập không gian khách hàng; sử dụng khóa bí mật, chữ ký số hoặc xác thực mTLS hai chiều, gắn kèm dấu thời gian và số dùng một lần (nonce), có cơ chế phòng chống tấn công gửi lại (replay) và định kỳ thay đổi khóa bảo mật. Cam kết chuyển phát thông báo ít nhất một lần (at-least-once delivery) đồng nghĩa với việc phía hệ thống tiếp nhận bắt buộc phải có thuật toán xử lý chống trùng lặp. Gói tin thông báo đẩy chỉ nên chứa lượng dữ liệu tối thiểu, thông thường chỉ gồm mã nhiệm vụ, trạng thái hiện tại và đường dẫn để chủ động truy vấn chi tiết; tuyệt đối không đính kèm các sản phẩm dữ liệu nhạy cảm trừ khi có thỏa thuận pháp lý đặc biệt trong hợp đồng. Thiết lập cơ chế thử lại có khoảng lùi thời gian, định tuyến vào hàng đợi thư chết (dead-letter queue) khi xử lý thất bại nhiều lần và tự động vô hiệu hóa các đầu mối mạng độc hại hoặc liên tục báo lỗi. Quyền sở hữu đăng ký nhận thông báo phải có thời hạn hết hiệu lực cụ thể. Hệ thống tiếp nhận phải xác thực danh tính người gửi và đối chiếu với nhiệm vụ dự kiến, chứ không chỉ dựa dẫm vào địa chỉ IP đơn thuần. Trường hợp thông báo đến sai lệch thứ tự thời gian phải được đối soát lại dựa trên số hiệu phiên bản. Thiết lập các hạn chế nghiêm ngặt đối với lưu lượng mạng đi ra và tiến hành thẩm định an ninh kỹ lưỡng các đầu mối kết nối của đối tác. Khi phát sinh sự cố bảo mật, phải lập tức thu hồi toàn bộ thông tin xác thực của cổng nhận phản hồi. Cơ chế thăm dò định kỳ vẫn luôn là phương án dự phòng cốt lõi; việc gửi thành công một thông báo đẩy kỹ thuật không bao giờ đồng nghĩa với việc kết quả nghiệp vụ kinh doanh đã hoàn tất trọn vẹn.

13. Trong môi trường đa khách hàng, giao diện tác nhân (AgentInterface) có thể chứa một giá trị định tuyến không gian khách hàng dạng chuỗi mờ (opaque tenant routing value); tuy nhiên giá trị này không tự định nghĩa ngữ nghĩa nghiệp vụ của khách hàng và cũng không thể dùng làm bằng chứng xác thực danh tính. Ứng dụng máy khách tiếp nhận thông tin định tuyến này từ thẻ Agent Card hoặc tệp cấu hình đáng tin cậy và gửi kèm trong trường thông tin bắt buộc; máy chủ dịch vụ phải tự động suy xuất không gian khách hàng được cấp quyền thực tế từ mã khóa xác thực (token) và chính sách bảo mật, sau đó tiến hành đối chiếu với đường định tuyến, tuyệt đối không bao giờ tin tưởng một giá trị tùy tiện do máy khách gửi lên. Phân vùng cô lập triệt để mọi dữ liệu nhiệm vụ, ngữ cảnh hội thoại, sản phẩm bàn giao, thông điệp trao đổi, bộ nhớ đệm, nhật ký truy vết, hạn mức sử dụng (quota), khóa mật mã và cơ sở dữ liệu. Giá trị không gian khách hàng phải là chuỗi ngẫu nhiên không có ý nghĩa rõ ràng, không làm lộ mã định danh kỹ thuật nội bộ của doanh nghiệp. Cổng an ninh mạng phải có cơ chế ngăn chặn tấn công gây nhầm lẫn đường dẫn hoặc lỗi chuẩn hóa chuỗi ký tự. Mọi hoạt động cộng tác giữa các tác nhân thuộc hai không gian khách hàng khác nhau đều bắt buộc phải có thỏa thuận văn bản rõ ràng và được cấp một phạm vi quyền hạn mới; nghiêm cấm việc âm thầm chia sẻ chung ngữ cảnh dữ liệu. Các kịch bản kiểm thử bảo mật phải chủ động tráo đổi mã khách hàng, mã nhiệm vụ, mã ngữ cảnh, mã sản phẩm, khóa bộ nhớ đệm và các đầu mối thông báo đẩy để kiểm tra độ kín của rào chắn. Quyền mạo danh của đội ngũ hỗ trợ kỹ thuật hoặc quản trị viên phải được kiểm soát và ghi nhật ký nghiêm ngặt. Quy trình sao lưu, khôi phục và xuất dữ liệu bắt buộc phải bảo toàn nguyên vẹn ranh giới phân vùng cô lập. Khả năng hiển thị của thẻ Agent Card phải được giới hạn chặt chẽ theo phạm vi quyền hạn của từng không gian khách hàng cụ thể.

14. Cơ chế xác thực được công bố công khai trong thẻ Agent Card và được triển khai cụ thể thông qua phương thức gắn kết kỹ thuật hoặc kiến trúc hạ tầng; tuy nhiên việc phân quyền thực thi luôn là trách nhiệm tối thượng thuộc về phía máy chủ dịch vụ. Cấu hình bảo mật công bố trên thẻ thuần túy chỉ là siêu dữ liệu mô tả, chứ tuyệt đối không phải là thông tin xác thực đăng nhập. Máy chủ bắt buộc phải kiểm tra kỹ lưỡng đơn vị cấp phát mã khóa, đối tượng tiếp nhận hợp lệ, chữ ký số mật mã, thời hạn hết hiệu lực, định danh ứng dụng máy khách, chủ thể người dùng, không gian khách hàng và phạm vi quyền hạn; luôn tuân thủ nguyên tắc phân quyền tối thiểu. Cơ chế định danh tải công việc giữa tác nhân với tác nhân (agent-to-agent workload identity) có bản chất kỹ thuật hoàn toàn khác biệt so với việc ủy quyền người dùng thông thường; chuỗi ủy quyền danh nghĩa (on-behalf-of) phải được ghi nhận rõ ràng mà không áp dụng lối làm tắt chuyển tiếp mã truy cập tùy tiện. Việc áp dụng xác thực mTLS hai chiều hoặc chữ ký số định danh tải công việc có thể bổ trợ hiệu quả cho khung xác thực OAuth chuẩn mực. Mỗi nguồn tài nguyên MCP ở các hệ thống phía dưới đều phải tiếp nhận đúng mã truy cập gắn liền với đúng phạm vi đối tượng được chỉ định. Kho lưu trữ thông tin đăng nhập phải được phân vùng cô lập chi tiết theo từng đối tác, từng tác nhân và từng loại tài nguyên nghiệp vụ. Duy trì quy trình xoay vòng khóa mật mã định kỳ, cơ chế thu hồi khẩn cấp và quy trình rút lui an toàn. Những nhiệm vụ có tính chất rủi ro cao đòi hỏi phải có sự kiểm soát của chính sách an ninh và phê duyệt chính thức của con người, chứ không chỉ dựa vào việc xác thực đăng nhập thành công. Nghiêm cấm hoàn toàn hành vi đưa mã khóa truy cập vào nội dung thông điệp, trường siêu dữ liệu, đường dẫn URL hay ghi ra nhật ký hệ thống. Ngữ nghĩa nghiệp vụ giữa mã lỗi 401 (chưa xác thực), 403 (bị cấm truy cập) và trạng thái nhiệm vụ đang chờ xác thực quyền (auth-required) bắt buộc phải được văn bản hóa đầy đủ và chính xác.

15. Việc kiểm soát phân quyền phải bám sát toàn bộ vòng đời phát triển của nhiệm vụ, chứ không chỉ dừng lại ở thời điểm gửi thông điệp ban đầu (SendMessage). Mọi thao tác như truy vấn thông tin (GetTask), liệt kê danh sách (ListTasks), hủy bỏ lệnh (CancelTask), đăng ký nhận luồng dữ liệu (Subscribe), cấu hình thông báo đẩy (Push) hay truy cập vào sản phẩm bàn giao (Artifact) đều bắt buộc phải kiểm tra lại định danh hiện tại, chính sách an ninh hiện hành và quyền sở hữu đối với đối tượng dữ liệu cụ thể. Quyền hạn của người dùng hoặc hệ thống hoàn toàn có thể bị thay đổi hoặc thu hồi ngay trong lúc nhiệm vụ đang được xử lý; khi đó, tác nhân từ xa phải chủ động tạm dừng tiến độ và chuyển sang trạng thái chờ xác thực quyền (auth-required), hoặc dừng lại một cách an toàn, tuyệt đối không được phép tiếp tục thao tác dựa trên các quyền hạn đã hết hiệu lực. Phạm vi quyền hạn để khởi tạo một nhiệm vụ mới có thể hoàn toàn khác biệt so với quyền xem kết quả hay quyền hủy bỏ nhiệm vụ đó. Một tác nhân ủy thác không bao giờ được phép cấp quyền vượt quá thẩm quyền thực tế của người dùng hoặc tổ chức mà nó đại diện. Quyết định phê duyệt của con người phải được ràng buộc chặt chẽ với đúng nhiệm vụ, hành động cụ thể, sản phẩm bàn giao, hạn mức giá trị kinh tế và có thời hạn hiệu lực cụ thể. Quy trình tái ủy quyền sau khi chuyển hướng đường dẫn phải xác thực kỹ lưỡng tham số trạng thái, cơ chế khóa bảo mật PKCE và nguồn gốc xuất xứ của yêu cầu. Mọi quyết định thực thi chính sách an ninh đều phải được quản lý theo phiên bản và ghi nhật ký kiểm tra đầy đủ. Các mã ngữ cảnh và mã nhiệm vụ tuyệt đối không phải là các mã khóa bí mật có thể dùng để chứng minh quyền truy cập. Việc sử dụng dữ liệu xuyên tổ chức, thời hạn lưu giữ và việc tái sử dụng cho các mục đích phụ phải chịu sự điều chỉnh tối thượng của các hợp đồng thương mại ràng buộc và quy định của pháp luật hiện hành, chứ không thể chỉ phó mặc cho các giao thức kỹ thuật tự quyết định.

16. Đàm phán kỹ năng (skill negotiation) tránh việc xem Agent Card viết bằng ngôn ngữ tự nhiên như một hợp đồng thực thi. Ứng dụng client chọn kỹ năng dựa trên danh mục (registry) đã phê duyệt, mã định danh (ID)/thẻ (tag)/ví dụ có cấu trúc và chính sách nội bộ, sau đó máy chủ (server) xác thực thông điệp gửi đến có khớp hay không. Không tự động cấp quyền động chỉ vì thẻ giới thiệu tự nhận có chuyên môn sâu. Phiên bản năng lực/kỹ năng và kỳ vọng đầu vào/đầu ra phải được theo dõi chặt chẽ; mọi điểm mơ hồ đều phải yêu cầu làm rõ. Thiết lập cơ chế ngưng hỗ trợ (deprecation) và phương án dự phòng khi kỹ năng lỗi thời. Kiểm thử các mô tả đối kháng (adversarial descriptions), kỹ năng chồng chéo và sai phương thức dữ liệu (modality). Chủ sở hữu doanh nghiệp hoặc con người phải nắm quyền kiểm soát các ủy quyền có tác động lớn. Đánh giá kết quả theo từng loại tác vụ; tác nhân từ xa có thể là hộp đen nhưng tiêu chí nghiệm thu thì không được phép mơ hồ. Hệ thống định tuyến ghi nhận danh sách ứng viên, lý do, độ tin cậy và tránh suy diễn phân biệt đối xử hay nhạy cảm. Tác vụ thất bại hoặc bị từ chối tuyệt đối không được tự ý định tuyến lại sang một tác nhân chưa xác thực.

17. Đàm phán phần mở rộng (extension negotiation) bổ sung các năng lực vượt ngoài chuẩn cốt lõi; URI của AgentExtension, cờ bắt buộc (required flag) và tham số đều là dữ liệu không đáng tin cậy cho đến khi được đưa vào danh sách trắng (allowlist) và hỗ trợ chính thức. Nếu phần mở rộng bắt buộc không được nhận diện, hệ thống phải từ chối tương tác hoặc báo lỗi không tương thích rõ ràng, tuyệt đối không được lờ đi. Sự cố của phần mở rộng tùy chọn không được làm thay đổi ngữ nghĩa cốt lõi của tác vụ. Cần tách biệt rõ ràng giữa không gian tên (namespace), nguồn gốc xuất xứ (provenance), phiên bản, bảo mật, vòng đời và tính tương thích chuẩn (conformance). Tham số mở rộng phải được kiểm tra dung lượng và lược đồ (schema); cấm nạp mã hoặc tải URL khi chưa qua kiểm duyệt. Hai tác nhân có thể hỗ trợ các phiên bản khác nhau—cần duy trì ma trận tương thích. Cổng kết nối (gateway) và sổ đăng ký chỉ hiển thị các tiện ích mở rộng đã được kiểm duyệt. Các phần mở rộng đặc thù của nhà cung cấp dễ tạo ra rủi ro khóa chặt (lock-in) và chi phí chuyển đổi cao. Tiện ích mở rộng của MCP và tiện ích mở rộng của A2A là hoàn toàn độc lập; tên gọi trùng khớp không đồng nghĩa với khả năng tương thích. Mọi công bố chính thức phải nêu rõ phiên bản tiện ích mở rộng và cặp tương tác cụ thể.

18. Lựa chọn ràng buộc giao thức (protocol binding) cần cân nhắc kỹ giữa hệ sinh thái, độ trễ, khả năng truyền phát (streaming), lược đồ/tạo mã tự động (schema/codegen), cổng kết nối (gateway) và vận hành. JSON-RPC thường quen thuộc với các tác nhân và MCP; REST tích hợp mượt mà với tài nguyên HTTP; gRPC đem lại lợi thế về protobuf, sinh mã tự động và truyền phát dữ liệu. A2A v1.0 giữ tính nhất quán cho các thao tác và dữ liệu trừu tượng, nhưng tiêu đề xác thực, mã lỗi, cơ chế streaming và ánh xạ khả năng quan sát (observability) sẽ khác nhau. Chỉ nên cung cấp nhiều binding khi có lý do chính đáng và đảm bảo tính tương thích đồng nhất; nếu không, bề mặt tấn công và rủi ro vận hành sẽ tăng gấp ba. Thứ tự khai báo trong Agent Card thể hiện mức độ ưu tiên; phía client sẽ đàm phán giao diện tương thích. Cổng chuyển đổi (translation gateway) phải bảo toàn nguyên vẹn ID, trạng thái, mã lỗi và không được tự ý sửa đổi quyền hạn. Quản lý phiên bản độc lập theo từng giao diện. Thiết lập đầy đủ cân bằng tải, ủy quyền ngược (proxy), TLS, thời gian chờ (timeout) và giới hạn kích thước thông điệp. Các bài kiểm thử chéo giữa các binding phải sử dụng cùng luồng tác vụ chuẩn và tập hiện vật mẫu.

19. Mô hình xử lý lỗi cần phân tách rành mạch giữa yêu cầu/thông điệp không hợp lệ, giới hạn năng lực tác nhân, tác vụ không tìm thấy hoặc không có quyền truy cập, lỗi xác thực, xung đột trạng thái, giới hạn tần suất/phụ thuộc bên ngoài và sự cố nội bộ. Tuyệt đối không để lộ sự tồn tại của dữ liệu giữa các bên thuê (cross-tenant) theo chính sách không tìm thấy (not-found). Cung cấp hướng dẫn thử lại và cơ chế giãn thời gian (backoff); các lượt thử lại SendMessage bắt buộc phải có tính bất biến (idempotency). Một tác vụ bị từ chối là quyết định nghiệp vụ hoặc chính sách, tác vụ thất bại là do lỗi thực thi kỹ thuật, tác vụ bị hủy phải ghi rõ chủ thể và lý do; phía client không được gộp chung tất cả thành một lỗi mơ hồ. Hiện vật từng phần, trạng thái trung gian và cơ chế bù trừ phải được ghi chép đầy đủ. Lỗi lan truyền từ công cụ MCP phải được biên dịch thành thông điệp an toàn kèm liên kết truy vết (trace link), không để lộ ngăn xếp lỗi (stack trace) hay dữ liệu nhạy cảm. Đo lường chỉ số theo thao tác, tác nhân, đối tác, trạng thái và nguyên nhân với sự kiểm soát chặt chẽ về số lượng nhóm (cardinality) và quyền riêng tư. Thực hiện kiểm thử hợp đồng và kiểm thử hỗn loạn (chaos testing) định kỳ.

20. Kiểm soát độ sâu ủy quyền và vòng lặp nhằm ngăn chặn tình trạng bóng bàn giữa các tác nhân (agent ping-pong). Mỗi yêu cầu đều chịu sự kiểm soát của chính sách về số chặng (hop), thời hạn chót (deadline), ngân sách, ngữ cảnh và phả hệ ủy quyền; siêu dữ liệu A2A hoặc cơ chế kiểm soát nội bộ chỉ mang liên kết an toàn chứ không truyền quyền hạn có thể biến đổi. Tác nhân phải chủ động phát hiện chu trình hoặc mục tiêu lặp lại để từ chối hoặc yêu cầu con người can thiệp. Ngân sách chi phí, token, lượt gọi công cụ và hành động cần được tổng hợp trên toàn chuỗi tác nhân nếu có thể. Giới hạn số lượng tác vụ phân nhánh (fan-out); lệnh hủy tác vụ được lan truyền với nỗ lực tối đa và có đối soát trạng thái. Một tác nhân từ xa không được phép tự ý ủy quyền công việc nhạy cảm cho bên thứ ba chưa được phê duyệt chỉ vì bên đó có năng lực. Chuỗi nhà thầu phụ và tác nhân ủy thác phải được liệt kê trong danh mục nhà cung cấp và hợp đồng pháp lý. Kết quả đầu ra phải đi kèm nguồn gốc xuất xứ và các lưu ý chưa xử lý. Khả năng quan sát giúp phát hiện sớm vòng lặp vô tận, khuếch đại tải và tác vụ mồ côi. Bố trí công tắc ngắt khẩn cấp (kill switch) theo từng đối tác, tác nhân và kỹ năng.

21. Con người can thiệp vào quy trình (human-in-the-loop) tại các ranh giới ra quyết định trọng yếu: ủy quyền ra bên ngoài, tiết lộ dữ liệu nhạy cảm, phê duyệt hành động thương mại/pháp lý/an toàn, xử lý yêu cầu cung cấp đầu vào hoặc xác thực, nghiệm thu hiện vật hoặc kích hoạt bù trừ khi sự cố xảy ra. Giao diện người dùng phải hiển thị rõ tác nhân yêu cầu, nhà cung cấp, tên miền, tác vụ, dữ liệu liên quan, phạm vi quyền hạn, hệ quả, các phương án thay thế và thời hạn hiệu lực. Phê duyệt phải gắn liền với mã băm (digest) và phiên bản nội dung; mọi thay đổi đều làm vô hiệu hóa phê duyệt trước đó. Tuyệt đối không dùng giao diện đánh lừa (dark pattern) hoặc phê duyệt hàng loạt thiếu kiểm soát. Áp dụng phân quyền vai trò, nguyên tắc tách biệt nhiệm vụ và phê duyệt hai người (four-eyes) khi cần thiết. Phản hồi của con người được chuyển hóa thành Thông điệp (Message) hoặc bước chuyển trạng thái có kiểm toán đầy đủ, không để mô hình tự phỏng đoán từ văn bản tự do. Thiết lập cam kết thời gian leo thang (escalation SLA) và lộ trình dự phòng. Có cơ chế khiếu nại và khắc phục sai sót cho người dùng bị ảnh hưởng. Mức độ tự động hóa phải tương xứng với mức độ rủi ro; giao thức hỗ trợ tương tác kỹ thuật nhưng doanh nghiệp mới là bên quyết định quyền hạn phê duyệt.

22. Đồ thị bằng chứng (evidence graph) liên kết chặt chẽ ý định và sự ủy quyền của người dùng, tác nhân client, Agent Card/phiên bản, tác vụ/ngữ cảnh/thông điệp/hiện vật/trạng thái A2A, tác nhân từ xa/nhà cung cấp, các quyết định nội bộ và các lệnh gọi công cụ/tài nguyên MCP, cùng các phê duyệt và tác động ngoại biên. Các mã định danh tương quan (correlation ID) phải ổn định và được bảo vệ việc ánh xạ; ghi nhận thời gian sự kiện, nguồn gốc, mã băm (hash) và phiên bản. Không nhất thiết phải lưu lại toàn bộ chuỗi suy nghĩ (chain-of-thought); chỉ cần lưu các sự kiện vận hành và quyết định then chốt là đủ. Bản kiểm toán phải đảm bảo tính bất biến và phát hiện can thiệp tương xứng với cấp độ rủi ro, tuân thủ chính sách truy cập, lưu trữ và quyền riêng tư. Quá trình đối soát xác nhận tác vụ đã hoàn thành thực sự tương ứng với hiện vật được chấp nhận và các hành động hạ nguồn đã cam kết; trạng thái hoàn thành từ tác nhân từ xa đơn thuần chưa thể tương đương với tất toán nghiệp vụ. Các tuyên bố hoặc công bố kết quả phải dựa trên cấp độ bằng chứng và kèm theo điều kiện loại trừ trách nhiệm. Khi xảy ra sự cố, hệ thống có thể truy vết phạm vi ảnh hưởng (blast radius) và thu hồi quyền của các tác nhân hoặc công cụ bị tác động.

23. Cam kết mức dịch vụ (SLO) vượt qua ranh giới tin cậy giữa các tổ chức. Cần định nghĩa rõ tính khả dụng và độ tươi mới của danh mục/thẻ giới thiệu, thời gian xác thực, tỷ lệ tiếp nhận SendMessage, độ tươi mới của tiến độ/thời gian hoàn thành tác vụ, chất lượng truyền phát/đẩy dữ liệu, tính toàn vẹn của hiện vật, thời gian xử lý hủy tác vụ và hoàn tất quy trình nghiệp vụ hạ nguồn. SLO của nhà cung cấp bên ngoài không bao gồm độ trễ của công cụ MCP nội bộ hay thời gian phê duyệt của người dùng; cần ánh xạ ngân sách thời gian cho từng phụ thuộc. Thời gian chờ (timeout) và hạn chót (deadline) được truyền đi nhưng không can thiệp thô bạo vào kế hoạch xử lý nội bộ của phía từ xa. Phân bổ ngân sách lỗi (error budget) theo mức độ nghiêm trọng, đối tác và kỹ năng. Giám sát tổng hợp giả lập (synthetic monitoring) bằng dữ liệu và tác nhân kiểm thử an toàn; tuyệt đối không tạo ra tác động phụ thực tế. Các chế tài vi phạm hợp đồng/SLA không đồng nghĩa với việc ngăn ngừa được thiệt hại thực tế. Chuẩn bị sẵn sàng kiến trúc đa vùng, khả năng phục hồi sau thảm họa (DR) và phương án rút lui/xuất dữ liệu. Quy định rõ vai trò truyền thông sự cố giữa các tổ chức và cơ chế chia sẻ bằng chứng theo thỏa thuận pháp lý.

24. Chương trình thử nghiệm (pilot) nên bắt đầu với một trường hợp cộng tác giới hạn, thiên về đọc dữ liệu, nơi năng lực chuyên sâu của tác nhân từ xa tạo ra giá trị vượt trội so với một công cụ đơn thuần: định nghĩa Agent Card rõ ràng, một luồng trạng thái tác vụ duy nhất, hiện vật có cấu trúc nhỏ gọn, con người trực tiếp nghiệm thu và các lệnh gọi MCP nằm trong từng phân vùng quản trị. Sử dụng dữ liệu giả lập hoặc đã làm mờ (redacted); tuyệt đối không cho phép tự động thực hiện các giao dịch tài chính hay tác động ngoại biên. Kiểm thử toàn diện quá trình khám phá, xác thực, tác vụ, thông điệp, hiện vật, cơ chế truyền phát/đẩy dữ liệu, trạng thái yêu cầu đầu vào/xác thực, quy trình hủy/thất bại/thử lại, cách ly đối tượng thuê, xử lý khi công cụ hạ nguồn gặp sự cố và thu thập bằng chứng. So sánh đối chuẩn với phương án gọi API trực tiếp, MCP hoặc giải pháp không dùng tác nhân trên các khía cạnh chất lượng, độ trễ, công sức, chi phí và rủi ro. Triển khai theo dõi canary cho nhóm nhỏ người dùng/tác nhân; chuẩn bị công tắc ngắt khẩn cấp và quy trình xử lý thủ công dự phòng. Chỉ mở rộng quy mô khi lợi ích về mặt ngữ nghĩa thực sự bù đắp được chi phí vận hành, quản lý trạng thái và ranh giới tin cậy phát sinh.

25. Tiến hóa lược đồ (schema evolution) cần tách bạch rõ ràng giữa phiên bản giao thức, phiên bản Agent Card, hợp đồng kỹ năng (skill contract), lược đồ thành phần có cấu trúc (structured Part schema) và lược đồ hiện vật (Artifact schema). Việc cùng hỗ trợ A2A v1.0 không đồng nghĩa với việc hai tác nhân tự động thấu hiểu chung các trường nghiệp vụ. Mỗi lược đồ phải có ID chuẩn hóa (canonical ID), phiên bản ngữ nghĩa (semantic version), chủ sở hữu, quy tắc tương thích và bộ dữ liệu mẫu chuẩn (golden fixtures). Bên phát hành (producer) không được tùy tiện xóa trường bắt buộc hoặc âm thầm thay đổi đơn vị/ngữ nghĩa; bên tiếp nhận (consumer) phải bảo toàn các trường chưa nhận diện theo quy tắc binding nhưng không cho phép chúng can thiệp vào các đặc quyền hệ thống. Cổng chuyển đổi (gateway) ghi nhận phiên bản nguồn/đích và cảnh báo hao hụt thông tin. Cơ chế đọc song song/ghi song song (dual-read/dual-write) chỉ áp dụng trong khoảng thời gian có giới hạn. Sổ đăng ký hợp đồng phải cảnh báo tác động đến bên tiếp nhận; chiến lược triển khai mở rộng–chuyển đổi–thu hẹp (expand–migrate–contract) cần đi kèm phương án thử nghiệm canary và khả năng khôi phục (rollback). Các tác vụ và hiện vật cũ lưu trữ vẫn phải hiển thị và xác minh được tính toàn vẹn. Trường bảo mật khẩn cấp phải có chính sách an toàn mặc định (fail-safe). Bằng chứng tương thích bắt buộc phải bao gồm kiểm thử vòng tròn (round-trip) qua mọi SDK và binding đã được phê duyệt, không dừng lại ở kiểm thử đơn vị trên một ngôn ngữ duy nhất.

26. Định tuyến và lựa chọn tác nhân (routing and selection) là quyết định chứa đựng rủi ro thực tế, không đơn thuần là bài toán đo độ tương đồng ngữ nghĩa. Tập hợp ứng viên luôn phải được chọn lọc từ sổ đăng ký đã phê duyệt; lọc trước theo bên thuê, vị trí địa lý, phân loại dữ liệu/hành động, binding/phiên bản, phương thức bảo mật, tiện ích mở rộng, tính khả dụng, điều khoản hợp đồng và ngân sách. Sau đó mới xếp hạng mức độ phù hợp kỹ năng, chất lượng quan sát thực tế, độ trễ hoặc chi phí. Mô tả do mô hình tự tạo và lời tự công bố từ nhà cung cấp tuyệt đối không được dùng làm tín hiệu định tuyến duy nhất. Bộ định tuyến (router) ghi nhận danh sách ứng viên, các tiêu chí lọc, tác nhân được chọn, phiên bản chính sách và lý do đủ chi tiết để kiểm toán nhưng không làm lộ bí mật thương mại. Lưu lượng thăm dò (exploration traffic) chỉ giới hạn trên dữ liệu giả lập hoặc tác vụ rủi ro thấp. Đánh giá tính công bằng và định kiến khi quyết định định tuyến có tác động đến con người. Khi nhà cung cấp gặp sự cố, việc chuyển hướng dự phòng chỉ được thực hiện sang các tác nhân đã phê duyệt với các biện pháp kiểm soát tương đương; tuyệt đối không hạ thấp tiêu chuẩn bảo mật để giữ cam kết SLA. Cơ chế ghim/chặn thủ công và công tắc ngắt khẩn cấp phải được kiểm thử định kỳ.

27. Bộ khung đánh giá (evaluation harness) cần kiểm thử tính chính xác của giao thức và chất lượng tác vụ như hai tầng hoàn toàn độc lập. Bộ kiểm thử giao thức tập trung đánh giá thẻ giới thiệu, xác thực, các thao tác, trạng thái, mã lỗi, cơ chế streaming, cơ chế đẩy dữ liệu, tính hợp lệ của lược đồ và sự cách ly giữa các bên thuê. Bộ kiểm thử nghiệp vụ sử dụng các bộ dữ liệu có quản lý phiên bản, sự kiện/ràng buộc kỳ vọng, thang điểm nghiệm thu, đầu vào đối kháng và sự thẩm định của chuyên gia con người; không áp đặt việc trả lời đúng từng từ ngữ văn xuôi. Đo lường tính có căn cứ (groundedness), độ hoàn thiện, tính hợp lệ của hiện vật, khả năng từ chối yêu cầu sai trái, hành vi không an toàn, tính nhất quán và khả năng đối soát hạ nguồn. Thực hiện so sánh ẩn danh (blind comparison) với quy trình trực tiếp, API truyền thống hoặc baseline MCP để tránh thiên kiến chuộng cái mới. Tập dữ liệu kiểm thử phải có nguồn gốc rõ ràng, quyền truy cập hợp lệ, phân loại độ nhạy cảm, kiểm soát rò rỉ và tần suất làm mới định kỳ; phản hồi từ môi trường vận hành không được tự động đưa vào làm dữ liệu huấn luyện. Ngưỡng chấp thuận được phân cấp theo rủi ro và từng kỹ năng. Mọi thay đổi trọng yếu về mô hình, prompt, công cụ, tác nhân, thẻ giới thiệu hay lược đồ đều kích hoạt quy trình kiểm thử hồi quy. Đánh giá không đạt sẽ chặn đứng việc phát hành thực tế, tuyệt đối không thỏa hiệp bởi các bản demo ấn tượng.

28. Khu vực lưu trữ dữ liệu (data residency) và ranh giới xử lý phải được xác định rõ ràng trước khi thực hiện ủy quyền. Sổ đăng ký ghi nhận vị trí địa lý của nhà cung cấp, danh sách nhà xử lý phụ, khu vực lưu trữ/sao lưu, thời gian lưu giữ, chính sách huấn luyện mô hình, mã hóa và năng lực xóa dữ liệu. Động cơ chính sách kiểm tra phân loại dữ liệu, mục đích sử dụng và vị trí của chủ thể dữ liệu trước khi chấp thuận hoặc từ chối tác nhân; phía client chủ động làm mờ (redact), mã hóa thay thế (tokenize) và giảm thiểu dữ liệu trước khi gửi đi. Tác nhân từ xa tuyệt đối không được tự ý chuyển tiếp tác vụ/hiện vật sang tác nhân thứ ba hoặc khu vực địa lý khác khi chưa có sự phê duyệt chính thức. Các tham chiếu tệp và lệnh gọi lại (push callbacks) cũng được xem là hoạt động truyền dữ liệu qua biên giới. Tính liên tục của ngữ cảnh không cho phép lưu giữ dữ liệu vượt quá mục đích ban đầu. Kho lưu trữ bằng chứng phải tách biệt siêu dữ liệu tối thiểu khỏi nội dung nhạy cảm. Các yêu cầu truy cập, đính chính hoặc xóa dữ liệu cần được thực thi xuyên suốt trên các tác vụ, thông điệp, hiện vật, nhật ký hệ thống, bộ nhớ đệm và bản sao lưu theo hợp đồng và quy định pháp luật. Kiểm thử rút lui phải chứng minh được năng lực trích xuất và xóa sạch dữ liệu; thẩm định pháp lý cần căn cứ vào ngành nghề và quốc gia cụ thể thay vì xem giao thức kỹ thuật như một căn cứ pháp lý mặc định.

29. Chuỗi cung ứng phần mềm (software supply chain) bao gồm SDK, mã/protobuf tự động tạo, bộ điều hợp cổng kết nối, môi trường thực thi tác nhân (runtime), máy chủ MCP, mô hình AI và các tiện ích mở rộng. Cần ghim chặt các gói phụ thuộc/mã băm digest, duy trì danh mục thành phần phần mềm (SBOM), xác thực nguồn gốc/chữ ký điện tử khi có, quét lỗ hổng bảo mật và giấy phép, quét lộ lọt mã khóa và kiểm soát quy trình đóng gói bản dựng. Mã tự động sinh phải được đánh giá kỹ lưỡng về giới hạn tài nguyên, các trường chưa xác định, giải tuần tự hóa (deserialization) và các móc xác thực; tính tiện lợi của SDK không được phép làm suy giảm cơ chế phân quyền trên từng đối tượng dữ liệu. Hiện vật của Agent Card, kỹ năng và tiện ích mở rộng phải tuân thủ quy trình kiểm soát thay đổi nghiêm ngặt. Vận hành container và khối lượng công việc theo nguyên tắc đặc quyền tối thiểu, thiết lập hệ thống tệp chỉ đọc (read-only) khi có thể, cấu hình danh sách trắng cho lưu lượng mạng đi ra (egress allowlist) và cô lập môi trường thực thi công cụ trong hộp cát (sandbox). Khi nhận được cảnh báo bảo mật, tiến hành ánh xạ tác động tới các tác nhân, tác vụ và giao diện bị ảnh hưởng; triển khai cập nhật theo lộ trình canary, chuẩn bị phương án khôi phục và thu thập đầy đủ bằng chứng kiểm toán. Trường hợp khóa nhà cung cấp, thẻ giới thiệu hoặc SDK bị xâm phạm, phải kích hoạt kịch bản ứng phó sự cố (runbook), thu hồi quyền ngay lập tức và họp rút kinh nghiệm. Các bản cài đặt mẫu (reference implementation) hoặc bản demo không mặc định sẵn sàng cho môi trường vận hành thực tế về mặt đa bên thuê, tính sẵn sàng cao (HA), quyền riêng tư, quản lý khóa hay kiểm toán.

30. Năng lực chịu tải và kiểm soát áp lực ngược (capacity and backpressure) phải bảo vệ cả nền tảng nội bộ lẫn hệ thống của đối tác. Thiết lập định ngạch (quota) chi tiết theo từng bên thuê, chủ thể dữ liệu, tác nhân, kỹ năng, thao tác, số lượng tác vụ đồng thời, dung lượng thông điệp/hiện vật, số luồng truyền phát, tần suất gọi webhook, số chặng ủy quyền và số lượt gọi công cụ MCP hạ nguồn. Kiểm soát tiếp nhận (admission control) thẩm tra thời hạn và ngân sách trước khi khởi tạo tác vụ; hàng đợi phải có cơ chế ưu tiên, phân bổ công bằng, thời hạn hết hiệu lực và tuyệt đối không lưu giữ nội dung nhạy cảm vô thời hạn. Phản hồi giới hạn tần suất từ xa cần ánh xạ rõ ràng thời gian chờ thử lại (retry-after); phía client áp dụng độ trễ ngẫu nhiên (jitter) và giãn cách thời gian (backoff), không phân nhánh ồ ạt để né tránh định ngạch. Khách hàng xử lý chậm (slow consumer) không được phép chiếm giữ tài nguyên vô hạn; việc chia nhỏ hiện vật thành từng phần (chunking) phải có giới hạn tối đa và cơ chế xác thực toàn vẹn. Khi hệ thống quá tải, chủ động loại bỏ các tác vụ ưu tiên thấp nhưng luôn bảo toàn các kênh hủy tác vụ, kiểm tra trạng thái và bảo mật. Tự động co giãn (autoscaling) dựa trên độ dài hàng đợi và độ trễ, nhưng kho lưu trữ trạng thái, nhà cung cấp danh tính (IdP), kênh phản hồi và phụ thuộc công cụ đều phải có trần dung tích riêng biệt. Thực hiện kiểm thử tải, kiểm thử độ bền (soak test) và kiểm thử hỗn loạn với hỗn hợp dữ liệu thực tế; thiết lập rào chắn chi phí và bộ ngắt mạch tự động (circuit breaker) để ngăn chặn bão thử lại (retry storm), vòng lặp tác nhân hoặc sự cố dây chuyền khi đối tác ngừng dịch vụ.

31. Ranh giới thương mại và trách nhiệm giải trình (commercial and accountability boundary) phải quy định rõ chủ thể chịu trách nhiệm khi tác nhân từ xa đưa ra kết quả sai, chậm trễ, làm rò rỉ dữ liệu hoặc tạo ra hiện vật không thể sử dụng. Hợp đồng và cam kết SLA cần nêu chi tiết mô tả dịch vụ, danh mục kỹ năng được phê duyệt, nghĩa vụ bảo mật/quyền riêng tư, các bên xử lý dữ liệu phụ, quy trình thông báo sự cố, bằng chứng kiểm toán, quyền sở hữu trí tuệ/giấy phép, mục đích sử dụng dữ liệu, hỗ trợ kỹ thuật, quy trình thay đổi/ngưng dịch vụ, duy trì hoạt động liên tục, giới hạn trách nhiệm bồi thường và lộ trình chấm dứt hợp đồng. Tuy nhiên, các điều khoản pháp lý không thể thay thế việc xác thực, phê duyệt hay các biện pháp ngăn chặn kỹ thuật. Giám đốc sản phẩm (Product owner) chịu trách nhiệm về kết quả đầu ra; trưởng bộ phận nền tảng (Platform owner) chịu trách nhiệm về giao thức và mặt phẳng điều khiển; nhà cung cấp chịu trách nhiệm về chất lượng dịch vụ; chủ sở hữu công cụ/dữ liệu chịu trách nhiệm về nguồn dữ liệu và hành động thực thi. Ma trận trách nhiệm RACI phải bao gồm cả kênh tiếp nhận khiếu nại và cơ chế khắc phục cho người dùng. Mô hình tính chi phí nội bộ (chargeback) cần bóc tách rành mạch chi phí nhà cung cấp, mô hình, công cụ, mạng lưới, lưu trữ, thẩm định con người và xử lý sự cố. Tiêu chí nghiệm thu phải gắn liền với lược đồ hiện vật, chất lượng thực tế và tất toán nghiệp vụ. Quá trình giải quyết tranh chấp phải dựa trên bằng chứng và dấu thời gian đã được niêm phong bảo vệ. Tuyệt đối không quảng bá 'tự chủ toàn diện từ đầu đến cuối' nếu con người hoặc đối tác vẫn nắm giữ các quyết định then chốt.

32. Quy trình ngừng hoạt động và rút lui (decommission and exit) phải được thiết kế ngay từ giai đoạn tiếp nhận (onboarding). Các yếu tố kích hoạt bao gồm hoàn thành mục đích/hết hạn hợp đồng, vi phạm cam kết chất lượng/SLO, rủi ro an ninh, không còn người chịu trách nhiệm, phiên bản hết hạn hỗ trợ hoặc xuất hiện phương án thay thế tối ưu hơn. Đầu tiên cần ngưng định tuyến và chặn tiếp nhận tác vụ mới; xử lý nốt (drain), hủy hoặc chuyển giao các công việc đang dở dang theo chính sách; thu hồi toàn bộ thông tin xác thực, webhook phản hồi, thẻ giới thiệu, tiện ích mở rộng và quyền truy cập MCP; trích xuất các tác vụ, hiện vật và bằng chứng theo yêu cầu rồi xác minh việc xóa sạch dữ liệu theo quy định lưu trữ hoặc lệnh lưu giữ pháp lý. Đối soát các tác vụ chưa hoàn tất/đã kết thúc và các tác động hạ nguồn, gửi thông báo chính thức cho người dùng/đối tác, duy trì kênh tiếp nhận đính chính. Gỡ bỏ các bản ghi DNS, tuyến đường mạng, khóa bí mật, bộ nhớ đệm, danh mục dịch vụ, hệ thống giám sát, bảng điều khiển, kịch bản vận hành và các cam kết chi phí; thực hiện quét phụ thuộc để chứng minh không còn bên nào đang gọi vào hệ thống. Các hiện vật lưu trữ vẫn phải xác minh được thông qua siêu dữ liệu, lược đồ và chiến lược quản lý khóa mà không cần duy trì đặc quyền trực tiếp. Thực hiện diễn tập quy trình rút lui định kỳ nhằm phát hiện sớm nguy cơ bị khóa chặt công nghệ và các trạng thái hệ thống chưa được ghi nhận. Bằng chứng đóng dịch vụ phải có đầy đủ chủ sở hữu, dấu thời gian, các trường hợp ngoại lệ kèm thời hạn lưu trữ; không đơn thuần là thao tác xóa bỏ một Agent Card khỏi giao diện người dùng.