AI Agent

七月底 CMU 放出一篇叫 ACM（Agentic Context Management）的論文，講的是怎麼讓 agent 自己管理 context。我維護一套 agent 記憶系統已經幾個月，看到題目的第一反應是想知道學術界處理同一個問題的做法跟我摸索出來的差多少。 對照下來的結果比我預期有意思：元件幾乎一一對得上，但兩邊解的其實是不同軸向的問題，而且論文裡有一組數據，反過來替我當初一個靠直覺做的設計決定提供了證據。 論文在做什麼 論文是 arXiv 2607.23809，程式碼在 lixiaochuan2020/agentic-context-management，MIT 授權。網路上不少轉述寫成「CMU 與 Meta 開源」，但論文首頁腳註寫得很明白：Meta 只擔任顧問角色，沒有實驗、資料收集或處理是在 Meta 的機器上跑的。這是 CMU 的工作。 ACM 的做法是給 agent 兩個工具，然後不設外部監控器： manage_context：agent 自己在推理途中決定要壓縮，由 summarizer LLM 產出摘要放回 context，被壓掉的原始訊息全部存到外部 workspace，每份摘要配一個 ID。 query_memory：帶著 summary ID 加一句自然語言問題，由 querier LLM 到存起來的原文裡撈回細節。 論文一直強調「lossless」，準確的意思是原文不刪、可回查。壓縮這個動作本身仍然有損，回查也要靠另一顆 LLM 去檢索，這條路徑會不會漏，論文沒有量測。 比工具設計更關鍵的是後訓練。他們用 Qwen3.5-9B 當學生、Qwen3.5-397B-A17B 當老師，讓學生同時跑「有工具」和「沒工具」兩種軌跡，再由老師雙向標註：對前者刪掉太早壓縮的呼叫、改成實際動作；對後者插入該壓卻沒壓的點。所以模型學的是「何時該壓」跟「何時不該壓」兩件事。 元件對照 我這套系統的骨架放在 openclaw-workspace-template，下面提到的檔案路徑都能在那個 repo 裡找到。 ACM 元件 我這邊的對應物 實作 manage_context 壓縮 curate-memory skill + journal rotation LLM 判斷內容該進 journal、notes/ 還是 MEMORY.md 索引；scripts/memory-archive.py --mode rotate-journal 把超過 5 天的日誌搬進 memory/archive-YYYY-MM/ 摘要落盤、原文不刪 同一組 rotation 原始日誌整份保留在 archive 目錄，--mode archive-timeline 另外把 MEMORY.md 裡過期的月份區塊搬到 timeline-archive.md 摘要 ID ↔ 原文映射 MEMORY.md 索引行 每條長期記憶就一行，附著指回 notes/ 或 memory/ 的檔案路徑 query_memory 回查 scripts/memory-search-hybrid.py BM25 加 jieba 分詞，再套時間衰減與 hall type 加權；輸出每一筆都附 verify: Read <path> 讓 agent 自己回原文核對 壓縮時機由誰決定 hook 與 cron templates/.claude/hooks/memory-search-trigger.py 掛 UserPromptSubmit；歸檔走 launchd 排程 後訓練 沒有 全部靠 prompt 加 hook 前四列基本上是同一件事的兩種寫法。後兩列是分歧點，也是這篇文章真正想講的。 ...

這天我在整理自己的 AI agent 記憶系統,順手研究了兩個開源專案(TencentDB-Agent-Memory 和 obra/superpowers),挑出幾個值得學的改動。 其中兩個我沒自己下判斷,而是交給同一套流程:讓一個較快、較便宜的 model 實作,再讓另一個同型 model 去對抗式複審。兩個改動、同一套流程,結果卻相反——一個被否決、一個通過合併。 回頭看,決定結果的不是流程本身,是「複審手上有沒有客觀標準可以打」。 那套流程長什麼樣 拆成兩個角色,刻意用不同的 agent: 實作 agent:在隔離的 git worktree 改 code、自己驗證、commit、回報。 複審 agent:進同一個 worktree,被明確指示「去 refute 第一版的宣稱、找邊界 case」,不是幫忙背書。 關鍵設計只有一條:複審不能是實作者自己。實作者對自己寫的東西有動機說「大致還好」,這個動機本身就是盲點來源。 第一輪:一個排序改動,被 golden bench 打回 背景是記憶搜尋的排序,想從線性加權換成 RRF(reciprocal rank fusion)。 實作 agent 加了新模式、保留舊的當預設、跑了幾個 query 的 A/B 對照,自評「大部分持平,有一個 query 略差」,並宣稱測試通過。 複審 agent 做了實作 agent 沒做的一件事:跑 repo 裡本來就有的 golden benchmark。結果不太好看: MRR 從 0.675 掉到 0.188、Recall@1 從 0.60 掉到 0.07。15 題裡 8 題退步、0 題改善。不是「略差」,是全面退化。 一個真 bug:RRF 讀到的是四捨五入到小數點三位的顯示值。在低區分度的 query 上,幾百個候選塌成十來個相異值、出現 35-way 平手,排序退化成按掃檔順序抽籤。 一個空測試:複審做了突變測試——把舊路徑的一個關鍵係數整段拿掉,測試竟然全綠。所謂「測試通過」根本沒在保護舊行為。 判決:否決,branch 直接刪掉。舊的本來就是預設,零損失。 ...

讓 AI agent 寫 code 久了，會發現一個固定毛病：你只要一個能跑的小東西，它給你一個帶設定檔、抽象層、還預留三個未來擴充點的「框架」。它當然會寫，毛病出在它的預設值——多寫一點比較安全。 最近讀了一個叫 Ponytail 的開源專案，專門治這個。它的招牌語是一句很有態度的話： The best code is the code never written. 我把它的原始碼 clone 下來實際跑過一遍 hook，這篇是拆解之後的筆記——它哪裡有意思、哪裡要保留懷疑。 它不是工具，是一份「規則」 第一個容易誤會的點在它的形態。Ponytail 把一份規則集注入成 agent 自己的 system context，agent 讀進去之後直接「就是」懶模式。它不是一個你去呼叫的 library，也沒有一個「外部第二意見」在旁邊讓 agent 查詢引用——規則直接長在 agent 身上。 所以你不會看到 agent 回你「根據 Ponytail……」。它只是行為變了：動手前先停下來想一輪「這真的需要寫嗎」。 核心：一道 YAGNI 階梯 整套東西的心臟是一道階梯。動任何 code 前，從上往下走，停在第一個成立的那一階： 1. 這東西需要存在嗎？ speculative = 跳過，一行說明 (YAGNI) 2. 標準庫能做嗎？ 用它 3. 平台原生功能涵蓋嗎？ <input type="date"> 勝過 picker library 4. 已裝的依賴能解嗎？ 用它，不為幾行能解的事新增依賴 5. 一行能解嗎？ 那就一行 6. 真的都不行才： 寫能動的最小實作 兩階都成立就取較高的那階。第一個能動的懶解，就是對的解。 ...

這個部落格有個存在很久的小債：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 當顧問、人類做最終決策。 ...