前39篇你已经能让程序上网拿数据了，但至今走的都是”官方点餐窗口”（API）。可世上不是每家网站都开窗口——窗口不开的时候，就得自己看懂网页的骨架，才谈得上从里面取东西。今天不写爬虫、不装任何新库，只干一件事：像”看懂房间布局”一样看懂网页的结构——标签、层级、class 和 id。骨架看懂了，下一篇的爬虫就是顺手的事。
上一篇的天气工具做完，你大概正得意：程序能自己上网了！然后你遇到这么一件事——
你们单位的公告栏网页上挂着一张排班表，领导说：”把这张表整理成 Excel 存档，每周一次。”你心想：这不就是上一篇的活儿吗？发请求、拿数据、存文件。于是你打开那个网页，右键”查看网页源代码”，准备找那个”官方点餐窗口”（API）——
没有窗口。人家网站压根没提供 API。
GitHub: https://github.com/FlowiseAI/Flowise
Star: 50k+ | 语言: TypeScript | 许可: Apache 2.0
状态: 已归档（2026年），推荐查看 Future of Flowise
Flowise 是一个可视化 AI 工作流构建器，定位为低代码/无代码平台，让用户通过拖拽式界面连接 AI 模型、工具、向量存储等组件，构建复杂的对话式 AI 应用。其核心理念是：将 LangChain 的编排能力可视化，降低 AI 应用开发门槛。
与 Dify、n8n 等同类产品相比，Flowise 的独特之处在于：它本质上是 LangChain 的图形化前端，每个节点都对应一个 LangChain Runnable，执行引擎直接复用 LangChain 的组合操作符。这意味着 LangChain 生态的任何新能力都能快速集成到 Flowise 中。
Flowise 采用 Turborepo + pnpm workspaces 管理的 monorepo，包含 4 个核心模块：
前面38篇，你攒了一柜子零件：变量、条件、循环、函数、文件、JSON、requests、API。今天这篇不发新零件——今天干的是”组装”：把 requests、JSON、函数三件套拧成一个真正能用的小工具——输入城市名，天气、温度、湿度一目了然，还能顺手记进账本。这是你第一个”联网的正经软件”
每天早上你醒来的第一件事，十有八九是摸手机、点开天气APP、看一眼今天几度要不要带伞。这个动作你可能已经做了几千次，从来没觉得它有什么了不起。
但你注意过吗：那个小小的天气页面背后，发生了一整套你已经全学过的事情——
看出来了吗？你已经会做这个APP了。不会的只是”做成手机APP”那层皮，而那层皮今天也不需要——一个命令行小工具，一样能把活儿干了。
Stars: 154k+ | License: MIT | 语言: Python + TypeScript
定位: 可视化 AI 工作流构建与部署平台，支持多 Agent 编排
Langflow 是一个用于构建和部署 AI 驱动的 Agent 和工作流的可视化平台。它提供拖拽式界面，让用户通过连接组件节点来构建 LLM 应用，同时内置 API 服务器和 MCP 服务器，可将工作流转化为工具集成到任意框架中。项目创建于 2023 年 2 月，目前已成为 AI 工作流可视化领域 star 数最高的开源项目之一（154k+）。
核心理念：“Source code access lets you customize any component using Python” — 每个可视化组件背后都是真正的 Python 代码，用户既可以拖拽使用，也可以直接编写 Python 自定义组件。这种”可视化 + 代码”的双模态设计是 Langflow 区别于纯低代码平台的关键差异。
Langflow 采用经典的前后端分离 + 服务化后端架构：
上一篇你已经让程序”上网”了，可拿回来的是一整张画给人看的网页，想从里面抠出一个数字，费劲还容易碎。今天学的 API，就是网站专门留给程序的”官方点餐窗口”：你递上一句正经请求，它直接把干干净净的数据端给你。今天只引入一个新概念：API——以及它的黄金搭档
回应.json()，把数据原封不动拆成 Python 里的字典
先讲讲上一篇留下的隐患。上一篇结尾让你试着上网查天气，你多半是这么干的：requests.get("https://www.weather.com.cn/...")，拿回来一大坨 HTML，然后……然后就卡住了。
那坨 HTML 是画给人看的：里面除了”沈阳 晴 20°C”，还有一堆导航栏、广告位、脚本代码、样式表。你想拿的就一个数字，却要在几千行字符里大海捞针。更要命的是，网站哪天改个版式，你辛辛苦苦写好的”抠取逻辑”当场报废。
这感觉就像：你想知道饭店今天有什么菜，人家明明有菜单，你却趴在后厨窗户上扒着看厨师炒菜，从油烟里猜今天卖什么。
项目: lobehub/lobehub (原 lobehub/lobe-chat)
Stars: 82k+ | Forks: 15.9k | Commits: 13,000+
定位: 开源 AI Agent 操作平台 —— “Chief Agent Operator”
分析时间: 2026-09
LobeChat 已从最初的”ChatGPT 聊天客户端”演进为 LobeHub —— AI Agent 编排平台。其定位从”对话 UI”升级为”7×24 不打烊的 AI 团队运营者”：自动招募 Agent、调度任务排班、汇总工作报告。这一演进路径清晰地体现在仓库从 lobe-chat 更名为 lobehub，以及 packages 中大量 agent-*、builtin-tool-* 模块的涌现。
核心理念：用户是老板，LobeHub 是首席 Agent 运营官（CAO）。
LobeHub 采用 Turborepo + pnpm workspace 的 Monorepo 架构，分为三大层级：
前36篇的程序再能干，也只在你自己的电脑里打转——读你硬盘上的CSV、写你硬盘上的Excel。可你想查的很多东西根本不在硬盘上：天气在气象网站上，汇率在银行网站上，新闻在新闻网站上。今天给程序接上”网线”，让它自己上网把数据拿回来。今天只引入一个新概念：
requests.get()——程序版的”打开浏览器、输入网址、按回车”
先讲个你肯定干过的事：每天早上打开浏览器，输入”沈阳天气”，看一眼，关掉。或者月底查汇率：打开银行网站，找到汇率页面，一个数字一个数字抄进表格。
一天一次不算什么，但架不住”每天”。这正是咱们从第1篇就念叨的那类活儿：固定动作、有规律、纯手工——最该交给程序的活儿。
可是前36篇的程序干不了这事。你写个程序读CSV，CSV得先在你硬盘上；你写个程序分析Excel，Excel得先下载下来。“上网查”这一步，一直是你这个”人肉搬运工”在干。
项目: camel-ai/camel
GitHub: https://github.com/camel-ai/camel
Stars: 17,600+ | Forks: 2,000+ | 许可证: Apache 2.0
论文: “CAMEL: Communicative Agents for ‘Mind’ Exploration of Large Language Model Society” (NeurIPS 2023)
定位: 第一个 LLM 多智能体框架，专注于发现智能体的规模化定律 (Scaling Laws of Agents)
CAMEL 的核心创新是 角色扮演 (Role-Playing) 协调机制，源自 NeurIPS 2023 论文。其核心问题是：如何让两个 LLM 代理自主协作完成任务，而无需人类持续干预？
Inception Prompting 机制：
关键洞察：无约束的代理对在 2-3 轮对话内就会发生角色反转——助手开始发号施令，用户开始提问，任务失败。CAMEL 通过 系统提示中嵌入 “Never flip roles!” 指令来维持角色一致性，这是一种提示级别的约束而非框架级强制。
第25到35篇学了十样本领：读CSV、读Excel、筛选排序、清洗、合并、分组、导出……可它们是”散装”的，每次都要现想现写。今天把它们串成一条流水线——原料（原始数据）从这头进去，成品（Excel报表）从那头出来，以后每月的报表活儿就是”换数据、按一次回车”。今天只引入一个新概念：把每一步写成函数、按顺序串起来，中间用”行数核对”当质检员
恭喜，你走到了阶段3（文件和数据）的最后一篇。先盘点一下军火库里有什么：
pd.read_csv()——把CSV文件整张吞进程序pd.read_excel()——Excel也照吞不误groupby——按部门/按班级分组报数merge——两张表对上号拼成一张to_excel / ExcelWriter——装订成册交出去单看每一招都不难，可现实世界的活儿从来不是”只用一招”。回忆一下这一个月的剧情：老板先问总量（31），再问明细（32），再问分组对比（33），再让你把订单表和员工表拼起来（34），最后让你导出Excel（35）。每一篇是一道独立的题，而真实工作是十道题连成一套卷。
更扎心的是：这套”卷子”每个月都要重考一次。这个月你东拼西凑写了五十行代码才交出报表，下个月数据一换，你又得从头再来一遍？那不叫学会了，那叫”每次都现学”。
项目: OpenBMB/ChatDev (GitHub ⭐ 34,272)
论文: *ChatDev: Communicative Agents for Software Development* (ACL 2024)
最新版本: ChatDev 2.0 “DevAll” (2026年1月发布)
许可: Apache-2.0
ChatDev 经历了两个截然不同的代际：
chatdev1.0 分支维护。这一演进反映了多 Agent 领域的趋势：从特定场景（软件开发）向通用编排框架的跃迁。
v2.0 的架构分为五层：