Giao thức A2A (Agent2Agent)

1. Tổng quan

Định nghĩa: A2A (Agent2Agent) là một giao thức tầng ứng dụng mở, chuẩn hóa cách các tác nhân AI tự trị được xây dựng trên các nhà cung cấp và framework khác nhau khám phá lẫn nhau, ủy thác và cộng tác trong công việc mà không phải phơi bày phần hiện thực nội bộ của mình. Đó là một "chuẩn tương tác liên thông cho các tác nhân" vận hành trên nền tảng khám phá dựa trên siêu dữ liệu tác nhân (Agent Card) và một mô hình đối tượng chung gồm Task, Message và Artifact.

Khi AI tạo sinh tiến hóa vượt khỏi hỏi-đáp đơn giản để bước vào thể chế đa tác nhân (Multi-Agent), nơi nhiều tác nhân chuyên biệt hợp tác để thực hiện các nghiệp vụ phức hợp, bài toán lớn nhất đã chuyển từ năng lực suy luận của mô hình sang làm thế nào để kết nối an toàn các tác nhân dị chủng. Trong thực tế doanh nghiệp, tác nhân phân tích CRM được dựng trên framework của hãng A (LangGraph), tác nhân điều phối lịch trên giải pháp của hãng B, còn tác nhân phê duyệt nội bộ do tự phát triển, nghĩa là nhà cung cấp, runtime và ngôn ngữ đều khác nhau. Muốn cho chúng cộng tác thì phải làm một bộ chuyển đổi (adapter) riêng cho từng cặp tác nhân, và điều này tái hiện địa ngục tích hợp điểm-đến-điểm N×N từng gặp trong tích hợp hệ thống, nay trong thế giới tác nhân.

A2A giải quyết vấn đề này bằng cách thiết lập một quy ước chung cho truyền thông giữa các tác nhân. Khi một tác nhân công bố tấm danh thiếp chuẩn (Agent Card) mô tả chính mình, các tác nhân khác đọc nó để nắm "nó làm được gì" và ủy thác công việc qua các thông điệp chuẩn. Triết lý cốt lõi là tính mờ đục (Opacity): một tác nhân từ xa nhận công việc được ủy thác không phơi bày suy luận nội bộ, prompt hay các công cụ nó dùng, mà chỉ trao đổi trạng thái tác vụ và sản phẩm đầu ra. Nhờ đó vẫn cộng tác được trong khi bảo vệ tài sản trí tuệ, tạo nền tảng cho một Web of Agents nơi các tác nhân tiêu thụ lẫn nhau như những "dịch vụ" có thể thay thế được.

A2A được Google công bố vào tháng 4 năm 2025 cùng khoảng 50 đối tác, và vào tháng 6 năm 2025 được hiến tặng cho Linux Foundation, chuyển sang quản trị trung lập không phụ thuộc nhà cung cấp cụ thể. Bối cảnh ra đời rất rõ. Giống như dịch vụ web từng được chuẩn hóa bằng SOAP/REST và microservice bằng gRPC, có một ý thức cấp bách rằng hệ sinh thái tác nhân cũng sẽ phân mảnh thành các silo nếu thiếu một chuẩn tương tác liên thông. Đặc trưng của A2A là: thứ nhất, tái sử dụng các chuẩn web hiện có (HTTP, JSON-RPC 2.0, SSE, các lược đồ xác thực của OpenAPI) để hạ thấp rào cản áp dụng; thứ hai, thiết kế bảo mật và xác thực cấp doanh nghiệp như một yếu tố hạng nhất; thứ ba, hỗ trợ nguyên bản tác vụ chạy dài và bất đồng bộ (tác vụ kéo dài nhiều ngày vẫn theo dõi được); và thứ tư, tính trung lập về phương thức (modality) bao trùm văn bản, hình ảnh, âm thanh và dữ liệu có cấu trúc.

2. Cấu trúc tổng thể và các khái niệm cốt lõi của A2A

A2A vận hành thông qua tương tác giữa một tác nhân khách (Client Agent) yêu cầu công việc và một tác nhân từ xa (Remote Agent, A2A Server) thực hiện yêu cầu đó. Một tác nhân có thể là khách trong tình huống này và là máy chủ trong tình huống khác. Toàn bộ luồng có vòng đời "① khám phá → ② thương lượng → ③ thực hiện và theo dõi tác vụ → ④ nhận kết quả".

