Hầu hết các hệ thống AI hiện nay đều là các tác nhân đơn lẻ. Một mô hình, một vòng lặp lời nhắc, một bộ công cụ. Điều này hoạt động tốt cho đến khi công việc quá lớn đối với một tác nhân, hoặc cho đến khi bạn cần một tác nhân được xây dựng bởi một nhóm khác để xử lý một bước mà tác nhân của bạn không thể. Khi đó bạn sẽ gặp phải một rào cản: không có cách tiêu chuẩn nào để hai tác nhân độc lập tìm thấy nhau, trao đổi công việc và báo cáo kết quả. Agent2Agent (A2A) là giao thức được xây dựng để loại bỏ rào cản đó.
Hướng dẫn này giải thích A2A là gì, vấn đề nó giải quyết, cách nó hoạt động ngầm, và cách nó khác với MCP. Nếu bạn muốn kiểm tra một tác nhân A2A sau khi đọc bài này, hướng dẫn Apidog A2A Debugger sẽ tiếp nối từ phần cuối của bài viết này.
Agent2Agent (A2A) là gì?
Agent2Agent (A2A) là một giao thức mở để liên lạc giữa các tác nhân AI. Nó định nghĩa cách một tác nhân quảng bá khả năng của mình, cách một tác nhân khác kết nối với nó, cách hai bên trao đổi tin nhắn và tệp, và cách trạng thái tác vụ được gửi về cho bên gọi.
Từ khóa chính là giữa. A2A không phải là việc cung cấp thêm công cụ cho một tác nhân. Đó là việc cho phép các tác nhân riêng biệt, thường được xây dựng trên các framework khác nhau bởi các nhóm khác nhau, làm việc cùng nhau mà không bên nào cần biết nội bộ của bên kia.
Hãy hình dung A2A như HTTP dành cho lưu lượng tác nhân. HTTP cho phép trình duyệt nói chuyện với bất kỳ máy chủ web nào mà không cần quan tâm máy chủ chạy bằng ngôn ngữ gì. A2A cho phép một tác nhân LangGraph nói chuyện với một tác nhân CrewAI mà không cần quan tâm tác nhân đó được xây dựng như thế nào. Cả hai bên đều đồng ý về cấu trúc chung; không bên nào tiết lộ chi tiết triển khai của mình.
Google giới thiệu A2A vào năm 2025 và sau đó chuyển giao cho Linux Foundation như một dự án trung lập với nhà cung cấp. Đặc tả kỹ thuật được công bố công khai trên kho lưu trữ GitHub của A2A, và các triển khai tham chiếu được công bố tại trang dự án A2A.
Vấn đề A2A giải quyết
Trước A2A, việc kết nối hai tác nhân đồng nghĩa với việc viết mã "keo dán" (glue code). Mọi cặp kết nối đều là tùy chỉnh. Nếu tác nhân của bạn cần gọi tác nhân nghiên cứu của một nhóm đối tác, ai đó sẽ viết một client riêng, chọn hình dạng payload, tạo ra một cơ chế xác thực và duy trì tất cả bằng tay. Việc kết nối tiếp theo lại bắt đầu từ con số không.
Cách tiếp cận đó nhanh chóng gặp vấn đề:
- Không có khả năng khám phá. Không có cách tiêu chuẩn nào để một tác nhân hỏi “bạn có thể làm gì?” trước khi gửi công việc.
- Không có mô hình tác vụ chung. Một tác nhân trả về một chuỗi văn bản thuần túy, một tác nhân khác trả về một khối JSON tùy chỉnh, một tác nhân thứ ba truyền các token. Bên gọi phải xử lý từng trường hợp riêng biệt.
- Không có xác thực chung. Mọi tích hợp đều phải tạo lại thông tin đăng nhập và tiêu đề.
- Không có khả năng tương tác. Một tác nhân được xây dựng trên AutoGen không thể thay thế cho một tác nhân được xây dựng trên LangGraph, ngay cả khi chúng thực hiện cùng một công việc.
A2A khắc phục điều này theo cách OpenAPI đã khắc phục các tích hợp REST: một hợp đồng đã được thống nhất, để bất kỳ tác nhân tuân thủ nào cũng có thể nói chuyện với bất kỳ tác nhân tuân thủ nào khác.
A2A hoạt động như thế nào
A2A có bốn khái niệm cốt lõi. Một khi bạn nắm được chúng, toàn bộ giao thức sẽ nằm gọn trong đầu bạn.
Thẻ tác nhân (Agent Card)
Thẻ tác nhân (Agent Card) là một tài liệu JSON mà một tác nhân công bố để mô tả chính nó. Đây là điểm khởi đầu để khám phá. Nó liệt kê tên, mô tả, khả năng, kỹ năng đã khai báo, các loại đầu vào và đầu ra được hỗ trợ, yêu cầu xác thực và phiên bản giao thức của tác nhân.
Theo quy ước, thẻ này nằm ở một đường dẫn được biết đến, thường là https://your-agent.example.com/.well-known/agent.json. Một tác nhân gọi sẽ tìm nạp URL đó trước, đọc thẻ và biết chính xác những gì nó có thể yêu cầu trước khi gửi một tin nhắn duy nhất.
Tác vụ
Tác vụ là đơn vị công việc trong A2A. Khi một tác nhân yêu cầu một tác nhân khác làm điều gì đó, yêu cầu đó trở thành một tác vụ với ID riêng và trạng thái di chuyển qua các trạng thái như submitted (đã gửi), working (đang thực hiện), input-required (yêu cầu đầu vào) và completed (đã hoàn thành). Bên gọi có thể thăm dò tác vụ hoặc đăng ký nhận cập nhật. Mô hình tác vụ chia sẻ này là điều giúp các tác nhân A2A có thể hoán đổi cho nhau; bên gọi xử lý trạng thái theo cùng một cách bất kể ai đang thực hiện công việc.
Tin nhắn và tạo phẩm
Một tin nhắn mang nội dung thực tế giữa các tác nhân. Một tin nhắn được tạo thành từ nhiều phần: một phần văn bản, một phần tệp, dữ liệu có cấu trúc hoặc hỗn hợp. Tác nhân nhận sẽ đọc các phần mà kỹ năng của nó cần.
Khi tác nhân hoàn thành, nó sẽ trả về các tạo phẩm (artifacts); đó là các đầu ra có cấu trúc của tác vụ. Một tạo phẩm có thể là một tài liệu được tạo, một bảng dữ liệu, một bản tóm tắt hoặc một tham chiếu tệp. Các tạo phẩm cũng được xây dựng từ nhiều phần, do đó định dạng vẫn nhất quán theo cả hai hướng.
Truyền trực tuyến và cập nhật
Các tác vụ chạy dài không nhất thiết phải chặn. A2A hỗ trợ các sự kiện được gửi từ máy chủ (server-sent events), vì vậy một tác nhân có thể truyền trực tuyến các kết quả một phần và các thay đổi trạng thái khi công việc tiến triển. Một tác nhân nghiên cứu có thể thông báo “đã tìm thấy 3 nguồn” trước khi đưa ra báo cáo cuối cùng. Bên gọi sẽ hiển thị tiến trình thay vì chỉ nhìn chằm chằm vào biểu tượng chờ.
Tổng hợp lại, một giao dịch A2A điển hình trông như thế này:
- Tác nhân A tìm nạp Thẻ tác nhân của Tác nhân B và đọc các kỹ năng của nó.
- Tác nhân A gửi một tin nhắn tạo ra một tác vụ.
- Tác nhân B thực hiện tác vụ và truyền trực tuyến các cập nhật trạng thái.
- Tác nhân B trả về các tạo phẩm khi tác vụ đạt trạng thái
completed(đã hoàn thành). - Tác nhân A tiêu thụ các tạo phẩm và tiếp tục.
Toàn bộ cuộc hội thoại là JSON qua HTTP. Không có gì quá xa lạ.
A2A so với MCP
A2A và Giao thức ngữ cảnh mô hình (MCP) thường xuyên bị nhầm lẫn vì cả hai đều liên quan đến tác nhân và đều là các giao thức mở. Tuy nhiên, chúng giải quyết các vấn đề khác nhau.
| A2A | MCP | |
|---|---|---|
| Kết nối | Giữa các tác nhân | Giữa tác nhân với công cụ và dữ liệu |
| Câu hỏi nó trả lời | “Một tác nhân khác có thể thực hiện bước này cho tôi không?” | “Tác nhân này có thể tiếp cận những công cụ và tài nguyên nào?” |
| Sử dụng điển hình | Luồng công việc đa tác nhân giữa các nhóm | Một tác nhân đơn lẻ gọi cơ sở dữ liệu, hệ thống tệp hoặc API |
| Đơn vị trao đổi | Tác vụ, tin nhắn, tạo phẩm | Cuộc gọi công cụ, tài nguyên, lời nhắc |
MCP là cách một tác nhân tiếp cận vào bên trong các hệ thống bên ngoài. A2A là cách một tác nhân tiếp cận ra bên ngoài để tương tác với một tác nhân khác. Một hệ thống sản xuất thực tế thường sử dụng cả hai: một tác nhân sử dụng MCP để truy vấn cơ sở dữ liệu và A2A để giao một tác vụ phụ cho một tác nhân chuyên gia. Bài viết so sánh máy chủ MCP và A2A đi sâu vào quyết định này, và trình gỡ lỗi client MCP của Apidog cho thấy khía cạnh MCP trong thực tế.
Hợp tác đa tác nhân trong thực tế
A2A là một cách để các tác nhân cộng tác, nhưng không phải là cách duy nhất. Một số hệ thống thay vào đó sử dụng điều phối trực tiếp, nơi một tác nhân lập kế hoạch công việc và ủy quyền rõ ràng cho tác nhân khác.
Một ví dụ mã nguồn mở rõ ràng là Codex-Claude-Collab, một kỹ năng điều phối quy trình làm việc theo thời gian thực giữa OpenAI Codex và Claude Code. Codex lập kế hoạch tác vụ, ủy quyền việc triển khai cho Claude Code, sau đó xem xét sự khác biệt và xác minh kết quả trước khi trả lời người dùng. Đây là một vòng lặp chặt chẽ giữa tác nhân lập kế hoạch và tác nhân xây dựng giữa hai tác nhân mã hóa khác nhau.
Mô hình đó là một sự điều phối cố định; một bên biết chính xác bên kia là ai. A2A khái quát hóa ý tưởng tương tự: thay vì Codex biết rằng nó đang gọi cụ thể Claude Code, một tác nhân gọi A2A đọc Thẻ tác nhân và làm việc với bất kỳ tác nhân tuân thủ nào trả lời. Điều phối rất tuyệt vời khi bạn kiểm soát cả hai đầu. A2A là thứ bạn muốn khi các tác nhân độc lập, thuộc sở hữu của các nhóm khác nhau hoặc cần có thể hoán đổi. Hầu hết các hệ thống trưởng thành đều kết thúc với cả hai: điều phối nội bộ nhóm, A2A xuyên biên giới nhóm.
Cách kiểm tra một tác nhân A2A
Khi bạn đã xây dựng hoặc sử dụng một tác nhân A2A, bạn cần xem lưu lượng truy cập. Nhật ký console thường ẩn các trường có cấu trúc, và các tập lệnh kiểm thử tùy chỉnh sẽ trở nên lỗi thời. Đây là lúc một trình gỡ lỗi A2A trực quan phát huy tác dụng.
Apidog tích hợp A2A Debugger vào client tiêu chuẩn của mình. Bạn dán URL Thẻ tác nhân, nhấp Connect, và Apidog sẽ đọc thẻ và hiển thị tên, khả năng cũng như kỹ năng của tác nhân. Bạn gửi một tin nhắn thử nghiệm, đính kèm tệp, thêm siêu dữ liệu và đọc phản hồi dưới ba dạng xem: bản xem trước dễ đọc, nội dung thô và toàn bộ payload JSON-RPC. Nó xử lý Bearer Token, Basic Auth và tiêu đề API-key mà không cần curl.
Vấn đề cốt lõi là sự cô lập. Khi một tác nhân hoạt động không đúng, bạn muốn biết liệu lỗi là do truyền tải hay do logic của tác nhân. Việc xem payload truyền tải chính xác sẽ trả lời câu hỏi đó chỉ trong vài giây. Hướng dẫn Apidog A2A Debugger trình bày chi tiết một vòng lặp kết nối-gửi-đọc đầy đủ, và nguyên tắc rộng hơn của việc kiểm thử các tác nhân AI gọi API của bạn áp dụng cùng một nguyên tắc "xác nhận đường truyền trước" đó.
Bắt đầu với A2A
Nếu bạn muốn xây dựng hoặc kết nối một tác nhân A2A, đây là lộ trình ngắn gọn:
- Đọc đặc tả kỹ thuật A2A để bạn biết các trường Agent Card bắt buộc và vòng đời tác vụ.
- Chạy một trong các tác nhân mẫu tham chiếu cục bộ. Hầu hết đều khởi động trong vài phút và hiển thị một Agent Card hoạt động.
- Chỉ định một trình gỡ lỗi A2A đến URL Agent Card của mẫu và gửi một tin nhắn “hello”. Xác nhận bạn có thể thấy quá trình truyền nhận.
- Xây dựng tác nhân của riêng bạn, hiển thị một Agent Card hợp lệ và kiểm tra nó theo cùng một cách trước khi tích hợp vào một quy trình làm việc.
- Thêm lớp xác thực, đính kèm tệp và truyền trực tuyến sau khi đường dẫn văn bản thuần túy hoạt động.
A2A còn non trẻ, nhưng nó được hỗ trợ bởi một quỹ trung lập với nhà cung cấp và một danh sách ngày càng tăng các tích hợp framework. Việc coi lưu lượng tác nhân là một giao thức hạng nhất ngay từ bây giờ sẽ giúp bạn tiết kiệm việc viết lại "mã keo dán" tùy chỉnh sau này. Bài viết Các tác nhân AI là người tiêu dùng API mới trình bày chi tiết hơn, và bài viết thiết kế API cho tác nhân AI bao gồm những thay đổi khi người tiêu dùng của bạn là một tác nhân chứ không phải con người.
Các câu hỏi thường gặp
A2A có phải do Google tạo ra không?
Google giới thiệu A2A vào năm 2025, sau đó tặng nó cho Linux Foundation như một dự án mở trung lập với nhà cung cấp. Đặc tả kỹ thuật được phát triển công khai và bất kỳ nhà cung cấp nào cũng có thể triển khai nó.
Tôi có cần A2A nếu tôi chỉ có một tác nhân không?
Không. A2A giải quyết vấn đề giao tiếp giữa các tác nhân. Một tác nhân đơn lẻ với một bộ công cụ cần MCP, không phải A2A. Bạn cần đến A2A khi có tác nhân thứ hai xuất hiện.
Những framework nào hỗ trợ A2A?
A2A được thiết kế để không phụ thuộc vào framework. Bất kỳ tác nhân nào công bố một Agent Card hợp lệ và sử dụng giao thức này đều có thể tham gia, vì vậy LangGraph, CrewAI, AutoGen và các tác nhân tùy chỉnh đều hoạt động được. Framework nội bộ của tác nhân là không thể nhìn thấy đối với các bên gọi.
A2A có giống MCP không?
Không. MCP kết nối một tác nhân với các công cụ và nguồn dữ liệu. A2A kết nối các tác nhân với nhau. Chúng bổ sung cho nhau, và nhiều hệ thống chạy cả hai cùng lúc.
Làm thế nào để gỡ lỗi một tích hợp A2A?
Sử dụng một trình gỡ lỗi A2A trực quan như Apidog A2A Debugger. Dán URL Agent Card, gửi tin nhắn kiểm thử và kiểm tra yêu cầu và phản hồi thô để bạn có thể phân biệt lỗi truyền tải với lỗi logic của tác nhân.
A2A có hỗ trợ các tác vụ chạy dài không?
Có. Mô hình tác vụ có các trạng thái rõ ràng, và giao thức hỗ trợ các sự kiện được gửi từ máy chủ (server-sent events) để truyền trực tuyến các kết quả một phần và cập nhật tiến độ, vì vậy các công việc dài không làm chặn bên gọi.