超级个体的情报系统：从信源监测到可靠行动

最危险的简报，可能一条内容都没有

早上打开每日简报，页面上显示 0 条新内容。也许昨夜确实风平浪静；也可能是 RSS 路由坏了、API 开始返回空页，或者凭据在凌晨过期。从读者这一端看，这几种完全不同的状态只有同一个样子：安静。

这正是个人情报系统给我的第一课。把更多信息搬进一个入口很容易演示，难的是知道机器是否健康、摘要有没有忠于原文，以及某个信号是否真的值得行动。我想要的不是一个会自动发内容的账号，而是一条能回答四个问题的流水线：什么变了，为什么可能重要，证据在哪里，接下来要不要改变动作。

这篇文章把《从信息到创作》 里的认知路径，落成一条可以长期运营的工程闭环。它是一张责任地图，不是声称所有信源和决策都能被塞进同一种完美架构。

信息要进入具体处境，才会成为情报

信息聚合器和情报系统可以读取同一批信源，最终交付的东西却不同：

• 聚合器优化的是送达：条目更多、更新更快、少开几个网站。
• 情报系统服务的是决策：保留来源、过滤可避免的噪音、暴露不确定性，再把有价值的信号送到人或一个有边界的工作流面前。

这并不意味着每条信息都要触发动作。“暂时不做”同样可以是一项经过思考的决定。真正的验收标准，是系统有没有提供足够证据，让我改变、确认，或者有意识地维持下一步。

这个区分能解释一种常见错觉。翻译、摘要、自动发布让信息流看起来已经加工完成，判断却仍然全部留给读者。界面变漂亮了，注意力成本只是被搬到了下游。

用订阅、轮询和查询设计采集

我习惯用三种模式拆解信息获取：

这是一套操作模型，不是“人类获取信息恰好只有三种方式”的自然定律。三者本来就会重叠。用户把 RSS 放进阅读器时，体验上叫订阅，阅读器通常仍在定时轮询 URL；只有接入 WebSub 或 webhook 之类的机制，更新才可能及时推送。一次 Agent 查询，也可能在背后轮询好几个 API。

这套模型仍然有用，因为它逼我回答一个工程问题：这个源有没有稳定契约，我是否必须自己检测变化，还是正在调查一个开放问题？

把兴趣编译成可版本化的信源定义

“我关注 AI Infra”不能被机器执行。一份信源定义可以写成：

id: github-model-context-protocol-releases
mode: poll
source: https://api.github.com/repos/modelcontextprotocol/servers/releases
interval: 6h
owner: ai-infra
expected_max_silence: 30d
priority: high

具体字段可以变化，重要的是把假设摆到台面上：谁负责这个源，多久检查一次，安静多久算异常，失败后有多着急。配置应该进入版本控制，密钥不应该。

根据信源契约选适配器，不追工具时髦

原生 RSS 与 Atom

发布者维护 feed 时，我会先用 feed，再考虑抓渲染后的页面。稳定 ID、时间戳和 canonical URL 往往能减轻下游处理，但 feed 也不是天然可靠：正文可能只有摘要，条目会被修改，GUID 也可能变化。

至少记录最近一次成功拉取、HTTP 状态、条目数量、最新条目时间和重复 GUID 比例。连续返回 200 却几个月没有新条目，仍然可能是信源坏了。

RSSHub

RSSHub 用社区维护的路由，把许多站点内容转换成 RSS 兼容 feed。这种归一化很有价值，但它没有把只能拉取的源变成真正的推送流；除非再接一层投递机制，阅读器或采集器仍要主动请求路由。

路由本质上是上游站点的适配器。HTML、鉴权、反爬规则或上游 API 一变，它就可能失效。有些路由需要 cookie、token、浏览器渲染或自托管实例。一个准备长期使用的路由，至少要记录：

• 路由文档和必需参数；
• 是否涉及凭据；
• 预期更新频率；
• 备用信源或可接受的中断策略；
• 能发现结构漂移的小型 fixture 或健康检查。

“订阅一切”很诱人。“知道哪些适配器是我真正运营得起的”，才是更稳妥的原则。

官方 API 与 webhook

官方 API 通常比抓页面拥有更清楚的契约，但“官方”不等于永久稳定，也不等于没有成本。版本变化、分页、限流、权限和数据保留周期，仍然属于系统设计。

例如，GitHub 明确提供仓库 Releases REST API ，却没有为 GitHub Trending 页面公开一个对应的 REST endpoint。因此，我不会再把 Trending 写成官方 API 信源。确实需要这份榜单时，就把它视为网页监测，或使用第三方数据集并明确接受维护风险。

产品 changelog 也一样：有的提供 feed 或 API，有的只是一张页面。契约必须逐个核验，不能按类别想当然。

