Phần lớn team ship “tính năng AI” năm 2026 vẫn dùng cùng một kiểu UI: một ô nhập text, response stream ra, thi thoảng có bảng markdown nếu model “hứng” format. Agency thiết kế Wavespace tuần này công bố một framework tên Beyond the Chatbox, gọi tên đúng vấn đề mà tôi gặp ở mọi sản phẩm hướng agent năm nay — cửa sổ chat vốn là một interface debug đã “trốn thoát” ra production, và nó đang chống lại chính thứ mà sản phẩm agentic cần mang lại.
Luận điểm thực sự
Framework này không nói “chat là xấu”. Nó nói rằng chat-là-interface-duy-nhất đang gộp chung ba thứ vốn cần tách biệt: agent suy luận thế nào, task đang ở trạng thái gì, và người dùng cần nhìn/hành động gì ngay bây giờ. Một luồng text thuần túy ép cả ba thứ vào một kênh tuyến tính, nghĩa là người dùng phải đọc văn xuôi để hiểu “nó có xong bước 2 chưa” hay “bảng này chỉnh sửa được hay chỉ là tóm tắt”. Generative UI — nơi agent quyết định render component nào, không chỉ nói gì — cho phép sản phẩm tách các mối quan tâm đó ra lại: reasoning hiển thị ở một chỗ, state ở chỗ khác, và một interface theo đúng loại task (form, bảng, wizard theo bước) cho việc người dùng thực sự cần làm tiếp theo.
Framework xoay quanh vài nguyên tắc ánh xạ trực tiếp vào quyết định kỹ thuật, không chỉ là gu thiết kế:
- Reasoning hiển thị (visible reasoning) — hiện kế hoạch hoặc bước trung gian của agent dưới dạng state có cấu trúc, không phải văn xuôi tường thuật mà người dùng phải đọc để hiểu tiến độ.
- Tín hiệu tin cậy rõ ràng (explicit trust cues) — UI nên hiện độ tin cậy, nguồn, hoặc phân biệt “đây là bản nháp vs đây là bản cuối” một cách rõ ràng, thay vì dựa vào ngôn ngữ rào đón trong text.
- Checkpoint phê duyệt là UI, không phải lượt chat — một cổng phê duyệt nên là nút bấm trên một diff hoặc form được render, không phải “gõ yes để xác nhận” chôn trong luồng chat.
- Interface theo đúng loại task — agent chọn đúng widget (bảng để so sánh, form để sửa lỗi, wizard cho task nhiều bước) thay vì dùng bong bóng chat cho mọi thứ.
Con số làm rõ vấn đề
Wavespace dẫn một case study: một công cụ sales-ops thay flow chỉ-có-chat bằng generative UI — bảng pipeline live, form inline để sửa lỗi dữ liệu, wizard theo bước cho task nhiều giai đoạn — và ghi nhận hoàn thành task nhanh hơn 38%, số ticket hỗ trợ giảm 22% sau bốn tuần. Nên nhìn các con số cụ thể này với một chút dè dặt hợp lý (một case study đơn lẻ, do vendor công bố), nhưng cơ chế đứng sau con số thì hợp lý về bản chất: người dùng hoàn thành task nhanh hơn với một form so với một đoạn văn bảo họ gõ gì — điều này đúng bất kể form đó do con người hay AI tạo ra.
Trông như thế nào trong stack triển khai thực tế
Đây không phải ý tưởng mới về mặt lý thuyết — generative UI đã là chủ đề nghiên cứu vài năm nay — nhưng 2026 là năm mà tooling bắt kịp đủ để nó trở thành lựa chọn mặc định hợp lý thay vì một dự án nghiên cứu. Pattern đang hội tụ giữa các framework:
// Agent phát ra một directive UI có kiểu, thay vì free text
type AgentAction =
| { type: "render_table"; data: Row[]; editable: boolean }
| { type: "render_form"; schema: JSONSchema; onSubmit: string }
| { type: "render_wizard"; steps: WizardStep[] }
| { type: "request_approval"; diff: Diff; actions: ["approve", "reject"] }
| { type: "text"; content: string };
// Frontend ánh xạ directive sang component thật — agent không bao giờ
// kiểm soát markup trực tiếp, chỉ chọn component nào và data gì
function renderAgentAction(action: AgentAction) {
switch (action.type) {
case "render_table": return <PipelineTable {...action} />;
case "render_form": return <DynamicForm schema={action.schema} />;
case "request_approval": return <DiffApprovalCard {...action} />;
default: return <ChatBubble text={action.content} />;
}
}Quyết định thiết kế then chốt — và cũng là điều đáng làm đúng trước khi build bất cứ gì — là agent nên chọn component nào, không sinh ra markup tùy ý. Để model phát ra HTML hoặc JSX thô vừa là vấn đề bảo mật (prompt injection biến thành vector UI injection) vừa là vấn đề nhất quán (design system của bạn không còn là design system nữa). Một vocabulary hành động có ràng buộc — một tập cố định các directive UI có kiểu mà agent chọn từ đó — cho bạn sự linh hoạt “agent quyết định hiện gì” mà không mất kiểm soát việc thực sự render ra cái gì. Đây cùng bản năng với constrained function-calling schema, chỉ áp dụng cho frontend thay vì backend.
Cũng đang nổi lên một lớp protocol ở đây — AG-UI và các định dạng wire agent-to-UI tương tự đang cố chuẩn hóa vocabulary directive này giống cách MCP chuẩn hóa tool-calling, để agent và frontend do các team khác nhau xây có thể nói chung “ngôn ngữ” kiểu “hãy render cái này”. Đáng theo dõi trước khi bạn tự phát minh schema riêng từ đầu.
Điểm tôi phản biện
Framework này đúng về đích đến nhưng đánh giá thấp cái giá của con đường đến đó. Chat là UI mặc định của agent không phải vì chưa ai nghĩ ra lựa chọn khác, mà vì nó là interface duy nhất degrade một cách “mềm” khi agent đoán sai điều người dùng cần. Nếu agent của bạn chọn sai component — render một form khi người dùng chỉ muốn câu trả lời nhanh, hoặc một wizard khi chỉ cần sửa một field — bạn đã tạo ra trải nghiệm tệ hơn cả text thuần, vì giờ người dùng phải vật lộn với một cấu trúc cứng nhắc thay vì chỉ đọc lướt qua một câu không liên quan. Generative UI nâng cái giá phải trả khi quyết định routing của agent sai. Team áp dụng pattern này cần có đường fallback (text thuần hoặc card chung) cho các trường hợp vocabulary có ràng buộc không bao phủ được, và cần đo tần suất agent chọn một component mà người dùng bỏ ngay lập tức — con số đó cho biết vocabulary hành động của bạn có thực sự khớp với task của người dùng, hay bạn chỉ vừa xây một câu trả lời sai đẹp hơn mà thôi.
Kết luận cho Technical Lead đang cân nhắc
Nếu vòng lặp lõi của sản phẩm bạn là “người dùng hỏi, agent trả lời, người dùng đọc” — chat là ổn, đừng thêm phức tạp. Nếu vòng lặp lõi là “người dùng cần review, sửa, phê duyệt, hoặc so sánh thứ gì đó agent tạo ra” — mô tả phần lớn sản phẩm agent B2B tôi thấy ship năm nay — thì một luồng chat đang là hình dạng sai cho tương tác đó, và cách sửa không phải là prompt hoa mỹ hơn, mà là cho agent một vocabulary nhỏ, có kiểu rõ ràng gồm các UI component để chọn thay vì chỉ có một. Đây là quyết định kiến trúc frontend nhiều như một quyết định prompt engineering, và đáng để đưa ra một cách chủ động trước khi cửa sổ chat của bạn tích tụ đầy các hack bảng markdown cố gắng trở thành một UI mà nó chưa bao giờ được thiết kế để làm.
Nguồn: