CopilotKit 四大开源 Agent 项目全解析:复刻大厂热门玩法
CopilotKit 四大开源 Agent 项目全解析:复刻大厂热门玩法
把大厂产品做成开源模板容易,难的是让这些模板在你自己的机房里真的跑起来。
CopilotKit 主仓 38,266 颗星(2026-10-27 数据),做的是前端 Agent 栈和生成式 UI,同时是 AG-UI 协议的作者。它最近连着放了四个仓库出来,每一个都对着市面上一款热门的商业 Agent 产品:OpenBot 对标 Grok Bot,OpenDots 对标 OpenAI Dots,OpenMuse 对标 Meta Muse,OpenDuet 对标 Claude Duet。四个都是 MIT,加起来 1.9 万星。
很多人看到这个组合的第一反应是"大厂玩法被开源复刻了"。我读完了四个仓库的全部 README(合计 95,870 个字符)、拉了 GitHub API 的仓库元数据之后,觉得这个读法漏掉了最要紧的一层:这不是四个并列的项目,而是一套逐层叠起来的三层堆栈。 OpenDots 的电脑能力直接调 OpenBot 的容器监管服务;OpenDuet 的 README 里写得更直白——"OpenDuet runs today as OpenBot, with OpenDuet's name, Bots and skills on top"。四个仓库里真正独立实现的只有 OpenMuse 一条线。
这个区别不是文字游戏。它决定了你要复刻的时候,工作量该按"四个产品"算,还是按"一个平台加三个界面"算——这两者差了一个数量级的运维成本。
本文提纲
- 先看数字:四个项目并不在同一个量级上
- 依赖图:两个半项目,一条主干
- 开源是入口,协议才是中路
- OpenBot:治理骑在协议上,而不是焊在框架里
- OpenMuse:长任务真正难的是状态,不是智能
- OpenDots:Dot 管角色,Space 管文档
- OpenDuet:主动式的代价,是学会什么时候闭嘴
- 和自建、和终端 agent 比,它省掉了哪四块
- 复刻它们要付的真实成本:五个坑
- 什么该抄,什么别抄
先看数字:四个项目并不在同一个量级上
GitHub API 拉下来的原始数据,按 Star 排序:
| 项目 | 对标产品 | Star | Fork | 创建日期 | 日均新增 | 开放 Issue |
|---|---|---|---|---|---|---|
| OpenBot | Grok Bot | 7,262 | 985 | 2026-08-17 | 103.7 | 45 |
| OpenDots | OpenAI Dots | 6,062 | 883 | 2026-09-29 | 224.5 | 78 |
| OpenMuse | Meta Muse | 5,694 | 830 | 2026-09-15 | 138.9 | 49 |
| OpenDuet | Claude Duet | 4 | 0 | 2026-10-21 | 0.8 | 2 |
(主仓 CopilotKit 作对照:38,266 星、4,777 fork、2023-06-19 创建,日均 31.2。)
这张表里有三件事,比 Star 总数有意思得多。
第一,Fork/Star 比异常统一。 四个新项目分别是 13.6%、14.6%、14.6%,主仓是 12.5%。主仓那个 12.5% 是三年积累下来的,而这几个才发布一两个月的项目,几乎一上来就复刻了这个比例。翻译成人话:来的人不是"收藏一下",是"先 clone 一份再说"。四份 README 里反复出现的 "A template, not a product"、"Clone this template and customize it however you want" 不是客套话,它就是这个项目的真实用法——这四件东西不是用来 install 的,是用来 fork 的。
第二,增速和资历反着走。 OpenDots 发布 27 天拿到 6,062 星,日均 224.5,是四个里最快的;OpenBot 发布 70 天才 7,262 星,日均 103.7。仓库 metadata 里能看到的官方背书也对得上:OpenBot 挂了 Trendshift "Repository Of The Day #3",OpenDots 挂的是 "TypeScript Repository Of The Day #2"。
第三,OpenDuet 那个 4 需要单独解释。 它 2026-10-21 才建仓,5 天,4 星,2 个 open issue。这不是质量差,是还没被社区发现。任何"四项目对比"的文章如果把 OpenDuet 和 7,000 星的 OpenBot 摆在同一行直接比功能,读完的结论一定是错的——一个是跑了两个半月的基建,一个是五天大的皮。 下面第七节会讲清楚它到底薄在哪。
还有一个不看 Star 就看不到的差别:四份 README 对"到底能跑到什么程度"的诚实度不一样。 OpenMuse 带 docs/VERIFICATION.md 和 ROADMAP.md,把"已验证"和"需要你额外配置"分开写,还专门标出开放推理、实时 Google 账号、Rich Threads 三项要各自配;OpenDots 在 Features 一节开头就区分"本地验证过的"和"接过服务才验证的",并提醒测试夹具必须和真实集成在界面上分开;OpenBot 与 OpenDuet 没有这类文档,靠徽章和状态行说明。做选型评估的话,优先读有 verification 文档的那个——不是因为它的代码更好,是因为它把不确定性写给了你看。
依赖图:两个半项目,一条主干
四个仓库的 README 交叉引用之后,代码关系长这样:
graph TD
INT["CopilotKit Intelligence
threads + memory"] -.-> APP["App surfaces
channels, /admin, Space"]
APP --> GW["Tool Gateway
resolve, decide, record"]
AG["Any AG-UI agent
LangGraph / Mastra / CrewAI"] --> GW
GW --> POL["Policy engine
browser, file, MCP"]
GW --> AUD["Audit log"]
GW --> CMP["Per-Bot computer
Chromium profile + workspace"]
DOTS["OpenDots
Dots + Spaces"] --> CMP
DUET["OpenDuet
proactive layer"] --> APP
MUSE["OpenMuse
React Native app"] --> CMP
classDef base fill:#FF6B6B,stroke:#764ba2,stroke-width:2px
classDef mid fill:#4ECDC4,stroke:#764ba2,stroke-width:2px
classDef top fill:#FFEAA7,stroke:#764ba2,stroke-width:2px
classDef ext fill:#98D8C8,stroke:#764ba2,stroke-width:2px
class GW,POL,AUD,CMP base
class APP,AG mid
class DOTS,DUET,MUSE top
class INT ext- OpenBot 是底座:容器监管、浏览器配置、工作目录、工具网关、权限策略、审计、Postgres、渠道(Slack / Teams / 短信)。
- OpenDots 是文档型界面:Dot 管角色,Space 管文档,电脑能力"using OpenBot's container supervisor and computer service"。
- OpenDuet 是主动式界面:README 原话是它"runs today as OpenBot ... with OpenDuet's name, Bots and skills on top",而且"Everything that makes it OpenDuet lives in one folder"——一个目录那么厚的一层皮。
- OpenMuse 是唯一独立的一条线:自带 server、task worker、browser worker,用 CopilotKit React Native 做 iOS / Android / Web 三端,不经过 OpenBot。
这里还有个细节值得记一笔。OpenDuet 的 About 段落写的是:"It is CopilotKit's open-source take on the proactive-agent category: assistants that reach out first, such as Claude Duet. OpenDuet is an independent project and is not affiliated with or endorsed by Anthropic." 四个仓库里只有它写了这句免责声明,说明这个名字起得确实擦边,法务看过了。
开源是入口,协议才是中路
在拆代码之前,先把商业模型看清楚,否则很容易把"复刻大厂"当成全部叙事。
四份 README 里,指向 "Talk to an engineer" 的链接分别是 4、2、1、1 处(OpenBot、OpenDuet、OpenMuse、OpenDots),几乎每一条都带着 ref=openbot_readme 这种来源参数。OpenBot 里那段话写得毫不含糊:
We can build this for you, or with you, at your company. Our engineers will stand OpenBot up inside your infrastructure, customize it into something that looks like your own product, and hand it back to you to keep changing.
这就是 FDE(Forward Deployed Engineer,前置交付工程师)模式的原文表达:工程师进场、在你的基础设施里搭起来、改成看起来像你自己产品的样子、再交回给你继续改。开源仓库在这里的作用是降低销售摩擦,不是替代交付。 你 clone 下来会得到一个能跑的东西,但 README 里的 examples/ tenant 是演示租户,不是你的生产系统;把它变成你的系统的那部分工作量,官方的默认预期是你来买。
再看那一层。CopilotKit 给自己的定义是 "The Frontend Stack for Agents & Generative UI",副标题跟着一句 "Makers of the AG-UI Protocol"。AG-UI 是它主导的协议仓库,16,841 星、1,535 fork、2025-05-07 建仓,一句话概括是 "the Agent-User Interaction Protocol. Bring Agents into Frontend Applications."
把 MCP 和 AG-UI 摆在一起看,分工很清楚:MCP 管 agent 到工具,AG-UI 管 agent 到人。 前者解决"agent 能碰什么",后者解决"agent 怎么把过程、审批、结果呈现给人,人怎么中途插手"。而人的那一侧,恰恰是所有 Agent 产品最难标准化、也最容易做烂的部分。
所以四个仓库更准确的定位是四个样板间:OpenBot 证明治理可以骑在协议上而不焊在框架里;OpenDots 和 OpenDuet 证明同一套底座能长出两种完全不同的界面(文档型 / 主动型);OpenMuse 证明移动端也能吃同一条事件流。样板间比文档有说服力——一个打算接 AG-UI 的团队,看完这四个仓库就知道自己那套 UI 该产出什么样的事件。
这个判断对读者是有用的:如果你只是想要一个能用的助手,这四件东西对你来说是半成品;如果你在自建 agent 产品,AG-UI 这一层是你最该先去读的,收益比抄界面大得多。 界面抄完会过时,事件契约抄对了能用三年。
OpenBot:治理骑在协议上,而不是焊在框架里
OpenBot 的定位是"你公司真的能自己拥有的那个 AI 助手",官方的对照物是 ChatGPT / Claude / Grok,区别只有一句:它跑在你的基础设施上,任何一处你都能改。
技术上它最有价值的决定,是把协议和框架拆开了。README 里那句话值得抄在架构文档里:
A Bot is any endpoint speaking AG-UI ... Agents built with LangGraph, Mastra, CrewAI, Pydantic AI, Google ADK or written by hand all arrive the same way, and the governance rides the protocol rather than the framework.
翻过来就是:你用什么框架写 agent 不重要,因为每一次工具调用都要回到网关,由网关负责三件事——解析目标、按策略裁决、记录下来。这带来的直接好处是换框架不用换治理。企业里最怕的那种项目("我们去年用 CrewAI,今年想换 LangGraph,权限和审计得全部重做")在这个结构下不存在。
配套的几个具体设计:
- 一个 Bot 一台电脑:独立容器、独立浏览器配置、独立工作目录、独立登录态。不是共享一个 headless 浏览器再靠参数隔离。
- 策略可配、默认拒绝:
/admin/boundaries配 browser / file / MCP 三类动作策略,拒绝规则优先,异常默认拒绝。填一次表单的完整过程可以在/admin/audit里逐条回看。 - 渠道延伸到工作软件:
/bots/:id/reach支持在 Slack、Microsoft Teams、短信里继续对话;To:里放两个以上 Bot 就自动变成群聊。 - 生成式 UI 可以治理:
/admin/components发布组件、/admin/playground在浏览器里草稿沙箱、/admin/learning给 Bot 分配 Learning 容器。Bot 用组件回话,不是只吐一段散文。 - 部署门槛压得很低:一条
docker run -p 3001:3001 --env-file .env -e EMBEDDED_POSTGRES=on ghcr.io/copilotkit/openbot:latest就能起来,一个镜像里装了前端、API、浏览器和可选 Postgres,不用 Kubernetes。README 里明说"Nothing to clone and nothing to build"。
三十来条路由全部列在 README 里,这是个典型的"先给你看全景、再看功能"的写法。信息密度高,也等于承认了一件事:这东西的复杂度不在代码里,在配置面里。
OpenMuse:长任务真正难的是状态,不是智能
OpenMuse 是四个里唯一不依赖 OpenBot 的,也是唯一把移动端当第一现场的。它的自我描述是"一个带浏览器、终端、文件、而且工作会一直进行下去的个人 agent",技术上是 CopilotKit React Native for iOS / Android / Web。
它的电脑是复合体:持久化 Chromium + 可选隔离 Linux 工作区。agent 可以在自己的容器里跑命令、动文件、把 PDF 在电脑和 App 之间搬;你可以随时点 Take control 接管同一个浏览器会话,干完再还给它。
但真正让我停下来的是 Activity 那一行表格里的半句话:
Durable task plans, progress, input requests, pause/resume/cancel/retry, approvals, and saved receipts. SQL leases recover interrupted work.
这是一句分布式任务队列的行话,不是 agent 框架的词汇。意思是你手机锁屏、进程被杀、连接掉线之后,那个跑了一半的任务能靠数据库租约被别的 worker 捡起来继续。长任务 agent 的难点从来不是模型多聪明,是崩溃之后谁来接着干。 大部分 demo 里的"长任务"其实是"一个很慢的同步请求",一旦手机锁屏就没了。OpenMuse 这里做的是工程,不是演示。
围着这个核心还有一圈配套,都是"个人助手"这个定位才需要的:
- Goals & Tracking:对公开页面做周期性检查——页面变化、文本出现、美元价格跌破阈值,告警去重、失败退避。
- Documents:邮件附件 → 转 PDF → 要表单字段值 → 填好副本 → 待审回复 → 回执,一条链走完。
- Ideas:带来源证据的建议,可改可收可忽略;已发出的回复和已完成的相关工作会被排除。
- Finance:导一份交易 CSV,出一份带分类、明细、储蓄目标动作的支出总结。
- 个人上下文:名字、语气、头像、记忆,都可以改。
代价同样实在:它要 Node 24 LTS 加 pnpm 11.19.0(精确到补丁号),还要一个 server-only 的 CopilotKit Intelligence project key——README 里写得很老实:"Rich Threads: CopilotKit Intelligence persistence in every mode ... A server-only project key is required." 没有 key,聊天连线程都开不了。
OpenDots:Dot 管角色,Space 管文档
OpenDots 的副标题是"always-on AI coworkers that move between text, calls, and Slack",落到界面上是两个概念的切分:Dot 管角色与权限,Space 管文档。
- Space 是工作文档的容器。页面存在本地工作库,支持嵌套子页、可搜索的库、网格与列表切换、聚焦式可视化编辑器(格式、斜杠命令、撤销重做)、以及 Markdown 源码模式。自动保存会报进度,保存失败保留草稿,还有版本检查防止旧编辑覆盖新内容——这几条听着琐碎,但凡是做过多人在线文档的人都知道,缺一条就会有人丢内容。
- Specialist Dot 是角色。每个 Dot 有名字、角色、指令、可用工具。研究员去查,写手去改,你能看见它们各自在干什么。
- 会话按页切分:每一页、每一个 specialist 各有一条会话,页面链接把文档空间和 Dot 聊天连起来。手动编辑在配置会话服务之前就能用——这个设计顺序是对的,先让文档能写,再谈 agent。
- 人工审阅卡:让 Dot 先出草稿再保存,
Approve & save或Decline;同意才在授权 Space 里建页并返回链接,同一份草稿重试能找回同一个页面,草稿变了就要重新审。这条规则定得很准,把"重试的幂等性"和"审批的时效性"同时守住了。 - MCP 按工具分级:只读工具自己跑,其他工具弹
Approve & run,一个 Dot 一个开关。 - 电脑是借来的:直接用 OpenBot 的容器监管与电脑服务,浏览器配置和工作区文件跨启停保留;服务凭据留在服务端,按 Dot 派生不同的电脑凭据——多租户系统里这条是底线。
它也是四个里最"热"的(日均 224.5 星),同时 open issue 最多(78 个)。这两个数字放在一起是典型的"需求跑在实现前面"。
OpenDuet:主动式的代价,是学会什么时候闭嘴
OpenDuet 只有 4 颗星、5 天大,但它的交互设计是四个项目里最值得单独拎出来讲的,因为主动式助手和被动式助手是两种完全不同的产品。
它的开场不是"你好,有什么可以帮你",而是一份早报:今天有什么、什么变了、哪件事需要你决定。它跨邮件、日历、Slack 看一遍,把少数几件需要你的提到最上面,其余的先压着,等到真的要紧了再说。
这里的产品赌注只有一个:分流准确率。它每天在赌"这件事值得打扰你"。判错了,一次是噪音,三次用户就关掉了。README 里专门提到邮件分流有评估数据,说明团队清楚这是核心指标,不是附属功能。
为了让"主动"不至于变成"危险",它写了四条硬约束:
- 动手前先演一遍:发消息、付款、签文件、删东西之前,把具体动作原样显示出来,等你选 Refuse / Allow once / Always allow;发给别人的消息一定要问,并且告诉你发给谁、内容是什么。
- 密码永远不进对话:站点要登录时,你在遮罩框里输入,密码到站点、不到 agent 读的上下文里;存下来的凭据加密且只写。
- 出站检查:每条要发出去的消息都过一遍敏感信息检测,卡号、健康信息这类东西不该因为一次幻觉就漏出去。
- 排队不抢占:它在执行动作时你插话,你的消息排队,等它做完再答。
这四条放在一起,构成了一份"agent 产品的上线前检查清单"。功能可以慢慢加,这四条缺任何一条,企业就不会让你接真实账号。现在抄 OpenDuet,抄的应该是这份契约,不是它的界面。
顺带说清它薄在哪:它的 Bots、skills、渠道、电脑全来自 OpenBot,自己那层在一个文件夹里;线程与记忆仍然要一个 CopilotKit Intelligence 项目(免费额度可以);5 天 4 星,连 issue 都只有两个。把它当"成品"评估会失望,当"参考实现"看则刚好。
和自建、和终端 agent 比,它省掉了哪四块
把这三个选项摆在一起,这四个仓库省的是什么就很具体了。
| 对比对象 | 你得到的 | 你付出的 |
|---|---|---|
| 用 LangGraph / Mastra 自建 | 完全自由,技术栈自己定 | 多租户隔离、动作网关与策略、审计留痕、每用户一台电脑的容器生命周期,四块都要自己写 |
| 用终端 agent(Claude Code、Codex CLI 这一类) | 单机仓库内循环极强,改动即验证 | 没有多租户、没有审批卡、没有"每人一台电脑"的模型,也不是给人看过程的界面 |
| 买 SaaS | 开箱可用,模型和体验都是顶配 | 数据在别人机器上,界面改不动,嵌不进你自己的产品 |
按我的判断,自建路线省不掉的正是这四块:多租户隔离、动作网关 + 策略裁决、审计留痕、每 Bot 独立容器与浏览器身份。 这四块都不是"写个中间件"的事——容器生命周期要处理崩溃重启和卷保留,浏览器身份要处理登录态和按租户派生凭据,策略要处理"拒绝优先 + 异常默认拒绝",审计要处理"动作发生前裁决、发生后记录"的一致性。这套东西的难点在边界条件,不在代码量。CopilotKit 四件套的价值,就是把这几块边界条件先替你踩了一遍。
反过来说,如果你的场景是"one repo、one developer、no shared accounts",那这四个仓库对你就是过度设计——终端 agent 加一个 MCP 服务器更快,成本低一个数量级。选型的分水岭不是模型能力,是"要不要给多个人发账号"。
复刻它们要付的真实成本:五个坑
Star 数不告诉你的事,全在这五个地方。
一、没有托管版,运维是你的。 OpenBot 的 README 里写着 "A template, not a product" 和 "There is no hosted version to sign up for",OpenDots 写着 "A template, not a hosted product"。OpenBot 明说"nothing here is published as a package to depend on: every workspace in this repository is private"。你要自己扛 Docker、Postgres、每个 Bot 的容器生命周期、卷备份。scripts/stop.sh 甚至要专门处理"每个 Bot 的 computer 不归 compose 管"这件事——这种细节只有在真机上跑过才会写出来。
二、MIT 不等于零外部依赖。 这是最容易误判的一条。OpenMuse 要 server-only 的 Intelligence project key;OpenDots 的会话"require CopilotKit Intelligence",三条路:托管服务、本地 Docker 评估、或商业授权的自托管;OpenDuet 要一个免费 Intelligence 项目;OpenBot 可以把 Intelligence 跑在本机 Docker 里,但那是"30 天许可、随时 local renew、目前只对 macOS + Docker Desktop 预览"的东西,README 自己标注"not a production installation"。开源的是代码,线程与记忆这层基础设施仍然要谈。
三、全是 Alpha。 三个仓库挂 status: alpha 徽章,OpenDuet 挂的是 early development。加起来 174 个 open issue。这不是劝退,是提醒你排期时把"跟着上游改"算进成本。
四、栈是绑死的,包管理器还是三套。 四份 README 里能数出四层绑定:全 TypeScript、CopilotKit 的 UI 组件、CopilotKit Intelligence(线程与记忆)、以及按需接入的 Composio(OpenDots 连接邮箱日历的方式);OpenMuse 再多一层 CopilotKit React Native。想在 Python 后端里嵌这套界面,等于把最后一层重写。顺带一提,包管理器也不统一:OpenBot 和 OpenDuet 用 bun,OpenDots 用 npm ci,OpenMuse 要 Node 24 LTS + pnpm 11.19.0,想在一台机器上把四个都跑一遍,环境得隔三套。这种摩擦在评估阶段特别伤士气——它不是难,是烦。
五、默认配置是给笔记本用的。 OpenBot 的 .env.example 里 OPENBOT_SINGLE_USER=true,注释写得很清楚:这个开关把每个请求都当作管理员放行,为的是"a fresh clone reaches the product without registering an OAuth client first"。自己玩没问题,上公网前必须关掉并配好登录,否则你的 Bot 电脑就是别人的电脑。
最短验证路径:半小时判断它值不值得
别从 OpenMuse 开始,它的前置条件最多(Node 24 + pnpm 11.19.0 + Intelligence key + 移动端工具链)。想快速判断这套东西对你有没有用,用 OpenBot 走一遍闭环就够了:
docker run -p 3001:3001 --env-file .env \
-e EMBEDDED_POSTGRES=on -v openbot-data:/var/lib/postgresql \
ghcr.io/copilotkit/openbot:latest前提是 .env 里得先有 INTELLIGENCE_API_KEY——OpenBot 缺这个变量会直接拒绝启动,README 里专门提醒过这一条:npx copilotkit@latest local connect 写进去的是 CPK_INTELLIGENCE_API_KEY,而它只从 INTELLIGENCE_API_KEY 读,值要手动拷一遍。这种"变量名不一致"的小坑,正是复刻时最耗时间的地方。
起来之后打开 http://localhost:3001,做三件事:
- 进
/bot问一句Open news.ycombinator.com and tell me the top story.——看它怎么驱动浏览器、过程怎么呈现。 - 让它去填
https://httpbin.org/forms/post,然后去/admin/audit逐条看记录。 - 去
/admin/boundaries加一条拒绝规则或预设,重试刚才那个动作——这一步才是关键,它验证的是"策略真的在动作之前生效",而不是事后记一笔日志。
三件事走完,你对"网关式治理"有没有用就有判断了。这个闭环比读十遍 README 快。
什么该抄,什么别抄
该抄的四个默认值:
- 工具调用过网关:解析目标 → 按策略裁决 → 留痕。治理跟着协议走,换框架不用换权限体系。
- 一个 agent 一台电脑:容器 + 独立浏览器配置 + 独立工作区 + 派生凭据。共享浏览器再靠参数隔离,早晚出事。
- 审批卡的粒度:一份草稿一次审批,草稿变了重新审批,同一份重试能恢复同一结果。这三句话同时解决了幂等和时效。
- 密码与出站的物理隔离:遮罩输入、只写凭据、出站敏感信息检查。这三样是接真实账号的门票。
别抄的三件事:
- 四个全上。 功能面大量重叠,OpenDots 和 OpenDuet 的底座就是同一份 OpenBot 代码。先想清楚用户是坐办公室还是在路上,再决定要不要 OpenMuse 那条独立的移动端线。
- 当"开源替代品"直接上线。 Alpha + 依赖 Intelligence,两个条件任何一个没解决,都不适合对外承诺 SLA。
- 照着路由表抄界面。 OpenBot 三十多条路由是"配置面全景",不是"功能优先级"。真做产品,先做
/admin/boundaries和/admin/audit,这两个是别人愿意把账号交给你的前提。
一句话收口:CopilotKit 这四件东西真正卖的,不是四个 App 的界面,而是把"多租户 + 每租户一台电脑 + 每个动作先裁决后留痕 + 敏感动作人工确认"这套企业约束,压成了可以 clone 的默认值。工程上难的部分,它已经替你想过了;产品上难的部分——你的用户到底需不需要一个会主动找他的 agent——它替你想不了。
参考文档与链接
- CopilotKit/OpenBot — 7,262 星(2026-10-27),自托管 Agent 平台底座,容器监管 + 工具网关 + 策略与审计
- CopilotKit/OpenDots — 6,062 星,Dot 角色 + Space 文档,电脑能力复用 OpenBot
- CopilotKit/OpenMuse — 5,694 星,React Native 三端个人助手,SQL 租约恢复中断任务
- CopilotKit/OpenDuet — 主动式助理参考实现,审批 / 密码遮罩 / 出站检查的完整契约
- CopilotKit 主仓 — 38,266 星,前端 Agent 栈与生成式 UI
- AG-UI 协议 — agent 与前端交互的开放协议,OpenBot 的框架无关性来自这里
- CopilotKit 文档 — Intelligence 的托管、本地 Docker 评估与自托管授权三条路径
- Composio — OpenDots 接入邮箱、日历等已连接应用的方式
你更愿意要一个"你问它才动"的助手,还是一个"它觉得重要就来找你"的助手?前者省心,后者省时间,但分流判错一次就是一次打扰。评论区说说你能忍几次。
作者: itech001
来源: 公众号:AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/
关注每日最新AI新闻和技术博客,主页有更多的文章的AI 技术参考:https://www.theaiera.top
本文首发于 AI人工智能时代,转载请注明出处。