News Agent 新聞聚合器：把多源 RSS 收斂成自己營運的訂閱源

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

News Agent 是一個掛在 GitHub Actions 上的開源新聞聚合管線，做的事情可以一句話講完：定時去抓一組 RSS 源，用內容指紋去重，選配一層 Gemini AI 篩選，產出各分類的累積新聞文件與標準 RSS 2.0 訂閱檔，再透過 GitHub Pages 免費上站。專案位於 zskfree/News-Agent，Python 寫成，2025 年 5 月建立，到目前累積 107 顆星與 66 個 fork。

先講結論。這個專案此刻直接訂閱示範源已經行不通：README 上列的三個訂閱網址，網域已經失去解析；真正還在運轉的部署掛在另一個網域，而且只在特定子網域回應。它的價值在於 fork 一份回家，把「新聞訂閱源」變成自己帳號裡的一條免伺服器管線。fork 之前有三件事值得先看清：README 宣稱 MIT 授權但 repo 裡沒有授權檔案、文件寫的更新時間與排程實際行為差一小時、AI 篩選是沒金鑰就靜默跳過的可選層。

它把訂閱源變成一份你接手營運的管線

整條管線的循環是這樣的。工作流每天三次啟動，先跑累積新聞腳本抓取所有來源、做指紋去重，寫成各分類的累積新聞文件，再跑訂閱檔腳本把它們整理成 RSS 2.0 XML。repo 裡另有產生每日精選簡報的腳本，本地端跑得到，排程工作流並沒有把它掛上。產出的檔案會被 commit 回 repo 本身，接著整份 repo 透過 GitHub Pages 部署上站，閱讀器拿到的就是 Pages 上的 XML 檔。全程沒有伺服器、沒有資料庫服務要顧，成本就是 Actions 的執行額度。

Pin

來源清單在 config/rss_feed_urls.json，共 19 個：10 個中文源、9 個英文源，分成三類。AI 類 11 個，從機器之心、量子位、雷峰網這些中國大陸科技媒體，到 Google Research、Hugging Face、NVIDIA、MIT 的 AI 部落格；科技類 6 個，有 InfoQ 中文網、極客公園、虎嗅、鈦媒體、少數派、逛逛Github；財經類 2 個，是 MarketWatch 與 Financial Times。實際打開訂閱檔看條目，內容以中國大陸科技媒體搭配英文 AI 官方部落格為主，這樣的口味合不合自己的閱讀習慣，訂之前翻一次清單最準。

把產物 commit 回 repo 這個設計還有一個副作用值得玩味：git 版本歷史本身就是這個服務的資料庫。機器人每天三次把當期狀態存檔成一則自動更新訊息，任何一天的訂閱檔長什麼樣、收了幾則條目，翻版本歷史就查得到，不需要另外建資料庫或備份機制。工作流裡還留著一個改寫門面頁時間戳與統計數字的步驟，但現行門面頁已經沒有對應的元素，這一步對著新版頁面空轉；門面上的快取大小、節點數這類統計是寫死的裝飾數字，與實際的 19 個源對不上。

去重的做法在原始碼裡寫得很具體：每篇文章先建內容指紋，再算標題相似度，相似度超過 0.85 就視為重複丟掉。多源聚合最怕的就是同一條新聞被五六個源轉載後重複出現，這道門檻是整個專案最關鍵的樸素設計。

產出物的規模可以從 repo 裡 commit 進去的檔案直接看：三個分類的訂閱檔各在 3 到 7KB 之間，AI 類的最新一檔只收了五則條目，標題全是中國大陸科技媒體的報導。量級透露了這個專案的定位：它產的是精選過的短清單，拿來當每日掃描的入口，而非海量索引。訂閱檔本身是標準 RSS 2.0 結構，有 pubDate 與 lastBuildDate，放進一般閱讀器都能正常解析。README 另外宣稱可以直接匯入 Inoreader、NetNewsWire、Readwise 這類閱讀器，這部分屬於作者自己的說法，結構上倒看不出會有相容問題。

