Agent-ready UI: đừng nhìn mỗi component

Agent-ready UI: đừng nhìn mỗi component

Astryx đáng bàn không vì thêm một design system, mà vì nó biến UI thành bề mặt máy có thể đọc, gọi và kiểm chứng được.

Có một kiểu demo rất quen ở team product: mở Cursor, gõ “tạo giúp tôi trang settings”, vài giây sau có một màn hình nhìn khá ổn. Cả phòng gật gù. Rồi bạn chạy thử trong codebase thật: spacing lệch, theme không ăn, component dùng sai variant, accessibility rơi đâu mất, và design system bị đối xử như menu quán cà phê mà ai cũng gọi topping theo trí nhớ.

Điểm đáng bàn ở Astryx không phải là “Meta vừa open-source thêm một React design system”. Nếu chỉ nhìn vậy thì dễ xếp nó cạnh MUI, Chakra, Radix, shadcn/ui rồi lướt qua. Thứ thú vị hơn nằm ở lớp vận hành: một design system được thiết kế để agent đọc được, gọi được, và trả về output có cấu trúc.

Sau bài này, mình muốn bạn đổi một cách nghĩ: agent-ready không có nghĩa là nhét thêm AI vào UI workflow; nó nghĩa là biến hệ thống hiện có thành một API rõ ràng cho cả người và máy.

Sơ đồ minh họa cho bài Agent-ready UI: đừng nhìn mỗi component

Sơ đồ tóm tắt ý chính của bài viết.

Tín hiệu chính: UI đang chuyển từ “nhìn được” sang “gọi được”

Astryx là design system open-source đang ở Beta, được xây trên React và StyleX. StyleX là compile-time CSS engine — hiểu ngắn là style được biên dịch thành CSS tĩnh ở build time, thay vì để runtime tự xoay xở quá nhiều.

Nó có foundations như typography, color, layout, accessibility; có component; có templates; có theme cascade bằng CSS variables; có dark mode; có TypeScript chiếm phần lớn codebase. Những thứ đó tốt, nhưng chưa phải phần lạ.

Phần lạ là Astryx đi kèm CLI và MCP server.

Nói thẳng ra thì: thay vì agent “đoán” cách dùng component qua vài file rải rác, Astryx đưa cho agent một quầy pha có menu, công thức, định lượng, và máy POS. Agent không cần giả làm designer; nó có thể hỏi hệ thống: “component này dùng thế nào?”, “template nào phù hợp?”, “API nào hợp lệ?”.

Đó là khác biệt giữa component library và machine-readable design system.

Lớp ẩn bên dưới: cấu trúc quan trọng hơn model

Nhiều team đang hiểu sai ở chỗ này: thấy agent tạo UI sai thì nghĩ cần model mới hơn. Có khi đúng. Nhưng thường vấn đề nằm ở bề mặt giao tiếp giữa codebase và agent.

Một agent muốn tạo UI ổn cần ít nhất bốn lớp:

  1. Vocabulary: hệ thống có tên gọi rõ cho component, token, theme, layout không?
  2. Contracts: prop, variant, composition rule có được mô tả máy đọc được không?
  3. Retrieval surface: agent có cách tìm đúng tài liệu, đúng ví dụ, đúng template không?
  4. Execution path: agent có tool chính thức để scaffold, validate, hoặc document không?

Astryx đánh vào cả bốn lớp đó. StyleX và theme cascade xử lý phần styling có quy luật. Primitives được export để compose linh hoạt, không giấu hết bên trong. CLI đưa ra đường gọi thống nhất. MCP server biến design system thành context provider cho agent.

Ví dụ cụ thể: giả sử team bạn có dashboard nội bộ với ba loại màn hình — list, detail, settings. Nếu chỉ đưa repo cho agent, nó có thể copy một pattern cũ, dùng nhầm spacing, hoặc tự bịa prop. Nhưng nếu design system có CLI kiểu create template settings, có metadata cho từng component, có doc gắn ngay cạnh code, agent sẽ ít phải “pha theo cảm giác”. Nó đi theo công thức đã có.

Đây cũng là sợi chỉ nối Astryx với vài release khác gần đây. Mistral OCR 4 không chỉ trả text; nó trả bounding boxes, block type, confidence score. Datalab lift không chỉ đọc PDF; nó decode theo JSON Schema. Liquid AI tách lựa chọn retrieval thành dense bi-encoder và late-interaction. Yandex YaFF không thay Protobuf về mặt ý nghĩa; nó đổi memory layout để đọc nhanh hơn.

Các release này khác nhau, nhưng cùng một hướng: đừng chỉ trả output; hãy trả output có hình dạng, ngữ cảnh, và contract.

Mổ xẻ theo hệ thống: Astryx có gì đáng giữ?

Nếu bạn là tech lead, đừng hỏi “có nên migrate sang Astryx không?” ngay. Câu hỏi tốt hơn là: design system của mình đã đủ rõ để agent làm việc chưa?

Mình sẽ bóc thành ba lớp đáng giữ.

1. Component không chỉ là JSX, mà là hợp đồng

Component library truyền thống thường tối ưu cho developer đọc docs. Agent thì cần thứ chặt hơn: prop hợp lệ, pattern composition, ví dụ đúng version, anti-pattern, và kết quả có thể kiểm tra.

JSDoc annotations trong Astryx là tín hiệu hay vì nó kéo tri thức dùng component về gần code. Với team lớn, docs rời repo rất dễ cũ. Với agent, docs cũ còn nguy hiểm hơn: nó làm sai rất tự tin.

Nếu bạn chưa dùng Astryx, vẫn học được một việc: hãy biến component quan trọng thành hợp đồng rõ ràng.

