A2A và MCP: khi agent của bạn phải giao việc cho agent của hãng khác trong hệ thống khách

Tuần thứ ba ở site khách, bạn đã có một agent chăm sóc khách hàng chạy ổn: đọc đơn hàng, tra chính sách đổi trả, trả lời đúng giọng thương hiệu. Rồi product owner bên khách hỏi một câu tưởng đơn giản: “Agent duyệt hoàn tiền của hãng ERP đã chạy rồi, bot của anh gọi sang nó được không?”

Bạn không có code của agent kia. Bạn không biết nó dùng model gì, nhớ những gì hay gọi những API nào. Thứ duy nhất bạn có là một endpoint và một cái tên.

Khi khách đã dùng agent của nhiều nhà cung cấp, việc nối chúng lại mà không làm thủng lớp bảo mật nào rất dễ rơi vào tay FDE đang ngồi tại chỗ. Muốn làm tốt, bạn cần phân biệt rạch ròi hai giao thức hay bị nhắc chung: MCP và A2A.

Gọi một tool hay giao việc cho một đồng nghiệp?

MCP, theo tài liệu chính thức, là chuẩn mã nguồn mở để nối ứng dụng AI với hệ thống bên ngoài. Agent của bạn dùng MCP để đọc database đơn hàng, gọi API chính sách hoặc tra kho. Mấy thứ đó là tool: bạn biết chúng làm gì, gọi bằng tham số gì và nhận lại kết quả gì.

A2A giải quyết bài toán khác. Bài công bố của Google viết rằng A2A là giao thức mở bổ sung cho MCP, và mục tiêu của nó là để agent của nhiều hãng cộng tác ngay cả khi chúng không chia sẻ bộ nhớ, tool hay ngữ cảnh.

Tài liệu A2A tóm lại thành một câu dễ nhớ: A2A nối các agent với nhau, còn MCP nối mỗi agent với tool của riêng nó.

Câu hỏi để phân loại khá đơn giản. Nếu bạn cần một khả năng và tự quyết định cách dùng nó, đó là MCP. Nếu bạn cần ai đó nhận một việc, tự suy luận rồi trả kết quả, đó là A2A. Tài liệu A2A cũng phân biệt như vậy: A2A là chuyện các agent hợp tác trên nhiệm vụ, còn MCP thiên về chuyện agent sử dụng năng lực.

Làm thử một luồng hoàn tiền từ đầu đến cuối

Quay lại ví dụ đổi trả. Đây là kịch bản giả định nhưng sát với việc thật. Khách hàng nhắn: “Áo giao sai size, tôi muốn hoàn tiền.” Agent của bạn dùng MCP để đọc đơn hàng và kiểm tra chính sách. Sau đó việc duyệt hoàn tiền phải chuyển sang agent của hãng ERP.

Bước 1: đọc Agent Card. Theo tài liệu A2A, agent công bố năng lực của mình qua một Agent Card dạng JSON. Đây là tài liệu metadata mô tả danh tính, năng lực, endpoint, các skill và yêu cầu xác thực. Một bản rút gọn, chỉ để minh hoạ, có thể trông như sau:

{
  "name": "erp-refund-agent",
  "url": "https://agents.erp-vendor.example/a2a",
  "skills": [
    { "id": "approve_refund", "description": "Duyệt hoặc từ chối yêu cầu hoàn tiền" },
    { "id": "refund_status", "description": "Tra trạng thái một yêu cầu hoàn tiền" }
  ],
  "authentication": "OAuth bearer token"
}

Tên trường thật phải lấy theo spec hiện hành. Điều cần học ở đây là cách đọc: hãy soi Agent Card kỹ như soi bản yêu cầu đầu tiên của khách. Skill nào được công bố? Skill bạn cần có nằm trong danh sách không? Nó đòi loại credential gì, và ai bên khách cấp credential đó?

Bước 2: tạo Task, đừng gọi kiểu hàm. Trong A2A, Task là đơn vị công việc có trạng thái, do một agent khởi tạo, có ID duy nhất và vòng đời xác định. Duyệt hoàn tiền có thể cần người thật xem qua, nên kết quả chưa chắc về ngay. Code của bạn phải lưu task ID, theo dõi trạng thái và nói với khách hàng điều gì đó hợp lý trong lúc chờ.

Bước 3: chấp nhận hộp đen. Tài liệu A2A nói rõ rằng từ góc nhìn của client, cách hoạt động bên trong, bộ nhớ và tool của agent từ xa đều bị ẩn. Vì vậy bạn phải gửi đủ ngữ cảnh trong chính Task, gồm mã đơn, lý do và bằng chứng, chứ đừng giả định agent kia tự tra được những gì agent của bạn đã thấy.

Bảo mật mới là nơi dự án thắng hay thua

Gửi được Task đầu tiên mới là nửa việc. Nửa còn lại, và là nửa bạn nên dành nhiều thời gian bàn với khách hơn, nằm ở xác thực và phân quyền.

