技术知识库 · 工具评测 · · 国科智飞 Gavin

Horizon：自建 AI 新闻雷达，把信息流变成简报

自己定义信源，AI 抓取、去重、打分、补背景、汇总评论，产出中英双语简报，还能通过 MCP 交给 Agent 调用。

每天的信息摄入是个矛盾：信源越多，噪音越多；交给算法推荐，又容易困在信息茧房里。Thysrael/Horizon（MIT 协议，Python）走的是第三条路——自己定义信源，让 AI 做去重、打分、过滤和背景补全，最后生成一份可发布的每日简报。数据管道完整暴露为 MCP 工具，Agent 可以直接指挥它干活。

它是什么

Horizon 是开源的「个人 AI 新闻雷达」。输入是 Hacker News、RSS、Reddit、Telegram、X、GitHub（发布与活动）、OpenBB 财经等信源；处理链路是抓取 → 去重 → AI 打分过滤 → 背景补全 → 评论汇总 → 生成双语摘要；输出可以发布到 GitHub Pages 每日站、邮件订阅，或者通过 webhook 推送到企业 IM（钉钉、Slack、Discord 等）。模型兼容 OpenAI、Gemini、DeepSeek、豆包、MiniMax、Claude、Ollama 等多家，本地模型也能接。

安装用 Python 的 uv 管理依赖，Docker 可选；配置走 data/config.json 和 .env，附一个交互式向导自动生成配置。截至本文写作时，项目约 9200 Star、1429 个 fork，2026 年 2 月创建后增长很快。

能力与亮点

Profile 驱动，不是写死的汇总器。 处理逻辑按题材分成 profile，每个 profile 有自己的提示词和过滤阈值，不同题材可以独立路由。这意味着科技新闻和财经新闻用各自的判断标准，而不是强塞进一个漏斗。可插拔的设计让新题材的接入成本很低。配置层也体现了这一点：配置文件统一管理信源、profile 和摘要平衡，文档覆盖配置、打分、抓取器和 MCP 的用法，交互式向导能先带出一份可运行的默认配置。

摘要平衡。 通过最大条数和分类分组做限制，避免单一品类吞掉整份简报——财经新闻刷屏时，科技条目不会从摘要里消失。这是长期使用后才会意识到的细节，它决定了简报能不能保持信息结构。

跨平台去重和背景补全。 同一条新闻在 HN、Reddit、X 上反复出现时，进简报前会先合并；遇到陌生的公司、项目或概念，流水线会做一轮网络调研补上下文。这两步解决的是「简报看起来热闹、读起来没信息量」的常见问题。

评论汇总。 抓取并总结 HN、Reddit 等社区的高质量评论。新闻本身谁都能转发，评论区往往是信息增量最大的地方，这个功能的价值容易被低估。

一源两版，双语发布。 同一份数据源生成中英文两版简报，对面向出海或中英双语的团队很实用。

MCP 集成是最值得关注的。 项目把抓取、打分、过滤、补全、汇总，以及跑完整流程都暴露成 MCP 工具——任何支持 MCP 的 AI 助理都可以指挥 Horizon 干活。这样一来，它就不只是一个新闻工具，而是 Agent 体系里的一件情报采集组件：让 Agent 按需发起一次行业扫描，或者每天定时收一次简报。

人类品味在环。 项目文档里有一句话说得很好：AI 擅长减噪，但新闻需要人的品味。信源选择、阈值设置、社区信源中心的贡献，这些决定「什么值得读」的判断始终由人来做。工具沉淀的其实是你的信源库和判断标准，而不是 AI 的输出。

局限与坑

跑起来要配的东西不少。 至少需要 LLM 的 Key；X、Telegram 这类信源还有各自的接口门槛和访问限制，稳定性和凭证需要自己解决。信源越多、跑得越勤，模型调用成本越高。好在本地模型和 Docker 可以降低一部分门槛。

默认配置不等于贴合你。 打分和过滤的质量取决于 profile 的提示词与阈值，默认题材之外的小众垂直领域需要自己调。做细分行业监控的话，很可能要自己写 profile：提示词、过滤阈值、分类路由都得重新设计，这部分没有现成答案。调参本身要花时间做阅读反馈——第一周不要急着加信源，先把一两个信源的效果调顺。

自动化不等于可以完全放手。 AI 打分可能漏掉有价值的冷门内容，也可能把噪音评成高分；去重做不到百分之百，背景补全偶尔会引入不准确的信息。简报发布前保留一个人工扫一眼的环节，成本很低，收益很高。

维护风险。 这是个个人发起、社区参与的项目，商业化程度弱，没有企业级的 SLA 和支持渠道。用于个人或小团队的情报工作没问题，把它当关键业务流程的基础设施要有备份方案（比如自己 fork）。

数据边界要注意。 邮件订阅、公开站点、webhook 推送都会让内容离开本机。内部敏感信息为主的行业监控场景，发布渠道要单独设计。

适用场景

选型建议

先问自己一个问题：你需要的是聚合还是判断？如果只是想把几个 RSS 合在一起，写个脚本就够了；Horizon 的价值出现在信源多、噪音大的场景——用 AI 做筛选，用人做信源和阈值的决策。

落地建议按三步走：第一天跑通默认配置，确认管道通畅；第一周只保留两三个最信任的信源，反复调整打分阈值，把简报质量调到你愿意每天读；之后再把信源、推送渠道和 MCP 接入逐步加上。如果已经在搭建 Agent 工作流，建议优先接 MCP——把 Horizon 当成一个工具挂进去，比单独维护一套采集脚本更划算。最后提醒一点：真正积累下来的是「你信任什么信源、用什么标准筛选」的判断，这部分要像代码一样版本管理起来。

参考来源