二途序

RSS 就是消息队列：搭一套内网自持的信息源 AI 学习系统

信息输入的问题

做技术的人每天面对三个输入难题：

  • 散：博客、新闻、视频收藏各在各的平台，人肉刷既低效又焦虑
  • 贵：网页搜索、抓取走外部 SaaS 按次收费，LLM 走外部 API 花钱且数据出网
  • 伪时效：总觉得信息要」追实时」，但个人学习场景里，晚几小时读毫无损失

这周我在新装的 Linux 笔记本上立项了 rss-reader，把这三个问题一次处理。核心认知只有一句话：RSS 本身就是消息队列。

RSS 就是消息队列

RSS（Really Simple Syndication，内容订阅的标准格式）常被当成」老技术」。但换一个视角看，它具备消息队列的全部核心性质：

消息队列性质 RSS 的对应
消息持久化 条目发布后一直存在，不会过期消失
拉取式消费 消费者自己定节奏，随时拉取
天然削峰 一天不读，积压都在，不丢不乱
解耦生产消费 作者发布与读者阅读完全异步

想清楚这一点，系统的消费模型就直接定型了：

flowchart LR
    S1[博客] --> Q[RSS 源<br/>= 持久化队列]
    S2[新闻] --> Q
    S3[自建源<br/>auto-trend / 视频源] --> Q
    Q -->|每日限额拉取| C[AI 分析]
    C --> R[报告 Markdown]

** 每日限制读取，不追时效。** 因为条目不会消失，限流消费即可，不需要为」实时性」付任何设计成本。这也是 rss-reader 后来演进成 Tier1 全量分析 + Tier2 零 AI 选取的两段式管线的思想起点 —— 成本按预算花，深度按重要性给。

系统架构：内网自持

系统三段式：输入（RSS 多源聚合）→ 处理（AI 分析）→ 输出（报告 Markdown）。

flowchart TB
    subgraph 输入
        FEED[RSS 源聚合<br/>管理后台扩充]
    end
    subgraph 处理
        AI[AI 分析<br/>概述 / 总结 / 归纳]
        AGENT[agent 联网调研补全<br/>信息不全时主动查证]
    end
    subgraph 底座 Linux 笔记本
        FC[firecrawl 内网部署<br/>websearch / webcrawl]
        LLM[llama.cpp 本地 3B<br/>分类 / 摘要]
    end
    subgraph 输出
        RPT[报告 Markdown<br/>每日学习简报]
    end
    FEED --> AI --> RPT
    AGENT --> AI
    FC --> AGENT
    LLM --> AI

几个关键取舍：

  • 前端复用不重写：把已有项目 Horizon 改造成 RSS 分析前端，再演进为独立项目（支持 agent 联网调研补全分析）
  • firecrawl 内网部署：开源的网页抓取与搜索服务跑在自己机器上，websearch / webcrawl 不依赖外部 SaaS，成本归零、数据不出网
  • 管理后台管源的扩充与聚合：自建源（GitHub trending 的 auto-trend、视频源解析项目）产出 RSS 即可接入，零适配

本地 3B 模型的能力边界

分析任务里分类、摘要这类轻活，交给本地模型。在 Linux 笔记本上用 llama.cpp 跑 granite 3B（Q4_0 量化，上下文 32K），实测出两条有价值的数据。

一是连通性坑：pi（终端 AI 代理）一直连不上服务。根因是 llama-server 默认绑定 127.0.0.1，只回环可达，局域网访问不通。改成 --host 0.0.0.0 解决。这个坑极其常见：127.0.0.1 永远只指当前机器。

二是性能天花板：生成速度约 16 token/s，此时内存带宽占用已到双通道峰值的八成 —— 瓶颈是硬件带宽，软件调参已无空间。进一步实测：这台机器内存实跑 2667 MT/s 是平台上限；核显卸载（把层卸到 iGPU）不升反降，生成速度反而降约四分之一，因为核显与 CPU 共享同一套内存。

结论很清晰：3B 本地模型做分类、摘要够用且零成本，重分析交给外部大模型。任务分层，各得其所。配套还有一条：小模型的提示词要少而显式，规则一多它会漏执行。

这周其他内容一句话带过：双机协同环境配好（VS Code 配置同步、RDP 远程桌面、pi 开箱可用），视频源分析项目调试完成。

参考资料