3.74 万星的 CopilotKit：它不卷 Agent 后端，只想解决「最后一公里」的界面协议

拾光·开源拾遗 技术创作者 2026-09-24 14 阅读

大多数 Agent 框架都在卷后端：怎么编排、怎么调工具、怎么把任务拆成步骤。可真正落到用户面前时，尴尬的问题出现了——Agent 在后台跑了 20 秒，前端只有一个转圈的”Thinking…”，用户不知道它在干什么，也不知道该不该等。CopilotKit 就是冲着这”最后一公里”来的。

它在 GitHub 上已经拿到约 3.74 万颗星（截至 2026 年 9 月 19 日，最新版本 v1.73.0），MIT 许可证，TypeScript 为主，仓库地址是 https://github.com/CopilotKit/CopilotKit 。一句话概括它的定位：它不是 Agent 的大脑，而是 Agent 和用户之间的那层界面协议。

它真正解决问题的那个点

传统做法里，后端 Agent 有推理能力，前端却只能被动渲染文本流。当 Agent 想”改一张表””确认一笔订单””画一张图”时，开发者往往得硬编码一堆 if-else 去解析特定格式的 JSON，前后端耦合一塌糊涂，而且这套 schema 换个项目就废了。

CopilotKit 的解法是它自己主导的 AG-UI 协议——一个基于事件的开放协议，规定 Agent 如何与前端通信。说白了，它把 Agent 输出从”纯文本”标准化成”UI 操作指令”。目前 AG-UI 已被 Google、LangChain、AWS、Microsoft、Mastra、PydanticAI 等采纳，这也是它能拿到 2026 年 5 月 2700 万美元 A 轮的原因之一。

协议本身很轻量：定义了大约 16 种事件类型（RUN_STARTED / TEXT_MESSAGE_CONTENT / TOOL_CALL_ARGS_DELTA / STATE_DELTA 等），传输层可以是 SSE、WebSocket 或 HTTP streaming，协议不强制你选哪一种。状态同步用 JSON Patch（RFC 6902）做增量 diff，而不是每次全量推状态——代价是你得先把 Agent 的 state 显式建模，这部分是实打实的工作量。

四个能落地的能力

  • 生成式 UI（Generative UI）：Agent 可以运行时决定渲染哪个组件。分三种模式——静态（AG-UI 协议，开发者预置组件、Agent 决定何时显示）、声明式（A2UI，Agent 返回 JSON 描述、前端负责渲染）、开放式（MCP Apps，Agent 返回完整 HTML/iframe，灵活但安全和一致性难管）。
  • 共享状态（Shared State）：useAgent 钩子（老 useCoAgent 的超集）让 UI 和 Agent 读写同一份状态。文档编辑、数据看板这类”人和 Agent 协作同一份数据”的场景，这是刚需。
  • 人在环中（Human-in-the-Loop）：Agent 可以暂停，等用户审批/澄清/修改后再继续。发邮件、改数据库、下单这类有真实后果的操作，这是生产环境的前提，而且它是内置在协议层的，不是应用层补丁。
  • 多端复用：一套 Agent 逻辑同时供 React / Angular / Vue / React Native，以及 Slack、Microsoft Teams 使用。

边界、门槛和它不适合谁

先把边界划清楚：CopilotKit 不是通用 LLM 封装库，也不是 RAG 框架。它的价值集中在 Agent↔前端这一层。如果你的需求只是一个渲染 Markdown 的问答机器人，引入它反而增加架构复杂度。

真实门槛有三条：

  1. 技术栈绑定明显。 React/Next.js 是一等公民（GA），Angular/Vue/RN 是”支持”，用 Svelte 或非组件前端栈的团队目前只能等社区移植，或者直接自己接 AG-UI。
  2. 生成式 UI 的质量高度依赖底层模型和 Agent 本身。 复杂的有状态 UI 需要认真设计组件，否则容易出现状态滞留（stale state）。协议帮你省的是”管道工程”，不是”业务设计”。
  3. 核心 MIT 免费且可自托管，但生产级能力在往付费走。 官方有个 CopilotKit Intelligence（托管或自托管）提供持久化 Rich Threads、用户记忆、自动学习，定价从开发者免费档到企业自定义档都有。

适合谁：正在用 React/Next.js/Angular 做 Agent 应用、需要动态 UI 渲染或人机协同的全栈团队；用 LangGraph 等编排框架、却被前端状态同步折磨的工程师；想一套 Agent 逻辑同时铺到 Web、移动端和 Slack/Teams 的团队。

不适合谁：只做静态 Markdown 聊天的开发者；对包体积敏感、交互简单的轻量应用；以及不接受 AG-UI 协议约束、坚持完全自定义 WebSocket 协议的团队。

上手路径

官方现在主推让编码 Agent 帮你接入：在项目根目录跑 npx --yes copilotkit@latest onboard start，它会检查你的项目并引导集成。从零起项目用 npx copilotkit@latest create，给已有项目加则是 npx copilotkit@latest init。

一个最小可跑的 Next.js 接入大概是这样：

pnpm add @copilotkit/react-core @copilotkit/react-ui @copilotkit/runtime
// app/api/copilotkit/route.ts
import { CopilotRuntime, OpenAIAdapter, copilotRuntimeNextJSAppRouterEndpoint } from '@copilotkit/runtime';
import { NextRequest } from 'next/server';

const runtime = new CopilotRuntime();
const adapter = new OpenAIAdapter({ apiKey: process.env.OPENAI_API_KEY! });

export const POST = async (req: NextRequest) => {
  const { handleRequest } = copilotRuntimeNextJSAppRouterEndpoint({
    runtime, serviceAdapter: adapter, endpoint: '/api/copilotkit',
  });
  return handleRequest(req);
};

然后在外层包 <CopilotKit runtimeUrl="/api/copilotkit">，放一个 <CopilotSidebar />，再用 useFrontendTool 注册一个前端工具。有开发者实测：从空白 Next.js 15 App Router 项目到 sidebar 能调用一个工具，约 15 分钟，中途唯一踩的坑是一个模型名写错，报错信息可读，改一行即可。把 OpenAIAdapter 换成 Anthropic 或自托管模型适配器，是五行改动、其它代码不动——这正是 runtime 抽象层的意义。

下一步建议

如果你在评估，我建议按这个顺序做：

  1. 先读 AG-UI 协议仓库（https://github.com/ag-ui-protocol/ag-ui ）弄清事件模型，判断它是否契合你的前端契约；
  2. 用 npx copilotkit@latest init 在你现有的一个内部项目里，只接入 useCopilotReadable（把应用状态暴露给模型）+ 一个 useFrontendTool，跑通”Agent 读你的状态并触发一个 UI 动作”这条最小闭环；
  3. 如果闭环顺畅，再上生成式 UI 和人在环中；如果不顺畅，至少你只花了一个下午。

参考链接：

评论区

0 条评论

登录后可评论。

拾光·开源拾遗 14 阅读