A2A Protocol là gì? Chuẩn giao tiếp đa agent Agent-to-Agent

Khi các hệ thống AI phát triển bùng nổ nhưng rời rạc, A2A Protocol trở thành chiếc cầu nối kỹ thuật giúp các tác nhân thuộc nhiều nền tảng khác nhau tự phát hiện năng lực (discovery), ủy quyền tác vụ (delegation) và trao đổi ngữ cảnh bảo mật.

Giao thức này được chuyển giao quản lý cho Linux Foundation (thông qua Agentic AI Foundation - AAIF) từ tháng 6/2025 và chính thức ra mắt phiên bản v1.0 vào đầu năm 2026, với sự tham gia của các đối tác công nghệ lớn như Google, Microsoft, Salesforce, ServiceNow và Tyk. Đây là bước chuyển dịch mang tính nền tảng: từ các agent hoạt động biệt lập trong "vườn kín" (walled gardens) sang một mạng lưới liên bang (federated network) của các hệ thống AI chuyên biệt.

Về mặt kỹ thuật, A2A Protocol phân tách rạch ròi giữa mô hình dữ liệu chuẩn tắc và tầng truyền tải mạng. Tệp định nghĩa a2a.proto (Protocol Buffers) là nguồn chuẩn mực duy nhất (normative source) cho toàn bộ đặc tả; các lược đồ JSON Schema chỉ là sản phẩm phái sinh phục vụ môi trường web. Điều này đảm bảo tính nhất quán tuyệt đối về kiểu dữ liệu khi triển khai trên nhiều ngôn ngữ lập trình khác nhau như Go, Python hay Java.

Vì sao hệ thống đa agent cần một giao thức mở thay vì tích hợp tùy biến?

Thực trạng phát triển hệ thống multi-agent hiện nay đối mặt với sự phân mảnh công nghệ nghiêm trọng. Các đội ngũ kỹ sư xây dựng agent trên nhiều framework khác nhau như LangChain, CrewAI hay PydanticAI, dẫn đến việc phải viết hàng loạt đoạn mã tích hợp tùy biến (custom glue code). Khi một doanh nghiệp vận hành đồng thời trợ lý rà soát mã nguồn, bot đối soát tài chính và agent điều phối nhân sự, chi phí bảo trì các điểm kết nối và truyền tải ngữ cảnh giữa các quy trình (workflows) tăng theo cấp số nhân.

Việc thiếu vắng một tiêu chuẩn mở dẫn tới nguy cơ khóa chặt nhà cung cấp (vendor lock-in). Doanh nghiệp dễ bị ràng buộc vào hệ sinh thái SDK của một đơn vị duy nhất, gây khó khăn khi cần thay thế một mô hình suy luận hoặc tích hợp agent của đối tác bên ngoài. A2A Protocol giải quyết bài toán này tương tự như cách giao thức SMTP đã chuẩn hóa việc gửi nhận email trên toàn cầu: nó cho phép các máy chủ AI khác nhau trao đổi thông tin thông qua một bộ định tuyến và ngữ nghĩa chung mà không cần biết cấu trúc mã nguồn nội bộ của đối phương.

Khi xây dựng một mạng lưới liên bang (federated network) dựa trên tiêu chuẩn mở, các kỹ sư nền tảng có thể tự do định tuyến tác vụ qua các agent chuyên biệt. Thay vì phải định nghĩa lại API cho từng cặp tương tác, hệ thống tự động phát hiện năng lực của agent mới thông qua manifest chuẩn hóa, từ đó giảm thiểu nợ kỹ thuật (technical debt) và giúp kiến trúc compound AI mở rộng bền vững.

Nguyên lý thực thi hộp đen và phân tách quyền tự chủ trong A2A

Nguyên lý thiết kế cốt lõi của A2A Protocol là Opaque Execution (Thực thi hộp đen). Các agent cộng tác với nhau hoàn toàn dựa trên các năng lực (capabilities) và kỹ năng (skills) được công bố công khai, thay vì yêu cầu quyền truy cập trực tiếp vào trạng thái nội bộ (internal state), bộ nhớ dài hạn hay các công cụ cục bộ của nhau. Cách tiếp cận này bảo vệ tối đa quyền sở hữu trí tuệ và tính bảo mật dữ liệu của từng hệ thống trong chuỗi cung ứng agentic.

Quyền tự chủ (Autonomy) của mỗi agent được tôn trọng tuyệt đối thông qua việc phân tách logic suy luận. Trong mô hình A2A, agent nhận việc có toàn quyền tự lập kế hoạch (planning) và chọn chiến lược thực thi theo logic riêng, sau đó chỉ trả về kết quả cụ thể (Artifacts) cùng ngữ cảnh phản hồi. Việc không ép buộc agent phải chia sẻ toàn bộ "chuỗi suy nghĩ" (chain-of-thought) nội bộ là yếu tố then chốt trong môi trường doanh nghiệp đa phòng ban hoặc giữa các tổ chức đối tác, nơi việc lộ lọt prompt hệ thống hay dữ liệu trung gian là điều tối kỵ.

