在 AI 时代下，信息源爆炸，为了更好地处理各项信息，驱动我捣鼓了一下 RSS，了解了一下 Follow 生态，想要做 Agent 驱动的信息处理

在 AI 时代下信息源爆炸为了更好地处理各项信息驱动我捣鼓了一下 RSS了解了一下 Follow 生态想要做 Agent 驱动的信息处理进入 AI 时代后我最明显的感受不是“信息越来越难找”而是信息源已经多到处理不过来了。技术文章散落在博客和公众号里项目动态藏在 GitHub行业讨论发生在社交平台视频、播客、邮件和群聊又在不断制造新的入口。AI 进一步降低了内容生产成本每天出现的新文章、新工具和新观点只会越来越多。以前的问题是我去哪里找信息现在的问题变成了信息都来了我怎么判断哪些值得看哪些与我有关又该怎样把它们变成真正可用的知识和行动带着这个问题我最近捣鼓了一下 RSS也顺着源码了解了 RSSHub 与 Follow 生态。这里的 Follow指的是现在已经更名为Folo的开源 AI RSS 阅读器。为了保持学习过程中的语境文中仍会交替使用 Follow 和 Folo。研究完以后我发现 RSS 的意义并不只是“换一个地方看新闻”。它更像一个开放、稳定、可编程的信息入口。Follow 负责把入口组织成阅读体验而我真正想继续做的是在它们之上增加一层由 Agent 驱动的信息处理系统。目录AI 时代真正稀缺的是信息处理能力为什么我重新捡起 RSSRSSHub 与 Follow 分别解决什么问题从订阅阅读走向 Agent 驱动我设想的信息处理链路真正落地时需要守住的边界这次学习带给我的工程启发AI 时代真正稀缺的是信息处理能力很多工具都在帮我们“获得更多信息”。平台用推荐算法持续推送内容搜索引擎帮助我们主动检索AI 又能在几秒钟内生成一份资料清单。单独看每一种能力都很强叠加在一起却容易产生新的问题入口越来越多待处理内容越来越长真正沉淀下来的东西却没有同步增加。我经常遇到这样的场景看到一篇文章先收藏之后再也没有打开。关注了很多信息源但每天只能快速划过标题。同一个新闻被不同账号重复转述占用了大量注意力。读到一个有价值的观点却没有和已有知识建立联系。明明持续输入真正需要写方案或做决策时还是要重新搜索。这让我意识到信息管理不能只解决“收集”。一条完整的信息链路至少包含发现 → 获取 → 清洗 → 去重 → 筛选 → 理解 → 关联 → 沉淀 → 行动传统阅读器通常可以很好地覆盖前半段但越靠近个人目标越需要理解我的项目、兴趣、任务和判断标准。这里恰好是 Agent 可以发挥作用的地方。为什么我重新捡起 RSSRSS 并不是新技术甚至常常被认为带有一点“古早互联网”的味道。但在今天重新理解它我反而觉得它非常适合成为 AI 信息处理系统的输入层。RSS 把不同网站转换成统一接口不同网站的页面结构、推荐机制和登录方式千差万别但只要它们提供 RSS 或 Atom Feed阅读器就能用相对统一的方式获取标题、链接、发布时间、作者和正文摘要。对于人来说这意味着可以在一个地方阅读多个来源对于程序和 Agent 来说这意味着不必为每个站点都设计一套完全不同的输入逻辑。标准化输入是自动化处理能够稳定运行的前提。RSS 让用户重新掌握信息源算法推荐的特点是平台替你决定下一条内容。RSS 的逻辑则相反用户先决定订阅谁再由阅读器按时间或规则呈现更新。它并不能自动消除信息噪声但至少把第一个选择权交还给了用户。我的信息流不再完全依赖某个平台的推荐策略也不会因为平台突然调整算法而彻底改变。RSS 天然适合机器持续消费一个稳定的 Feed 地址可以被定时拉取、缓存、去重和解析。新内容进入系统后还可以继续触发摘要、分类、翻译或知识归档。从这个角度看RSS 不只是一个阅读协议也可以被理解为一种简单的信息事件源。它不像完整消息队列那样提供复杂的投递保证但足够开放、足够通用也非常容易接入个人自动化系统。RSSHub 与 Follow 分别解决什么问题刚开始接触时我很容易把 RSSHub 和 Follow 当成同一类产品。真正读过生态和源码后我才看清它们分别位于信息链路的不同位置。RSSHub 负责把不能订阅的内容变成 Feed如果一个博客已经提供标准 RSSFollow 可以直接订阅RSSHub 完全不需要介入。但现实中还有大量网站没有提供 Feed。RSSHub 会根据不同网站编写路由通过页面或公开接口取得内容再转换成标准的 RSS、Atom 或 JSON Feed。链路大致是Follow 请求 RSSHub 路由 → RSSHub 请求目标网站 → 解析 HTML 或 API → 组装结构化数据 → 输出 FeedRSSHub 扩大的是“什么内容可以被订阅”的边界。它的工程价值也不只是爬取。路由负责理解具体站点通用中间层负责缓存、过滤、全文提取和格式输出。站点差异与协议处理被拆开后社区才能持续维护大量信息源。当然这条链路也有脆弱的一面。公共实例访问量大可能触发目标网站的限流、鉴权或反爬策略页面和接口变化也可能让原有路由失效。自建 RSSHub 可以提升控制力但并不意味着从此高枕无忧。Follow 负责把 Feed 变成现代阅读体验Follow 现在已经更名为 Folo项目将自己定位为 AI RSS Reader。它处理的是订阅之后的问题如何管理信息源、同步状态、展示文章、视频、图片和音频以及怎样用摘要、翻译等 AI 能力降低阅读成本。从源码结构看Folo 是一个持续演进的跨平台项目。桌面端、移动端和共享能力被放在同一个 Monorepo 中管理背后需要处理多端同步、离线数据、已读状态、收藏、列表以及不同内容形态的展示。Folo 改善的是“订阅之后怎样消费”的体验。因此两者之间并不是替代关系有原生 Feed 时Folo 可以直接订阅。没有原生 Feed 时RSSHub 可以补上转换层。有了 Feed 之后仍然需要阅读器或其他系统负责消费。如果把整个生态看成一条生产线RSSHub 更像输入适配器Folo 更像面向人的工作台。从订阅阅读走向 Agent 驱动RSS 和 Follow 已经解决了很多问题但它们依然没有完全解决我的核心诉求。因为我的目标不是每天内容而是让真正有价值的信息更快进入当前工作。例如同样一篇关于 AI Agent 的文章对不同人可能意味着完全不同的事情对产品经理它可能是一条产品趋势。对开发者它可能包含可以验证的新框架。对正在做某个项目的人它可能正好命中一个设计难点。对暂时没有相关任务的人它也许只需要进入稍后阅读。判断这些差异需要的不只是理解文章还要理解“我现在正在做什么”。这就是我想引入 Agent 的原因。Agent 不只是生成摘要让大模型给每篇文章写一段摘要是最容易实现的一步但这还称不上完整的信息处理。我更期待 Agent 能完成下面这些工作根据我的长期关注方向对内容做初步筛选。识别多个来源是否在讨论同一件事减少重复阅读。区分事实、观点、教程、宣传和二手转述。找出内容与当前项目、任务或已有知识之间的关系。把真正需要阅读的内容排进收件箱而不是全部推给我。把可以直接执行的事项转换成待办、调研问题或验证任务。保留原文链接和处理依据让所有结论可以回查。摘要只是压缩内容Agent 真正的价值应该是结合上下文做路由与转化。Follow 是工作台Agent 是处理流水线Folo 已经提供 AI 摘要、翻译等能力但一个面向大众的阅读产品很难天然了解每个人的本地项目、知识库结构和工作习惯。我设想的方式不是重新做一个 Follow也不是让 Agent 取代阅读器而是让两者分工RSSHub 和原生 Feed 负责提供稳定输入。Follow 负责订阅管理与人工阅读。Agent 负责按个人目标进行筛选、加工和分发。本地知识库、任务系统或日报负责承接最终产物。这样人仍然保留判断权Agent 则承担重复、机械且可以规则化的处理工作。我设想的信息处理链路如果把这个想法做成一个最小可用系统我不会一开始就追求“全自动信息大脑”而是先跑通一条可观察、可纠错的链路。建立信息源清单第一步不是写 Agent而是明确我要长期跟踪什么。每个信息源至少记录名称、Feed 地址、主题、可信度、更新频率和保留策略。原生 Feed 优先没有原生 Feed 时再考虑 RSSHub 路由。这张清单决定了系统吃进去什么。如果源头本身没有边界后面的 AI 再聪明也只是在更高效地处理噪声。统一进入原始信息箱系统定时获取 Feed把新条目写入统一的原始信息箱并保存来源、原文地址、发布时间和抓取时间。这里最重要的是去重和幂等同一篇文章被重复拉取时不能重复触发后续处理不同来源转载同一事件时也应该尽量识别为相关内容。原始数据需要保留。Agent 的摘要和判断可能变化只有保留原文后续才能重新处理和回查。让 Agent 分层处理与其让一个大 Prompt 一次完成所有任务我更倾向于把处理拆成几层基础清洗移除广告、导航和无效文本统一字段。内容识别判断主题、内容类型、语言和大致质量。个人相关性结合当前项目与关注方向计算优先级。关联分析查找相似信息、已有笔记和潜在冲突。输出路由决定进入阅读箱、知识库、待办还是直接忽略。每一层都应该留下简单的结果和理由。这样当系统判断错误时我可以知道问题出在信息源、规则还是模型而不是面对一个无法解释的最终答案。把信息转换成不同产物并不是所有内容都应该变成一篇笔记。有些内容只需要一句提醒有些适合进入每日报告有些应该和现有主题建立链接有些则应该转化为一个需要验证的任务。我希望最终形成几类明确出口今日必读数量有限确实值得投入注意力。主题摘要合并同一事件的多个来源减少重复信息。知识候选与长期研究方向有关等待人工确认后沉淀。行动候选可以转化为调研、开发或验证任务。低优先级归档暂时无关但保留检索能力。真正有效的信息处理不是把所有内容塞进知识库而是让不同信息去往合适的位置。用人工反馈修正规则Agent 不可能一开始就准确理解我的偏好。我需要持续告诉它哪些推荐有用哪些只是看起来相关哪些来源虽然更新频繁但价值不高哪些主题应该临时提高优先级。这些反馈可以逐步变成明确规则而不是永远依赖更长的 Prompt。真正落地时需要守住的边界Agent 驱动听起来很美好但如果没有边界它也可能制造出新的信息垃圾。不把模型结论伪装成原文事实任何摘要、分类和关联都应该保留原文链接。模型生成的判断需要与来源事实分开重要结论还应允许人工回查。不追求一开始就全自动自动收藏、自动写笔记的风险相对可控自动创建外部任务、发送消息或发布内容则可能产生真实副作用。因此我更愿意先让 Agent 生成候选结果由人确认后再进入外部系统。只有规则稳定、错误成本足够低的环节才逐渐自动化。不让知识库变成另一个垃圾场如果每篇文章都自动生成摘要并永久保存知识库很快就会被低质量内容淹没。知识沉淀应该有门槛它需要与已有主题产生关系或者对未来决策具有复用价值。无法说明用途的信息可以留在可检索的归档层而不是进入核心知识区。不忽略信息源本身的稳定性RSSHub 路由可能失效源站可能调整接口Feed 也可能只提供摘要。系统需要记录抓取异常和最后成功时间否则 Agent 没有输出时很难区分“今天没有新内容”和“信息链路已经断了”。这次学习带给我的工程启发这次捣鼓 RSSHub 和 Follow我最大的收获并不是掌握了几个订阅技巧而是重新理解了信息系统的分层。先解决输入标准化再讨论智能如果输入来源不稳定、字段混乱、重复数据严重直接叠加大模型只会让结果更不可控。RSS 和 Atom 提供的统一结构恰好为 Agent 处理打下了基础。协议、平台与个人自动化各有职责RSS 负责开放格式RSSHub 负责扩展信息源Follow 负责阅读体验Agent 负责个人化处理。把每一层的边界分清比试图用一个“万能工具”包办所有事情更可靠。AI 应该减少决策负担而不是增加阅读量如果使用 AI 后我每天收到的摘要从 20 条变成 200 条那么系统只是提高了噪声生产效率。Agent 最重要的指标不应该是“处理了多少文章”而应该是它是否帮助我更早发现重要信息是否减少了重复阅读是否让有价值的内容真正进入了项目和行动。写在最后AI 时代不会缺少信息甚至也不会缺少总结信息的工具。真正稀缺的是一条由自己掌控、能够理解个人目标并且可以持续纠错的信息处理链路。RSS 给了我一个开放、稳定的信息入口RSSHub 扩大了可以接入的来源Follow 提供了现代化的订阅与阅读体验。下一步我想尝试把 Agent 放在这条链路中间让它承担清洗、去重、筛选、关联和分发。我并不期待它替我阅读和思考。我期待的是当真正值得投入注意力的信息出现时它能更早、更准确地把内容送到我面前当一条信息可以推动项目时它不再停留在收藏夹里而是进入下一步行动。这或许就是我理解的 Agent 驱动信息处理不是拥有更多信息而是让信息更稳定地转化为认知与行动。如果你也在尝试用 RSS、Follow 或 Agent 管理自己的信息流欢迎在评论区聊聊你的做法。参考资料RSSHub GitHub 仓库Folo GitHub 仓库W3C WebSub RecommendationAtom 1.0RFC 4287RSS 2.0 Specification