Blog / Series AI Agents Thực Chiến

A2UI 2026: khi AI agents bắt đầu trả lời bằng giao diện native

Chủ đề này đang tăng nhiệt ở đâu

Cuối tháng 4/2026, trang chủ Google Developers Blog tiếp tục đẩy nổi bật A2UI v0.9 như một mốc mới cho generative UI: có agent SDK, React renderer chính thức, transport gọn hơn và khả năng chạy qua A2A, AG-UI, REST, WebSockets hay MCP. Trước đó, Google đã công khai dự án qua bài Introducing A2UI, đặt vấn đề rất rõ: agent từ xa không thể chạm trực tiếp vào UI của bạn, nhưng người dùng vẫn cần một trải nghiệm native thay vì iframe lạc quẻ hoặc text chat lê thê.

Tín hiệu nóng ở đây không chỉ nằm ở một spec mới. Nó nằm ở chuyện lớp giao diện của agent đang được tách thành một bài toán kiến trúc độc lập. AIWiki đã có bài về MCP và tool calling, A2A Protocol, agentic browser và agent registry. Nhưng giữa các lớp đó vẫn còn một khoảng trống: khi agent đã biết làm việc rồi, nó trình bày kết quả ra sao để người dùng có thể thao tác tiếp ngay.

Đó chính là lý do A2UI đáng theo dõi. Nó không cố làm model thông minh hơn. Nó làm cho đầu ra của agent dễ dùng hơn, an toàn hơn và ít phá UX hơn.

A2UI là gì ở tầng kiến trúc

Nếu mô tả ngắn gọn, A2UI là một định dạng khai báo để agent gửi cấu trúc giao diện thay vì gửi HTML, JavaScript hoặc chỉ một đoạn văn bản. Agent nói rằng nó muốn hiển thị thẻ nào, trường nhập nào, biểu đồ nào, nút nào, layout nào; còn ứng dụng chủ ánh xạ những phần đó sang component nội bộ của mình.

Điểm quan trọng nhất là quyền render nằm ở client, không nằm ở agent. Agent chỉ gửi ý định và dữ liệu. Ứng dụng của bạn mới quyết định render bằng React, Flutter, Angular, Lit hay component nội bộ. Điều này khác rất xa kiểu “LLM tạo HTML rồi nhét vào iframe”.

Từ góc nhìn hệ thống, A2UI làm ba việc cùng lúc:

• biến UI thành một dạng output có cấu trúc, giống như structured outputs nhưng ở tầng trải nghiệm;
• cho phép agent từ xa nói chuyện với frontend qua trust boundary mà không cần quyền chạm trực tiếp vào DOM hay native view tree;
• tách riêng phần agent quyết định nên hiện gì khỏi phần ứng dụng quyết định hiện như thế nào.

Đây là mức trừu tượng rất hợp với kỷ nguyên agent. Khi agent chỉ chat, text là đủ. Khi agent bắt đầu bán hàng, hỗ trợ hiện trường, chăm sóc sức khỏe, điều phối lịch, sửa lỗi phần mềm hay làm việc đa bước, text thường không còn là đầu ra tối ưu. Người dùng cần chọn, xác nhận, kéo thả, lọc, xem bản đồ, kiểm chứng số liệu, điền form và ra quyết định tiếp. UI lúc đó không phải lớp trang trí; nó là phần của workflow.

Use case end-to-end: trợ lý bồi thường và dịch vụ hiện trường

Hãy lấy một ví dụ thực tế hơn các demo card đẹp mắt. Một công ty bảo hiểm muốn triển khai trợ lý AI cho hai nhóm người dùng: khách hàng gửi yêu cầu bồi thường trên di động và nhân viên hiện trường xử lý hồ sơ trên tablet.

Bước 1: người dùng gửi ảnh và mô tả, agent phải hiểu đúng ngữ cảnh

Khách hàng chụp ảnh xe va quệt, nhập vài dòng mô tả và yêu cầu tạo hồ sơ. Phía sau, một agent dùng vision model để đọc ảnh, phân loại loại hư hại, ước lượng mức độ nghiêm trọng và lấy policy phù hợp. Nếu chỉ trả bằng text, agent sẽ phải yêu cầu người dùng trả lời qua nhiều lượt: ngày xảy ra, địa điểm, số người liên quan, gara mong muốn, giấy tờ nào còn thiếu.

Với A2UI, agent có thể trả về ngay một giao diện native gồm:

• thẻ tóm tắt hồ sơ đã nhận diện được;
• form chỉ hiện những trường còn thiếu;
• lịch chọn buổi giám định gần nhất;
• bản đồ gara được bảo lãnh;
• nút xác nhận gửi hồ sơ hoặc chuyển sang gọi nhân viên hỗ trợ.

