MCP vs A2A vs ACP: AI Agent giao tiếp thế nào?

Trả lời nhanh: MCP vs A2A vs ACP không phải ba lựa chọn ngang hàng. MCP chuẩn hóa kết nối giữa ứng dụng AI với tool, dữ liệu và prompt. A2A chuẩn hóa việc khám phá, giao nhiệm vụ và trao đổi giữa các agent độc lập. ACP từng phục vụ bài toán agent-to-agent, nhưng đã hợp nhất vào A2A; dự án mới nên ưu tiên A2A.

Cập nhật lần cuối: 20/08/2026

Một agent đặt vé máy bay cần đọc chính sách công ty, kiểm tra ngân sách và gọi API đặt chỗ. Đó là bài toán kết nối agent với năng lực bên ngoài. Nhưng nếu agent du lịch phải giao phần kiểm tra visa cho một agent pháp lý thuộc hệ thống khác, theo dõi tiến độ nhiều bước và nhận lại hồ sơ, đây là bài toán cộng tác giữa hai agent.

Hai tình huống nghe giống nhau nhưng có contract rất khác. Nhầm lẫn chúng dẫn tới tool bị thiết kế như agent, agent bị ép vào một lệnh RPC, quyền hạn quá rộng và trace không thể hiện ai chịu trách nhiệm cho hành động.

Điểm cần biết trước tiên vào năm 2026: cuộc so sánh không còn là cuộc đua ba bên. ACP đã hội tụ vào A2A. Quyết định kiến trúc thực tế thường là dùng MCP, dùng A2A, hay kết hợp cả hai.

MCP vs A2A vs ACP khác nhau ở đâu?

Khác biệt cốt lõi nằm ở đối tượng giao tiếp và mức độ tự chủ. MCP nối một ứng dụng AI với capability có contract; A2A nối các agent có khả năng tự lập kế hoạch và cộng tác trên task; ACP là giao thức agent-to-agent trước đây đã được hợp nhất vào A2A.

Tiêu chí	MCP	A2A	ACP
Tên đầy đủ	Model Context Protocol	Agent2Agent Protocol	Agent Communication Protocol
Bài toán chính	Ứng dụng AI dùng tool, resource, prompt	Agent khám phá và cộng tác với agent	Giao tiếp giữa agent, ứng dụng và con người
Hai phía điển hình	MCP host/client và MCP server	Client agent và remote agent	Client và agent theo thiết kế ACP cũ
Đơn vị công việc	Primitive hoặc request có schema	Message, task, status, artifact	Message/run trong giao thức lịch sử
Mức tự chủ phía nhận	Thường là capability xác định	Có thể là hệ thống tự lập kế hoạch, dùng tool và giữ state	Có thể là agent tự chủ
Tác vụ dài	Có thể hỗ trợ qua extension, nhưng không phải ranh giới phân biệt chính	Là use case cốt lõi với lifecycle và cập nhật tiến độ	Từng hỗ trợ luồng agent
Trạng thái năm 2026	Tiếp tục phát triển độc lập	Chuẩn agent-to-agent đang được phát triển	Đã hợp nhất vào A2A, dừng phát triển riêng
Khi nên chọn	Cần cung cấp tool hoặc dữ liệu cho AI	Cần giao việc cho một agent độc lập	Chỉ để hiểu hệ thống cũ và lập kế hoạch migration

Bảng này là bản đồ định hướng, không thay thế việc khóa phiên bản spec và đọc chính xác capability của SDK đang dùng.

MCP là gì và giải quyết bài toán nào?

Model Context Protocol là chuẩn mở để ứng dụng AI kết nối với hệ thống bên ngoài. Trong kiến trúc MCP, một host quản lý client; mỗi client giao tiếp với một MCP server cung cấp context hoặc capability.

Theo tài liệu kiến trúc MCP hiện hành, server có thể công bố 3 primitive chính:

• Tools: hàm có thể thực thi như tìm kiếm, truy vấn cơ sở dữ liệu hoặc gọi API.
• Resources: dữ liệu dùng làm context như tệp, record hoặc phản hồi API.
• Prompts: template có thể tái sử dụng để cấu trúc tương tác.

MCP giúp trả lời bốn câu hỏi kỹ thuật:

1. Server có những capability nào?
2. Input và output của capability có schema gì?
3. Client gọi capability theo message format nào?
4. Kết quả được trả về và cập nhật ra sao?

Ví dụ, một content agent cần phân tích Search Console. MCP server có thể expose:

• resource mô tả property và metric;
• tool query_search_performance với date range, dimension và filter;
• prompt hướng dẫn quy trình phân tích suy giảm traffic.

Agent không cần biết code nội bộ của connector. Nó chỉ cần hiểu contract đã được công bố.

MCP server có phải là AI Agent không?

Không nhất thiết. Một MCP server có thể chỉ là adapter xác định bao quanh API, database hoặc file system. Nó nhận request có cấu trúc và trả kết quả. Nó không cần tự đặt mục tiêu, phân rã kế hoạch hay thương lượng nhiệm vụ.

MCP server có thể bao quanh một capability thông minh, thậm chí một agent. Nhưng việc dùng MCP không tự động biến phía server thành agent. Đây là ranh giới quan trọng khi thiết kế quyền và kỳ vọng vận hành.

MCP hiện dùng kiến trúc nào?

Phiên bản MCP ngày 28/07/2026 chuyển core sang mô hình stateless request/response. Mỗi request mang thông tin phiên bản và capability cần thiết; ứng dụng vẫn có thể giữ state ở lớp của mình. Tài liệu xác định 2 transport chính: stdio cho tiến trình cục bộ và Streamable HTTP cho server từ xa.

Điều này nhắc chúng ta không được đồng nhất “protocol stateless” với “workflow không có trạng thái”. Conversation, approval, checkpoint và side effect vẫn phải được ứng dụng lưu bền vững nếu use case yêu cầu.

A2A là gì và khác MCP thế nào?

Agent2Agent Protocol là chuẩn mở để các agent độc lập, có thể được xây bằng framework hoặc nhà cung cấp khác nhau, khám phá capability và cộng tác. A2A không yêu cầu một agent phải lộ memory, tool hoặc logic nội bộ cho agent còn lại.

Một tương tác A2A thường có các khái niệm sau:

• Agent Card: metadata để mô tả danh tính, endpoint, skill và capability.
• Message: nội dung trao đổi giữa các bên.
• Task: đơn vị công việc có lifecycle.
• Status update: tiến độ hoặc trạng thái như đang xử lý, cần thêm input, hoàn tất, thất bại.
• Artifact: kết quả đầu ra có thể gồm text, file hoặc dữ liệu có cấu trúc.
• Streaming hoặc bất đồng bộ: cơ chế cho công việc dài thay vì buộc giữ một request đồng bộ.

Nếu MCP gần với “hãy gọi chức năng này bằng input đúng schema”, A2A gần với “hãy nhận mục tiêu này, tự xử lý trong phạm vi capability và báo lại tiến độ cùng kết quả”.

Vì sao không dùng MCP cho mọi kết nối?

Một agent có thể được bọc thành MCP tool, nhất là khi nhiệm vụ hẹp, stateless và output xác định. Nhưng abstraction bắt đầu rò rỉ khi phía nhận cần:

• hỏi lại nhiều lượt;
• thương lượng modality;
• giữ task trong thời gian dài;
• gửi tiến độ;
• tạo nhiều artifact;
• tự chọn tool và kế hoạch;
• yêu cầu người dùng cung cấp thêm thông tin;
• tiếp tục sau khi client ngắt kết nối.

Lúc đó, task-oriented protocol phù hợp hơn một tool call đơn lẻ. Tài liệu A2A cũng mô tả MCP và A2A là hai giao thức bổ sung, không phải đối thủ.

ACP là gì và hiện còn nên triển khai không?

ACP, viết tắt của Agent Communication Protocol, được IBM Research giới thiệu cho hệ sinh thái BeeAI nhằm tạo giao diện HTTP-native gọn nhẹ để agent, ứng dụng và con người giao tiếp.

Tuy nhiên, sau khi A2A xuất hiện với mục tiêu gần nhau, hai cộng đồng chọn hội tụ. Ngày 29/08/2025, LF AI & Data thông báo ACP chính thức hợp nhất vào A2A. Đội ACP dừng phát triển độc lập và chuyển công nghệ, kinh nghiệm sang A2A; repository ACP cũng được lưu trữ ở chế độ chỉ đọc.

