Blog / Series AI Agents Thực Chiến

A2A Protocol 2026: sau MCP, doanh nghiệp bắt đầu cần lớp agent-to-agent thực sự

Vấn đề gốc: vì sao MCP chưa đủ khi hệ đi vào nhiều agent

Sau làn sóng MCP, nhiều đội ngũ bắt đầu cảm thấy mình đã có đủ “kết nối” cho agent. Điều này đúng, nhưng chỉ đúng với một nửa bài toán. MCP chủ yếu trả lời câu hỏi: agent kết nối với công cụ như thế nào. Nó không tự động trả lời câu hỏi: nhiều agent phối hợp với nhau như thế nào.

Khi một tổ chức mới triển khai AI, họ thường bắt đầu với một agent trung tâm, gọi vài tool, trả kết quả cho người dùng. Kiến trúc này đủ tốt ở giai đoạn đầu. Nhưng khi khối lượng việc tăng lên, một agent duy nhất bắt đầu trở thành nút thắt. Một agent lo intake, một agent chuyên đọc policy, một agent chuyên đối chiếu dữ liệu, một agent khác chỉ được phép hành động khi có approval. Lúc đó, giao diện tool-call không còn là trung tâm duy nhất của hệ nữa. Quan hệ giữa agent với agent trở thành một lớp kiến trúc riêng.

Đây là lý do A2A nổi lên như một chủ đề nóng của quý II/2026. Thị trường đang đi từ câu hỏi “làm sao để agent dùng tool” sang câu hỏi “làm sao để nhiều agent hợp tác mà không biến hệ thành mê cung không ai audit nổi”.

A2A là gì, và khác orchestration nội bộ ở đâu?

A2A, hay agent-to-agent, là lớp giao tiếp chuẩn hóa để một agent có thể khám phá, gọi, ủy quyền hoặc phối hợp với agent khác mà không phải dựa hoàn toàn vào tích hợp tùy biến cho từng cặp hệ thống.

Ở đây cần tách ba khái niệm rất dễ bị trộn vào nhau:

1. Tool calling / MCP: agent gọi công cụ hoặc tài nguyên.
2. Workflow orchestration: một runtime hoặc scheduler điều phối chuỗi bước.
3. A2A: một agent hoặc agent-runtime công bố năng lực của mình để agent khác có thể giao việc theo một hợp đồng đủ rõ.

Nói cách khác, orchestration nội bộ có thể giải quyết phối hợp trong cùng một hệ. Nhưng khi agent đến từ nhiều nhóm, nhiều stack, hoặc nhiều nền tảng, nhu cầu về một lớp giao thức chung bắt đầu xuất hiện. A2A không thay thế orchestration. Nó giúp orchestration không bị khóa cứng vào một runtime duy nhất.

Vì sao chủ đề này nóng lên đúng lúc này?

• Các tổ chức bắt đầu có sprawl của agent, tương tự giai đoạn microservices bùng nổ trước đây.
• Nhiều nền tảng lớn đã bắt đầu nhắc tới registry, signed identity, capability discovery cho agent.
• Agent không còn chỉ trả lời chat, mà đã tham gia vào các luồng mua hàng, vận hành, hỗ trợ và compliance, nơi cần handoff có kiểm soát.

Bài AI Agent Identity 2026 đã chỉ ra danh tính và ủy quyền là bài toán lõi. A2A đẩy vấn đề đó lên một cấp nữa: không chỉ ai đang gọi tool, mà còn ai đang giao việc cho ai, trong bối cảnh nào, với phạm vi trách nhiệm nào.

Use case end-to-end: đội vận hành thương mại điện tử với bốn agent chuyên trách

Hãy lấy một use case thực tế hơn demo. Một doanh nghiệp thương mại điện tử muốn dùng AI để rút ngắn thời gian xử lý sự cố đơn hàng. Họ có bốn agent:

1. Intake Agent nhận ticket từ email, chat và form.
2. Policy Agent đọc chính sách đổi trả, bảo hành, phí vận chuyển.
3. Order Agent tra cứu CRM, OMS và trạng thái thanh toán.
4. Resolution Agent chuẩn bị hướng xử lý hoặc draft phản hồi cho nhân viên vận hành.

Nếu dồn hết vào một agent trung tâm, prompt sẽ rất dài, quyền truy cập bị nở ra, và mọi failure mode dính vào cùng một chỗ. Nếu tách agent nhưng chỉ nối chúng bằng các HTTP endpoint ngẫu hứng, hệ sẽ chạy được một thời gian rồi bắt đầu gãy ở khâu hiểu capability, version, identity và handoff state.