Người dùng không phải bơi trong một đoạn chat dài. Họ chỉ thấy đúng giao diện cần cho bước tiếp theo.

Bước 2: hồ sơ chuyển qua agent từ xa nhưng UX vẫn native

Sau khi gửi, hồ sơ không còn do agent trên điện thoại xử lý trực tiếp. Nó có thể được chuyển qua một agent đánh giá tổn thất ở backend, hoặc thậm chí qua một agent đối tác bên gara. Đây là lúc trust boundary xuất hiện. Agent từ xa không được quyền đụng vào app của bạn, nhưng nó vẫn cần gửi lại UI cập nhật cho nhân viên hiện trường.

A2UI cho phép agent đó trả lại giao diện như:

• checklist kiểm tra thân vỏ, đèn, kính, lốp;
• khung nhập chi phí ước tính với validation cứng;
• ảnh trước/sau theo từng góc chụp bắt buộc;
• biểu đồ chênh lệch giữa ước tính AI và báo giá gara;
• nút escalate sang giám định viên cao cấp khi vượt ngưỡng chính sách.

Điều đáng chú ý là toàn bộ UI này vẫn có thể mang đúng màu sắc, font, spacing, accessibility và logic tương tác của ứng dụng gốc. Agent không “vẽ app mới”; agent chỉ đề xuất cấu trúc trên catalog component mà ứng dụng đã cho phép.

Bước 3: con người ra quyết định ở nơi giá trị nhất

Ở đây agent không thay con người hoàn toàn. Nó giúp rút ngắn các bước lặp lại và gom ngữ cảnh thành một UI hành động được. Nhân viên chỉ cần vào những điểm có giá trị đánh giá cao: chênh lệch lớn giữa báo giá, dấu hiệu gian lận, hồ sơ thiếu giấy tờ quan trọng hoặc case vượt policy. Đây là tinh thần giống với bài workflow, memory, approval: hệ tốt không để con người lái từng bước, mà đưa con người tới đúng điểm quyết định.

Tầng hệ thống: catalog, renderer, transport, sync, policy và trace

Đằng sau một UI trông mượt mà là cả một lớp hạ tầng. Nếu muốn A2UI đi vào production, ít nhất bạn cần làm rõ sáu phần sau.

1. Component catalog là biên giới quyền lực thật sự

Catalog quyết định agent được “nói” những gì ở tầng giao diện. Nếu catalog chỉ có card, text, button, form field và chart cơ bản, agent không thể tự tiện sinh ra widget lạ hoặc chạy script tùy ý. Đây là điểm khác biệt quan trọng về an toàn. Trong A2UI, client không nhận code lạ; client chỉ nhận yêu cầu dùng các khối đã được duyệt trước.

Về thực tế triển khai, catalog nên đi kèm metadata như quyền truy cập, nền tảng hỗ trợ, ràng buộc dữ liệu, ví dụ few-shot và mô tả ngữ nghĩa để agent chọn đúng component.

2. Renderer là nơi UX thật sự được giữ thống nhất

Google nhấn mạnh chuyện A2UI chạy đa framework, và v0.9 đẩy thêm React cùng web-core library. Điều đó quan trọng vì đội frontend không muốn ném bỏ design system đã đầu tư nhiều năm. Renderer tốt giúp payload A2UI được ánh xạ sang component nội bộ mà không làm UX bị “ngoại lai”.

Nói cách khác, A2UI chỉ có ý nghĩa khi đội frontend cảm thấy nó đi cùng hệ hiện tại, không phải ép họ xây một ngăn xếp UI riêng cho agent.

3. Transport quyết định agent nói chuyện với ai và bằng nhịp nào

A2UI không tự thay thế transport. Nó có thể đi qua AG-UI, A2A, WebSockets, REST hoặc các lớp trung gian khác. Đây là chi tiết nhiều người hay bỏ qua. Một production stack thường cần tách ba câu hỏi:

• agent nào sở hữu logic nghiệp vụ;
• giao thức nào chở message và state;
• định dạng nào mô tả UI để client render.

Khi tách được ba lớp này, bạn mới có quyền thay agent backend, thay transport hoặc thay renderer mà không đập toàn bộ bề mặt sản phẩm.

4. Client-server sync và validation là phần làm mọi thứ bớt mong manh

A2UI v0.9 đưa thêm client-defined functions, đồng bộ dữ liệu hai chiều và streaming chịu lỗi tốt hơn. Những chi tiết này cực kỳ quan trọng ở ngoài demo. Một form tạo bởi agent mà không có validation cứng sẽ nhanh chóng thành ác mộng. Một UI không đồng bộ state tốt sẽ tạo ra tình huống người dùng sửa xong nhưng agent không thấy. Một luồng streaming không có cơ chế “heal” JSON sẽ vỡ vụn ngay khi model lạc format.

