CopilotKit:AI前端栈

CopilotKit：AI前端栈

AI Agent 不能永远住在聊天框里。真正进入软件之后，它需要看见界面、理解状态、渲染组件，还要在关键步骤把控制权交还给人。

01 聊天框，可能不是 Agent 的最终形态

过去两年，AI 产品有一个很统一的入口：聊天框。

用户输入一句话，模型返回一段文字。

这个形态很自然。

因为大语言模型最早被大众认识，就是从 ChatGPT 开始的。于是大家做 AI 应用时，也很容易顺手套一个 Chat UI：左边历史记录，右边对话窗口，底部一个输入框。

但问题也在这里。

聊天框很好用，但它不是所有软件的终点。

想象一个真实业务场景：

你在 CRM 里让 AI 帮你分析客户。

如果它只是在聊天框里回复：

“这个客户优先级较高，建议下周跟进，并重点介绍 A 产品。”

这当然有用。

但更好的体验应该是：

AI 自动打开客户详情；
高亮关键沟通记录；
生成一份跟进计划；
在表单里预填下一步动作；
提醒你确认后再写入系统；
必要时生成一个可编辑的报价草稿。

这时候，AI 不再只是“回答问题”。

它开始参与界面、状态、流程和操作。

这就是今天 GitHub 趋势榜上 CopilotKit/CopilotKit 值得关注的原因。

项目地址：github.com/CopilotKit/CopilotKit

截至 2026 年 6 月 7 日，CopilotKit 在 GitHub 上约 33.2K stars、4.2K forks，仓库语言为 TypeScript，采用 MIT License。官方定位非常明确：

The Frontend Stack for Agents & Generative UI。

翻译过来就是：

面向 Agent 和生成式 UI 的前端技术栈。

一句话概括：

CopilotKit 想解决的问题，不是“怎么再做一个聊天框”，而是“怎么把 Agent 真正接进应用界面”。

02 Agent 进入软件后，前端会变复杂

很多人以为做 Agent 应用，难点都在后端。

比如：

怎么调用模型；
怎么接工具；
怎么做多步任务；
怎么规划和执行；
怎么接 LangGraph、CrewAI、OpenAI Agent SDK。

这些当然重要。

但当 Agent 真正进入一个产品，前端问题会突然冒出来。

因为用户不是在命令行里使用 Agent，而是在一个具体软件里使用 Agent。

软件里有按钮、表格、表单、卡片、图表、权限、状态、审批、协作、撤销、重试。

这时候，前端至少要回答几个问题：

Agent 运行时，用户界面怎么实时展示？
Agent 调用工具后，结果是文字还是组件？
Agent 能不能读写前端状态？
用户能不能中途插手、确认、修改？
同一个 Agent 能不能跑在 Web、移动端、Slack、Teams 里？
后端 Agent 框架和前端 UI 之间用什么协议通信？

这些不是一个简单聊天框能解决的。

CopilotKit 切入的正是这一层。

它不是替代模型，也不是替代 LangGraph 这类 Agent 编排框架。

它更像是 Agent 应用的“前端连接层”：

后端 Agent 负责思考和执行，CopilotKit 负责把它变成用户能理解、能操作、能参与的界面。

03 CopilotKit 到底提供了什么？

从官方 README 看，CopilotKit 已经从一个 React 库，演进成一个多平台 Agentic Framework。

它支持 React / Next.js、Angular、Vue、React Native，还在扩展 Slack、Microsoft Teams 等办公协作场景。

核心能力主要有六类。

1. Chat UI

这是最基础的能力。

CopilotKit 提供可定制的聊天界面，支持消息流式输出、工具调用、Agent 响应展示。

但这里的 Chat UI 不是最终目标，而是入口。

真正有价值的是：它能和应用状态、工具调用、生成式 UI 连起来。

2. Backend Tool Rendering

这是 CopilotKit 很关键的能力。

传统工具调用里，后端工具返回的通常是一段 JSON 或文字。

但 CopilotKit 希望后端工具可以返回 UI 组件，由前端直接渲染。

比如 Agent 调用“查询订单”工具，返回的不是一段文字：

“订单 A、订单 B、订单 C。”

而是直接渲染一个订单表格，带筛选、按钮、详情入口。

这比纯文本自然得多。

因为业务软件里的信息，本来就不应该全部被压扁成文字。

3. Generative UI

这是 CopilotKit 最有想象力的部分。

