Hầu hết hệ thống AI hiện nay vẫn chạy theo mô hình một tác nhân: một model, một vòng lặp prompt, một bộ công cụ. Cách này ổn cho đến khi tác vụ quá lớn, hoặc bạn cần gọi một tác nhân do nhóm khác xây dựng để xử lý một bước chuyên biệt. Khi đó vấn đề xuất hiện: không có cách chuẩn để hai tác nhân độc lập tìm thấy nhau, trao đổi công việc và trả kết quả. Agent2Agent (A2A) được thiết kế để giải quyết đúng khoảng trống đó.
Bài viết này giải thích A2A là gì, nó giải quyết vấn đề nào, cách giao thức hoạt động, cách phân biệt với MCP, và cách bạn có thể bắt đầu kiểm thử một tác nhân A2A. Nếu bạn muốn debug thực tế sau khi đọc xong, xem thêm hướng dẫn Apidog A2A Debugger.
Agent2Agent (A2A) là gì?
Agent2Agent (A2A) là một giao thức mở cho giao tiếp giữa các tác nhân AI. Nó định nghĩa:
- Một tác nhân tự mô tả khả năng của mình như thế nào.
- Một tác nhân khác kết nối ra sao.
- Hai bên trao đổi tin nhắn, tệp và dữ liệu có cấu trúc như thế nào.
- Trạng thái tác vụ và kết quả được trả về cho bên gọi ra sao.
Điểm quan trọng của A2A là chữ giữa: giao tiếp giữa các tác nhân. A2A không phải là cách gắn thêm tool cho một tác nhân. Nó là cách để các tác nhân riêng biệt, có thể được viết bằng framework khác nhau và do các nhóm khác nhau vận hành, cộng tác mà không cần biết chi tiết triển khai nội bộ của nhau.
Có thể hình dung A2A giống HTTP 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ỳ web server nào mà không cần biết server viết bằng Go, Java, Node.js hay Python. Tương tự, A2A cho phép một tác nhân LangGraph giao tiếp với một tác nhân CrewAI miễn là cả hai tuân thủ cùng một hợp đồng giao thức.
Google giới thiệu A2A vào năm 2025, 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ố tại kho GitHub của A2A, còn các triển khai tham chiếu có trên trang dự án A2A.
Vấn đề A2A giải quyết
Trước A2A, tích hợp hai tác nhân thường đồng nghĩa với việc viết glue code riêng cho từng cặp kết nối.
Ví dụ, tác nhân của bạn cần gọi một tác nhân nghiên cứu của nhóm khác. Bạn thường phải tự quyết định:
- Endpoint gọi là gì.
- Payload request có shape ra sao.
- Response trả về dạng text, JSON hay stream.
- Xác thực dùng Bearer token, Basic Auth hay header riêng.
- Trạng thái tác vụ dài hạn được biểu diễn như thế nào.
Kết quả là mỗi tích hợp trở thành một chuẩn riêng. Khi cần gọi thêm tác nhân thứ hai, bạn gần như bắt đầu lại từ đầu.
Các vấn đề phổ biến gồm:
- Không có khám phá chuẩn. Tác nhân gọi không có cách thống nhất để hỏi: “Bạn làm được gì?”
- Không có mô hình tác vụ chung. Một tác nhân trả chuỗi text, tác nhân khác trả JSON tùy chỉnh, tác nhân khác stream token.
- Không có xác thực thống nhất. Mỗi tích hợp tự định nghĩa credential và header.
- Không có khả năng hoán đổi. Một tác nhân AutoGen khó thay thế bằng tác nhân LangGraph dù cả hai làm cùng một việc.
A2A xử lý vấn đề này theo hướng tương tự OpenAPI trong thế giới REST: định nghĩa một hợp đồng chung để các thành phần độc lập có thể làm việc với nhau.
A2A hoạt động như thế nào?
Bạn có thể hiểu A2A qua bốn khái niệm chính:
- Agent Card
- Task
- Message và Artifact
- Streaming và cập nhật trạng thái
1. Agent Card
Agent Card là tài liệu JSON mà một tác nhân công bố để mô tả chính nó. Đây là điểm bắt đầu cho quá trình khám phá.
Agent Card thường cho biết:
- Tên tác nhân.
- Mô tả.
- Khả năng.
- Danh sách kỹ năng.
- Kiểu input/output được hỗ trợ.
- Yêu cầu xác thực.
- Phiên bản giao thức.
Theo quy ước, Agent Card thường được đặt tại một URL dễ đoán, ví dụ:
https://your-agent.example.com/.well-known/agent.json
Một tác nhân gọi sẽ fetch URL này trước, đọc metadata, sau đó mới quyết định có gửi tác vụ hay không.
Ví dụ tối giản về Agent Card:
{
"name": "research-agent",
"description": "Tác nhân hỗ trợ nghiên cứu và tổng hợp thông tin",
"protocolVersion": "0.1.0",
"skills": [
{
"id": "web-research",
"name": "Web Research",
"description": "Tìm kiếm và tóm tắt thông tin từ nhiều nguồn"
}
],
"capabilities": {
"streaming": true
}
}
Trong thực tế, bạn nên kiểm tra Agent Card trước khi tích hợp để chắc chắn:
- URL có thể truy cập được.
- JSON hợp lệ.
- Kỹ năng được mô tả đủ rõ.
- Xác thực được khai báo đúng.
- Phiên bản giao thức tương thích.
2. Task
Task là đơn vị công việc trong A2A.
Khi tác nhân A yêu cầu tác nhân B làm điều gì đó, yêu cầu đó được biểu diễn thành một task có ID riêng. Task di chuyển qua các trạng thái như:
submittedworkinginput-requiredcompleted
Điểm quan trọng là bên gọi có thể xử lý task theo cùng một cách bất kể tác nhân phía sau được xây dựng bằng framework nào.
Một vòng đời đơn giản:
submitted -> working -> completed
Nếu tác nhân cần thêm dữ liệu:
submitted -> working -> input-required -> working -> completed
Cách tiếp cận này giúp bạn không phải tự phát minh cơ chế trạng thái cho từng integration.
3. Message và Artifact
Message là dữ liệu được gửi giữa các tác nhân. Message có thể gồm nhiều phần:
- Text.
- File.
- Dữ liệu có cấu trúc.
- Kết hợp nhiều loại nội dung.
Ví dụ một message dạng khái niệm:
{
"role": "user",
"parts": [
{
"type": "text",
"text": "Hãy tóm tắt tài liệu này thành 5 ý chính."
},
{
"type": "file",
"file": {
"name": "report.pdf",
"mimeType": "application/pdf"
}
}
]
}
Khi tác nhân hoàn thành, nó trả về artifacts. Artifact là đầu ra có cấu trúc của task, ví dụ:
- Tài liệu được tạo.
- Bảng dữ liệu.
- Bản tóm tắt.
- Tham chiếu đến file.
- Kết quả phân tích.
Cả message và artifact đều được cấu thành từ nhiều phần, giúp định dạng nhất quán ở cả chiều request và response.
4. Streaming và cập nhật trạng thái
Không phải task nào cũng hoàn tất ngay. Với các tác vụ dài như nghiên cứu, phân tích tài liệu, tạo báo cáo hoặc xử lý file lớn, A2A hỗ trợ server-sent events để stream tiến độ và kết quả từng phần.
Ví dụ, một tác nhân nghiên cứu có thể gửi các cập nhật như:
working: Đang tìm kiếm nguồn liên quan
working: Đã tìm thấy 3 nguồn phù hợp
working: Đang tổng hợp báo cáo
completed: Báo cáo đã sẵn sàng
Nhờ vậy, bên gọi không cần chờ trong trạng thái “mù”. Bạn có thể hiển thị tiến độ trong UI hoặc ghi log chi tiết để debug.
Luồng A2A điển hình
Một giao dịch A2A thường diễn ra như sau:
- Tác nhân A fetch Agent Card của tác nhân B.
- Tác nhân A đọc danh sách kỹ năng và khả năng được hỗ trợ.
- Tác nhân A gửi message để tạo task.
- Tác nhân B xử lý task.
- Tác nhân B stream cập nhật trạng thái nếu cần.
- Tác nhân B trả artifacts khi task chuyển sang
completed. - Tác nhân A đọc artifacts và tiếp tục workflow.
Ở tầng truyền tải, toàn bộ quá trình là JSON qua HTTP. Vì vậy, với developer, cách debug cũng gần giống debug API: kiểm tra request, response, header, auth, payload và trạng thái.
A2A so với MCP
A2A và MCP thường bị nhầm lẫn vì cả hai đều liên quan đến tác nhân AI và đều là giao thức mở. Tuy nhiên, chúng giải quyết hai bài toá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ể xử lý bước này cho tôi không?” | “Tác nhân này có thể dùng những công cụ và tài nguyên nào?” |
| Sử dụng điển hình | Workflow đa tác nhân giữa nhiều nhóm hoặc hệ thống | Một tác nhân gọi database, file system hoặc API |
| Đơn vị trao đổi | Task, message, artifact | Tool call, resource, prompt |
Nói ngắn gọn:
- MCP giúp một tác nhân truy cập công cụ và dữ liệu.
- A2A giúp một tác nhân giao tiếp với tác nhân khác.
Một hệ thống thực tế có thể dùng cả hai. Ví dụ:
- Tác nhân điều phối nhận yêu cầu từ người dùng.
- Nó dùng MCP để truy vấn database nội bộ.
- Nó dùng A2A để giao tác vụ phân tích cho một tác nhân chuyên gia.
- Nó nhận artifact cuối cùng và trả kết quả cho người dùng.
Nếu bạn đang quyết định khi nào dùng giao thức nào, xem thêm bài so sánh máy chủ MCP và A2A. Phía MCP trong thực tế được minh họa thêm trong bài trình gỡ lỗi client MCP của Apidog.
Hợp tác đa tác nhân trong thực tế
A2A không phải là cách duy nhất để các tác nhân cộng tác. Một số hệ thống dùng điều phối trực tiếp: một tác nhân lập kế hoạch, sau đó gọi rõ ràng một tác nhân khác để thực thi.
Một ví dụ mã nguồn mở là Codex-Claude-Collab, một kỹ năng điều phối workflow theo thời gian thực giữa OpenAI Codex và Claude Code. Codex lập kế hoạch, giao phần triển khai cho Claude Code, sau đó review diff và xác minh kết quả trước khi trả lời người dùng.
Đây là mô hình đ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 mô hình đó. Thay vì hard-code “gọi Claude Code”, tác nhân gọi đọc Agent Card và làm việc với bất kỳ tác nhân nào tuân thủ giao thức, miễn là tác nhân đó cung cấp kỹ năng phù hợp.
Cách chọn thực tế:
- Dùng điều phối trực tiếp khi bạn kiểm soát cả hai đầu và workflow ổn định.
- Dùng A2A khi tác nhân độc lập, thuộc nhóm khác, hoặc cần có khả năng thay thế.
- Dùng kết hợp cả hai nếu hệ thống có cả workflow nội bộ và tích hợp liên nhóm.
Cách kiểm tra một tác nhân A2A
Khi xây dựng hoặc tích hợp một tác nhân A2A, bạn cần nhìn thấy lưu lượng thực tế. Console log thường không đủ vì nó có thể che mất header, payload thô hoặc trường JSON lồng sâu. Script test tự viết cũng dễ lỗi thời khi giao thức hoặc Agent Card thay đổi.
Một checklist debug tối thiểu:
- Fetch Agent Card.
- Xác minh JSON hợp lệ.
- Kiểm tra auth.
- Gửi message thử nghiệm.
- Theo dõi task ID và trạng thái.
- Kiểm tra stream event nếu có.
- Đọc artifact cuối cùng.
- So sánh payload thô với dữ liệu UI hiển thị.
Bạn có thể bắt đầu bằng curl:
curl https://your-agent.example.com/.well-known/agent.json
Sau đó gửi một message test theo endpoint và format mà tác nhân hỗ trợ. Tuy nhiên, khi cần kiểm tra auth, file attachment, metadata, stream và JSON-RPC payload, dùng debugger trực quan sẽ nhanh hơn.
Apidog tích hợp A2A Debugger trong client tiêu chuẩn. Quy trình cơ bản:
- Dán URL Agent Card.
- Nhấn Connect.
- Apidog đọc thẻ và hiển thị tên, khả năng, kỹ năng của tác nhân.
- Gửi message thử nghiệm.
- Đính kèm file hoặc metadata nếu cần.
- Đọc response ở ba chế độ:
- Preview dễ đọc.
- Nội dung thô.
- Payload JSON-RPC đầy đủ.
Apidog cũng xử lý Bearer Token, Basic Auth và API key header mà không cần tự viết lệnh curl.
Điểm quan trọng khi debug A2A là tách lỗi truyền tải khỏi lỗi logic:
- Nếu request không đến được tác nhân, kiểm tra URL, DNS, TLS, auth và header.
- Nếu task không được tạo, kiểm tra payload và schema.
- Nếu task chạy nhưng artifact sai, lỗi có thể nằm trong logic tác nhân.
- Nếu streaming không hoạt động, kiểm tra server-sent events và client support.
Hướng dẫn Apidog A2A Debugger trình bày chi tiết vòng lặp kết nối-gửi-đọc. 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 cũng áp dụng cùng tư duy: xác nhận đường truyền trước, sau đó mới debug logic.
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, có thể đi theo lộ trình sau.
Bước 1: Đọc đặc tả
Bắt đầu với đặc tả kỹ thuật A2A. Tập trung vào:
- Cấu trúc Agent Card.
- Vòng đời task.
- Message parts.
- Artifact parts.
- Cách streaming hoạt động.
- Cách xác thực được mô tả.
Bạn không cần đọc toàn bộ trước khi viết code, nhưng cần hiểu các khái niệm bắt buộc để tránh thiết kế sai từ đầu.
Bước 2: Chạy tác nhân mẫu
Dùng một trong các tác nhân mẫu tham chiếu để có baseline hoạt động.
Mục tiêu của bước này không phải là production-ready, mà là xác nhận bạn hiểu luồng:
Agent Card -> message -> task -> status update -> artifact
Bước 3: Kiểm tra Agent Card
Trước khi gửi task, kiểm tra Agent Card bằng browser, curl hoặc debugger:
curl https://your-agent.example.com/.well-known/agent.json | jq
Xác nhận:
- JSON parse được.
- Trường mô tả không rỗng.
- Kỹ năng được khai báo rõ.
- Auth đúng với cách server thực thi.
- URL public hoặc private đúng theo môi trường tích hợp.
Bước 4: Gửi message “hello”
Đừng bắt đầu bằng tác vụ phức tạp. Hãy gửi một message đơn giản để kiểm tra đường truyền.
Ví dụ nội dung test:
hello
Bạn chỉ cần xác nhận:
- Task được tạo.
- Có task ID.
- Trạng thái chuyển đúng.
- Có response hoặc artifact cuối cùng.
Bước 5: Thêm input thực tế
Sau khi đường text hoạt động, mới thêm từng phần:
- Metadata.
- File attachment.
- Dữ liệu có cấu trúc.
- Streaming.
- Auth production.
Cách làm này giúp bạn biết chính xác bước nào gây lỗi.
Bước 6: Tích hợp vào workflow
Khi tác nhân đã phản hồi ổn định, tích hợp nó vào workflow thật. Ở bước này, nên log tối thiểu:
- Agent Card URL.
- Task ID.
- Trạng thái cuối.
- Thời gian xử lý.
- Lỗi truyền tải.
- Lỗi logic do tác nhân trả về.
- Artifact nhận được.
Những log này sẽ rất hữu ích khi bạn thay thế tác nhân hoặc nâng cấp phiên bản giao thức.
Khi nào nên dùng A2A?
A2A phù hợp khi bạn có một trong các trường hợp sau:
- Bạn cần gọi tác nhân do nhóm khác vận hành.
- Bạn muốn các tác nhân có thể hoán đổi.
- Bạn có workflow nhiều bước, mỗi bước do một tác nhân chuyên biệt xử lý.
- Bạn muốn tránh viết glue code tùy chỉnh cho từng integration.
- Bạn cần mô hình task/status/artifact thống nhất.
- Bạn muốn tách nội bộ framework khỏi hợp đồng giao tiếp bên ngoài.
A2A có thể chưa cần thiết nếu bạn chỉ có một tác nhân đơn lẻ gọi tool nội bộ. Trong trường hợp đó, MCP hoặc tích hợp API trực tiếp có thể đủ.
A2A còn mới, nhưng được hỗ trợ bởi một quỹ trung lập với nhà cung cấp và ngày càng có nhiều tích hợp framework. Nếu bạn đang xây dựng hệ thống đa tác nhân, việc coi giao tiếp giữa tác nhân là một giao thức hạng nhất từ sớm sẽ giúp giảm đáng kể lượng glue code về sau.
Xem thêm bài Các tác nhân AI là người tiêu dùng API mới và thiết kế API cho tác nhân AI nếu bạn muốn chuẩn bị API cho các consumer 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?
Có. 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.
Tôi có cần A2A nếu chỉ có một tác nhân không?
Không. A2A giải quyết giao tiếp giữa nhiều tác nhân. Nếu bạn chỉ có một tác nhân cần gọi tool, database, file system hoặc API, MCP hoặc tích hợp tool trực tiếp thường phù hợp hơn.
Những framework nào hỗ trợ A2A?
A2A được thiết kế để không phụ thuộc framework. Bất kỳ tác nhân nào công bố Agent Card hợp lệ và tuân thủ giao thức đều có thể tham gia. Điều đó có nghĩa là LangGraph, CrewAI, AutoGen hoặc tác nhân tùy chỉnh đều có thể tương tác qua A2A nếu triển khai đúng hợp đồng.
A2A có giống MCP không?
Không. MCP kết nối một tác nhân với 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à có thể cùng tồn tại trong cùng một hệ thống.
Làm thế nào để gỡ lỗi một tích hợp A2A?
Dùng một trình gỡ lỗi A2A trực quan như Apidog A2A Debugger. Dán URL Agent Card, gửi message kiểm thử, sau đó kiểm tra request/response 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ợ tác vụ chạy dài không?
Có. Mô hình task có trạng thái rõ ràng và giao thức hỗ trợ server-sent events để stream kết quả từng phần cũng như cập nhật tiến độ. Nhờ vậy, các công việc dài không cần chặn bên gọi cho đến khi hoàn tất.
Top comments (0)