如何构建基于n8n的RAG日报工作流（手把手教程）

过去两周，又是在昏天暗地项目实施和咨询中度过，计划发的文章也略微耽搁了两篇，后续补上。

接触业务场景越多，愈发觉得应该埋头苦干的同时，除了日常翻些公众号和知乎的水文外，还是应该多浏览些国内外优质信息源的不同行业最佳实践。说到这里也就要引出“AI 日报”（自动化信息/内容汇总推送）这个概念。

虽然市面上有不少“AI 日报”类的信息推送，但实测了些发现，大多还是偏向于泛化内容，比如新模型发布动态、新奇产品和工具推荐，当然还有些是什么大厂花边新闻之类。

So，过去一周花了些时间持续优化个自动化 RAG 日报工作流，每天聚合和筛选国内外围绕 RAG 在不同行业落地的最佳实践、实用技巧和最新案例。后续完成进一步测试后，我会把日报每天更新在知识星球会员群中。

这篇试图说清楚，我在开发这套“RAG 日报”工作流过程中的思考、工具选择、踩过的坑，以及未来的优化计划。

以下，enjoy:

1

技术实现：为啥选择 n8n

首先，需要回答的问题是，用啥工具来实现这个信息的收集、处理和推送？

1.1

工具横评

市面上自动化工具不少：n8n、Make、Zapier、直接用 Python 脚本，甚至用 Airflow 这类调度工具，都各有优势。

我一开始也并不确定哪一个最适合，于是做了几轮尝试后选择了 n8n。整了个表格做了些横向对比，感兴趣的可以瞅一瞅。

看到这里，可能会有人好奇为啥不直接用 dify 来搭这个流程。这是因为 Dify 本身定位是 “AI-native app builder”，虽然具备工作流编排、LLM 集成、RAG 配置这些功能，似乎也可以实现一套“AI 日报”的自动化流程。但 Dify 并不具备像 n8n 那样丰富的 API 节点（没有 RSS、爬虫、Webhook 等模块），数据源接入需要自建外部 API 或用代码补齐。

换句话说，相比之下，n8n 原生是面向“集成+自动化+流程编排”场景，有成熟的节点库支持各种 API、爬虫、数据处理、消息推送，而 Dify 更偏向“AI 应用开发平台”。

1.2

如何使用

官方网站

官方支持 14 天试用，如果是新手盆友，建议先在官网跟着官方模板测试几个工作流先上手再说。这部分不做展开讨论，具体看下文的搭建过程介绍。

本地化部署

n8n 如上所述是个开源框架，支持本地化部署。部署方式也支持两种，在安装 node.js 的前提下使用 npx n8n 命令即可一键部署。或者使用 Docker 部署，使用 http://localhost:5678 即可打开。

docker volume create n8n_datadocker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n

Github 仓库地址： https://github.com/n8n-io/n8n 

2

信息源的选择与构建

一个高质量、专业性强的 RAG 日报肯定是要有对应的优质信源作为支撑，我梳理了以下几种类型的部分信源供参考：

2.1

Blog

Weaviate 博客

深入解析 RAG 架构、不同实现方式（如 HyDE、ReAct）、评估方法、与向量数据库的结合。技术深度高，有很多关于向量搜索和 RAG 结合的实战文章。?https://www.google.com/urlsa=E&q=https%3A%2F%2Fweaviate.io%2Fblog 

LlamaIndex 博客

作为领先的 RAG 框架，其博客会分享关于数据摄取、索引、查询引擎、评估 RAG 应用等的最新进展和最佳实践。

?https://www.google.com/url?sa=E&q=https%3A%2F%2Fblog.llamaindex.ai%2F )

Kapa.ai博客

总结了来自 OpenAI、LangChain 等团队的 RAG 实践经验，提供了数据源管理、评估方法等方面的最佳实践，尤其关注 RAG 在文档问答、代码问答等场景的应用。实测有很多有价值的“避坑”指南。

?https://www.google.com/url?sa=E&q=https%3A%2F%2Fkapa.ai%2Fblog )

Cohere 博客

Cohere 提供强大的嵌入模型和重排（Rerank）API，其博客常有关于提升检索质量、语义表示、多语言 RAG 等方面的文章。关注提升 RAG 中“R”（Retrieval）环节质量的前沿技术和思考。

? https://www.google.com/url?sa=E&q=https%3A%2F%2Ftxt.cohere.com%2Fblog%2F )