Generative UI 指的是：Agent 可以根据用户意图和当前状态，动态生成或更新界面组件。

用户问：

“帮我比较这三个候选供应商。”

传统聊天框会返回一段对比文字。

Generative UI 可以返回一个对比表、风险标签、评分卡，甚至给每个供应商生成可展开的详情模块。

用户说：

“按价格权重 40%、交付权重 30%、售后权重 30% 重新排序。”

界面可以直接更新。

这才更接近“AI 原生软件”。

不是人围着聊天框转，而是 AI 进入已有业务界面，按任务生成合适的交互形态。

4. Shared State

Agent 如果只会输出文字，其实不知道前端正在发生什么。

但真实应用里，状态很重要。

比如当前用户选中了哪一行、筛选条件是什么、表单填了哪些字段、地图定位在哪、图表展示哪个时间范围。

CopilotKit 提供 shared state，让 Agent 和 UI 组件可以实时读写同一份状态。

官方示例里，useAgent hook 可以直接访问 agent，并通过 agent.setState() 更新状态。

这意味着 Agent 不只是“说”，还能和界面状态协同。

5. Human-in-the-Loop

Agent 进入业务系统后，最危险的不是它不够聪明，而是它太主动。

比如自动发邮件、改订单、提交审批、删除数据、生成报价。

这些动作不能让 Agent 一路狂奔。

CopilotKit 支持 Human-in-the-Loop，让 Agent 在关键节点暂停，请用户确认、补充、修改，然后再继续。

这点非常重要。

因为企业级 Agent 的核心不是“全自动”，而是“可控自动化”。

6. Self-Learning Agents

CopilotKit 还在推进 Self-Learning Agents，官方称为 CLHF，也就是 Continuous Learning from Human Feedback。

简单说，就是 Agent 能从用户反馈中持续改进，不一定需要重新微调模型，而是通过上下文强化、提示词增强、交互历史和用户偏好适配来变好。

这部分目前属于 early access，但方向很清楚：

Agent 不能每次都像第一次见你。

它需要记住交互结果、用户偏好和历史上下文。

04 AG-UI：给 Agent 和界面之间铺一条路

如果说 CopilotKit 是前端 SDK，那么它背后更大的东西是 AG-UI Protocol。

AG-UI 的全称是 Agent-User Interaction Protocol。

官方定义是：

一个开放、轻量、基于事件的协议，用来标准化 AI Agent 如何连接用户界面应用。

这句话有点抽象。

可以换个说法：

Agent 后端和前端应用之间，不能永远靠临时 JSON、临时 WebSocket、临时约定。

如果每个 Agent 框架都自己定义一套消息格式，每个前端又自己写一套适配，那生态会非常碎。

AG-UI 想做的，就是把 Agent 与 UI 的交互抽象成一组标准事件。

官方 README 提到，Agent backend 在执行过程中可以发出兼容 AG-UI 的约 16 种标准事件，也可以接受 AG-UI 兼容输入。传输层可以是 SSE、WebSocket、Webhook 等。

重点不在传输方式，而在事件语义。

比如：

Agent 开始执行；
Agent 正在流式输出；
Agent 调用工具；
工具返回结构化结果；
前端状态更新；
Agent 请求用户确认；
用户反馈进入执行链；
生成式 UI 组件被渲染。

有了这样的协议，后端 Agent 框架和前端 UI 之间才有可能解耦。

这有点像 AI Agent 世界的“前端交互协议层”。

05 MCP、A2A、AG-UI：三层协议各管一段

AG-UI README 里有一个很好的定位：它是 Agent 协议栈里缺的第三块。

MCP：给 Agent 提供工具；
A2A：让 Agent 和 Agent 通信；
AG-UI：把 Agent 带进用户界面。

这个划分很清楚。

过去大家讨论 MCP 很多。

MCP 解决的是“Agent 怎么使用外部工具和数据源”。比如文件、数据库、浏览器、搜索、GitHub、CRM。

A2A 解决的是“Agent 之间怎么协作”。比如一个规划 Agent 调度一个研究 Agent、一个编码 Agent、一个测试 Agent。

但还有一个问题：

Agent 最终怎么和人交互？

人不是 API。

人需要看见过程，需要确认风险，需要修改中间结果，需要在界面里操作。

AG-UI 补的就是这一块。

所以 CopilotKit 的价值，不只是一个 React 组件库，而是站在一个更大的趋势上：