本地要跑的話，環境是 Python 3.12 起，依賴同時給了兩份宣告：pyproject.toml 配 uv.lock 給用 uv 的人，requirements.txt 給 pip，兩邊內容一致，選一條就好。三個進入腳本都放在 scripts 目錄，累積新聞、產生訂閱檔、產生每日簡報各一支，簡報腳本還能指定回看區間。工作流另外有一個純手動觸發的測試版本，提供 quick、full、debug、time-check 四種模式，但 quick 模式引用的舊目錄結構已不存在，跑起來必然失敗，除錯時直接手動觸發主工作流比較實際。

示範站的三個斷點：網域、憑證、排程停擺

這個專案是觀察「依賴別人免費跑的服務」風險的好案例，因為它的示範部署剛好把三種斷點湊齊了。

網域先斷。README 的即時示範徽章與三個訂閱網址全部指向 zskksz.asia 這個網域，它目前已經沒有任何 DNS 解析紀錄。repo 首頁欄位填的另一個網域 280468.xyz 倒是活的，門面頁標題寫著 Intelligence Hub，是一個回應式的新聞門面。也就是說，照著 README 訂閱的人會直接撲空，要自己發現部署其實搬了家。

Pin

憑證是另一道牆。門面頁上的訂閱按鈕連到 280468.xyz 的根網域網址，瀏覽器打開會收到 Cloudflare 的 526 錯誤，代表來源伺服器的 SSL 憑證沒過 Cloudflare 的檢查。同一個網址加上 www. 前綴之後一切正常，XML 訂閱檔拿得到，內容也是對的。按鈕與實際可用網址差一個子網域，這種細節對願意手動貼網址的人只是小麻煩，對照著文件設定閱讀器的人就是一道無聲的牆。

最實質的斷點是管線本身停了。可下載的 AI 訂閱檔 lastBuildDate 停在 2026 年 8 月 7 日，repo 的自動 commit 也停在同一天。工作流的排程紀錄顯示，8 月 7 日最後一次成功執行後，隔天起每次排程都被標成 cancelled，中間還有一筆卡在佇列，最新一輪停在 pending。原因從外部看不出來，可能是帳號層的執行額度，也可能是維護者主動停用，repo 裡沒有交代。對訂閱者來說教訓很具體：免費管線斷更不會有人通知你，你的閱讀器只會安靜地不再出現新文章。訂閱任何第三方產生的訂閱源之前，先打開 XML 看 lastBuildDate 跟今天差幾天，這個習慣比看官網門面可靠得多，門面頁連時間戳都沒有，統計數字也是寫死的，唯一可信的更新訊號就是 XML 裡的 lastBuildDate。

README 說 MIT，repo 裡沒有授權檔案

README 的徽章列掛著 MIT License，文末也明言這套軟體基於 MIT License 協議開源，連結指向 repo 根目錄的 LICENSE 檔。repo 根目錄裡並沒有這個檔案，GitHub API 回報的授權欄位也是空的。

對只是 fork 來自己跑的人，這大概不影響什麼。但想把它的程式碼拆一部分放進自己的專案、改作後對外提供服務、或拿去商業使用的人，法律依據此刻是懸空的。MIT 的寬鬆授權要成立，得有那份聲明檔存在；徽章與宣稱不等於授權本身。這也提醒一個通則：看到開源專案先確認授權檔案真的在，宣稱與檔案是兩回事。

排程寫 12 點，cron 實際跑 13 點

文件上寫每天三個時段更新，標的是北京時間 7 點、12 點、16 點。工作流檔案裡的 cron 設定為 UTC 的 23、5、8 點，換算成北京時間是 7 點、13 點、16 點。工作流裡的註解寫的 13 點是對的，README 與執行摘要裡的 12 點則與實際行為對不上。

差一個小時對多數訂閱者無感，但它指向一個更實用的判斷習慣：這類專案的文件不會跟著程式碼同步演進，排程、數字、網址這種會漂移的東西，一律以工作流與設定檔為準。同樣把事情掛在 GitHub Actions 排程上的 Auto-login-netlib 保活腳本就上演過同款戲碼，README 寫 60 天、工作流註解寫 30 天、cron 實際又是另一種展開。文件看方向，行為看 yml，這條規則在免維護的小專案上尤其省事。

AI 篩選是會靜默退場的一層