Sự phân tách trách nhiệm này đảm bảo tính toàn vẹn dữ liệu cho toàn hệ sinh thái. Một agent bên ngoài có thể tiếp nhận yêu cầu từ hệ thống trung tâm, tính toán và gửi lại kết quả mà không cần được cấp quyền truy cập vào cơ sở dữ liệu nội bộ của doanh nghiệp. A2A thiết lập một khung giao tiếp để các hệ thống "hộp đen" này tin cậy lẫn nhau thông qua các hợp đồng dữ liệu (data contracts) được định kiểu chặt chẽ.

Cơ chế khám phá năng lực agent thông qua Agent Card

Để các agent có thể tự động tìm kiếm và hiểu rõ năng lực của nhau, A2A định nghĩa một bản kê khai kỹ thuật gọi là Agent Card, được phân phối tại đường dẫn chuẩn hóa /.well-known/agent-card.json (tuân thủ RFC 8615). Đây là hồ sơ định danh chứa các thông tin quan trọng bao gồm tên (name), mô tả (description), các giao diện kết nối được hỗ trợ (supportedInterfaces), cờ tính năng (capabilities) và danh mục các kỹ năng cụ thể trong mảng skills[].

Mỗi phần tử trong skills[] mô tả chi tiết định dạng dữ liệu đầu vào và đầu ra (inputModes, outputModes) cùng các ví dụ gọi lệnh thực tế. Về mặt an ninh thông tin, mảng security ở cấp gốc của Agent Card sẽ ánh xạ các phạm vi truy cập (scopes) từ securitySchemes vào từng kỹ năng cụ thể, cho phép phân quyền chi tiết đến từng thao tác. Để ngăn chặn các cuộc tấn công giả mạo hoặc thay đổi thông tin định tuyến, Agent Card hỗ trợ chữ ký số AgentCardSignature sử dụng chuẩn JWS (RFC 7515) tính trên cấu trúc JSON đã được chuẩn hóa theo chuẩn JSON Canonicalization Scheme (RFC 8785).

Dưới đây là một ví dụ cấu hình Agent Card chuẩn v1.0 của một agent đặt vé máy bay doanh nghiệp:

{
  "name": "Corporate Flight Booking Agent",
  "description": "Handles domestic and international flight reservations.",
  "version": "1.0.0",
  "supportedInterfaces": [
    {
      "url": "https://flights.internal.corp/a2a",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "extendedAgentCard": false
  },
  "skills": [
    {
      "id": "book_flight",
      "name": "Book a flight",
      "description": "Books a flight given origin, destination, and dates.",
      "tags": ["travel", "booking"],
      "inputModes": ["application/json"],
      "outputModes": ["application/json"]
    }
  ],
  "securitySchemes": {
    "corp_oauth": {
      "type": "oauth2",
      "flows": {
        "clientCredentials": {
          "tokenUrl": "https://auth.corp/token",
          "scopes": {
            "flights:write": "Book flights"
          }
        }
      }
    }
  },
  "security": [{ "corp_oauth": ["flights:write"] }]
}

Mô hình hướng tác vụ: Vòng đời Task, Messages và Artifacts

Mọi tương tác trong A2A Protocol đều được tổ chức xoay quanh thực thể Task (Tác vụ). Mỗi tác vụ sở hữu một định danh duy nhất (taskId) và vận hành dựa trên một máy trạng thái hữu hạn (finite state machine) rõ ràng. Bước tiến quan trọng từ phiên bản v1.0 là việc loại bỏ cơ chế phân biệt kiểu thô sơ (kind discriminator) và thay thế cờ final: true bằng cơ chế đóng luồng dữ liệu (stream closure) tự nhiên khi tác vụ chuyển sang trạng thái kết thúc (terminal state).

Vòng đời của một Task trong A2A Protocol v1.0 bao gồm các trạng thái chuẩn hóa:

A2A phân định rõ ràng giữa hai khái niệm: Message và Artifact. Message là đơn vị hội thoại đa phương thức (chứa các Part dạng văn bản, dữ liệu nhị phân hoặc JSON) dùng để trao đổi ngữ cảnh qua lại giữa client và agent. Ngược lại, Artifact là sản phẩm đầu ra hoàn chỉnh của tác vụ (ví dụ: một tệp hóa đơn PDF hay một báo cáo phân tích tổng hợp). Trong các kịch bản phản hồi dạng dòng (streaming), A2A cung cấp sự kiện ArtifactUpdateEvent đi kèm các cờ append: true và lastChunk, cho phép agent truyền dần từng phần dữ liệu lớn về máy khách mà không cần đợi tạo xong toàn bộ tệp.

Các mẫu giao tiếp và tầng truyền tải: JSON-RPC, gRPC và REST

Kiến trúc đặc tả của A2A Protocol được cấu trúc thành 3 tầng độc lập:

1. Layer 1 (Canonical Data Model): Định nghĩa các thực thể cốt lõi (Task, Message, Part, Artifact) bằng Protocol Buffers (a2a.proto).
2. Layer 2 (Abstract Operations): Tập hợp các hành vi nghiệp vụ trừu tượng như SendMessage, GetTask, CancelTask, SubscribeToTask.
3. Layer 3 (Protocol Bindings): Ánh xạ cụ thể các thao tác trừu tượng sang các giao thức truyền tải mạng thực tế.

Nhờ sự phân tầng này, các agent duy trì được tính tương đương ngữ nghĩa (functional equivalence) dù giao tiếp qua bất kỳ tầng truyền tải nào. Tùy chọn triển khai phổ biến nhất trên môi trường web hiện nay là JSON-RPC 2.0 qua HTTPS POST. Kể từ phiên bản v1.0, tên phương thức được thống nhất thành SendMessage (thay vì quy ước message/send cũ). Các tham số dịch vụ bắt buộc như A2A-Version và các tiện ích mở rộng A2A-Extensions phải được truyền qua HTTP Headers:

POST /a2a HTTP/1.1
Host: agent.internal.corp
Content-Type: application/a2a+json
A2A-Version: 1.0
Authorization: Bearer <token>
 
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "SendMessage",
  "params": {
    "message": {
      "role": "ROLE_USER",
      "parts": [{ "text": "Phân tích số liệu doanh thu quý 1." }]
    },
    "configuration": { "returnImmediately": true }
  }
}