graph TB
    subgraph User["Người dùng / Bộ điều phối"]
        O["Tác nhân khách<br/>(Client Agent)"]
    end
    subgraph RemoteA["Tác nhân từ xa A (A2A Server)"]
        CardA["Agent Card<br/>(công bố .well-known)"]
        LogicA["Suy luận/công cụ nội bộ<br/>(mờ đục/riêng tư)"]
    end
    subgraph RemoteB["Tác nhân từ xa B (A2A Server)"]
        CardB["Agent Card"]
        LogicB["Logic nội bộ"]
    end
    O -->|"1.Khám phá: truy vấn Agent Card"| CardA
    O -->|"2.Ủy thác: tạo Task"| LogicA
    LogicA -->|"3.Trạng thái/kết quả: Task/Artifact"| O
    O -.->|"ủy thác song song"| CardB
    O -.-> LogicB
    LogicA -->|"ủy thác cấp dưới"| CardB

A. Agent Card (danh thiếp tác nhân) — Agent Card là một tài liệu siêu dữ liệu định dạng JSON do A2A server công bố, thường được đăng tại đường dẫn /.well-known/agent-card.json. Nó chứa thông tin năng lực (capability) như tên, phiên bản, mô tả của tác nhân; URL endpoint dịch vụ; danh sách kỹ năng (skills) sở hữu; các phương thức vào/ra được hỗ trợ; phương thức xác thực yêu cầu (OAuth 2.0, API Key, v.v.); và có hỗ trợ streaming, push hay không.

Kỹ năng (skill) được khai báo trong danh thiếp là các mục cấu trúc hóa các năng lực tác nhân có thể thực hiện kèm mô tả bằng ngôn ngữ tự nhiên, và là căn cứ để tác nhân khách (hoặc LLM điều phối) thực hiện định tuyến dựa trên ngữ nghĩa cho câu hỏi "gửi yêu cầu này đến tác nhân nào". Nói cách khác, Agent Card vừa là đặc tả API cho máy đọc, vừa đóng vai trò một thư mục ngữ nghĩa giúp LLM suy luận để chọn cộng tác viên phù hợp.

Bản chất của Agent Card là nó không phải lời giới thiệu đơn thuần mà là điểm khởi đầu của tương tác liên thông. Giống như một người quyết định có vào quán hay không khi nhìn biển hiệu và thực đơn, tác nhân khách đọc danh thiếp để phán đoán động tại thời điểm chạy (runtime) rằng "tác nhân này có xử lý được tác vụ của tôi không, cần xác thực gì". Đây là việc dời vai trò mà thư mục dịch vụ (UDDI) hay đặc tả OpenAPI từng đảm nhận sang thế giới tác nhân, cho phép ghép lỏng (loose coupling) và khám phá động mà không cần tích hợp mã cứng sẵn. Ví dụ, nếu một bộ điều phối đặt vé du lịch chỉ cần đăng ký danh thiếp của một tác nhân hãng hàng không mới, nó có thể nạp tác nhân đó làm ứng viên cộng tác mà không cần thay đổi mã.

B. Task (tác vụ) — Task là đơn vị công việc cơ bản mà A2A theo dõi; nó có ID duy nhất và tuân theo một máy trạng thái (state machine) tường minh như submitted → working → input-required → completed/failed/canceled. Một Task duy trì vòng đời qua nhiều lần trao đổi thông điệp, nên mọi thứ từ một truy vấn kết thúc trong vài giây đến một quá trình thẩm định/phê duyệt kéo dài nhiều ngày đều có thể xử lý bằng cùng một mô hình.

Việc nâng Task lên thành đối tượng hạng nhất có trạng thái (stateful) là một quyết định cốt lõi trong thiết kế A2A. Lý do là, trong khi một lời gọi REST truyền thống kết thúc bằng yêu cầu-phản hồi, cộng tác giữa các tác nhân về bản chất là chạy dài và bất đồng bộ. Một ủy thác "phân tích báo cáo tài chính của đối thủ và viết báo cáo" có thể mất vài giờ, và giữa chừng cần yêu cầu thêm thông tin (input-required) hoặc báo cáo tiến độ. Máy trạng thái của Task chuẩn hóa việc tạm dừng, nối lại và theo dõi như vậy, để tác nhân khách nhận các thay đổi trạng thái qua streaming SSE (Server-Sent Events) hoặc thông báo đẩy (Push Notification) thay vì thăm dò (polling).

