无需手动控制的自主 AI 新闻系统

## 自主 AI 新闻系统：如何用统一架构取代七个工作流

在一个半月内，七个碎片化的 n8n 工作流组成的新闻管道转变为一个稳定的系统，拥有 160 个来源、11 个工作者和 5 个 AI 代理。现在，数据库中的 7127 条记录处理过程无需人工干预，本地 mini-PC 上的 LLM 取代了云端 API。我们来剖析这个消除故障点并确保 24/7 运行的架构。

从七个故障点到单一系统

最初，新闻管道由七个独立 n8n 工作流组成：数据采集、过滤、翻译、图像生成和发布等阶段。每个阶段孤立运行，导致故障级联发生。典型问题：某个工作流将任务标记为“已完成”，但输出为空。由于缺乏统一监控系统，诊断耗时数小时。关键漏洞是没有每个新闻项的单一状态。如果一个工作流卡住，其他工作流仍继续处理，产生不一致数据。

解决方案源于使用 Perplexity 分析和 Claude Code 实验。与其手动用 Python 重写逻辑，不如让 AI 助手接收源工作流和架构需求。一小时内，它生成了一个容器化应用，职责清晰分离。关键变化：从基于触发的工作流转向状态导向管道，每个新闻项严格通过定义阶段，并在数据库中固定状态。

本地处理：为什么选择 mini-PC 上的 Qwen 3.5

通过云端 API 翻译新闻在经济上不可行：160 个来源每 15 分钟更新一次，每天需数万次请求。解决方案：在家用 mini-PC 上部署 Ubuntu，并通过 llama.cpp 优化 Vulkan 运行本地 LLM。选择了 Qwen 3.5 模型（qwen3.5-9b-q5_k_m.gguf），因为它在速度和俄语质量间取得平衡。

设置包括：

• 通过 Cursor 为 CPU 架构微调
• 校准线程数以最小化延迟
• 配置中间结果缓存

系统每分钟处理多达 50 个请求而不超载 CPU。数据永不离开本地网络，这对有限制 API 密钥的来源至关重要。对比而言：当前量下云端翻译每月约需 120 美元，本地初始设置后为 0 美元。

管道架构：11 个工作者如何协作

基于“一个进程——一个任务”原则构建。每个工作者隔离运行，消除级联故障。处理流程：

collector → scraper → deduplicator → ai_filter → translator
    → llm_editor → image_worker → publisher

collector 每 15 分钟运行一次，从 160 个来源（包括 Arxiv、TechCrunch、GitHub）解析 RSS/API。scraper 通过本地 Jina Reader 实例提取全文——这消除了云服务限制。deduplicator 使用基于嵌入的语义比较，而非精确文本匹配。ai_filter 分配相关性分数（0-100），过滤掉低于 75 分的项目。

特别关注 llm_editor 阶段。在那里，MiniMax M2.7 将文本格式化为频道风格：为标题添加表情符号、结构化内容、添加归属。模型基于历史频道数据训练，确保格式一致。所有工作者通过带投递保证的消息队列交互，支持从最后一个检查点恢复故障。

通过 AI 代理管理：从 Telegram 命令到行动

基于 OpenClaw 的协调器取代手动管理。它运行在同一台 mini-PC 上，并通过 API 访问工具。系统使用 5 个专用代理：

• AgentLLMEditor：每 20 分钟校正文本
• AgentPipelineManager：每天 4 次分发帖子到时段
• AgentSourceAuditor：每周禁用无效来源
• AgentAnalyst：21:05 生成分析报告
• Coordinator：管理其他代理

如“Coordinator，将每日发布限额降至 8 条”的 Telegram 命令，会转为对管道管理器的 API 调用。代理检查当前设置、执行变更并确认。这免除了 SSH 访问和配置文件语法知识需求。对于关键操作（如禁用来源），系统要求通过人工介入（hitl）工作者确认。

仪表板：实时监控

界面整合 9 个标签页：概览、代理、来源、队列、工作者、时段、已发布、设置、GitHub Discovery。主要指标：

• 来源通过率：Anthropic News（100%）对比 iXBT.com（14%）
• 阶段处理时间：翻译（4 分钟）对比过滤（2 分钟）
• 工作者状态：活跃/空闲进程

检测到异常（如翻译队列卡住）时，仪表板自动在 Telegram 工作组创建任务。与 GitHub Discovery 集成跟踪星标急剧增长的仓库——数据显示在单独标签页的活动图上。系统会在问题影响发布前预警：如来源一周通过率降至 10% 以下。

通过筛选节省：从每周 1000 条新闻到每日 8 条帖子

系统不会发布所有内容。每周处理约 1000 条，但仅 56 条上线（每日 8 条）。筛选标准：

• 相关性分数 ≥ 80（ai_filter）
• 通过 LLM 编辑器批准（状态 approved）
• 匹配当日时段

时间表与时区挂钩：

• 上午（08:00–11:00）：2 条
• 白天（12:00–16:00）：2 条
• 晚上（18:00–22:00）：2 条
• 夜间（00:00–06:00）：2 条

此前每日 28 条，但分析显示用户仅读最后 1-2 条。现在，减少量后留存率提升 37%——读者查看时段内所有发布。来源通过率允许每周调整列表：已禁用 20 个低效 RSS 源。

关键点

• 统一状态系统 取代孤立工作流：每个新闻有明确状态，故障诊断速度提升 5 倍。
• 本地 LLM 每月节省高达 120 美元 用于翻译和编辑，50 个并行任务延迟不超过 4 分钟。
• AI 代理消除手动管理：Telegram 命令转为 API 调用，无需操作员介入。
• 严格内容筛选（每日 8 条而非 28 条）通过减少噪音，将受众留存率提升 37%。

— Editorial Team