用 RSS + AI Agent 自建每日資訊摘要

用 RSS + AI Agent 自建每日資訊摘要

為什麼要自建資訊流 每天早上打開手機,幾十個 tab、幾百則未讀。技術論壇、社群媒體、新聞源——每個都說自己很重要。花 30 分鐘刷完,真正有用的可能三條。 更糟的是,演算法幫你選的東西,跟你真正需要的東西,往往不是同一批。演算法優化的是你的停留時間,不是你的知識密度。 所以我想做的事很簡單:自己選來源、讓 AI 幫我篩重點、每天早上給我一份摘要。 不是讓 AI 取代我讀東西——是讓它幫我從 200 則裡挑出值得讀的 20 則,然後我自己決定要不要點進去看全文。 Pipeline 一:RSS 路線 RSS 是最乾淨的資訊來源。沒有演算法、沒有廣告、格式統一。大多數技術論壇和部落格都還支援 RSS,只是很多人忘了它的存在。 架構 自架 Tiny Tiny RSS(TTRSS),訂閱想追的 feed。TTRSS 有完整的 API,可以程式化操作一切。 流程長這樣: cron(每天早上) → shell script 呼叫 TTRSS API 抓未讀 → 餵給 AI agent 做分類摘要 → shell script 上傳靜態頁面 + 標記已讀 TTRSS API 操作 # 登入拿 session SID=$(curl -s -X POST "https://rss.example.com/api/" \ -H "Content-Type: application/json" \ -d '{"op":"login","user":"myuser","password":"mypass"}' \ | python3 -c "import json,sys; print(json.load(sys.stdin)['content']['session_id'])") # 抓未讀文章(最多 200 篇) curl -s -X POST "https://rss.example.com/api/" \ -H "Content-Type: application/json" \ -d "{\"op\":\"getHeadlines\",\"sid\":\"$SID\",\"feed_id\":2,\"view_mode\":\"unread\",\"limit\":200}" # 處理完後標記已讀 curl -s -X POST "https://rss.example.com/api/" \ -H "Content-Type: application/json" \ -d "{\"op\":\"catchupFeed\",\"sid\":\"$SID\",\"feed_id\":2}" API 回來的是 JSON,每篇有 title、link、excerpt。腳本把這些整理成一個大 prompt,丟給 AI agent 做摘要。 ...

February 20, 2026 · 3 分鐘 · Mark Lee
在 WSL 上跑 Qwen3-TTS Voice Clone:從 Fish Speech 到三代 TTS 的踩坑之旅

在 WSL 上跑 Qwen3-TTS Voice Clone:從 Fish Speech 到三代 TTS 的踩坑之旅

為什麼要自己跑 TTS? 市面上的 TTS API 不缺——ElevenLabs、OpenAI TTS、Azure Speech。但如果你想要的是用自己的聲音說話,而且不想每個月付錢、不想把錄音傳到別人的 server,那選擇就少很多了。 我的需求很簡單:讓我的 AI agent(跑在 OpenClaw 上)能用我的聲音回覆語音訊息。Agent 跑在 Oracle Cloud 的 ARM VPS 上,沒有 GPU。但家裡有一台 Windows 桌機,裝了 RTX 4070 Ti。 所以架構很明確:VPS 負責 agent 邏輯,Windows 桌機負責 GPU 推理,中間用 SSH tunnel 串起來。 聽起來簡單。實際上花了三代 TTS 模型、無數次 WSL 踩坑,才到今天穩定運作的狀態。 第一代:Fish Speech(2025 年底) Fish Speech 是最早嘗試的方案。它支援 voice cloning,品質不錯,社群也活躍。 部署在 WSL 上,port 8880,透過 autossh reverse tunnel 讓 VPS 能連到。一開始跑得還行,但遇到幾個問題: 模型更新頻繁,API 不太穩定 VRAM 吃得多,跟其他任務搶資源 後來有更好的選擇出現,就換了 Fish Speech 的功勞是:它驗證了整個架構是可行的——WoL 喚醒、WSL systemd、autossh tunnel、VPS 呼叫腳本這一整套 pipeline。後面換模型只需要改 server 端,其他都能重用。 ...

February 19, 2026 · 4 分鐘 · Mark Lee
OpenClaw 記憶管理:從零到自迭代的架構演化

OpenClaw 記憶管理:從零到自迭代的架構演化

前言 當你給一個 AI agent 一台 VPS、一堆 API key、和一個空白的工作區,它要怎麼「記住」東西? 這篇記錄了我在 OpenClaw 上建構 AI agent 記憶系統的過程——從最初的空白 MEMORY.md,到現在帶有優先級標籤、自動過期清理、事件時間軸的結構化架構。不是教學文,而是真實的踩坑記錄。 第零天:空白的開始 OpenClaw 啟動時,工作區裡有四個檔案:SOUL.md(人格設定)、USER.md(使用者資訊)、AGENTS.md(行為規範)、和一個空的 MEMORY.md。 Agent 每次醒來(新 session)都是失憶狀態——它只知道人格和行為規範。所有對話、決策、偏好,隨著 session 結束就消失了。 第一個問題:agent 要怎麼知道「上次我們聊到哪了」? 第一階段:Daily Files(流水帳) 最自然的做法:每天一個 markdown 檔,如 memory/2026-01-26.md、memory/2026-01-27.md,記錄當天發生的事。 格式很自由——## 標題 分段,裡面就是對話摘要、設定紀錄、debug 過程。Agent 在每次 session 開始時讀今天和昨天的 daily file,大概知道最近在幹嘛。 好處: 簡單、自然、寫入無摩擦。 壞處: 兩週前的事?要翻十幾個檔案。 「上次 OpenClaw 升級是什麼時候?」→ 沒人記得在哪個 daily file 裡。 重要決策淹沒在日常瑣事中。 第二階段:MEMORY.md(策展式長期記憶) Daily file 是流水帳,MEMORY.md 是策展。 想法很簡單:把真正重要的東西從 daily file 「升級」到 MEMORY.md。Agent 每次啟動都讀這個檔案,等於它的「核心記憶」。 最初的 MEMORY.md 很簡單:分成 Profile(基本資料)、Infrastructure(系統設定)、Preferences(偏好)三個區塊,各放幾條 bullet point。 問題來了:誰來維護? ...

February 18, 2026 · 2 分鐘 · Mark Lee