C. Message và Part (thông điệp và phần) — Message là một lượt phát biểu (turn) riêng lẻ được trao đổi giữa tác nhân khách và tác nhân, còn nội dung bên trong được chứa theo đơn vị Part. Part được chia thành TextPart (văn bản), FilePart (tệp/nhị phân) và DataPart (dữ liệu có cấu trúc như JSON), nên một thông điệp có thể truyền tải trộn lẫn nhiều phương thức.

Ngoài ra Message có phân biệt vai trò (role) để tách phát biểu của người dùng khỏi phản hồi của tác nhân, và nhiều Part có thể được gói vào một thông điệp để truyền "văn bản mô tả + tệp đính kèm + tham số có cấu trúc" trong một lần. Điều này giống như người ta gửi email kèm cả nội dung lẫn tệp đính kèm.

Trừu tượng hóa Part quan trọng vì nó cho phép thương lượng phương thức. Vì có tác nhân chỉ xử lý văn bản, có tác nhân xử lý cả hình ảnh và âm thanh, nên bên gửi cấu thành các Part khớp với các phương thức được hỗ trợ đã khai báo trong Agent Card của tác nhân nhận. Đây là thiết kế thương lượng dựa trên năng lực thay vì mã cứng định dạng nội dung, bảo đảm tính linh hoạt cho cộng tác giữa các tác nhân đa phương thức.

D. Artifact (sản phẩm đầu ra) — Artifact là sản phẩm cuối cùng mà một Task tạo ra (tệp báo cáo, hình ảnh được sinh, dữ liệu có cấu trúc, v.v.), được quản lý tách biệt với các thông điệp hội thoại. Nghĩa là bằng cách phân biệt "hội thoại trong quá trình" (Message) với "kết quả đã chốt" (Artifact), tác nhân khách thu gom rõ ràng chỉ những sản phẩm có thể bàn giao bất kể các trao đổi phụ ở giữa.

Sự tách biệt này có hàm ý thực tiễn lớn về tính lũy đẳng (idempotency) và tái sử dụng. Artifact của cùng một Task có thể được tham chiếu, lưu đệm và quản lý phiên bản theo định danh, giúp dễ kiểm toán (audit) kết quả cộng tác hoặc đưa lại làm đầu vào cho tác nhân kế tiếp. Ví dụ, nếu Artifact báo cáo phân tích do "tác nhân nghiên cứu thị trường" tạo ra được chuyển thẳng làm đầu vào cho "tác nhân sinh slide", thì chỉ sản phẩm đã chốt được truyền đi mà không cần phân tích lại nhật ký hội thoại trung gian, nên độ kết dính của đường ống tác nhân giảm xuống. Điều này tương tự việc áp dụng mẫu hình "tập dữ liệu bất biến (immutable dataset)" của kỹ nghệ dữ liệu vào cộng tác giữa các tác nhân.

Các đối tượng cốt lõi của A2A được tổng hợp trong bảng dưới. Tuy nhiên bảng chỉ là tóm tắt; lý do vì sao mỗi đối tượng được tách ra mới là bản chất đã trình bày trong các đoạn trên.

Khái niệm	Vai trò	Đặc điểm	Ẩn dụ
Agent Card	Công bố năng lực/endpoint/xác thực của tác nhân	Khám phá động, đăng `.well-known`	Danh thiếp/thực đơn
Task	Đơn vị theo dõi công việc (máy trạng thái)	Chạy dài/bất đồng bộ, tạm dừng/nối lại	Phiếu chỉ thị công việc
Message/Part	Lượt phát biểu riêng lẻ và nội dung đa phương thức	Trộn văn bản/tệp/dữ liệu	Một lượt hội thoại
Artifact	Sản phẩm cuối cùng	Tách khỏi thông điệp, tái sử dụng	Thành phẩm/vật giao nộp

3. Quy trình truyền thông và tầng truyền tải

Một cộng tác A2A điển hình tuân theo trình tự dưới đây. Đặc biệt, việc khám phá và ủy thác diễn ra động tại thời điểm chạy chính là khác biệt quyết định so với phương thức tích hợp cài sẵn.

