用Dify搭建Agent工作流：实现AI日报自动生成与信息汇总

08/09 的 AI 讨论里，OpenAI 暂停 Astra、Grok Image 2.0 疑似推送这类消息，往往散落在新闻站、推文和社区帖子中。靠人工打开十几个页面再整理成日报，既慢还容易漏。与其重复这种操作，不如用 Dify 搭一个 Agent 工作流，把“输入主题 -> 搜索信息 -> LLM 汇总 -> 输出日报”固定成可视化流程。这篇文章会从 Dify 的部署开始，逐步实现一个可复用的 AI 日报生成工作流，然后解释节点设计、参数调整、运行验证和生产化注意点。学完之后，这套流程可以直接扩展到竞品动态跟踪、技术周刊生成、内部情报汇总等场景。

1. 先理解 Dify 中的 Agent 工作流在编排什么

1.1 从普通问答到 Agent 工作流

普通问答应用的结构是：用户输入问题，模型直接返回答案。这种方式适合常识问答，但面对“今天的 OpenAI 有什么新动态”这类需要实时数据的问题，模型会受限于训练截止日期，无法给出可靠答案。Agent 工作流的核心差异，是在模型回答之前插入一个外部信息获取环节：模型先理解任务，再调用搜索接口或数据库接口，拿到结果之后才生成最终回答。

在 Dify 中，这个链路被可视化成一张工作流图。开发者不需要自己维护工具调用、API 鉴权、上下文拼接，只需要把节点拖到画布上，配置好输入输出变量。对大部分团队来说，这比从零写一套 Agent 框架更容易维护，也更容易排查问题。

1.2 为什么选择 Dify 而不是直接写代码

直接写一个 Agent 服务，通常要解决这些问题：

• 如何接多个模型供应商，并做密钥管理。
• 如何封装搜索、网页抓取、数据库查询等工具。
• 如何把工具的返回结果和系统提示词拼接到一次模型请求中。
• 如何处理超时、重试、截断和错误日志。
• 如何把能力封装成 API 给前端或定时任务调用。

Dify 把这些能力内置了。模型供应商、工具节点、知识库、工作流编排、API 发布都能在界面上完成，适合快速验证和长期维护。代价是学习曲线：你需要理解节点类型、变量传递和不同模式（工作流、Chatflow、Agent）之间的差异。不过，一旦理解了最小闭环，后面扩展并不难。

1.3 日报助手工作流的节点设计

这篇文章要搭建的 AI 日报生成工作流，包含四个核心节点：

固定流程的优点是稳定。每个节点负责一件事，出问题时可以通过节点日志快速定位。相比让模型自主决定调用哪些工具，固定工作流更适合日报这种重复性任务。等流程跑通之后，再考虑是否升级成完全由模型决策的 Agent 模式。

2. 环境准备：把 Dify 社区版跑起来，并接入模型

2.1 部署方式选择

Dify 有云服务和社区版。云服务适合快速体验，社区版适合本地开发、私有化部署或生产环境自托管。这篇文章以社区版为例，因为部署过程本身也能让你理解 Dify 的依赖组件。

学习环境一般只需要一台本地机器或开发机，配置不用太高。生产环境则需要独立数据库、Redis、对象存储和日志系统。这里先以本地 Docker Compose 部署为准。

2.2 使用 Docker Compose 部署 Dify

部署前确认 Docker 已安装，并且 Docker Compose 可用。

docker --version docker compose version

接下来从官方仓库拉取最新代码，进入 docker 目录，复制环境变量模板并启动服务。

git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d

启动过程会拉取多个镜像，耗时取决于网络环境。启动完成后检查容器状态。

docker compose ps

看到所有服务处于 running 或 healthy 状态后，打开浏览器访问http://localhost/apps，第一次访问会要求设置管理员账号。

最低配置建议如下表：

如果机器内存不足，容器启动时会因为 PostgreSQL 或 Weaviate 被 OOM 杀死而失败，所以内存不是可选项。

2.3 配置模型供应商

进入 Dify 的“设置 -> 模型供应商”，添加你使用的模型服务。这里以 OpenAI 兼容接口为例，需要关注四个配置项：

配置完模型供应商之后，还要在“系统模型设置”中指定默认对话模型和默认推理模型。这是因为不同节点可能使用不同的模型，如果系统默认模型没有设置，运行工作流时会出现Model provider not initialized这类报错。