Agent 基础设施正在从后端工具调用，延伸到前端交互协议。

06 为什么“生成式 UI”会成为下一阶段重点？

现在很多 AI 产品有个通病：所有内容都往聊天框里塞。

查询订单，返回文字。

分析数据，返回文字。

生成计划，返回文字。

填写表单，还是返回文字。

但软件世界本来不是纯文字的。

表格适合对比。

图表适合趋势。

卡片适合摘要。

表单适合录入。

时间线适合过程。

地图适合位置。

看板适合任务流。

如果 Agent 只能输出文本，就等于把复杂软件降级成了客服对话。

生成式 UI 的方向，是让 AI 根据任务选择合适的表达方式。

比如：

用户要“比较方案”，生成对比表；
用户要“规划旅行”，生成地图 + 日程卡片；
用户要“分析销售数据”，生成图表和异常点；
用户要“处理工单”，生成可确认的操作步骤；
用户要“配置系统”，生成表单并预填参数。

这不是炫技，而是效率问题。

好的 AI 应用不应该让用户阅读一大段文字，再手动复制到系统里。它应该直接出现在任务发生的地方。

CopilotKit 的 Generative UI、Backend Tool Rendering、Shared State，本质上都是围绕这件事展开。

07 一个开发者怎么用它？

CopilotKit 的快速开始非常直接。

新项目可以用：

npx copilotkit@latest create -f <framework>

已有项目可以用：

npx copilotkit@latest init

官方希望做到“Add AI to your app in 1 minute”。

当然，这里的 1 分钟更多是指接入基础脚手架。

真正做好一个 Agent Native 应用，还需要定义业务状态、工具边界、用户确认流程、UI 组件和后端 Agent。

但它至少把前端侧的通用问题封装掉了。

开发者不需要从零写：

聊天流式输出；
Agent 连接管理；
前端状态同步；
工具调用 UI 展示；
人类确认流程；
生成式 UI 渲染；
多框架适配。

这就像早期 Web 开发从手写 DOM，进入 React / Vue 组件化时代。

今天的 Agent 前端，也需要类似的抽象。

否则每家公司都会重复造一套“AI 聊天侧边栏 + 工具调用展示 + 审批确认”的轮子。

08 它适合哪些场景？

CopilotKit 最适合的不是纯聊天机器人，而是“AI 深度嵌入业务界面”的产品。

1. SaaS Copilot

比如 CRM、ERP、项目管理、BI、客服系统。

用户不想跳出当前系统去问 ChatGPT，而是希望 AI 就在产品里帮他看数据、填表、生成建议、执行流程。

2. 数据分析产品

用户用自然语言提问后，AI 不应该只回答“销售额上升了”。

它应该生成图表、筛选条件、异常点卡片，并允许用户继续追问和调整。

3. 内部运营系统

比如审批、采购、工单、风控、售后。

Agent 可以自动整理信息，但关键动作需要 Human-in-the-Loop 确认。

4. 开发者平台

云平台、低代码平台、API 管理平台都适合做 Agent UI。

AI 可以根据用户意图生成配置、解释错误、补全参数、发起部署，但不能绕过权限和确认。

5. 移动端和协作工具

CopilotKit 提到同一个 Agent 可以进入 Web、移动端、Slack、Microsoft Teams。

这点很现实。

用户不一定每天打开你的 Web 后台，但他们可能一直在 Slack 或 Teams 里工作。

Agent 如果能跨界面运行，价值会更大。

09 和普通 AI 组件库有什么区别？

市面上已经有很多 AI UI 组件库。

它们通常提供：聊天气泡、输入框、消息列表、Markdown 渲染、代码块、loading 状态。

这些当然有用。

但 CopilotKit 关注的层级更深。

它不是只做“聊天界面长什么样”，而是做：

Agent 怎么和应用状态共享；
Agent 怎么触发前端工具；
Agent 怎么返回可渲染 UI；
Agent 怎么在执行中请求用户输入；
Agent 怎么跨前端框架运行；
Agent 怎么通过 AG-UI 与不同后端框架对接。

所以它更像 Agent 应用的前端基础设施，而不是一个 UI 皮肤包。

这也是为什么它和 AG-UI 绑定得很深。

一个组件库解决的是“界面好不好看”。

CopilotKit 想解决的是“Agent 和界面怎么协作”。

10 当然，它也有挑战

CopilotKit 的方向很对，但落地并不简单。