Vì vậy:

• dự án mới không nên chọn ACP như một đối thủ hiện hành của A2A;
• hệ thống đang chạy ACP nên xem tài liệu migration của BeeAI;
• bài so sánh ACP vẫn hữu ích để hiểu lịch sử và lý do thị trường giảm phân mảnh;
• tên viết tắt ACP trong tài liệu khác có thể chỉ một đề xuất không liên quan, cần kiểm tra publisher và repository.

Đây là ví dụ điển hình cho rủi ro của nội dung công nghệ: một bảng so sánh đúng ở đầu năm 2025 có thể dẫn tới quyết định sai vào năm 2026 nếu không kiểm tra trạng thái dự án.

MCP và A2A kết hợp với nhau như thế nào?

Kiến trúc điển hình có hai ranh giới:

1. A2A ở bên ngoài agent: agent điều phối giao task cho agent chuyên môn.
2. MCP ở bên trong agent: mỗi agent dùng MCP để truy cập tool và nguồn dữ liệu của mình.

Ví dụ một hệ thống marketing đa agent:

• Orchestrator gửi task A2A cho Research Agent: “Đánh giá nhu cầu tìm kiếm của nhóm chủ đề X”.
• Research Agent dùng MCP để truy vấn Search Console, kho tài liệu và công cụ keyword.
• Research Agent trả artifact gồm dữ liệu, giả định và nguồn qua A2A.
• Orchestrator gửi artifact cho Content Agent qua A2A.
• Content Agent dùng MCP để đọc style guide, kiểm tra nội dung trùng và tạo draft trong CMS.
• Hành động publish được chặn bởi approval policy, không giao hoàn toàn cho model.

MCP chuẩn hóa capability cục bộ của từng agent. A2A chuẩn hóa hợp đồng cộng tác giữa các đơn vị tự chủ. Hệ thống vẫn cần orchestration, identity, policy, state store và observability; hai giao thức không tự cung cấp toàn bộ nền tảng production.

Khi nào chọn MCP, A2A hay API thông thường?

Không phải mọi hệ thống đều cần giao thức agent.

Tình huống	Lựa chọn khởi đầu	Lý do
Một ứng dụng AI gọi database hoặc SaaS	MCP	Capability có schema, phạm vi rõ
Hai agent khác nền tảng cần giao task dài	A2A	Cần discovery, task lifecycle và artifact
Một workflow cố định gọi microservice nội bộ	REST/gRPC/API hiện có	Không có lợi ích rõ từ agent abstraction
Agent điều phối dùng một agent chuyên môn, agent chuyên môn dùng nhiều tool	A2A + MCP	Hai lớp trách nhiệm khác nhau
Hệ thống cũ dùng ACP	Migration sang A2A	ACP đã dừng phát triển độc lập
Một script nhỏ, một model, hai hàm nội bộ	Function calling trực tiếp	MCP có thể tạo thêm chi phí vận hành chưa cần thiết

Cây quyết định ngắn

Hãy hỏi theo thứ tự:

1. Phía nhận chỉ thực hiện một capability có contract rõ? Chọn API, function calling hoặc MCP.
2. Capability cần được nhiều AI client khám phá và tái sử dụng? Nghiêng về MCP.
3. Phía nhận tự lập kế hoạch, giữ state và có thể hỏi lại? Nghiêng về A2A.
4. Hai bên thuộc team, framework hoặc tổ chức khác nhau? Giá trị interoperability của A2A tăng.
5. Đang dùng ACP? Lập migration sang A2A thay vì mở rộng implementation cũ.

Đừng chọn protocol chỉ vì xu hướng. Chọn abstraction nhỏ nhất thể hiện đúng semantics của công việc.

Cách thiết kế hệ thống MCP và A2A trong production

Bước 1: Vẽ ranh giới trách nhiệm

Liệt kê từng capability và xác định nó là:

• function xác định;
• nguồn context;
• workflow có state;
• agent độc lập;
• hành động có side effect;
• hành động cần người duyệt.

Nếu một thành phần chỉ truy vấn tồn kho, đừng gọi nó là Inventory Agent. Nếu nó tự lựa chọn nhà cung cấp, thương lượng điều kiện, giữ task nhiều lượt và tạo đề xuất, agent abstraction có thể hợp lý.