2.4 准备搜索工具

日报工作流需要实时信息，因此需要一个可调用的搜索接口。常见选择包括 Tavily、SerpAPI、Bing Search，也可以使用团队自建的搜索服务。

以 Tavily 为例，申请到 API Key 后，在 Dify 工具节点中配置即可。如果 Dify 的工具市场里没有对应工具，也可以在工具节点中通过自定义 OpenAPI 接入一个 HTTP 搜索接口。生产环境建议使用收费或自建服务，免费接口的限流会直接影响日报稳定生成。

3. 创建“AI 日报生成”工作流

3.1 新建应用并选择工作流模式

在 Dify 控制台点击“创建应用”，选择“工作流”或“Agent”类型，应用名称可以叫“AI日报生成器”。不同版本的入口名称可能有差异，但核心都是在一张画布上编排节点。

建议先用空白工作流开始，因为固定节点顺序容易调试。等熟悉之后，再尝试使用 Agent 节点或 Chatflow 模式。

3.2 配置开始节点

进入工作流画布后，首先配置开始节点。添加两个输入字段：

• topic，字符串类型，表示日报主题，例如OpenAI。
• date，字符串类型，表示日报日期，例如08/09。

这两个变量会在后面的搜索节点和提示词模板中被引用。命名的目标是让人一眼看出用途，不要用a、b这种无意义名称。

3.3 配置搜索工具节点

添加一个工具节点，选择准备好的搜索服务。核心逻辑是拼出搜索词，并调用搜索接口。

如果工具节点支持模板变量，可以把查询参数配置成：

{ "query": "{{#start.topic#}} {{#start.date#}} 最新动态", "max_results": 10, "search_depth": "basic" }

