問題：SKILL.md 靠人工調校太慢 OpenClaw 的 skill 系統靠 SKILL.md 指引 agent 行為——什麼時候觸發、怎麼執行、輸出什麼格式。寫得好，agent 就穩定；寫得差，每次跑出來的品質都不一樣。 我的 workspace 裝了二十多個 skill，平時靠「出問題 → 改一行 → 觀察幾天 → 再改」的方式迭代。這種人工調校有兩個問題： 回饋週期太長。 改了一行要等幾天才知道有沒有效果。 靠直覺不靠數據。 改完「感覺比較好」，但沒有量化指標。 如果能讓 LLM 自己評估 SKILL.md 的效果，再自動改進，迭代速度會快很多。 靈感：GEPA（ICLR 2026） 逛 GitHub 時發現 NousResearch 的 hermes-agent，裡面有一套 self-evolution 機制，核心引用了 GEPA 這篇論文（Genetic Prompt Evolution with NL Reflection，ICLR 2026 Oral）。 GEPA 的概念不複雜： 評估：用 LLM 打分（而不是人類標註） 反思：讓 LLM 自己分析「哪裡扣分了、為什麼」 變異：根據反思結果修改 prompt 選擇：保留最高分的版本，淘汰退步的 跟 RLHF 不同，整個過程只需要 API call，不需要 GPU 做 gradient update。論文宣稱比 GRPO 少 35 倍 rollouts。 ...

Espresso 的變數太多：豆子、烘焙度、粉量、研磨度、萃取時間⋯⋯每個參數都會影響風味。想穩定萃取，就得記錄每次的參數，慢慢找到每支豆子的 sweet spot。 紙筆記了幾天就懶了，試過幾個 App 也都不順手。最後決定自己做一個。 用對話蓋出來的 整個開發過程是透過 OpenClaw（開源 AI Agent 框架）完成的。我沒打開 IDE，就是在對話框裡描述需求： 「單頁 HTML，localStorage 存資料，Chart.js 畫圖。」 「豆子名稱要能搜尋。」 「預設值帶入上一杯的參數。」 AI 生成程式碼、我測試、回報問題、它修。來回大約 30 分鐘，從空白檔案到部署上 NAS。 Placeholder 的坑 過程中卡最久的是預設值。需求很簡單：新增記錄時自動帶入上一杯的粉量、研磨度等參數，使用者只改有變動的欄位。 前幾版用 placeholder 顯示預設值。畫面上看得到數字，但 placeholder 只是提示文字，不是 input.value。留空送出時，存進去的是空值，不是畫面上顯示的數字。 來回修了三版才想通：別用 placeholder 模擬預設值，直接把值填進 input。看到什麼就存什麼，沒有歧義。 最佳參數怎麼算 儀表板有一個「各豆子最佳參數」的區塊。一開始是取所有記錄的平均值，但這樣失敗的杯次會拉低數據。 改成：找每支豆子評分最高的記錄，取那些記錄的平均水粉比、研磨度、萃取時間。邏輯很簡單，就是 filter + reduce，但語義上合理多了——你想參考的是最好的幾杯，不是所有杯的平均。 長什麼樣 記錄表單：填完按儲存，預設值自動帶入上一杯 最近 10 杯，每筆可編輯或刪除 儀表板：各豆子最佳參數、研磨度趨勢、評分分佈 功能 記錄：豆子、烘焙度、粉量、研磨度、萃取時間、出杯量、粉碗、評分、備註 豆子和粉碗都有搜尋（從歷史記錄建 autocomplete） 預設值自動帶入，選了歷史豆子會切換成該豆子上次的參數 時間快捷鍵：現在 / 5 分前 / 10 分前 / 30 分前 / 1 小時前 儀表板：研磨度趨勢、評分分佈、各豆子最佳參數 JSON 匯入匯出 深色主題，手機可用 技術上就是一個 HTML 檔，沒後端。 ...

