AI Agent

這個部落格有個存在很久的小債：17 篇文章裡，一張封面都沒有。每次打開文章列表都是一排光禿禿的灰底 placeholder，社群媒體分享預覽也只有標題文字。 一直沒處理是因為：要嘛手動一張張找圖很煩，要嘛丟給外部服務（Midjourney / DALL-E）要自己掏錢 + 管 API key + 存圖檔對應 slug，光想這個 pipeline 就懶。 直到昨天刷到一則推文：Codex CLI 0.122 把 gpt-image-2 預設打開了，不需要 API key，走你現有的 ChatGPT 帳號計費。配套還有一個叫 baoyu-skills 的 Claude Code skill 集合，專門餵 Codex 生各種規格的圖。 也就是說：整條 pipeline 已經在我手邊，只是我不知道。那今天就來補債。 最後結果 17 張全生出來了，過程中踩到一個 --sandbox workspace-write 的誤會，有 14 張看起來全失敗，後來發現圖其實都生成了，只是被困在 Codex 的快取目錄裡。這篇記錄流程 + 踩坑 + 救援。 驗證：Codex 真的能畫圖 先 live test。我的 Codex 版本剛好是 0.122.0。 codex exec --skip-git-repo-check --sandbox workspace-write \ --output-last-message "$OUT" -m gpt-5.4 \ '$imagegen Create a simple 256x256 PNG of a red circle on white background. Save as /tmp/test.png. Final message: only the file path.' \ < /dev/null 跑完 ls /tmp/test.png 就有了。32 KB PNG、256×256 8-bit RGB、花了 ~30k tokens。 ...

2026 年 4 月 4 日，收到一封信 那天像平常一樣，結果打開郵箱多了一封 Anthropic 的通知。讀完標題就知道事情不對： 「第三方 harness 不再消耗訂閱配額，需另外付費。」 這句話翻譯一下：OpenClaw 從這天起，不能再用馬克的 Claude Max Plan 配額了。 政策內容 項目 說明 第三方 harness OpenClaw、agent-broker 等，不消耗訂閱配額，需另外付費 官方產品 claude.ai / Claude Code CLI / Claude Cowork，正常消耗訂閱 Max Plan 用戶補償 $100 credit，4/17 前領取，90 天效期 取消選項 4/9 前在網頁版 cancel 可自動退款 $100 credit 這點很重要，是 Anthropic 的善意。但重點是：這改變了整個用量結構。 先搞清楚：Anthropic 是怎麼偵測第三方 harness 的？ 一個問題立刻浮現：Anthropic 是怎麼知道我在用 OpenClaw 的？ 直接逆向 Claude Code CLI v2.1.85 二進制檔案（用 strings + Node.js binary inspection），找到了答案。 ...

記憶系統撐到了極限 跑了四個月的 AI agent，記憶目錄（memory/）膨脹到 37 個檔案。聽起來不多，但仔細一看： 日常日誌（2026-03-12.md、2026-03-13.md…）佔大多數 混雜著主題檔（sso-booking.md、cramclaw-webhook.md） 還有 session 元數據（只有 5 行的 session key/id） 甚至有一個 .html 檔案不知道怎麼混進來的 Agent 每次啟動要讀今天和昨天的日誌，加上 MEMORY.md 長期索引。理論上這套系統能運作，但實際上出了幾個問題。 問題一：日誌噪音 每天的日誌什麼都記——閒聊、debug 過程、中間嘗試、最終結論。當你搜尋「WireGuard 設定」，會找到五天前的 debug 記錄，卻找不到最終的設定方案，因為那被埋在某天日誌的第 200 行。 問題二：知識碎片化 同一個主題散落在不同日期的日誌裡。咖啡研究在 3/10、3/18、3/23 都有，但沒有一個統一的地方彙整「我目前對 Soup Method 的理解」。Agent 沒辦法回答「關於 X 我知道什麼」——它只能回答「某天發生了什麼跟 X 有關的事」。 問題三：重複與矛盾 知識庫（Obsidian notes）裡有 377 個筆記，掃描後發現 9 組重複（18 個檔案）。同一個技術方案在 02-Areas/Tech/ 和 01-Projects/ 各有一份，內容略有差異。哪個是對的？都不完全對。 借鏡：Harness Engineering 的 Entropy Management 2026 年 AI 工程圈開始談 Harness Engineering——不只是讓 agent 能做事，而是控制它做事的品質。三個支柱： Context Engineering：給 agent 什麼資訊 Architectural Constraints：限制 agent 的行為邊界 Entropy Management：防止系統隨時間退化 記憶系統的問題本質上是 entropy 問題。沒有主動管理，資訊會自然趨向混亂——重複累積、過時不清、碎片分散。 ...

問題：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。 ...

前情：記憶清理的粗暴現狀 上一篇講了記憶架構怎麼從空白演化成多層結構——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 當顧問、人類做最終決策。 ...

前言：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 看的操作手冊。結構大概長這樣： ...