Agent2Agent (A2A) là gì? Giao thức mở cho giao tiếp AI Agent

Agent2Agent (A2A) is an open protocol introduced by Google in 2025 and transferred to the Linux Foundation, designed to enable standardized communication between independent AI agents built with different frameworks. It defines a common contract—including Agent Cards, Tasks, Messages, and Artifacts—allowing agents to discover each other, exchange work, and return results without requiring custom integration code for each connection. A2A functions similarly to HTTP for web servers, enabling agents like those built with LangGraph or CrewAI to collaborate seamlessly as long as they adhere to the same protocol.

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à một giao thức mở cho giao tiếp giữa các tác nhân AI. Nó định nghĩa: Đ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. 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: 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: 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. Bạn có thể hiểu A2A qua bốn khái niệm chính: 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: 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: 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ư: submitted working input-required completed Đ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. 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: 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ụ: 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. 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. Một giao dịch A2A thường diễn ra như sau: completed .Ở 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 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. Nói ngắn gọn: Một hệ thống thực tế có thể dùng cả hai. Ví dụ: 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. 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ế: 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: 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: 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: 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. 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ắt đầu với đặc tả kỹ thuật A2A. Tập trung vào: 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. 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 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: Đừ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: Sau khi đường text hoạt động, mới thêm từng phần: Cách làm này giúp bạn biết chính xác bước nào gây lỗi. 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: 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. A2A phù hợp khi bạn có một trong các trường hợp sau: 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ó. 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. 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. 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. 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. 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. 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.