AI

最近 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 個命中記錄。 ...