前情：記憶清理的粗暴現狀 上一篇講了記憶架構怎麼從空白演化成多層結構——daily files、MEMORY.md 長期記憶、自動反芻和做夢機制。寫入的問題解決了，但清理一直很粗暴。 memory-expire.sh 的邏輯就一行：超過 30 天就歸檔。 大部分時候這沒問題。但有些記憶明明超過 30 天了，卻每天都在被搜尋命中——比如二月初寫的 espresso 配方筆記，到三月中還一直被引用。一刀切歸檔會把活躍記憶誤殺。 另一方面，有些記憶寫完就再也沒被搜到過。它們佔著 embedding 搜尋的空間，拉低搜尋精度。 需要一個比日期更聰明的判斷依據。 思路：追蹤「誰在用這段記憶」 靈感很直接：如果一段記憶在過去 30 天內被搜尋命中過多次，它就是「活的」，不該被歸檔。 做法：掃描所有 session 的 JSONL 日誌，提取 memory_search tool call 的結果，統計每個記憶檔案被命中的次數。 session JSONL → 提取 memory_search 結果 → 統計命中次數 → hit_counts.jsonl 這個 hit count 資料就是 Memory Quality Score 的核心。 實作：從 Python 到 Rust Python 原型（200 行） 第一版用 Python 寫，邏輯很直接： 掃 ~/.openclaw/agents/main/sessions/*.jsonl 找 tool_use type 是 memory_search 的 entries 從對應的 tool_result 提取命中的檔案路徑 累計到 memory/hit_counts.jsonl 跑一次大概 160ms，掃完 145 個 session 檔案得到 408 個命中記錄。 ...

這是我們在 OpenClaw 系統實作記憶機制的心得，也是對「讓 AI Agent 學會做夢」一文的延伸。我們不談論文，只談踩過的坑和做出來的解法。 為什麼 AI Agent 需要記憶？ 不是所有 LLM 應用都需要記憶。一個回答使用者問題的客服機器人，問完就可以忘了；一個生成文案的工具，用完就走。但當 Agent 需要 長期運行、累積經驗、理解上下文，情況就完全不同了。 我們的 OpenClaw Agent 需要： 記住使用者的偏好（他喜歡高密度資訊，不愛廢話） 記住基礎設施的狀態（哪台機器開了、哪個服務掛過） 記住決策的來龍去脈（當初為什麼選這個方案） 沒有記憶，每次對話都是獨立的瞬間，Agent 永遠是新手。這就是我們要解決的問題。 難題一：壓縮 — context window 有限，保留什麼？ 問題 即使是 GPT-5.4 或 Claude 4.6，context window 終究有限。當記憶累積超過臨界點，你不可能把全部東西都塞進去。壓縮不是選項，是必然。 但壓縮代表選擇。選擇本身就是困難的： 哪些對話值得記住？ 抽象化（summarization）會不會丟失關鍵細節？ 如果壓縮演算法選錯了重要資訊，後果是什麼？ 業界做法 常見的壓縮策略有幾種： 方法 說明 缺點 簡單摘要 LLM 產出濃縮版本 容易遺漏細節，無法精確檢索 向量檢索 存 embedding， query 時召回 只能搜「相似」，無法知道「重要」 優先級排序 依重要性決定保留顆粒度 依賴準確的優先級判斷 我們的做法 我們採用 三層記憶架構，用「分層」取代「一次性壓縮」： daily memory（便簽）→ MEMORY.md（長期）→ reference/（結構化知識） daily memory：每天的 raw 紀錄，像貼在冰箱上的便利貼 MEMORY.md：萃取後的長期知識，需要主動維護 reference/：結構化資料（設定檔、API 文件、流程 SOP） 同時搭配 P 級優先級： ...

記憶的腐爛問題 跑了兩個月的 AI agent，記憶檔案從幾 KB 膨脹到幾十 KB。一開始沒什麼感覺，直到某天 agent 引用了一個三週前就被推翻的技術決策，我才意識到問題有多嚴重。 記憶不是寫進去就沒事了。沒有維護的記憶，比沒有記憶更危險——因為 agent 會很有信心地根據過時資訊做決策。 人類的記憶會在睡眠中自動整理：重要的強化、矛盾的修正、不用的淡化。AI agent 的記憶沒有這個機制，所以得自己造一個。 靈感來源：Karry 的 Orb 直接觸發這個想法的，是 Karry 寫的一篇文章：《認知アップグレードの本当のループ——AI Agent の記憶設計から學んだ 3 つのこと》。 Karry 運營自己的 AI agent「Orb🔮」超過兩個月，得出一個跟主流完全不同的結論：記憶系統的核心不是 Vector DB，是認知循環。他指出三個真正的難題： 什麼時候該忘？ — 頻率衰減不夠用，年用一次但救命的記憶不能丟 AI 會捏造記憶 — 搜尋結果為空 ≠ 記錄不存在 教訓寫了也不一定有效 — 「知道」和「做到」之間有巨大的鴻溝 他的解法是三層記憶（L0 原始日誌 → L1 回顧摘要 → L2 長期記憶）加上「Hard Constraint」——犯錯兩次就強制鎖死，不靠自覺靠系統。 這些觀點跟我自己踩坑的經驗高度吻合，但我的問題不完全一樣。Karry 著重在「怎麼讓記憶影響行為」，我面對的是更前面一步：怎麼讓記憶自己保持乾淨。 Orb 做了什麼，我做了什麼不同 Karry 的 Orb 和我的 agent 有很多共通點——都用 Markdown 檔案、都分層、都相信簡單架構。但設計哲學有幾個明顯的差異： Karry’s Orb 我的做法 記憶儲存 Markdown + LLM 多段抽取 Markdown + LLM，但加了 Gemini embedding 做向量索引 遺忘策略 P0/P1/P2 分級 + 人工 review P0/P1/P2 分級 + 自動化腳本 (janitor/expire) 防呆機制 Hard Constraint（犯兩次就鎖） 分析/執行分離（反芻只建議，main session 決策） 獨特機制 — 「做夢」——冷記憶隨機抽取找跨領域洞察 記憶維護 LLM 每日抽取 cron 四件套：janitor + reflect + dream + expire 矛盾處理 手動 反芻引擎自動檢測，但人工確認修改 最大的差異是：Karry 更信任 agent 自己管記憶（自動壓縮、自動昇格），我更偏向讓 agent 當顧問、人類做最終決策。 ...

調磨焦慮 新手玩 espresso 最怕的事，大概就是調磨。 磨了半包豆子還是苦的、換個參數變酸了、昨天好喝今天又不對了。網路上的建議又互相打架——有人說看時間、有人說看重量、有人說看流速。看完十篇文章比看之前更焦慮。 最近密集看了幾個 YouTube 頻道，英文的 Lance Hedrick 和中文的「咖啡愛好者」翔子，加起來六七支影片。看完之後覺得調磨這件事被講得比實際上複雜太多。 以下是我的整理。不是教學，就是把不同來源的觀念串在一起，幫自己（和你）理一個清楚的框架。 時間不重要，比例才重要 Lance Hedrick 反覆強調一件事：萃取時間是最不重要的變數。 很多人（包括我）一開始都在追「25-30 秒」這個數字。但同一個比例下，25 秒萃完和 35 秒萃完，可能都好喝。時間只是結果，不是原因。 真正決定一杯 espresso 好不好喝的，是 ratio（粉液比）： Ratio 風格 適合 1:1 ~ 1:1.5 濃厚、body 強 深焙、拉花基底 1:2 經典平衡 大多數豆子的起點 1:2.5 ~ 1:3 清爽、風味清晰 淺焙、果酸型 Hedrick 說得很直接：1:2 不是萬能公式，每支豆子都不同。 與其糾結時間，不如固定粉量，調整出液量，喝一口再決定方向。 翔子也有類似的觀點：一豆一參數，沒有標準答案。 酸和苦怎麼判斷 調磨的過程一定會遇到「這杯太酸」或「這杯太苦」的問題。但酸和苦各有兩種，搞混了會越調越歪。 萃取不足的酸 vs 水果酸 萃取不足的酸： 尖銳、刺舌、像咬到未熟的水果，很快就消失 水果酸（好的酸）： 圓潤、帶甜感、像柑橘或莓果 前者需要調整（磨細、拉長比例），後者是咖啡本身的風味，留著就好。 過萃的苦 vs 巧克力苦 過萃的苦： 乾澀、尾韻持續很久、像咬茶葉渣 烘焙的苦（正常）： 巧克力感、回甘、有層次 Hedrick 建議的判斷法很實用：喝一口，問自己「是尖的還是圓的？」「是很快消失還是留很久？」 感受 可能原因 調整方向 尖銳、快速消失 萃取不足 磨細，或多拉 5g 出液 乾澀、持續很久 過度萃取 磨粗，或少拉 5g 出液 又酸又苦 通道效應 / 萃取不均 檢查布粉和填壓 重點：一次只改一個變數。 不要同時調研磨度又改粉量又換比例，那等於重新開始。 ...

前言：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 的成本越高，但有事的機率並沒有相應增加。 ...

為什麼寫這篇 最近開始認真玩 espresso。機器是入門級的 E5EC1（51mm 濾杯、沒有三相閥、沒有壓力表），磨豆機也不是什麼好貨。在這種設備條件下，網路上那些「壓力曲線」「流量分析」的內容基本上看了也用不上。 直到看了 Lance Hedrick 的兩支影片，才覺得 dialing in 這件事被講得比實際上複雜太多了。 以下是我的筆記，不是教學，就是整理給自己看的。 六大萃取變數：你只需要管三個 Lance 把 espresso 萃取拆成六個變數，但真正需要動手調的只有前三個： 1. Dose（粉量）— 設好就不動 重點不是「幾克」，而是粉層深度。 不同咖啡密度不一樣，同樣 18g 在不同豆子裡體積完全不同。正確的做法是：裝粉、壓粉、裝上機器（不啟動）、拉出來看頂部。 有螺絲或濾網壓痕 → 粉太多 沒碰到 → 正確 離太遠 → 粉太少（body 會弱） 找到之後記下克數，固定不變。這是你的常數。 2. Grind（研磨度）— 只管「能不能正常跑」 網路上最常見的建議是「grind finer」。但 Lance 指出，磨太細會帶來三個問題： 口感混濁（muddy）：風味糊在一起 Channeling 增加：粉餅太密，水走捷徑 澀感：細粉穿過濾杯，帶來不愉快的收斂感 他的建議是把研磨度調到「shot 能正常跑」就好——水流是穩定的細流而不是噴射，開始萃取後 3-5 秒才開始有液體滴出。到了這個區間，就不要再動研磨度了。 3. Ratio（比例）⭐ 最重要的旋鈕 “Ratio is the number one dictator on extraction yield” 這是 Lance 反覆強調的核心觀點。比例對萃取率的影響比研磨度更直接、更可預測： 太酸 → 拉長 ratio（例如 1:1.8 改 1:2.2） 太苦 → 縮短 ratio 想要更厚的 body → 縮短 ratio（但可能要接受多一點酸） 4-6. 時間、溫度、壓力 — 忽略 時間：「時間是紅鯡魚」——它是其他變數的結果，不是輸入。不要執著 30 秒 溫度：淺焙高溫、深焙低溫，但大多數機器調不了 壓力：9 bar 是標準但不是真理，大多數機器也調不了 三個省豆技巧 這是第二支影片的重點，比基礎理論更實用。 ...

背景 我在玩 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 看的操作手冊。結構大概長這樣： ...