Meta 近期发布了 Astryx 的开源 Beta 版本。这套设计系统在内部演进了八年，基于 React 19 与 StyleX，提供超过 150 个注重可访问性的 UI 组件、可定制的 CSS 设计令牌，以及面向工程师和 AI Agent 的 CLI、MCP 工具。它值得关注的地方不只是组件数量，而是把“机器能否正确发现、选择和组合组件”也纳入了设计系统的工程边界。
设计系统开始拥有两类使用者
传统 React 组件库主要服务人类开发者：工程师阅读文档、查找组件、复制示例，再根据 TypeScript 类型和运行结果修正代码。这套流程默认使用者能够理解视觉规范，也能在信息不完整时作出判断。
AI Agent 的工作方式不同。它更依赖结构化输入，需要明确知道：
- 当前有哪些组件和设计令牌；
- 每个组件接受什么属性；
- 哪些组合方式符合设计规范；
- 如何生成、检查和修改代码；
- 某个需求应当使用现成组件，还是创建业务封装。
Astryx 同时提供 CLI 与 MCP 工具，意味着设计系统不再只是运行时依赖和文档网站。命令行工具可以参与项目初始化、组件发现或代码工作流，MCP 则可以把设计系统能力暴露给兼容的 AI 工具。具体命令和能力仍应以 Beta 版本的正式文档为准，但这一方向已经很明确：组件的机器可发现性正在成为新的基础设施要求。
React 19、StyleX 与设计令牌如何配合
React 19 提供应用和组件的运行基础，StyleX 负责可组合、可静态处理的样式表达，而 CSS 设计令牌把颜色、间距、字号、圆角等决策变成可替换的变量。三者关注的问题并不相同：
| 层次 | 主要职责 |
|---|---|
| React 组件 | 交互、状态、语义结构和可访问性 |
| StyleX | 样式声明、组合和构建期处理 |
| CSS 设计令牌 | 品牌主题与跨组件视觉约束 |
| CLI / MCP | 工程自动化与 Agent 可发现性 |
设计令牌尤其适合承担品牌差异。团队不必复制一套 Button 再修改颜色，而是保持组件行为一致，只替换受支持的令牌。这样既降低主题分叉的维护成本，也让 AI Agent 更容易遵守约束：它应当选择已有令牌，而不是随手生成新的十六进制颜色。
不过，可定制不等于可以覆盖一切。直接穿透组件内部结构、依赖私有类名或堆叠高优先级 CSS，都会让升级变得脆弱。更稳妥的边界是优先使用公开属性和设计令牌，业务层只在缺少明确能力时增加薄封装。
可以这样建立一个最小验证项目
下面是一个可改造的 React 19 验证项目。由于摘要没有给出 Astryx 的正式 npm 包名和导出接口，示例使用 @astryx/react 作为占位符；运行前必须根据 Astryx 当前文档替换包名、组件名和属性。这段流程的目的，是隔离验证组件导入、令牌覆盖和可访问性检查，而不是假定 Beta API 已经稳定。
npm create vite@latest astryx-evaluation -- --template react
cd astryx-evaluation
npm install
npm install react@19 react-dom@19 @stylexjs/stylex
# 将下面的占位包名替换为 Astryx 文档给出的正式包名
npm install @astryx/react
npm run dev
可以把验证页面改造成一个很小的组件清单：
// src/App.jsx
// 假设性接口：请按 Astryx 正式文档替换导入路径和组件属性。
import { Button, TextField } from "@astryx/react";
import "./tokens.css";
export default function App() {
function handleSubmit(event) {
event.preventDefault();
const data = new FormData(event.currentTarget);
console.log({ email: data.get("email") });
}
return (
<main className="page">
<h1>Account settings</h1>
<form onSubmit={handleSubmit}>
<TextField
name="email"
type="email"
label="Email address"
required
/>
<Button type="submit">Save changes</Button>
</form>
</main>
);
}
令牌文件应只覆盖组件库明确公开的变量。以下变量名同样是用于说明集成方式的占位示例：
/* src/tokens.css */
:root {
/* 替换为 Astryx 实际公开的 CSS token 名称 */
--astryx-color-accent: #0057b8;
--astryx-color-on-accent: #ffffff;
--astryx-radius-control: 6px;
--astryx-space-control-gap: 12px;
}
.page {
max-width: 40rem;
margin: 3rem auto;
padding: 0 1rem;
}
form {
display: grid;
gap: var(--astryx-space-control-gap, 12px);
}
验证时不要只看页面是否“像设计稿”。还应检查键盘焦点顺序、标签与输入框的关联、错误信息能否被辅助技术感知，以及令牌覆盖后各类状态是否仍有足够对比度。组件库提供可访问性基础，并不意味着业务组合天然可访问。
引入 Beta 设计系统时该检查什么
Astryx 目前处于 Beta 阶段，适合先在边界清晰的场景试点，例如内部工具、新功能页面或独立表单。不要一开始就重写整套前端。一个务实的评估清单包括：
- 锁定准确版本，记录升级前后的组件 API 和视觉快照变化；
- 盘点现有组件，确认 Astryx 能替代哪些能力、哪些仍需业务封装；
- 验证 React 19、StyleX 与当前构建工具、SSR 或测试环境的兼容性；
- 只通过公开令牌做主题定制，避免依赖内部 DOM 和类名；
- 使用键盘、屏幕阅读器和自动化工具共同检查可访问性；
- 给 AI Agent 限定可用组件、令牌和目录，并对生成代码执行 lint、类型检查与测试；
- 将 MCP 服务视为开发工具权限边界，审查它能读取的项目内容和能够执行的操作。
Astryx 展示了一种更广的设计系统形态：组件、样式规范、工程工具和 Agent 上下文被放在同一套产品里。对团队而言，真正的收益不在于让 AI 更快地产生 JSX，而在于让人和 Agent 都从同一份受约束、可验证的 UI 能力集合出发。是否采用，则应由兼容性、升级成本、可访问性表现和工具权限模型共同决定。