Awesome-Dify-Workflow 实战指南：Dify 工作流 DSL 的目录导航、源码级拆解与排错手册

• 示例工程

本篇技术指南以开源仓库 Awesome-Dify-Workflow 的英文主文档（README_EN.md，与 README.md 互为双语版本）为核心，全面讲解该仓库沉淀的 Dify 工作流资产：如何按版本前提导入 DSL、如何根据目录索引快速定位所需 Workflow、五个代表性工作流的源码级实现细节，以及维护者在长期实践中沉淀的十余条常见问题速查。读完本文，你将掌握从「复制 DSL 文件 URL 导入 Dify」到「读懂并改造他人工作流节点逻辑」的完整闭环，并能独立处理沙箱依赖、字符串超限、知识库排队等高频运维问题。

一、项目定位与导入版本前提

Awesome-Dify-Workflow 是一个专门收集、整理「好用 Dify 工作流」的开源仓库，定位是自用与学习两相宜：所有 DSL 基本都可免费使用，同时持续收录、更新新流程。

在使用前，有两个必须明确的版本前提（来源：README_EN.md）：

1. 请使用 Dify 0.13.0 及以上版本导入。该版本线开始支持任务并行（parallel tasks）、会话变量（session variables）、表单（forms）、ECharts 渲染等特性；
2. Agent 节点是 Dify 1.0 之后的功能，涉及 Agent 节点的流程（如Agent工具调用.yml、旅行Demo.yml、Demo-tod_agent.yml）请尽可能使用最新版 Dify 导入。

所有 DSL 均为工作流模式（workflow mode），可以方便地发布为工具（Tool）后嵌入 ChatBot 流程；工作流内部会包含基础的输入节点、条件判断、变量聚合器、输出等组件（见 README_EN.md）。

二、DSL 目录：按分类与更新批次快速定位工作流

仓库的导用方式是：参考表格中每个 yml 的描述 → 在 DSL 文件夹中找到对应文件 → 复制文件的 URL → 导入自己的 Dify 账号。目录按「更新批次 + 主题分类」组织，下表完整保留了原文档的分类清单。

2.1 最新更新批次（2025-04 至 2024-11）

补充：仓库 DSL 目录中还存放了未列入英文版表格的部分流程（如AgentFlow.yml、MCP.yml、思考助手.yml、瞎说新语v2.yml等），中文版 README.md 的更新记录更为完整，可交叉查阅。

2.2 翻译类（Translation）

2.3 工具类（Tools）

2.4 聊天机器人类（Chatbots）与代码类（Code）

三、代表性工作流源码级拆解

本节选取目录中的核心流程，直接阅读仓库 DSL 目录下的 YAML 源文件，从节点拓扑、提示词与代码三个层面还原实现原理，方便你「看懂别人的流程」并加以改造。

3.1 translation_workflow.yml：Agentic Workflow 的四段式翻译流水线

文件：DSL/translation_workflow.yml。其拓扑（见 L127-L453）为：

开始(4参数) → TRANSLATION(LLM) → COUNTRY IS NULL(if-else) ├─ true → EXPERT_SUGGESTIONS(LLM) └─ false → EXPERT_SUGGESTIONS_WITH_COUNTRY(LLM) → SUGGESTIONS(变量聚合器) → IMPROVE_TRANSLATE(LLM) → 结束

关键实现要点：

• 输入参数（L133-L157）：source_lang（文本输入，最大 48 字符，必填）、target_lang（文本输入，必填）、country（文本输入，可选）、source_text（段落输入，最大 50000 字符，必填）。其中country可选是后续分支的关键；
• 第一段 TRANSLATION（L171-L217）：系统提示词声明「You are an expert linguist」，用户提示词要求只输出译文、不附加解释，模型使用deepseek-chat、temperature: 1；
• 分支判断（L218-L247）：if-else节点通过comparison_operator: empty判断country是否为空，从而决定走「带国家」还是「不带国家」的专家建议路径；
• 两条专家建议路径（L248-L353）：二者提示词几乎一致，区别是EXPERT_SUGGESTIONS_WITH_COUNTRY额外要求「最终风格与语气匹配目标语言在指定国家（country）的口语表达」，并约定用 XML 标签<SOURCE_TEXT>、<TRANSLATION>包裹原文与初稿；审查维度固定为四条：准确性（accuracy）、流畅度（fluency）、风格（style）、术语（terminology）；
• 变量聚合器 SUGGESTIONS（L354-L377）：output_type: string，把两个 LLM 分支的text输出聚合成单一字符串；
• 最终润色 IMPROVE_TRANSLATE（L378-L430）：以<SOURCE_TEXT>、<TRANSLATION>、<EXPERT_SUGGESTIONS>三个 XML 标签同时喂入原文、初稿与专家建议，要求按五类错误（增译/误译/漏译、语法、风格、术语、其他）编辑译文，只输出新译文。

