AI 信息过载的时代，筛选比收集更重要。

两个月前我开源了自己搭建的 AI 热点追踪系统，现在它又进化了：

• 新增Github Trending 热点项目 和 Hacker News 热点讨论
• 把启动命令 迁移至 systemd timer，可一键启动，实现系统级服务管理
• 借助nitter的公开实例实现自定义指定X用户帖子追踪
• 上线了归档网站ai daily，不想动手的朋友们可以直接线上查阅了

简述一下 ai daily 背景

或者可以看之前发布的文章：AI 热点追踪系统

ai daily 是一个 AI 驱动的新闻聚合与推送系统。每天自动收集，智能评分过滤，定时汇总，并支持发送到飞书实时通知用户。

核心功能

• 400+ RSS 信息源 —— 聚合全球主流 AI 媒体、博客、Twitter 账号
• GitHub Trending 板块 —— 抓取 GitHub trending，LLM 深读 README / topics / metadata，选出值得关注的开源项目
• Hacker News 板块 —— 跟踪 HN 首页 AI 相关讨论，整合外链正文与顶层评论由 LLM 总结
• 即时推送 —— 热点新闻立即推送到手机(飞书/discord)
• 定时汇总 —— 每天可以自定义定时自动推送 AI 资讯日报

systemd timer 让服务像系统组件一样可靠

上个版本的运行方式比较原始——跑一下 python 脚本，信息就唰唰唰地抓进来了，整个服务跑起来，也没想太多服务进程管理的相关问题。

但是长时间运行了之后发现几个痛点：

1. 如果一旦出现某些不可预知的问题，整个服务就挂掉了，需要手动重启，还需要手动管理如何把进程放到后台
2. 改了个参数，需要重启
3. 日志没有有效记录，难以定位问题
4. 定时在python内部，sleep状态下，进程还在，但是完全没有必要

我就问AI， 像openclaw这种服务一键安装就可以了，我的这个项目也想要这样的，该怎么做。

我把以上这些问题都抛给了AI，经过几轮商讨，最后选择了使用 systemd timer。

在配置好参数和环境变量之后，现在只需要这样：

./scripts/install.sh

对，这样就行了。脚本会自动同步依赖、安装 systemd 服务并按 config.json 中的调度配置启动定时任务，机器重启后自动恢复。安装成功后无需额外操作。

这次重构把定时任务交给系统服务来管理，python不维护cron定时。没到定时时间，也没有python进程运行。一次调度出现错误(比如网络波动，json解析等)，不影响下一次。 config参数支持热重载(除了定时参数)，中间可以随便改，下次任务启动生效。连日志也帮着一起管理了。

并且系统服务提供很多方便的指令:

daily-news status [N]      # 查看 timer/service 状态 + 最近 N 行日志（默认 15）
daily-news logs            # 实时跟随日志（Ctrl+C 退出）
daily-news start           # 启动两个 timer
daily-news stop            # 停止两个 timer
daily-news restart         # 重启两个 timer（仅重置调度，不立即触发任务）
daily-news help            # 用法说明

daily-news status 可以查看定时任务的状态，上次触发时间，下次触发时间，日志输出等。

这样可以很方便地管理或者显示整个服务的运行状态，这才是系统级集成该有的样子。

通过 nitter 实例自定义 X 用户帖子追踪

x（twitter）上的信息还是不能忽视。当前项目里的默认rss源是从BestBlogs项目引进来的，它里面提供了160+ 用户的rss列表，涵盖了大部分ai相关的高关注度用户。

好是好，坏就坏在这个列表我没法随意添加新的用户，因为这个rss源是第三方维护的。

除了上面已有的用户，我想要自己能个性化地定义我想关注的用户。举个例子，我想追踪 openclaw 的帖子，这个列表里面没有openclaw，那我就没法追踪。

我希望找到一种可用的，可指定用户的rss源。当然，必须是免费的。

我找了很多种方法，问了很多ai，查到了nitter。

简单来说nitter是一个无需登录即可浏览公开帖子的开源项目，同时提供用户帖子的rss链接。

不过由于X不断加强反爬虫和 API 限制，nitter的很多公共实例难以长期稳定运行。

现在比较稳定的推荐较高的是xcancel， 如果想关注某个用户，把这个链接https://rss.xcancel.com/<user>/rss加入rss源即可。

实际测试下来 xcancel 对反爬还是有一定门槛的，它用了多层指纹识别判断客户端，代码里面已经对这类实例做了额外的适配。

如果在其它项目里面使用该源，建议频率不要太高。

访问 yeekal.com/daily/ 在线阅览

看着飞书里每天准时发布的日报，历史记录直接被删除掉感觉有些可惜

所以做了个项目主页，加入了历史归档。每天早八点和晚五点会更新当天早晚报，不需要部署也可以方便查看。

当然，在线日报本身也支持rss订阅，访问项目主页查看订阅地址。

(注： 5.24 之前的日报存在测试样本，不建议查看)

workflow 还是 agentic

说一些开发过程中的疑惑，思考

上一次发文出来，有很多人会问： 这openclaw不也能做么，这让claude跑几个新闻网站不就拿到信息了么

其实我也在想，费时费力开发这些，是不是直接写一个skill让agent自己去做这件事更好一些。

我记得anthropic去年也发过一篇文章介绍工作流和agent的区别。

我现在做的事情其实就是工作流的编排，定义好每一步该做什么，按照流程一步一步走。步骤可控，可操作灵活度大，但是扩展自由度低。加一个模块就要加一份代码。而agent模式是通过harness工程，通过自然语言，通过skill约束agent的任务，给agen配齐工具，给它自由，让它自定义如何一步一步走到最终的结果。agent模式扩展很灵活，但是可控性依赖模型对指令的遵循程度。

对于该项目而言，第一阶段对rss信息源的抓取非常适合工作流，因为它高频，请求数量多，任务清晰，并且代码实现很直接。

github trending和hacker news这类具体并且一次性的任务就比较适合让agent来做了。写代码要写一大串，但是写提示词可能几句话告诉他总结一下当天热点即可。并且这类任务在agent端很方便扩展，加入对应网址和输出格式就行了。

3月份开始开发之前，我其实让openclaw给出过每天8点的新闻总结。但是这里面有很多影响因素，比如对网站源的选择，文本的markdown化，网络请求的限制等等。我对它的结果并不满意。更重要的一点是我希望对于突发消息能及时给我到，这如果让openclaw跑的话，token耗费将会是巨大的。所以那个时候我才考虑，这需要一整个系统化的工程来应对。

整个项目运行下来从结果上看符合预期的，并且整个流程，对信息源的把控，日志，报错等都在可追溯的范围内。还有一点重要的是，token的花费非常低。因为工作流里面token只花费在做任务总结上，没有多余的工具调用，文本转换/读写/编辑，思考过程。这些过程被系统架构层给替代掉了。用Deepseek V4 flash 在30min的抓取频率下差不多一天6-7毛钱。最近我把频率又调低了，60min一次，这样花费会更少。(调低不是因为花费，是想减轻公共rss服务实例的压力）.

不过未来如果要加入更多的信息源(比如reddit，product hunt), 那么有必要考虑一下哪种方式是最优的。是用工作流写采集模块，还是用 Agent 几句提示词搞定？这可能没有一个标准答案，取决于你对「可控」和「灵活」各有多少容忍度。