5 篇博文 含有标签「workflow automation」

是否厌倦了电子书翻译后格式错乱、排版全无的糟糕体验？EPUB Translator 的智能翻译技术不仅完美保留原书的精美版式，更独创双语对照功能，让语言学习变得前所未有的直观高效。

无论是阅读原著小说还是学习专业文献，现在你都能获得精准对齐的双语文本，所有插图、章节和特殊格式都完整保留。原句与译文并排呈现，助你轻松对比学习，就像拥有了一位随时在侧的翻译导师，让跨语言阅读真正成为愉悦的学习之旅。

epub-translator 是一个开源库，采用 AI 大模型自动翻译 EPUB 电子书，并 100% 保留原书的格式、插图、目录和布局。它在 oomol 中封装成了共享区块，可在 oomol 商店中找到。

首先在左侧导航栏进入 Community 页面，搜索 "books rranslator" 模板。这个预置模板包含了所有必要的运行环境和配置，点击 "Use" 按钮即可快速初始化一个新项目。系统会自动创建一个包含 epub-translator 所有依赖的工作空间，完全不需要手动安装任何组件。

项目创建完成后，你会看到一个预设好的工作流界面。点击区块上的 source_file 字段，上传需要翻译的电子书文件，这里支持标准的 epub 格式。

接下来进入关键的参数设置阶段。在语言选择下拉菜单中，你可以在 language 字段指定目标翻译语言，如简体中文、英文或日语等。然后，你需要配置翻译使用何种大语言模型，我们推荐使用DeepSeek Chat作为默认翻译引擎，它在保持文学性和技术准确性方面表现优异。此外，你还可以在 prompt 加入提示此，以告知大语言模型如何处理角色人名和术语之类的注意事项。

翻译过程完全自动化进行，你可以在日志窗口实时查看进度。处理完成后，系统会生成一个全新的双语对照电子书。打开查看时会发现，所有原始格式元素都被完美保留——插图保持在原有位置，特殊字体得到正确渲染，目录结构也自动生成了双语版本。更贴心的是，系统会自动处理电子书内部的各类元数据，确保在新的语言环境下也能正确显示作者、出版社等信息。

Do you also collect a lot of scanned PDF documents? Those academic papers, e-books or work materials, although the content is precious, are very difficult to read - rigid layout, unadjustable fonts, always need to zoom in and out when reading on mobile phones.

Now, these PDFs can be easily converted into comfortable EPUB format through pdf-craft. Just like organizing a pile of paper documents into a portable e-book, you can finally browse these contents in the most suitable way for you on your favorite EPUB reader: adjust the font size, switch to night mode, or even listen to AI reading.

pdf-craft is an open source library dedicated to processing scanned book PDFs. It can accurately identify text content, headers and footers, reference annotations, etc. in PDF files. It can maintain the coherence of cross-page content and restore the correct reading order. In addition, it will use LLM to build a complete EPUB contents structure.

It is very simple to use pdf-craft in oomol. First, create a blank project. Then type "pdf-craft" in the search box in the oomol store to find it.

Drag the “Analyse PDF” and “Generate EPUB” blocks onto the empty flow. Then, connect their output_dir and analysed_dir fields as shown in the figure.

Then, set the pdf field to the PDF source file to be processed, and then set the epub_file_path to the converted EPUB file path. Finally, click the Run button in the upper right corner to start the conversion.

作为开发者，我们每天都在忍受着这样的折磨。明明一个简单的正则表达式就能搞定数据清洗，但工具偏偏只提供基础筛选。想要在流程中插入一个API调用，却发现工具只允许使用预设的集成服务。遇到特殊文件格式处理时，只能眼睁睁看着流程卡死。

这种“看得见需求却够不着解决方案”的无力感，就像给你一把瑞士军刀却把最重要的刀刃焊死了。

