「别再刷教程了!」4.5 万人围观的 AI Agent 90天速成路线:clone 这 10 个 GitHub 仓库,语音、浏览器、RAG 全栈一次拆完

clone > tutorial，这个分歧终于被挑明了

5 月 3 日，开发者 Sukh Sroay 在推特上发了一段话，开头相当直接：

“If I had to learn to build AI agents in 90 days, I would not waste time on tutorials.”

「如果我必须在 90 天内学会构建 AI Agent，我不会把时间浪费在教程上。」

“I would clone these 10 GitHub repos and build until something shipped.”

「我会直接克隆这 10 个 GitHub 仓库，一直做，直到真的做出能交付的东西。」

▲ Sukh Sroay 的原帖，列出了 10 个 GitHub 仓库的完整清单（4.5 万次浏览，596 赞，1383 收藏）

话说得够狠。但它能传开，原因在于他直接甩出了 10 个真实的开源仓库名字——每一个都对应 AI Agent 技术栈里的一个关键能力。

很多人看到”10 个仓库”就想跳过去抄清单了。

别急。清单只是表面。真正有看头的，是这 10 个项目合在一起，刚好拼出了 2026 年 Agent 工程的完整技能树。

先看全景：10 个仓库，8 条技术主线

这 10 个仓库分属完全不同的技术层级。按能力拆开看：

语音、浏览器、编排、平台、检索、记忆、工具、技能库——8 条线拼在一起，就是今天做一个完整 AI Agent 系统需要覆盖的所有层级。

下面按层拆。

让 Agent 有”嘴”和”耳朵”：实时语音

Pipecat（⭐ 11,742）排在清单第一位，有它的道理。

做语音 Agent 和做文本 Agent 完全是两件事。你需要处理实时音频流、turn-taking（轮次切换）、延迟预算管理——STT 占多少毫秒、LLM 首 token 占多少、TTS 占多少，每一段都要精打细算。Pipecat 把这些脏活封装成了框架，还支持 Subagent 协议。

不过要注意一点：原帖提到的”sub-200ms latency”是 Pipecat 的官方宣传口径。社区里有开发者（@somi_ai）指出，端到端语音场景里 STT + LLM + TTS 都要吃延迟预算，这个数字不能直接当通用结论。

LiveKit Agents（GitHub: livekit/agents）走的是另一条路——底层靠 WebRTC，偏实时通信基础设施。如果说 Pipecat 像一个开箱即用的语音 Agent 框架，LiveKit Agents 更像给你提供了一整套实时音视频管道，Agent 逻辑由你自己往里填。

两个项目放在一起拆，你会对”实时多模态 Agent 到底难在哪里”有非常具体的体感。

让 Agent 有”手”：浏览器操作

Browser Use（⭐ 92,100）可能是这份清单里最容易让普通人理解”Agent”含义的项目。

它做的事情说起来很简单：让 AI Agent 像人一样操作浏览器——点击、输入、翻页、导航。那些”AI 帮我订机票””AI 帮我填表”的演示视频，背后跑的大概率就是这一类技术。

▲ Browser Use GitHub 页面：92.1k stars，10.5k forks，当前 browser-agent 赛道的头部项目

官方定位也很明确：

“Make websites accessible for AI agents. Automate tasks online with ease.”

「让网站对 AI Agent 可访问，轻松完成在线自动化任务。」

这个项目不只在推特上有热度。2025 年 2 月它在 Hacker News 做了 Launch HN，拿到了259 points、100 条评论。开发者社区讨论的焦点集中在几个关键问题：AI 代理操控浏览器到底能不能当通用接口？远程调试权限是否开得太大？云端执行是否更安全？

▲ Browser Use 的 Hacker News 讨论页：259 points / 100 comments，browser-agent 方向在开发者社区经得起较真的讨论

这些问题到现在也没有标准答案。但正因如此，Browser Use 才值得深入拆——你在 clone 之后会立刻遇到权限、安全、错误恢复这些真实的生产级问题。

让 Agent 能被”编排”：框架与多 Agent 协作

单个 Agent 能做事。但当你需要多个 Agent 分工合作，问题就变成了系统设计。

Mastra（⭐ 23,554）是 Gatsby 团队做的 TypeScript-first Agent 框架。为什么 2026 年很多 Agent 团队更倾向于用工程化框架？因为当 Agent 的数量和复杂度上来之后，统一管理状态、工具注册、memory 接入、browser 支持——单脚本根本撑不住。

Mastra 值得关注的一点在于，它背后有持续迭代的团队和资金在支撑。

▲ Mastra 官方博客：2026 年 4 月密集更新——Browser Support、Platform、$2200 万 A 轮融资、Memory/Workspace