Đây là nơi A2A tạo ra giá trị thực dụng. Intake Agent có thể phát hiện ticket thuộc nhóm hoàn tiền. Nó không cần tự giải toàn bộ bài toán. Nó chỉ cần biết rằng có một Policy Agent công bố năng lực đọc policy hoàn tiền, và một Order Agent công bố năng lực đối chiếu đơn hàng. Sau đó Resolution Agent nhận kết quả tổng hợp, chấm confidence, rồi quyết định trả draft cho con người duyệt hay escalte tiếp.

Dòng chảy end-to-end nhìn từ góc vận hành

• Người dùng gửi ticket: “Đơn hàng giao trễ 9 ngày, tôi muốn hoàn tiền phí ship và hủy phần quà tặng”.
• Intake Agent phân loại ý định, chuẩn hóa thông tin và quyết định cần gọi hai agent khác.
• Policy Agent trả về policy áp dụng theo hạng thành viên, trạng thái giao hàng và loại khuyến mãi.
• Order Agent trả về thực trạng đơn hàng, payment status và lịch sử thay đổi.
• Resolution Agent hợp nhất kết quả, tạo draft xử lý, gắn cờ phần cần approval của quản lý.

Điểm quan trọng là mỗi agent chỉ chịu một phạm vi rõ hơn. Điều này không tự động làm hệ đơn giản hơn, nhưng nó làm hệ có thể kiểm soát hơn. Và đó là điểm A2A đáng quan tâm: nó giúp sự phân vai này không bị biến thành mớ tích hợp tay khó bảo trì.

Kiến trúc hệ thống: danh tính, capability, handoff, state và approval

Một hệ A2A có thể trông “mượt” trong demo nhưng rất dễ vỡ trong production nếu bỏ qua lớp điều hành. Tối thiểu nên có năm thành phần.

1. Danh tính và xác thực agent

Agent không nên chỉ là một URL có thể gọi. Nó cần một danh tính có thể xác thực, tốt nhất có metadata về owner, phạm vi quyền, version và chính sách dữ liệu. Nếu không có lớp này, A2A sẽ mở ra một bề mặt tấn công mới, tương tự việc mở tool server mà không có policy.

2. Capability discovery

Muốn giao việc cho đúng agent, hệ phải biết agent đó làm được gì, nhận đầu vào nào, cam kết output ra sao, và độ ổn định đến mức nào. Một registry hoặc agent card là cách tự nhiên để giải quyết điều này. Đây cũng là điểm giao cắt với xu hướng agent registry đang được nhắc tới trên thị trường.

3. Handoff contract

Phần khó nhất của A2A không phải gửi request. Phần khó là handoff sao cho agent nhận hiểu đủ bối cảnh nhưng không bị nhồi toàn bộ lịch sử vô ích. Hợp đồng handoff nên nêu rõ:

• mục tiêu hiện tại là gì,
• phạm vi hành động được phép,
• các ràng buộc policy cần giữ,
• state nào phải được giữ lại để audit,
• kết quả nào được xem là thành công.

Nếu thiếu hợp đồng này, hệ nhiều agent sẽ rơi vào đúng vấn đề mà bài State of AI Agent Memory 2026 cảnh báo: state bị rò rỉ, lặp lại, hoặc mất dấu giữa các bước.

4. Approval và policy layer

Không phải mọi handoff đều được phép đi thẳng đến execute. Những hành động như hoàn tiền, đổi đơn, truy cập dữ liệu nhạy cảm hoặc liên hệ khách hàng phải gắn với approval và policy tách bạch khỏi prompt. A2A chỉ có ích khi nó sống được cùng workflow thật, không phải chỉ trong đường thẳng “agent A gọi agent B”. Bài workflow, memory, approval đặc biệt quan trọng ở đây.

5. Observability và trách nhiệm

Khi một quyết định sai đi qua ba hoặc bốn agent, câu hỏi đầu tiên của doanh nghiệp sẽ là: lỗi phát sinh ở đâu? Nếu không có trace theo handoff, log theo agent và lý do route rõ ràng, A2A sẽ biến debugging thành ác mộng. Thực tế, nhu cầu observability của hệ nhiều agent gần với model routing hơn nhiều người nghĩ, vì cả hai đều là bài toán điều phối nhiều năng lực dưới một chính sách chung.

Trade-off và failure mode khiến nhiều hệ nhiều agent bị hỗn loạn

Rất dễ bị hấp dẫn bởi ý tưởng “chia nhỏ thành nhiều agent chuyên gia”. Nhưng chia nhỏ không tự động làm hệ mạnh hơn. Đôi khi nó chỉ chia nhỏ sự hỗn loạn.

