AI

七月底 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 前四列基本上是同一件事的兩種寫法。後兩列是分歧點，也是這篇文章真正想講的。 ...

我在 Mac 上跑一個叫 cc-memory-project 的個人 agent 環境（從 OpenClaw workspace 演化來的），有自製的 hybrid memory search、knowledge graph、cron → flag → SessionStart hook pipeline。一直缺一塊：人不在電腦前的時候，沒辦法用手機驅動它。 這篇記錄怎麼用 Claude Code 原生的 channels 功能把 Telegram 接回來、做成開機常駐，計價路徑怎麼選，以及部署過程踩到的四個坑。順帶講同一段時間長出來的兩個搭配能力：記憶的混合搜尋，跟抓 X/Twitter 走遠端瀏覽器。 為什麼是現在接回來 之前想過用 tmux 加一層腳本去駭出一個遠端輸入管道，一直沒做。結果 Claude Code 自己補上了 --channels：原生支援把外部聊天介面（Telegram、Discord 等）接成 agent 的輸入輸出端。官方做掉了我本來要自己駭的東西，那就不用駭了。 另一個推力是計價。Anthropic 五月公告，六月中之後 claude -p、Agent SDK、GitHub Actions、以及經 ACP 認證的第三方 app，會從訂閱池移出去、改吃獨立的月度 credit。但互動式 TUI（terminal 或 IDE）明確不受影響、繼續吃訂閱。所以如果我能讓 Telegram bridge 走的是「互動 TUI」這條路，就不會被新政策抽走額度。 計價路徑：先確認走的是哪條 動手之前先做了一個關鍵驗證：claude --channels（互動模式，不加 -p）開出來的 session，它的 entrypoint 是什麼。 # 開一個 channels session（用一個假的 echo plugin 測） claude --channels plugin:fakechat@claude-plugins-official # 然後去翻這個 session 的 jsonl，抓 entrypoint ls -t ~/.claude/projects/<project>/*.jsonl | head -1 \ | xargs grep -o '"entrypoint":"[^"]*"' | head -1 結果是 entrypoint=cli，不是 sdk-cli。這就確認了：claude --channels 是互動 TUI 那條路，吃訂閱、不碰新的 credit pool。boot log 也看得到完整互動 TUI 起來、SessionStart hook 把記憶底圖載進去、訊息進來 agent 回應。 ...

最近 Anthropic 官方放了一支 Building the future of agents with Claude 的對談，由 Alex Albert（Claude Relations）、Brad Abrams（Claude Developer Platform PM）、Katelyn Lesse（Engineering Lead）三人主持。12 分鐘左右，涵蓋 Claude Developer Platform 改名、agent 的定義、unhobble the model、Claude Code SDK 作為 general-purpose agentic harness、context pruning、agentic memory primitive、observability。 我在 Mac 上跑一個叫 cc-memory-project 的個人 agent 環境（從 OpenClaw workspace 演化），有自製的 hybrid memory search、knowledge graph、cron → flag → SessionStart hook pipeline。看完對談做了一些對映，挑兩個有具體 patch 落地的記錄一下。 五點對映 對談重點 我的個人 agent 現況 落地動作 Unhobble the model — scaffolding 在新模型上會變成 liability spec/ 三檔 + AGENTS.md / CLAUDE.md 約 800 行 砍 6 段過時 scaffolding（Group Chats / Heartbeats / 返工循環段移走 / MM 從主力改 fallback / 工具決策改 reference / OpenClaw sync 段濃縮）約 -1050 tokens SDK 是 general-purpose agentic harness 用 Claude Code 本身 + cron/hook/skill 自製 harness 不需動 Context pruning + tombstone memory-archive.py 把舊月份 section 直接刪掉 加 tombstone 留痕跡（第一個 patch） Agentic memory primitive hybrid search + graphify + hall taxonomy + always-on recall 不需動，方向對 Observability for long-running tasks SessionStart hook prompt-budget-telemetry 已寫 JSONL 升級為結構化 event（第二個 patch） Patch 1：Tombstone for archive_timeline scripts/memory-archive.py 的 archive_timeline 會把 MEMORY.md 裡 ### 2026-XX 這種舊月份 section 搬到 memory/timeline-archive.md。原本邏輯是直接刪除： ...

問題：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 個命中記錄。 ...