这四个东西，任何一个都能让你在一个下午里跑出一条流式消息列表——所以选型评估最后总是打成平手，决定往往落在口味上。你真正在挑的，是那一层你到了第九个月换不掉的东西：一套线上协议、一个 npm 依赖、一份被拷进你仓库的源码，还是一整台你从没写过其前端的 Python 服务器。在这样一年之后——一个可视化构建器把自己归档了，另一个换了东家——这一层值得占据整个决策。
先看全貌
四个项目，对「我刚刚依赖上了什么」给出了四种不同的答案。
| 项目 | 形态 | 你装进来的是什么 | 它安静下来时你还剩什么 |
|---|---|---|---|
| CopilotKit | React 前端加一个运行时，说的是 AG-UI 协议 | 一批包、一个运行时端点、一套协议 | 协议与你的智能体；要 fork 的是那个运行时 |
| assistant-ui | 跑在你自己传输层之上的无头 React 原语 | 一个 npm 依赖，一批 shadcn/ui 形状的组件 | 你的传输层与样式；要 fork 的是那批原语 |
| AI Elements | 被拷进你仓库、且焊死在 AI SDK 流上的组件 | 你代码树里的源文件，外加 AI SDK | 组件彻底归你；被锁住的是那套流协议 |
| Chainlit | 一台自带前端的 Python 服务器 | 一个你去配置、而不是去组合的应用 | 你的 Python 处理函数；那套 UI 从来就不是你的 |
四种耦合，同一条消息列表
关于聊天界面的争论，通常是在比组件质量：能不能做消息分支、附件、Markdown、工具调用渲染。到了 2026 年，它们全都能做，而彼此的差距无非是一周的工作量。真正持久的差别，在于这个项目占住了哪一层。
CopilotKit 占的是线上协议这一层。它是 MIT 许可，2026 年 5 月拿到 2,700 万美元融资，而它的重心是 AG-UI——一套「智能体对用户」的开放协议，源自它与 LangChain 的合作，CrewAI 随后加入。你为这份重量换来的是双向状态：智能体可以读写应用状态、抛出一个由用户来回答的中断、并流式发出结构化事件而不只是 token。如果你的智能体需要知道用户在你应用里选中了什么，那这就是它的产品价值所在。如果不需要，那你就是为了渲染一条消息列表而跑着一套协议和一个运行时。
assistant-ui 占的是组件这一层，并刻意不去占线上协议。MIT、React、按 shadcn/ui 与 Tailwind 的路子来做，乐于坐在 AI SDK 的 useChat 之上，也乐于坐在你自己的路由处理函数之上。线程持久化、分析之类是可选的托管服务，而不是必需品。它适合这样一种判断：你已经有了一个自己满意的后端，只希望聊天界面是整个技术栈里最不多事的那一部分。
AI Elements 同样占组件这一层，但它把源码交给你。它是 shadcn 那种 registry 形态：跑一条命令，二十多个组件文件就落进你的仓库，而且已经接好了 AI SDK 的流式原语——也就是随 AI SDK 6 到来的 message-parts 模型。这里没有升级路径，因为压根没有依赖可升；这既可能是这张表里最好的性质，也可能是最糟的，全看你对「拥有一份不是自己写的代码」作何感想。
Chainlit 占的是你的处理函数之上的一切。Python、Apache-2.0，也是从一个脚本走到「能发给同事看看」的最短路径：一个加了装饰器的 Python 函数，就换来一套带推理步骤、文件上传与 Markdown 的像样网页界面。那套前端是产品的，不是你的；想偏离它，就意味着离开它。
拷进来 vs 依赖住：差别在第六个月现身
assistant-ui 与 AI Elements 在第一天看起来是同一种选择，往后却表现得像两种相反的选择——因为一个依赖和一份被 vendor 进来的源码，是朝相反方向失败的。
- 依赖会在你之外自己升级。缺陷修复与无障碍改进按别人的节奏到来，代价只是一次版本号提升。你付出的是：你的定制活在包装层、覆盖样式和 API 露出的那些接缝里——而你包过的某个组件出现破坏性变更时，那是一次不由你选择的变更。
- 拷过来的源码永远不会升级。你拷贝那天之后的每一个修复，要么你手工搬过来，要么你就没有。你付出的是无声的分叉：半年之后，你的
Message组件和 registry 里那个已经毫无共同之处，而且没有任何 diff 会告诉你漏掉了什么。 - 判断依据是你的定制深度。如果你只是改改样式就收手，那依赖等于白送的维护。如果你的设计体系反正要把内部实现重写一遍——在多数产品团队里它就是会——那拷过来的源码，替你省掉了一层你原本要去搏斗的间接层。
还有一个值得点名的二阶效应。拷进来的组件是可评审的：它们就在你的仓库里、会出现在代码评审里，而关于它们的供应链疑问，读一遍就能回答。一个渲染模型输出的组件库，本身就是一个渲染面，而「安全地渲染智能体输出」是一类真实存在的缺陷，不是假想出来的。
运行状态住在哪里，以及一次中断要付什么代价
拿同一个尴尬问题去问每一个库——智能体正做到计划的一半，需要用户批准某一步，而用户刷新了页面——架构差异立刻就分开了。CopilotKit 的答案是协议层面的中断加共享状态，这是最强的答案，也正是那个运行时存在的理由。AI Elements 的答案是一次等待输入、由流承载的工具调用，只要你的服务器能续上这条流，它就很干净。assistant-ui 的答案是「你的传输层怎么做就怎么样」，这很诚实：原语会把它渲染出来，可恢复性是你的问题。Chainlit 的答案是一个会话内的「问用户」步骤，在同一个会话里非常好用，进程一换就没了。
这几种做法都不算错。但「明天早上用户还能不能批准这一步」是一个关于你后端的耐久性问题，而四者中只有一个假装替你回答了它。如果审批流很重要，那就先把可恢复运行的设计定下来，让界面层跟着走——审批与确认的 UX 与持久状态与可恢复性才是约束这个选择的两页。
生成式界面把问题挪到了组件目录上
如今这四者都处在一场不是它们发起的协议之争的下游。A2UI——谷歌那套与框架无关的生成式界面规范——在 2026 年 7 月来到 v0.9；MCP Apps 于 2026 年 1 月作为首个官方 MCP 扩展发布，由 OpenAI 共同设计，并吸收了社区的 MCP-UI 工作。AG-UI 待在另一层——智能体后端与应用之间的运行时连接——而这些项目彼此把对方视为互补而非竞争。
由此得出的实际结论，就是我们在那篇讲组件目录的文章里论证过的：无论是哪个库在渲染你的聊天界面，智能体可以组合的那些组件，都是一份由你穷举、拥有并评审的集合。一个让「渲染模型自己写的任意标记」变得很容易的库，并不是在替你省活；它是在把你的设计评审挪到运行时、把你的安全评审挪到服务器边界。评判这四者时，要看它们把「可穷举」那条路做得有多顺手，而不是看自由发挥的 demo 有多惊艳。
耐久性，因为 2026 年一直在考它
Chainlit 的原班团队于 2025 年 5 月 1 日退出了活跃开发；项目由社区维护者接手，签有正式的维护者协议，2.x 版本线仍在稳定发布。这比另一种结局要好，但它依然是一条你该定价的治理事实。Flowise 在 2026 年 8 月把自家仓库归档了，维护者点名编码智能体是原因。Langflow 则在 IBM 于 2025 年 11 月完成对 DataStax 的收购时换了东家。
- 问一句 fork 要多少钱。fork 一个组件库是一个周末。fork 一个说着某套协议的运行时是一个季度。fork 一台你压根没拥有过其前端的应用服务器，那是一次重写。
- 问一句留下来的产物是什么。拷进来的组件本来就是你的。React 原语可以就地替换。协议可以被任何读得懂规范的人重新实现。而一个 Chainlit 应用，是 Python 处理函数加上一套你得从头再造的 UI。
- 问一句还有谁依赖着这一层。一套有多个独立实现的协议，扛得住某一家公司失去兴趣；一个只有一家厂商的组件库扛不住——不管它今天有多好。
什么时候选哪个
| 情形 | 选 | 因为 |
|---|---|---|
| 智能体必须读写你应用内部的状态 | CopilotKit | 共享状态与协议层面的中断本身就是产品，不是外挂 |
| Next.js 应用，技术栈里已经有 AI SDK | AI Elements | 胶水最少，组件还直接落进你设计体系所在的那个仓库 |
| 已有的 React 应用，自带传输层与设计体系 | assistant-ui | 它主张得最少，把你的后端与流式方案原样留着 |
| Python 团队，内部工具或研究 demo | Chainlit | 当团队里没人愿意去养一个前端时，它是通往可用界面的最快路 |
| 面向客户、且设计体系很严的界面 | AI Elements 或 assistant-ui | 这两个都让设计体系说了算；更重的那些会让你去跟它们的那一套谈判 |
常见问题
CopilotKit 是智能体框架还是界面库？
两者都是，这正是它的取舍。它提供 React 界面，也提供一个说 AG-UI 的运行时——AG-UI 是它与 LangChain 一起做出来的「智能体对用户」协议。如果你只需要一个聊天界面，那你引入的是一套用不上的协议与运行时；如果你需要智能体与应用共享状态，那更轻的东西都做不对这件事。
用 AI Elements 会被 Vercel 锁定吗？
不会被平台锁定——组件就是你仓库里的源文件，哪儿都能跑。耦合的是 AI SDK 的流式协议，因为组件本来就是照着消费它来写的。这是一处真实的耦合，但它在传输层而不在托管方，而 AI SDK 在任何 Node 或边缘运行时上都能跑。
2026 年新项目还适合用 Chainlit 起步吗？
做内部工具与 demo，适合：它是 Apache-2.0，自 2025 年 5 月原团队退出后由社区维护，至今仍在发版。若是面向客户的产品、而且你预期会偏离内置 UI，那么离开的代价，是把一套你从未拥有过的前端重写一遍——所以请在第二个冲刺之前就把这件事定下来，而不是之后。
能混着用吗？
常见的组合是行得通的：让 assistant-ui 或 AI Elements 的组件坐在一个 AG-UI 后端前面；或者把 AI Elements 拷进来，再改造进一个同时服务于非智能体界面的设计体系。行不通的，是同时跑两个都自认为拥有线程状态的运行时。
那 A2UI 与 MCP Apps 呢？
它们回答的是另一个问题——智能体如何描述一个界面——而这四者回答的是你的应用如何渲染并驱动一次运行。先按你想要的耦合来挑库，再单独决定：智能体自己写的界面到底要不要进入你的产品，以及从哪一份组件目录里出来。
延伸阅读
本站相关：
- 生成式界面模式——把组件目录当作一份契约。
- 审批与确认的 UX——约束这个选择的中断设计。
- 持久状态与可恢复性——为什么「用户刷新了页面」是一个后端问题。
- 安全地渲染智能体输出——一个组件库的安全那一半。
- 生成式界面有了两套标准——A2UI 与 MCP Apps，以及组件目录归谁。