/**
 * Use for primary page actions only.
 * Do not place more than one primary button in the same form footer.
 */
export function Button(props: ButtonProps) {}

Đoạn này không thần kỳ, nhưng nó tạo “mùi vị chuẩn” cho cả người lẫn máy. Quầy pha có recipe thì barista mới đỡ mỗi người một kiểu.

2. CLI là đường ray automation, không phải đồ trang trí

CLI trong design system nghe nhỏ, nhưng với agent lại lớn. Vì agent cần hành động qua tool. Nếu không có tool chính thức, nó sẽ sửa file trực tiếp, copy-paste pattern, hoặc chạy lệnh linh tinh.

Một CLI tốt nên trả output có cấu trúc, ví dụ JSON, để agent parse được. Đây là điểm rất đáng chú ý trong các hệ thống agent production: text log cho người đọc khác với structured output cho máy xử lý.

Hình dung thế này: bạn yêu cầu agent tạo một settings page. Workflow tốt không phải là agent tự viết tất cả từ đầu, mà là:

  1. gọi CLI để liệt kê template hợp lệ;
  2. chọn template gần nhất;
  3. scaffold file;
  4. chạy typecheck/lint;
  5. ghi lại component nào đã dùng và vì sao.

Cùng là “AI tạo UI”, nhưng một bên là freestyle, một bên là quy trình có điểm kiểm soát.

3. MCP biến docs thành context sống

MCP đã được nói nhiều trên blog, nên mình không giới thiệu lại từ đầu. Với Astryx, điểm đáng chú ý là MCP không đứng riêng như lớp demo agent, mà được gắn vào design system.

Điều này quan trọng vì UI workflow có rất nhiều quyết định nhỏ: dùng Card hay Panel, form layout nào, theme token nào, spacing ra sao. Nếu agent phải tự suy từ codebase, context window — vùng ngữ cảnh model giữ được trong một lượt xử lý — sẽ nhanh đầy và dễ nhiễu.

MCP server có thể đóng vai trò “menu động”: agent hỏi đúng thứ cần, thay vì nuốt cả docs. Đây là cách giảm hallucination — bịa thông tin nhưng nói rất chắc — bằng cấu trúc, không chỉ bằng prompt dài hơn.

Phần dễ bị thổi quá: open-source từ Big Tech không tự động hợp codebase bạn

Astryx có pedigree tốt: lớn lên trong môi trường Meta, dùng React, StyleX, có theme, có templates, có tooling. Nhưng public Beta vẫn là public Beta. Với builder, câu hỏi không phải “nó xịn không?”, mà là “chi phí tích hợp nằm ở đâu?”.

Có bốn điểm cần soi trước khi đem vào production:

| Lớp | Câu hỏi cần hỏi | Rủi ro nếu bỏ qua |
|---|---|---|
| Styling | Team bạn có chấp nhận StyleX không? | Thêm một hệ styling song song |
| Design tokens | Token hiện tại map sang Astryx thế nào? | Theme lệch, migration kéo dài |
| Agent workflow | Agent của bạn gọi CLI/MCP ra sao? | Demo đẹp nhưng không vào CI được |
| Governance | Ai duyệt component, template, rule? | Agent nhân bản pattern sai rất nhanh |

Đặc biệt, nếu team bạn đang có design system ổn, đừng vội thay toàn bộ chỉ vì Astryx có MCP server. Cách hợp lý hơn là mượn framework tư duy: docs gần code, tool có structured output, agent gọi qua interface chính thức, validation chạy trong pipeline.

Một buổi để tự kiểm tra design system của bạn

Không cần migrate gì cả. Trong một buổi, bạn có thể test mức “agent-ready” của hệ thống hiện tại.

Chọn một màn hình vừa đủ thật, ví dụ “user settings” hoặc “billing overview”. Sau đó làm bài kiểm tra này:

Bước 1: Viết một prompt lạnh

Không cho agent đọc Slack, Figma, hay trí nhớ của bạn. Chỉ cho repo và docs chính thức.

Create a settings page using our design system.
Use existing components only.
Explain which components you used and why.
Do not invent props.

Bước 2: Ghi lại lỗi theo lớp

Đừng chỉ chấm “xấu/đẹp”. Gắn lỗi vào nhóm:

Bước 3: Sửa hệ thống, không sửa prompt trước

Nếu agent dùng sai prop, thêm type/docs gần component. Nếu nó không biết template, tạo registry. Nếu nó sửa file bừa, thêm CLI. Nếu nó không validate, thêm lệnh check vào workflow.

Bước 4: Chạy lại với cùng prompt

Nếu kết quả tốt hơn, bạn vừa chứng minh vấn đề nằm ở interface của hệ thống, không chỉ ở model.

Đây là phần nhiều team bỏ lỡ. Họ đổi model như đổi hạt cà phê liên tục, trong khi máy xay, áp suất, và công thức chiết xuất vẫn lộn xộn.

Kết: agent-ready là kỷ luật hệ thống

Astryx đáng chú ý vì nó chỉ ra một hướng thiết kế mới cho frontend tooling: component không còn chỉ phục vụ developer bằng mắt, mà phải phục vụ cả agent bằng contract.

Bạn không nhất thiết phải dùng Astryx. Nhưng nếu đang xây hệ thống AI quanh UI, RAG, document extraction hay internal tooling, hãy giữ câu này: đừng bắt agent đoán những thứ hệ thống có thể nói rõ bằng interface.

Cà phê ngon không đến từ việc hét “pha ngon lên” với bartender; nó đến từ công thức đủ rõ để người mới vào ca vẫn không làm cháy vị.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo