- Hướng dẫn giải thích từng bước, kèm mã thực tế, cách 6 giao thức AI agent gồm MCP, A2A, UCP, AP2, A2UI, AG-UI được gắn kết trong một kịch bản agent chuỗi cung ứng cho nhà hàng, đồng thời chỉ ra vấn đề mà mỗi giao thức giải quyết
- Cấu trúc sử dụng Agent Development Kit (ADK) của Google, bắt đầu từ một LLM trống rồi bổ sung từng giao thức để hoàn thiện toàn bộ quy trình từ kiểm tra tồn kho, báo giá, đặt hàng, thanh toán đến render dashboard
- MCP phụ trách kết nối công cụ/dữ liệu, A2A phụ trách giao tiếp giữa các agent, UCP phụ trách chuẩn hóa thương mại, AP2 phụ trách ủy quyền thanh toán, A2UI phụ trách cấu thành UI, AG-UI phụ trách truyền phát trực tuyến
- Mỗi giao thức chia sẻ các mẫu chung như discovery dựa trên URL well-known, schema có định kiểu, luồng sự kiện tiêu chuẩn để bảo đảm khả năng tương thích trong hệ sinh thái
- Không cần áp dụng cả 6 giao thức ngay từ ngày đầu; khuyến nghị cách tiếp cận bổ sung dần theo nhu cầu
MCP(Model Context Protocol) — kết nối công cụ và dữ liệu
- Đây là giao thức giải quyết rào cản đầu tiên khi kết nối agent với hệ thống và dữ liệu, loại bỏ việc phải viết mã tích hợp tùy chỉnh thủ công cho từng API
- Cấu trúc là máy chủ MCP tự quảng bá (advertise) các công cụ của mình để agent tự động discovery, từ đó cung cấp một mẫu kết nối chuẩn duy nhất cho hàng trăm máy chủ
- Vì máy chủ MCP được chính đội ngũ xây dựng hệ thống đó bảo trì, phía agent không cần viết hay cập nhật mã tích hợp mà vẫn luôn có định nghĩa công cụ mới nhất
- ADK hỗ trợ hạng nhất thông qua McpToolset; ví dụ minh họa việc truy vấn cơ sở dữ liệu PostgreSQL (MCP Toolbox for Databases), tra cứu công thức qua Notion MCP, và gửi email cho nhà cung cấp qua Mailgun MCP
- Kết nối DB tồn kho bằng
ToolboxToolset
- Kết nối dịch vụ bên ngoài như Notion, Mailgun bằng
McpToolset
- Mẫu triển khai gọn nhẹ: chạy máy chủ MCP bằng lệnh
npx và kết nối trực tiếp vào agent mà không cần mã bổ sung
A2A(Agent2Agent Protocol) — giao tiếp giữa các agent
- Sau khi MCP giải quyết truy cập dữ liệu, giao thức này xử lý bài toán còn lại là chuyên môn hóa (expertise), cung cấp phương thức discovery và giao tiếp tiêu chuẩn giữa các agent từ xa chạy trên những đội ngũ, framework và máy chủ khác nhau
- Mỗi agent A2A công bố Agent Card tại
/.well-known/agent-card.json để lộ tên, năng lực và endpoint; agent quản lý bếp sẽ lấy thông tin này và định tuyến truy vấn tới agent phù hợp trong thời gian chạy
- Khi thêm một agent từ xa mới, chỉ cần thêm URL nên không cần sửa mã thủ công hay triển khai lại
RemoteA2aAgent của ADK định tuyến tới một agent từ xa cho mỗi lượt; nếu cần truy vấn đồng thời nhiều agent từ xa, hãy dùng trực tiếp a2a-sdk- Có thể chuyển mọi agent ADK thành dịch vụ A2A bằng hàm
to_a2a()
- Ngay cả khi dữ liệu thô như giá, cấp chất lượng hay khung giờ giao hàng không được lộ ra qua API, vẫn có thể truy cập qua giao diện agentic
UCP(Universal Commerce Protocol) — chuẩn hóa thương mại
- Đây là giao thức hợp nhất quy trình đặt hàng giữa các nhà cung cấp có API khác nhau, bằng cách chuẩn hóa vòng đời mua sắm thành các chức năng mô-đun
- Giao thức giữ tính nhất quán bằng schema request/response có định kiểu mạnh; bất kể tầng truyền tải bên dưới là REST, MCP, A2A hay EP (giao thức nhúng dựa trên trình duyệt), cách hoạt động vẫn theo cùng một mẫu
- Có thể discovery catalog nhà cung cấp qua cùng mẫu URL
/.well-known/ucp như A2A
- Không cần SDK độc quyền; có thể tích hợp trực tiếp với REST API tiêu chuẩn bằng HTTP client hiện có
- Trong ví dụ,
CheckoutCreateRequest được dùng để đặt 10 pound cá hồi và 3 chai dầu ô liu, còn PaymentCreateRequest dùng để cấu hình yêu cầu thanh toán
- Kho mẫu UCP có ví dụ về trợ lý mua sắm dùng AI kết hợp ADK và A2A
AP2(Agent Payments Protocol) — ủy quyền thanh toán và dấu vết kiểm toán
- Nếu UCP xử lý mặt hàng và nhà cung cấp cần đặt, thì AP2 phụ trách ai là người phê duyệt mua hàng và dấu vết kiểm toán
- Mandate có định kiểu cung cấp bằng chứng về ý định không thể chối bỏ (non-repudiatable proof of intent), đồng thời áp dụng guardrail có thể cấu hình cho mọi giao dịch
- Toàn bộ luồng:
IntentMandate → PaymentMandate (đã ký) → PaymentReceipt
- IntentMandate: thiết lập guardrail như đơn vị bán được phép, hạn mức chi tiêu, có tự động phê duyệt hay không, yêu cầu khả năng hoàn tiền, thời điểm hết hạn...
- PaymentMandate: văn bản ủy quyền thanh toán gắn với giỏ hàng và số tiền cụ thể; nếu vượt hạn mức thì sẽ ở trạng thái chưa ký cho đến khi có phê duyệt rõ ràng từ quản lý
- PaymentReceipt: biên lai hoàn tất dấu vết kiểm toán
- Hoạt động như một extension của UCP, bổ sung bằng chứng ủy quyền được mã hóa vào luồng checkout
- Hiện đang ở giai đoạn v0.1, chưa tích hợp sẵn trong lõi ADK mà cung cấp kiểu qua gói riêng
A2UI(Agent-to-User Interface Protocol) — cấu thành UI động
- Đây là giao thức cho phép agent động tạo ra dashboard, biểu mẫu đặt hàng, bảng so sánh nhà cung cấp thay vì chỉ trả văn bản thông thường
- Giao diện được ghép dưới dạng JSON khai báo từ catalog cố định gồm 18 primitive component an toàn như hàng, cột, trường văn bản...
- Tách cấu trúc UI khỏi dữ liệu, nhờ đó có thể chỉ cập nhật dữ liệu mà không phải gửi lại component
- Component được truyền dưới dạng danh sách phẳng có tham chiếu chéo bằng ID
- Dữ liệu được chuyển riêng qua
dataModelUpdate
- Renderer phía client chuyển JSON thành UI native trên Lit, Flutter, Angular và các nền tảng tương tự
- Cùng một agent có thể tạo ra những giao diện hoàn toàn khác nhau như checklist kiểm kho, biểu mẫu đặt hàng hay bảng so sánh nhà cung cấp chỉ với cùng 18 primitive đó
- Giao diện web ADK (
adk web) có thể render component A2UI một cách native, nên không cần tự dựng renderer riêng trong lúc phát triển
- Có thể ghép layout tương tác bằng A2UI Widget Builder
AG-UI(Agent-User Interaction Protocol) — truyền phát trực tuyến
- Khác với REST API truyền thống, agent có mẫu tương tác phức tạp như stream văn bản dần dần, gọi công cụ giữa chừng trong lúc phản hồi, hoặc tạm dừng để chờ đầu vào từ con người
- AG-UI hoạt động như middleware, chuyển đổi các sự kiện thô theo từng framework thành luồng SSE tiêu chuẩn hóa
- Frontend chỉ cần nhận các sự kiện có định kiểu như
TEXT_MESSAGE_CONTENT, TOOL_CALL_START mà không cần biết framework agent nào đã tạo ra chúng
- ADK có endpoint
/run_sse native, nhưng AG-UI giải quyết vấn đề mã phân tích boilerplate và nguy cơ hỏng khi định dạng sự kiện thay đổi
- Chỉ cần bọc bằng gói
ag_ui_adk rồi mount vào ứng dụng FastAPI là có thể cấu hình endpoint streaming AG-UI
Luồng hoạt động tích hợp tổng thể
- Khi người dùng yêu cầu “kiểm tra tồn kho cá hồi, tra giá sỉ và cấp chất lượng hôm nay, nếu thiếu hàng thì đặt 10 pound từ Example Wholesale và ủy quyền thanh toán”, 6 giao thức sẽ hoạt động theo từng bước
- Bước 1 — thu thập thông tin: truy vấn DB tồn kho bằng MCP (
check_inventory) → truy vấn agent giá/chất lượng từ xa bằng A2A (ask_agent)
- Bước 2 — hoàn tất giao dịch: gửi yêu cầu checkout bằng UCP (
place_order) → lấy payment mandate trong giới hạn guardrail đã đặt bằng AP2 (authorize_payment)
- Bước 3 — hiển thị kết quả: tạo widget tương tác bằng A2UI → stream lời gọi công cụ và phản hồi văn bản theo thời gian thực bằng AG-UI
Mẹo áp dụng giao thức
- Cần hiểu chính xác vấn đề mà từng giao thức giải quyết để kiến trúc luôn gọn gàng
- Không cần cả 6 giao thức ngay từ ngày đầu; phần lớn có thể bắt đầu với MCP rồi bổ sung dần giao tiếp đa agent, thương mại, thanh toán, UI phong phú, streaming... khi yêu cầu tăng lên
- Trước khi xây dựng bằng các giao thức này, nên kiểm tra tích hợp ADK, SDK chính thức và mã mẫu để tránh tự triển khai lại những gì đã có
- Dù các giao thức vẫn đang trong quá trình trưởng thành, việc sớm áp dụng các mẫu như discovery qua URL well-known, schema có định kiểu và luồng sự kiện chuẩn sẽ giúp bảo đảm khả năng tương thích với hệ sinh thái công cụ, dịch vụ và agent
1 bình luận
Tổng hợp lại thế này mới thấy có quá nhiều giao thức liên quan đến AI.