从博客可以直接看到，2026 年 4 月他们连续发了 Browser Support、Platform 发布、融资公告、Memory/Workspace 等更新。这个项目处于快速进化状态，远不止一个孤立的开源仓库。

AG2（GitHub: ag2ai/ag2）是 AutoGen 的社区分叉延续版本，主打多 Agent 对话框架。如果你想理解”多个 Agent 怎么协商、分工、共享上下文”，AG2 是目前最成熟的参考实现之一。

让 Agent 能被”搭建”：可视化工作流

Dify（⭐ 140,061）在这份清单里 stars 最多，也最特别——它走的是低代码/平台化路线。

你可以把 RAG、MCP、模型接入、工作流用拖拽的方式串起来。对于想快速验证 Agent 想法却不想从零写框架代码的人来说，Dify 是门槛最低的起点。

但也正因为是平台型产品，它和 Mastra 这种纯代码框架要解决的问题不在同一个维度。两个都拆一遍，你会对”做 Agent 到底该用平台还是框架”这个选择有自己的判断。

让 Agent 有”知识”和”记忆”：RAG + Memory

RAGFlow（⭐ 79,639）提醒了一件很多人忽略的事——Agent 的能力远不止”会调用工具”。在复杂知识场景里，检索和 grounding 是另一条关键主线。

RAGFlow 主打 layout-aware chunking（基于版面的文档切分）、agentic retrieval（代理式检索）、citation grounding（引用定位）。当你的 Agent 需要处理上百页的 PDF、合同、技术文档，简单的向量搜索完全不够——你需要一套完整的 RAG 引擎。

Mem0（GitHub: mem0ai/mem0）解决的是另一个迟早会碰到的痛点——记忆。

做 Agent 做到后面，你一定会遇到这个场景：用户上周说过的事，Agent 完全不记得。Mem0 做的就是跨会话长期记忆、混合搜索、持久化存储。在 chatbot 时代可以勉强忽略，到了 Agent 时代就是刚需。

让 Agent “连接世界”：工具接入与技能库

Composio（GitHub: ComposioHQ/composio）解决的是 Agent 工程里最让人头疼的问题之一——工具接入和授权。

你想让 Agent 发邮件、发 Slack 消息、操作 GitHub、读 Notion 文档？每一个都要处理 OAuth 授权流程，每一个 API 的格式都不一样。Composio 把这些全部统一封装，替开发者绕过”OAuth 噩梦”。

Awesome Claude Skills（GitHub: travisvn/awesome-claude-skills）是清单里最”非典型”的一个——它跟框架、平台都不在一个赛道上，提供的是 1000+ 可直接安装的 prompt 和 workflow 技能包。

这个项目的价值在于它补上了一个容易被忽视的维度：当 Agent 真正上线时，提示和工作流本身也需要工程化管理。prompt 不能全靠手写、靠记忆，它们也需要版本控制、模块化复用、一键安装。

社区争论：10 个仓库，太多还是刚好？

帖子传开之后，争论也跟着来了。

支持派很直接。开发者 @Cyberhonk26 评论：

“Clone > tutorial every time.”

「比起刷教程，直接 clone 仓库永远更有效。」

他还专门点名了 Pipecat 和 Browser Use，认为这两个项目最能让人快速碰到真实生产问题。

但谨慎派的声音也很有分量。@saen_dev 的观点：

“Pick two repos max and actually ship something to real users with them.”

「最多挑两个仓库狠狠干，并且真的把东西交付给真实用户。」

这条评论戳到了一个核心问题：90 天如果平均分配给 10 个项目，很容易变成”每个都跑了 demo，没有一个真正上线”。

也有人在回复里补充了 Google ADK 等项目，说明社区并没有把这份清单当绝对榜单——更像一个开放的讨论模板。

这份清单的真正价值：一张 Agent 技术全景图

说到底，Sukh Sroay 这条帖子最有价值的部分，远不止那 10 个仓库名字。

它把 2026 年 AI Agent 技术栈的主要层级，用 10 个真实项目完整拼了出来。

语音、浏览器、框架、平台、RAG、记忆、工具、技能库——如果你在学 Agent 的过程中只知道”调 API + 写 prompt”，这张地图会让你看到自己还缺多少块拼图。

更务实的用法可能是这样：

1.第一阶段：用 10 个仓库建立完整的技术认知地图——每个 clone 下来，跑通 demo，搞清楚它在什么层、解决什么问题。 2.第二阶段：挑 1-2 个最贴近业务场景的项目深入改造，直到能跑在真实用户面前。

因为真正困难的从来不是 clone 下来跑通 demo。真正困难的是后面那些东西——鉴权、会话持久化、观测性、错误恢复、成本控制、延迟优化、权限管理。

从复刻到交付，中间隔着的，才是 AI Agent 工程能力的真正门槛。

— END —