README 把「Gemini AI 提純」列為主打亮點，說它會對新聞標題與摘要評分、留下高價值內容。原始碼裡的接線比宣傳誠實也更有彈性：篩選模組用 try import 載入，載入失敗只印一行警告照常往下走；初始化與篩選呼叫都包在例外處理裡，沒設金鑰會以未篩選的清單續跑，API 呼叫失敗則退回內建的關鍵字規則評分，清單照樣會被精簡，只是挑題的從 AI 換成一組固定規則。

換句話說，不申請 Gemini 金鑰也能把整條管線跑起來，訂閱檔照樣出，只是少了 AI 那道精選。設計上這叫優雅降級，宣傳上它讓「AI 篩選」聽起來比實際更核心。順帶一提，篩選用的模型在程式碼裡寫死為 gemini-3.1-flash-lite，換模型要改原始碼；金鑰的載入順序是參數、設定檔 config/API_KEY.txt（已列入 .gitignore，不會被 commit）、環境變數 GEMINI_API_KEY。程式裡另留有一段關閉 SSL 憑證檢查的 context，但它從未接上 API 客戶端，屬於無效的死碼。

fork 之前的三個成本

決定 fork 之前，有三個負擔要先放進考量。

最直接的負擔是 repo 體積。工作流每次跑完會把產出的訂閱檔、累積新聞文件與歷史資料 commit 回 repo，一天三次累積下來，這個專案目前已經長到約 253MB。fork 與 clone 都要繼承這份歷史，想瘦身就得自己改工作流，別再把產物 commit 回主分支。

平台額度與斷更風險排在另一層。GitHub Actions 免費額度對這種輕量排程綽綽有餘，但示範站 8 月 7 日後的停擺示範了額度之外的不確定性。排程被取消、執行卡在佇列，這些狀態 fork 到自己帳號後一樣可能遇到，差別是你有權限去看紀錄、換排程或重跑。

部署邊界則常被忽略。工作流部署 Pages 時上傳的是整個 repo 根目錄，內部狀態檔也一起公開：data/rss_history.json 這份約 792KB 的歷史紀錄、完整的來源設定檔，任何人都能直接下載。這不是漏洞，金鑰檔也被正確排除在上傳之外，但 fork 的人要知道掛上網的東西比「三個訂閱檔」多得多，任何沒被 gitignore 的檔案都會變成公開資產。

誰該 fork，誰該繞路

分流其實清楚。你想控制來源清單、想要一條不需要伺服器的訂閱源產生管線，或者單純想研究 GitHub Actions 怎麼組這類自動化，fork 它很值得。官方給的步驟就四步：fork repo、在 Settings 的 Pages 啟用 GitHub Actions 來源、視需要新增 GEMINI_API_KEY secret、等排程自己跑。想先試再說的話，把 config/rss_feed_urls.json 換成自己常讀的幾個源，手動觸發一次工作流，看產出的 XML 再決定要不要長期養它。

你要的本來就是一個閱讀介面，那有更省事的選擇。Readdig 這類自架閱讀器走伺服器路線，Node 加 PostgreSQL 加 Redis 一套起來，換到的是完整的閱讀體驗與社群討論聚合；不想自架任何東西的話，線上聚合器一樣能收 RSS 與電子報。你已經有順手的閱讀器、缺的是把又臭又長的摘要變成全文或中文，FeedCraft 這類 RSS 中介軟體架在源與閱讀器之間，做全文提取加 AI 翻譯。你想要的是 AI 挑題過的聚合站台而不是一條管線，RSS-AIGC 這類自架聚合平台把 Hacker News、GitHub、ArXiv 收進同一個介面做 AI 摘要再推送。News Agent 的獨特位置在它是清單裡最輕的那個：沒有伺服器、沒有資料庫，代價是你得自己當營運者。

授權與專案狀態

專案由 zskfree 維護，2025 年 5 月 27 日建立，最後一次程式碼更新在 2026 年 8 月 7 日，提交紀錄在停擺前每天三次的自動更新都看得到，star 與 fork 的比例顯示有一定實際使用量。issue 列表唯一一筆開著的，是 2025 年 11 月一則沒有內容的留言，回應紀錄付之闕如，單人專案的維運現實一覽無遺。授權狀態如前述：README 宣稱 MIT，授權檔案缺席，引用或改作前建議先請作者補上檔案再動工。程式碼本身結構乾淨，模組拆分與例外處理看得出用心，作為 GitHub Actions 自動化的學習材料，它的價值不因示範站的停擺而打折。