网页变更监测

当我只关心一个已知页面，而它没有合适的 feed 或 API，轮询就很合适。监测器可以抓取页面、圈定 selector、消除无关标记，再在关键区域变化时产生事件。

难点从来不是做 diff，而是避免 cookie 弹窗、旋转时间戳、个性化内容和 A/B 测试变成“信号”。应保存 selector、代表性 fixture 和最近一次已接受快照。页面需要登录态浏览器时，要把 session 当作凭据，并把权限收窄。

搜索与 Agent 调查

查询补的是已知信源与未知问题之间的空白。普通搜索返回候选；Agent 还能规划多轮搜索、打开来源、比较说法，并判断是否需要补证据。

这是一种有用的流程能力，却不能直接等同于可靠“判断”。一次可审计的研究运行应保留：

• 原始问题和范围；
• 实际发出的查询与读过的页面；
• 引用片段或证据位置；
• 发布时间和获取时间；
• 尚未解决的矛盾；
• 需要复现时的模型与工具版本。

这些痕迹一旦消失，再流畅的答案也只是难以审计的成品。

MCP 统一接口，不替信源担保

Model Context Protocol 让兼容客户端连接到提供 resources、prompts 和 tools 的服务端。在这条流水线里，搜索、数据库、feed 注册表和内部工作流，都可以被 MCP server 包装成一套共同的发现与调用方式。

它能降低一部分集成成本，却不会让所有信源真正变得一样：

• server 仍要处理上游鉴权、分页、重试和数据结构；
• client 决定自己支持哪些协议能力和授权流程；
• 工具描述可能不完整，甚至产生误导；
• 返回数据可能过时、带有恶意内容，或者只是错了；
• 模型仍会选错工具、传错参数；
• 一枚权限过大的 token，会把一次工具错误放大成事故。

应遵循协议当前的安全最佳实践 ：使用最小权限凭据，验证 redirect 与 token，显式维护信任边界，并为有后果的访问保留用户同意。

多个兼容客户端确实需要共享同一项能力时，我会考虑 MCP；一个稳定的 cron job 没有必要仅仅为了看起来“更 Agent”而包上一层协议。

五段流水线：采集、分析、处理、判断、行动

这五段不是价值高低排序，而是一张责任地图：

采集 ──▶ 分析 ──▶ 处理 ──▶ 判断 ──▶ 行动
  │        │        │        │        │
  └────────┴────────┴────────┴────────┘
           来源 · 指标 · 复核 · 重放

采集：先保住来源

信源契约明确时，采集器应该尽量确定性。保存 source ID、canonical URL、拉取时间、发布者时间戳、内容 hash，以及在政策允许范围内可供重放的原始表示。后续产物如果不能指回自己处理过什么，排障只能靠猜。

这一层值得观察：

• 按信源拆分的成功率和拉取延迟；
• 连续失败次数，以及距上次新条目过去多久；
• 限流响应和鉴权失败；
• 每次条目数量和解析错误率。

分析：去重，但别抹掉分歧

去重不是没有副作用的清洁工作。一次错误合并，可能藏掉独立信源的相互印证，也可能把两个名字相近的版本当成同一个事件。

我会从便宜到昂贵逐层处理：

1. 规范 URL，删除已知追踪参数；
2. 比较稳定 ID 与内容 hash；
3. 用文本指纹识别转载和小幅修改；
4. 把语义接近的报道聚成候选事件，同时保留每一个来源。

向量相似不等于“同一个事件”。阈值需要在标注样本上评估，而且至少要同时看：

• merge precision：系统合并的条目中，有多少真的应该合并？
• merge recall：真正的重复条目中，系统找回了多少？

不同领域的代价并不一样。安全公告的误合并风险，通常比普通产品新闻更值得保守对待。

处理：压缩，但让结论带着证据

翻译、标签和摘要，是为了把原始材料压成能快速检查的单元，而不是切断它与来源的关系。重要事实应附支持它的原文片段或链接，不确定性也要在压缩后活下来。

让第二个模型检查第一个模型，能发现一部分问题，却不能充当真相。更可靠的门禁会组合：

• 强制指向已取回原文片段的引用；
• 对日期、名称、版本和 URL 做确定性检查；
• 标出矛盾或缺少依据的陈述；
• 人工抽样复核；
• 低置信度或低质量信源自动升级给人。

指标可以看人工样本中的无依据陈述率、引用覆盖率、纠正率、处理延迟，以及每条通过内容的成本。

判断：写下“为什么与我有关”

系统可以给候选排序，分数却不是决策。对排在前面的条目，我会写下一句很短的判断：