在 oomol studio 中，我们重新定义了工作流工具的交互方式，让它真正理解程序员的工作习惯。想象一下，当你正在构建一个数据处理流程时，突然发现需要添加一个特殊的数据转换步骤——这时你可以直接插入一个代码编辑器窗口。这个代码块就像乐高积木一样自然地融入整个流程，与其他可视化节点平起平坐。

写代码的过程就像在熟悉的 IDE 中一样流畅，你可以使用 Python、TypeScript、JavaScript 来写代码。在 oomol studio 中，依赖管理采用容器化方案确保稳定性。当你需要使用第三方库时，可以确保工作流在任何机器上运行时，第三方库的版本和行为都保持一致。不需要用户手动处理虚拟环境或包安装，常用库开箱即用。

我在视频中完整演示了如何用代码插槽快速构建自定义图片处理流程。

当工作流在你的计算机上正常运行时，你是否考虑过将它运行在所有人都可以访问的服务器上，将你的工作成果与他人共享？或者让你的工作流作为一个服务运行在后台，方便你随时调用？

现在你可以用 OOMOL Studio 来达到这一目的。接下来我将详细介绍如何将工作流导出为镜像并运行在后台，我将实现一个翻译 PDF 然后转换为 EPUB 电子书的工作流，这让我可以在我的移动设备上阅读各类外国作家的文献而不用收到语言限制。

具体实现的工作流你可以通过 translate-pdf-to-epub 下载，你可以跟随文章将本文的工作流作为服务运行在你想要的计算机或者云平台上。

阅读该文章需要你具备基础的镜像容器相关知识。

工作流开发​

如果你已经有实现完成的工作流那么可以跳至导出镜像

我们要实现功能可以拆分为以下几个步骤：

1. 将 PDF 文件转换为 epub 文件。
2. 将转换后的 epub 文件翻译。
3. 将翻译后的 epub 文件保存在指定位置。

流程很简单，我们将使用 OOMOL 社区中已有的区块来实现。

首先我们创建了一个 translate-pdf-to-epub 的项目，然后在安装了商店中的以下包：

pdf-craft

books-translator

然后我们分别使用 pdf-craft 包中的 Analys PDF 和 Genrate EPUB 区块，books-translator 包中的 Translate epub book 区块，串联后得到工作流。

工作流已经实现完成，接下来我们为工作流填入参数。我们需要填写以下几个参数：

1. 需要处理的 pdf 文件路径
2. 最终输出 epub 文件的路径

Translate epub book 区块默认的输出语言是中文。如果有需要请自行调整参数。

这里可以清空 output_dir 参数，让中间产物都放在内存中，关闭应用即可释放。

由于 pdf 文件输入需要一个 pdf 地址，所以我们要将需要处理的 pdf 文件放入到 OOMOL Studio 环境中以便应用可以读取。我们在左侧面板中将文件复制到 OOMOL 空间内：

然后我们就可以选择 pdf 文件地址以及输出的 epub 文件地址和后缀名：

接下来我们运行工作流，在一段时间的运行后，我们可以看到成功有文件输出，同时内容已经翻译完成。

可以看到文章被翻译为了中文。

到此为止我们开发并运行了一个工作流，现在工作流只能运行在 OOMOL Studio 应用内，接下来我们要将工作流脱离 OOMOL Studio 的环境并运行起来。

导出镜像​

我们回到OOMOL Studio 的 Home 页面，找到刚才开发完成的工作流，右键单机并选择导出为镜像功能，选择导出的文件夹然后等待一段时间，就可以得到一个与工作流同名的镜像文件。

镜像运行​

在得到镜像文件后，我们使用 docker 命令加载镜像文件。在终端中运行

docker load -i ~/Downloads/translate-pdf-to-epub.tar.zst  # 选择你保存镜像文件的地址

运行完成后可以找到该镜像：

因为镜像的运行环境并不在 OOMOL Studio 内，所以我们无法分辨运行容器的用户是谁，而当前的工作流中使用到了 AI 进行翻译，OOMOL 会将翻译产生的费用折算为积分，使用 API-key 就可以将积分在对应用户的账户中扣除，让工作流正常运行。

如果工作流中用户并没有使用到 AI 之类的内置服务，或者使用了自己的 AI 服务，用户在启动容器的时候仍然需要传入 API-key，但是并不会产生费用。

API-key 可以在 OOMOL Console 中生成一个。

API-key 展示关闭后无法再次获取，请妥善保管。

获取 API-key 后我们可以执行以下命令运行容器:

docker run --privileged -p 3000:3000 -e OOMOL_API_TOKEN={OOMOL_API_TOKEN} -v $HOME/oomol-storage:/oomol-driver/oomol-storage localhost/translate-pdf-to-epub:latest

在运行镜像后，我们就可以通过 http://localhost:3000 访问启动的容器了，此时前面的工作流已经作为一个本地的服务运行了起来。

镜像内的文件地址​

在这个例子中，我们工作流的起点是输入一个文件地址，但是工作流在被导出为镜像后，所有的在镜像容器内的地址都是指在容器内的地址，如果我们直接将宿主机的地址传给工作流，容器内的工作流是无法读取到有效文件的。

这里我们将计算机上的 $HOME/oomol-storage 路径挂载到了容器内的 /oomol-driver/oomol-storage 路径下，这样用户在 $HOME/oomol-storage 路径下添加文件就相当于将文件放在容器内的 /oomol-driver/oomol-storage 文件夹下。这样容器内外就可以通过这个文件夹交换文件。

如果你想要将该镜像部署到云服务器中，也需要满足这个要求，你必须要让容器内的工作流可以访问到真实的文件地址。如果你觉得通过挂载的方式读取文件太麻烦，那么你可以将输入文件路径改为读取一个网络地址，比如上传到 aws a3 服务等网络文件管理服务，然后在你的工作流内下载这个文件并读取。这样文件访问始终在镜像容器内进行，不会存在文件找不到的问题。

调用工作流​

在启动镜像容器后，你就可以通过 http 请求来查询、启动、停止工作流。

访问 http://localhost:3000/ui 你可以看到镜像容器暴露的 http 请求接口：

接口的具体描述可以参考 API 文档。

查询工作流​

使用 GET 方法调用 http://localhost:3000/v1/flows 可以查询容器镜像内的工作流列表。

返回的内容包含了工作流的详细结构，包括节点信息、输入输出接口的名称和类型。

运行任务​

使用 POST 方法调用 http://localhost:3000/v1/tasks 可以运行工作流并创建一个任务。

在工作流开发中我们说过启动工作流前我们需要为几个节点填入参数，这里我们调用请求传入参数：

这里参数的 flowName / nodeId / handle 的信息我们都可以从查询工作流中找到。

这里填写的输入文件地址为 /oomol-driver/oomol-storage/test.pdf，由于我们之前在镜像运行的时候将 /oomol-driver/oomol-storage 文件夹映射到了 $HOME/oomol-storage路径下，所以我们只要将 test.pdf 放入到$HOME/oomol-storage 中，工作流就可以正确读取文件，然后我们将输出文件命名为 local-service-output。

在运行 API 调用后，我们将会得到一个任务 ID。

查询任务​

使用 GET 方法调用 http://localhost:3000/v1/tasks 可以列出所有镜像容器中的任务。

使用 GET 方法调用 http://localhost:3000/v1/tasks/{task_id} 可以通过任务 ID 查询任务的详情。

用户可以通过轮询这两个 api 来查询任务的运行情况。

当任务运行完成后，我们可以查询到任务状态为完成并看到任务的输出结果：

总结​

本文介绍了如何将 OOMOL Studio 的工作流导出为镜像同时脱离 OOMOL Studio 单独运行。