从该文件可以直观看出「Agentic Workflow」的典型形态：初译 → 反思（专家审阅）→ 修订，且温度从 1.0（初译）降到 0.7（建议与修订），兼顾创造性表达与输出稳定性。

3.2 中译英.yml：宝玉三步翻译 Prompt 的最小落地

文件：DSL/中译英.yml。拓扑极为精简：开始(content) → LLM → 结束，核心全部封装在单个 LLM 节点的系统提示词中（L93-L135）：

1. 直译：保持原有 Markdown 格式，不遗漏任何信息；
2. 反思：基于直译结果指出具体问题（不符合英文表达习惯、语句不通顺、晦涩难懂等），要求准确描述、不做笼统表示；
3. 意译：综合前两步重新意译，保证原意基础上更符合英文科研论文表达习惯，同时保持原有格式不变。

提示词还内置了术语对照表（如 零样本 → Zero-shot、少样本 → Few-shot），并要求按固定模板输出三段（### 直译/### 问题/### 意译）。该流程使用deepseek-chat、temperature: 1.1（L87-L91），可整体迁移到任意支持长上下文的模型。

3.3 json_translate.yml：迭代器驱动的结构化 JSON 批量翻译

文件：DSL/json_translate.yml。这是「代码节点 + 迭代器 + 内置工具」配合的典型范例，拓扑为：

开始(json_data) → 抽取(code) → 迭代(解析(code) → 翻译(tool) → 合并(code)) → 组装(code) → 结束

• 抽取节点（L164-L196）：递归遍历 JSON，收集所有「可翻译文本」。判定逻辑值得复用到其他流程：
  • 数字类型与非字符串类型直接跳过；
  • 通过正则黑名单过滤不可翻译项：颜色代码^#[0-9A-Fa-f]{3,8}$、纯数字、UUID^[0-9a-fA-F-]{36}$、URL^https?://、IP 地址、日期数字、邮箱等；
  • 至少含一个中文字符或字母才判定为可翻译。
  • 输出结构为items_to_translate（array[object]），每个元素含path（从根到值的路径数组）与text；
• 迭代器（L224-L255）：iterator_selector指向抽取.items_to_translate，is_parallel: false、parallel_nums: 10、error_handle_mode: terminated；内部依次执行「解析（取出 item 的 path/text）→ 翻译（内置 google_translate 工具，dest: en）→ 合并（把translated_text写回 item）」；
• 组装节点（L387-L402）：update_json_with_translations深拷贝原始 JSON，按每个 item 的path逐级定位（列表索引需从字符串转回整数）并回填译文，最后json.dumps(..., ensure_ascii=False, indent=2)输出格式化结果。

这套「抽离可翻译项 → 迭代翻译 → 按路径回填」的架构，可轻松替换翻译工具为 LLM 节点或企业翻译 API，是处理 i18n 语言包、配置文件的通用模板。

3.4 json-repair.yml：非标准 JSON 的自动修复

文件：DSL/json-repair.yml。拓扑为开始(llm_string) → 代码执行 → 结束（L36-L138）：

• 开始节点定义llm_string段落输入，最大长度 10000 字符（L60-L71）；
• 代码节点核心逻辑（L86-L88）：

import json_repair import json def main(llm_string): new_string = json_repair.repair_json(llm_string, ensure_ascii=False) return { "result": new_string }

即调用 Python 的json_repair库对 LLM 输出做容错修复（缺引号、多括号、未闭合等），ensure_ascii=False保证中文不被转义。注意：该流程依赖沙箱中已安装json_repair库（安装方式见下文第五节）。

3.5 matplotlib.yml：Base64 图片渲染的完整链路

文件：DSL/matplotlib.yml，其mode为advanced-chat（L5）。拓扑：开始 → 代码执行 → 直接回复。

• 代码节点（L122-L136）有两个值得注意的细节：
  • 首行Path.home = lambda: Path("/dependencies/home")：官方沙箱的HOME权限复杂，通过重定向Path.home绕过 matplotlib 写缓存目录的权限问题；
  • 绘图后plt.savefig(buffer, format='png', dpi=100)写入内存缓冲区，再用base64.b64encode(...).decode('utf-8')转为 Base64 字符串；
• 回复节点（L100-L103）通过 Markdown 内嵌 data URI 渲染：

描述文本

这套「画图 → Base64 → data URI 渲染」的思路同样适用于 ECharts 图表、PDF 预览等场景。

3.6 图文知识库：让检索结果「图配文」

文件：DSL/图文知识库，内含图文知识库.yml 与配套 Markdown 文档（如 知识库内容/coffbox开启Gemini和Anthropic代理，chatwise连接方法.md）。核心思路是：在知识库文档中加入图片的远程 URL，检索召回时即可呈现图文配文效果；若仅有本地 Word 图文、没有远程图片服务器，则需要额外方案（仓库中文版 README 提供了对应帖子链接）。