Phía A2A dùng các cơ chế web quen thuộc như OAuth token hoặc API key đặt trong HTTP header. Tài liệu enterprise của A2A yêu cầu server xác thực mọi request đến bằng credential trong header.

Quyền truy cập cũng có thể cấp theo từng skill đã công bố trong Agent Card. Trong ví dụ trên, khách hoàn toàn có thể chỉ cho agent của bạn gọi refund_status và giữ approve_refund cho nội bộ.

Phía MCP có một cái bẫy khác. Spec authorization bản 2025-06-18 bắt MCP server kiểm tra audience của token và cấm chuyển tiếp nguyên token nhận từ MCP client sang API phía sau.

Thử hình dung MCP server của bạn trong mạng khách đem token của người dùng đi gọi thẳng hệ thống thanh toán. Lúc đó server biến thành “confused deputy”, tức một kẻ trung gian vô tình mượn quyền của người khác.

Server phải tự lấy credential riêng cho từng hệ thống phía sau.

Khi có sự cố, trace ID là bằng chứng của bạn

Sớm muộn gì sẽ có một đơn hoàn tiền bị kẹt. Bên khách hỏi lỗi của ai, và nếu không có dữ liệu thì hai nhà cung cấp sẽ đổ cho nhau.

Tài liệu A2A khuyến nghị cả client lẫn server tham gia hệ thống distributed tracing và ghi log kèm task ID, session ID và correlation ID ở cả hai phía. Lời khuyên cho bạn: đưa phần này vào thiết kế ngay từ ngày đầu, đừng đợi có sự cố mới thêm.

Mỗi dòng log của agent bạn cần có task ID mà bên ERP cũng ghi lại, để khi mở hai hệ thống log cạnh nhau, bạn ghép được một dòng thời gian duy nhất.

Còn một lý do khiến kỹ năng này không chỉ dùng cho một khách hàng. A2A đã được chuyển cho Linux Foundation quản lý theo hướng trung lập, với Amazon Web Services, Cisco, Google, Microsoft, Salesforce, SAP và ServiceNow là thành viên sáng lập. Nhiều nền tảng doanh nghiệp mà khách của bạn đang dùng nằm trong danh sách này.

Tự làm: năm bước trước khi nối hai agent

Đầu tiên, vẽ luồng nghiệp vụ và tô màu từng mũi tên: mũi tên nào là agent gọi tool của chính nó (MCP), mũi tên nào băng qua ranh giới giữa hai hãng (A2A). Tiếp theo, lấy Agent Card của đối tác, đối chiếu skill với nhu cầu, rồi liệt kê credential cần xin.

Sau đó, ngồi với đội bảo mật của khách để chốt phân quyền theo skill và cách cấp token, trước khi viết code. Bước thứ tư là thiết kế Task cho trường hợp chậm hoặc thất bại: lưu ID, đặt timeout và chuẩn bị thông điệp cho người dùng. Cuối cùng, thống nhất định dạng trace ID với đội của hãng kia bằng văn bản.

Ba lỗi dễ mắc

Một lỗi dễ mắc là bọc agent của hãng khác thành một MCP tool rồi gọi như hàm đồng bộ, bỏ qua việc Task có vòng đời riêng. Cách này có thể chạy đẹp trên demo, nhưng sẽ vỡ khi một ca duyệt cần người xem và mất nhiều thời gian. Lỗi thứ hai là chuyển tiếp token: làm vậy nhanh, tiện, và đúng thứ spec MCP cấm.

Lỗi thứ ba khó thấy hơn: tin rằng agent kia “biết” ngữ cảnh. Nó không biết gì ngoài những gì bạn gửi trong Task. Nếu bạn thấy kết quả trả về lạc đề, hãy kiểm tra payload của chính mình trước.

Biến kỹ năng này thành một dòng CV

Với developer Việt Nam muốn chuyển sang FDE, đây là thứ đáng đưa vào CV dưới dạng một câu cụ thể, chẳng hạn “tích hợp agent của bên thứ ba qua A2A, phân quyền theo skill, có tracing xuyên hai hệ thống”.

Khi đọc JD, hãy để ý các cụm như “multi-agent”, “third-party integration” hay “enterprise security”. Những cụm này có thể là dấu hiệu vị trí đó cần đúng loại việc trong bài, nên đáng hỏi kỹ ở vòng phỏng vấn.

Bài tập tuần này: dựng hai agent nhỏ trên máy. Agent A dùng một MCP server đọc file CSV đơn hàng. Agent B công bố Agent Card với hai skill và chỉ cho A gọi một skill. Cho A giao một Task sang B, ghi log task ID ở cả hai phía, rồi cố tình làm B trả lỗi và lần theo log đến tận nguyên nhân.

Nếu bạn lần ra được lỗi đó chỉ bằng log, bạn đã có câu trả lời tốt cho lần đầu khách hỏi lỗi nằm ở bên nào.