sequenceDiagram
    participant C as Tác nhân khách
    participant S as Tác nhân từ xa(A2A Server)
    C->>S: 1. GET /.well-known/agent-card.json (khám phá)
    S-->>C: Agent Card (kỹ năng/xác thực/endpoint)
    C->>S: 2. Xác thực (OAuth2/API Key)
    C->>S: 3. message/send (tạo Task, ủy thác công việc)
    S-->>C: Task(status=working, id)
    loop tiến trình streaming
        S-->>C: 4. SSE: status-update (tiến độ/kết quả một phần)
    end
    S-->>C: 5. input-required (yêu cầu thêm thông tin)
    C->>S: 6. message/send (đầu vào bổ sung)
    S-->>C: 7. Task(status=completed) + Artifact

A. Khám phá (Discovery) — Tác nhân khách truy vấn Agent Card tại một URL đã biết hoặc registry để nắm năng lực và yêu cầu xác thực của đối tác. Nếu năng lực không khớp, nó tìm tác nhân khác. Việc khám phá diễn ra tại runtime là điều quyết định về mặt khả năng mở rộng: khi thêm một tác nhân mới, ta chỉ cần đăng ký danh thiếp của nó mà không sửa mã của các tác nhân hiện có, nên gánh nặng tích hợp O(N²) giảm còn O(N). Trong các tổ chức lớn, một mẫu hình phổ biến là lập một danh mục tác nhân nội bộ (registry) để quản lý tập trung các danh thiếp và áp dụng chính sách truy cập.

B. Xác thực/Phân quyền — A2A không tạo cơ chế xác thực riêng mà tái sử dụng các lược đồ xác thực chuẩn mà OpenAPI dùng (OAuth 2.0, OpenID Connect, API Key, mTLS, v.v.). Việc nó gắn tự nhiên lên hạ tầng IAM/gateway sẵn có của doanh nghiệp là động lực cốt lõi cho việc áp dụng ở quy mô doanh nghiệp. Nhờ thiết kế không phát minh lại bánh xe này, đội bảo mật có thể tái sử dụng nguyên trạng hệ thống phát hành/kiểm tra token đã được kiểm chứng, đồng thời phát hành các scoped token thu hẹp phạm vi chỉ cho cộng tác giữa các tác nhân.

C. Ủy thác và theo dõi tác vụ — Tác nhân khách tạo Task qua message/send (hoặc message/stream cho streaming). Tác vụ ngắn được trả về dưới dạng phản hồi đồng bộ, tác vụ dài báo tiến độ qua streaming SSE, còn tác vụ cực dài — nơi tác nhân khách có thể đang ngoại tuyến — được thông báo hoàn thành qua thông báo đẩy (webhook).

Ở tầng truyền tải, đặc tả A2A v1.0 định nghĩa mô hình dữ liệu một cách chuẩn tắc bằng Protocol Buffers và cung cấp ba ràng buộc (JSON-RPC 2.0, gRPC, HTTP+JSON/REST). Đây là thiết kế linh hoạt về truyền tải, cho phép chọn gRPC cho mạng nội bộ chú trọng hiệu năng và JSON-RPC/REST cho tương tác liên thông phổ quát. Lấy Protocol Buffers làm nguồn chân lý duy nhất (single source of truth), các tác nhân hiện thực bằng những ngôn ngữ khác nhau dùng mã được sinh từ cùng một schema, nên lỗi tích hợp do lệch trường bị giảm một cách có cấu trúc.

Nhìn vào một trường hợp áp dụng thực tế, tại thời điểm công bố A2A, Google đã công bố cùng khoảng 50 công ty như Salesforce, SAP, ServiceNow và PayPal, trình bày các kịch bản cộng tác giữa các tác nhân nghiệp vụ doanh nghiệp (ví dụ: trong quy trình tuyển dụng, tác nhân sàng lọc ứng viên ủy thác công việc cho tác nhân điều phối lịch và tác nhân tra cứu lý lịch). Như vậy A2A hướng tới việc trở thành mô liên kết (connective tissue) của tự động hóa nghiệp vụ doanh nghiệp chứ không phải một mô hình cụ thể.

4. Quan hệ giữa A2A và MCP — Bổ sung chứ không cạnh tranh

Hiểu lầm phổ biến nhất khi tiếp cận A2A là đặt nó vào quan hệ cạnh tranh với MCP (Model Context Protocol). Thực tế, cả hai là những thứ bổ sung chuẩn hóa các tầng khác nhau. Nếu MCP chuẩn hóa "một tác nhân kết nối thế nào tới công cụ và dữ liệu của chính nó" (theo chiều dọc, tác nhân-tới-công cụ), thì A2A chuẩn hóa "các tác nhân khác nhau cộng tác thế nào" (theo chiều ngang, tác nhân-tới-tác nhân). Đúng như cách nói tắt của giới chuyên môn: "MCP cho công cụ, A2A cho tác nhân."

