1. 2026-08-31热榜观察多智能体课堂为什么能登顶1.1 榜单上的几个信号不只是多智能体课堂每天刷一遍GitHub今日热榜已经成了我的固定动作倒不是怕错过什么大新闻主要是想看看社区里正在往哪个方向使劲。2026年8月31日这天的榜单很有意思拿到第一名的不是某个大厂开源的基础设施也不是某个人气很旺的AI应用而是一个名字听起来像教育产品的项目——多智能体课堂。这个结果让我意外了几秒但冷静下来一想又觉得完全在情理之中。同一天榜单上还有几个值得注意的项目。gaoshu705/qzonearchive出现在比较靠前的位置这个项目主要解决的是把QQ空间里的数据完整恢复和归档保存下来属于典型的工具型开源项目需求明确、定位清晰用户量起来之后热度很容易冲上去这类项目的逻辑比较简单痛点足够痛就会有人用脚投票。榜单后段还有一些老面孔比如各类AI开发框架的更新版本、数据库工具、前端组件库之类的都是日常刷屏的标准配置。但多智能体课堂能压过这些项目登顶说明的不只是项目本身的完成度更是整个技术社区关注点的转移。过去半年里多智能体从论文里走出来的速度比我预想的快得多。去年我还在跟朋友讨论多Agent到底是不是伪需求今年GitHub上就已经出现了几千星的教学型项目而且不是那种只有PPT和概念图的PPT开源而是带着可运行代码、完整实验环境和作业题目的实体内容。这个信号比任何技术报告都真实。所以说这份榜单本质上反映了两类项目在今天的生态位一类是解决具体问题的实用工具另一类是定义大家接下来该学什么的教育型基础设施。后者能在热度上超过前者恰恰说明行业已经过了要不要用的争论期进入了怎么系统学会的普及期。1.2 多智能体课堂的定位面向谁、解决什么问题我去翻了多智能体课堂这个项目的完整仓库它的定位非常清楚面向已经有一定AI开发基础、但还没有系统接触过多智能体系统的开发者提供一条从零到一的学习路径。项目作者没有把它包装成三天精通多智能体的速成课而是用了一种更实在的方式——把概念、架构、代码、实验按章节组织好每一章都是原理 可运行示例 思考题的结构整体上更像一门大学的课程设计而不是短视频平台的碎片化教学。项目解决的问题也很具体多智能体领域最大的门槛其实不是某个算法看不懂而是不知道一个完整的多智能体系统到底由哪些部件组成。大多数人打开LangGraph或者AutoGen的文档第一反应往往是我该用哪个API这些概念之间是什么关系。多智能体课堂做的就是把这层窗户纸捅破它先用很朴素的语言讲清楚黑板的角色再给出可以直接跑起来的代码最后让你在修改参数的过程中建立直觉。适合读这个项目的读者我觉得有三类。第一类是正在做AI应用开发、想尝试让多个模型角色协作的工程开发者他们需要的是能落地的模式第二类是研究强化学习、Multi-Agent Reinforcement Learning方向的学生可以在项目里找到基础环境练手第三类是技术决策者他们不一定自己写代码但需要对多智能体系统核心架构与运行原理有一个全局认识否则没法判断团队提出的方案靠不靠谱。1.3 我为什么愿意花时间写这篇文章说实话我平时不太愿意给热门项目写推荐文章GitHub上每个月都有几个看起来很厉害的项目冲上热榜但很多经不起细看。这次愿意花一个下午把多智能体课堂拆开研究是因为它恰好戳中了我最近的实际需求。我手头有一个内部工具原本是让一个Agent按照固定流程处理数据清洗和报表生成跑了两三个月效果一直不太稳定。问题出在单个Agent需要同时承担理解数据调用工具生成结论检查错误好几件事结果每一项都做不精。后来我把任务拆给了三个角色——一个负责解析需求一个负责操作数据一个专门做质量检查——只花了一周多的时间稳定性和准确性都有了明显提升。这个经历让我意识到多智能体不是学术圈自嗨它对实际工程的价值是实实在在的。正好多智能体课堂里有一套章节讲的就是这种角色拆分模式和我的实践对上了。所以这篇文章里有不少内容其实是我一边读项目文档一边对照自己踩坑经历做的笔记希望能帮那些准备入坑多智能体开发的朋友少走点弯路。2. 多智能体课堂到底在教什么课程体系与项目亮点2.1 课程主线从单Agent到多Agent协作的演进多智能体课堂的课程主线设计得比较用心它不是一上来就扔出一堆架构图而是先花了两个章节讲清楚为什么单个Agent不够用。单个Agent的典型问题项目里总结为角色过载和上下文污染。角色过载很好理解就是让一个人既当前台又当会计又当保洁他处理复杂事务时一定会顾此失彼上下文污染则更隐蔽当Agent在一个长对话里既要理解用户意图又要处理工具返回结果时无关信息会不断混入上下文窗口导致模型注意力被稀释。这两个问题我在实际项目中都遇到过所以读到这部分时非常有共鸣。课程从第三章开始引入多Agent的解决方案顺序安排是先讲角色拆分再讲通信方式然后讲任务编排最后落到工程落地。整个路径是层层递进的关系不是知识点的堆砌。尤其值得表扬的是项目里每引入一个新概念都会配套一个mini示例比如讲角色拆分时给了一个两个Agent互相交接任务的例子代码只有几十行跑起来不需要GPU任何一台普通笔记本都能快速看到效果。这种设计思路其实暗合了学习理论里的脚手架原则每学一个新知识都站在已有知识的台阶上。我第一次上手多智能体时走的就是弯路一上来就研究复杂的图结构和状态机结果被各种抽象概念绕晕了如果当时有这样的课程结构至少能节省两周的时间。2.2 技术栈与运行环境不是只教你概念项目在技术选型上走的是实用主义路线没有绑定某一家厂商的闭源生态。我看了一下仓库里的依赖文件核心基于Python 3.11以上主要用到的库包括LangGraph、Pydantic、以及OpenAI兼容接口的调用封装。作者还专门写了一个抽象层意思是说无论你底层接的是哪家大模型的API还是本地跑的推理服务只要是OpenAI兼容格式都能对接得上。这一点我特别认可。很多教学项目会把自己绑死在某个特定框架上结果读者学完之后换个场景就不知道怎么用了。多智能体课堂的做法是弱化框架的存在感把重心放在智能体之间如何定义工具、如何传递消息、如何裁决冲突这些通用设计问题上。框架只是用来呈现这些思想的载体换一个框架核心思想依然成立。运行环境的搭建也非常友好。项目提供了一个Docker Compose配置一键可以启动一个本地运行环境里面包含了模型代理服务、示例数据库和任务队列。也就是说你不必拥有昂贵的GPU也能完整跑通大部分实验因为课程示例本身用的模型规模就不大很多任务用中等参数量模型就能完成。我大概估算了一下一个完全没有接触过这个项目的人从克隆仓库到跑通第一个多Agent示例正常网络条件下半小时内是可以完成的。当然如果你访问GitHub时遇到网络不通畅的情况那可能需要先解决网络环境问题这部分不在项目本身的讨论范围内。对于想深入学习的人来说Docker环境还有另一个好处可以随意折腾而不用担心把宿主机搞坏。我在跑实验时曾经把某个Agent的循环次数调得过大结果进程直接吃满了CPU但因为跑在容器里直接重启容器就恢复了省了很多麻烦。2.3 可运行示例的设计思路从玩具到真实的梯度多智能体课堂的示例设计是我见过最讲究的之一。整个仓库大概有二十多个示例难度呈梯度分布从最基础的两个Agent一问一答到接近生产环境的多Agent协作完成数据报表自动生成每个示例都标注了推荐运行时长和预期输出。早期的示例刻意保持玩具感。比如有个示例是让一个Agent扮演图书管理员、另一个扮演读者通过消息队列进行查询和回答逻辑非常简单但把多Agent通信的四个核心步骤都走了一遍请求构造、消息路由、任务执行、结果返回。这种玩具其实是很好的教学工具因为它把复杂系统的关键环节全部暴露在明面上读者可以单步调试看清楚每一条消息从哪里来到哪里去。到了中期示例复杂度开始上升。比如多智能体课堂里有一个经典的多Agent辩论示例三个Agent分别承担正方、反方和裁判的职责针对一个问题展开多轮讨论最终由裁判Agent输出结论。这个示例我第一次跑的时候非常震撼因为它让我直观感受到了多个AI角色一起思考和单个AI自言自语之间的本质区别——当正方Agent知道有反方Agent会反驳自己时它输出的论点会明显更加严谨。后期示例则接近真实工程场景。比如有一个章节讲的是如何构建一个自动运维值班助手系统里包含了监控数据采集Agent、故障分析Agent、工单创建Agent和人工审批Agent它们之间通过一个事件总线协作任何一个环节出问题都有超时和重试机制。这类示例的价值在于它让读者看到多智能体系统在真实环境里会遇到的工程挑战——消息丢失怎么办、某个Agent卡住了怎么办、不同Agent的结论冲突怎么办——这些都是纯理论教程永远不会告诉你的细节。2.4 项目文档与社区活跃度一个教学项目能走多远最后聊聊文档和社区。GitHub热榜项目很多但文档质量能跟代码质量匹配的项目少之又少。多智能体课堂的中文文档写得很细每个章节除了代码注释之外还配了说明图虽然我不建议新手一上来就看图但作为复习资料确实很有用。文档里甚至专门有一页常见概念辨析把很多人在技术群里天天问的问题做了统一整理比如什么是编排式协作什么是协商式协作Multi-Agent和Agent Workflow有什么区别。社区的活跃度也是一个重要指标。我特意看了项目的Issue区和Discussions区作者回复问题的频率很高而且不是敷衍式回答很多回复都附带修改后的代码片段或运行日志。有人在Issue里反馈某个示例在Windows环境下跑不通作者两天内就给出了修复补丁。这一点对学习者太重要了一个教学项目如果遇到问题没人管学习体验会大打折扣。3. 多智能体系统核心架构拆开来看协作是怎么发生的3.1 三种主流协作模式编排式、协商式、市场式看完了多智能体课堂的课程设计咱们来深入聊聊多智能体系统的核心架构。项目里有句话让我印象深刻多智能体系统的设计本质上是选择一种协作的治理模式。市面上绝大多数系统设计都可以归入三种模式。第一种是编排式协作也是最容易理解的一种。系统里有一个明确的管理者角色它负责拆解任务、决定把子任务分给谁、收集结果并做最终汇总。这种模式就像一家公司里的项目总监所有信息流都经过它好处是行为可预测、方便调试坏处是管理者容易成为性能瓶颈如果任务特别多中心节点会不堪重负。LangGraph里的StateGraph天然适合做这种编排因为它的节点和边定义了清晰的控制流。第二种是协商式协作系统里没有绝对的中心Agent之间通过互相沟通来达成一致。这种模式更像一桌人在开会每个人基于自己的专业视角发表意见然后通过投票或共识机制形成最终决策。多智能体辩论就是一个典型例子。协商式的优点是灵活、鲁棒性高某个Agent挂了其他Agent还可以继续讨论缺点是收敛速度慢对话轮次一多Token消耗会呈指数级上涨而且容易出现讨论了半天没有结论的尴尬局面。第三种是市场式协作系统里有一个任务市场各个Agent根据自己的能力对任务进行竞标出价最低或条件最优的Agent获得执行权。这种模式借鉴了经济学里的拍卖机制在资源调度场景下特别有效。但实现难度也最高因为你需要定义清楚价格是什么——是计算资源成本、时间成本还是置信度不同的定价函数会导致完全不同的系统行为。多智能体课堂对这三种模式都做了详细讲解和代码示例。我在读的时候对照自己的项目想了想我做的数据清洗工具其实最适合编排式因为流程非常固定但如果是做一个开放域的问答系统协商式可能更好因为答案不是唯一的需要多个视角交叉验证。3.2 消息传递与共享记忆通信协议的设计无论选哪种协作模式Agent之间的通信协议都是绕不开的基础设施。多智能体课堂里专门有一章讲这个问题作者开篇就抛出一个观点Agent之间的消息格式比你选什么框架重要得多。我之前在做多Agent实验时犯过一个低级错误——让两个Agent直接传递自然语言文本。第一轮跑下来效果还行到了第三轮就乱了套因为Agent A输出的自然语言包含了很多无关内容Agent B无法准确解析出其中的结构化指令。读了项目的通信协议章节后我才意识到问题出在哪里Agent之间的消息应该尽可能结构化而不是走自由聊天路线。这里的核心设计模式是消息必须包含至少四个字段发送者ID、接收者ID或广播标志、消息类型、消息载荷。消息类型可以是指令、查询、回复、错误、心跳这几种每种类型有固定的处理逻辑。这样做的好处是每个Agent接收消息后可以先按类型路由不需要每次都做一次自然语言理解。项目里甚至给出了JSON Schema的定义照着写基本不会出大问题。共享记忆是另一个容易翻车的地方。多智能体课堂讲得很实在多Agent系统需要一个共享记忆层来同步状态否则每个Agent的上下文都是割裂的系统整体就会像一个各说各话的会议。但共享记忆也不是越大越好项目建议维护一个结构化记忆库而不是让所有Agent共享完整的对话历史。我的理解是各Agent之间的信息传递应该遵守最小必要原则只传对方完成当前任务所需的信息而不是把整个对话上下文都丢过去。3.3 多智能体强化学习与MCP的交叉为什么今年特别火如果说协作模式和通信协议解决的是多个Agent怎么合作的问题那么多智能体强化学习解决的则是多个Agent怎么在动态环境里学习最佳策略的问题。传统单Agent强化学习里只有一个策略网络在更新但多智能体强化学习里每个Agent都有自己的策略而且它们的策略会互相影响这就带来了非平稳性问题——环境对某个Agent来说不再是固定的因为其他Agent的行为也在变。多智能体课堂里对MARL的介绍偏入门主要覆盖了经典的MADDPG算法和一些基础环境。作者很诚实地指出学术界很多MARL算法离工程落地还有距离目前实际项目里用得更多的仍然是基于大模型推理的协作方案。但理解MARL的基本思想仍然有价值尤其是每个Agent只观察到局部信息但需要通过通信来达成全局目标这个问题设定几乎存在于所有真实多智能体系统里。今年MCP协议的火热也让多智能体开发进入了一个新阶段。MCP本质上定义了Agent与外部工具之间的一套标准化接口如果把Agent想象成人的大脑MCP就是让大脑灵活控制双手的标准协议。在多智能体系统里MCP的价值更加明显不同的Agent可以共享同一个工具集通过标准化的接口调用不再需要为每个Agent单独定制工具接入逻辑。多智能体课堂里有一些章节已经用到了MCP风格的工具调用设计这也解释了为什么这个教学项目能踩中当前的技术热点——它不只是在讲理论而是跟上了工具生态的演进速度。4. 动手跑通一个多智能体课堂式的小项目4.1 环境准备与项目骨架半小时起步讲了这么多概念不动手跑一个项目总觉得不踏实。我建议你不要光看文章最好自己动手把多智能体课堂仓库里最基础的示例跑一遍。下面是我实测过的环境准备流程。首先你需要一台能运行Python的电脑Windows、macOS、Linux都行。我自己的测试环境是Ubuntu 22.04加上Python 3.11。项目推荐使用虚拟环境我一般习惯用python -m venv venv创建独立环境避免依赖冲突这是个很好的习惯尤其当你同时看好几个GitHub项目时虚拟环境能帮你隔离不同项目之间的包依赖。接下来是安装依赖项目根目录下有requirements.txt直接执行pip install -r requirements.txt即可。我实测过核心依赖大概包括langgraph、pydantic、openai、rich这几个库安装过程比较顺畅。如果你打算用本地模型跑实验还需要额外装一个推理服务的客户端项目文档里有说明。然后是配置文件。仓库里有一个.env.example文件你需要复制成.env并填入你的模型API配置。项目做得很贴心它支持通过环境变量指定模型名称和API地址默认配置指向一个标准的OpenAI兼容接口。我测试时用的是本地部署的中等规模模型效果完全够用内容生成速度也很快。最后跑一下最小示例验证环境。我建议先从examples/01_basic_two_agents开始这个示例创建了两个Agent一个负责接收问题一个负责回答问题中间通过简单的消息传递连接起来。运行成功后会出现一个命令行交互界面你可以输入任何问题看看两个Agent是怎么协同工作的。4.2 实现一个三Agent协作的文本处理流水线跑通了基础示例之后我想带你做一个更有意思的实验实现一个三Agent协作的文本处理流水线这也是多智能体课堂里一个核心模式的简化版。任务设定是这样的给一段原始文本Agent A负责拆解要点Agent B负责把要点扩充成正式内容Agent C负责质量审核。这个实验虽然是教学用途但它包含了多智能体系统的关键元素角色分工、结构化消息、结果校验、错误回退。下面是核心代码骨架基于项目的设计模式改写而成from dataclasses import dataclass from typing import Optional dataclass class Message: sender: str receiver: str msg_type: str payload: dict class TextAgent: def __init__(self, name: str, system_prompt: str): self.name name self.system_prompt system_prompt def handle(self, msg: Message, llm) - Message: # 调用模型生成回复 response llm.chat(self.system_prompt, msg.payload.get(content, )) return Message( senderself.name, receivermsg.sender, msg_typereply, payload{content: response} ) def run_pipeline(input_text: str, agents: dict, llm) - str: # Agent A拆解要点 msg_a Message(user, summarizer, task, {content: input_text}) reply_a agents[summarizer].handle(msg_a, llm) # Agent B扩写内容 msg_b Message(summarizer, writer, task, {content: reply_a.payload[content]}) reply_b agents[writer].handle(msg_b, llm) # Agent C质量审核 msg_c Message(writer, reviewer, task, {content: reply_b.payload[content]}) reply_c agents[reviewer].handle(msg_c, llm) # 简单检查审核结果 if 通过 in reply_c.payload[content]: return reply_b.payload[content] else: # 重试机制把审核意见返回给writer重新修改 msg_retry Message(reviewer, writer, revise, { content: reply_b.payload[content], feedback: reply_c.payload[content] }) reply_b2 agents[writer].handle(msg_retry, llm) return reply_b2.payload[content]这段代码虽然简单但已经体现出了多Agent协作的精髓三个Agent各司其职消息以结构化对象的形式传递审核结果通过条件判断决定是否需要回退重试。实际跑下来你会发现加入审核Agent之后最终输出的质量比单个Agent直接生成要高很多因为writer知道自己的稿子会被reviewer检查生成时会不自觉变得更严谨。你可以在此基础上继续扩展比如在工作流里加入Agent间互相调用的机制或者让Agent在生成过程中使用外部工具。这些扩展都很有趣尤其是当其中一个Agent需要查数据库或调用API时MCP风格的接口设计会让整个集成变得非常简单。4.3 踩坑记录与排查思路我自己掉过的坑这部分我想分享几个我在跑这个项目时真实遇到的坑以及对应的排查思路。其中有些问题在项目文档里也不一定能直接找到答案。第一个坑是Agent不按指令格式输出。我给一个Agent设计了严格的JSON输出格式要求但模型在部分场景下会额外输出解释性文字导致下游解析直接报错。后来我的解决方法是双管齐下一方面在提示词里加入few-shot示例把输出格式正确和输出格式错误的例子都给出另一方面在解析层做容错用正则把JSON片段从文本中提取出来而不是直接做全量解析。这个经验几乎适用于所有基于大模型的应用开发。第二个坑是Agent陷入无限循环。我在测试开放域问答时两个Agent在一个问题上反复交换信息就是无法达成共识日志里出现了几百条消息。这个问题的根因是缺少终止条件。我后来给整个工作流加了最大轮次限制和超时机制一旦超过阈值就强制返回当前最优解。这里分享一个经验策略——设计任何多Agent协作时都应该给整个系统引入一个断路器机制类似于电路里的保险丝在系统失控前主动拦截。这对生产环境尤其重要否则一次异常对话可能让你付出高额的计算成本。第三个坑是某个Agent霸占了公共工具。我在一个实验里让多个Agent共享同一个数据库连接结果发现某个Agent的大批量查询把数据库连接池占满了其他Agent的请求全部排队等待。这本质上是一个资源竞争问题解决办法是给不同的Agent分配独立的工具实例或者在任务调度层面限制每个Agent对共享资源的访问频率。多智能体系统的复杂度很大程度上就来源于这种资源共享问题越是接近真实场景这个问题越明显。第四个坑是上下文窗口溢出。我在早期设计中没有做记忆清理几千轮对话后整个历史都塞进提示词里最终触发了模型上下文长度限额报错。为了解决这个问题我为系统引入了摘要机制——当对话达到一定轮次后先让一个单独Agent把此前对话压缩成一段摘要之后所有Agent共享这段摘要而不是完整对话历史。这相当于给系统做了一次记忆压缩效果很理想Token消耗也降低了不少。5. 从热榜项目到工程思维GitHub趋势的正确打开方式5.1 热榜不只是看热闹如何从中提取有效信息回到开头聊的热榜话题。很多人刷GitHub热榜的心态是看热闹点进去看几眼觉得哇这个项目好厉害然后就没有然后了。我觉得这样太浪费了热榜其实是一个高质量的技术信号源关键是你要知道怎么从里面提取信息。我在GitHub上关注了各种方向的开源项目早已把刷热榜变成了自己的技术雷达而不是娱乐消遣。我自己的方法是看榜单时问三个问题。第一为什么是这个项目上了热榜而不是另一个这个问题能帮你识别当前社区的情绪和痛点。比如多智能体课堂能登顶说明大量开发者正在寻找多智能体的入门路径这是一个强烈的需求信号。第二这个项目解决的是谁的问题有些项目是给开发者用的有些是给企业决策者看的你只有知道目标用户是谁才能判断它跟你的关联度。第三如果我要用这个项目最核心的20%是什么这决定了你值不值得花时间深入研究。除了这三个问题我还会关注一个容易被忽略的指标Star增长速度与Issue数量的对比。一个项目如果Star涨得快但Issue区全是抱怨那很可能只是营销做得好反之如果Star涨得不快但Issue区都是高质量的技术讨论这个项目往往有真东西。多智能体课堂属于后者它的Issues里大量是这个示例在xxx场景下应该如何调整这类深度问题。5.2 学习开源项目的三步法从跑通到改造很多人拿到一个优秀开源项目第一反应是全部源码读一遍结果读了几天就放弃了。以我个人的经验来看新生项目正确的学习方式应该是用起来而不是看完结。我把自己的方法总结为三步法不一定适合所有人但希望可以供你参考。第一步是跑通最小闭环。不要一开始就读源码先按项目文档把最小示例跑起来看到实际输出是什么样的。这一步的核心目标是建立这玩意儿真的能跑的信心给自己吃一颗定心丸。跑通之后你再看文档感受会完全不同。第二步是改一个变量。多智能体课堂的设计师很懂教学心理学它的示例里标注了哪些参数可以调整调整之后会有什么影响。把一个Agent的初始角色描述改掉或者把协作模式从串行改成并行观察输出有什么变化。这个过程能帮你建立直觉模型——你不需要理解每一行代码但你已经能预测系统在什么情况下会如何表现。第三步是照着重写一遍。找一个最简单的示例关上仓库代码凭理解和记忆从零写一个类似的出来想不起来的地方再回头看。这一步耗时最长但收获也最大。我自己最近就在干这件事重写了一个多智能体课堂里的复杂示例最终代码大概只有原来一半的代码量其中还融入了我自己的状态清理逻辑。这种学别人的思想写自己的代码的路径是我认为最高效的开源项目学习方式。5.3 多智能体工程化的现在与未来最后说说我对多智能体工程化前景的看法。多智能体课堂能登顶热榜说明开发者对系统化知识的需求非常旺盛但真正的大规模生产级应用我认为还有一段路要走。当前阶段最有价值的多智能体应用集中在流程相对固定的场景数据处理流水线、复杂任务的子任务拆分与并行执行、需要多角色交叉验证的内容生成、以及需要人机协同的决策支持系统。这些场景的共同特征是边界清晰、评估标准明确Agent之间的协作可以被设计得比较稳定。至于完全开放域、任多个Agent自由协作解决任意问题目前还不够成熟容易出现不可控行为。从基础设施的角度看我比较乐观。MCP这类标准协议的普及会让Agent与工具之间的连接成本大幅下降消息队列、事件总线和状态管理这些传统后端技术正在被复用到多智能体系统里这个趋势非常明显。多智能体课堂里后期章节讲的那些工程模式其实就是传统分布式系统里早就被验证过的技术在多Agent场景下的重新映射——超时重试、断路器、幂等处理、分布式追踪这些概念放在多Agent系统里不但不过时反而是刚需。所以我的判断是接下来半年到一年多智能体工程化会沿着标准协议 成熟基建 领域模板的路径继续演进。多智能体课堂这类型的教学项目正好卡在这个时间点上它教的不只是几个算法示例更是把一套可以被复用的工程思维沉淀成了开源教材这类知识在GitHub上是稀缺资源登顶热榜可以说是实至名归。最后再分享一个我的个人习惯。每次看到优秀的热榜项目我除了学习和点赞还会在本地单独建一个笔记文件记下这个项目解决的核心问题、它的关键技术决策、以及我能从里面迁移到什么场景。过一段时间回看这些笔记你会发现技术趋势的脉络清清楚楚而且你自己的想法也在一次次记录中变得越来越有体系。