1. Over-decomposition

Tách agent quá nhỏ khiến một tác vụ đơn giản cũng phải đi qua quá nhiều hop. Latency tăng, context bị phân mảnh, và cost orchestration ăn mất lợi ích chuyên môn hóa.

2. Capability inflation

Mỗi agent tự mô tả mình quá rộng, khiến router hoặc agent gọi không biết nên tin vào đâu. Kết quả là discovery có vẻ đẹp trên giấy nhưng rất yếu trong thực tế.

3. Responsibility blur

Nếu không ghi rõ ai là agent quyết định cuối cùng, các hệ nhiều agent rất dễ trôi vào vùng “không ai thực sự chịu trách nhiệm”. Đây là failure mode nghiêm trọng trong các luồng có rủi ro tài chính hoặc tuân thủ.

4. Hidden policy drift

Một agent có thể tuân thủ policy tốt khi chạy độc lập, nhưng khi nhận handoff từ agent khác, nó vô tình nhận thêm dữ liệu hoặc quyền mà nó lẽ ra không nên có. Bài Agent Security 2026 liên quan trực tiếp ở điểm này.

5. Multi-agent theater

Nhiều hệ gọi mình là “multi-agent” nhưng thực chất chỉ là một orchestration graph tách tên bước cho đẹp. Điều này không sai, nhưng nếu đã không cần độc lập về danh tính, capability hay runtime, doanh nghiệp có thể chưa cần A2A thật. Một workflow engine đơn giản hơn có thể là lựa chọn tốt hơn.

Checklist rollout trong môi trường production

Nếu đội ngũ đang cân nhắc A2A trong 2026, checklist dưới đây thực dụng hơn nhiều so với việc chạy theo từ khóa nóng.

Giai đoạn 1: chứng minh lý do phải có nhiều agent

• Xác định rõ vì sao một agent duy nhất không còn đủ tốt.
• Chỉ tách agent khi cần phân quyền, phân trách nhiệm, hoặc phối hợp xuyên nền tảng.
• Viết rõ đâu là boundary của từng agent trước khi viết prompt.

Giai đoạn 2: dựng capability registry tối thiểu

• Mỗi agent phải công bố capability, input contract, output contract, owner và policy.
• Version hóa capability để tránh gọi nhầm contract cũ.
• Gắn identity xác thực được cho từng agent.

Giai đoạn 3: bắt đầu với handoff hẹp

• Chỉ cho phép một số handoff rõ ràng thay vì mạng lưới tự do.
• Ưu tiên các luồng có output dễ kiểm chứng.
• Buộc trace toàn bộ request qua từng handoff.

Giai đoạn 4: gắn approval, observability và postmortem

• Hành động rủi ro cao phải có approval ở bên ngoài prompt.
• Theo dõi handoff success rate, escalation rate, human override rate.
• Postmortem các case agent giao việc sai hoặc rơi vào vòng lặp.

Giai đoạn 5: chỉ mở rộng khi economics và governance đều ổn

• Đo tổng latency và chi phí orchestration, không chỉ chi phí model.
• Kiểm tra lại policy drift định kỳ.
• Giữ quyền “rollback về workflow đơn giản hơn” nếu multi-agent không tạo ra giá trị ròng.

Insight cuối cùng: sau tool use, cuộc chơi chuyển sang điều phối năng lực giữa các agent

MCP giúp thị trường vượt qua giai đoạn agent chỉ biết nói. Nhưng khi agent bắt đầu làm việc thật trong doanh nghiệp, vấn đề tiếp theo gần như không thể tránh: các agent phải cộng tác, giao việc và giới hạn trách nhiệm của nhau một cách đủ chuẩn để sống được trong production.

Đó là lý do A2A đang nóng lên. Không phải vì doanh nghiệp thích thêm một acronym mới, mà vì kiến trúc bắt đầu đụng phải một nhu cầu thật: điều phối năng lực suy luận giữa nhiều thực thể bán tự trị.

Với nhiều đội ngũ, câu hỏi đúng không phải “A2A có phải xu hướng lớn không”, mà là “ở điểm nào workflow hiện tại của chúng ta đã vượt khỏi ngưỡng một agent đơn lẻ”. Nếu câu trả lời vẫn là chưa, đừng vội phức tạp hóa hệ thống. Nhưng nếu tổ chức đã bắt đầu có agent sprawl, nhiều quyền truy cập, nhiều boundary và nhiều điểm cần audit, thì A2A không còn là chủ đề bên lề. Nó đang trở thành lớp hạ tầng tiếp theo của agentic systems.