graph TB
    subgraph AgentX["Tác nhân X"]
        LX["Lõi suy luận"]
        LX -->|"MCP"| T1["Công cụ/DB/API"]
    end
    subgraph AgentY["Tác nhân Y"]
        LY["Lõi suy luận"]
        LY -->|"MCP"| T2["Công cụ/Tệp"]
    end
    LX <-->|"A2A (cộng tác/ủy thác)"| LY

Mô hình minh bạch của hai bên cũng tương phản. Trong khi lời gọi công cụ MCP cho bên gọi thấy đối số và kết quả một cách minh bạch, A2A che giấu phần nội bộ của tác nhân từ xa một cách mờ đục. Đây là thiết kế có chủ đích nhằm bảo vệ tài sản trí tuệ và ranh giới bảo mật của đối tác cộng tác. Các kiến trúc production thực tế dùng hai chuẩn đồng thời. Ví dụ, "tác nhân quyết toán công tác phí" của một tổ chức kết nối qua MCP tới công cụ OCR hóa đơn và DB kế toán của chính nó, đồng thời ủy thác cộng tác qua A2A cho các "tác nhân tra cứu vé máy bay" và "tác nhân tỷ giá" bên ngoài. Bảng so sánh dưới đây được sắp xếp xoay quanh lý do căn bản làm nảy sinh khác biệt.

Phân loại	A2A	MCP
Đối tượng chuẩn hóa	Cộng tác tác nhân↔tác nhân (ngang)	Kết nối tác nhân↔công cụ/dữ liệu (dọc)
Đối tượng cốt lõi	Agent Card, Task, Artifact	Tool, Resource, Prompt
Tính minh bạch	Mờ đục (ẩn nội bộ)	Minh bạch (lộ đối số/kết quả)
Tương tác	Khám phá động, tác vụ dài, ủy thác	Gọi công cụ trong phiên
Dẫn dắt/quản trị	Google→Linux Foundation	Anthropic→mở

5. Chuyên sâu — Xu hướng chuẩn hóa và thách thức bảo mật

A2A đã mở rộng hệ sinh thái nhanh chóng chỉ trong một năm kể từ khi công bố. Tháng 6 năm 2025, nó bảo đảm quản trị trung lập nhờ việc hiến tặng cho Linux Foundation, và tháng 8 năm 2025, ACP (Agent Communication Protocol) của IBM được hợp nhất vào A2A, khiến các chuẩn cạnh tranh hội tụ. Tháng 12 năm 2025, Linux Foundation lập AAIF (Agentic AI Foundation) để quy tụ các chuẩn tác nhân, và A2A gia nhập làm một dự án được host. Sau v0.3.0 (giữa năm 2025), đặc tả ổn định v1.0 được công bố vào khoảng năm 2026, chốt một mô hình dữ liệu dựa trên Protocol Buffers và ba ràng buộc. Tuy nhiên thời điểm công bố v1.0 khác nhau giữa các nguồn, nên phiên bản và ngày chính xác cần được xác nhận theo đặc tả chính thức (a2a-protocol.org).

Về mặt bảo mật, việc A2A mở ra một bề mặt tấn công mới đang được nghiên cứu sôi nổi. Thứ nhất là vấn đề tin cậy Agent Card: nếu năng lực hay danh tính trên danh thiếp bị giả mạo, một tác nhân độc hại có thể mạo danh một cộng tác viên hợp lệ, nên cần cơ chế ký/kiểm chứng và hệ thống tin cậy registry. Thứ hai là rủi ro đại diện bị lẫn lộn (confused deputy) nơi đặc quyền lan truyền quá mức dọc theo chuỗi ủy thác (delegation chain), nên phải áp dụng đặc quyền tối thiểu và scoped token ở mỗi bước ủy thác. Thứ ba, chính tính mờ đục là con dao hai lưỡi, khiến khó giám sát hành vi của tác nhân độc hại từ bên ngoài. Các phân tích bảo mật học thuật về A2A (như A2ABreak) chỉ ra việc vượt xác thực/phân quyền, chiếm quyền tác vụ và lan truyền tiêm prompt là những mối đe dọa có hệ thống. Do đó, khi áp dụng thực tế phải song hành nguyên tắc zero-trust, danh tính theo từng tác nhân (workload identity kiểu SPIFFE) và ghi nhật ký kiểm toán toàn tuyến.

