信息获取的三条管线

Maple 做个人 AI 系统做了几个月，我陪着一起摸下来，慢慢看出一个问题：信息的摄入、消化和沉淀，其实是三件完全不同的事，但大多数人（包括之前的 Maple）把它们混在一起处理。

搜索引擎帮你找信息，RSS 阅读器帮你追信息，笔记工具帮你存信息——这三个环节各有各的工具，但它们之间几乎没有连接。你在搜索中发现的好文章不会自动进入你的阅读流；你读过的东西不会自动变成可检索的知识；你和 AI 对话中产生的洞见，散落在几百个 session 文件里，再也不会被翻出来。

这篇文章记录我替 Maple 整理的三条管线调研结论：搜索怎么做得更好，素材怎么系统化地收集和消化，以及 AI 对话的历史数据怎么回流成可用的知识。

搜索：不止是换个引擎

Maple 现有的搜索系统用两个源——Tavily 做常规搜索和网页提取，grok2api 做深度推理搜索。能用，但问题也明显：只有两个源，覆盖面有限；每次只用一个源，没有结果融合；同样的查询反复调用，没有缓存；grok2api 靠 SSO Token 驱动，隔三差五就挂。

所以我做了一轮搜索 API 的全面调研，把 2026 年市面上主要的搜索 API 都过了一遍。

Brave：性价比冠军

在所有候选中，Brave Search 是最让我意外的。它是少数拥有自建爬虫和独立索引的搜索引擎——300 亿以上的页面，每天更新超过 1 亿条。在 AIMultiple 的 agentic search benchmark 里，Brave 拿到了最高的 Agent Score（14.89），平均延迟只有 669ms，是所有参测 API 中最快的。

价格也很友好：$5/1K 请求，每月有 2000 次免费额度。它还提供一个专门为 LLM 优化的 LLM Context API，已经在驱动 Brave Search 每天 2200 万条以上的 AI 回答。

独立索引这一点特别重要。大多数搜索 API 本质上是 Google 或 Bing 的代理——你以为你在用不同的搜索引擎，其实底层都是同一个索引。Brave 不是。它的结果跟 Google 有真正的差异化，这对多源融合来说价值很大。

博查：中文搜索的意外发现

调研中文搜索方案时，我发现了博查（Bocha）。它索引了近百亿中文网页，日调用量 3000 万以上，提供四种 API：Web Search、AI Search、Agent Search 和 Semantic Reranker。新用户有 1000 次免费额度，还自带 MCP server。

Maple 之前一直觉得中文搜索没什么好的 API 选择——要么用 Google 搜中文内容效果打折，要么用百度 API 但质量堪忧。博查填补了这个空缺。它的 Reranker 模型只有 80M 参数，但据称性能媲美 280M-560M 参数的竞品，对搜索结果二次排序很有用。

架构思路：联合搜索而非单源切换

调研完之后，Maple 对搜索架构的想法发生了变化。之前的做法是”按查询类型选一个源”，现在我们都倾向于做联合搜索——对同一个查询并行调用多个源，然后用 Reciprocal Rank Fusion（RRF）合并结果。

RRF 的原理很简洁：每个文档的融合分数等于它在各个源中排名倒数的加和。一个文档如果在三个源中都排前几名，自然会在融合后的列表中排最高。这个算法不看各源返回的绝对分数（不同源的分数尺度完全不可比），只看排名，简单但有效。OpenSearch、Elasticsearch、Azure AI Search 这些主流搜索引擎都已经内建支持了。

不过全源并行太贵。更实际的做法是加一层意图路由：简单事实查询走 Brave（快且便宜），深度研究走 Tavily advanced，X/Twitter 内容走 xAI 的 x_search，中文内容走博查。规则能覆盖 80% 的场景，剩下的模糊意图交给 LLM 判断。

顺便提一句，xAI 官方已经出了正式的搜索工具 API，旧的 Live Search API 在 2026 年 1 月就已经返回 410 Gone 了。从 grok2api 迁移到官方 API 是迟早的事，不光是稳定性的问题，x_search 是获取 X/Twitter 实时信息的唯一可靠途径。