用户可以将镜像部署在任何环境下，成为一个持续运行的服务可以让工作流发挥出最大的作用，无论是在本地服务器、云平台还是团队协作环境中，都能实现自动化流程的高效复用和共享。

引言​

在当今快速发展的数字化时代，自动化工作流已经成为提升生产力的关键工具。从简单的任务连接到复杂的业务流程自动化，各种工具层出不穷，试图满足用户不断增长的自动化需求。然而，随着业务复杂度的提升和定制化需求的增加，传统的工作流工具正在显露其局限性。

在这样的背景下，OOMOL Studio 应运而生，它不仅继承了现有工具的优势，更在关键的技术突破上实现了革命性的进步。通过支持完整的代码环境、本地化运行、镜像导出和完善的开发者体验，OOMOL Studio 正在逐步接近自动化工作流工具的最终形态。

本文将深入探讨自动化工作流的发展历程、当前工具的能力边界，以及 OOMOL Studio 如何通过技术创新成为目前最强大的自动化工作流解决方案。

百花齐放的工具生态​

当今市面上有很多的自动化工作流工具，Zapier / n8n / Dify 等等，每个工具都有相当丰富的社区内容和大量用户。

Zapier 连接 7000+ 以上的应用，n8n 有超过 2000 个模版，Dify 则在 AI 领域站稳了脚跟，还有不断出现其他的工作流工具，总体来说他们都在努力为客户减少工作量，提升工作效率。

自动化工作流就像工厂流水线一样，它将所有生产中的步骤作为一个个可以重复使用的单元并串联起来并自动化运行，达到清晰可控且高效的目的，最终提高客户的生产效率，节省时间。

自动化工作流的演进​

Zapier 将市面上的各种应用作为单元并串联起来，包括各种 AI Agent，对于大多数用户来说，Zapier 连接的数量足够多因此多数简单需求都可以满足，比如读取邮件然后通过 AI 回信，或者是读取一个表格然后给 AI 分析一下表现之类的。很多客户的需求也止步于此，因此 Zapier 就够用了。

这是一种线性的执行过程，一步一步地把工作完成。真实环境下的工作流程可能没那么理想，每个步骤之间并不一定是严格的先后关系，他们之间的联系更加像一张网络，根据需要随时可能跳过某些节点。

但是业务实际上是在不断发展的，真实环境下的需求总是会出现一些变化，当你的目标客户发生了变动，或者工作流中的一个环节的提供商面临倒闭，那会让你不得不调整你的工作流：要么找一家替代的提供商，要么自己实现替代的功能。

大多数客户在将简单需求自动化之后，总会尝试能不能将更复杂多变的任务自动化，没有人不想把自己从重复劳动中解放出来，这种时候，只有固定应用的工作流平台就遇到了麻烦，他们只能让开发者增加一个新的功能，然后发布给用户使用，这个时间通常不会太短。因此Zapier 提供了 Code、Path 之类的功能，希望可以让用户自己解决一些特殊的问题。

所以 n8n 这类工具会声称它们更加灵活，因为他们支持更好的代码编辑体验，同时他们的工作流编排会更复杂，可以应对多变的问题，在 n8n 的工作流可以以自由的方式编排，他们提供了更多的逻辑控制节点比如 if 、switch 等。这些内置工具让工作流更加灵活，各种条件可以让工作流的适用范围变得更广泛。

到这一步是今天市场上大多数工作流工具能做到的极限，他们已经尽可能实现了编程中的多数概念，让流程控制变得非常自由，同时支持代码让用户可以自己满足一些小范围的定制化需求。虽然代码无法依赖第三方模块，但是毕竟在云端运行，这个问题多数人也可以接受。

OOMOL 的技术突破与新可能​

在这个基础上，多数用户已经完成了进一步复杂的业务，那么是不是还会有部分用户有更高阶的需求呢？答案是肯定的，数据分析工程师或者科学家们大量的心血都通过Python 代码实现，他们使用 pandas 或者 numpy 这样的模块来实现目标，所以市面上的工作流基本上无法满足他们的需求。