2.2

社区与论坛

Reddit

r/MachineLearning: 定期有关于 RAG 的讨论和最新研究分享。

r/LocalLLaMA: 大量关于在本地运行 LLM 和相关技术（包括 RAG）的讨论。

r/LangChain & r/LlamaIndex: 针对这两个框架的 RAG 实践、问题和解决方案。

Hugging Face、GitHub 这些就不多做赘述了。

这里穿插介绍个 The Batch (DeepLearning.AI），Andrew Ng 团队出品，每周精选 AI 领域的重要新闻和研究，RAG 相关进展常被覆盖。

?https://www.google.com/url?sa=E&q=https%3A%2F%2Fwww.deeplearning.ai%2Fthe-batch%2F 

2.3

播客与访谈

LlamaIndex 播客 (原 The Index by LlamaIndex)

LlamaIndex 团队成员或行业专家讨论 LLM 应用开发、数据框架、RAG 等话题?  https://www.google.com/url?sa=E&q=https%3A%2F%2Fwww.youtube.com%2F%40LlamaIndex )

Latent Space Podcast

由 swyx 和 Alessio 主持，采访 AI 领域的构建者，经常深入探讨 LLM、向量数据库、RAG 等技术细节和实践。? https://www.google.com/url?sa=E&q=https%3A%2F%2Fwww.latent.space%2Fpodcast )

InfoQ 播客

如 Redis 工程师 Sam Partee 分享了关于向量数据库和混合搜索在 RAG 中的应用。? 在 InfoQ 网站或各大播客平台搜索 "InfoQ Podcast Sam Partee"。 

3

工作流介绍

注：为了演示方便，信源部分这里只演示通过 NewsAPI.org 的 api 获取的 RAG 相关资讯

Schedule Trigger (定时触发器)：

作为工作流的起点，按照预设的时间（每天固定时间）自动触发整个流程的执行。

GET_NewsAPI (获取新闻 API)：

通过 HTTP 请求调用外部新闻 API（如 NewsAPI.org)，检索关键词“Retrieval-Augmented Generation”

（注意不要只使用RAG,实测会搜出一些和rag字面意思破布相关的内容）