四、常见问题速查（来自维护者一线解答）

原文档维护者在交流群中沉淀了一批高频问题，以下完整收录（详见 README_EN.md）：

1. Dify 国内镜像源配置：可把镜像链接前缀统一加上dockerpull.org；
2. 沙箱安装 pandas 等第三方库：打开/docker/volumes/sandbox/dependencies/python-requirements.txt，填入所需依赖后重启沙箱；
3. 定时执行某个工作流：可参考 dify-schedule 项目（实现周期性触发）；
4. 节点间传递 string 数据提示超限制：修改.env中的两个参数后重启容器——

   CODE_MAX_STRING_LENGTH: 1000000 TEMPLATE_TRANSFORM_MAX_LENGTH: 1000000

5. 拿到图片 URL 无法在聊天窗口渲染：Markdown 写法本身正确，通常是图片不支持跨域请求（CORS）导致无法加载；
6. 知识库上传大文件报错：仅修改 Dify 配置还不够，还需在.env中搜索nginx相关配置一并调整（Nginx 上传大小限制）；
7. 知识库永久排队：修改.env中LOG_FILE=/app/logs/server.log，然后重启容器；
8. 自学 Dify 的途径：可参考 dify101.com 等学习资料；
9. Dify 生成图表的方案：Dify 自带柱状图、折线图等绘图功能；也可自写 ECharts 插件，从数据库读取数据绘图；
10. DuckDuckGo 翻译不可用：多半是服务器挂了代理而 Dify 容器内未挂代理所致；
11. 官方示例应用切换中文：右上角头像 → 设置 → 语言，先切换为其他语言再切回中文即可；
12. 忘记管理员密码：执行

    docker exec -it docker-api-1 flask reset-password

五、沙箱依赖与 dify-sandbox-py

仓库英文版明确提示：在官方沙箱中运行pandas、numpy>2.0、matplotlib、scikit-learn代码时经常报错（典型如error: operation not permitted）。维护者为此开发了简化版沙箱dify-sandbox-py，上述依赖已实测可用，需要运行matplotlib.yml、jieba.yml、File_read.yml、runLLMCode.yml、数据分析.7z等流程时建议替换使用（相关背景见 README_EN.md）。

若仅需在既有沙箱中补充依赖，按上文 FAQ 第 2 条操作即可：编辑python-requirements.txt后重启沙箱容器。

六、Dify 1.0 插件体系与离线安装

插件是 Dify 1.0 最大的更新点。仓库维护者建立了 dify_plugin_collection 仓库，存放 Dify 官方插件市场的安装包，方便离线用户自由选择下载、不定期更新（见 README_EN.md）。

若希望开发插件，维护者开源了多款插件源码作为参考：

• google translate：属 Tool 插件，代码量很少，适合入门理解 Dify 插件文件结构；
• conversation Agent（tod_agent）：属 Agent strategy 插件，Agent 策略抽象了 Dify 的很多能力，玩法多但对开发者要求较高。

仓库内与之配套的 DSL 包括Demo-tod_agent.yml（对话优化 Agent 策略示例）与Agent工具调用.yml（Function Calling 调工具示例），可在导入后直接体验 Agent 节点效果。

七、三步上手：注册 → 添加模型 → 导入 DSL

依据原文档的 Usage 章节（README_EN.md），上手流程如下：

1. 注册 Dify 账号（可使用官方云端服务，免费用户可创建最多 5 个流程）并添加模型（仓库流程示例中常见deepseek-chat，可替换为自建或云端模型）：
2. 获取 DSL 文件：将仓库克隆到本地（git clone https://gitcode.com/GitHub_Trending/aw/Awesome-Dify-Workflow），或在 DSL 目录中定位目标 yml，复制其文件 URL；
3. 导入并微调：在 Dify 中导入 DSL 文件，按需调整模板、提示词或模型参数（如 temperature、max_length）：

导入后即可在工作流画布中查看节点拓扑、运行调试，或将工作流发布为工具嵌入 ChatBot 流程。

八、总结

Awesome-Dify-Workflow 的价值在于：既是一份可以直接导入运行的 Dify 工作流合集，也是一套「高密度」的工程范式样板。从本文的源码级拆解可以看到：

• 翻译类流程沉淀了「初译 → 专家反思 → 修订」的 Agentic 模式（translation_workflow.yml）与单节点三步 Prompt 模式（中译英.yml）；
• 数据处理类流程示范了代码节点与迭代器的组合（json_translate.yml）、非标 JSON 修复（json-repair.yml）、Base64 图片渲染（matplotlib.yml）；
• 使用层面，则可以通过 FAQ 速查表快速解决沙箱依赖、参数超限、知识库排队等运维问题。

建议新手按「目录导航 → 导入运行 → 对照源码拆解 → 动手改造」的路径使用本仓库，即可在较短时间内吃透 Dify 工作流的关键节点类型与编排思想。

• 示例工程