我们可以发现，市面上的工作流工具为了实现各种情况下的业务，他们把自己变得越来越像编程一样，毕竟程序是图灵完备的，这意味着越接近编程，可以做的事情就越多。这也是为什么现在的工作流工具都引入了代码模块。

那么为什么他们不直接支持完整的编程呢？原因是这些工具在云端运行，想要在云端做到代码编译运行加上代码依赖管理是非常困难的，用户越多，需要隔离的环境就越多，从成本来说就不可能实现。

那么在本地应用支持呢？n8n 在做这方面的努力，但是在各平台同时支持不同语言的运行仍然是一个很艰巨的工作，而且从客观上来说，简单需求占多数，他们只需要实现这部分需求的自动化，然后根据节省用户的时间来适当收费就已经能够盈利了，也许再投入到支持编程的研究中会入不敷出。

那么为什么 OOMOL Studio 还是要做这么困难且未来不确定的事情呢？

现在的工作流工具中充斥着把一个文件转换为另一个格式的文件，或者是根据搜索内容生成一段话发送到社交媒体上之类的任务，你知道这一类任务不可能是客户想要的完整的业务，他们在文件转换为另一个格式之后需要将文件分享或者分析，发送到社交媒体上的话是为了吸引用户获得某些数据或者收益，但是剩下的步骤不是现在的工作流工具可以完成的，它们太过复杂，无法用简单的 if / else 来处理。

所以不是用户不想把业务自动化，而是现在做不到。

因此 OOMOL Studio 支持代码是为了让用户真正实现全部业务的自动化，Python 和 Node.js 社区存在大量开源的各类问题的解决方案，我们希望用户能使用这些已经存在的工具来解决问题，或者让用户可以根据自己的需要亲手构建自动化流程。我们相信真正的高附加值工作一定是相对复杂的，客户能够赚取的利润应该取决于问题的困难程度和节省的时间。

同时本地化运行能够将用户手中的计算资源运用起来，不是所有工作流都需要强大的硬件设备，某些业务虽然复杂，但是一般的计算机完全可以胜任，本地化运行可以为用户节省这部分没有必要的成本。

与完全使用代码实现的区别​

既然代码是图灵完备的，那么为什么不直接写代码而是要使用 OOMOL Studio？

从灵活度上来看，代码毫无疑问是最高的，但是用户要实现的业务目的一定是有时效的，如果通过写代码来实现，那么你需要安装开发环境，选择语言和框架，构建应用，然后发布安装，整个过程作为一个工程来实现。 这对于个人用户来说是非常巨大的工作量，而且如果出现了需求变动，那么上述流程也许要再走一遍。

OOMOL Studio 内置了代码环境，工作流编写完成后，只需填写基本信息就可以直接发布并分享，大大缩短了开发到交付的时间，用户也可以随时调整其中的任意节点，作为工作流工具的优势仍然存在。可以帮助用户快速试错和交付。

结论​

让我们回到自动化工作流工具的终极目标：让绝大部分可以量化的工作都由计算机自动运行，并评估运行结果输出给用户，以此节省大量时间提高人类的生产力。

我们不认为社交媒体上随处可见的"我靠这个工作流自动生成 AI 视频已经赚了数万美元"的文章真的想提高所有人的生产力，他们的目标只是你的咨询费而已，或者更简单只是一个广告。这只是把一个实际问题的最简单部分的自动化流程重复分享传播，实际上他们确实提高了一部分生产力，但是真正困难的事情在于需要让用户手动参与定制的流程。

OOMOL Studio 选择在这条困难的道路上探索，也许我们不是最终正确的方案，但是至少我们做出了一部分努力，就是让想要真正解决复杂问题并自动化的用户可以有机会实现目标。