Giao diện do AI tạo có thể biến câu trả lời thành một biểu đồ, bộ lọc hay công cụ nhỏ phù hợp với câu hỏi ngay lúc đó. Nhưng để đưa cách làm này vào sản phẩm, đội kỹ thuật cần kiểm soát cấu trúc, dữ liệu, quyền hành động và đường lui khi mô hình hoặc renderer sai.
Từ câu trả lời sang giao diện
Phần lớn ứng dụng số đặt con người trước một tập màn hình và quy trình đã thiết kế trước. Cách đó có tính dự đoán: nút “Đặt lịch” luôn ở cùng chỗ, form có trường bắt buộc và validation rõ ràng. Đổi lại, một giao diện tĩnh khó bao quát mọi câu hỏi và hoàn cảnh. Câu hỏi “so sánh ba gói cước” có thể phù hợp với bảng, còn “giải thích lãi kép” có thể dễ hiểu hơn nếu người đọc kéo thanh trượt để đổi số năm.
Generative UI đưa ra một lựa chọn khác: agent chọn và sắp xếp các thành phần giao diện theo nhiệm vụ, rồi ứng dụng hiển thị chúng trong một vỏ kiểm soát được. Đây không phải cách gọi chung cho mọi ứng dụng có chatbot. Cần phân biệt UI thích ứng theo quy tắc, UI được tạo theo ngữ cảnh và agent dùng computer-use để thao tác một giao diện vốn đã tồn tại. Hình 1 tóm tắt ba cơ chế theo hai câu hỏi: ai quyết định bố cục và agent có đang điều khiển ứng dụng có sẵn hay không.
Hình 1. Bản đồ ba cơ chế UI. Sơ đồ gốc của tác giả, tạo cho bài này; không dùng tài sản bên ngoài. Alt: “UI thích ứng theo quy tắc dùng bố cục đã định, generative UI sắp thành phần theo ngữ cảnh, còn computer-use thao tác UI có sẵn.”
Intelligent UI của ChatGPT: điều đã được công bố
Ngày 7/10/2026, OpenAI giới thiệu Intelligent UI trong ChatGPT như một năng lực của GPT-6 để phối hợp văn bản, hình ảnh và phần tử tương tác tùy câu hỏi. Ví dụ được công bố gồm câu trả lời trực quan, giải thích có thể khám phá từng bước, và công cụ tức thời như bộ chia hóa đơn, máy tính tiết kiệm hoặc trò chơi nhỏ. OpenAI nói mô hình được huấn luyện để chọn cách trình bày và có thể trả lời bằng văn bản khi đó là lựa chọn phù hợp.
Điểm kiến trúc đáng chú ý trong mô tả chính thức là “thư viện component native, có thể stream” cùng một compiler xử lý giao diện trong lúc mô hình sinh ra. Theo OpenAI, cách này cho phép giao diện xuất hiện dần thay vì đợi toàn bộ nội dung hoàn tất; thư viện tạo nền thiết kế quen thuộc, còn mô hình quyết định cách ghép các phần. Đây là mô tả sản phẩm từ nhà cung cấp. Bài công bố không nêu schema giao diện công khai, API cho bên thứ ba, định dạng stream, quy tắc sandbox hay hợp đồng tương thích component. Vì vậy không nên biến các chi tiết nội bộ chưa công bố thành một kiến trúc có thể tái tạo.
Một minh họa trong trang giới thiệu là kế hoạch bữa tối: nội dung có danh sách món, lượng nguyên liệu thay đổi theo số khách và checklist theo thời gian. Giá trị của giao diện ở đây không nằm ở việc “trông đẹp”, mà ở sự gắn kết giữa câu trả lời và điều khiển: thay đổi số người có thể cập nhật danh sách mua sắm; checklist biến hướng dẫn thành tiến trình. Tuy vậy, trang giới thiệu không phải đánh giá độc lập về độ chính xác của công thức hoặc mức cải thiện hoàn thành tác vụ. Đội sản phẩm cần thử từng miền dữ liệu của mình, nhất là khi lỗi đầu vào có thể gây hậu quả.
Hình 2 tách hai luồng để tránh một suy diễn dễ gặp: Intelligent UI là hệ thống sản phẩm OpenAI được mô tả ở mức khái quát; A2UI là giao thức mở có đặc tả và mã nguồn. Không có nguồn được dẫn ở đây chứng minh ChatGPT sử dụng, tương thích hay chia sẻ schema với A2UI.
Hình 2. Hai pipeline độc lập. Sơ đồ gốc của tác giả, dựa trên mô tả công khai của OpenAI và tài liệu A2UI; nhãn “chưa công bố” chỉ vùng thiếu bằng chứng. Alt: “Pipeline Intelligent UI được OpenAI mô tả và pipeline A2UI có giao thức kiểm tra catalog được trình bày riêng, không có đường nối tương thích.”
A2UI: agent gửi mô tả, ứng dụng quyết định cách render
A2UI (Agent-to-UI) giải quyết một ranh giới khác: làm sao agent gửi giao diện phong phú qua một ranh giới tin cậy mà không gửi mã tùy ý để chạy trong ứng dụng. Tài liệu dự án mô tả agent phát ra các message có cấu trúc; client diễn giải chúng bằng component catalog và renderer của chính client. Catalog đóng vai trò danh sách thành phần và thuộc tính được phép. Ứng dụng có thể xây renderer riêng cho web, mobile hoặc desktop, trong khi agent không được tùy tiện tải và thực thi JavaScript để dựng màn hình.
Trong A2UI v0.9, capability của client được gửi trong metadata của transport hoặc payload khởi tạo, không phải như một message hay field capability chung của UI. a2uiClientCapabilities nêu catalog ID mà renderer hỗ trợ (supportedCatalogIds) và có thể kèm catalog inline khi tích hợp cho phép. Agent chọn catalog phù hợp cho surface; client kiểm tra message theo schema/catalog đã thống nhất, liên kết dữ liệu rồi render bằng component đã cài đặt. Trao đổi phiên bản spec cần được xử lý riêng ở lớp SDK/transport; ví dụ SDK A2UI v0.9 mô tả version negotiation theo khả năng của client, nhưng không biến version negotiation thành field trong client capability v0.9. Hình 3 tóm tắt các bước, trong đó capability đi qua metadata và version được xử lý riêng.
Hình 3. Chu trình A2UI v0.9. Sơ đồ gốc của tác giả, dựa trên đặc tả v0.9; capability đi qua transport metadata, còn lựa chọn phiên bản thuộc lớp SDK/transport. Không đại diện cho một tích hợp VTI. Alt: “Client gửi a2uiClientCapabilities qua transport metadata; agent gửi mô tả UI; client kiểm tra catalog, render và chuyển action được phép.”
Cần tách ba khái niệm thường bị nhập làm một. Thứ nhất, schema mô tả hình dạng message hợp lệ. Thứ hai, catalog định nghĩa các component và chức năng mà renderer hiểu. Thứ ba, renderer ánh xạ mô tả đó sang giao diện thực tế. Hai client cùng nhận một message không đảm bảo hình ảnh, accessibility hay hành vi giống hệt nhau nếu catalog hoặc renderer khác nhau. Khả năng tương tác phụ thuộc vào việc các bên thống nhất phiên bản, catalog, binding và ngữ nghĩa action, chứ không chỉ cùng “dùng JSON”.
Ở các phiên bản giao thức gần đây, A2UI hướng tới mô hình prompt-first và cho phép catalog tùy biến. Dữ liệu động có thể gắn với vị trí trong model dữ liệu; message cập nhật surface hoặc component có thể được xử lý dần. Tuy nhiên “streaming” không đồng nghĩa mọi phần tử đều an toàn để hiển thị ngay: client cần xử lý message chưa đầy đủ, thứ tự đến, hủy hoặc tạo lại surface và trạng thái lỗi. Hành động tương tác cũng cần hợp đồng rõ: một nút xác nhận không nên bị hiểu giống một lời gọi có side effect nếu chưa kiểm tra quyền và xác nhận của người dùng.
Cần khóa đúng version khi đọc tài liệu. Release GitHub ngày 8/10/2026 liệt kê a2ui-core 0.3.0 và a2ui-agent-sdk 0.8.0; hai package không phải số phiên bản của cùng một thứ. SDK 0.8.0 yêu cầu core từ 0.3.0 đến trước 0.4.0 và ghi nhận thay đổi breaking liên quan validation/catalog. Trang tài liệu A2UI tại thời điểm kiểm tra nêu v0.9.1 là bản giao thức hiện hành, v0.9 là stable trước đó, còn v0.8 là legacy. Do đó bài này dùng release package 0.8.0/0.3.0 làm mốc kiểm tra SDK/core, nhưng khi nói về khái niệm giao thức phải chỉ rõ phiên bản spec; không thể suy ra package SDK 0.8.0 chỉ hỗ trợ spec 0.8.
Ranh giới an toàn nằm ở ứng dụng
Mô hình có thể đề xuất bố cục, nhưng ứng dụng vẫn phải quyết định điều gì được hiển thị và điều gì được phép xảy ra. Cách tiếp cận thực tế là allowlist component theo use case, giới hạn độ sâu cây và kích thước payload, xác thực kiểu và miền giá trị, rồi từ chối hoặc thay thế thành phần không biết. Thông tin nhạy cảm nên đến từ dịch vụ có quyền truy cập phù hợp, không phải từ dữ liệu do mô hình tự điền. Renderer cần coi mọi chuỗi là nội dung không tin cậy, tránh diễn giải HTML hay biểu thức tùy ý.
Action nên được phân tầng theo hậu quả. Mở rộng một tab hay đổi bộ lọc thường có thể xử lý tại client. Gửi yêu cầu, đặt lịch, chuyển tiền hoặc xóa dữ liệu cần kiểm tra quyền ở backend, hiển thị tóm tắt dễ hiểu và xin xác nhận tại thời điểm phù hợp. Không nên xem nhãn nút do model sinh là bằng chứng về ý định hợp lệ. Server phải kiểm tra người dùng, đối tượng, trạng thái hiện tại và tính lặp an toàn; giao diện chỉ là lớp tương tác, không phải ranh giới bảo mật.
Fallback cũng là một phần của thiết kế. Nếu payload sai schema, catalog không hỗ trợ component, stream bị ngắt hoặc renderer lỗi, ứng dụng nên giữ lại phần văn bản hữu ích và cho phép quay về form hoặc luồng tác vụ chuẩn. Ghi nhận loại lỗi, version, thời gian đến component đầu tiên và tỷ lệ fallback giúp nhóm phân biệt lỗi mô hình với lỗi tích hợp. Các phép đo cần đặt cạnh task success, độ chính xác dữ liệu, thời gian hoàn thành, khả năng dùng bàn phím/đọc màn hình, chi phí suy luận và mức độ người dùng phải sửa kết quả. Hình 4 gợi ý cách chọn theo mức kiểm soát và một số chỉ số để thử; đây là khung đánh giá, không phải kết quả thực nghiệm.
Hình 4. Ma trận lựa chọn và đo lường. Sơ đồ gốc của tác giả; tiêu chí là đề xuất đánh giá, không phải benchmark. Alt: “Bảng so sánh form tĩnh, UI theo quy tắc, generative UI và computer-use theo quyền kiểm soát cùng các phép đo cần thử.”
Khi nào nên dùng UI sinh theo ngữ cảnh
Một ví dụ giả định là trợ lý bảo hiểm giúp khách hàng hiểu quyền lợi của một gói. Một câu hỏi định nghĩa có thể cần văn bản; so sánh hai mức khấu trừ có thể cần bảng; ước lượng khoản hoàn trả có thể cần vài đầu vào. Đội sản phẩm có thể định nghĩa catalog gồm đoạn văn, bảng so sánh, bộ chọn số và nút “tạo bản ước tính”. Client kiểm tra loại dữ liệu và giới hạn giá trị; backend tính toán từ điều khoản có phiên bản; action cuối mở bước xác nhận trước khi gửi yêu cầu. Nếu chưa xác minh danh tính hoặc dữ liệu hợp đồng không có, UI phải nói rõ giới hạn và chuyển sang kênh hỗ trợ.
Generative UI hữu ích nhất khi các tác vụ cùng một miền có nhiều hình thức đầu ra nhưng vẫn có thể diễn đạt bằng tập component nhỏ, có ý nghĩa. Nó kém phù hợp khi quy trình pháp lý đòi bố cục cố định, khi sai lệch hiển thị làm thay đổi nghĩa, hoặc khi ứng dụng chưa có cách xác thực dữ liệu và quyền hành động. Giao diện tạo mới cũng có chi phí: thiết kế accessibility, localization, kiểm thử tổ hợp và phân tích sự cố phức tạp hơn so với một form chuẩn.
A2UI cung cấp một hướng để chuẩn hóa ranh giới message giữa agent và client, nhưng không tự giải quyết xác thực người dùng, quản trị dữ liệu, chất lượng nội dung hoặc khả năng tiếp cận. Intelligent UI cho thấy một sản phẩm có thể xây thư viện và compiler nội bộ để phục vụ trải nghiệm tích hợp, nhưng thông tin công bố hiện không đủ để suy ra API bên ngoài. Vì vậy lựa chọn kiến trúc cần bắt đầu từ phạm vi tác vụ và mức kiểm soát cần thiết, sau đó mới quyết định giao diện nào nên được sinh.
Kết luận
UI do AI tạo đáng xem như một lớp trình bày linh hoạt nằm trên component, dữ liệu và quyền hạn do ứng dụng quản lý. Trước khi mở rộng, hãy đo chất lượng trên tác vụ thật, kiểm soát action ở backend và giữ một lối fallback dễ hiểu; giao diện linh hoạt chỉ hữu ích khi hệ thống vẫn có thể giải thích và kiểm chứng điều nó đang làm.
Nguồn và giới hạn kiểm chứng
• OpenAI, GPT-6 and Intelligent UI for everyone, 07/10/2026. Nguồn sơ cấp về phạm vi sản phẩm và mô tả component/stream/compiler; chưa công bố schema/API hay đánh giá độc lập UX.
• OpenAI, GPT-6 model data and training, đối chiếu release context. Không dùng làm đặc tả UI.
• A2UI, GitHub releases, tag python/a2ui-core/v0.3.0, python/a2ui-agent-sdk/v0.8.0, commit release 6175393, ngày 08/10/2026. Release notes là nguồn cho thay đổi package; không đồng nhất với phiên bản protocol.
• A2UI, tài liệu giao thức, trạng thái phiên bản được kiểm tra 12/10/2026; repository. Đây là tài liệu dự án đang phát triển; triển khai cần khóa tag/spec cụ thể.
• Google Developers Blog, A2UI v0.9, 17/04/2026, bối cảnh phát triển giao thức.
• VTI TechBlog, Tự động hóa Mobile bằng AI với Mobile MCP, trang trả HTTP 200 khi kiểm tra 12/10/2026 và tiêu đề khớp. HTML tuyên bố canonical là https://www.crm.vtitech.vn/tu-dong-hoa-mobile-bang-ai-voi-mobile-mcp/; canonical đó không xác minh TLS được trong môi trường kiểm tra. Dùng permalink công khai hoạt động làm liên kết; biên tập nên xác nhận đường canonical CMS trước xuất bản.
Vui lòng đăng nhập để bình luận.