OpenClaw

前言：AI Agent 的維護成本問題 大家都在聊怎麼讓 AI agent 更聰明，很少人聊怎麼讓 agent 更省。 真實數字：我的 OpenClaw agent 一開始全用 LLM heartbeat，每小時燒 token 檢查「有沒有事」。一天 24 次 LLM call，90% 的回覆都是 HEARTBEAT_OK——什麼事都沒發生。 問題不是 LLM 太貴，是用 LLM 做不需要 LLM 的事。 這篇記錄了一個 AI agent 從「LLM 做所有事」進化到「只做該做的事」的過程——heartbeat 系統三次重構，self-improvement 系統上線，以及一個反直覺的結論：AI agent 成熟的標誌不是用了多少 AI，而是把多少東西從 AI 移出去。 演進一：全 LLM Heartbeat（失敗） 最初的架構很直覺：OpenClaw 內建 heartbeat 機制，每小時叫醒 agent 做檢查。檢查清單包括 email、calendar、版本更新、sub-agent 殘留、cron 狀態等。 想法很美好：讓 agent 主動發現問題。 實際跑起來的問題： Token 浪費：agent 醒來要讀 context，花 token。90% 的時間回 HEARTBEAT_OK（沒事）。 Session 衝突：偶爾 heartbeat cron 跟使用者對話搶 session，誰也進不去。 Heartbeat skip：當 main session 閒置太久，OpenClaw 會跳過 cron，導致監控失效。 最致命的是：這是一個「越有用越浪費」的系統。監控項目越多，每次 heartbeat 的成本越高，但有事的機率並沒有相應增加。 ...

背景 我在玩 Polymarket——一個基於加密貨幣的預測市場。你可以買入「某事件會發生」或「不會發生」的合約，價格反映市場共識的機率。如果你認為市場定價錯了，就有套利空間。 一開始是手動看新聞、手動下單。後來想自動化，畢竟我已經有一個跑在 VPS 上的 AI agent（用 OpenClaw 串接 Telegram），何不讓它幫我盯盤？ 第一版：全自主 agent 最初的版本很粗暴： 每 30 分鐘，cron 喚醒 AI agent Agent 自己用 CLI 查持倉、掃新聞、分析信號、下單 所有邏輯都在一個大 prompt 裡 問題很快浮現： 成本高：每次喚醒都用高階模型（因為需要推理能力），30 分鐘一次，token 消耗驚人 不可預測：同一組資料，不同次執行可能產生完全相反的結論 難以除錯：出了問題很難回溯「當時為什麼這樣決定」 浪費算力：90% 的時間市場沒有變化，agent 做了一堆分析然後什麼都沒做 核心矛盾：資料收集不需要推理能力，但決策需要。把兩者混在一起，等於用高階模型的價格做低階模型的工作。 第二版：分層架構 改版的核心想法：分離收集與決策，只在需要時才啟動高階模型。 ┌─────────────┐ ┌──────────────┐ ┌─────────────┐ │ Cron 排程 │────▶│ 資料收集層 │────▶│ 決策層 │ │ (每 30 min) │ │ (低成本模型) │ │ (高階模型) │ └─────────────┘ └──────────────┘ └─────────────┘ │ │ 有信號時才觸發 審閱 + 下單 │ │ ┌──────▼──────┐ ┌─────▼──────┐ │ Exit 檢查 │ │ Telegram │ │ 新聞掃描 │ │ 回報結果 │ │ 跟單偵測 │ └────────────┘ └─────────────┘ 資料收集層 一個 shell script 串接多個 Python 模組，每次執行輸出一份 JSON 摘要： ...

起因 工作上有個需求：把散落在多個內部 API 的資料整合成一份分析報告。涉及的資料源有好幾個，每個 API 的認證方式、資料格式、存取路徑都不一樣。 我手上有兩個 AI agent 環境——一個跑 Claude（Opus），是我自己長期使用的個人 agent；另一個跑 OpenAI 的模型，是公司環境。需求最終要在公司環境執行，但探索和開發的過程在個人 agent 上進行比較順手。 問題來了：怎麼把我跟個人 agent 討論出來的知識，有效地交給公司 agent 使用？ 不能只丟一段文字 最直覺的做法是把對話結論複製貼上，寫個文件丟過去。但實際試了就知道——一份平鋪直敘的文件，agent 讀完還是會問你一堆問題： 「這個 API 的 base URL 是什麼？」 「認證 token 放哪裡？」 「回傳格式是 JSON 還是 Parquet？」 「欄位名稱是 revenue 還是 acc_R100？」 每個問題都合理，但每次來回都是時間成本。尤其在 Telegram 這種非同步介面上，一個問題可能要等你看到、回覆、agent 再繼續，中間過了好幾分鐘。 Skills 作為 Agent 間的介面 後來採用的做法是把知識打包成一個 Skills 專案。這是 OpenClaw 生態系的一個概念，但核心想法跟框架無關： skills/ ├── my-skill/ │ ├── SKILL.md # 入口：agent 第一個讀的文件 │ └── references/ # 詳細參考資料 │ ├── api-guide.md │ └── data-sources.md └── knowledge/ └── domain-logic.md # 領域知識和判斷邏輯 SKILL.md 是關鍵。它不是寫給人看的文件，是寫給 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 做摘要。 ...

前言 當你給一個 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。 問題來了：誰來維護？ ...