Awesome-Dify-Workflow 设计模式拆解

从 svcvit/Awesome-Dify-Workflow ↗ 仓库中 46 份可导入 DSL 的真实图拓扑出发，归纳 Dify 工作流里反复出现的编排模式与”节点级配方”，每种模式给出结构特征、仓库范例与图示。把这 46 个工作流拆开看，绝大多数不是”全新发明”，而是少量控制流骨架和一批节点级配方的组合。骨架决定数据怎么走，配方决定单个节点干成什么。

• 控制流骨架（形状决定”步骤怎么排”）：链式、分块迭代(Map)、路由、并行扇出、编排者-执行者、评估-优化循环、会话状态机、Agent 自规划。
• 节点级配方（一个节点承担的真实能力）：代码节点做确定性重活、参数提取器把 LLM 输出结构化成列表喂给迭代器、变量赋值器把上下文写进会话变量、HTTP 请求把渲染/沙箱外包出去、多知识库检索。

决策权转移是理解这些模式的轴线：越靠后的模式，模型在”运行时决定下一步”的比例越高，可控性与成本可估算性越低——这也和常见的 Agent 范式谱系一致（提示链 → 工作流 → 规划型 Agent）。Dify 的好处是每种模式都可以只花少量节点落成图，下面每种模式我都标出了仓库里的对应文件，可在 Dify 中直接导入对照。

