MinerU 插件接入 Dify从单文件 Chat PDF 到批量解析归档 S3 的完整工作流实战【免费下载链接】MinerUTransforms complex documents like PDFs and Office docs into LLM-ready markdown/JSON for your Agentic workflows.项目地址: https://gitcode.com/GitHub_Trending/mi/MinerU本文围绕 MinerU 官方文档中《Dify 插件》一章展开完整继承原文档的两个实战案例单文件解析搭建 Chat PDF 应用、批量解析并上传 S3并结合 MinerU 仓库中的 HTTP API 源码/file_parse、/tasks等端点与表单参数补充插件背后所调用的本地 API 服务细节与参数含义帮助读者在 Dify 中快速搭出可用的文档解析工作流并理解插件输出变量text、full_zip_url与 MinerU 服务端返回结果之间的对应关系。Dify 与 MinerU 插件概述Dify是一个开源的大语言模型LLM应用开发平台旨在简化和加速生成式 AI 应用的创建和部署。它结合了后端即服务BaaS和 LLMOps 的理念为开发者提供了用户友好的界面和强大的工具有效降低了 AI 应用开发的门槛。目前 MinerU 与 Dify 联合研发的MinerU 插件已在 Dify 市场上架Dify 官网与 Dify 插件市场均可找到该插件帮助用户在 Dify 工作流中完成文档解析工作。新版 MinerU Dify 插件亮点v0.4.0完美适配 MinerU2全面兼容 MinerU2 的最新功能释放顶尖的文档解析能力超高灵活性同时支持官方在线 API 和本地化部署的 API并向下兼容 1.x 版本赋能工作流让 Dify 的 Agent 拥有强大的文档“读写”能力轻松处理复杂任务。准备安装插件与配置 API在 Dify 插件页面安装 MinerU 插件私有化部署的 Dify 同理在插件设置中填写 API URL 等信息。关键区别使用官方 API时令牌Token必须提供使用本地部署 API时令牌可不填写。本地 API 背后调用了什么结合仓库源码理解当你选择本地部署 API 时插件实际请求的是 MinerU 自带的 HTTP 服务其入口实现在 fast_api.py 中。从源码可以看到服务对外暴露了以下核心端点这与插件“单文件同步解析 / 批量解析取结果”的工作方式直接对应端点方法作用/file_parsePOST同步解析提交上传文件并等待解析完成在同一次响应中返回最终结果/tasksPOST提交异步解析任务立即返回 task id/tasks/{task_id}GET查询异步任务状态/tasks/{task_id}/resultGET获取异步任务的解析结果未就绪时返回 202失败返回 409/healthGET健康检查任务管理器不可用时返回 503以上端点分别定义在 fast_api.py 中。几个与插件调用相关的细节并发与窗口控制api_protocol.py 定义了API_PROTOCOL_VERSION 2、默认最大并发请求数DEFAULT_MAX_CONCURRENT_REQUESTS 3、处理窗口大小DEFAULT_PROCESSING_WINDOW_SIZE 64即本地 API 服务默认同时处理 3 个解析请求批量工作流中的多文件迭代会按队列顺序消化同步接口的错误语义/file_parse在任务执行失败时返回 409fast_api.py任务管理器不可用时返回 503排查 Dify 中“解析节点报 5xx/4xx”时可对照这些状态码定位问题。插件参数与 API 表单参数的对应关系插件解析节点可配置的参数最终会落到 api_request.py 中parse_request_form定义的 multipart 表单上。几个与插件行为最相关的参数及其默认值参数默认值说明backendhybrid-engine解析后端可选pipeline/vlm-engine/hybrid-engine/vlm-http-client/hybrid-http-client见 backend_options.pylang_list[ch]OCR 语言列表parse_methodauto仅对 pipeline / hybrid 后端生效可选auto/txt/ocrformula_enable/table_enableTrue/True是否启用公式 / 表格解析return_mdTrue在响应中返回 Markdown 内容即插件输出变量text的来源response_format_zipFalse以 ZIP 而非 JSON 返回结果插件的full_zip_url输出与此能力对应start_page_id/end_page_id0/99999PDF 解析页码范围从 0 起也就是说插件的textMarkdown 文本来自服务端按return_mdTrue组装的md_content而full_zip_url完整结果包对应response_format_zip模式下的 ZIP 结果ZIP 打包逻辑见 build_result_dict / create_result_zip。这一对应关系决定了后文中两个案例如何消费插件输出。案例一解析单文件搭建 Chat PDF 应用想借助 AI 与你的文档对话吗跟着下面几步轻松实现一个“文档问答”Chat PDF应用。第一步创建空白应用选择“Chatflow”输入应用名称与描述。第二步选择“开始”节点配置输入变量字段类型选为单文件填写变量名称此处填为input_file支持文档类型选为文档与图片。第三步添加工具节点——MinerU 插件在“开始”节点后添加 MinerU 工具节点用于解析上一步开始节点上传的文件。第四步设置 MinerU 的输入变量将 MinerU 的file输入选择为开始节点添加的input_file。第五步配置 LLM 模型选择“LLM”节点后如果没有模型可用需要单独在插件市场安装示例中使用 Deepseek。“上下文”选择 MinerU 的输出变量textMinerU 解析文档后的 markdown 格式在“SYSTEM”区域根据实际需求填写提示词可填写如“在 Parse Filetext中提取用户的问题答案”。第六步预览并测试点击“预览”上传文件并向机器人提问关于文档的内容即可看到基于解析结果的回答。第七步发布保存并发布你的应用。现在上传一份 PDF 或图片你就可以和它自由对话了。说明该应用的链路为「开始单文件→ MinerU Parse Filetext输出 Markdown→ LLM上下文引用text」。由于 LLM 上下文直接注入 Markdown 全文长文档注意模型上下文长度限制若文件较长可结合服务端start_page_id/end_page_id参数做分页解析。案例二自动化批量处理文档并上传至云端 S3需要处理大量文档并归档MinerU 插件同样能胜任。本案例的链路为开始文件列表→ 迭代MinerU 逐文件解析→ 代码执行结果转 base64→ Botos3上传 S3。第一步安装 botos3 插件在 Dify 插件市场安装 botos3 插件。第二步配置 S3 bucket在 botos3 插件设置中填写 S3 凭证与 bucket 名称等信息。第三步创建工作流开始节点选择字段类型为文件列表填写变量名称此处填为upload_files支持的文档类型选为文档与图片。第四步添加“迭代”在“开始”节点后添加“迭代”并配置迭代内的 MinerU 节点设置迭代的输入为开始节点的upload_files迭代输出节点暂时不填写整个迭代配置完成后再选择 MinerU 节点 Parse File 的full_zip_url作为迭代输出将 MinerU 的输入参数file选择为迭代器的item。第五步增加“代码执行”中间节点转换解析结果代码执行节点的变量契约变量名称需与代码定义一致输入变量text选择 MinerU Parse File 的输出变量textMarkdown 文本uploadFiles选择开始节点的文件列表upload_files用来根据迭代的 index 下标找到对应的原始文件名index迭代的下标索引选择迭代器的index。输出变量fileNameString解析结果文件在 S3 中的对象名base64String待上传内容的 Base64 编码。代码选择 JavaScript原文档同时提供了 Python 版本。原文档中该代码块因来源限制未能完整展示其职责很明确以uploadFiles[index]的原始文件名为基准构造fileName如将原扩展名替换为.md并把text文本编码为base64供 S3 上传。最小实现逻辑等价于function main({ text, uploadFiles, index }) { const baseName uploadFiles[index].name.replace(/\.[^.]$/, ); return { fileName: ${baseName}.md, base64: btoa(unescape(encodeURIComponent(text))) // UTF-8 安全的 base64 }; }注意 Base64 编码需兼容 UTF-8 中文内容直接对多字节字符串做 naive base64 会得到乱码这正是该中间节点存在的意义。第六步配置 Botos3 插件上传内容添加工具节点 Botos3选择“通过 S3 上传 base64”文件 base64选择代码执行节点图中为“转换MINERU MD文本”输出的base64字段S3 对象 key填写文件存储的路径。由于在 botos3 插件配置界面已填写 bucket 名称这里只需填写 bucket 下存储的目录对象名选择代码执行节点的fileName。第七步预览效果连接结束节点至此一个简单的“上传到 S3”的工作流配置完成点击“运行”查看效果。第八步用 Vis3 查看文档运行结束后可通过 Vis3Opendatalab 的 S3 数据可视化工具查看 S3 桶内是否已上传解析后的 md 文件填入 AK/SK 即可直接预览 S3 中的 JSON、图片等数据也支持本地文件。小结与排查建议单文件问答场景核心是让 LLM 上下文引用 MinerU 的text输出链路简单、调试成本低对应服务端return_mdTrue的 Markdown 返回批量归档场景核心是「迭代 item/indexfull_zip_url/text的消费」配合代码执行节点做文件名映射与 Base64 转换最终由 Botos3 落盘 S3API 选型官方在线 API 必须配置 Token本地部署 API 依赖 MinerU 仓库自带的 HTTP 服务fast_api.py默认最大并发为 3见 api_protocol.py批量任务会排队执行属正常现象故障定位Dify 节点报 409 表示解析任务执行失败503 表示服务端任务管理器不可用202 表示异步任务结果尚未就绪均可对照上文端点表在服务端日志中进一步定位。通过本文两个案例你可以在 Dify 中快速获得“文档 → Markdown/ZIP 结果”的自动化能力并利用 MinerU 2.x 的解析后端为下游 Agent、RAG 或归档流程供给结构化数据。【免费下载链接】MinerUTransforms complex documents like PDFs and Office docs into LLM-ready markdown/JSON for your Agentic workflows.项目地址: https://gitcode.com/GitHub_Trending/mi/MinerU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 MinerU 插件接入 Dify：从单文件 Chat PDF 到批量解析归档 S3 的完整工作流实战
MinerU 插件接入 Dify从单文件 Chat PDF 到批量解析归档 S3 的完整工作流实战【免费下载链接】MinerUTransforms complex documents like PDFs and Office docs into LLM-ready markdown/JSON for your Agentic workflows.项目地址: https://gitcode.com/GitHub_Trending/mi/MinerU本文围绕 MinerU 官方文档中《Dify 插件》一章展开完整继承原文档的两个实战案例单文件解析搭建 Chat PDF 应用、批量解析并上传 S3并结合 MinerU 仓库中的 HTTP API 源码/file_parse、/tasks等端点与表单参数补充插件背后所调用的本地 API 服务细节与参数含义帮助读者在 Dify 中快速搭出可用的文档解析工作流并理解插件输出变量text、full_zip_url与 MinerU 服务端返回结果之间的对应关系。Dify 与 MinerU 插件概述Dify是一个开源的大语言模型LLM应用开发平台旨在简化和加速生成式 AI 应用的创建和部署。它结合了后端即服务BaaS和 LLMOps 的理念为开发者提供了用户友好的界面和强大的工具有效降低了 AI 应用开发的门槛。目前 MinerU 与 Dify 联合研发的MinerU 插件已在 Dify 市场上架Dify 官网与 Dify 插件市场均可找到该插件帮助用户在 Dify 工作流中完成文档解析工作。新版 MinerU Dify 插件亮点v0.4.0完美适配 MinerU2全面兼容 MinerU2 的最新功能释放顶尖的文档解析能力超高灵活性同时支持官方在线 API 和本地化部署的 API并向下兼容 1.x 版本赋能工作流让 Dify 的 Agent 拥有强大的文档“读写”能力轻松处理复杂任务。准备安装插件与配置 API在 Dify 插件页面安装 MinerU 插件私有化部署的 Dify 同理在插件设置中填写 API URL 等信息。关键区别使用官方 API时令牌Token必须提供使用本地部署 API时令牌可不填写。本地 API 背后调用了什么结合仓库源码理解当你选择本地部署 API 时插件实际请求的是 MinerU 自带的 HTTP 服务其入口实现在 fast_api.py 中。从源码可以看到服务对外暴露了以下核心端点这与插件“单文件同步解析 / 批量解析取结果”的工作方式直接对应端点方法作用/file_parsePOST同步解析提交上传文件并等待解析完成在同一次响应中返回最终结果/tasksPOST提交异步解析任务立即返回 task id/tasks/{task_id}GET查询异步任务状态/tasks/{task_id}/resultGET获取异步任务的解析结果未就绪时返回 202失败返回 409/healthGET健康检查任务管理器不可用时返回 503以上端点分别定义在 fast_api.py 中。几个与插件调用相关的细节并发与窗口控制api_protocol.py 定义了API_PROTOCOL_VERSION 2、默认最大并发请求数DEFAULT_MAX_CONCURRENT_REQUESTS 3、处理窗口大小DEFAULT_PROCESSING_WINDOW_SIZE 64即本地 API 服务默认同时处理 3 个解析请求批量工作流中的多文件迭代会按队列顺序消化同步接口的错误语义/file_parse在任务执行失败时返回 409fast_api.py任务管理器不可用时返回 503排查 Dify 中“解析节点报 5xx/4xx”时可对照这些状态码定位问题。插件参数与 API 表单参数的对应关系插件解析节点可配置的参数最终会落到 api_request.py 中parse_request_form定义的 multipart 表单上。几个与插件行为最相关的参数及其默认值参数默认值说明backendhybrid-engine解析后端可选pipeline/vlm-engine/hybrid-engine/vlm-http-client/hybrid-http-client见 backend_options.pylang_list[ch]OCR 语言列表parse_methodauto仅对 pipeline / hybrid 后端生效可选auto/txt/ocrformula_enable/table_enableTrue/True是否启用公式 / 表格解析return_mdTrue在响应中返回 Markdown 内容即插件输出变量text的来源response_format_zipFalse以 ZIP 而非 JSON 返回结果插件的full_zip_url输出与此能力对应start_page_id/end_page_id0/99999PDF 解析页码范围从 0 起也就是说插件的textMarkdown 文本来自服务端按return_mdTrue组装的md_content而full_zip_url完整结果包对应response_format_zip模式下的 ZIP 结果ZIP 打包逻辑见 build_result_dict / create_result_zip。这一对应关系决定了后文中两个案例如何消费插件输出。案例一解析单文件搭建 Chat PDF 应用想借助 AI 与你的文档对话吗跟着下面几步轻松实现一个“文档问答”Chat PDF应用。第一步创建空白应用选择“Chatflow”输入应用名称与描述。第二步选择“开始”节点配置输入变量字段类型选为单文件填写变量名称此处填为input_file支持文档类型选为文档与图片。第三步添加工具节点——MinerU 插件在“开始”节点后添加 MinerU 工具节点用于解析上一步开始节点上传的文件。第四步设置 MinerU 的输入变量将 MinerU 的file输入选择为开始节点添加的input_file。第五步配置 LLM 模型选择“LLM”节点后如果没有模型可用需要单独在插件市场安装示例中使用 Deepseek。“上下文”选择 MinerU 的输出变量textMinerU 解析文档后的 markdown 格式在“SYSTEM”区域根据实际需求填写提示词可填写如“在 Parse Filetext中提取用户的问题答案”。第六步预览并测试点击“预览”上传文件并向机器人提问关于文档的内容即可看到基于解析结果的回答。第七步发布保存并发布你的应用。现在上传一份 PDF 或图片你就可以和它自由对话了。说明该应用的链路为「开始单文件→ MinerU Parse Filetext输出 Markdown→ LLM上下文引用text」。由于 LLM 上下文直接注入 Markdown 全文长文档注意模型上下文长度限制若文件较长可结合服务端start_page_id/end_page_id参数做分页解析。案例二自动化批量处理文档并上传至云端 S3需要处理大量文档并归档MinerU 插件同样能胜任。本案例的链路为开始文件列表→ 迭代MinerU 逐文件解析→ 代码执行结果转 base64→ Botos3上传 S3。第一步安装 botos3 插件在 Dify 插件市场安装 botos3 插件。第二步配置 S3 bucket在 botos3 插件设置中填写 S3 凭证与 bucket 名称等信息。第三步创建工作流开始节点选择字段类型为文件列表填写变量名称此处填为upload_files支持的文档类型选为文档与图片。第四步添加“迭代”在“开始”节点后添加“迭代”并配置迭代内的 MinerU 节点设置迭代的输入为开始节点的upload_files迭代输出节点暂时不填写整个迭代配置完成后再选择 MinerU 节点 Parse File 的full_zip_url作为迭代输出将 MinerU 的输入参数file选择为迭代器的item。第五步增加“代码执行”中间节点转换解析结果代码执行节点的变量契约变量名称需与代码定义一致输入变量text选择 MinerU Parse File 的输出变量textMarkdown 文本uploadFiles选择开始节点的文件列表upload_files用来根据迭代的 index 下标找到对应的原始文件名index迭代的下标索引选择迭代器的index。输出变量fileNameString解析结果文件在 S3 中的对象名base64String待上传内容的 Base64 编码。代码选择 JavaScript原文档同时提供了 Python 版本。原文档中该代码块因来源限制未能完整展示其职责很明确以uploadFiles[index]的原始文件名为基准构造fileName如将原扩展名替换为.md并把text文本编码为base64供 S3 上传。最小实现逻辑等价于function main({ text, uploadFiles, index }) { const baseName uploadFiles[index].name.replace(/\.[^.]$/, ); return { fileName: ${baseName}.md, base64: btoa(unescape(encodeURIComponent(text))) // UTF-8 安全的 base64 }; }注意 Base64 编码需兼容 UTF-8 中文内容直接对多字节字符串做 naive base64 会得到乱码这正是该中间节点存在的意义。第六步配置 Botos3 插件上传内容添加工具节点 Botos3选择“通过 S3 上传 base64”文件 base64选择代码执行节点图中为“转换MINERU MD文本”输出的base64字段S3 对象 key填写文件存储的路径。由于在 botos3 插件配置界面已填写 bucket 名称这里只需填写 bucket 下存储的目录对象名选择代码执行节点的fileName。第七步预览效果连接结束节点至此一个简单的“上传到 S3”的工作流配置完成点击“运行”查看效果。第八步用 Vis3 查看文档运行结束后可通过 Vis3Opendatalab 的 S3 数据可视化工具查看 S3 桶内是否已上传解析后的 md 文件填入 AK/SK 即可直接预览 S3 中的 JSON、图片等数据也支持本地文件。小结与排查建议单文件问答场景核心是让 LLM 上下文引用 MinerU 的text输出链路简单、调试成本低对应服务端return_mdTrue的 Markdown 返回批量归档场景核心是「迭代 item/indexfull_zip_url/text的消费」配合代码执行节点做文件名映射与 Base64 转换最终由 Botos3 落盘 S3API 选型官方在线 API 必须配置 Token本地部署 API 依赖 MinerU 仓库自带的 HTTP 服务fast_api.py默认最大并发为 3见 api_protocol.py批量任务会排队执行属正常现象故障定位Dify 节点报 409 表示解析任务执行失败503 表示服务端任务管理器不可用202 表示异步任务结果尚未就绪均可对照上文端点表在服务端日志中进一步定位。通过本文两个案例你可以在 Dify 中快速获得“文档 → Markdown/ZIP 结果”的自动化能力并利用 MinerU 2.x 的解析后端为下游 Agent、RAG 或归档流程供给结构化数据。【免费下载链接】MinerUTransforms complex documents like PDFs and Office docs into LLM-ready markdown/JSON for your Agentic workflows.项目地址: https://gitcode.com/GitHub_Trending/mi/MinerU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考