RAGFlow爬虫组件使用及ragflow vs dify 组件设计对比

上周末，两台电脑都失联了，一个是断网了，一个被我不小心关机。导致我两天没环境。只能整理，学点东西。

上周有个有个群友问我ragflow 爬虫的没法使用的问题。幸好周六早上的时候实践了下。

使用网络爬虫

我搭建一个最简单的工作流。

我点击执行完以后报无法解析，前端报：

我又看了下后端日志报。说需要安装chrome依赖。

An unexpected error occurred: BrowserType.launch: Executable doesn't exist at /root/.cache/ms-playwright/chromium-1134/chrome-linux/chrome
╔════════════════════════════════════════════════════════════╗
║ Looks like Playwright was just installed or updated.       ║
║ Please run the following command to download new browsers: ║
║                                                            ║
║     playwright install                                     ║
║                                                            ║
║ <3 Playwright Team                                         ║
╚════════════════════════════════════════════════════════════╝

我把问题抛给了deepseek，然后它告诉我的方法。

重新构建可以，但是大家基本上都没有环境，直接进入docker操作吧。


# 进入ragflow服务的docker容器
docker exec -it ragflow-server /bin/bash#安装依赖
apt-get update && \ apt-get install -y \ libnss3 \ libnspr4 \ libatk1.0-0 \ libatk-bridge2.0-0 \ libcups2 \ libdrm2 \ libxkbcommon0 \ libxcomposite1 \ libxdamage1 \ libxfixes3 \ libxrandr2 \ libgbm1 \ libasound2# pip国内镜像源设置
pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple# 安装 Playwright 并自动下载浏览器
pip install playwright && playwright install --with-deps chromium# 设置双重镜像加速
export PLAYWRIGHT_DOWNLOAD_HOST="https://npmmirror.com/mirrors/playwright/"
export PLAYWRIGHT_CDN_MIRROR="https://npmmirror.com/mirrors/playwright/"

如果没法执行，建议参考。ragflow想说爱你不容易，win10环境搭建、常用修改中添加国内pip镜像源。

在安装的时候，可能会出现502,是因为官方的源不稳定，替换为清华的即可