分析口径：解析自 2026-09-03 该仓库 HEAD 的 DSL/*.yml，共 46 个工作流。节点中文名按 Dify 节点类型翻译；截图均取自仓库 snapshots/（与 README 表一一对应）。截图已压缩后放于 /images/dify-workflow-patterns/。

1. 仓库长什么样#

仓库按 README 分组 + 按日期追加 组织，DSL 全部放在 DSL/，每个文件是一次 Dify 导出 DSL：

三种读取姿势：

1. 当成作品集：找同场景文件导入改提示词即可（README 每条都注明来源）。
2. 当成模式库：识别每个文件用到的骨架与配方（本文目标），做新流程时”按形状选模板”。
3. 当成 Dify 特性测试集：仓库大量演示了迭代器、会话变量/变量赋值、表单、意图分类、参数提取器、代码节点 + 沙箱、MCP/Agent 等特性，是最新版本能力的可运行样例。

运行依赖提示：部分流程依赖第三方组件——jieba/matplotlib/File_read/runLLMCode 需要换用 dify-sandbox-py ↗；MCP* 需要 Agent/MCP 插件；Artifact 需要 dify-plugin-artifacts ↗；腾讯云SubtitleInfo 需要腾讯云密钥；春联生成器 需要本机中文字体；Dify 运营一条龙 的封面图服务目前已不可用（README 已注明）；翻译长文本需调大 CODE_MAX_STRING_LENGTH 等环境变量。

2. 模式一：单节点内链 —— 把”直译→挑错→意译”写进一条 Prompt#

识别信号：图里只有一个 LLM 节点，Start → LLM → End，但 Prompt 内部是分步骤的”先 A 再 B 再 C，每步打印结果”。

中译英.yml（宝玉 Prompt 的中译英版 ↗）就是标准形态，整条链只有 3 个节点、1 次模型调用：

flowchart LR
  S((开始)) --> P[LLM 单节点<br/>一步直译 · 二步指出问题 · 三步意译]
  P --> E((结束))

我在 DSL 里摘出的真实指令是这样的：

分三步进行翻译工作，并打印每步的结果：
1. 根据中文内容直译成英文，保持原有格式，不要遗漏任何信息
2. 根据第一步直译的结果，指出其中存在的具体问题，要准确描述……
3. 根据第一步直译的结果和第二步指出的问题，重新进行意译……

这不是工作流”链”，而是把反思（Reflect）折叠进一次调用——用打印步骤来强制中间产物可见。它的价值是零工程成本地拿到”自审式”输出；代价是单次调用越长，越容易在中途丢失约束，且中间产物无法被下游复用或修正。当”反思”需要真正影响后续分支时，就该升级为模式五（多节点评估-优化循环）。

仓库范例：DSL/中译英.yml、DSL/宝玉的英译中优化版.yml；同款写法还出现在 DSL/根据用户的意图进行回复.yml 的”意图向量机”节点（四步信息整理后分类）。标题党创作.yml（LLM 出爆款标题 → 代码节点转数组）也是”单 LLM + 一次确定性加工”的形态。

图：DSL/中译英.yml 的整图就 3 个节点，三步都在一条 Prompt 里完成。（源截图 snapshots/Xnip2024-07-24_13-04-11.jpg）

3. 模式二：工具打底 + LLM 打磨（Tool-Assisted Chain）#

识别信号：确定性/低成本工具先做一步（机器直译、搜索、取数据），LLM 只做”最擅长的那段”（润色、归纳、改写），形成 工具 → LLM 的短线链。

DuckDuckGo翻译+LLM二次翻译.yml 是最小实现——用免费翻译引擎替代模式一的”第一步直译”，省 token 且质量稳，LLM 再按宝玉式反思去挑错润色：

flowchart LR
  S((开始)) --> T[工具 · DuckDuckGo 直译]
  T --> L[LLM · 反思与意译润色]
  L --> E((结束))

真实边序（该文件全部 4 节点 3 边）：

开始 → DuckDuckGo 翻译 → LLM → 结束

这也是”搜索大师/Jina Reader/Deep Researcher”类检索流的下半身：机器抓内容，模型做总结，只是多包了一层迭代。该模式教会你一个取舍原则：能用工具换来的第一步，不要用模型烧 token。

图：DuckDuckGo翻译+LLM二次翻译.yml 整图仅 4 节点，工具替掉模式一的”第一步直译”。（源截图 snapshots/Xnip2024-07-16_13-42-06.jpg）

4. 模式三：迭代器 Map —— 切块、逐块处理、合并（Iteration）#

识别信号：图里出现 iteration + iteration-start（循环体）。Dify 的迭代器把上游列表逐项喂进循环体，是处理”长文本/批量任务/JSON 结构”的核心骨架。

全书翻译.yml 把它和模式一结合得最典型：上游 代码节点 把长文切成块 → 迭代器对每一块跑一条 4-LLM 的小链（识别专有名词 → 直译 → 识别问题 → 意译）→ 模板把结果合回整篇：

flowchart LR
  S((开始)) --> C[代码 · 切分长文本]
  C --> I[/迭代器<br/>每个文本块/]
  I --> B1[LLM 识别专有名词]
  B1 --> B2[LLM 直接翻译]
  B2 --> B3[LLM 识别问题]
  B3 --> B4[LLM 意译]
  B4 --> J[模板 · 合并回整篇]
  J --> E((结束))

真实边序印证了”链内嵌在迭代内”：

开始 → 代码执行 → 迭代
  迭代开始 → LLM识别专有名词 → LLM直接翻译 → LLM识别问题 → LLM意译   ← 循环体
迭代 → 模板 → 结束

同一个 Map 骨架可套不同”体内动作”：

关键经验：迭代器吃的”列表”多来自”参数提取器”或”代码节点”的 JSON 转换（见模式十）。json_translate 之所以能保持 JSON 结构，是因为抽 key、翻译、重组三段分别用代码/工具切开了，天然是”按 key 并行翻译再装回”。

图：全书翻译 用代码把长文切成块，迭代器逐块跑 4-LLM 小链。（源截图 snapshots/Xnip2024-10-30_18-02-24.jpg）

5. 模式四：编排者-执行者（Orchestrator-Worker）#

识别信号：一个”拆解者”把任务变成列表，N 个”执行者”分头做，最后”汇总者”收口。与模式三的区别在拆解是否由模型完成——编排者的子任务是运行时由 LLM 决定的。

llm2o1.cn.yml 是串行单执行者版本，边序一目了然：

开始 → LLM任务拆解 → 参数提取(任务提取) → 迭代任务
  迭代开始 → 代码解析任务 → LLM执行任务
迭代任务 → 模板合并结果 → LLM归纳答案 → 直接回复

flowchart LR
  S((开始)) --> D[LLM 任务拆解]
  D --> PE[参数提取 · 任务列表]
  PE --> I[/迭代 · 逐个执行/]
  I --> W[代码解析任务 + LLM 执行单步]
  I --> J[模板 · 合并各步结果]
  J --> F[LLM 归纳出最终答案]
  F --> R((回复))

Deep Researcher On Dify.yml（Deep Research 复现）是并行多执行者的豪华版：先把主问题分解成若干研究角度/子主题，每个子主题跑一条”关键词提取 → 迭代搜索（维基工具 + 知识检索）→ LLM 子主题分析”的小流水，途中用大量 变量赋值 保存各轮上下文与回答记录，最后”总结文档 → 起始段/结尾段 → 回答优化（多轮）“合成最终报告。71 个节点、13 个 LLM、4 个迭代器、11 个变量赋值器，是仓库里最接近”深度研究产品”的编排示范。

flowchart LR
  S((开始)) --> Q[LLM 问题分解<br/>提炼研究角度]
  Q --> V[变量赋值 · 上下文/问题]
  V --> S1[子主题1 · 搜索+分析]
  V --> S2[子主题2 · 搜索+分析]
  V --> S3[子主题3 · 搜索+分析]
  V --> S4[子主题4 · 搜索+分析]
  S1 & S2 & S3 & S4 --> R[LLM 总结文档 · 起止段]
  R --> O[LLM 回答优化]
  O --> A((最终回复))

仓库范例：DSL/llm2o1.cn.yml（串行）、DSL/Deep Researcher On Dify .yml（并行）、DSL/dify_course_demo.yml（大纲→逐章执行，可看作轻量编排者）。

图：Deep Researcher On Dify 的并行多执行者编排。（源截图 snapshots/Xnip2025-02-24_10-12-56.jpg）

6. 模式五：评估者-优化者循环（Evaluator-Optimizer / 自我修正）#

识别信号：同一产物先被”生成”，再被”另一个模型视角检查并重写”，中间常有条件分支决定走哪条检查线，最后用变量聚合器把多条专家意见合流。

translation_workflow.yml（吴恩达 Agentic 翻译）是教科书级例子：先 TRANSLATION 粗翻，按”是否给定目标国家”走不同专家建议线（EXPERT_SUGGESTIONS / EXPERT_SUGGESTIONS_WITH_COUNTRY），两条线经变量聚合器合流后由 IMPORVE_TRANSLATE 吸收意见改写：

flowchart LR
  S((开始)) --> T[LLM TRANSLATION]
  T --> IF{COUNTRY IS NULL?}
  IF -- 是 --> E1[LLM 专家逐句意见]
  IF -- 否 --> E2[LLM 专家意见 + 国家化用语]
  E1 --> AGG[变量聚合 SUGGESTIONS]
  E2 --> AGG
  AGG --> I[LLM IMPROVE_TRANSLATE]
  I --> F((结束))

真实边序（全部 8 节点 8 边）：

开始 → TRANSLATION → 条件分支(COUNTRY IS NULL)
  [true]  → EXPERT_SUGGESTIONS            → 变量聚合 SUGGESTIONS
  [false] → EXPERT_SUGGESTIONS_WITH_COUNTRY → 变量聚合 SUGGESTIONS
变量聚合 SUGGESTIONS → IMPORVE_TRANSLATE → 结束

记忆测试.yml 展示了并行多裁判 + 重写：判定需要 CoT 时，同时让”时间合理性 / 内容合理性 / 上下文一致性”三个 LLM 各自评审，汇合后 LLM 重新输出回复——典型的三裁判并行评估者。Dify 运营一条龙.yml 里也有一个 LLM 转义错误检查 节点在正文生成后做一轮自检。

图：评估-优化循环的”双线专家 + 合流重写”形态。（源截图 snapshots/Xnip2024-07-16_16-58-05.jpg）

7. 模式六：意图路由（Router）+ 汇聚#

识别信号：question-classifier（意图分类）或 if-else 把请求分到互斥分支，各分支产出后经变量聚合器汇合再进统一收尾。和”并行的扇出”不同，路由分支是互斥的。

根据用户的意图进行回复.yml 是”分类器路由 + 变量聚合”的干净样本：意图向量机（LLM 整理聊天/图片→补全意图）→ 问题分类器 分成”健康咨询”与”使用帮助”两类——前者直接 LLM 回复，后者先检索知识库再 LLM 回复——两条路经 变量聚合器 合流，交给 风格化回复内容 统一话术：

flowchart LR
  S((开始)) --> V[LLM 意图向量机<br/>整理四步意图]
  V --> Q{问题分类器}
  Q -- 健康咨询 --> H[LLM 文本健康咨询回复]
  Q -- 使用帮助 --> K[知识检索] --> U[LLM 文本使用帮助回复]
  H --> AGG[变量聚合器]
  U --> AGG
  AGG --> ST[LLM 风格化回复内容]
  ST --> E((结束))

真实边序：

开始 → LLM意图向量机 → 意图分类(问题分类器)
  [健康] → LLM文本健康咨询回复 → 变量聚合器
  [帮助] → 知识检索 → LLM文本使用帮助回复 → 变量聚合器
变量聚合器 → LLM风格化回复内容 → 结束

Document_chat_template.yml 则是”守卫 + 多库路由”：先 if-else 判断要不要检索，要走检索就交给 Question Classifier 在多个知识库之间选路（每个库带各自的提示模板与 LLM 收尾，各分支都有独立 End）。这是企业里”一个入口问 N 套文档”的最省心结构。

图：根据用户的意图进行回复 的分类器路由 + 变量聚合骨架。（源截图 snapshots/WechatIMG4894.jpg）

设计要点：路由后若分支还要继续走同一套收尾，务必像上面那样用变量聚合器汇合再进统一节点，否则每个分支都要复制一遍收尾逻辑。

8. 模式七：知识库问答（RAG 变体）#

严格说 RAG 更像”配方”而非骨架，但这仓库里 RAG 的出现频率高到值得单列。三种变体：

1. 直连式：检索 → LLM → 回答。思考助手.yml（开始 → 知识检索 → LLM → 回复）就是最小可用的 RAG。
2. 图文式：图文知识库 在知识库条目里预置图片远程 URL，检索后以”图配文”输出（README 提供了把 Word 图片转远程 URL 的教程）。
3. 路由式：见模式六的 Document_chat_template（按意图选库）与 根据用户的意图进行回复（按意图决定”要不要检索”）。

flowchart LR
  S((开始)) --> Q{是否检索?}
  Q -- 是 --> QC{选哪个库}
  QC --> KB1[库A 检索→模板→LLM]
  QC --> KB2[库B 检索→模板→LLM]
  Q -- 否 --> D[直接 LLM]
  KB1 & KB2 & D --> R((回答))

图：图文知识库的检索结果直接以 Markdown 图片输出。（源截图 snapshots/WechatIMG9731.jpg）

9. 模式八：Agent 单节点 —— Function Calling / MCP 工具调用#

识别信号：图里一个 agent 节点直接接 Start/Answer（3 节点整图）。控制流完全由模型在运行时决定，工具注册在 Agent 里。

这批 2025 年文件是 Dify 1.0 Agent 节点的演示：

flowchart LR
  S((开始)) --> A[Agent<br/>模型自主选工具<br/>· Function Calling 工具集<br/>· MCP 外部服务]
  A --> R[if-else / 收尾 LLM]
  R --> O((回复))

图：Agent 节点把”规划-调工具-再规划”收敛成一个节点。（源截图 snapshots/Xnip2025-02-17_16-51-30.jpg）

取舍提醒：Agent 把决策权全部交给运行时，图会”消失”成单节点——直观、灵活，但不可复现、难估成本。仓库里几乎所有”工具 + 固定步骤”的活儿（检索、翻译、发多平台文案）仍刻意用确定骨架完成，只有真正开放的任务才交给 Agent。这是很好的分寸感示范。

10. 模式九：Agent/聊天 + 会话记忆环（变量赋值写回）#

识别信号：variable-assigner（变量赋值）出现在”回复之后”，把本轮内容写回会话变量，供下一轮从”开始侧”读出——图上看是一个回环。这是让 Chatflow 记住上下文的通用手段（README 称之为会话变量）。

旅行Demo.yml 是”Agent 记忆环”的最小示范：

开始 → 模板转换2(拼装提示) → 变量赋值2(写会话变量) → Agent → 直接回复
        → 模板转换(整理消息) → 变量赋值(把本轮对话写回会话变量)   ← 回环

flowchart LR
  S((开始)) --> T1[模板 · 从会话变量拼上下文]
  T1 --> A1[变量赋值 · 初始化/写入]
  A1 --> AG[Agent 依据记忆回复]
  AG --> T2[模板 · 整理本轮消息]
  T2 --> A2[变量赋值 · 对话历史写回]
  A2 --> S

记忆测试.yml 把”记忆”做成了一等公民：会话变量里有 长期记忆 / 短期记忆(重置/追加) / 本周任务 / 可用话题，先按会话轮数判断是重置还是增量更新，需要更新时走”LLM 记忆生成 → 工具取当前时间 → 代码组织记忆与时间 → 变量赋值追加”；同时它还是”主动关怀”型客服——判定模块判断”该不该主动发消息”，决定追问 / 找热点话题 / 购药任务 / 近期关怀等行为。Form表单聊天Demo 则用会话变量存登录 token，实现”登录后才有权限访问模型”。

图：旅行Demo 用变量赋值把每轮对话写回会话变量。（源截图 snapshots/Xnip2025-01-23_13-22-24.jpg）

设计要点：会话变量是 Dify 里做”有状态”的唯一正道——游戏关卡、登录态、用户偏好、多轮上下文都能用它表达，且变量在节点间靠 {{#...}} 引用。

11. 模式十：会话状态机 —— 用 if-else + 会话变量做交互式应用#

识别信号：多个 if-else 以状态字段做条件，分支里既有”输出到回答”也有”改状态/重入”的边，answer 节点很多——本质是把游戏/流程的状态转移图画成了工作流。

完蛋！我被LLM包围了！.yml 是仓库最出名的例子：以 开始 → 输入判断 → 变量赋值(启动/重启状态) → 模板 → 变量聚合器 → 状态判断 打底，之后按状态分发到不同玩法——LLM问答（正面提问）、倒序问题（把问题倒过来问的”回文”考验）、互惠问题；每条玩法回答后都用”代码验证 + 验证通过判断”推进关卡，关卡号、题目序号、当前状态都通过 变量赋值 写进会话变量（节点名就叫”设置游戏关卡、问题序号和状态”），直到通关或失败。

flowchart LR
  S((开始)) --> IN{输入判断}
  IN --> AS[变量赋值 · 启动/重启]
  AS --> ST{状态判断<br/>读会话变量}
  ST -->|出题| Q[LLM 问答]
  ST -->|倒序题| RQ[问题倒序 + LLM]
  ST -->|互惠题| MQ[互惠问题 LLM]
  Q & RQ & MQ --> V[代码 · 取题并验证]
  V --> CK{验证通过判断}
  CK -- 否 --> ST
  CK -- 是 --> AS
  ST --> A1[回答 · 挑战成功/失败/完成]

（为可读性做了简化；真实图 30 节点、6 个 if-else、3 个变量赋值、10 个回答节点。）同族示例 小支付-DEMO.yml 用会话变量记”支付状态 + 对话轮次”，是”带状态的商业流程”的轻量版。

图：文本游戏靠状态判断 + 变量赋值把”关卡/题号/状态”转起来。（源截图 snapshots/Xnip2025-01-21_09-39-18.jpg）

12. 模式十一：代码节点做确定性重活（Code + Sandbox）#

识别信号：code 节点串联 LLM 之间或 LLM 之后，承接”LLM 做不好但规则能做好”的事。这是仓库中另一条高频主线，几乎每个非翻译流程都有。

代码节点的典型职责可归纳为六类：

flowchart LR
  S((开始)) --> C1[代码 · 读文件/切分/解析]
  C1 --> L[LLM · 语义处理]
  L --> C2[代码 · 结构化输出/绘图/修复]
  C2 --> E((结束))

runLLMCode.yml 走得更远：让 LLM 先写代码，再交给沙箱执行，以此突破代码节点”不能引用 LLM 动态代码”的限制（README 说明：通过 HTTP 请求把代码发到 dify-sandbox-py ↗ 执行）。它用 HTTP 请求而不是 HTTP 工具，就是为了把 LLM 生成的代码正文作为载荷传递。

开始 → 代码获取文件路径 → 代码读取csv → LLM(分析) 
     → 代码提取LLM中的代码 → HTTP(sandbox执行代码) → 代码提取输出 → 结束

图：runLLMCode 让 LLM 先写代码，再交给沙箱执行。（源截图 snapshots/Xnip2024-12-05_10-16-16.jpg）

实践原则：凡是”结果必须精确、可解释、可复现”的步骤（JSON 合法性、签名、坐标、格式），一律下沉到代码节点；LLM 只负责”模糊的语义创造”。仓库把这条边界守得很清楚。

13. 模式十二：一源多产（Fan-out / 内容流水线并联）#

识别信号：同一个上游结果被扇到多个同构分支（每家平台一套 LLM 文案 + 标签），各分支再各自组装成最终产物；分支之间没有互斥，是并行放大而非路由选择。

Dify 运营一条龙.yml 是 51 节点的大号样本：先从 30 来个”模板转换”拼好个人偏好与专有名词配置 → LLM 生成一版正文 → 转义错误检查 自检 → 随后按平台扇出：小红书/微博、抖音/视频号、X(Thread)、Instagram、Bilibili、YouTube，各配”正文 + hashtag”LLM；封面/配图再走一套”模板画布设置 → HTTP 图片渲染(ImgRender) → 代码提取 URL”的外部渲染链。

flowchart LR
  S((开始)) --> CFG[30×模板转换 · 偏好/名词/样式配置]
  CFG --> G[LLM 生成内容初稿]
  G --> CHK[LLM 转义错误检查]
  CHK --> F1[小红书/微博 文案+标签]
  CHK --> F2[抖音/视频号 文案+标签]
  CHK --> F3[X Thread 文案]
  CHK --> F4[Instagram/B站/YT 文案]
  F1 --> C1[封面画布模板 + HTTP 渲染]
  F2 --> C2[封面画布模板 + HTTP 渲染]
  C1 & C2 --> E((各平台产物))

值得警惕的是它的反面教训：README 已注明封面图 ImgRender 服务年久失修，主流程已不可用。这告诉我们”扇出 + 外部渲染服务”的模式虽然结构漂亮，但外部服务不稳固时整条产线都会失效——这也是该仓库贴出的最真实的工程注解。

图：一份初稿扇到 6 个平台再各自渲染封面。（源截图 snapshots/Xnip2024-07-24_16-34-29.jpg）

近亲还有 文章仿写-单图_多图自动搭配.yml：用 3 个 if-else（是否清除图片 / 是否单图仿写 / 爬取结果判断）加参数提取器，把”爬原文 → 仿写 → 配图”切成可复用分支——它展示的是扇出/分支与 if-else 的混合用法：判断走哪条仿写管线，而不是像运营一条龙那样全部产出。

14. 模式十三：研究型多轮检索（Search → Read → Synthesize）#

识别信号：工具/HTTP 搜索 + 多级迭代 + 最终 LLM 综述。它 = 模式三(Map) + 模式二(工具打底) + 工具集检索的组合。

搜索大师.yml 的结构（14 节点）可以抽象成”追问 → 逐题搜索 → 逐页抓正文 → 表格汇总 → 综述”：

开始 → LLM1(生成追问列表) → 代码(解析成列表) → 迭代1(逐问题 SearXNG 搜索)
     → 代码2 → 迭代2(逐结果 JinaReader 抓正文) → 模板(汇总表) → LLM4(综述) → 回答

flowchart LR
  S((开始)) --> G[LLM 生成追问]
  G --> I1[/迭代 · 逐题搜索/]
  I1 --> SE[SearXNG]
  I1 --> I2[/迭代 · 逐链接抓正文/]
  I2 --> JR[JinaReader 读取网页]
  I2 --> TB[模板 · 汇总表]
  TB --> SY[LLM 综述 + 引用 URL]
  SY --> R((回答))

Jina Reader Jinja.yml 是同款精简版（TavilySearch → 迭代切 URL/摘要 → 表格）。再往上是模式四的 Deep Researcher——把这里的”检索循环”升级成”每子主题一套独立检索→写作”，并加上总结与多轮回答优化。你可以把这三者看成同一条研究流水线的三个复杂度档位：Jina Reader（单轮问答）→ 搜索大师（提问-搜索-阅读-综述）→ Deep Researcher（并行多角度深度研究）。

图：搜索大师 把”追问 → 逐题搜索 → 逐页抓正文 → 综述”串成两级迭代。（源截图 snapshots/Xnip2024-07-24_13-07-55.jpg）

15. 参数提取器 + 外部服务：把”图/结构/HTTP”交给专业环节#

收尾提一个仓库里高频出现的跨模式配方：parameter-extractor（参数提取器）+ http-request（HTTP 请求）/ 模板把”结构化输出”与”专业渲染”外包给确定性服务。

• Text to Card Iteration.yml：模板拼请求 → HTTP 调用卡片服务 → 参数提取器取结果 → End。
• chart_demo.yml：HTTP 取天气数据 → 代码组合数据 → 直接回复（配合前端渲染图表）。
• 上文提到的封面渲染、runLLMCode 的沙箱执行、Dify 运营一条龙 的 ImgRender 都是这个配方的变体。

flowchart LR
  S((开始)) --> T[模板 · 拼请求体]
  T --> H[HTTP 请求 · 外部渲染/沙箱/数据服务]
  H --> P[参数提取器 · 结构化取值]
  P --> E((结束))

配合模式三，参数提取器还是给迭代器供列表的标准接口——它把 LLM 的自由文本输出约束成带 schema 的 JSON，直接变成下一级循环体要消费的数组。这条配方是仓库里”LLM 只做语义、格式交给代码、渲染交给外部”工程观的落点。

图：HTTP 取数据后组合渲染。（源截图 snapshots/Xnip2024-11-14_15-17-39.jpg）

16. 归纳：模式 × 文件速查表#

选型建议（从简到繁）：

• 别急着上 Agent。仓库显示：翻译、检索、运营这些”步骤已知”的任务，作者们都用固定骨架，只有”开放探索/多轮对话补全信息”才给 Agent。判断标准一句话——能不能在设计时画完这张图：画得完就工作流，画不完才 Agent。
• 需要”每步可控、可插桩”就拆节点链；只是想要一次漂亮输出，先试模式①的单节点 Prompt，成本最低。
• 长文本/批量对象一律想”要不要切成列表喂迭代器”；有没有状态要跨轮保存，一律想”会话变量 + 变量赋值”。
• 会破坏稳定性的外部服务（渲染、沙箱、图片站）单独收口成 HTTP 配方，坏了只影响一段链路——Dify 运营一条龙 的封面服务就是现成教训。

17. 延伸阅读#

• 仓库 README 对每个 DSL 的用途、来源、截图、运行前提都有逐条说明，是最可靠的配套文档。
• 若把这里的”模式”再往抽象层提一层（脱离 Dify、落到通用编排范式），可参照 Anthropic《Building Effective Agents》的 Prompt Chaining / Routing / Parallelization / Orchestrator-Workers / Evaluator-Optimizer 分类，本仓库大部分文件都能归到那一套谱系里。
• Dify 特性对照：多任务并行、会话变量、表单、意图分类、参数提取器、迭代器、代码沙箱、MCP/Agent 插件，都能在本仓库找到最小可运行样例。