用 Dify Chatflow 搭建多模态视觉创作 Agent 与 SEO 自动化全链路工作流:节点设计、提示词调优与 API 接入完整拆解

本文由 莫潇羽@源码七号站(www.fuyuan7.com)撰写,转载请注明出处。

快速摘要(只看结论就够了)

这篇文章把两条核心链路从头到尾拆开来讲清楚。第一条是"多模态视觉创作 Agent",在 Dify 的 Chatflow 里用问题分类器把一篇 SEO 文案拆成图片需求,再分别走文生图、图生图、智能抠图、图生视频四条子链路,统一通过聚合 API 平台调用底层模型,切模型只需改四个地方。第二条是"SEO 全自动化生产线",三个 Workflow 串起来用:DataForSEO 负责挖关键词,Tavily + Firecrawl 双引擎做素材采集与深度抓取,Kimi K2 类长上下文模型负责大纲,创作型模型负责正文,Google Apps Script 把 Sheets 改造成可读可写的轻量后端,实现"输入种子词 → 自动产出整篇正文 → 自动入库 → 自动规划站内架构"的闭环。

这套打法的关键不在于堆模型,而在于把每个环节交给最擅长它的工具:广度搜索给 Tavily,深度抓取给 Firecrawl,逻辑推理给长上下文模型,文字润色给写作型模型,持久化给 Google Sheets。所有节点都用提示词指令而非关键词列表来判断分支,这一改动直接把分类准确率提升了一个数量级。文末附完整的踩坑总结、API 调用模板、模型切换方法论以及结构化输出避错的 JSON Schema 写法。

想看完整拆解,往下翻。

一、单点对话的瓶颈,与"工作流式 AI"为什么是更稳的解

我最近这一年折腾下来,跟身边几位做内容、做出海、做独立产品的朋友交流,几乎所有人都有过同一种感受——刚开始接触大模型那阵子,大家都泡在对话框里:把要求丢进去、看着它生成、不满意就改一句重发。这个过程很爽,但只要把它放到真正的"产能"语境下,就会立刻露怯。

露怯的地方有三处。第一,结果不稳定。同样一段提示词,今天生成的东西能用,明天再发就不一定有那个味儿了。第二,深度不够。模型的知识库截止于训练时点,即使开了联网,搜出来的也常常是浮在表面的几条新闻摘要,写出来的东西读起来像新闻拼接,没真功夫。第三,没法规模化。一次只能写一篇,人盯着对话框,出活效率被人的注意力捆死。

工作流式 AI 解决的就是这三件事。它的核心思想很简单:不再把一个复杂任务整个塞给模型,而是把它拆成若干个步骤,每一步交给最擅长那一步的工具去处理,前一步的输出作为后一步的输入。 这就跟工厂的流水线一个意思——磨刀的不切菜,切菜的不掌勺,每个工位只做自己最熟的那一件事。

这套理念落到 AI 应用里,会带来三个非常实在的好处。

第一个是确定性。 每个节点都有明确的输入和输出。文档解析节点的输出是结构化文本,搜索节点的输出是一个 JSON 数组,大模型节点的输出是一段符合 schema 的内容。出了问题,一眼就能定位到是哪一环掉链子,不像传统的"一句 prompt 包打天下",崩了根本不知道崩在哪。

第二个是上限被打开了。 单一模型的上下文窗口、联网能力、推理深度都是有限的。但只要把任务拆出来,你就能把"广度搜索"、"深度抓取"、"逻辑统筹"、"创作润色"这几件事分别交给不同的工具,各自发挥到极限,最后再拼起来。我自己用这套方法生产的长文,跟单纯让模型"联网写一篇"出来的内容,质感差距大到几乎不像同一类东西。

第三个是可复制。 工作流一旦调通,就可以批量跑。喝杯茶的功夫,一篇有深度的好文章已经躺在表格里等着你了。这件事的复利效应是非常吓人的,跑一天和跑一个月,在内容积累上完全是两个量级。

回到我们今天要拆解的内容,本文要彻底讲明白的是两条主线:

• 多模态视觉创作链路——用 Dify 的 Chatflow 搭一个能识别意图、能调用图像引擎、能生成视频的 Agent,从一篇 SEO 文章直接产出配图与短视频。
• SEO 内容生产链路——三个 Workflow 串起来,从关键词挖掘、内容生产到站内架构规划,全部跑成自动化。

我会逐个节点讲清楚每一条连线背后的逻辑,以及踩过的坑。这不是一篇"复制粘贴跟着抄"的教程,而是一次关于提示词工程与系统架构的完整复盘——这点是我做完两版工作流之后特别想强调的。光知道怎么连线没用,你得理解为什么这么连。莫潇羽@源码七号站今天的目标,就是让你看完之后能自己改、自己魔改、自己往业务里嵌。

