OKOK大家好欢迎大家来到大鹏 AI 教育我是张大鹏。这几天我做了一件事重新把 Dify 看了一遍。不是那种“打开官网看几张截图读一遍功能介绍”的看法。我是把 GitHub 上的 RuyiDify 仓库拉下来真的去看它的目录、看它的前后端分层、看它把 Agent、RAG、Workflow、模型管理和部署这些东西放在了什么位置。看完以后我心里有一个很明确的判断这件事可以做成一门课。而且不是那种“教你点几个按钮搭一个应用”的工具课而是一门真正围绕智能体工程交付展开的实战课。我这次重新看 Dify脑子里其实一直有三个问题它能不能作为主线项目不是做一两个小案例而是撑起一门完整课程。️它有没有真实工程复杂度能不能讲清前端、后端、Agent、RAG、部署这些真实问题。它能不能沉淀成长期资产课程、实战仓库、模板、交付方案能不能顺着一条线长出来。我为什么突然重新看 Dify这几年我做 AI 课程有一个感受越来越强烈。很多人学 AI最开始都很兴奋。 今天搭一个聊天机器人。 明天接一个知识库。 后天试一下工作流。✅ 每一步看起来都有结果界面也能跑回答也能出来。但再往后走就卡住了。卡在哪里卡在“我会用”但“我不知道它里面怎么运转”。这些问题只靠点界面是解决不了的知识库问答为什么有时候答得准有时候又一本正经地胡说Agent 工具调用为什么有时候能调用工具有时候就停在原地工作流节点为什么 Demo 里很顺一到真实资料就各种边界问题线上交付为什么本机能跑换一台机器就开始报错所以我一直想找一个项目把“会用 AI 工具”和“会交付 AI 系统”之间这段路讲清楚。这就是我重新看 Dify 的原因。我打开 RuyiDify 时先看的不是功能我没有先去看它能不能搭一个漂亮应用。我先看的是项目骨架。RuyiDify 仓库一打开我看到的是一个完整的大项目而不是一个薄薄的 Demo。我先看的是这些关键目录api后端 API。项目说明里写得很清楚后端是 Python Flask 应用而且按领域驱动和清晰架构来组织。️web前端 Web。Next.js、TypeScript、React不是几页简单表单。dify-agent智能体后端服务专门处理 agent 的管理和执行。docker容器化部署配置说明这个项目不是只准备在开发机上玩。cli命令行相关能力后续很适合做自动化和工程化延伸。packages、sdks、e2e、docs配套包、SDK、端到端测试和文档说明它有完整生态的影子。这些目录摆在一起我马上就知道这不是一个适合“十分钟速成”的项目。它更适合做长期拆解。也正因为这样它适合做课。真正打动我的是它的工程味我看一个开源项目适不适合做教学通常不只看它火不火。火当然重要但火不代表适合教。我一般会从这几个角度判断火不火这决定学员有没有兴趣但不是唯一标准。结构稳不稳结构太散讲起来就容易变成资料堆砌。深度够不够工程深度不够就只能做小实验。路线清不清如果不能拆成阶段和章节再好的项目也不好教。Dify 打动我的地方是它已经有很明显的工程味。比如后端api/AGENTS.md里有一条要求改后端代码之前要读周围的 docstring 和注释因为这些说明本身就是规格的一部分。这句话我很喜欢。因为我见过太多初学者改项目上来就是搜关键词找到一个函数改两行跑一下能过就觉得完成了。在真实系统里这种改法很危险。一个接口背后可能连着租户隔离、数据库事务、异步任务、外部存储、模型调用和日志。你只看眼前两行代码很容易把系统改坏。Dify 的后端规则里有几类边界特别值得讲控制器边界控制器负责解析输入、调用服务、返回响应不应该塞业务逻辑。服务层边界服务层协调仓储、Provider 和后台任务不能散成一堆临时调用。租户边界查询和写入都要注意tenant_id这是真实 SaaS 系统绕不开的问题。⏱️异步边界Celery 和 Redis 不是装饰品很多 AI 任务本来就不是同步小接口能扛住的。⚙️配置边界配置要走统一入口不能想起一个环境变量就随手读一个。它不是在教你写一个接口而是在提醒你AI 应用一旦进入产品级就不是“调一下大模型”这么简单。这正是我想讲给学员听的东西。前端也不是“把页面画出来”这么简单然后我去看web/AGENTS.md。前端这边同样让我确认了一件事Dify 不是一个只有页面的项目它是一个真正的产品。前端规则里我看到的是另一种复杂度文案国际化用户可见文案要走 i18n不是随手写死在页面里。组件体系overlay 组件要使用统一的langgenius/dify-ui。设计资产图标、设计 token、圆角映射都有统一约定。状态管理本地状态、Jotai、feature store、本地持久化各有各的位置。我特别注意到 Agent V2 那一段。它要求 Agent V2 和旧的 workflow Agent 分开不要混用旧数据形态后端调用要走生成的 contracts 和consoleQuery、consoleClient不要手写 REST helper不要手写 API 类型。这背后其实是一个很典型的真实产品问题旧能力还在legacy workflow Agent 不能说删就删。新能力要长出来Agent V2 要有自己的目录、契约和状态模型。中间不能乱接不能为了快随手写一个 REST helper 绕过去。以后还要维护今天乱接一下后面课程、二开和升级都会付利息。这不是写一个 React 组件就能解决的问题。如果我把 RuyiDify 做成课我一定不会只讲“这个按钮怎么写”。我会讲为什么这个状态应该归这个模块为什么这个接口不能随手手写为什么 Agent V2 不能和旧 Agent 混在一起。这些判断才是工程能力。我最想拆的是 dify-agent看完整体结构以后我对dify-agent这个目录很感兴趣。现在大家都在说智能体。但很多时候智能体被讲得太玄了会规划、会调用工具、会自己完成任务。我更关心真实执行链路。我最想拆的问题有这些一次 agent run 怎么开始用户点下去以后后端到底创建了什么事件怎么返回前端流式输出、状态变化、错误事件怎么传回来工具失败怎么办工具调用不是永远成功失败路径必须讲清楚。知识库怎么参与知识库、模型、工具和用户输入到底怎么组合前后端怎么对齐前端配置的 Agent V2最后怎么变成后端的一次执行这些问题不拆源码是讲不扎实的。所以 RuyiDify 对我来说不只是一个 Dify 二开仓库。它更像一个智能体工程实验台。我可以带大家从界面走到后端从配置走到执行从“我点了运行”走到“系统到底跑了什么”。这条路才是我真正想教的。我也得承认现在只是起点这里我也要讲实话。我看了课程资料目录我新建了一套课程资料骨架名字叫“如意 Dify 智能体开发实战”。现在这个目录下面已经有几个文件夹中文版️资料❓常见问题错误日志但它还只是骨架。也就是说这门新课还没有正式长出章节内容。这件事不能吹。但它不是从零开始。但它不是从零开始我已经有几类资产可以接上旧课程资料我之前已经整理过一套“大鹏 Dify 开发 AI 智能体”课程资料里面有 10 章内容从大模型到 AI Agent、Dify 开发流程、部署环境、功能应用、工作流节点到几个具体 Agent 案例和云端知识库。配套实战仓库我还准备了 DapengDifyCourse 实战仓库已经按chapter01到chapter10建好结构。真实测试线索第 10 章写了云端知识库 API 的真实测试脚本路线用来走通建库、传文档、等待索引、召回测试这一整套流程。新课程骨架如意 Dify 智能体开发实战目录已经在但章节还没正式长出来。所以我现在要做的不是凭空发明一门课。我是在已有课程资产、已有实战仓库和现在这个 RuyiDify 源码主线之间重新拉一条更硬的路线。我对新旧路线的区分是旧路线学会用 Dify 做智能体。新路线读懂 Dify二开 Dify用 Dify 交付智能体项目。我不会一上来就改代码很多人做二开第一反应是换 Logo、改标题、换颜色。这些事可以做但我不想一上来就做。如果一上来就换皮很容易给自己一种错觉好像项目已经变成自己的了。但真正的二开不是把名字改掉。真正的二开是知道哪里能改哪里不能乱改知道需求应该落在前端、后端、agent 执行层还是只需要改配置知道怎么跟上游保持关系而不是改两周以后再也同步不回去。所以 RuyiDify 的第一阶段我准备做得慢一点先读源码把api、web、dify-agent、docker这些关键层看清楚。▶️先跑通不靠想象能运行的地方尽量真实运行。先记录把路径、命令、错误、判断都留下来。️再二开知道系统边界以后再开始做品牌化、课程化和功能改造。这四步听起来笨但我现在越来越相信做长期项目笨办法反而最稳。这门课最后想训练什么能力如果你只是想知道 Dify 怎么创建应用网上已经有很多教程。但我想做的不是这个。我想训练的是四层能力。这四层能力我准备这样拆第一层会用你能用 Dify 搭出工作流、知识库和 Agent。第二层会解释你能讲清一次提问从前端到后端再到模型、知识库和结果返回中间经过了哪些模块。️第三层会修改你知道一个需求该改哪里知道为什么不能随手绕过现有架构。第四层会交付你能部署、能测试、能写文档、能记录错误日志能把一个 Demo 变成别人真的能使用的东西。RuyiDify 这门课我想训练的就是这四层能力。为什么我觉得这件事值得做我做课程这么久越来越不喜欢纯知识点列表。知识点当然要有但如果没有主线项目学完很容易散。一个好的主线项目我觉得至少要满足几件事有真实复杂度不是三五个文件就讲完。有清楚边界能拆成章节能分阶段推进。能反复复用课程、博客、实战仓库、模板都能围绕它长出来。能继续交付学完以后不是只停在课堂里还能往产品和服务上走。RuyiDify 正好有这个潜力底座成熟背后是 Dify能讲 Workflow、RAG、Agent、模型管理、部署和二开。课程资产已有基础旁边有我已经整理过的 Dify 课程资料和实战仓库。商业延展明确后面还能继续接模板市场、行业智能体和企业知识库项目。它现在还只是起点。但我愿意从这个起点开始。接下来我会把每一步都做成能留下证据的东西看过哪些文件跑过哪些命令踩过哪些坑改过哪些地方为什么这么改。然后再把这些真实记录整理成一门课。不是教大家跟着我点界面。而是带大家一起从 Dify 走到 RuyiDify从会用智能体走到会造智能体。
我重新看了一遍Dify，决定把RuyiDify做成一门实战课
发布时间：2026/7/9 16:10:15
OKOK大家好欢迎大家来到大鹏 AI 教育我是张大鹏。这几天我做了一件事重新把 Dify 看了一遍。不是那种“打开官网看几张截图读一遍功能介绍”的看法。我是把 GitHub 上的 RuyiDify 仓库拉下来真的去看它的目录、看它的前后端分层、看它把 Agent、RAG、Workflow、模型管理和部署这些东西放在了什么位置。看完以后我心里有一个很明确的判断这件事可以做成一门课。而且不是那种“教你点几个按钮搭一个应用”的工具课而是一门真正围绕智能体工程交付展开的实战课。我这次重新看 Dify脑子里其实一直有三个问题它能不能作为主线项目不是做一两个小案例而是撑起一门完整课程。️它有没有真实工程复杂度能不能讲清前端、后端、Agent、RAG、部署这些真实问题。它能不能沉淀成长期资产课程、实战仓库、模板、交付方案能不能顺着一条线长出来。我为什么突然重新看 Dify这几年我做 AI 课程有一个感受越来越强烈。很多人学 AI最开始都很兴奋。 今天搭一个聊天机器人。 明天接一个知识库。 后天试一下工作流。✅ 每一步看起来都有结果界面也能跑回答也能出来。但再往后走就卡住了。卡在哪里卡在“我会用”但“我不知道它里面怎么运转”。这些问题只靠点界面是解决不了的知识库问答为什么有时候答得准有时候又一本正经地胡说Agent 工具调用为什么有时候能调用工具有时候就停在原地工作流节点为什么 Demo 里很顺一到真实资料就各种边界问题线上交付为什么本机能跑换一台机器就开始报错所以我一直想找一个项目把“会用 AI 工具”和“会交付 AI 系统”之间这段路讲清楚。这就是我重新看 Dify 的原因。我打开 RuyiDify 时先看的不是功能我没有先去看它能不能搭一个漂亮应用。我先看的是项目骨架。RuyiDify 仓库一打开我看到的是一个完整的大项目而不是一个薄薄的 Demo。我先看的是这些关键目录api后端 API。项目说明里写得很清楚后端是 Python Flask 应用而且按领域驱动和清晰架构来组织。️web前端 Web。Next.js、TypeScript、React不是几页简单表单。dify-agent智能体后端服务专门处理 agent 的管理和执行。docker容器化部署配置说明这个项目不是只准备在开发机上玩。cli命令行相关能力后续很适合做自动化和工程化延伸。packages、sdks、e2e、docs配套包、SDK、端到端测试和文档说明它有完整生态的影子。这些目录摆在一起我马上就知道这不是一个适合“十分钟速成”的项目。它更适合做长期拆解。也正因为这样它适合做课。真正打动我的是它的工程味我看一个开源项目适不适合做教学通常不只看它火不火。火当然重要但火不代表适合教。我一般会从这几个角度判断火不火这决定学员有没有兴趣但不是唯一标准。结构稳不稳结构太散讲起来就容易变成资料堆砌。深度够不够工程深度不够就只能做小实验。路线清不清如果不能拆成阶段和章节再好的项目也不好教。Dify 打动我的地方是它已经有很明显的工程味。比如后端api/AGENTS.md里有一条要求改后端代码之前要读周围的 docstring 和注释因为这些说明本身就是规格的一部分。这句话我很喜欢。因为我见过太多初学者改项目上来就是搜关键词找到一个函数改两行跑一下能过就觉得完成了。在真实系统里这种改法很危险。一个接口背后可能连着租户隔离、数据库事务、异步任务、外部存储、模型调用和日志。你只看眼前两行代码很容易把系统改坏。Dify 的后端规则里有几类边界特别值得讲控制器边界控制器负责解析输入、调用服务、返回响应不应该塞业务逻辑。服务层边界服务层协调仓储、Provider 和后台任务不能散成一堆临时调用。租户边界查询和写入都要注意tenant_id这是真实 SaaS 系统绕不开的问题。⏱️异步边界Celery 和 Redis 不是装饰品很多 AI 任务本来就不是同步小接口能扛住的。⚙️配置边界配置要走统一入口不能想起一个环境变量就随手读一个。它不是在教你写一个接口而是在提醒你AI 应用一旦进入产品级就不是“调一下大模型”这么简单。这正是我想讲给学员听的东西。前端也不是“把页面画出来”这么简单然后我去看web/AGENTS.md。前端这边同样让我确认了一件事Dify 不是一个只有页面的项目它是一个真正的产品。前端规则里我看到的是另一种复杂度文案国际化用户可见文案要走 i18n不是随手写死在页面里。组件体系overlay 组件要使用统一的langgenius/dify-ui。设计资产图标、设计 token、圆角映射都有统一约定。状态管理本地状态、Jotai、feature store、本地持久化各有各的位置。我特别注意到 Agent V2 那一段。它要求 Agent V2 和旧的 workflow Agent 分开不要混用旧数据形态后端调用要走生成的 contracts 和consoleQuery、consoleClient不要手写 REST helper不要手写 API 类型。这背后其实是一个很典型的真实产品问题旧能力还在legacy workflow Agent 不能说删就删。新能力要长出来Agent V2 要有自己的目录、契约和状态模型。中间不能乱接不能为了快随手写一个 REST helper 绕过去。以后还要维护今天乱接一下后面课程、二开和升级都会付利息。这不是写一个 React 组件就能解决的问题。如果我把 RuyiDify 做成课我一定不会只讲“这个按钮怎么写”。我会讲为什么这个状态应该归这个模块为什么这个接口不能随手手写为什么 Agent V2 不能和旧 Agent 混在一起。这些判断才是工程能力。我最想拆的是 dify-agent看完整体结构以后我对dify-agent这个目录很感兴趣。现在大家都在说智能体。但很多时候智能体被讲得太玄了会规划、会调用工具、会自己完成任务。我更关心真实执行链路。我最想拆的问题有这些一次 agent run 怎么开始用户点下去以后后端到底创建了什么事件怎么返回前端流式输出、状态变化、错误事件怎么传回来工具失败怎么办工具调用不是永远成功失败路径必须讲清楚。知识库怎么参与知识库、模型、工具和用户输入到底怎么组合前后端怎么对齐前端配置的 Agent V2最后怎么变成后端的一次执行这些问题不拆源码是讲不扎实的。所以 RuyiDify 对我来说不只是一个 Dify 二开仓库。它更像一个智能体工程实验台。我可以带大家从界面走到后端从配置走到执行从“我点了运行”走到“系统到底跑了什么”。这条路才是我真正想教的。我也得承认现在只是起点这里我也要讲实话。我看了课程资料目录我新建了一套课程资料骨架名字叫“如意 Dify 智能体开发实战”。现在这个目录下面已经有几个文件夹中文版️资料❓常见问题错误日志但它还只是骨架。也就是说这门新课还没有正式长出章节内容。这件事不能吹。但它不是从零开始。但它不是从零开始我已经有几类资产可以接上旧课程资料我之前已经整理过一套“大鹏 Dify 开发 AI 智能体”课程资料里面有 10 章内容从大模型到 AI Agent、Dify 开发流程、部署环境、功能应用、工作流节点到几个具体 Agent 案例和云端知识库。配套实战仓库我还准备了 DapengDifyCourse 实战仓库已经按chapter01到chapter10建好结构。真实测试线索第 10 章写了云端知识库 API 的真实测试脚本路线用来走通建库、传文档、等待索引、召回测试这一整套流程。新课程骨架如意 Dify 智能体开发实战目录已经在但章节还没正式长出来。所以我现在要做的不是凭空发明一门课。我是在已有课程资产、已有实战仓库和现在这个 RuyiDify 源码主线之间重新拉一条更硬的路线。我对新旧路线的区分是旧路线学会用 Dify 做智能体。新路线读懂 Dify二开 Dify用 Dify 交付智能体项目。我不会一上来就改代码很多人做二开第一反应是换 Logo、改标题、换颜色。这些事可以做但我不想一上来就做。如果一上来就换皮很容易给自己一种错觉好像项目已经变成自己的了。但真正的二开不是把名字改掉。真正的二开是知道哪里能改哪里不能乱改知道需求应该落在前端、后端、agent 执行层还是只需要改配置知道怎么跟上游保持关系而不是改两周以后再也同步不回去。所以 RuyiDify 的第一阶段我准备做得慢一点先读源码把api、web、dify-agent、docker这些关键层看清楚。▶️先跑通不靠想象能运行的地方尽量真实运行。先记录把路径、命令、错误、判断都留下来。️再二开知道系统边界以后再开始做品牌化、课程化和功能改造。这四步听起来笨但我现在越来越相信做长期项目笨办法反而最稳。这门课最后想训练什么能力如果你只是想知道 Dify 怎么创建应用网上已经有很多教程。但我想做的不是这个。我想训练的是四层能力。这四层能力我准备这样拆第一层会用你能用 Dify 搭出工作流、知识库和 Agent。第二层会解释你能讲清一次提问从前端到后端再到模型、知识库和结果返回中间经过了哪些模块。️第三层会修改你知道一个需求该改哪里知道为什么不能随手绕过现有架构。第四层会交付你能部署、能测试、能写文档、能记录错误日志能把一个 Demo 变成别人真的能使用的东西。RuyiDify 这门课我想训练的就是这四层能力。为什么我觉得这件事值得做我做课程这么久越来越不喜欢纯知识点列表。知识点当然要有但如果没有主线项目学完很容易散。一个好的主线项目我觉得至少要满足几件事有真实复杂度不是三五个文件就讲完。有清楚边界能拆成章节能分阶段推进。能反复复用课程、博客、实战仓库、模板都能围绕它长出来。能继续交付学完以后不是只停在课堂里还能往产品和服务上走。RuyiDify 正好有这个潜力底座成熟背后是 Dify能讲 Workflow、RAG、Agent、模型管理、部署和二开。课程资产已有基础旁边有我已经整理过的 Dify 课程资料和实战仓库。商业延展明确后面还能继续接模板市场、行业智能体和企业知识库项目。它现在还只是起点。但我愿意从这个起点开始。接下来我会把每一步都做成能留下证据的东西看过哪些文件跑过哪些命令踩过哪些坑改过哪些地方为什么这么改。然后再把这些真实记录整理成一门课。不是教大家跟着我点界面。而是带大家一起从 Dify 走到 RuyiDify从会用智能体走到会造智能体。
