多 Agent 新闻情报系统

每天跨平台看新闻很痛苦——来源分散、重复率高、噪声多。我做了一个 AI 新闻聚合系统：每天早上 9 点自动发一封邮件简报，从 170+ 条原始新闻中筛出 20-25 条值得看的，10 分钟读完当天全域动态。

核心能力：14 个中英文来源实时采集（Hacker News、36氪、ArXiv、TechCrunch 等），AI 语义聚类去重、跨天事件向量追踪（同一事件连续多天报道会自动关联成时间线）、正负双向读者画像驱动个性化筛选。

技术实现：8 个阶段的流水线，10+ 个 Agent 分工协作。6 组子 Agent 并行采集，脚本做机械预处理，Agent 做语义判断，最终由全局校准 Agent 按重要性、相关性、多样性、信息增量四个维度选出最终内容。基于 LanceDB 本地向量数据库做跨天事件匹配。

现状：稳定运行 2 个月+，已开源，分享给朋友使用并根据反馈持续迭代。

---

三个关键产品决策

1. 跨天去重：AI 漏检 80%，改用脚本兜底

上线第一周，我看自己的简报，发现一条 OpenAI 新闻的 URL 和昨天一字不差——但系统给它标了"连续报道·第 2 天"，还编了一段"最新进展"。

去查日志：30 条新闻里 15 条 URL 和昨天完全一样，AI 编了 15 条假的进展说明（"内部失控证据具体化"、"金融 AI 专用赛道成形"……全是废话），只主动降级了 2 条。漏检率超 80%。

一开始我以为是 prompt 写得不够严。深入查之后发现问题更根本：AI 没有 star 数、point 数这类客观锚点来判断"有无新进展"，只能靠文字；而且 AI 倾向保留新闻而不是降级，编一个模糊的理由保留。

由此我得到一个设计原则：能写 if-else 的事全部交给脚本，AI 只做需要语义理解的事。 比如"这个 URL 昨天出现过吗"是 if-else，交给脚本；"这两篇报道是不是同一件事"需要语义判断，交给 Agent。

这个原则后来贯穿了整个系统的设计——全局校准 Agent 只输出"谁留谁走"的决策，脚本负责执行；事件关联 Agent 只做语义匹配，URL 去重由脚本兜底。

2. 个性化筛选：正向画像告诉AI我想看什么，负向画像告诉AI我不要看什么

上线后我逐条检查简报，5 条里 4 条是噪声——"苹果折叠屏"、"Xbox 泄露备忘录"、"Linux 7.0 稳定版"。我的正向画像写了"关注 AI/科技"，AI 推理"苹果是 FAANG 重大战略动作"→ 入选。逻辑没问题，但对我就是噪声。

问题在于：单向画像没法表达"对的方向但不对的细分"。我对消费电子整体感兴趣（关注 AI 终端），但不关心折叠屏；对游戏行业不感兴趣，除非是 AI 游戏。这些"除非 / 不包括"的条件，正向画像写不进去。

我加了负向画像：一个 md 文件里同时维护"关注什么"和"不关心什么"，所有 Agent 共读这一个文件。反馈方式很简单——我觉得某条新闻多余，就在对话里说一句"这个我不关心"，AI 帮我加进负画像，次日生效。加了负向画像后，之前那类"逻辑上沾边但实际上是噪声"的新闻基本消失了。

过程中还抓到一个自己的设计 bug：校准 Agent 的 prompt 里硬编码了"产品发布、工具更新"等筛选规则，而不是引用画像文件——两处副本，改一个漏一个。立刻改成统一引用，画像只维护一份。

3. 分类失衡：分数截断导致整类新闻被团灭，改用全局校准

最初的方案很直觉：6 组子 Agent 各自给新闻打重要性分数（6-10 分），脚本按分数排序取前 20 条。

跑了几天发现：68% 的新闻分数挤在 6-7 分，区分度极差。某天跑完发现被砍掉的 25 条全是 科技 类——该类的重要新闻被"团灭"了。

问题不是分数粒度不够。就算改成 1-100 分，AI 给出 63、65、67 这些数字之间的差异也是伪精度。真正的问题是让分数承担了它不该承担的职责——在各自的分类里，两条可能都是 6 分的新闻，但一条是 AI Infra 重大变化，一条是例行手机出货数据，没有全局的评估，只在组内进行排序。

我引入了全局校准 Agent：它读所有候选的精简摘要（只有标题、一句话摘要、分类，约 1500 token），按四个维度做全局选择——重要性、读者相关性、分类多样性、信息增量。输出一个"谁留谁走"的决策文件，脚本负责执行。把"打分"和"选择"拆成两件事。

修复前 科技 类新闻占 80%，其他类被挤压；加了全局校准 + 单分类不超过总数 50% 的硬约束后，全球头条、科技、财经、社会，各类均衡分布。

4. 事件追踪：向量检索召回 + Agent 精排的两阶段架构

同一事件连续多天被不同来源报道（比如"美伊霍尔木兹海峡冲突"连续 19 天），如果每天都当新闻推，简报就变成了重复信息轰炸。我需要系统能自动识别"这条新闻和昨天那条是同一件事"，关联成时间线，然而，也不能新闻一报道就展示，需要只在有实质新进展时才展示。

最初的做法是让事件关联 Agent 拿每条新闻去全量匹配历史事件。问题：44 条查询 × 每条取 top 15 最近邻 = 660 条候选，每条附带完整历史，上下文直接爆到 400k token。而实际只有 个位数 条是真匹配，命中率仅 1% 左右，相当于AI要在召回结果中大海捞针，效果很差。

改成两阶段：向量检索先粗筛（LanceDB 按语义相似度召回，限定同分类 + 30 天窗口 + 距离阈值过滤），Agent 再精排（只看候选的标题和摘要，逐条语义判断是否同一事件）。

关于距离阈值如何确定，我用历史数据中 44 条已知真相数据做对比实验：

再拿 228 条历史做交叉验证，P99 覆盖 99.1%。选 1.0：不漏、量可控、有大样本兜底。

结果：候选量从 660 降到 106，上下文从 400k 降到 30k token（-93%），匹配到的事件自动构建时间线，在简报中展示为"事件追踪·第 N 天"。

---

架构演进

不是一开始就设计成 8 阶段的。最初的想法很简单：抓新闻 → 去重 → 排序 → 发邮件。每次加一个阶段都是在解决一个跑起来之后才暴露的真实问题：

---

收获

• 多 Agent 系统的核心不是 prompt 写得多好，而是分工边界划得清不清楚。 需要了解，哪些事该 Agent 做、哪些该脚本做。认识到单Agent的能力上限以及适用场景，通过工程的方式来划分职能，而不是一股脑调优prompt，可能会获得更好的表现。
• 给 Agent 配套工具脚本来降低上下文负担，而不是一股脑把所有信息塞给它。 校准 Agent 从读 40k token 原文改成只读 1.5k 精简摘要，判断质量反而提高；事件关联 Agent 从 400k 降到 30k，靠的是向量检索先筛一轮。Agent 看到的信息越少越聚焦，输出越准确。

现状

稳定运行 2 个月+，分享给朋友使用，他们的反馈驱动了多轮迭代。已开源。