Horizon：把新闻筛选权留给 AI，把品味留给你

新闻太多，但品味不能外包

Horizon 要解决的问题很具体：你关心的信息散落在 Hacker News、Reddit、Telegram、RSS 和 GitHub 上，每个平台都有噪声，而 AI 摘要工具往往只做一件事，就是把内容压短，却不管来源是否可信，也不管社区讨论是否改变了故事的含义。Horizon 的定位是给新闻加一道人工筛选层。它不是一个自动化的全权代理，而是一个可配置的流水线，让你指定信源、处理配置文件和过滤阈值。README 里有一句话点明了这个立场：AI 擅长降噪，但新闻仍然需要人的品味。这个项目面向的是愿意花时间调教工具的人，而不是想完全撒手不管的普通读者。

从抓取到投递的七步管道

Horizon 的工作流程在 README 里画成了一张流程图，分成七个阶段：定义、抓取、去重、分析过滤、丰富、摘要、投递。定义阶段你指定信源、处理配置、模型、语言和投递方式。抓取阶段会并发拉取所有配置源的最新内容。去重阶段把指向同一故事或 URL 的条目合并，这一步很关键，因为同一个新闻往往在 Reddit 和 Hacker News 同时出现。分析过滤阶段按你选的处理配置对每条内容打分，并应用你设定的阈值。丰富阶段根据配置生成内容块，但只允许使用该块允许的工具，这个限制意味着不是所有模型能力都会被调用。摘要阶段把本地化标题、导语、章节和引用来源渲染成 Markdown 简报。最后投递阶段把结果发布到 GitHub Pages、邮件、webhook 或本地文件。整个流程是批处理式的，不是实时流，这一点决定了它的使用场景。

用向导起步，用 JSON 调细节

安装 Horizon 有两种方式。本地安装推荐用 uv，命令是 git clone 后执行 uv sync，如果需要开发依赖就加 --extra dev，如果要 OpenBB 财经新闻源就加 --extra openbb。Docker 方式用 docker compose build --build-arg EXTRAS=trafilatura horizon，多个 extra 用逗号分隔。配置也有两条路。交互式向导运行 uv run horizon-wizard，它会问你兴趣点，比如 LLM inference 或嵌入式，然后自动生成 data/config.json。手动配置需要复制 .env.example 和 data/config.example.json，然后在 JSON 里写 AI provider、模型、API key 环境变量名，以及信源列表。最小的配置示例里，ai 部分指定 provider 为 openai，model 为 gpt-4，api_key_env 指向 OPENAI_API_KEY。sources 部分是一个 rss 数组，每个条目有 name、url 和 profile 字段。processing 部分指定 profiles_dir 和 default_profile。这个结构不复杂，但如果你不熟悉 JSON，向导是更安全的起点。

双语输出与社区讨论的取舍

Horizon 支持从同一组信源生成英文和中文日报，这是它区别于大多数英文优先的新闻工具的地方。实现方式是在摘要阶段渲染本地化标题和导语，而不是简单翻译，这意味着你需要为每种语言配置对应的处理配置。另一个特点是收集并总结社区评论，比如 Hacker News 和 Reddit 下的讨论。这个功能有价值，因为评论往往能暴露文章里没有的背景或反对意见。但代价是抓取和处理的成本更高，每次运行都要调用 LLM 来分析评论，这会增加 API 费用。README 没有给出具体的成本估算，只说你可以配置模型和阈值来控制开销。如果你只关心头条，不关心社区反应，这个功能可能只是额外负担。

投递渠道：GitHub Pages 是默认，邮件和 webhook 是补充