Đội ngũ nên xem lớp này như phần mở rộng của structured outputs + state machine, không phải chi tiết giao diện thuần túy.

5. Policy và security phải đứng trước tính linh hoạt

Bài Agent Security 2026 đã nói nhiều về prompt injection, tool abuse và data exfiltration. Với generative UI, rủi ro đổi dạng chứ không biến mất. Câu hỏi mới là:

• agent có thể đề xuất component nào cho người dùng bấm?
• component nào được phép gọi hành động nhạy cảm?
• dữ liệu nào được đổ vào giao diện, dữ liệu nào phải mask?
• agent có được sinh ra bước xác nhận giả gây nhầm lẫn không?

Nói ngắn gọn, UI cũng là một bề mặt tấn công. Chỉ khác là thay vì code injection trực tiếp, rủi ro nằm ở lạm dụng luồng tương tác, thuyết phục người dùng bấm nhầm, hoặc để lộ dữ liệu nhạy cảm qua widget tưởng như vô hại.

6. Observability phải trace từ prompt tới component

Nếu một UI sinh ra sai, lỗi có thể nằm ở nhiều lớp: model hiểu sai ngữ cảnh, catalog mô tả kém, renderer map sai prop, transport cắt mất message, validator sửa JSON quá tay, hoặc state sync trượt phiên bản. Vì thế quan sát phải trace được ít nhất:

• agent nào sinh payload;
• catalog phiên bản nào được chọn;
• renderer nào đang dùng;
• component nào được render hoặc bị từ chối;
• sự kiện người dùng tương tác nào quay ngược về agent.

Không có trace kiểu này, đội ngũ sẽ chỉ thấy một kết quả mơ hồ: “UI của agent lúc được lúc không”.

A2UI khác AG-UI, A2A và MCP Apps ở điểm nào

Đây là đoạn rất dễ lẫn nếu chỉ đọc lướt các thông báo sản phẩm.

A2UI không phải AG-UI

AG-UI nghiêng về lớp kết nối full-stack giữa agentic backend và agentic frontend: state, lịch sử, message, middleware, scaffolding ứng dụng. A2UI tập trung hơn vào định dạng giao diện khai báo mà agent gửi cho client. Có thể hiểu đơn giản: AG-UI là đường ống tương tác; A2UI là một kiểu payload rất quan trọng chạy trong đường ống đó.

A2UI không phải A2A

A2A giải quyết chuyện agent nói chuyện với agent qua trust boundary. A2UI giải quyết chuyện agent nói chuyện với giao diện người dùng mà vẫn giữ an toàn và tính native. Hai lớp này bổ sung cho nhau. Bài về A2A trên AIWiki đi vào coordination giữa agent; A2UI kéo câu chuyện đó tới tận màn hình cuối cùng mà người dùng chạm vào.

A2UI cũng không giống MCP Apps

Theo mô tả của chính Google, MCP Apps đi theo hướng coi UI như một resource được tool/server trả về, thường được render như nội dung có tính đóng gói cao hơn. A2UI đi theo hướng native-first: gửi blueprint của component, để host app render bằng design system của chính nó. Nếu mục tiêu của bạn là giữ giao diện đồng nhất xuyên web, mobile, desktop và nhiều agent từ xa, đây là khác biệt rất lớn.

Nhìn ở tầng kiến trúc, ba lớp này không loại trừ nhau. Một hệ mạnh có thể dùng MCP cho tool surface, A2A cho liên lạc agent từ xa, AG-UI cho luồng tương tác full-stack và A2UI cho phần giao diện được agent điều khiển có kiểm soát.

Trade-off, failure mode và nơi dễ hiểu sai

1. Declarative UI không tự động tạo UX tốt

A2UI giúp agent gửi UI an toàn hơn, nhưng không đảm bảo UI đó tốt. Nếu catalog kém, ví dụ thiếu pattern cho selection, xác nhận, so sánh hoặc progressive disclosure, agent vẫn sẽ ghép ra những trải nghiệm khó dùng. Bạn không thể outsource toàn bộ UX judgement cho model.

2. Catalog phình to rất nhanh

Đội nào nghiêm túc sẽ sớm muốn thêm hàng chục component, biến thể, props, quyền truy cập và logic điều kiện. Nếu không có governance, catalog sẽ thành một API khổng lồ khó dạy cho model và khó bảo trì cho frontend. Đây là phiên bản giao diện của bài toán knowledge gap: model chỉ làm tốt khi hệ thống dạy nó dùng đúng khối đúng lúc.

