Dify开发智能电子书制作工具支持多格式转换

先说结论：想让Dify直接把PDF、Markdown、Word变为EPUB或MOBI电子书？Dify本身确实无法直接完成这个任务。但别担心，我们可以通过自定义工具链为它赋予这项能力。关键在于手动搭建一个清晰的转换流程：先搞定文件格式，再识别章节结构，最后交给转换引擎处理。

说白了，目标很明确：无论你上传的是排版复杂的PDF、带表头的Markdown，还是格式工整的Word，最终都能得到一本结构清晰、自动生成目录、支持中文分章的电子书。这听起来不简单，但利用Dify的自定义工具链，完全可以实现。

先把“转换”这个基建搭起来

万事开头难，但第一步最难的是找一个能真正干活的后端。CorelDRAW还是Adobe全家桶？不，这里有个更轻量的方案：Calibre的命令行工具。它就像电子书格式转换领域的“瑞士军刀”。将其封装成一个简单的HTTP接口，用Docker启动，几乎可以一键搞定：docker run -d -p 8000:8000 -v $(pwd)/calibre:/calibre calibre-web:latest。

这个服务至少需要支持一个POST /convert接口，通过file字段接收文件，通过output_format参数指定输出格式为epub。搭建完成后，建议先用curl测试一下：上传一个test.md，检查响应头是否为Content-Type: application/epub+zip。如果返回HTML页面或404错误，通常是API路由未正确配置。别着急，要么调整容器内的Nginx配置，要么直接用Flask写一个简易服务来替代。

把“工具”注册进Dify

服务运行起来后，接下来去Dify中注册它。操作路径很简单：登录Dify控制台 → 进入「Agent」→「Tools」→「+ Add Tool」→ 选择「HTTP API」类型。

填写工具名称和简介。例如Tool Name设为“EbookConverter”，Description写为“专为PDF、MD、DOCX准备的格式转换器，支持自动识别章节标题”。

然后，最关键的一步：粘贴OpenAPI 3.0的JSON描述。其中有一项必须正确填写，否则后续会踩坑。需要特别强调的是，file字段的format必须声明为binary。为什么？因为如果不这样做，Dify发送请求时会把文件内容当作普通文本字符串发送，Calibre收到后无法解析，必然失败。因此，【file字段必须声明format: binary，否则Dify上传时会把文件内容当纯文本发送，导致Calibre解析失败】。其他如output_format（枚举["epub", "mobi"]）、title（可选，用于封面）等按需填写即可。

验证方式选择“No Auth”，URL填写你的服务地址。本地调试时使用http://host.docker.internal:8000/convert，部署到公网则填写对应的公网地址。保存后，触发一次测试请求，确认返回状态码为200，并且响应体为二进制EPUB数据。到这一步，工具就注册成功了。

关键环节：构建智能的格式识别与处理流程

工具就位，但直接调用还不够智能。我们需要让流程能自动判断原始文档的结构。这里提供两个实用方法。

方法一：Dify工作流串联法

第一步，添加一个「Text Extractor」工具，从PDF或DOCX中提取纯文本。这一步不仅能获取文本内容，还能顺便识别原始文件的格式类型，例如通过文件扩展名来判断。

第二步，接一个「LLM Node」。给这个LLM明确的指令，例如：“仔细分析文本结构，找出所有符合‘第X章’‘## 第一节’或‘CHAPTER ONE’模式的标题行。最终以JSON数组形式输出，每个JSON对象包含level（1-3级）、text和start_line。如果找不到明显的章节结构，就返回空数组。”

第三步，用「Condition Router」做决策。检查上一步生成的JSON数组长度，如果章节数量大于等于3，说明结构清晰，就调用「EbookConverter」并传入toc_auto: false参数，手动指定目录；否则，跳过目录生成，直接进行简单转换。

方法二：Python函数工具统一处理法

如果你想绕过Dify内部复杂的二进制序列化，更直接地控制流程，可以使用一个Python函数工具来处理。思路很简单：在自定义工具中编写一段Python代码，使用python-docx、pypdf2或Markdown解析库读取原始文件。然后，用正则表达式匹配中文章节标题，比如“第[一二三四五六七八九十]+[章节卷]”这种。匹配成功后，再调用本地安装的Calibre命令行工具直接生成EPUB，最后将结果进行base64编码后返回。这样做的好处是减少Dify对二进制文件处理时的损耗。

不过需要提醒：这种方法要求Dify服务器上已安装对应的Python依赖库。而且，你一定要把函数的执行超时时间设置得长一些，建议至少120秒。为什么？因为PDF转EPUB时，如果文档中包含较大的图片，重采样过程经常会卡住，需要给它留足处理时间。

让Agent知道该做什么

最后一步，配置Agent的行为逻辑。新建一个Agent，模型推荐选择GLM-4或Qwen2.5-72B，它们的长文本理解能力更强。然后，关闭「Enable retrieval」，因为电子书转换这件事本身不依赖知识库。

在Prompt中写死约束条件，非常直接：

“你只能做两件事：① 当用户上传文件时，二话不说，立刻调用EbookConverter工具进行转换；② 当用户问‘怎么用’‘支持什么格式’这类问题时，简洁地回答支持PDF、DOCX、MD三种，并特别强调不支持扫描版PDF。”

一切都配置好之后，上传一个测试文件。打开调试面板，查看Tool Call日志。如果能清晰地看到"file": "data:application/pdf;base64,..."这样的请求，并且后续收到content_type: "application/epub+zip"的响应，那么恭喜你，这条自定义链路已经全线贯通了。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：Dify开发智能电子书制作工具支持多格式转换要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题