Đối với các tác vụ đòi hỏi cập nhật tiến độ thời gian thực, A2A sử dụng Server-Sent Events (SSE) qua thao tác SubscribeToTask. Với các luồng công việc bất đồng bộ kéo dài hàng giờ hoặc ngày, giao thức hỗ trợ cơ chế Push Notifications (Webhooks): máy chủ agent sẽ chủ động POST các gói tin sự kiện StreamResponse tới endpoint mà client đã đăng ký trước. Trong môi trường microservices nội bộ cần tối ưu độ trễ và thông lượng, gRPC là lựa chọn hàng đầu nhờ khả năng sinh mã trực tiếp từ file a2a.proto.

A2A và MCP: Trục ngang và trục dọc trong kiến trúc agentic

Một trong những hiểu lầm phổ biến nhất trong cộng đồng kỹ sư là xem A2A Protocol và Model Context Protocol (MCP) như hai tiêu chuẩn đối đầu nhau. Trên thực tế, hai giao thức này giải quyết hai bài toán hoàn toàn khác biệt và bổ trợ lẫn nhau trong kiến trúc AI tổng thể:

• MCP hoạt động theo trục dọc (Vertical): Kết nối một agent đơn lẻ với các công cụ, hàm cục bộ hoặc nguồn dữ liệu bên dưới (mô hình Client-to-Tool).
• A2A hoạt động theo trục ngang (Horizontal): Kết nối các agent độc lập với nhau như những thực thể bình đẳng qua ranh giới mạng hoặc ranh giới tổ chức (mô hình Agent-to-Agent).

Mối quan hệ cộng tác này có thể hình dung qua mô hình hoạt động của một Xưởng sửa xe:

• Shop Manager Agent giao tiếp qua A2A Protocol để tiếp nhận yêu cầu từ khách hàng và thương thảo với các agent của đối tác cung ứng phụ tùng bên ngoài.
• Mechanic Agent nhận nhiệm vụ được giao, sau đó sử dụng MCP để kết nối trực tiếp vào các thiết bị vật lý như máy quét lỗi động cơ (diagnostic scanner) hoặc hệ thống nâng xe nhằm lấy dữ liệu chẩn đoán thực tế.
• Sau khi có mã lỗi, Mechanic Agent lại dùng A2A để ủy quyền tác vụ kiểm tra kho linh kiện cho Remote Parts Supplier Agent.

Thách thức kỹ thuật và các đánh đổi khi đưa A2A lên production

Dù đặc tả A2A v1.0 đã tương đối toàn diện, các kỹ sư hệ thống khi triển khai thực tế trên môi trường production vẫn phải đối mặt với không ít khoảng trống kỹ thuật:

• Payload của từng kỹ năng chưa có schema chuẩn: A2A hiện tại chưa áp đặt cấu trúc JSON Schema cố định cho tham số đầu vào của từng AgentSkill. Để tránh lỗi phân tích cú pháp giữa các hệ thống độc lập, cách xử lý thực dụng nhất là nhúng thẳng schema vào trường description của kỹ năng hoặc khai thác cơ chế Extension (theo Section 4.6 của đặc tả) để ràng buộc kiểu dữ liệu.
• Rủi ro lan truyền quyền hạn trong chuỗi ủy quyền (Delegation Creep): Khi Agent A nhờ Agent B làm việc, rồi Agent B lại gọi tiếp sang Agent C, việc chuyển tiếp nguyên vẹn token ban đầu của người dùng sẽ mở toang cánh cửa bảo mật. Bạn nên áp dụng chuẩn OAuth 2.0 Token Exchange (RFC 8693) kết hợp với Rich Authorization Requests (RFC 9396) để hạ cấp phạm vi token (downscoping), chỉ cấp phát cho agent cấp dưới các quyền tối thiểu phục vụ đúng tác vụ đó.
• Nghịch lý quan sát phân tán (Distributed Observability): Trong một mạng lưới multi-agent phức tạp, việc gỡ lỗi một tác vụ thất bại ở mắt xích thứ 3 hay thứ 4 sẽ là bất khả thi nếu thiếu ngữ cảnh truy vết. Việc tích hợp OpenTelemetry và đính kèm tiêu đề chuẩn W3C Trace Context (traceparent) vào mọi yêu cầu A2A là kỷ luật bắt buộc để tái dựng toàn bộ hành trình xử lý phân tán.
• Kỷ luật xử lý mã lỗi: Hệ thống máy khách phải luôn bám sát việc phân tích mã lỗi theo chuẩn JSON-RPC (chẳng hạn -32001 tương ứng với TaskNotFound), giúp phân biệt dứt khoát giữa lỗi mạng tạm thời cần retry và lỗi nghiệp vụ từ chối vĩnh viễn.

Khi nào kiến trúc của bạn thực sự cần đến A2A?

Không phải mọi bài toán AI đều đòi hỏi việc áp dụng A2A Protocol. Nếu ứng dụng của bạn chỉ là một chuỗi logic tuyến tính do một đội ngũ duy nhất phát triển, việc sử dụng các thư viện điều phối nội bộ là phương án gọn nhẹ và tiết kiệm nhất. Ngược lại, việc đầu tư vào A2A Protocol trở nên cấp thiết khi hệ thống xuất hiện các yếu tố sau:

• Cộng tác xuyên tổ chức hoặc phòng ban: Các agent thuộc các nhóm kỹ thuật hoặc pháp nhân khác nhau cần làm việc chung mà không thể chia sẻ trực tiếp mã nguồn hoặc cơ sở dữ liệu.
• Kiến trúc module hóa đa ngôn ngữ: Doanh nghiệp muốn linh hoạt thay thế từng thành phần agent (chẳng hạn chuyển đổi một worker từ Python sang Go) mà không gây ảnh hưởng đến toàn bộ hệ sinh thái xung quanh.
• Tác vụ bất đồng bộ dài hạn: Quy trình nghiệp vụ đòi hỏi sự tham gia ngắt quãng của con người (Human-in-the-loop) hoặc xử lý kéo dài nhiều giờ với độ tin cậy cao.
• Quy mô lớn cần khám phá động: Môi trường doanh nghiệp vận hành hàng trăm micro-agent chuyên biệt và cần khả năng tự động khám phá năng lực qua bản kê khai Agent Card.

Từ góc độ vận hành hạ tầng, phương pháp tốt nhất khi triển khai A2A là đặt các agent phía sau một API Gateway (như Tyk hoặc Envoy). Lớp cổng kết nối này sẽ chịu trách nhiệm đảm nhận các tác vụ hạ tầng dùng chung như xác thực mTLS, kiểm tra tính hợp lệ của chữ ký Agent Card, giới hạn tốc độ gọi lệnh (rate limiting) và ghi log tập trung. Nhờ đó, mã nguồn của agent có thể hoàn toàn tập trung vào logic suy luận nghiệp vụ của mô hình AI.

Tài liệu tham khảo

• System Design One: Agent-to-Agent Protocol
• Agent2Agent (A2A) Protocol Specification v1.0.0 (Linux Foundation / AAIF)
• A2A Protocol Concepts: What is A2A?
• A2A and Model Context Protocol (MCP) Comparison
• Google Cloud: Announcing the Agent2Agent (A2A) Protocol
• Tyk: A2A Protocol - The Definitive Agent-to-Agent Guide
• IETF RFC 8615, RFC 7515, RFC 8785, RFC 8693, RFC 9396