Lịch sử điện toán phân tán luôn chứng kiến sự bùng nổ rồi hợp nhất của các giao thức. Từ CORBA, DCOM, Java RMI và SOAP cạnh tranh thị trường tích hợp doanh nghiệp cuối những năm 1990 trước khi REST âm thầm chiến thắng nhờ sự đơn giản và bản chất HTTP-native, đến XMPP, IRC phân mảnh tin nhắn thời gian thực trước khi MQTT và WebSockets tìm được chỗ đứng riêng. Mỗi kỷ nguyên điện toán mới đều tạo ra một loạt các tiêu chuẩn cạnh tranh, sau đó dần hội tụ khi các triển khai tích lũy và khả năng tương tác trở nên cần thiết về mặt kinh tế.
Hệ sinh thái tác nhân AI hiện đang ở giai đoạn "bùng nổ" tương tự. Chỉ trong mười tám tháng qua, bốn giao thức quan trọng đã được công bố: Model Context Protocol (MCP) từ Anthropic (cuối 2024), Agent Communication Protocol (ACP) từ IBM Research (tháng 3/2025), Agent2Agent (A2A) từ Google (tháng 4/2025), và Agent Network Protocol (ANP) từ một nhóm làm việc độc lập. Các tổ chức lớn như W3C AI Agent Protocol Community Group và Internet Engineering Task Force (IETF) cũng đã bắt đầu quá trình tiêu chuẩn hóa, cho thấy tầm quan trọng của việc hiểu rõ sự hội tụ này đối với các quyết định kiến trúc hiện tại.
🔎 **Các Giao Thức Hiện Có Đã Giải Quyết Điều Gì?**
Sự bùng nổ giao thức có vẻ hỗn loạn hơn thực tế, bởi hầu hết chúng giải quyết các lớp khác nhau của một ngăn xếp thay vì cạnh tranh cùng một vị trí. Sự nhầm lẫn đến từ cách tiếp thị, khi mô tả mỗi giao thức là "tiêu chuẩn cho giao tiếp tác nhân AI" mà không chỉ rõ khía cạnh nào của giao tiếp.
* MCP (Model Context Protocol): Đây là giao diện gọi công cụ. Nó xác định cách một mô hình khám phá các chức năng mà một máy chủ cung cấp, cách gọi chúng và cách diễn giải phản hồi. MCP là một hợp đồng RPC (remote procedure call) có kiểu chặt chẽ giữa máy khách mô hình và máy chủ công cụ, chạy trên HTTP. Đến tháng 4/2026, Linux Foundation xác nhận đã có hơn 10.000 máy chủ MCP công khai đang hoạt động và 164 triệu lượt tải xuống Python SDK hàng tháng. MCP đã giành chiến thắng ở lớp gọi công cụ, công việc tiêu chuẩn hóa về cơ bản đã hoàn tất. * A2A (Agent2Agent): Đây là giao diện phối hợp tác vụ. Nếu MCP định nghĩa cách một tác nhân gọi một công cụ, thì A2A lại định nghĩa cách hai tác nhân ủy quyền một tác vụ. Nó giới thiệu Agent Cards (quảng cáo khả năng), trạng thái vòng đời tác vụ và ba chế độ tương tác: đồng bộ, truyền trực tuyến và bất đồng bộ. Google đã tặng A2A cho Linux Foundation vào tháng 6/2025 và các nhóm AI doanh nghiệp đã áp dụng rộng rãi vì nó lấp đầy một khoảng trống thực sự mà MCP còn bỏ ngỏ. * ACP (Agent Communication Protocol): Đây là định dạng bao tin nhắn. Nhẹ, không trạng thái, được thiết kế cho trao đổi tin nhắn giữa các tác nhân mà không cần ngữ nghĩa phối hợp đầy đủ của A2A. Nó hữu ích trong các hệ thống mà việc truyền tin nhắn đơn giản là đủ và không cần đến chi phí quản lý vòng đời tác vụ của A2A. * ANP (Agent Network Protocol): Đây là giao thức khám phá và định danh. Nó sử dụng Decentralized Identifiers (DIDs) cho định danh tác nhân và biểu đồ JSON-LD cho mô tả khả năng, cung cấp nền tảng cho các thị trường tác nhân phi tập trung không yêu cầu sổ đăng ký trung tâm.
Tóm lại, một ngăn xếp đang hình thành gồm: khám phá khả năng qua ANP hoặc các sổ đăng ký đơn giản hơn, phối hợp tác vụ qua A2A, gọi công cụ qua MCP, và nhắn tin nhẹ qua ACP cho các trường hợp không yêu cầu quản lý vòng đời tác vụ đầy đủ. Các lớp này bổ trợ lẫn nhau chứ không cạnh tranh.
❌ **Bài Toán Giao Vận Nào Còn Đang Bỏ Ngỏ?**
Mỗi giao thức trong danh sách này đều chạy trên HTTP. Điều này phản ánh nguồn gốc của các giao thức: các nhóm nghiên cứu, nhà cung cấp API và công ty phần mềm doanh nghiệp xây dựng hệ thống nơi HTTP là một giả định không thể nghi ngờ. HTTP là giao thức họ biết, giao thức máy chủ của họ đã sử dụng và giao thức giúp việc demo trở nên dễ dàng.
Vấn đề trong môi trường sản xuất là HTTP giả định một máy chủ có thể truy cập được. Tuy nhiên, đằng sau NAT (Network Address Translation) – và 88% thiết bị nối mạng nằm sau NAT – thì không có máy chủ nào có thể truy cập được nếu không có máy chủ chuyển tiếp (relay). Đối với các đội tác nhân cần định tuyến tác vụ trực tiếp giữa các thiết bị ngang hàng qua các ranh giới đám mây, mạng gia đình và triển khai biên, việc tập trung hóa này buộc mọi thông điệp phải đi qua hạ tầng chuyển tiếp. Hạ tầng chuyển tiếp làm tăng độ trễ, chi phí và tạo ra một điểm lỗi.
Các giao thức ở tầng ứng dụng giải quyết ngữ nghĩa của "điều gì" các tác nhân nói với nhau. Chúng không giải quyết "làm thế nào" các tác nhân tìm thấy nhau và thiết lập kết nối trực tiếp. Đó là vấn đề của tầng phiên (Layer 5) trong mô hình OSI, và không một giao thức nào trong số MCP, A2A, ACP, hay ANP giải quyết được nó.
💡 **Lời Giải Cho Giao Vận Có Thể Đến Từ Đâu?**
Các công nghệ để giải quyết vấn đề giao vận đã tồn tại. UDP hole-punching với STUN (Session Traversal Utilities for NAT) cung cấp khả năng xuyên NAT cho khoảng 70% các cấu trúc mạng. X25519 Diffie-Hellman và AES-256-GCM cung cấp mã hóa xác thực ở cấp độ đường hầm mà không cần cơ quan cấp chứng chỉ. QUIC (Quick UDP Internet Connections) (RFC 9000) hoặc các giao thức cửa sổ trượt tùy chỉnh qua UDP cung cấp khả năng phân phối đáng tin cậy mà không bị tắc nghẽn đầu dòng của TCP. Đây chính là những nguyên tắc cơ bản mà WireGuard sử dụng cho đường hầm VPN và WebRTC dùng cho luồng truyền thông trình duyệt-tới-trình duyệt.
Điểm khác biệt trong bối cảnh tác nhân là định tuyến dựa trên khả năng. Các tác nhân cần tìm các thiết bị ngang hàng không phải bằng tên máy chủ mà bằng khả năng của chúng. Một tác nhân nghiên cứu nên có thể hỏi "những tác nhân nào có dữ liệu ngoại hối thời gian thực?" và nhận được danh sách các tác nhân chuyên biệt đang hoạt động. Điều này gần giống với một sổ đăng ký dịch vụ hơn là DNS, và là một phần mở rộng tự nhiên của triết lý thiết kế ANP áp dụng cho tầng giao vận.
Một số dự án đang ghép nối các mảnh ghép này lại. Pilot Protocol có đặc tả hoàn chỉnh nhất được công bố, với một bản dự thảo Internet-Draft của IETF bao gồm định địa chỉ, thiết lập đường hầm và xuyên NAT cho mạng tác nhân. Libp2p cung cấp một nền tảng vững chắc với các nguyên tắc cơ bản tương tự. Nhóm làm việc QUIC của IETF cũng đang phát triển các tiện ích mở rộng xuyên NAT sẽ có liên quan ở đây.
🚀 **Con Đường Hội Tụ Sẽ Trông Như Thế Nào?**
Các giao thức dựa trên HTTP (MCP, A2A) đã và đang hội tụ về các phiên bản ổn định. Trong 12 tháng tới, chúng ta sẽ thấy sự củng cố trong sản xuất, cải thiện bảo mật, máy chủ MCP không trạng thái để mở rộng quy mô ngang, và liên kết A2A tốt hơn – thay vì các thiết kế cơ bản mới. Các lớp gọi công cụ và phối hợp tác vụ về cơ bản đã được giải quyết.
Lớp giao vận đang chậm hơn 18 đến 24 tháng. Dự kiến sẽ có một thời kỳ đa dạng triển khai khi các nhóm thử nghiệm các phương pháp khác nhau cho mạng tác nhân P2P (peer-to-peer), sau đó là sự hợp nhất xung quanh một số ít triển khai khi dữ liệu thực nghiệm về hiệu suất và độ tin cậy được tích lũy. Các lộ trình tiêu chuẩn hóa của IETF và W3C có thể sẽ đưa ra kết quả vào khoảng năm 2027-2028, thời điểm mà một hoặc hai triển khai mã nguồn mở đã tích lũy đủ triển khai sản xuất để thiết lập các tiêu chuẩn de facto trước khi có đặc tả chính thức.
Đối với các nhà lãnh đạo kỹ thuật đưa ra quyết định kiến trúc hiện nay, ý nghĩa thực tế là áp dụng theo từng lớp. Các giao thức lớp ứng dụng đủ ổn định để xây dựng. Việc áp dụng MCP hiện tại là ít rủi ro. Việc áp dụng A2A cho phối hợp đa tác nhân là hợp lý với kỳ vọng giao thức sẽ phát triển. Lớp giao vận là nơi bạn có thể phải xây dựng một giải pháp tùy chỉnh và lên kế hoạch thay thế nó sau này, hoặc đánh giá các triển khai ban đầu với nhận thức rằng không gian này vẫn đang thay đổi.
Các nhóm sẽ có nhiều lợi thế nhất khi lớp giao vận ổn định là những nhóm đã thiết kế hệ thống tác nhân của mình với sự tách biệt rõ ràng giữa ngữ nghĩa ứng dụng (MCP, A2A) và giao vận (bất cứ thứ gì nằm bên dưới). Sự tách biệt rõ ràng này rẻ để triển khai ngay bây giờ và tốn kém để điều chỉnh sau này, một bài học mà kỷ nguyên microservices đã dạy cho bất kỳ ai cố gắng thêm khả năng quan sát hoặc ngắt mạch vào các hệ thống không có chúng.
Nguồn: Philip Stayetski, đồng sáng lập Vulture Labs.