获取API key(每天100次免费请求）https://gnews.io/docs/v4#authentication 

news_api_article (数据处理/编辑字段 - 手动)：

对从 NewsAPI 获取到的原始数据进行初步的筛选、格式化或字段提取。只保留新闻部分的文字内容。

AI Agent：

核心的内容生成与处理单元，接收上一步处理好的新闻数据，并利用连接的OpenRouter Chat Model（DeepSeek-chat-v3-0324:free ）进行总结、提炼、改写。

注：OpenRouter 中有很多免费的 LLM 可供选择，在测试阶段可考虑使用这个。不过经过测试，一般免费 LLM 的上下文窗口有限，建议内容控制在 2000 字以下。https://openrouter.ai/settings/keys 

Code (代码处理/数据转换)：

在 AI Agent 输出后，通过自定义 JavaScript 代码对生成的内容进行进一步的格式化、转换或数据结构调整。

HTTP Request (企业微信机器人推送)：

将 Code 节点处理好的日报内容，通过 HTTP POST 请求发送到企业微信机器人的 Webhook 地址 (https://qyapi.weixin.qq....)。 

Google Sheets (数据备份与中转)：

将 Code 节点处理好的日报内容（或其核心部分及元数据）追加到指定的 Google Sheets 电子表格中。方便后续的数据分析、内容二次加工（如转语音、深度解读）、以及向个人网站等其他平台发布。

4

推送机制的设计与优化

当把日报内容生成之后，如何自动推送到微信群，是个很重要的一步。以下介绍我探索过的三种方法。简而言之，微信有点特别，自动化发送是种执念，我最后还是权衡下选择了人机结合的方式。

4.1

放弃魔法

首先需要声明，根据《微信软件许可及服务协议》的约束，微信官方对各种形式的外挂明确立场是不支持、不鼓励、严厉打击。我调研了多个基于开源项目的解决方案，这类方案的核心思路是模拟微信客户端的行为，与微信服务器进行通信。从实现原理上说有三种：

iPad/Mac 协议类 (如 Padlocal 等付费方案)：通过模拟 iPad 或 Mac 微信客户端的通信协议，被认为是相对稳定的一种方式（尤其在早期）。这类方案通常需要获取特定的 token 或通过扫码登录。

低版本 Windows/Android 客户端 Hook 类：通过逆向工程或 Hook 特定版本的微信客户端（通常是较旧版本，因为新版本防护更严）来实现消息收发。这种方式可能需要特定的运行环境和客户端版本。

网页版微信 API (已失效)：早期很多机器人基于网页版微信，但该接口已被官方关闭，不再可行。

有一说一，我折了个小号，不建议再尝试了。所以，这也说明了当你去搜公开教程中介绍 AI 日报的，最后都是教你怎么发到 email、teleragm、飞书、notion 等等。或者教你上述前两种的，封号风险了解下。

4.2

官方路径

官方提供的解决方案——企业微信群机器人。

企业微信允许在群聊中添加机器人，并为每个机器人生成一个唯一的 Webhook 地址。外部应用（如 n8n）只需要向这个 Webhook 地址发送特定格式的 HTTP POST 请求（通常是 Markdown 或文本消息），机器人就会将消息内容推送到群聊中。

但这里有个 Bug 是，企业微信机器人只能将消息发送到企业微信内部的群聊。如果最终目标是个人微信群，则无法一步到位。选择这种方式就意味着，不得不采取“先自动推送到企业微信群，再手动复制粘贴到个人微信群”的折中方案。

4.3

RPA 的强大与笨拙

RPA 提供了强大的界面自动化能力，为了克服直接对接个人微信的困难和企业微信的局限，我尝试了另一种自动化思路——使用影刀 RPA 工具来模拟人工操作。

实现原理

RPA 通过识别桌面应用的 UI 元素（窗口、按钮、输入框等）并模拟鼠标点击、键盘输入等操作来完成任务。LLM 生成日报 -> 存入中转站 -> RPA 读取中转站 -> RPA 打开微信 -> 定位群聊 -> 粘贴/输入内容 -> 发送。

中转站的选择

为了让 RPA 能稳定获取日报内容，我把 LLM 的输出分别保存到以下三个地方，实测都可以，具体用哪个看个人喜好：

Notion：优点是排版美观，内容组织灵活。缺点是 API 获取页面内容（尤其是包含多种块类型时）相对复杂，解析 JSON 提取纯文本步骤较多。

Google Sheets/飞书多维表格：优点是结构化数据，API 相对简单，易于读写特定单元格的纯文本。

RPA 模拟输入的风险

我测试发现 RPA 在处理长文本时，不是直接将内容“粘贴”到输入框，而是像人一样通过模拟键盘逐字输入。这种操作不仅带来了高耗时，重点是长时间、高频率的模拟输入可能被微信客户端识别为异常行为，甚至导致客户端崩溃或退出（不要问我是怎么知道的）。搜了下虽然某些 RPA 工具可能提供模拟 Ctrl+C/Ctrl+V 的指令，但猜测微信可能对此类操作也有防护。

4.4

最后选择

经过以上三个阶段的探索和试错，综合考虑稳定性、合规性、维护成本和实现效果，我最终选择了以下方案作为当前 AI 日报发送的最佳实践：

核心发送渠道：使用企业微信群机器人。

n8n 工作流将 AI 生成的日报内容格式化后，通过 Webhook 推送到指定的企业微信群。

手动转发：从企业微信群手动复制内容，再粘贴到个人微信群。这是当前在合规和触达个人微信之间的一个平衡点。

数据沉淀与二次利用：

在 n8n 工作流的末端，将 AI 日报的核心文本内容以及相关的元数据同步保存到 Google Sheets 中，为后续的深度利用提供基础（内容转语音、LLM 深度解读、个人网站发布等）

5

写在最后

构建一个自动化的 RAG 日报系统本身只是手段，充分实践才是真理。但确实要要警惕“闭门造车”。我计划下周开始，陆续把过去半年沉淀下来的一些项目案例进行梳理，制作成视频内容，供不同实践阶段的盆友参考。也欢迎加入付费社群获取更多优质内容。

最后，再说个“过度工程化”的问题，我年初到现在接触过的 180 多家企业里，大部分都对 LLM 本地化部署有些执念，尤其是在没有足够多卡的情况下，选择了一种低配的底座模型。这带来的致命问题是，当 RAG 或者其他特定任务的理解和生成效果不佳时，会让研发投入过多的精力去做复杂的工程化“雕花”和外围系统优化，结果当前是事倍功半。毕竟，工程的价值在于放大模型的优势，而非弥补其根本性的不足