其中{{#start.topic#}}表示引用开始节点的topic变量。实际变量名需要根据画布里的节点 ID 调整，Dify 界面里可以直接点击选择变量，不需要纯手写。

如果工具节点不支持，也可以使用 HTTP 请求节点，手动指定请求地址、请求头和请求体。搜索服务的返回结果中至少应包含标题、链接和摘要，这三个字段是日报生成的基础材料。

3.4 配置 LLM 汇总节点

添加 LLM 节点，模型选择系统中已经配置好的模型。这里的关键是提示词模板。

提示词模板可以这样写：

你是一名 AI 行业日报编辑。根据下面的搜索结果，生成当天的 {{#start.topic#}} 日报。 要求： 1. 只保留与 {{#start.topic#}} 相关的内容。 2. 每条信息必须包含标题、来源站点、原文链接和一句话摘要。 3. 如果某条信息没有官方确认，必须在标题前标注 [未确认]。 4. 如果搜索结果不足，直接写“今日没有可确认的动态”，不要编造。 5. 最终输出使用 Markdown 格式，按“头条 / 产品更新 / 社区讨论”分节。 搜索结果： {{#search_result.output#}}

这里的{{#search_result.output#}}是示意写法，实际引用搜索工具节点的输出变量。注意：不要直接把变量名复制进代码块，要在 Dify 界面中选择对应变量。

3.5 配置结束节点

最后添加结束节点，把 LLM 节点的输出映射为最终结果。建议输出两个字段：

• daily_report：Markdown 日报正文。
• sources：本次引用的来源列表，方便后续二次核验。

结束节点是工作流的出口。配置完成后，整张工作流图就形成了“开始 -> 搜索 -> LLM -> 结束”的闭环。

4. 参数说明：让日报更稳定、更可用

4.1 模型参数速查

LLM 节点里温度、最大 token、top-p 等参数会影响输出质量。对于日报这种偏向事实汇总的任务，推荐参数如下：

日报任务建议使用较低温度，因为事实汇总需要的是准确，而不是创意。

4.2 搜索参数

搜索节点的参数会直接影响日报质量。

如果搜索返回的结果与主题无关，通常是搜索词拼接有问题。可以先把搜索词的模板打印出来，检查是否出现了不必要的字符。

4.3 提示词里必须强调“来源”和“未确认”

日报类自动化应用最大的风险是信息失真。自动生成的内容一旦被当成已确认事实转发，会造成误导。

因此提示词模板里要强制要求：

• 每条内容带来源链接。
• 对“疑似”“可能”的消息保留不确定性。
• 没有官方来源时，不允许模型自行推断。

这个设计不是多余，而是生产环境的基本要求。

4.4 可选：加入知识库检索

如果日报需要结合公司内部资料，可以在搜索工具节点之后加入一个知识库检索节点，把检索结果一并传给 LLM。知识库节点通常需要关注两个参数：分段大小和 topK。分段太大，检索命中精度下降；topK 太小，可能漏掉关键内容。一般建议先用默认值，再根据测试结果微调。

5. 运行验证与发布

5.1 在工作流编辑器里运行测试

配置完成后，点击工作流右上角的“运行”按钮，输入测试参数：

{ "topic": "OpenAI", "date": "08/09" }

运行后逐个检查节点状态：

• 搜索节点是否返回了数据。
• LLM 节点是否成功调用。
• 结束节点是否输出了 Markdown 日报。

如果某个节点变红，点击节点打开日志面板，查看具体报错。把搜索工具节点的输出先直接放到结束节点，可以快速区分“搜索失败”和“LLM 汇总失败”。

5.2 发布并获取 API

工作流测试通过后，点击“发布”。发布后，在“API 访问”页面可以找到工作流的 API 地址和密钥。API 密钥以app-开头，只能保存在服务端，不能直接写到前端代码里。

5.3 通过 curl 调用工作流 API

工作流发布后，可以通过 HTTP 接口调用：

curl --location --request POST 'https://your-app.example.com/v1/workflows/run' \ --header 'Authorization: Bearer app-xxx' \ --header 'Content-Type: application/json' \ --data-raw '{ "inputs": { "topic": "OpenAI", "date": "08/09" }, "response_mode": "blocking", "user": "daily-news-bot" }'

响应中会包含workflow_run_id和outputs字段。outputs.daily_report就是最终日报内容。

示意响应结构如下：

{ "workflow_run_id": "run_abcdef", "status": "succeeded", "outputs": { "daily_report": "# OpenAI 日报\n\n## 头条\n- [未确认] ...", "sources": [] } }

不同版本的 Dify 返回字段会有差异，以实际接口文档为准。

5.4 用 cron 定时触发生成每日日报

日报适合定时生成。可以在服务器上写一个 cron 任务，每天早上请求一次工作流 API。

0 8 * * * curl --location --request POST 'https://your-app.example.com/v1/workflows/run' \ --header 'Authorization: Bearer app-xxx' \ --header 'Content-Type: application/json' \ --data-raw '{"inputs":{"topic":"AI","date":"'"$(date +%m/%d)"'"},"response_mode":"blocking","user":"cron"}' \ >> /var/log/dify-news.log 2>&1

生产环境建议不要直接把 cron 输出丢弃，至少要保留日志，并在请求失败时发送告警。

6. 常见问题排查：从日志到节点状态逐层定位

6.1 模型节点报错Model provider not initialized

常见原因是模型供应商没有配置，或者没有设置系统默认模型。

修复后重新运行工作流。如果仍报错，重启 Dify 容器再测试。

6.2 搜索工具提示 401、429 或超时

根据 HTTP 状态码区分原因：

• 401：API Key 无效或未配置。
• 429：请求超出配额，需要等待或升级套餐。
• 超时：搜索服务不可达，或网络策略限制。

排查方式是先用 curl 单独调用搜索接口，确认接口本身正常。如果外部搜索 API 在当前部署环境不可用，建议改用本地可访问的搜索服务，或者退一步使用知识库检索作为数据来源。

6.3 日报内容为空或输出被截断

可能原因有三个：

1. max_tokens设置过小，日报太长被截断。
2. 搜索结果为空，LLM 没有材料可写。
3. 提示词过于复杂，模型没有严格遵循输出格式。

排查顺序应该是：先看搜索节点输出是否正常，再看 LLM 节点实际接收的上下文，最后调整max_tokens和提示词。

6.4 知识库检索不到内容

检查知识库文档是否成功分段和索引。如果文档更新后没有重新索引，检索结果就不会包含新内容。另外，检索的 topK 太小也可能导致无结果。先在知识库页面直接测试检索，确认能召回内容，再回到工作流里检查变量引用。

6.5 Dify 服务启动失败

使用docker compose logs -f查看容器日志。常见问题包括：

• 端口被占用。
• 磁盘空间不足。
• 内存不足导致容器退出。
• 环境变量配置错误。

排查顺序是先看日志，再关注资源占用，最后检查.env文件里是否有冲突配置。

7. 用这个工作流追踪 08/09 的 AI 动态

7.1 输入 “OpenAI Astra” 和 “Grok Image 2.0”

08/09 的公开讨论中，OpenAI 暂停 Astra 和 Grok Image 2.0 疑似推送都是比较受关注的话题。这类信息具有两个特点：一是分散在不同平台，二是多为“疑似”或“讨论中”状态。手动整理时很容易忽略来源，或把猜测写成事实。

使用刚才搭建的工作流，把topic分别设为OpenAI Astra和Grok Image 2.0，工作流会先搜索相关页面，再根据提示词生成日报。由于提示词中已经要求对未确认消息标注[未确认]，最终输出会更接近“信息摘要”而不是“新闻定论”。

下面是输出结构的一个示意，不代表真实搜索结果：

# OpenAI Astra 日报（08/09） ## 头条 - [未确认] OpenAI 暂停 Astra 项目的相关讨论在社区扩散。 来源：链接A / 链接B 摘要：多个消息源都在讨论该项目状态，官方尚未发布正式公告。 ## 社区讨论 - 开发者对 Astra 后续方向存在不同解读。 来源：链接C

这个结构能帮助读者快速判断哪些信息可以引用，哪些还需要进一步确认。

7.2 让工作流保留“疑似”信息

自动生成日报时，最重要的一件事是区分“事实”和“推测”。Grok Image 2.0 疑似推送这类信息，很可能只有少数用户反馈，还没有官方公告。如果提示词不强调“未确认标注”，模型可能会根据上下文自行脑补成已确认事实。

在提示词中加入这条规则：

对于没有官方来源的信息，必须在标题前标注 [未确认]，并在摘要中说明信息来源。

这样生成的日报才不会误导读者。

7.3 把日报推送到订阅渠道

工作流 API 发布后，可以把输出接入钉钉、飞书、企业微信或邮件。常见做法是写一个脚本：

• 请求工作流 API。
• 解析outputs.daily_report。
• 调用群机器人 Webhook 发送消息。
• 失败时写入日志并重试。

这个环节不需要 Dify 参与，属于外部调度逻辑。生产环境建议单独监控。

8. 生产化建议：从“跑通”到“稳定”

8.1 学习环境与生产环境的差异

本地 Docker 部署跑通是第一步，但生产环境还要考虑更多组件。

不建议直接把学习环境的 Docker 容器搬到生产环境。至少要把数据库和 Redis 拆出来，避免容器重启导致数据丢失。

8.2 发布前检查清单

上线前可以按下面的清单过一遍：

• 系统默认模型已配置，且测试过多种长度输入。
• 工具 API Key 使用环境变量或凭据管理。
• 提示词中包含来源链接和未确认标注规则。
• 搜索节点设置了超时和失败处理。
• 测试覆盖空结果、结果过多、API 超时三种场景。
• 工作流 API 密钥只保存在服务端。
• 定时任务有日志、重试和失败告警。
• 生产数据定期备份。

每一条都对应实际事故案例。比如没有日志的定时任务，一旦工作流发布新版本导致变量名变化，你会很难定位问题。

8.3 从“固定工作流”升级为真正的 Agent

日报生成适合固定工作流，因为任务边界清晰：搜索、汇总、输出。固定工作流的好处是稳定和可控，缺点是不够灵活。

如果要把日报助手升级成真正的 Agent，可以改为 Agent 模式：让模型根据用户问题自动判断是否需要搜索、调用哪个工具、追问还是直接回答。这种模式适合开放式查询，但会增加不可控性。实际项目中建议保留两种入口：稳定流程走工作流，探索性查询走 Agent。

8.4 后续扩展方向

日报工作流只是开始。后续可以：

• 加入更多工具节点，比如抓取指定新闻源、查询数据库。
• 加入知识库，将历史日报入库，做趋势分析。
• 加入人工审核节点，重要信息发布前由人确认。
• 接入内容审核服务，避免自动生成内容包含违规信息。
• 把生成的日报归档到对象存储，形成历史检索库。

对于一个开发团队，这套流程最大的价值不是省去写日报的时间，而是把信息收集、过滤、摘要、分发环节标准化。任何以信息汇总为核心的任务，都可以复用今天这个工作流模板。

Dify 的版本迭代很快，节点名称、配置入口和 API 字段会有变化。建议以官方文档为准，同时保留本文理解的核心思路：先定义数据流，再配置节点，最后在日志中验证每一步输出。日报助手是这样，其他自动化工作流也是这样。