2026/5/23

n8n 多源信息获取、筛选与摘要推送工作流

记录基于 n8n 的信息获取工作流：RSSHub 订阅 Bilibili、HTTP Request 获取 YouTube 官方 RSS、XML 拉平、24 小时过滤、LLM 摘要和多端推送。

这篇记录当前正在使用的 n8n 信息获取工作流。目标不是做一个单一 RSS 阅读器，而是把不同来源的信息先统一成结构化条目，再交给后续筛选、摘要、分类和通知模块处理。

目标

工作流主要解决三件事：

• 定时获取 YouTube、Bilibili、科技媒体、论文和热榜等来源。
• 将不同节点返回的数据统一成同一套字段，避免后续节点分别适配每个来源。
• 只处理近期新内容，再通过 LLM 总结后推送到飞书、ntfy 或其它通知通道。

核心原则是：抓取节点尽量简单，复杂逻辑集中在规范化、过滤和摘要阶段。

当前结构

整体结构可以概括为：

Schedule Trigger
  -> 来源配置
  -> Split Out
  -> 抓取节点
  -> 规范化 Code
  -> Merge Append
  -> 24 小时过滤
  -> LLM 摘要/分类
  -> 推送

不同来源可以并行维护，但进入 LLM 之前都要整理成统一字段：

source
 title
 link
 published
 updated
 author
 summary
 thumbnail
 views
 raw

这样后面的过滤、去重、摘要和消息模板只依赖这一套字段。

Bilibili：RSSHub + Cookie

Bilibili 不直接使用公共 RSSHub 实例，而是在本地 Debian Docker 中部署 RSSHub。

容器结构：

/opt/apps/rsshub
  -> rsshub
  -> rsshub-redis

RSSHub 加入 n8n 的 Docker 网络后，n8n 可以直接通过容器名访问：

http://rsshub:1200/bilibili/user/video/<uid>

n8n 中使用：

http://rsshub:1200/bilibili/user/video/{{ $json.feeds }}

Bilibili 路由触发风控时，需要在 RSSHub 的 .env 中配置登录 Cookie 和必要的风控参数。Cookie 属于登录凭据，只保存在服务器本地，不写入博客、截图或仓库。

如果 RSSHub 返回 503，先看错误正文，而不是只看状态码：

curl -s http://127.0.0.1:1200/bilibili/user/video/<uid> | grep -A 8 "Error Message"

常见问题：

风控校验失败 -> 更新 Bilibili Cookie
Playwright executable missing -> 使用 diygod/rsshub:chromium-bundled
rsshub-cache-status: HIT -> 清 Redis 缓存后重试

清缓存：

docker exec rsshub-redis redis-cli FLUSHALL

YouTube：HTTP Request 获取官方 RSS

YouTube 没有继续使用 n8n 的 RSS Feed Read 节点，因为该节点在当前环境中容易超时。实际采用：

HTTP Request -> XML -> Code 拉平

HTTP Request 节点：

Method: GET
URL: https://www.youtube.com/feeds/videos.xml?channel_id={{ String($json.feeds).trim() }}
Response Format: Text
Put Output in Field: data

如果服务器没有透明代理，YouTube 节点可以单独配置代理，而不是给整个 n8n 容器配置全局 HTTP_PROXY。

为什么不建议全局代理：全局代理可能把 Docker 内网地址，例如 rsshub、postgres、redis，也交给代理处理，导致内网服务异常。更稳的做法是：

Bilibili -> RSSHub 内网
YouTube -> HTTP Request 节点单独代理
国内接口 -> 直连

YouTube XML 拉平

YouTube 官方 RSS 返回 Atom XML。HTTP Request 后接 XML 节点：

Mode: XML to JSON
Input Field: data
Output Field: parsed

再用 Code 节点把 feed.entry 拉平成 n8n items。核心输出字段：

source: 'youtube',
title,
link,
published,
updated,
author,
summary,
videoId,
channelId,
thumbnail,
views,
raw

拉平后，YouTube 和其它来源就可以一起进入 Merge 与过滤节点。

Bilibili 字段规范化

Bilibili RSS 节点通常已经输出结构化数据，但字段名和 YouTube 不一致，所以也接一个 Code 节点统一字段：

source: 'bilibili',
title: item.json.title,
link: item.json.link || item.json.guid,
published: item.json.isoDate || item.json.pubDate,
author: item.json.creator || item.json.author,
summary: item.json.contentSnippet || item.json.content,
raw: item.json

这样后续节点只判断 published，不再关心来源。

24 小时过滤

筛选条件使用 published，而不是 updated。

原因：

• published 表示内容发布时间，适合判断是否为新内容。
• updated 可能因为标题、描述、统计数据变化而更新，不适合判断新视频或新文章。

过滤条件：

{{ $json.published }}

is after：

{{ new Date(Date.now() - 24 * 60 * 60 * 1000).toISOString() }}

如果某个来源字段不稳定，可以在规范化 Code 中提前兜底，而不是在过滤节点写复杂表达式。

摘要与推送

通过 24 小时过滤后，内容进入 LLM 节点做摘要、分类和排序。摘要结果再根据类型进入不同推送通道。

当前推送方式包括：

飞书机器人
ntfy topic
HTTP Request 自定义接口

推荐把发送账号做成只写权限。例如 ntfy 中：

n8n-jesiyar -> 只写 n8n 通知 topic

这样即使 n8n 凭据泄露，也不能读取历史通知。

部署与网络要点

本地服务关系：

n8n-main / n8n-worker
  -> Docker 网络访问 rsshub:1200
  -> PostgreSQL / Redis 内网访问
  -> 需要海外站点时使用 sing-box

sing-box 当前采用普通 mixed 代理监听：

0.0.0.0:7897

这意味着它不会自动接管所有程序流量。需要访问海外站点的节点，可以单独指定代理；Docker 拉镜像时也可以临时配置 Docker daemon 代理。

如果未来要做到“所有程序自动国内直连、国外代理”，再考虑 TUN 或透明代理模式。当前工作流优先保持节点级可控，避免全局代理影响 Docker 内网服务。

排障记录

RSSHub 返回 503

先看错误正文：

curl -s http://127.0.0.1:1200/<route> | grep -A 8 "Error Message"

不要只看 curl -I。RSSHub 会把具体错误写在 HTML 里。

n8n 能连 RSSHub 但仍然失败

如果看到：

Connecting to rsshub:1200
HTTP/1.1 503 Service Unavailable

说明 n8n 到 RSSHub 网络是通的，问题在 RSSHub 抓上游。

YouTube RSS Feed Read 超时

换成：

HTTP Request -> XML -> Code

不要强行使用 RSS Feed Read 节点。

YouTube URL 里出现 %20

%20 是空格。URL 表达式中不要写：

channel_id= {{ $json.feeds }}

应写：

channel_id={{ String($json.feeds).trim() }}

后续改进

后续可以继续补充：

• 每个来源的去重缓存。
• 按来源设置不同更新频率。
• 对 LLM 摘要结果做结构化评分。
• 将重要结果保存到数据库或静态归档页。
• 将失败来源推送到 ntfy 告警 topic。