10-14 使用LangGraph实现一个Agentic Workflow
✅使用LangGraph实现一个Agentic Workflow
我们使用LangGraph实现一个多角色协作的“研究助手”系统,当用户问一个问题(如“AI 对医疗行业有哪些影响?”),系统自动:
Planner Agent:制定研究计划(分几步查什么)
Researcher Agent:按计划搜索信息(模拟调用搜索引擎)
Writer Agent:整合信息写报告
Reviewer Agent:检查报告质量,若不满意则要求重写(形成反思循环)
使用langgraph来实现,初始化环境:
1234567uv init agentic_workflow_testcd agentic_workflow_testuv venvsource .venv/bin/activate
编写main.py中的代码:
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697 ...
10-13 Agentic Workflow
✅Agentic Workflow前面介绍过了传统的Workflow和AI Workflow了,其实现在还有个概念挺火的,那就是Agentic Workflow(智能化工作流),这个概念挺新的,目前没有特别精确的解释,可以参考吴恩达在一次演讲中描述的Agentic Workflow有以下四种模式(范式):
Planning(规划): 让 Agent 分解复杂任务并按计划执行。
Tool Use(工具): LLM 生成代码、调用 API 等工具进行操作。
Reflection(反思): 让 Agent 审视和修正自己生成的输出。
Multiagent Collaboration(多智能体协同): 多个 Agent 扮演不同角色合作完成任务。
也就是说,相比人工提前定义好的一个流程来说,Agentic更加看重的是AI的规划能力,流程是由LLM实时生成的,这样才能实现动态决策和自主优化的效果。
对比一下三种工作流:
Automated Workflow
无LLM节点
通常用传统工作流进行编排,如activiti等。
Ai ...
10-12 Dify & N8N & Coze & FastGPT对比
✅Dify & N8N & Coze & FastGPT对比
Dify、N8N、Coze、FastGPT等都是目前比较常用的一些LLM应用开发平台。包括我们前面介绍过的百炼。
百炼不在我们对比的范围内,因为百炼毕竟是收费的,而且他只能基于百炼上已有的模型使用。灵活度和性价比都不是特别的高。而Dify、N8N这种都是开源的,我们可以完全做定制开发,以及使用私有化模型。灵活性、性价比,包括数据安全性都比较高。
核心定位对比
Column 1
Column 2
Column 3
平台
核心定位
技术基因
Dify
企业级开源 LLM 应用开发平台(LLMOps)
全栈 AI 开发 + RAG + 模型管理
n8n
开源通用工作流自动化引擎
节点驱动 + 跨系统集成 + 可编程自动化
Coze(扣子)
字节推出的零代码对话机器人平台
无代码 Bot 构建 + 多平台发布
FastGPT
开源轻量级知识库问答系统
RAG 优化 + 私有化部署 + OpenAI API 兼容
易用性
Column 1
Column 2
Colum ...
10-11 什么是n8n?
✅什么是n8n?n8n是一款企业级的****开源、可视化、高度可扩展的工作流自动化平台,相比于Dify来说,N8N算是历史悠久了,在没有AI 工作流这个概念的时候,他们就已经在做工作流自动化的事情了,在AI出来之后,就顺理成章的转变成基于AI的工作流的搭建。
所以, 在工作流本身的能力上,N8N要更强一些。尤其是一些第三方的集成上面,N8N甩Dify几条街,毕竟这都是长时间积累下来的(官方支持数百种服务集成)。所以,在N8N中,AI只是他的能力之一,但是不仅仅局限于AI,所以,他也是很多企业级工作流搭建的首选。
n8n 内置超过 300+ 官方节点,支持与主流 SaaS 工具(如 Slack、Google Sheets、Notion、Airtable、Shopify、Discord、Telegram、Zapier Webhooks 等)以及数据库(PostgreSQL、MySQL、MongoDB)、消息队列(RabbitMQ、Kafka)和自定义 HTTP 接口无缝集成。
github:https://github.com/n8n-io/n8n
官网: https://n8 ...
10-10 Dify进阶:API调用
✅Dify进阶:API调用
Dify 不仅支持通过可视化界面。还支持通过 API 调用,Dify 提供了完善的 RESTful API 接口,方便开发者将 Dify 构建的应用集成到自己的系统中。
获取 API Key在 Dify 控制台中:
进入你的应用页面(工作流或者agent等)
点击右上角「访问API」选项卡
获取 API Key
API 调用有了api key了之后,只需要按照页面上给出的文档,替换key,发送http请求就行了。
不同的应用是不同的api key ,他就是通过这个key来路由到具体的应用做调用的。
更多的文档大家可以官方看,不展开说了,很简单:
https://docs.dify.ai/api-reference/%E5%AF%B9%E8%AF%9D%E6%B6%88%E6%81%AF/%E5%8F%91%E9%80%81%E5%AF%B9%E8%AF%9D%E6%B6%88%E6%81%AF
10-09 Dify进阶:插件开发
✅Dify进阶:插件开发Dify提供了插件机制,我们可以基于dify的插件能力开发出我们自己的插件,来丰富工作流的功能。本文演示一个脱敏插件的开发全流程。
使用cursor进行插件开发,在dify官网中给出了dify插件开发的prompt:
https://docs.dify.ai/plugin-dev-zh/0211-getting-started-by-prompt
我们可以把这个当做rules设置个cursor,然后借助cursor帮我们开发一个dify的插件。
开发环境安装开发 Dify 插件需要进行以下准备。本文档是开始插件开发的第一步。
Dify 插件 CLI 工具
Python 环境,版本号 ≥ 3.12
Dify 插件 CLI 工具可以通过 Homebrew(在 Linux 和 macOS 上)或独立的二进制可执行文件(在 Windows、Linux 和 macOS 上)进行安装。(其他安装方式:https://docs.dify.ai/plugin-dev-zh/0221-initialize-development-tools )
1 ...
10-08 Dify进阶:MCP的使用
✅Dify进阶:MCP的使用Dify作为一个 AI 工作流平台,他肯定是支持MCP协议的,这里的支持分为两个方面:
1、支持把一个Dify上面的工作流作为一个MCP Server发布
2、支持在Dify中调用一个MCP Server
在之前的Dify的版本中,想要使用MCP,还是比较麻烦的需要各种插件,但是从Dify 1.6开始,已经支持双向MCP了,即上面的这两种,本文就是基于官方内置的MCP的支持介绍。
发布为MCP Server
如果我们在Dify上部署了一个工作流之后,想要在其他的地方集成他,比如在Cursor中的话,有个好的办法就是把他发布为一个MCP Server,然后在Cursor中使用它。
那就从实际需求出发:我们在cursor中看代码的时候,有的时候,想让cursor帮我们生成一些UML图,比如时序图、类图之类的,这样看起来就方便很多。
这样我们可以在Dify中搭建一个工作流,实现把代码转成UML图,这里我们用一个在大模型兴起之后非常火的mermaid。
mermaid,他是一种基于JavaScript的开源工具,它允许用户使用类似Markd ...
10-07 Dify进阶:RAG的使用
✅Dify进阶:RAG的使用前面我们介绍过RAG,也提到过很多AI的工作流平台也支持RAG,比如Dify。Dify中有一个[知识库],他就是个RAG,能实现从知识库中做向量检索。
知识库创建
知识库的创建一共有三个步骤,选择数据源,文本分段与清洗,处理并完成。
数据源的选择有三种,分别是导入文件、从Notion同步,以及从web站点同步。
前两个比较好理解,第三个很多人不知道是啥,从页面上看,支持两种工具,一个是Jina Reader,另一个是Firecrawl。
Jina Reader和Firecrawl都能能将网页信息转换成LLM 友好的格式,如Markdown,去除冗余HTML 标签和代码,保留核心文本内容,方便LLM 解析和理解。
关于firecrawl,他是个爬虫工具,后面我们再介绍工作流的实战的时候还会用到他。
在知识库导入中,最常用的其实还是导入文本。在这里上传一个文件之后,就会进入第二步,分段与清洗了。
知识库的文档有大小限制,默认是15M,如果想要突破这个限制,需要自己修改配置,如果是自己部署的dify,可以参考:h ...
10-06 基于Dify实现Ai Workflow
✅基于Dify实现Ai Workflow
Anthropic在 《Building Effective Agents》这篇文章中也提了一些关于workflow用来构建智能体系统的一些”范式”。我们借助这几种范式也顺带介绍下工作流的常见搭建方式。
Prompt Chaining提示链模式将任务分解为一系列步骤,每次 LLM 调用都处理前一次 LLM 的输出。你可以在任何中间步骤上添加校验(如示图中的“Gate”),以确保该过程仍运行在正轨上。
如以下方式,我们通过一个LLM链,生成一份公众号文章,三个不同的节点,分别做大纲生成,文章生成以及内容润色。
DSL内容(可直接导入Dify):
PromptChain
ing.yml(6.4 KB)
- 0%
Routing路由模式根据输入类型路由到不同专用处理流程或模型。
在上面的流程中,我们引入一个问题分类器,做用户的意图识别,根据意图分别路由到不同的分支,生成公众号文章或者小红书文案。
DSL内容(可直接导入Dify):
Rout
ing.yml(9.8 KB)
- 0%
Paralle ...
10-05 工作流平台(Dify为例)中的常用组件
✅工作流平台(Dify为例)中的常用组件本文拿 Dify举例,他支持通过可视化工作流(Workflow)来编排复杂的 AI 应用逻辑。在 Dify 的工作流编辑器中,用户可以通过拖拽组件节点的方式,快速构建从用户输入到最终输出的完整流程。
以下是 Dify 工作流中常用的组件及其功能说明。
1. 开始
工作流的入口节点,接收用户输入(如文本、变量等)。他是自动创建的,必须要有的。
可以在输入节点中定义变量,如 query, user_id 等。
2. LLM
调用大模型生成文本,可配置提示词(Prompt)、模型类型(如 qwen、Claude、本地模型等)、可以设置温度、开启记忆等参数。并且支持配置失败重试、异常处理等。
3. 条件分支
类似编程中的 if-else,根据条件判断执行不同路径。
支持分别为if和else配置条件,条件支持很多,包括字符串比较、数值比较、包含判断、为空判断等。
4. 代码执行
可以在这里运行自定义 Python 代码,处理数据或调用外部服务。
输入/输出变量可配置。支持标准库及部分第三方库(如 reque ...