Horizon 的投递层支持 GitHub Pages、邮件、飞书、钉钉、Slack、Discord 和自定义 webhook。GitHub Pages 是默认的发布方式，生成 Markdown 后直接推送到 Pages 站点，这适合每天固定时间生成一份公开的日报。邮件投递需要自建 SMTP/IMAP 服务，并且要处理订阅和退订逻辑，README 里说这是自动的，但自建邮件服务器本身就是一项运维工作。webhook 方式适合把简报推送到聊天工具或自动化流程，比如飞书通知。这里有一个明显的取舍：渠道越丰富，配置越复杂。如果你只需要一份本地 Markdown 文件，投递部分其实可以跳过，直接读输出文件。但如果你想要多语言多平台分发，就需要为每个渠道写配置。

已知的坑：twitter 源和 OpenBB 依赖

Horizon 的 README 明确提到了两个限制。twitter 源需要 Playwright 浏览器和系统包，而当前的 Dockerfile 没有安装这些依赖，这意味着用 Docker 跑 twitter 源会失败，除非你手动修改镜像或改用本地安装。OpenBB 财经新闻源需要额外安装，而且如果 openbb 拉取到没有 wheel 的包，你得用 uv pip install --only-binary=:all: openbb openbb-benzinga 来强制使用二进制版本。这两个问题说明 Horizon 的源支持不是均匀成熟的，有些源是实验性的。另外，项目没有发布任何 release，README 里也没有版本号，这意味着你只能依赖 main 分支的最新状态，无法锁定一个稳定版本。对于生产环境，这是一个需要权衡的风险。

替代方案：与 RAG 管道的本质区别

Horizon 的替代品不是另一个新闻聚合器，而是你自己用 LangChain 或 LlamaIndex 搭的 RAG 管道。两者的核心区别在于：RAG 管道通常是为问答设计的，你给模型一堆文档，然后问问题，模型检索相关片段生成答案。Horizon 不是问答系统，它是一个批处理过滤器，每天固定跑一次，输出一份排序的简报。RAG 管道需要你自己写抓取、去重、评分和投递的代码，而 Horizon 把这些步骤封装成了配置。但 Horizon 的灵活性不如 RAG 管道，因为它的处理配置是预设的，你不能随意定义任意复杂的检索逻辑。另一个替代方案是直接写一个 cron 脚本调用 LLM API 处理 RSS 源，但那样你就得自己处理去重和评论收集，Horizon 把这些都内置了。如果你想要的是实时警报，比如某个关键词一出现就通知你，Horizon 不合适，它更适合每日汇总。

维护成本与许可证

Horizon 使用 MIT 许可证，这意味着你可以自由使用、修改和商用，只要保留版权声明。这是最宽松的开源许可之一，没有 copyleft 义务。维护成本方面，项目依赖多个外部服务，包括 LLM API、各种信源的 API 以及可能的 Playwright 浏览器。每次运行都会消耗 API 额度，你需要监控成本。由于没有 release 记录，你无法依赖语义化版本控制，升级 main 分支可能带来破坏性变更。README 建议用 uv sync 安装，但如果你用的是 pip，需要 pip install -e .，这要求你熟悉 Python 环境管理。文档站点在 https://thysrael.github.io/Horizon/ 上有配置指南，但项目本身没有提供测试数据或 mock 模式，所以验证配置是否正确的唯一方式是实际跑一次，这会产生 API 费用。

编辑结论

Horizon 适合那些愿意花时间配置自己信源、并且希望每日简报既包含 AI 摘要又保留人类判断的工程师或技术写作者。它不适合只想一键安装、完全不想碰 JSON 配置的用户，也不适合需要实时新闻推送的场景，因为它的设计目标是每日批处理。在采用之前，先确认三件事：你是否有可用的 LLM API key 并愿意为每次运行付费；你是否接受 GitHub Pages 作为默认发布渠道，或者愿意自己配置 SMTP 和 webhook；你是否能忍受 Docker 方式下 twitter 源需要额外安装 Playwright 浏览器和系统包的限制。Horizon 的 MIT 许可证允许自由修改和商用，但它的维护节奏和版本稳定性目前没有 release 记录可查，这意味着你可能会遇到文档与实际行为不一致的情况。

官方来源

1. Official documentation
2. Official README
3. Project repository