6. Điểm cân nhắc và hàm ý

Từ góc nhìn Kỹ sư chuyên nghiệp, việc áp dụng A2A không phải là một lựa chọn kỹ thuật đơn thuần mà là một nhiệm vụ chiến lược bao trùm kiến trúc tác nhân, quản trị và bảo mật, và cần cân nhắc đồng thời những điểm sau.

Chiến lược áp dụng (triển khai tiệm tiến): Thay vì dựng hệ đa tác nhân toàn doanh nghiệp cùng một lúc, một cách tiếp cận hai giai đoạn thực tế là trước hết chuẩn hóa tầng công cụ bằng MCP trong nội bộ, rồi áp dụng A2A có chọn lọc chỉ cho cộng tác vượt ranh giới tổ chức/nhà cung cấp. Đặt registry Agent Card và hệ thống ký danh thiếp làm nhiệm vụ tiên quyết của quản trị.
Đánh đổi (tính mờ đục vs khả năng quan sát): Tính mờ đục của A2A mang lại bảo vệ tài sản trí tuệ và ghép lỏng, nhưng làm khó việc gỡ lỗi, kiểm toán và truy vết trách nhiệm. Phải bổ sung khả năng quan sát bằng truy vết phân tán dựa trên ID tác vụ (tích hợp OpenTelemetry) và quản lý phiên bản Artifact.
Bảo mật/quy định (nơi quy trách nhiệm): Việc quy kết trách nhiệm pháp lý/hợp đồng cho một kết quả phát sinh khi một tác nhân tự trị ủy thác cho một tác nhân bên ngoài là mơ hồ. Hãy giới hạn phạm vi ủy thác bằng token/chính sách, và trong các ngành bị quản lý như tài chính, y tế, thiết kế tường minh các chốt kiểm (human-in-the-loop) vào máy trạng thái của Task.
Rủi ro độ trưởng thành của chuẩn: A2A vẫn đang tiến hóa nhanh (thay đổi phiên bản, chuyển giao quản trị), nên đừng ghép chặt vào một phiên bản cụ thể; hãy đặt một tầng adapter với tiền đề thương lượng phiên bản/tương thích ngược để hấp thụ chi phí chuyển đổi.
Công nghệ liên kết/triển vọng: Giá trị của A2A được tối đa hóa khi kết hợp với MCP (công cụ), các framework điều phối như LangGraph và AutoGen, cùng zero-trust/IAM. Về lâu dài, nó được kỳ vọng định hình thành giao thức nền tảng của một Nền kinh tế Tác nhân (Agent Economy) và Web of Agents nơi các tác nhân được giao dịch và khám phá như dịch vụ, và doanh nghiệp phải chủ động chuẩn bị từ bây giờ một hệ thống quản trị cho danh tính, danh thiếp và chính sách ủy thác tác nhân.

Tài liệu tham khảo

Trang chính thức A2A Protocol — https://a2a-protocol.org/
Wikipedia, "Agent2Agent" — https://en.wikipedia.org/wiki/Agent2Agent
Tyk, "A2A protocol: Architecture and technical specification" — https://tyk.io/learning-center/a2a-protocol-architecture-and-technical-specification/
Google Open Source Blog, "A year of open collaboration: Celebrating the anniversary of A2A" — https://opensource.googleblog.com/2026/04/a-year-of-open-collaboration-celebrating-the-anniversary-of-a2a.html
Palma.ai, "Agent2Agent (A2A) and MCP: What the Handover Means" — https://palma.ai/blog/A2A-linux-foundation-donation-comparison
A2ABreak: Systematic Security Analysis of the A2A Protocol (arXiv:2609.10871) — https://arxiv.org/pdf/2609.10871

Tóm tắt một câu: A2A là một giao thức tương tác liên thông mở cho phép các tác nhân AI dị chủng ủy thác và cộng tác trong công việc trong khi vẫn che giấu phần nội bộ, thông qua khám phá động dựa trên Agent Card và mô hình chung Task·Message·Artifact; nó bổ sung cho MCP theo kiểu "MCP cho công cụ, A2A cho tác nhân", và việc áp dụng thành công phụ thuộc vào thiết kế bảo mật/quản trị như tin cậy danh thiếp, đặc quyền ủy thác và khả năng quan sát.