这件事与我当前工作有关，因为 ___；依据是 ___；如果 ___ 出现，我会重新判断。

这句话把公共信息流接到了我的具体处境。AI 可以参与整理，但我应该能为它辩护。这也接上了《把笔记交给 AI 操作》 ：值得沉淀的判断，要带着证据和复查日期流进第二大脑，而不是变成失去上下文的摘要。

经过一个约定周期后，再回看判断质量。被标为高信号的条目，有多少真的改变了项目、对话、实验或明确决策？还要抽查被过滤的内容，估算漏报率。一个从不看 false negative 的系统，最后只会越来越欣赏自己的过滤器。

行动：只在清楚的风险边界内自动化

行动让链路闭环，却不是每一个动作都适合自动化：

旧稿用 0.95^20 ≈ 0.36 渲染复合误差。算术只适用于二十个互相独立、成功率相同的步骤；现实工作流里，故障会相关，步骤风险不同，还有重试和验证门禁。真正的工程结论不需要这个玩具数字：找出有后果的状态转换，在周围布置审批、幂等、回滚和审计日志。

安全长在 harness 里，不能寄希望于模型每一次都自己看见边界。

能长期留下来的工作，大多在模型调用之外

给“AI”和“基础设施”分配一个精确比例很诱人。旧稿反复使用 98.4% / 1.6%，却没有可复现的一手来源；Claude Code 的公开仓库也不能证明整个产品代码库存在这样的构成。这个数字不该再替论点撑腰。

可检查的事实已经足够：长期运行的系统需要调度、状态、重试、限流、身份、存储、来源、评估、预算、告警和恢复。一次模型调用可以改善某个环节，却不会让这些责任消失。

模型往往比运营经验更容易替换：哪个源会沉默失败，哪个阈值会误合并，哪种摘要总会丢限定条件，哪类告警我真的会采取动作。这些被时间磨出来的知识，才是手艺。

可观测性：识别系统为什么安静

我会用一块小看板盯四组信息。

信源健康

• 成功率、解析错误率和连续失败次数；
• 距上次成功拉取、上次新条目过去多久；
• 预期条目量与实际条目量；
• 即将过期的凭据和剩余限流额度。

告警必须有负责人和 runbook，否则看板只是在记录系统如何慢慢腐烂。

信息质量

• 聚类前后的重复率；
• 标注样本上的 merge precision 与 recall；
• 无依据陈述率和纠正率；
• 带一手证据的高优先级条目占比。

运行状态

• 从发布者时间到卡片通过的端到端延迟；
• 每条拉取、处理和通过内容的成本；
• 队列年龄、重试量和 dead-letter 数量；
• 能从已保存来源完整重放的运行比例。

决策价值

• 最终推动一项决策或实验的高信号条目；
• 每天复核 shortlist 花费的时间；
• 抽样估算的漏报率；
• 告警被忽略、行动或静音的比例。

这些指标没有放之四海而皆准的目标值。先建立基线，再根据失败后果设阈值，并在固定节奏里复查。

一条最小可运营闭环

先选一个主题和三个源：

1. 一个有人维护的 RSS 或 Atom feed；
2. 一个有文档的 API，例如 GitHub Releases；
3. 一个被监测的页面，或经过谨慎选择的 RSSHub 路由。

让它连续跑两周：

采集 → 归一 → 保留来源 → 去重
     → 带引用摘要 → 每日 shortlist → 一句人工判断

在增加 Agent 之前，先写下验收标准：

• 每张卡片都能指回来源与获取时间；
• 信源故障能在约定检测窗口内暴露；
• 人工抽样的摘要不存在无依据的重要陈述；
• 重复聚类达到事先约定的 precision；
• 每日复核不突破注意力预算；
• 外部或不可逆动作未经审批绝不执行；
• 成本与延迟被真实记录，而不是凭感觉估算。

试运行结束后，先看失败，再加信源。让已经赢得信任的部分变大，把只是看起来厉害的部分换掉。

结尾：搭一套让下一步不同的系统

一个人现在可以连接的 feed、API、搜索和工具，早已超过自己能读完的数量。这是一项能力，还不是优势。

优势出现在链路后半段：证据没有在摘要中丢失，沉默能与故障区分，反复出现的信号成为一句你解释得清的判断，而判断又在不越过安全边界的前提下，改变了下一步。

别去造知道得最多的系统。去造一个能帮你看见什么重要、说明它为什么这样相信，并且仍把有后果的决定留给你的系统。

延伸阅读：

• 《信息、记录、知识、创作》 ：这条流水线背后的认知框架；
• 《把笔记交给 AI 操作》 ：知识层如何进入第二大脑；
• 《超级个体的栈》 ：Agent、MCP 与个人系统如何长期运营。