二、Dify Chatflow 与 Workflow:先选对类型再开工

工具选错,后面全是麻烦。在 Dify 里建应用的第一步就是选类型,这个选择会决定你整个项目的形态。先把两种类型的差别说清楚。

2.1 Chatflow 与 Workflow 的核心差别

Dify 把可视化编排分成两种:

简单一句话区分:用户要不要跟它聊天?要聊,选 Chatflow;不聊,选 Workflow。

多模态创作那条链路,用户得跟 Agent 多轮交互——上传文章、看方案 A/B/C、选定一个、追加生成视频的指令——所以必须用 Chatflow,因为只有它支持 Memory(对话历史)和 Answer 回复节点。SEO 关键词挖掘那条链路,用户输入一个种子词,流程跑完直接把结果写进表格,中间不需要任何交互,这种就是典型的 Workflow 场景。

新手最容易犯的错就是把交互式应用做成了 Workflow,做完发现没法承接"用户的下一句话",只能从头再来。我刚开始也犯过这毛病,后来才慢慢摸清楚两者的分工。

2.2 会话变量与环境变量:别搞混

进到 Chatflow 编辑器里,右上角能看到两个图标:会话变量和环境变量。这俩长得像,但作用完全不同。

• 会话变量(Conversation Variable):作用域是"这一次会话"。用户开一次对话,变量就生效一次,关掉就清空。典型用途是临时保存用户上传的图片 URL、保存某一轮生成结果的句柄,方便后续节点取用。
• 环境变量(Environment Variable):作用域是"整个应用"。所有用户、所有会话共享同一份。典型用途是存 API Key、存某个第三方服务的 base URL,改一次全应用生效。

我在多模态 Agent 里设了一个会话变量叫 image_url,专门用来保存当前会话里那张待处理的图片地址。当用户上传图片之后,系统先把 URL 存进这个变量,后面无论是抠图节点还是图生视频节点要用图,都从这个会话变量里拿,逻辑非常清爽。

2.3 文件与图片上传:别忘了开

Chatflow 默认不开图片、文件上传,需要手动点开。位置在编辑器右上角的"功能"按钮里,把"图片上传"和"文件上传"分别打开,然后点进设置:

• 最大上传数:拉到最大。Dify 当前版本一次最多支持上传 10 个文件,反正都是用户决定上传几个,给足上限不亏。
• 文件类型:按需勾选。视觉创作 Agent 主要要"文档"和"图片",其它格式可以不勾;SEO 工作流如果让用户输入种子词就用纯文本输入即可,不需要打开文件上传。

顺手再说一下"对话开场白",这个特别容易被忽略。开场白是用户打开应用第一眼看到的提示语,合理设计能极大降低用户的上手成本。比如可以写:"你好,我是视觉创作助手,你可以上传一篇 SEO 文章,我会分析需要什么配图;也可以直接上传一张产品图,我会帮你生成融合后的成图或视频。"——这种带使用示例的开场白,比一句"请输入您的问题"友好太多了。

把这些基础设施铺好之后,真正的活就要开始干了。下一章讲的是整个多模态 Agent 的骨架——问题分类器与它带出来的六条子链路。

三、多模态视觉创作 Chatflow 的整体架构

把骨架搭好之前,先把整张地图画出来,后面看每一节会清晰很多。这套 Chatflow 的全貌长这样:

flowchart TD
    A[用户输入<br/>文档/图片/文字] --> B[问题分类器]
    B -->|分类一<br/>方案规划| C[文档提取器]
    C --> C1[视觉规划大模型]
    C1 --> C2[直接回复方案]
    B -->|分类二<br/>产品融合| D[视觉大模型]
    D --> D1[代码节点<br/>提取图片URL]
    D1 --> D2[变量赋值<br/>保存到会话变量]
    D2 --> D3[直接回复融合提示词]
    B -->|分类三<br/>智能抠图| E[代码节点<br/>调用抠图API]
    E --> E1[直接回复抠图结果链接]
    B -->|分类四<br/>图生视频| F[代码节点<br/>提交视频任务]
    F --> F1[直接回复任务查看链接]
    B -->|分类五<br/>图生图| G[代码节点<br/>调用图生图API]
    G --> G1[直接回复融合后的成图]
    B -->|分类六<br/>纯文生图| H[清洗大模型]
    H --> H1[代码节点<br/>调用文生图API]
    H1 --> H2[直接回复成图链接]

整张图看下来,问题分类器就是中枢神经。它要把用户那句话理解清楚,然后正确地导向某一条子链路。整个 Agent 能不能用,关键就在这一个节点上。