3. Streaming đẹp trên demo chưa chắc bền ngoài production

UI sinh từng phần nghe rất hấp dẫn, nhưng nếu payload thay đổi liên tục, người dùng có thể thấy layout nhảy, form reset, nút đổi vị trí hoặc validation đến muộn. Cảm giác này làm mất niềm tin rất nhanh. Với workflow quan trọng, đôi khi chiến lược tốt hơn là stream ở mức skeleton hoặc card riêng, thay vì stream mọi mảnh nhỏ.

4. Native-first đánh đổi một phần tự do biểu đạt

Đây là đánh đổi cố ý. Khi chỉ cho agent dùng component đã được duyệt, bạn sẽ mất khả năng “vẽ bất cứ thứ gì”. Nhưng đổi lại, bạn có an toàn, accessibility, theo dõi, quyền kiểm soát và khả năng tái dùng đa nền tảng. Với doanh nghiệp, đây thường là đánh đổi đúng.

5. Version negotiation và tương thích ngược sẽ thành việc thật

Khi có nhiều client web/mobile/desktop, nhiều renderer và nhiều agent độc lập, câu hỏi “phiên bản catalog nào, schema nào, capability nào” sẽ xuất hiện rất sớm. Nếu bỏ qua từ đầu, generative UI sẽ bị phân mảnh y như API nội bộ không có versioning.

6. Dễ nhầm giữa “agent điều khiển UI” và “agent nên điều khiển mọi UI”

Không phải màn hình nào cũng nên do agent dựng ra. Trang quản trị lõi, luồng pháp lý nhạy cảm, nghiệp vụ đòi hỏi tuân thủ cứng hoặc thao tác tần suất rất cao thường vẫn cần UI tĩnh tối ưu thủ công. A2UI mạnh nhất ở nơi giao diện cần thích ứng theo ngữ cảnh, không phải ở nơi quy trình đã cố định và được tối ưu đến từng pixel.

Checklist rollout thực dụng trong 90 ngày

30 ngày đầu: chọn một bề mặt hẹp nhưng thật

• Chọn một workflow có đủ biến thiên để text thuần tỏ ra bất tiện.
• Ưu tiên nơi có vài component lặp lại: form bổ sung, card tóm tắt, checklist, bảng so sánh, selector.
• Thiết kế catalog tối thiểu, không tham mở rộng sớm.
• Gắn validation cứng và audit log từ ngày đầu.

30 ngày tiếp theo: nối với transport, state và observability

• Quyết định rõ A2UI đi qua AG-UI, A2A hay transport riêng.
• Trace toàn bộ vòng đời từ prompt tới component render.
• Đo tỷ lệ component bị từ chối, tỷ lệ người dùng hoàn thành tác vụ, thời gian tới outcome usable.
• Ghi lại các payload agent phải “heal” hoặc sửa schema để tìm đúng failure mode.

30 ngày cuối: mở rộng theo năng lực hệ thống, không theo hào hứng

• Thêm capability negotiation cho client khác nhau.
• Phân tầng component theo độ nhạy cảm và yêu cầu approval.
• Xác định luồng nào nên cho agent dựng UI, luồng nào vẫn giữ UI thủ công.
• Chỉ mở catalog sau khi hiểu rõ component nào thực sự tăng completion rate.

Insight cuối cùng: AI agent đang đi từ “trả lời đúng” sang “tạo ra bề mặt làm việc đúng”

Chúng ta đã quen nhìn năng lực của agent qua prompt, tool call và benchmark. Nhưng ở giai đoạn production, một năng lực khác đang nổi lên nhanh không kém: khả năng tạo ra đúng bề mặt tương tác cho đúng việc, đúng người, đúng thiết bị và đúng ranh giới an toàn.

A2UI đáng chú ý không phải vì nó là thêm một chuẩn mới cho frontend. Nó đáng chú ý vì nó biến giao diện thành phần mở rộng có cấu trúc của hệ agent. Khi đó, cuộc chơi không chỉ còn là agent lấy dữ liệu hay thực thi hành động, mà là agent dựng được điểm tiếp xúc nơi con người tiếp quản, kiểm tra và hoàn tất công việc.

Nếu MCP mở rộng cánh tay của agent tới tool, A2A mở rộng mạng lưới phối hợp giữa agent, thì A2UI đang mở rộng mặt tiền sản phẩm của agent. Đó là một dịch chuyển rất thực dụng. Và với nhiều đội ngũ, đây có thể là bước còn thiếu để agent thoát khỏi khung chat và đi vào trải nghiệm phần mềm thật.