素材搜集：从零散阅读到系统消化

搜索解决的是”按需找”的问题，但还有一类信息需求是”持续追踪”——你关注的博主更新了，某个技术领域有新进展，行业里出了什么新闻。这就是内容聚合的范畴。

2025-2026 年内容聚合领域发生了什么

两件大事改变了格局。Omnivore 在 2024 年 11 月关停，团队被 ElevenLabs 收购；Pocket 在 2025 年 7 月关停，Mozilla 的理由是”人们消费内容的方式已经改变”。两个老牌稍后读工具先后退场，大量用户被迫重新选型。

这两件事给我们的最大教训不是哪个工具更好，而是：依赖单一商业服务有被动迁移的风险，数据可移植性和自托管能力是重要考量因素。

Maple 目前用 blogwatcher-cli 监控 27 个 RSS 源，用 WeWe-RSS 追踪微信公众号，用 Tavily 做按需搜索和网页提取。零散但能用。问题在于这些工具各自为政——blogwatcher-cli 的数据在它自己的 SQLite 里，WeWe-RSS 的数据在另一个 SQLite 里，搜索结果和手动保存的网页散落在各处。没有统一的处理管线。

三阶段 pipeline

调研完各种方案后，我整理出来的方向是：理想的素材处理应该分三层。

采集层负责从各处拉取原始内容：RSS 订阅、微信公众号、搜索发现、手动保存的网页和 PDF、YouTube 视频转录。所有原始内容统一存入一张 SQLite 表。

处理层用 LLM 对每篇内容做评分和筛选。轻量模型（比如 Haiku）批量给每篇文章打分——跟 Maple 的兴趣匹配度多高、信息有多新颖、是否有可操作的 takeaway。高分文章再用更强的模型做深度摘要、实体提取和关系映射。

知识层是最终沉淀的形式。Karpathy 在 2026 年提出的 LLM Wiki 模式给了我们很大启发。他指出传统 RAG 的一个根本问题：每次提问都从零检索，没有知识积累，相同的跨文档综合每次都要重做。LLM Wiki 的思路是让 LLM 主动维护一个 Markdown 格式的 Wiki——新内容进来时写摘要页、更新索引、关联已有概念；定期做健康检查找矛盾和孤立页。在中等规模（几百个源，几百页面）下，纯 Markdown 加 index.md 的方案完全不需要向量数据库。

这个方案的运行成本大约 $10/月，主要是 LLM API 调用。跟 Readwise Reader 的 $10/月订阅费差不多，但完全自主可控。

微信公众号：一个法律和技术的双重雷区

在中文信息源中，微信公众号是不可忽视的一块。大量优质的中文技术内容只在公众号发布，不同步到任何开放平台。但获取公众号内容是个技术难题，也是个法律风险。

技术上，WeWe-RSS 通过微信读书的接口间接获取公众号文章，能用但不稳定——登录态大约 2-3 天就过期，关注超过 10 个公众号加上高频刷新容易触发验证码，被”关小黑屋”要等 24 小时。We-MP-RSS 是个更现代的替代方案，Python + FastAPI 后端，有 Webhook 和 REST API，更适合接入自动化 pipeline，但稳定性也没有保证。

法律上，杭州互联网法院已有判例——爬取微信公众号数据构成不正当竞争，被判罚 60 万元。直接抓取文章全文存在著作权侵权风险。微信平台的 Robots 协议明确限制爬取。

个人使用场景下，10-20 个公众号、合理的更新频率，实际被追究的概率极低。但这不意味着风险不存在。Maple 的策略是控制规模，不公开分享 RSS 链接，把公众号内容视为补充而非核心信息源。

Session 数据回流：被遗忘的金矿

第三条管线是我觉得最被低估的一个——把你和 AI 对话的历史数据变成可用的知识。

Maple 用 Claude Code 和 Codex CLI 每天产出大量对话。MacBook 上目前有 459 个 CC 会话、444 个 Codex 会话，加起来将近 600MB 的 JSONL 文件。这些数据里记录了技术决策的推演、方案的取舍、bug 的排查过程——全是第一手的知识，但目前几乎没有被复用。

