TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
aigc-weekly 開源 AI 週刊：OpenCode Agent 加 Cloudflare 自動策展 AIGC 內容，自架前先看三個真實成本
aigc-weekly 是一份用 OpenCode Agent 加 Cloudflare 自動策展 AIGC 內容的開源週刊，活站可訂 RSS，倉庫可自架。自架前要先算清三個真實成本：Cloudflare Containers 要付費、內容發現靠第三方 Firecrawl、授權是 AGPL-3.0。
用 AI 摘要這篇文章：
aigc-weekly 是一份由 AI Agent 自己抓文、篩選、排版的 AIGC 週刊，活站掛在 aigc-weekly.agi.li，整個產出流程的原始碼在 GitHub 上開源（倉庫 miantiao-me/aigc-weekly，AGPL-3.0 授權）。你想看 AI 資訊，訂它的 RSS 就夠；你想把這條「AI 自動編週刊」的管線搬回來自己跑、換成自己關心的主題，那它真正有價值的地方是那套架構，挑了哪些新聞反而是其次。
不過在把它當成「免費的 Cloudflare serverless 方案」之前，有三件 README 自己寫出來、但很容易被忽略的事會直接改變你的部署成本：Agent 跑的 Cloudflare Containers 要付費、內容發現靠第三方 Firecrawl 抓網、授權是 AGPL-3.0 的網路公用條款。這篇就從我把倉庫和活站實際查過一遍得到的結果，把這套架構和它的真實邊界講清楚。
一份 AI Agent 自己編的 AIGC 週刊
先把讀者和自架者分開。如果你只是想追 AI 工具和研究進展，aigc-weekly.agi.li 這個站我實際打開過，回 HTTP 200，伺服器是 Cloudflare，頁面由 Next.js 加 Payload CMS 驅動，RSS 在 /rss.xml 也正常回 XML。換句話說，純閱讀這條路是通的，訂閱 RSS 就拿到每週更新，不需要自己架任何東西。
它把自己定位成「Agentic AI Agent 驅動的 AIGC 精選週刊」。這裡的 AIGC 指的是 AI 生成的內容與相關工具鏈，週刊內容是簡體中文、面向中國大陸開發者圈，更新頻率宣稱每週。從首頁的原始碼看，它是一個標準的 Next.js 渲染站，有完整的標題、描述、社群分享標籤，SEO 基本面是做過的。對台灣讀者來說，當議題雷達可以，但若你要的是繁體中文、貼近本地語境的 AI 情報來源，它頂多是其中一條輸入，沒辦法當主力。我沒有實際訂閱跑滿幾週來評它的挑文品質，這份評價需要你自己訂一輪再決定。
值得停下來看的不是內容本身，而是「一份週刊怎麼由 AI Agent 自己跑起來」。這正是它跟一般 AI 資訊站拉開差距的地方，也是自架者會感興趣的部分。這兩年 AI 工具的情報來源爆炸性增長，靠人工編一份週刊越來越跟不上，用 Agent 接手例行性的抓取、初篩、排版，再讓人只在最後審一輪，是不少內容團隊正在試的方向，aigc-weekly 等於把這個方向做成一份公開可檢視的實作。
把策展拆開看：OpenCode Agent、Firecrawl 抓網、MCP 寫回 CMS
從 README 的架構章節和 agent/opencode.json、worker/ 目錄看，這套管線實際上是三個元件在分工，弄清誰負責什麼，後面估成本才估得準。
前台是一個 Next.js 15（App Router）加 Payload CMS 的網站，負責讀者看到的頁面和後台管理介面，透過 OpenNext 部署到 Cloudflare Workers，資料放在 Cloudflare D1（一種 SQLite），圖檔類的物件放 Cloudflare R2。這一層是讀者和編輯接觸的地方，也是整套架構裡最標準、替代方案最多的一塊。
第二層是真正做策展的 Agent。這裡有一個容易被誤解的點要先導正：很多介紹文把它說成「Claude Agent 驅動」，但從倉庫現況看，Agent 框架其實是 OpenCode（一套開源的 AI 編程代理，可以想成它跑一個能自己呼叫工具的 AI 助理），設定檔 opencode.json 的 schema 指向 opencode.ai/config.json。背後的 LLM 是用環境變數指定（OPENCODE_MODEL、OPENCODE_SMALL_MODEL），可以接 Anthropic、OpenAI、Google 的模型。所以精確的說法是：它用 OpenCode 當執行環境，模型可換，沒有綁死某一家的 Agent SDK。這個差別會影響你估算成本和選模型的方式，因為換模型只是改環境變數，不用改程式碼。
把一套「寫程式用的代理」拿來做編輯工作，本身就是這類專案常見的手法。OpenCode 這類代理擅長讀資料、呼叫工具、按規則產出結構化結果，這些能力拿來抓網、彙整、寫入 CMS 完全夠用，不一定要挑一套專門的「內容策展框架」。這也意味著如果你想改 Agent 的行為（例如換挑選標準、改摘要語氣），改的是 agent/.opencode/ 裡的提示詞和技能設定，不必碰一個封閉的黑盒子。
第三層是內容怎麼進來。Agent 透過 MCP（模型上下文協議，一種讓 AI 直接操作外部工具的標準介面）和 Payload CMS 溝通，把整理好的內容直接寫進資料庫，不經過人工貼文。這一步是「自動策展」能成立的關鍵：Agent 讀完資料、決定要收哪些、組好版面，然後自己呼叫 CMS 的 MCP 介面寫入，全程不需要你開後台手動操作。
抓網這一步不是 Agent 自己做，而是交給第三方服務 Firecrawl。設定檔裡能看到 mcp.firecrawl.dev 的 MCP 端點，需要你提供 FIRECRAWL_API_KEY。另外還有一個 Cloudflare Worker 負責把請求轉發到 Container，並控制那個跑 Agent 的 Container 的生命週期（worker/ 裡有 index.ts、container.ts、sse.ts 三支檔案對應這件事，sse.ts 負責解析 Container 回傳的事件流、讓 Worker 監控 session 狀態）。這層 Worker 不是多餘的：Cloudflare Containers 不像 Workers 那樣常駐，它會按需啟動、用完收掉，所以需要前面有一個輕量的 Worker 幫它接請求、喚醒它，再把串流結果轉給前端。實務上這代表 Agent 第一次跑時會有一段冷啟動的等待，不是點下去立刻有結果。整條鏈「Worker 喚醒 Container、Container 跑 OpenCode Agent、Agent 呼叫 Firecrawl 抓網、再透過 MCP 寫回 CMS」聽起來環節很多，但每一環都是現成的服務，這也是這類專案能一個人維護的原因。
拆開之後會發現，「AI 自動策展」其實是「Firecrawl 負責抓、OpenCode Agent 負責讀和寫、Payload CMS 負責呈現」三塊拼起來。這個分工清楚，但也代表每一塊的依賴和成本都要分開算，前一段那個「自動」二字底下藏了不少外部服務。
「全 Cloudflare 免費」斷在哪裡：Containers 要付費
README 在技術棧那段寫了一句很關鍵但容易被略過的話：Agent 執行環境 Cloudflare Containers「需要付費套餐，或者在本地運行」。這句話直接打破了「整套東西都跑在 Cloudflare 免費方案上」的想像。
前台（Workers）、資料庫（D1）、物件儲存（R2）這些確實在 Cloudflare 上，免費方案有一定的額度可以跑，對一個讀者量不大的個人週刊綽綽有餘。但真正做策展決策的 Agent 是跑在 Containers 裡，而 Containers 不是免費方案能用的。你要嘛升到 Cloudflare 的付費方案（Workers Paid 每月數美元起），要嘛照 README 的建議在本地用 Docker 跑（pnpm dev:worker 會啟動本地的 Container 沙箱，需要你機器上有 Docker）。
這就是「免費 serverless」敘事常見的斷點：前台看起來免費，但只要有「一個需要持續運算的元件」，成本就會從那一層冒出來。CloudMeet 那個開源會議預約系統也走 Cloudflare 自架，最後因為郵件通知得綁第三方 Emailit，免費的邊界一樣是在「會發熱的元件」那裡斷掉的，可以對照著看（CloudMeet 開源會議預約系統）。如果你之前考慮過 SubsTracker 這類跑在 Cloudflare Workers 的自架工具，那種純 Workers 加 KV 的方案還能停在免費方案，aigc-weekly 這裡多了一層 Containers 的門檻，要算進去。
內容從哪裡來：Firecrawl 這層第三方依賴
第二個邊界是內容來源。Agent 本身不會上網抓頁面，抓網這件事整個外包給 Firecrawl。Firecrawl 是一個把網頁轉成結構化資料給 AI 用的商業服務，有免費額度，超過要付費。
這件事對你的決策有兩層影響。成本上，週刊每跑一輪策展都要燒 Firecrawl 的額度，如果你想把主題擴大、抓的來源變多，Firecrawl 的用量會跟著長，免費額度撐不撐得住要看你實際跑的規模，這部分我同樣沒有實跑量測過，建議你拿自己想抓的網址數量直接去 Firecrawl 官網算一下。可信度上，策展的覆蓋範圍取決於 Firecrawl 抓得到什麼，如果某些網站擋爬、或 Firecrawl 對某類來源支援不好，Agent 再聰明也沒有原料可以挑。
把抓網交給第三方是合理的工程選擇，自己寫一套穩定的爬蟲成本很高、還要顧反爬。但這代表這套「自架」其實不是完全自足的，你的管線裡有一段命脈握在 Firecrawl 手上。和那種「模型在雲端、閘道在本地」的 BYOK 架構一樣，本地這段再多，只要有一段依賴外部服務，整條鏈的邊界就劃在那裡（OmniRoute 那種本地閘道加雲端模型的邊界 是同一類問題的不同切面）。想完全擺脫 Firecrawl，你得改 Agent 的 MCP 設定、換成自己寫的抓取工具，等於把「外包出去的抓網」拿回來自己養，這個工程量要先有心理準備。
AGPL-3.0 授權：自架沒事，改作對外服務要回饋原始碼
第三個邊界是授權。LICENSE 全文是 GNU AGPL v3，這是比 MIT、Apache 更嚴格的 copyleft 授權，關鍵差別在於「網路使用」條款：如果你修改了這套程式，然後把它當成一個對外提供服務的網站上線，使用者透過網路互動就算觸發，你有義務把你修改後的完整原始碼公開給這些使用者。
對個人用途的影響很小。你自己架一份、自己看、甚至改來只追蹤自己關心的主題，不對外公開，這些都不會觸發 AGPL 的公開義務。但如果你打算把它改一改、包成自己品牌的一個對外 AI 週刊服務上線營運，那就要準備好把你的修改版本開源出去。這跟那種「隨便用、隨便改、不用回饋」的 MIT 專案是不同的法律預設，採用前要先確認你的使用情境落在哪一邊。
倉庫本身的健康度：552 顆星、64 個 fork、TypeScript 寫的、預設分支 master，作者 miantiao-me（顯示名稱「麵條」，南京的開發者），倉庫 2025 年 11 月底建立，最近一次推送在 2026 年 7 月中，還在動。這個倉庫的舊網址 ccbikai/aigc-weekly 現在會 301 轉向到 miantiao-me/aigc-weekly，因為作者把 GitHub 帳號改名了；你看其他介紹文如果還寫舊網址，那是過時的，引用時要用現址。活站本身沒有公開的服務條款或隱私權頁面，純讀者風險很低（訂閱不用建帳號、不送個人資料），但如果你要把自架版做成對外服務，這些頁面得自己補上。
訂閱還是自架：一個簡單的判斷
回頭看你會落在哪一邊。如果你是純讀者，要的就是一條 AI 議題的 RSS 輸入，那訂 aigc-weekly.agi.li/rss.xml 就解決了，完全不用碰部署，也不用管 Containers 和 Firecrawl。把它的 RSS 丟進你平常用的閱讀器，再配幾條繁體中文的 AI 來源平衡語境，就是最省事的做法。
如果你是開發者，看的是「我想不想用同一套架構，跑一份自己主題的週刊」，那把它當成「OpenCode Agent 加 Firecrawl 加 Cloudflare 三件式」的參考實作最合適。你可能會想把主題換成前端工程、資安漏洞、或某個語言生態的更新，這時改的是 Agent 的提示詞和 Firecrawl 抓的網址清單，架構本身不用動。動手前先確認三件事：你的 Cloudflare 帳號能不能用 Containers（要付費方案）、你的 Firecrawl 額度夠不夠撐你想抓的範圍、你能不能接受 AGPL 對改作對外服務的公開義務。三項都過了，再去 clone 倉庫照 README 的 pnpm deploy 走，作者把資料庫遷移和應用部署都包進同一條指令了；任何一項卡住，這套就不會是「免費擁有自己 AI 週刊」那麼輕鬆的事。
它的價值是示範一條可以複製的 Agent 策展管線長什麼樣子，至於幫你省下訂閱 AI 資訊的錢，那倒是其次。把那三個真實成本算清楚，你才會知道這條路自己走不走得下去。
