Meta 上周开源了 Astryx，一个基于 React 19 和 StyleX 的设计系统，150 多个无障碍组件，内部打磨了 8 年。比较特别的是，它专门给 AI Agent 提供了 CLI 和 MCP 工具链，让 Agent 也能直接调用组件。

这条新闻让我想起几年前我们团队做组件库的经历。设计系统这个概念，听起来很美，做起来很美，用起来往往没那么美。

组件复用的幻觉

每个前端团队都经历过这个阶段：我们发现不同产品线的代码里，按钮长得不一样，表单校验逻辑不一样，弹窗交互不一样。然后自然而然地想，为什么不搞一套统一的组件库？

我们当年也是这么想的。五个业务线，前端代码里 40% 以上的组件和状态管理是重复的，团队总共 12 个人。重复意味着浪费，统一意味着效率。逻辑上完全成立。

于是我们花了三个月，基于 Ant Design 做了一层封装，搞出了一套"统一组件库"。头三个月用着确实不错，组件越攒越多，大家也都在用。然后问题来了：某个业务线需要一个日期选择器，但这个日期选择器需要支持金融产品的特殊规则——节假日禁用、交易日展示、额度相关样式。我们的通用组件加配置项加不动了，加到最后发现配置项的代码比组件本身还长。

前后花了两天讨论方案，最后发现"通用组件 + 配置"这条路走不通，只能让那个团队单独写一个业务专属组件。组件库的第一个裂痕就这么出现了。

维护成本的反直觉增长

大部分人对组件库的预期是：前期投入大，后期维护成本低。实际情况正好相反。

我后来看到一个数据，来自 InfoQ 的一份前端工程化报告：超过 40% 的企业内部组件库，在使用两年后活跃度下降超过 60%。不是因为技术过时了，而是因为维护方和使用方之间永远在打架。维护方想保持组件的通用性和稳定性，使用方想要快速响应业务需求。当组件库变大以后，这两件事变得越来越矛盾。

我们当时也有类似的问题。每次底层组件升一个大版本，下游五个业务线都要做兼容性测试。有一次升级一个表单组件，改了一个事件回调的参数顺序，结果三个业务线的表单提交都出了问题。排查花了一整天，因为问题不是报错，而是"提交后数据少了一个字段"——那种最让人头疼的静默失败。

当 Agent 也开始用你的组件

Astryx 真正让我觉得有意思的地方，不是它的 150 个组件，而是它给 AI Agent 提供了专门的工具链。这意味着组件的消费者从人变成了机器，或者至少是人和机器并存。

这对技术管理者来说，是一个全新的问题空间。

以前设计组件 API，考虑的是开发者用起来顺不顺手。文档写得清楚不清楚，示例代码全不全，TypeScript 类型定义好不好。现在还要考虑另一层：Agent 能不能理解和调用这些组件。文档不光要给人看，还得能被 Agent 解析。API 设计不光要 human-friendly，还得 machine-friendly。而这两者，很多时候不是一回事。

举个我遇到过的事。之前有个团队做了一个 Select 组件，接口设计得很灵活，支持 render props、自定义 option 模板、异步数据源。人用起来觉得挺方便，配置项丰富。后来一个同事用 AI 辅助写代码，发现 Agent 经常把这个 Select 用错——不是选错了值，而是传了一堆不支持的参数组合，渲染出一堆奇怪的东西。

我们花了一个下午才定位到原因：那个组件的文档里，"互斥参数"的关系是用一段自然语言描述的，Agent 没法准确解析。后来把互斥关系改成了 JSON Schema 的 oneOf 约束，Agent 的调用成功率从 60% 左右提到了 95% 以上。

这个经历让我意识到一件事：组件库的"好用"，在 Agent 时代有了一个新的定义维度。

组件库的真正门槛不在于大

很多团队把组件库的价值等同于组件数量。"我们有 200 个组件"听起来很厉害，但我见过一个团队维护了 300 多个组件，其中超过一半在过去半年里一次都没被调用过。维护这些"僵尸组件"的成本不低，每次升级依赖、修安全漏洞，都得全量检查。为什么没人删？因为删了怕影响某个不知道的内部工具。不删是安全选择，删了要承担责任。结果就是越积越多。

我现在的判断是，组件库的价值不在于有多少个组件，而在于能不能定义清楚"哪些组件不该进库"。

如果一个组件只有两个团队在用，它放在公共组件库里的维护成本，可能比两个团队各自维护一个版本还高。因为公共组件的每一次变更都需要协调两方，协调成本往往大于代码维护成本。这个道理不新鲜，但真正在做取舍的团队不多。

开源设计系统的适配成本

回到 Astryx。作为一个外部开源设计系统，它解决了一部分问题——有人替你维护组件、修 bug、做无障碍适配。但它也引入了新的成本。

我在评估这类系统时，通常会看三个点：

技术栈匹配度。Astryx 基于 React 19 和 StyleX。如果你的团队还在 React 18 上，或者用的是 CSS Modules 而不是 StyleX，引入它的前提是先完成技术栈升级。升级本身的成本，加上升级带来的兼容风险，都得算进去。我们去年从 React 17 升到 18，光回归测试就花了三周。如果当时还要同时切换 CSS 方案，那个成本我不敢想。

维护边界。开源不等于免费维护。版本升级、安全补丁、兼容性测试，这些还是得自己做。如果团队没有专人跟进上游更新，用开源和自己写区别不大。

定制化天花板。金融业务有大量特殊需求：合规展示、风险提示、数据精度。这些在通用设计系统里很难覆盖。如果定制化比例超过 30%，用成熟组件库（比如直接用 Ant Design）加上业务层面的定制，效率可能更高。

我们之前做过一个粗略的对比：同样实现一套金融产品页面，基于一个开源设计系统做二次开发，比直接在 Ant Design 上定制慢了大约 20%。主要原因是理解源码的学习成本和处理上游更新的合并冲突。

Agent 消费者改变了什么

不过 Astryx 确实打开了一个新思路：设计系统不光服务于人，还服务于 Agent。如果你的团队还没决定要不要引入一套设计系统，或者现有的设计系统维护得不太好，这反而是一个重新评估的契机。

Agent 不会抱怨你的组件文档写得差，但文档不好，Agent 生成的代码质量会下降。Agent 不会催你升级 API，但 API 一变，依赖它的 Agent 流程全挂，得人工介入。

从管理角度讲，组件 API 的稳定性、文档质量、版本兼容性，以前可能只是团队内部的技术品味问题。现在它直接影响到了 Agent 的工作可靠性。要求变高了，而且这个要求不是你自己定的，是 Agent 的能力边界替你定的。

这不是说现在就该去引入一套新的设计系统。但如果现有的在维护，可以考虑先把组件文档做好结构化，让 API 契约更清晰。这件事既服务于人也服务于 Agent，不亏。

写这篇的时候我翻了一下去年底的团队内部文档，里面赫然写着"组件库是前端工程化的基础设施，必须持续投入"。现在看这句话，我可能会加个注释：投入的方式不一定是做大而全的组件库，也可能是把已有的 30 个核心组件打磨到 Agent 也能用好的程度。哪个更值，取决于你的团队现在在什么阶段。不过具体怎么判断，我也还在想。