Bước 2: Viết task contract trước protocol contract

Task contract cần nêu:

• mục tiêu;
• input bắt buộc;
• output và artifact;
• tiêu chí hoàn thành;
• nguồn được phép;
• giới hạn thời gian, chi phí và số bước;
• trường hợp cần hỏi lại;
• điều kiện chuyển người;
• hành động bị cấm.

Protocol chỉ vận chuyển contract. Nó không sửa được một mục tiêu mơ hồ.

Bước 3: Thiết kế MCP tool nhỏ và có schema chặt

Một tool tốt nên có tên cụ thể, mô tả khi nào dùng, JSON Schema chặt, output nhỏ và error code ổn định. Tách read tool khỏi write tool. Với write, thêm:

• idempotency key;
• expected version;
• dry-run nếu phù hợp;
• scope quyền tối thiểu;
• audit event;
• cơ chế rollback hoặc compensation.

Hướng dẫn API composition giải thích sâu hơn cách gom dữ liệu mà không biến orchestration thành điểm nghẽn.

Bước 4: Công bố Agent Card tối thiểu

Agent Card không nên biến thành brochure. Nó phải giúp client quyết định có giao task hay không. Chỉ công bố:

• identity và endpoint đã xác minh;
• skill thực sự hỗ trợ;
• input/output modality;
• auth scheme;
• giới hạn và phiên bản;
• extension bắt buộc;
• thông tin vận hành cần thiết.

Không để secret, prompt nội bộ hoặc topology nhạy cảm trong metadata công khai.

Bước 5: Mô hình hóa task lifecycle

Task dài phải có state machine rõ. Một mô hình tối thiểu có thể gồm:

1. submitted;
2. working;
3. input-required;
4. completed;
5. failed;
6. canceled;
7. rejected.

Quy định transition hợp lệ, ai được chuyển state và kết quả nào là terminal. Lưu task ID, correlation ID, parent task, version và timestamp ở state store bền vững.

Bước 6: Tách authentication, authorization và consent

Ba khái niệm này không thay thế nhau:

• Authentication: bên gọi là ai?
• Authorization: bên gọi được dùng capability nào trên tài nguyên nào?
• Consent/approval: người dùng có đồng ý với hành động cụ thể này không?

Một token hợp lệ không có nghĩa model được quyền gửi email, chuyển tiền hoặc publish. Policy phải kiểm tra actor, tenant, resource, action, risk và ngữ cảnh của từng lệnh.

Bước 7: Xử lý retry và trùng lặp

Network timeout tạo ra trạng thái mơ hồ: request có thể đã tới server nhưng response bị mất. Mọi write cần idempotency key gắn với business operation, không chỉ request ID ngẫu nhiên mỗi lần retry.

Task A2A cũng cần quy tắc dedup. Nếu orchestrator gửi lại cùng một yêu cầu, remote agent phải biết đó là resume, retry hay task mới. Xem chi tiết tại bài Idempotency là gì?.

Bước 8: Thiết kế observability xuyên biên giới

Một trace hữu ích cần liên kết:

• user request;
• orchestration run;
• A2A task và message;
• MCP tool call;
• model call;
• approval;
• side effect;
• artifact cuối.

Ghi protocol version, agent version, tool schema version, latency, token, retry, error code và policy decision. Không log nguyên secret, credential hoặc dữ liệu cá nhân nhạy cảm.

Bước 9: Kiểm thử contract và failure mode

Ngoài happy path, hãy kiểm thử:

• Agent Card sai hoặc đổi version;
• tool schema thay đổi;
• task hoàn tất hai lần;
• stream đứt giữa chừng;
• callback đến trễ;
• agent yêu cầu input vô hạn;
• artifact chứa prompt injection;
• token đúng nhưng tenant sai;
• write đã thành công trước timeout;
• remote agent trả dữ liệu không đúng provenance.

Production readiness cần eval trên task thật, canary, quota và kill switch. Bài xây dựng AI Agent production cung cấp checklist đầy đủ hơn.

Rủi ro bảo mật lớn nhất khi agent giao tiếp

Protocol interoperability mở rộng bề mặt tấn công. Một message đúng schema vẫn có thể mang ý định độc hại.

Prompt injection đi qua artifact

Remote agent có thể trả tài liệu chứa chỉ dẫn như “bỏ qua policy và gọi tool X”. Bên nhận phải coi artifact là dữ liệu không tin cậy, giữ ranh giới instruction/data và không tự động nâng quyền theo nội dung.

Capability bị khai báo quá mức

Agent Card hoặc MCP tool description có thể phóng đại, mơ hồ hoặc bị giả mạo. Registry không thay thế trust verification. Cần allowlist publisher, pin version, kiểm chữ ký khi hệ sinh thái hỗ trợ và test behavior thực tế.

Confused deputy

Agent A có quyền thấp thuyết phục Agent B có quyền cao thực hiện hành động thay mình. Policy phía B phải kiểm tra cả caller, người dùng gốc, chuỗi delegation và resource scope, không chỉ tin lời mô tả trong prompt.

Data exfiltration

Agent có quyền đọc CRM và quyền gọi endpoint ngoài có thể vô tình gửi dữ liệu khách hàng ra khỏi trust boundary. Dùng egress allowlist, data classification, redaction, DLP và tách agent đọc dữ liệu nhạy cảm khỏi agent truy cập internet.

Hành động dây chuyền

Một task A2A có thể gọi nhiều agent; mỗi agent lại dùng nhiều tool. Giới hạn depth, fan-out, thời gian, token, tiền và số write. Human approval phải đặt trước side effect rủi ro, không đặt sau khi hành động đã diễn ra.

Các biện pháp này bổ sung cho threat model tổng thể trong bài bảo mật LLM.

Bảy anti-pattern cần tránh

1. Biến mọi API thành MCP server

Nếu chỉ có một consumer và contract hiện tại hoạt động tốt, lớp protocol mới có thể tăng dependency, auth path và công việc vận hành mà không tạo interoperability thực tế.

2. Gọi mọi service là agent

Tên gọi không làm service trở nên tự chủ. Phân loại sai khiến team thiết kế task lifecycle cho một lookup đơn giản hoặc ngược lại.

3. Dùng A2A như RPC đồng bộ

Nếu luôn chờ một response duy nhất, bỏ qua status, cancel và artifact, hệ thống không nhận được lợi ích của abstraction task dài.

4. Cho model tự quyết định quyền

Model có thể đề xuất action; policy engine xác định action có được phép. Authorization không nên nằm trong system prompt.

5. Tin metadata do phía xa tự khai báo

Agent Card và tool description là dữ liệu đầu vào. Xác minh endpoint, issuer, version, capability và tenant trước khi cho vào trust registry.

6. Không khóa phiên bản

MCP và A2A tiếp tục tiến hóa. Đọc “latest” khi nghiên cứu, nhưng production phải pin version, test compatibility và có deprecation plan.

7. Tiếp tục đầu tư vào ACP mới

ACP có giá trị lịch sử, nhưng roadmap độc lập đã dừng. Xây thêm integration mới trên ACP làm tăng migration debt không cần thiết.

Migration từ ACP sang A2A nên làm thế nào?

Migration không chỉ là đổi endpoint. Hãy thực hiện theo sáu bước:

1. Kiểm kê agent, route, message type, auth và dependency ACP.
2. Ánh xạ capability sang Agent Card và skill A2A.
3. Ánh xạ run/message sang task, message, status và artifact.
4. Viết contract test cho hành vi cũ và hành vi A2A mục tiêu.
5. Chạy adapter hoặc dual-stack trong giai đoạn chuyển tiếp nếu framework hỗ trợ.
6. Canary theo một nhóm task, so sánh completion, latency, error và duplicate trước khi tắt ACP.

BeeAI cung cấp adapter để expose agent theo A2A và tích hợp agent A2A bên ngoài. Dù dùng adapter nào, hãy kiểm tra chính tài liệu migration tương ứng với phiên bản framework của bạn.

Đo hiệu quả của kiến trúc agent interoperability

Đừng chỉ đo số agent kết nối. Một hệ thống nhiều node nhưng hoàn thành ít task là thất bại được phân tán đẹp hơn.

Nên theo dõi:

• task completion rate theo loại việc;
• end-to-end latency p50, p95, p99;
• số handoff trên mỗi task;
• tool call và model call trên mỗi task;
• tỷ lệ input-required;
• retry và duplicate side effect;
• policy denial;
• human escalation;
• chi phí mỗi task hoàn tất;
• artifact acceptance rate;
• tỷ lệ trace có đủ provenance.

Phân rã metric theo agent version, protocol version, tool schema và tenant. Nếu không, một bản cập nhật nhỏ có thể làm giảm chất lượng nhưng bị che trong số trung bình.

FAQ - Câu hỏi thường gặp về MCP vs A2A vs ACP

MCP có dùng để agent nói chuyện với agent được không?

Có thể bọc một agent thành MCP tool hoặc resource cho use case hẹp. Nhưng khi cần discovery giữa các agent, task dài, nhiều lượt, trạng thái, progress và artifact, A2A thể hiện đúng semantics hơn.

A2A có thay thế MCP không?

Không. A2A tập trung vào cộng tác giữa agent; MCP tập trung vào việc ứng dụng AI sử dụng tool và resource. Một agent A2A thường vẫn dùng MCP ở bên trong.

ACP còn hoạt động không?

Repository và tài liệu cũ vẫn có thể truy cập, nhưng active development độc lập đã dừng sau khi ACP hợp nhất vào A2A. Dự án mới nên dùng A2A; dự án ACP hiện hữu nên theo migration guide chính thức.

Có cần cả MCP và A2A cho một agent đơn lẻ không?

Không. Nếu một agent chỉ dùng vài tool, MCP hoặc function calling có thể đủ. A2A chỉ mang lại giá trị khi có ranh giới agent độc lập cần cộng tác.

MCP hoặc A2A có tự bảo đảm an toàn không?

Không. Protocol cung cấp cơ chế và contract, nhưng hệ thống vẫn phải triển khai identity, authorization, consent, secret management, validation, audit, least privilege và incident response.

A2A có bắt buộc các agent dùng cùng model hoặc framework không?

Không. Mục tiêu của A2A là interoperability giữa các agent có implementation khác nhau. Phía nhận có thể giữ kín model, memory, tool và logic nội bộ.

Nên học giao thức nào trước?

Hãy học MCP trước nếu bạn đang xây một agent cần dữ liệu và tool. Học A2A khi hệ thống xuất hiện remote agent hoặc ranh giới tổ chức. Với ACP, chỉ cần hiểu khái niệm để bảo trì hoặc migration hệ thống cũ.

Kết luận

Điều đáng nhớ trong MCP vs A2A vs ACP không phải là ba danh sách feature. Đó là ba câu hỏi kiến trúc:

1. Agent đang dùng một capability hay hợp tác với một chủ thể tự chủ?
2. Công việc là một lời gọi có schema hay một task có lifecycle?
3. Hệ thống có kiểm soát identity, quyền, state, retry và provenance xuyên suốt hay không?

MCP phù hợp để nối AI với tool, resource và prompt. A2A phù hợp để các agent độc lập khám phá, giao việc và trao đổi artifact. ACP đã đóng góp vào tiến trình chuẩn hóa nhưng nay đã hội tụ vào A2A.

Kiến trúc thực dụng nhất thường không chọn một giao thức để làm mọi thứ. Nó dùng MCP cho capability, A2A cho collaboration và giữ business policy trong một control plane có thể kiểm tra, quan sát và dừng được.

Nguồn tham khảo

• MCP vs A2A vs ACP: How AI Agents Actually Talk to Each Other, ByteByteGo.
• MCP Architecture Overview, tài liệu chính thức Model Context Protocol.
• A2A and MCP: Detailed Comparison, tài liệu chính thức A2A Protocol.
• Agent2Agent Protocol Specification, đặc tả chính thức A2A.
• ACP Joins Forces with A2A, LF AI & Data Foundation.

Lưu ý: MCP và A2A là các chuẩn đang phát triển. Bài viết phản ánh tài liệu được kiểm tra ngày 20/08/2026. Khi triển khai, hãy khóa phiên bản và xác nhận lại đặc tả cùng SDK chính thức.

Đọc tiếp

• Xây dựng AI Agent production: 12 nguyên tắc thực chiến
• Bảo mật LLM: Threat model đầy đủ cho hệ thống AI
• Idempotency là gì? Delivery semantics và chống trùng lặp
• API composition là gì? Hướng dẫn thiết kế thực chiến