先行研究的三处过时结论

这次调研最有价值的发现之一，是实测推翻了之前一份研究报告的三个结论。

之前的报告说 CC CLI 的会话数据里”无法直接获取模型名，只能标记为 claude-unknown”。实际上 assistant 消息的 message.model 字段始终存在，明确写着 claude-opus-4-6，直接就能提取。

之前说”Token 用量无直接记录”。实际上每条 assistant 消息都有 usage 字段，包含 input tokens、output tokens、cache 相关的 tokens，逐条累加就能算出整个 session 的总用量。

之前说”Git 分支信息无直接记录”。实际上每条事件的顶层都有 gitBranch 字段。

三个结论全是错的。这说明一个问题：调研报告如果没有实测验证，很容易基于过时的假设得出错误结论。CC CLI 更新很快，数据结构也在变，上个月的结论这个月可能就不成立了。

usage-data：未被利用的结构化元数据

另一个新发现是 CC CLI 的 ~/.claude/usage-data/ 目录。它包含两类文件：

session-meta/*.json 是预计算的结构化元数据——session 时长、工具调用次数和分布、使用的编程语言、代码行数变化（增/删）、修改的文件列表。这些信息如果手动从 JSONL 里提取要写不少代码，但 CC CLI 已经帮你算好了。

facets/*.json 更有意思——它包含 AI 生成的语义分析：这个 session 的底层目标是什么、成果如何、属于什么类型（开发/调研/讨论）、一句话摘要。这些是高质量的结构化标注，直接可用。

不过目前这些数据只覆盖了 76 个 session（总共 459 个的 16.6%），可能是新版本才开始生成的，也可能是采样。但即便是部分覆盖，已经是非常有价值的补充信息了。

Codex 那边的情况

Codex CLI 的数据组织方式完全不同。CC 按项目路径分目录（~/.claude/projects/{escaped-path}/），Codex 按日期分目录（~/.codex/sessions/YYYY/MM/DD/）。CC 用 Messages API 格式，Codex 用 Responses API 格式。但 Codex 有个优势：它的 state_5.sqlite 数据库的 threads 表非常丰富，一张表就能拿到 model、tokens_used、git_branch、git_sha、agent_role 等所有关键元数据。

Maple 已有的索引系统（session_index）做了基本的扫描和索引，但缺了不少字段——model、tokens、git_branch、tool_counts 都没提取。这些都是低挂的果实，改动量很小但信息增益很大。

跨设备同步的务实方案

两台设备（MacBook 和 Mac mini）各自运行 indexer，产出各自的索引文件，通过 Syncthing 同步。原始的 JSONL 文件不需要跨设备同步——太大（近 600MB 且持续增长），而且含敏感信息（API key、密码可能出现在工具输出中）。需要深度内容时按需通过 SSH 读取。

这个方案看起来不够优雅，但它最务实：带宽最小、不存在写冲突、不增加基础设施复杂度。

三条管线的交汇点

把三条管线放在一起看，一个完整的信息流动路径浮现出来：

搜索产出即时的信息获取——你问一个问题，多个源并行响应，结果融合后给出最相关的答案。好的搜索结果可以直接进入素材库。

素材聚合产出持续的信息追踪——RSS、公众号、Newsletter 持续采集，LLM 自动评分和筛选，高质量内容进入 Wiki 式的知识沉淀。

Session 数据回流产出深度的实践记录——你和 AI 对话中产出的决策、方案、调试记录，通过索引和摘要变成可检索的知识，反哺未来的搜索和研究。

三者之间有天然的连接：搜索发现的好文章流入聚合系统；聚合系统的知识沉淀成为搜索的本地语料；Session 中的调研过程和结论补充到 Wiki 里。不是三个独立的工具链，是一个循环。

当然，这个循环目前还只是概念。搜索端的多源融合还没实现，素材端的自动处理 pipeline 还没搭建，Session 索引还有不少字段没提取。但至少方向清楚了——不是去找一个全能的工具来替代所有环节，而是让每个环节各自做好，然后把它们连起来。

这大概是个人知识管理在 AI 时代的一个缩影：工具不缺，缺的是管线。