assistant-ui 评测：把 ChatGPT 的界面拆成 React 积木，但你要自己拼
项目速览：用于 AI 聊天的 Typescript/React 库。您将获得什么 可组合原语：从 Thread、Message、Composer、ThreadList、ActionBar 等构建任何聊天 UX。
秒懂
- 它是什么？
- assistant-ui 是一套 TypeScript/React 组件库，用 Thread、Message、Composer 等原语搭建 AI 聊天界面。它不给你一个现成的黑盒，而是给你积木和一套默认主题，代价是你得理解它的运行时抽象。
- 适合谁用？
- assistant-ui 适合那些已经确定用 React 构建聊天界面、并且愿意接受组件库抽象的开发团队。如果你需要快速上线一个标准聊天窗口，CLI 的 init 命令和默认 shadcn/ui 主题能省不少事。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的不是「聊天」问题，而是「聊天界面重复开发」问题
每个 AI 应用都要一个聊天窗口，但每个聊天窗口的细节都差不多：消息列表、输入框、流式输出、重试按钮、附件上传。assistant-ui 把这些东西拆成 Thread、Message、Composer、ThreadList、ActionBar 等原语，让你不用每次从头写。它的目标用户很明确：React 开发者，尤其是用 Next.js 的人，因为 CLI 默认脚手架就是 Next.js。它不是聊天框架，不负责模型调用，也不管消息存哪里。它只管 UI 层，后端通过 runtime 接口接进来。这一点从 README 的示例就能看出来，核心代码只有三行：一个 Provider、一个 runtime hook、一个 Thread 组件。
运行时抽象：UI 与后端之间的薄层
assistant-ui 的核心机制是 runtime。useChatRuntime 这个 hook 默认连接 Vercel AI SDK，但你可以换成 useLangGraphRuntime、useDataStreamRuntime，或者写一个自定义 runtime。这个设计的含义是，UI 组件不直接知道消息从哪来，它只跟 runtime 定义的接口打交道。好处是后端可以换，坏处是你得理解 runtime 的约定。README 里没有给出自定义 runtime 的代码，但提到「easy extension to any custom HTTP backend」，这意味着你需要阅读文档去实现那个接口。对于只用 OpenAI 官方 API 的团队，直接用 AI SDK 的 runtime 就够了，不需要碰底层。
安装与初始化：CLI 是主入口，但直接装包也可以
官方推荐两条路。新项目用 npx assistant-ui@latest create，已有项目用 npx assistant-ui@latest init。这两个命令会生成 styled components，也就是把 shadcn/ui 风格的主题代码复制进你的项目。你也可以手动装包：npm install @assistant-ui/react @assistant-ui/ai-sdk。注意，这两个包是分开的，前者是核心 UI，后者是 AI SDK 适配器。如果你用 LangGraph，就要装 @assistant-ui/react-langgraph。CLI 的好处是它帮你把主题文件放进项目里，你之后可以直接改那些文件，而不是改 node_modules 里的库。
Generative UI：把工具调用变成 React 组件，但安全边界要自己划
README 提到 Generative UI 可以渲染工具调用和 JSON 为 React 组件，还能收集人工批准，以及「expose safe frontend actions to the model」。这句话值得拆开看。渲染工具调用意味着模型返回的 function call 会被映射成组件，这比纯文本输出强得多。但「safe frontend actions」这个说法暗示了风险：模型输出不能直接当作代码执行，你需要定义哪些 action 是安全的。README 没有给出具体的安全机制，只说了「safe」，这意味着安全策略是你自己实现的。如果你让模型决定渲染哪个组件，等于给了模型一个函数调用入口，这个入口的权限控制必须由你来做。
定制路径：Base UI 和 Radix UI 两种风格，但都是「自带样式」
assistant-ui 不提供一个 monolithic 组件，而是让你组合原语并自带样式。CLI 会生成一个起始主题，默认用 Base UI，也可以选 Radix UI。这个选择影响的是底层无障碍组件库，不是视觉效果。README 里说「style every pixel yourself」，这是它的卖点，也是它的门槛。如果你不想自己写样式，默认主题已经够用，但如果你想做 Perplexity 那种界面，你得自己调 CSS。这里有一个明显的 trade-off：组件库给了你结构，但视觉层完全裸露。对于设计团队来说这是好事，对于只想尽快上线的团队来说，这可能是额外的工作量。
后端矩阵：适配器多，但每个适配器都有各自的维护节奏
README 列了 Vercel AI SDK、LangGraph、AG-UI、A2A、Google ADK、OpenCode 等适配器。每个都有独立的包，比如 @assistant-ui/react-langgraph 和 @assistant-ui/react-ag-ui。这意味着如果你用某个小众协议，你得依赖那个适配器的维护活跃度。最近 releases 里有 safe-content-frame 和 heat-graph 这些独立包，说明项目在拆分发版，但这也意味着版本对齐可能是个问题。另一个选择是 assistant-cloud，它提供托管线程历史和遥测，但那是商业服务，不是开源的。如果你不想绑定某个云服务，就得自己实现线程持久化，README 没有提供开源的存储方案。
局限与替代方案：不是聊天框架，也不是端到端方案
assistant-ui 的局限在于它只管 UI。它不处理消息存储、用户鉴权、模型调用的计费，也不提供后端逻辑。如果你的应用需要复杂的对话状态管理，比如多轮工具调用链，你可能需要 LangGraph 这类框架，而 assistant-ui 只是它的前端壳。替代方案有两个方向。一是直接用 Vercel AI SDK 的 useChat hook，它自带简单的 UI 状态，但不提供 ThreadList、ActionBar 这些组件，你需要自己拼。二是用完整的聊天 UI 库，比如 ChatUI 或自研组件，但那些通常绑定特定的样式或后端。assistant-ui 的差异在于它把 UI 原语和 runtime 分离，这是它区别于「一个聊天组件」的地方。如果你的需求只是嵌入一个简单的对话框，assistant-ui 可能过重，useChat 加几个 div 就够了。
维护成本与许可证：MIT 是宽松的，但版本碎片化要注意
项目是 MIT 许可证，这意味着你可以自由使用和修改，甚至商用。但要注意，assistant-cloud 是可选商业服务，README 明确说「optional Assistant Cloud for managed thread persistence」，所以如果你用那个服务，就涉及商业条款。维护成本方面，因为组件库拆成多个包，升级时需要同时更新 @assistant-ui/react 和对应的适配器包，比如 ai-sdk 或 langgraph，版本不匹配可能导致类型错误。另外，CLI 生成的代码是复制进你项目的，这意味着你升级库时，生成的主题文件不会自动更新，你得手动合并。这不算致命，但确实是长期维护时要考虑的点。
编辑结论
assistant-ui 适合那些已经确定用 React 构建聊天界面、并且愿意接受组件库抽象的开发团队。如果你需要快速上线一个标准聊天窗口，CLI 的 init 命令和默认 shadcn/ui 主题能省不少事。如果你追求完全控制渲染细节，或者你的后端协议不在官方适配器列表里，你应该先确认 runtime 层能否对接，再决定是否引入。不要被「生产级」这个词迷惑，流式、重试、附件这些能力是组件库给的，但底层的消息存储、鉴权和错误处理仍然是你自己的责任。建议先跑 npx assistant-ui@latest init，在一个已有项目里生成默认组件，检查生成的代码是否符合你的样式体系，再决定是否深入。
社区笔记