Architecture

OpenAI 在 4 月 15 日更新了 Agents SDK，加入了 sandbox 隔離、Harness/compute 分離、Manifest 工作區描述、Capabilities 分層。看完技術文件後我的第一反應是「這跟我們在做的事情不一樣」，第二反應是「但裡面有幾個結構性概念可以偷」。 這篇記錄我們從中借了什麼、怎麼落地到 openclaw-workspace-template v3.0.0，以及為什麼大部分東西我們選擇不抄。 兩個系統的定位差異 先把前提講清楚：OpenAI Agents SDK 跟我們的 workspace template 解決的是完全不同的問題。 OpenAI Agents SDK 我們的 workspace template 目標使用者 企業，多租戶 SaaS 個人，單使用者 執行環境 雲端 sandbox（Modal / E2B / Cloudflare / Vercel） 本機 Mac / Linux，直接 filesystem access 權限模型 Tool calls 在 unprivileged container 裡跑，隔離網路和 secret 跟使用者同權限，能碰 git / cron / Telegram / Obsidian State serialize_session_state() / resume()，snapshot 整個 workspace 檔案系統就是 state，git 就是 snapshot Memory 內建 Memory() capability，session close 自動 summarize → consolidate 自建 MemPalace：hall-tagged journal + 主題筆記 + weekly reflection + knowledge graph OpenAI 在解的是「怎麼讓 agent 安全可靠地跑在生產環境」。我們在解的是「怎麼讓一個人的知識和自動化系統持續累積和整合」。拿來直接比就像比 AWS Lambda 跟家裡的 crontab。 ...

記憶系統撐到了極限 跑了四個月的 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 問題。沒有主動管理，資訊會自然趨向混亂——重複累積、過時不清、碎片分散。 ...

這是我們在 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 的維護成本問題 大家都在聊怎麼讓 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 的成本越高，但有事的機率並沒有相應增加。 ...

前言 當你給一個 AI agent 一台 VPS、一堆 API key、和一個空白的工作區，它要怎麼「記住」東西？ 這篇記錄了我在 OpenClaw 上建構 AI agent 記憶系統的過程——從最初的空白 MEMORY.md，到現在帶有優先級標籤、自動過期清理、事件時間軸的結構化架構。不是教學文，而是真實的踩坑記錄。 第零天：空白的開始 OpenClaw 啟動時，工作區裡有四個檔案：SOUL.md（人格設定）、USER.md（使用者資訊）、AGENTS.md（行為規範）、和一個空的 MEMORY.md。 Agent 每次醒來（新 session）都是失憶狀態——它只知道人格和行為規範。所有對話、決策、偏好，隨著 session 結束就消失了。 第一個問題：agent 要怎麼知道「上次我們聊到哪了」？ 第一階段：Daily Files（流水帳） 最自然的做法：每天一個 markdown 檔，如 memory/2026-01-26.md、memory/2026-01-27.md，記錄當天發生的事。 格式很自由——## 標題 分段，裡面就是對話摘要、設定紀錄、debug 過程。Agent 在每次 session 開始時讀今天和昨天的 daily file，大概知道最近在幹嘛。 好處： 簡單、自然、寫入無摩擦。 壞處： 兩週前的事？要翻十幾個檔案。 「上次 OpenClaw 升級是什麼時候？」→ 沒人記得在哪個 daily file 裡。 重要決策淹沒在日常瑣事中。 第二階段：MEMORY.md（策展式長期記憶） Daily file 是流水帳，MEMORY.md 是策展。 想法很簡單：把真正重要的東西從 daily file 「升級」到 MEMORY.md。Agent 每次啟動都讀這個檔案，等於它的「核心記憶」。 最初的 MEMORY.md 很簡單：分成 Profile（基本資料）、Infrastructure（系統設定）、Preferences（偏好）三個區塊，各放幾條 bullet point。 問題來了：誰來維護？ ...