第一，生成式 UI 很容易失控。

如果 Agent 随意生成组件，产品一致性、权限、可访问性、性能都会出问题。

真正可用的 Generative UI，往往不是完全开放生成，而是在一组可控组件和 schema 里生成。

第二，Human-in-the-Loop 的设计很考验产品能力。

什么时候自动执行？什么时候必须确认？确认文案怎么写？失败后怎么回滚？这些都不是 SDK 能完全替开发者决定的。

第三，协议生态需要时间。

AG-UI 很有潜力，但协议是否能成为事实标准，要看更多 Agent 框架、云厂商、前端框架是否长期支持。

第四，企业集成复杂度很高。

业务系统里有权限、审计、合规、日志、审批链、数据隔离。CopilotKit 提供的是前端和协议层能力，真正落地还需要企业工程体系配合。

第五，开源项目仍在快速迭代。

CopilotKit 当前 open issues 数量较多，说明社区活跃，也说明项目仍在高速变化。生产环境使用，需要做好版本锁定、测试和回滚策略。

所以它不是“装上立刻变成超级 Agent”的魔法。

它更像一套正在成型的 Agent 前端工程底座。

11 为什么它值得写进今天的趋势榜？

CopilotKit 上榜，不只是因为 star 多。

更重要的是，它代表了 Agent 应用发展的一次重心转移。

早期大家关心模型。

后来大家关心工具调用。

再后来大家关心 Agent 编排。

现在问题开始来到前端：

Agent 怎么真正进入用户每天使用的软件？

如果答案只是“加一个聊天侧边栏”，那很多 AI 应用会变得很鸡肋。

因为用户最终还是要手动把 AI 的回答复制到系统里。

而 CopilotKit 指向的方向是：

AI 可以理解当前界面状态；
AI 可以调用业务工具；
AI 可以生成合适的 UI；
AI 可以和用户协作确认；
AI 可以跨 Web、移动端、Slack、Teams 存在；
AI 后端和前端之间有标准协议。

这才是 Agent Native Application 的样子。

不是把旧软件旁边外挂一个聊天机器人。

而是让软件本身具备 Agent 能力。

12 对国内开发者的启发

CopilotKit 对国内开发者和企业服务商很有启发。

第一，AI 应用不能只卷模型调用。

大模型 API 越来越标准化，真正决定体验的会是产品界面、业务状态和工作流。

第二，前端团队会重新变重要。

过去很多 Agent 项目偏后端，前端只是一个 Demo。

但当 Agent 进入真实产品，前端要处理状态、交互、权限、确认、组件、错误恢复，这些都是硬活。

第三，生成式 UI 要和行业组件结合。

国内很多行业软件都有复杂表单、审批流、数据看板、组织权限。

如果能把 Agent 和这些组件深度结合，而不是只做通用聊天框，商业价值会更高。

第四，协议层值得关注。

MCP 已经证明：一旦协议被接受，生态会快速围绕它长出来。

AG-UI 现在还在早期，但它切的是人机交互层，长期价值不低。

第五，Agent 的落地不是“全自动”，而是“可控协作”。

企业客户真正需要的不是一个不受控的自动驾驶员，而是一个能给建议、能预填、能执行、能暂停确认、能留下审计记录的智能助手。

CopilotKit 的 Human-in-the-Loop 正是这个方向。

写在最后

AI Agent 的第一阶段，是会聊天。

第二阶段，是会用工具。

第三阶段，是会进入软件界面，和人一起完成任务。

CopilotKit 关注的正是第三阶段。

它把问题从“模型怎么回答”推进到“Agent 怎么出现在用户界面里”。

这件事听起来没有新模型发布那么热闹，但对 AI 应用落地非常关键。

因为用户真正需要的，不是另一个聊天窗口。

用户需要的是：

在 CRM 里直接生成跟进计划；

在 BI 里直接生成图表和解释；

在审批系统里直接预填材料并等待确认；

在项目管理工具里直接拆解任务；

在 Slack 或 Teams 里直接完成跨系统操作。

一句话：

未来的软件，不会只是“带一个 AI 聊天框”，而会逐渐变成 Agent 可以参与操作的动态界面。

CopilotKit 和 AG-UI 做的，就是给这个未来搭前端底座。

如果说 MCP 让 Agent 接上了工具，那么 AG-UI 和 CopilotKit 想做的，是让 Agent 真正走到用户面前。