3.1 输入字段:三态共存的写法

进到"开始"节点配置用户输入,我建议只设一个字段就够了,起名叫 文档(也可以叫别的,但要跟后面的引用对应上)。这个字段的类型选单文件——它对应的就是"一个可选的文件/图片占位符"。

这里有个关键细节:必填项关掉。如果开了必填,用户没传文件就不能发消息,体验非常不好。我们要做到的是:用户既可以传图、也可以传文档、也可以什么都不传只发一句话。

打开"文件上传"功能,允许的类型勾上"文档"和"图片"。在 Chatflow 内,这两类文件背后都对应 array[file] 类型的变量,后面节点引用的时候按需取就行。

3.2 为什么不在用户输入这里做"必填"约束

很多新手会想:既然图生视频必须要图,那为什么不在输入端就强制要求传图?

道理是这样的——意图识别要在"问题分类器"这一步做,不要在"开始"节点做。 开始节点做硬性约束会让 UI 体验变僵,用户得提前知道"哦原来你要图我才让我说话"。而把判断挪到问题分类器里,系统就可以做得更聪明:用户没传图、但说了"帮我生成视频",分类器可以直接回一句"请上传一张参考图再试",体验会自然得多。

把硬约束往后挪、把柔性判断往前提,这是我做 Agent 这两年总结出来的一个小心得,用户感知到的"聪明"绝大多数都来自这种设计,跟模型本身的强弱关系反而没那么大。莫潇羽自己在源码七号站发的几个内嵌 Agent 都是这个思路,确实管用。

3.3 子链路的功能定位

六个分类各自负责什么,先讲一遍,有个全局观:

每条子链路单独看都很简单,串起来才有威力。一个常见使用路径是:用户先走分类 1 拿到配图方案,看中方案 A 之后,把方案 A 的提示词复制回来交给分类 6 生成图,觉得图还行但想要动效,再把生成的图丢给分类 4 出视频。整套 Agent 的乐趣就在于它可以"接力"——前一步的产物可以作为后一步的输入,实现真正的多模态闭环。

骨架画完了,下一节把问题分类器单独拎出来重点讲。这一节我会同时给出"旧方案"和"新方案"的对比,这是这套工作流升级前后最大的改动,也是踩坑最多的地方。

四、问题分类器:从关键词列表到指令式提示词的关键升级

问题分类器是这套 Agent 唯一一个"绝对不能错"的节点。它判断错了,整条链路就跑偏,后面再聪明的模型也救不回来。我前后做了两版工作流,在这个节点上栽了两次跟头,最终找到的解法,值得单独拿一章来讲。

4.1 模型选择:别贪强

分类器的工作量并不大——读一段几十个字到几百个字的用户输入,判断它属于六个分类里的哪一个。这种任务根本不需要旗舰模型,选个性价比高的中端模型就够用了。

我目前用的是 Gemini 2.5 这一档的模型,主要是国内通过中转使用 token 单价控制得住,而且这一档的模型在"分类、判别、结构化输出"这类任务上表现稳定。如果你预算更紧,Kimi 系列的中等档位、智谱 GLM 系列的标准款都可以胜任,实测准确率掉得不多。

4.2 旧方案:把关键词塞进分类条目

我第一版的做法非常朴素——在每个分类条目下面,把可能触发这个分类的关键词列出来。比如:

• 分类 4 图生视频:关键词列表填 让它动起来 / 生成视频 / 做成视频 / 动效 / 动画 / 视频
• 分类 5 图生图(产品融合):关键词列表填 融合 / 合成 / 结合 / 加上元素 / 背景换

这种写法直观,看起来非常符合"程序员思维"——你给我关键词,我去匹配。但跑起来之后会发现一个问题:关键词冲突。

举个真实的例子。用户上传了一张产品图,说"帮我把这个图融合成一个视频"。这句话里同时出现了"融合"和"视频",触发了分类 5(产品融合)和分类 4(图生视频)两个分类的关键词。模型在两个之间犹豫,有时候选对,有时候选错——尤其是分类 5 和分类 6(纯文生图),触发词长得太像了,经常错位跳进图生图,但图生图必须要图片,用户没传就直接报错。

那段时间我做了上百次测试,错位率大概有 30% 到 40%,这个失败率对一个生产级 Agent 是完全不能接受的。

4.3 新方案:把判别逻辑写进指令

后来我把整个写法翻了过来——关键词列表全部清空,改成在分类器的"指令"区写一段结构化提示词。

这一段提示词的核心结构长这样:

你是一个意图分类器,需要根据用户的输入和上下文,