# 1. 备份原始源
cp /etc/apt/sources.list /etc/apt/sources.list.bak# 2. 替换为清华源（Ubuntu 22.04）
sed -i 's/archive.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g' /etc/apt/sources.list
sed -i 's/security.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g' /etc/apt/sources.list# 3. 清理缓存并更新
apt-get clean
rm -rf /var/lib/apt/lists/*
apt-get update -o Acquire::CompressionTypes::Order::=gz# 4. 重新安装字体依赖（使用清华源）
apt-get install -y --fix-missing \fonts-noto-color-emoji \fonts-wqy-zenhei \fonts-freefont-ttf \libfreetype6

还有一种情况，安装过程没有明显报错，但是不解析，查看运行结果。

执行成功以后。又用下面的连接进行了尝试，ok。

https://llamafactory.readthedocs.io/zh-cn/latest/getting_started/data_preparation.html

节点设置

网页爬虫的节点设置里，提取类型，可以是markdown、html、文本三种，我们选择markdown即可。

提取完以后，我们可以直接返回对话，也可以使用大模型把进行适当的整理。

需要注意的是：

网页爬虫组件一次只能爬取一个网页，所以要给一个url
不要给爬虫传递上一个节点的信息，要确保只有url

我们可以在这里把所有的页面链接拿到，同提示词特殊处理，把相关的目录链接都拿到，然后再进行迭代处理，整个网页我们就都拿到，对于，然后在用大模型清洗一遍，调用接口保存到ragflow的向量库。是不是就实现了技术文档的采集，以及知识库的整理。

实现原理

然后我就想为什么ragflow的组件不能像dify那样，把输入和输出结构化？我简单的翻了下github上的源码。

在ragflow的agent/canvas.py文件里实现了一个工作流引擎，通过DSL定义组件及其执行流程。主要功能包括：

DSL解析：加载包含组件配置的JSON结构
组件管理：动态实例化组件并建立依赖关系
流程控制：基于路径追踪的顺序执行机制
状态管理：维护对话历史、执行路径等运行时状态

我让ds帮我整理了下对应的流程，流程如下。

ragflow_dify_129">ragflow 和dify的组件基类对比

我又找到了ragflow和dify的组件基类，然后deepseek帮我对比了下。优缺点

ragflow的组件基类地址agent/component/base.py

dify的组件基类地址api/core/workflow/nodes/base/node.py

维度	dify	ragflow
设计目标	工作流节点基类	参数化组件基类
核心优势	类型安全 + 事件驱动	参数管理 + 数据兼容性
性能	轻量级（无第三方库依赖）	较重（依赖pandas）
扩展性	接口扩展	配置扩展
适用场景	事件驱动型工作流系统	数据密集型批处理系统
技术债务	泛型学习成本	pandas依赖 + 递归风险

dify（BaseNode类）优缺点

优点：

类型安全完善
- 使用TypeVar、Generic和严格的类型提示（如NodeRunResult | Generator）
抽象层级清晰

通过@abstractmethod明确定义接口，强制子类实现关键方法（如_run）
分离运行逻辑（run）与核心实现（_run），符合模板方法模式

异常处理健壮

全局捕获异常并封装为NodeRunResult，保证工作流稳定性

扩展性优秀

提供extract_variable_selector_to_variable_mapping等扩展点
支持Generator生成事件流，适应异步场景

代码简洁高效

核心方法（如run）仅30行，无冗余逻辑

缺点：

学习成本较高
- 依赖泛型编程和复杂类型系统，对新手不友好
灵活性受限

节点数据强绑定_node_data_cls，动态配置能力弱

调试难度大

生成器事件流机制增加调试复杂度

ragflowComponentBase_182">ragflow（ComponentBase类）优缺点

优点：

参数管理强大
- 完整的参数生命周期管理（更新/验证/序列化）
- 支持嵌套参数解析（_recursive_update_param）
数据兼容性好

原生支持pd.DataFrame和partial对象
自动处理输入输出格式转换

调试能力完备

内置debug_inputs和详细日志记录
提供get_input_elements等诊断方法

工作流集成度高

通过canvas管理组件依赖关系
自动追踪message_history_window_size

验证机制全面

20+种参数检查方法（check_decimal_float等）
JSON Schema动态校验支持

缺点：

性能瓶颈明显
- 频繁使用pd.concat可能引发内存问题
- 深度递归方法（_recursive_update_param）存在栈溢出风险
代码冗余度高

多个相似静态方法（如check_positive_integer）
硬编码路径（param_validation_path_prefix）

强耦合依赖

深度绑定pandas和settings模块
canvas上下文强依赖增加测试难度

知识库检索组件对比

ragflow的的知识库检索组件agent/component/retrieval.py
dify的知识库检索组件
api/core/workflow/nodes/knowledge_retrieval/knowledge_retrieval_node.py

维度	dify	ragflow
设计范式	工作流节点模式（强调状态流转）	服务组件模式（强调参数配置）
错误处理	多层异常捕获+业务错误分类	依赖基础类异常处理，缺少细粒度错误类型
数据访问	直接操作SQLAlchemy ORM	通过KnowledgebaseService抽象数据访问
性能优化	数据库查询优化+结果缓存机制	依赖向量计算库（如Faiss）优化
扩展性	通过`extract_variable_selector_to_variable_mapping`支持变量映射	通过`LLMBundle`实现模型热插拔
多租户支持	显式传递`tenant_id`	通过`canvas.get_tenant_id()`隐式获取
结果排序	基于分数的手动排序+元数据增强	支持重排模型（Rerank Model）自动优化
外部集成	仅支持内置数据集	集成Tavily API等第三方服务

典型场景对比

场景1：高精度文档检索

# dify实现
results = dataset_retrieval.single_retrieve(planning_strategy=PlanningStrategy.ROUTER,model_config=...  # 精确控制LLM参数
)# ragflow实现
settings.retrievaler.retrieval(rerank_mdl=LLMBundle(...),  # 使用重排模型rank_feature=label_question(...)  # 特征工程
)

对比结论：

dify更适合需要精细控制大模型行为的场景
ragflow在自动化结果优化方面更胜一筹

场景2：多源数据融合

# dify处理外部文档
for item in external_documents:source = {"metadata": {"_source": "external", ...}}# ragflow混合检索
kbinfos["chunks"].extend(tav_res["chunks"])  # 整合网络结果

对比结论：

dify采用硬编码处理逻辑，扩展性受限
ragflow通过参数驱动实现灵活的数据源组合

后记

对于结果的对比，我不做评判，因为个人都有自己的喜好和习惯。大家参考大模型的对比来即可。

系列文档：

DeepSeek本地部署相关

ollama+deepseek本地部署

局域网或断网环境下安装DeepSeek

vlllm部署deepseek基准测试

DeepSeek个人应用

不要浪费deepseek的算力了，DeepSeek提示词库指南

服务器繁忙，电脑配置太低，别急deepseek满血版来了

DeepSeek+本地知识库：真的太香了(修订版)

DeepSeek+本地知识库：真是太香了（企业方案）

deepseek一键生成小红书爆款内容，排版下载全自动！睡后收入不是梦

最轻量级的deepseek应用，支持联网和知识库

当我把公众号作为知识库塞进了智能体后

个人神级知识库DeepSeek+ima 个人学习神器

dify相关

DeepSeek+dify 本地知识库：真的太香了

Deepseek+Dify本地知识库相关问题汇总

dify的sandbox机制，安全隔离限制

DeepSeek+dify 本地知识库：高级应用Agent+工作流

DeepSeek+dify知识库，查询数据库的两种方式（api+直连）

DeepSeek+dify 工作流应用,自然语言查询数据库信息并展示

聊聊dify权限验证的三种方案及实现

dify1.0.0版本升级及新功能预览

ragflow_336">ragflow相关

DeepSeek+ragflow构建企业知识库：突然觉的dify不香了（1）

DeepSeek+ragflow构建企业知识库之工作流，突然觉的dify又香了

DeepSeek+ragflow构建企业知识库：高级应用篇，越折腾越觉得ragflow好玩

模型微调相关

模型微调之基础篇：模型微调概念以及微调框架

📢【三连好运 福利拉满】📢🌟 若本日推送有收获：
👍 点赞 → 小手一抖，bug没有
📌 在看 → 一点扩散，知识璀璨
📥 收藏 → 代码永驻，防止迷路
📤 分享 → 传递战友，功德+999
🔔 关注 → 关注5ycode，追更不迷路，干货永同步💬 若有槽点想输出：
👉 评论区已铺好红毯，等你来战！