OpenClaw進階：如何通過九層塔架構打造高效能AI Agent
整理版優先睇
大上下文窗口唔等於上下文管理，九層塔先係長期運行 AI Agent 嘅關鍵
呢篇文章係基於 OpenClaw 多 Agent 環境超過三個月嘅實際運行經驗，同埋近一個月對九層上下文架構嘅集中升級整理。作者指出，好多人以為上下文窗口越大就越唔需要記憶管理，但其實窗口大隻解決「裝得幾多」，唔解決「裝咩、幾時召回、點樣壓縮、點樣進化」。為咗令 Agent 喺長期運行、多會話、多任務、多 Agent 協作入面持續治理上下文，作者逐步演化出一套「九層塔」架構。
九層塔分成三組，每組三層：基礎層（L1–L3 身份、規則、記憶）、運行時層（L4–L6 檢索、召回、會話生存）、進化層（L7–L9 整理、迭代、技能化）。呢個唔係線性流水線，而係一個閉環——每一層嘅輸出都係其他層嘅輸入。作者特別強調，最容易「安靜吃虧」嘅兩點都喺 L6：context engine 唔綁定 slot 唔會報錯，只係悄悄退化；LLM 摘要器冇做 secrets redaction，API key 會經 FTS 同向量被放大注入。
整體結論係：大上下文窗口唔係上下文管理。Context Engineering 嘅核心係「治理上下文」——寫入、召回、壓縮、清噪、晉升、驗證、回滾。唔需要一次過搭曬九層，可以分階段：L1–L3 幾小時上手，L4–L6 係質變臨界點，L7–L9 令系統真正自愈。工程態度比單點修復更重要，開源組件嘅小修整要做成 idempotent 同 boot-time 自愈嘅工程資產。
- 結論：大上下文窗口只解決容量，唔解決治理；九層塔從九個維度管理上下文生命週期。
- 方法：九層塔分基礎層（L1-L3 身份/規則/記憶）、運行時層（L4-L6 檢索/召回/會話生存）、進化層（L7-L9 整理/迭代/技能化）。
- 差異：三層記憶架構適合簡單場景，九層塔解決跨日、跨會話、多 Agent 協作嘅系統化治理。
- 啟發：L6 最容易安靜失敗——context engine 唔綁 slot 唔報錯、secrets 未 redact 會經 FTS 放大，搭建時要一次到位。
- 可行動點：唔需要一次過起九層；先 L1-L3 幾小時，再 L4-L6 達到質變，最後 L7-L9 形成閉環。
內容結構
memory/ shared/ ← 所有 Agent 可讀寫：項目、偏好、決策 daily/ ← 每日共享日誌 private/ ← 各 Agent 私有記憶 self-improving/ ← 行為改進記錄引言：大窗口嘅幻覺
上下文窗口由 4K 去到 128K 甚至 1M+，好多人以為窗口夠大就唔需要記憶管理。呢個係一個危險嘅幻覺。
窗口變大解決咗「能放多少」，但冇解決放咩、幾時放、過期點清、跨會話點延續、多 Agent 點共享又隔離、錯誤記憶點修正、經驗點沉澱成能力。
呢啲問題需要 Context Engineering——對上下文嘅工程化治理。本文介紹嘅「九層塔」就係喺 OpenClaw 環境入面演化出嚟嘅一套上下文管理架構。
九層塔總覽：三組九層嘅閉環架構
九層塔分成三組：基礎層（L1-L3）、運行時層（L4-L6）、進化層（L7-L9）。每層解決一個維度，互相補足。
- L1 身份注入層：用 SOUL.md、IDENTITY.md 定義 Agent 係邊個，每次 session 自動注入，防止人格漂移。
- L2 規則治理層：用 AGENTS.md、TOOLS.md 界定操作邊界，規則要分層，衝突時高優先級覆蓋。
- L3 文件記憶層：用 Markdown 持久化知識，shared / private 分區，方便人工修正。
- L4 語義檢索層：embedding + BM25 混合搜索，有 temporal decay 同 MMR，結果要質量閾值。
- L5 主動召回層：用戶消息前自動檢索相關記憶，壓縮成摘要注入，並標記為 untrusted context。
- L6 會話生存層：用 Lossless Context Engine 做 DAG/摘要/分層壓縮，確保長會話唔丟上下文。
運行時層嘅 L6 最複雜，最容易安靜失敗。作者建議搭建時一次到位，特別係要綁定 context engine 並做好 secrets redaction。
L6 嘅核心係「運行時上下文生存」，而唔係單純 flush 去文件。
進化層：由經驗到技能
L7 後台整理層（Dreaming）每日自動運行 deep sleep、light sleep、REM，從 session corpus 提煉候選記憶，並用 post-sweep watchdog 清理噪聲。
Dreaming 唔係記住曬所有嘢，而係有選擇地晉升高價值內容，promotion rate 一般只有 4-6%。
L8 自我迭代層將錯誤記錄、信號積累、規則晉升分開，重複出現先改規則，shared-rules 跨 Agent 共享。用 agent id 而非 persona name 命名目錄，避免分裂。
- 1 L7 噪聲清理係必要後置步驟，否則 heartbeat、compaction 等內容會污染長期記憶。
- 2 L8 要有一致嘅目錄命名慣例，用絕對路徑避免 cron 飄移。
- 3 L9 技能要有生命週期：創建、使用、驗證，可能 deprecate。
呢三層令系統隨時間變得更好，形成真正嘅閉環。
搭建路徑同工程態度
唔需要一次過搭九層。建議分階段：第一階段（L1-L3）幾小時上手；第二階段（L4-L6）係質變臨界點；第三階段（L7-L9）令系統自愈。
工程態度比單點修復更重要：對開源組件嘅小修整要做成 idempotent、boot-time 自愈嘅工程資產。
作者整理咗 14 個高頻陷阱，當中最容易「安靜吃虧」嘅係 #6 同 #7。搭建 L6 時建議一次到位，避免 context engine 冇綁定或 secrets 被放大注入。
- L1-L3：寫好身份文件、建立記憶目錄、定義簡單規則。
- L4-L6：啟用向量搜索、配置 active memory、設定 session memory 同 compaction。
- L7-L9：啟用 Dreaming、建立 self-improving、啟動技能進化。
完整嘅九層塔先可以真正做到上下文治理，令 Agent 喺長期運行中持續進化。
OpenClaw Agent嘅長期記憶、主動召回同自我進化架構
一個真正長期運行嘅AI Agent，需要嘅唔係更大嘅上下文窗口，而係一套完整嘅上下文治理體系。
基於OpenClaw多Agent環境三個幾月嘅實際運行經驗，以及近一個幾月對九層上下文架構嘅集中升級同整理。九層塔唔係一次性設計出嚟，而係喺解決一個又一個實際問題嘅過程中逐步演化出嚟。運維治理本身都係架構成熟嘅一部分。
引言：大窗口嘅幻覺#
上下文窗口從4K到128K再到1M+，好多人以為「窗口夠大就唔需要記憶管理喇」。
呢個係一個危險嘅幻覺。
窗口變大解決嘅係「能放幾多」，但冇解決：
放咩入去？ 幾時放？ 過期嘅點樣清？ 跨會話點樣延續？ 多Agent點樣共享同隔離？ 錯誤記憶點樣修正？ 經驗點樣沉澱成能力？
呢啲問題，唔係靠「更大嘅窗口」解決到。佢哋需要嘅係 Context Engineering——對上下文嘅工程化治理。
本文介紹一套喺OpenClaw多Agent環境中運行三個幾月、並喺近一個幾月集中升級整理出嘅上下文管理架構。我哋稱之為「九層塔」。
從三層到九層：點解簡單記憶唔夠#
最基礎嘅記憶架構分三層：
- Layer 0
：身份同規範（靜態，低頻修改） - Layer 1
：知識積累同檢索（持續增長） - Layer 2
：驅動行動（實時運轉）
三層架構能讓Agent「記住嘢」。但當你開始長期運行——跨日、跨星期、多會話、多Agent協作——你會發現三層唔夠：
- 記憶膨脹
：文件越嚟越多，bootstrap注入被截斷 - 噪聲累積
：系統日誌、heartbeat、maintenance消息混入記憶 - 召回失敗
：記咗但揾唔到，或者揾到嘅唔係最相關嘅 - 壓縮丟失
：長會話被compaction後，關鍵決策冇咗 - 重複勞動
：同樣嘅任務做咗十次，每次由零開始
九層塔就係為咗解決呢啲問題而逐步演化出嚟嘅。
九層塔唔係替代三層架構，而係喺三層之上回答咗「系統化治理」呢個新問題。兩者讀起嚟可對比，但本文唔依賴你讀過前文。
九層塔總覽#
L9 | 能力進化層⚠ 3 經驗 → 可複用技能 |
L8 | 自我迭代層⚠ 5🚨 2 錯誤 / 反饋 → 行為規則 |
L7 | 後台整理層⚠ 3🚨 1 短期上下文 → 長期記憶 |
L6 | 會話生存層⚠ 5🚨 2 Lossless Context Engine / compaction / flush |
L5 | 主動召回層⚠ 3🚨 1 消息前自動注入相關上下文 |
L4 | 語義檢索層⚠ 4🚨 1 embedding / search / fallback |
L3 | 文件記憶層⚠ 3 Markdown長期事實 |
L2 | 規則治理層⚠ 3 行為邊界 / 工具協議 |
L1 | 身份注入層⚠ 3 身份 / 用戶 / persona |
⚠ 數字 為常見坑數 · 🚨 數字 為高嚴重度坑數
三組，每組三層：
- 基礎層（L1-L3）
：定義Agent係邊個、應該點樣做、記住咗咩 - 運行時層（L4-L6）
：讓記憶喺對話中真正發揮作用 - 進化層（L7-L9）
：讓系統隨時間變得更好
L1身份注入層：Agent係邊個#
解決嘅問題：Agent需要一個穩定嘅身份錨點，否則喺長對話或多Agent場景中會「人格漂移」。
OpenClaw中嘅實現：
SOUL.md— 定義人格、語氣、行為邊界 IDENTITY.md— 基本資訊：名、角色、emoji USER.md— 用戶畫像：偏好、溝通風格、技術棧
關鍵設計：呢啲文件喺每次session啟動時自動注入context window，唔依賴Agent主動讀取。
常見坑：
身份文件寫得太長，擠佔有效上下文空間 多Agent場景中，由chat history推斷身份而唔係由配置文件確認 persona寫得太強，壓過任務目標
L2規則治理層：Agent應該點樣行動#
解決嘅問題：Agent需要明確嘅操作邊界——咩可以做、咩唔可以做、點樣做。
OpenClaw中嘅實現：
AGENTS.md— 操作手冊：讀寫邊界、協作協議、安全規則 TOOLS.md— 工具使用規範：咩場景用咩工具 Bootstrap配置 — 啟動時嘅行為指令
關鍵設計：規則分層——身份規則 > 安全規則 > 任務協議 > 工具偏好。優先級明確，衝突時高優先級覆蓋。
常見坑：
規則堆太多，Agent遵循率下降 規則冇分層，任務協議同人格描述撈埋一齊 缺少「完成後必須彙報/落盤」嘅閉環要求
L3文件記憶層：長期事實載體#
解決嘅問題：Agent需要一個持久化嘅、可人工修正嘅知識庫。
OpenClaw中嘅實現：
memory/
shared/ ← 所有 Agent 可讀寫：項目、偏好、決策
daily/ ← 每日共享日誌
private/ ← 各 Agent 私有記憶
self-improving/ ← 行為改進記錄關鍵設計：
Markdown格式：可讀、可diff、可版本控制、可人工修正 shared / private分區：多Agent協作時既共享又隔離 寫入規則明確：咩資訊寫邊度，由AGENTS.md定義
常見坑：
MEMORY.md變咗垃圾桶，咩都塞入去，導致bootstrap截斷 shared區被某個Agent意外覆蓋 短期日誌同長期事實撈埋一齊，信噪比下降
L4語義檢索層：從記憶中揾上下文#
解決嘅問題：記憶文件越嚟越多，冇可能全部塞入prompt。需要按需召回。
OpenClaw中嘅實現：
向量索引（embedding）+ 混合搜索（BM25 + semantic） 多源檢索：memory文件 + session transcript Fallback機制：primary backend超時時降級到builtin index
關鍵設計：
唔止「向量相似度」，仲有 temporal decay（時間衰減）同 MMR（多樣性） 索引定期更新（掃描 + embedding） 搜索結果有質量閾值，唔係「揾到就注入」
工程Insight：
搜索timeout由15s提到60s只係解決咗配置層問題。真正嘅瓶頸喺query expansion + LLM rerank路徑。搜索系統需要區分：索引是否更新、embedding是否覆蓋、query path是否穩定、ranking是否符合預期。
常見坑：
淨係睇「文件已索引」，忽略embedding覆蓋率 Fallback靜默工作，掩蓋primary backend嘅性能問題 exact query被日誌文件排喺源文件前面（rerank偏差） 檢索CLI嘅stdout唔係乾淨JSON——遇到collection唔存在/參數異常時會先print Warning:或Usage:文本再俾JSON。下游parser必須容錯噉跳過非JSON前綴，拋錯會令多collection路徑整體退化到慢fallbackper-agent索引會累積大量 orphan向量（content已刪但vector留低），需要週期性cleanup；orphan佔比 > 50%係sqlite體積膨脹嘅常見原因
L5主動召回層：消息前自動帶上下文#
解決嘅問題：用戶唔應該每次都講「幫我查嚇記憶」。系統應該自動判斷需要咩上下文。
OpenClaw中嘅實現：
Active Memory插件：喺用戶消息進入Agent前，自動搜索相關記憶 將召回結果壓縮成短摘要注入prompt 結果標記為 untrusted context：明確告知Agent呢部分內容來自自動召回而唔係用戶原話，可質疑、可忽略、可反向校驗，唔作為權威事實直接採用
關鍵設計：
主動召回唔等於無腦注入。有質量閾值、空結果過濾、相關性判斷 注入內容明確標記來源，Agent可以選擇忽略 對慢query可以選擇更輕嘅搜索模式
常見坑：
低質量摘要污染當前對話 Active memory輸出被誤當作trusted fact 召回subagent timeout太短，導致頻繁空結果 - 檢索後端單點失敗傳染整條召回鏈
：active memory調底層多collection檢索時，任一子查詢拋錯會令整條召回退化到builtin slow path（>10s / 0 hits）。L4 parser必須fail-soft（warn + 返回空數組），主動召回層先至穩定
L6會話生存層：長會話唔丟上下文#
L6係九層塔最複雜、亦都最容易「靜靜雞蝕底」嘅一層——本節多數 critical標註集中喺呢度，建議慢慢讀。
解決嘅問題：長對話會超過模型上下文窗口。只靠簡單截斷或一次性compaction，會令早期約定、任務狀態同關鍵決策從當前對話消失。
OpenClaw中嘅實現：
Lossless Context Engine（lossless-claw）：作為 plugins.slots.contextEngine嘅運行時上下文引擎，實時攝入消息，並用 DAG /摘要/分層壓縮嚟組裝下一輪模型上下文Session Memory hook：實時保存會話transcript，保留可審計嘅原始時間線 Compaction Memory Flush：壓縮前自動將重要資訊寫入durable memory，作為最後一道持久化防線 Session transcript被索引，可供L4語義檢索同後續Dreaming使用
關鍵設計：
L6嘅中心唔係單純flush，而係「運行時上下文生存」：邊個負責攝入、壓縮、組裝當前會話 檢索層回答「該找回咩長期記憶」，context engine回答「當前呢條長會話點樣持續保持連貫」——兩者互補，唔互相替代 memoryFlush / safeguard compaction係fallback safety rail，唔係替代context engine嘅主機制 長任務應該外化plan到文件，而唔係只存在context裏便 - 必須顯式綁定
plugins.slots.contextEngine：唔綁唔會報錯，只會悄悄退化到legacy截斷引擎（詳見坑#6） - 摘要LLM調用前必須regex redact secrets
：否則sk-XXX / token會經FTS + vector持續放大注入（詳見坑#7） - 短源 (< 200 tokens) 跳過summarizer
：避免「摘要 = timestamp + 原文」嘅反向膨脹（詳見坑#8）
工程Insight：
compaction / heartbeat / system prompt被寫入transcript後，可能被後台整理層（L7）錯誤晉升為長期記憶。會話生存層同後台整理層之間需要噪聲過濾機制。
Secrets喺raw消息裏便容易識別（grep一抓一個準），但LLM摘要將佢換個上下文重新表述後，固定嘅grep規則就唔一定catch得到了。喺源頭redact比事後audit容易得多——呢個係L6必須正視嘅安全責任。
常見坑：
只依賴大窗口模型，唔做顯式context engine / 持久化治理 將memoryFlush當成主機制，而唔係fallback safety rail 長任務冇外化plan，壓縮後目標漂移 系統消息混入transcript，污染下游
L7後台整理層：Dreaming消化上下文#
解決嘅問題：短期記憶同session transcript會無限增長。需要定期整理、去重、提煉。
OpenClaw中嘅實現：
Memory Core Dreaming：每日自動運行 Deep sleep：修復recall store Light sleep：從session corpus中提煉候選記憶 REM：生成摘要同關聯 Post-sweep watchdog：檢查Dreaming產物、清理噪聲、統計健康指標
關鍵設計：
Dreaming唔係簡單嘅「將所有嘢都記住」，而係有選擇噉晉升 - Promotion threshold
：只有高價值內容先會從短期進入長期 噪聲清理係Dreaming嘅必要後置步驟 - L7仲要監控L6引擎本身
：context engine係個安靜失敗嘅組件（唔寫入即等於沉默）。L7應該包含一個星期度健康監控cron，監控lcm.db增長、DAG leaf / condensed比例、WAL 狀態。否則一次配置迴歸可能要40日先被發現
工程Insight：
Dreaming會將heartbeat、maintenance、compaction通知等系統噪聲納入候選。因此需要post-sweep watchdog：每日Dreaming完成後自動清理噪聲、統計promotion ratio、報告異常。典型數據：每日清理200+行噪聲，promotion率約4-6%。
健康監控閾值要分級——🔴先告警（ingest沉默 / lcm停擺 / WAL損壞），🟡只寫報告唔打擾（DAG淺 / WAL滯後），🟢靜默通過。否則告警疲勞會令真問題被淹沒。
常見坑：
後台任務成功但報告投遞失敗，無人知道結果 噪聲進入corpus後被長期污染 Promotion threshold太寬，低價值內容晉升
L8自我迭代層：從錯誤中改進行為#
解決嘅問題：Agent會犯錯。同樣嘅錯誤唔應該犯第二次。
OpenClaw中嘅實現：
memory/self-improving/
hot/ ← 當前活躍的行為信號
corrections/ ← 被糾正的錯誤記錄
signals/ ← 觀察到的行為模式
shared-rules/ ← 晉升為穩定規則的條目關鍵設計：
錯誤記錄 → 信號積累 → 規則晉升：唔係一次犯錯就改規則，而係重複出現先至晉升 shared-rules跨Agent共享：一個Agent嘅教訓，所有Agent受益 有reviewer同threshold，防止規則膨脹 - agent identity用唯一規範
：自我迭代目錄用agent id（ agent-A/agent-B/ ...），唔用persona name（Persona-A/Persona-B呢類用戶自定義顯示名）。所有跨進程協作（cron、patrol、promotion）用同一份mapping - cron payload用絕對路徑
：週期性自反思任務裏便寫 memory/self-improving/X/hot.md呢種相對路徑會被不同cwd解析到不同workspace，造成同一agent嘅內容分裂到多處。統一用/root/.openclaw/workspace/memory/self-improving/<id>/...嘅絕對路徑 - patrol用枚舉白名單
： KNOWN_AGENTS+KNOWN_FILES列表化，掃到唔在白名單嘅就報警。呢個能在第1星期內發現命名漂移、拼寫錯誤（如corrrections.md多打一個r）、persona vs agent-id大小寫分裂
常見坑：
將一次性偏好過早晉升為全局規則 冇deprecation機制，過時規則永遠存在 目錄命名不一致，導致掃描漏項 persona name vs agent id雙軌命名唔統一，cron同patrol各走各路寫出多份目錄 cron payload用相對路徑，cwd一漂全軍覆沒
L9能力進化層：將經驗變成技能#
解決嘅問題：Agent反覆做同樣嘅嘢，每次由零開始。經驗應該固化為可複用能力。
OpenClaw中嘅實現：
Skill Evolution：從歷史任務中 harvest → synthesize → review → promote 產出嘅skill存入shared-skills目錄，所有Agent可調用 定期審計：清理過窄、過時、重複嘅skill
關鍵設計：
技能唔係手動寫嘅，而係從實際任務中自動提煉 有review環節：唔係所有workflow都值得變成skill 技能有生命週期：創建 → 使用 → 驗證 → 可能deprecate
常見坑：
技能過窄，只適用於特定場景 命名差，其他Agent揾唔到 私有上下文被錯誤抽象成shared skill
九層之間嘅數據流#
點擊任一節點跳到對應章節 · 虛線表示跨輪閉環
呢個唔係線性流程，而係一個閉環。每一層嘅輸出都係其他層嘅輸入。
搭建路徑建議#
唔需要一次性搭建九層。建議分階段：
第一階段：基礎可用（L1-L3）
| 第二階段：檢索同召回（L4-L6）
| 第三階段：自動進化（L7-L9）
|
源碼層嘅小修整：將開源組件做成「工程資產」#
老實講，將九層塔落到生產時，光配置係唔夠嘅。前文L4（parser fail-soft）同L6（摘要前redact secrets / 短源跳過LLM）提到嘅幾處問題，都需要喺開源組件源碼上做小幅適配。
呢一節唔再重複「改咩」，重點講「點樣令呢種修改活下去」——臨時hotfix會隨着npm升級或上游git pull失效；只有做成可觀測、可重啟自癒嘅工程資產，先至真正成為架構嘅一部分。最佳實踐係：
// PATCH:<name> 註釋，apply腳本據此判斷冪等 | |
ExecStartPre 自動跑apply腳本——上游覆蓋目標後下次重啟自動重打 | |
.patch | |
令對開源組件嘅小修整可被持續維護，而唔係「換部機就丟」。
運維真心話：14個最容易踩嘅坑#
九層塔架構清單容易睇，但落地時會反覆踩一啲坑。以下係從實際運行整理出嘅高頻陷阱，按層歸類：
篩選全部14L1–L31L44L52L64L72L82運維1🚨 高嚴重度2
| context engine slot冇綁定 = 安靜失敗 | plugins.slots.contextEngine | ||
| LLM摘要把secrets經 FTS 放大 | |||
ignoreSessionPatterns | |||
. 被默認忽略 | /etc/sudoers.d/X.tmpX 唔帶後綴 |
冇匹配嘅坑。換一個篩選條件試試。
其中 #6 和 #7 係呢套架構最容易「靜靜雞蝕底」嘅兩點：context engine唔綁slot，整個L6等於冇裝；摘要器冇做secrets redaction，secrets會經FTS持續放大。呢兩條強烈建議喺搭建L6時就一次到位。
結語#
九層塔唔係為咗複雜而複雜——長期運行嘅Agent面臨嘅問題天然分佈喺九個不同維度（身份/規則/記憶/檢索/召回/會話生存/整理/自我迭代/技能化），缺一層就會喺某個時刻「漏出來」。
好嘅Agent唔係「記得更多」，而係知道咩該記、幾時召回、何時壓縮、點樣清噪、點樣從經驗中進化。
呢個就係Context Engineering嘅本質：唔係管理上下文嘅大細，而係將上下文嘅整個生命週期做成 可觀測、可修復、可進化 嘅工程閉環。
OpenClaw Agent 的長期記憶、主動召回與自我進化架構
一個真正長期運行的 AI Agent，需要的不是更大的上下文窗口，而是一套完整的上下文治理體系。
基於 OpenClaw 多 Agent 環境三個多月的實際運行經驗，以及近一個多月對九層上下文架構的集中升級與整理。九層塔不是一次性設計出來的，而是在解決一個又一個實際問題的過程中逐步演化而成。運維治理本身也是架構成熟的一部分。
引言：大窗口的幻覺#
上下文窗口從 4K 到 128K 再到 1M+，很多人以為"窗口夠大就不需要記憶管理了"。
這是一個危險的幻覺。
窗口變大解決的是"能放多少"，但沒有解決：
放什麼進去？ 什麼時候放？ 過期的怎麼清？ 跨會話怎麼延續？ 多 Agent 怎麼共享又隔離？ 錯誤記憶怎麼修正？ 經驗怎麼沉澱成能力？
這些問題，不是靠"更大的窗口"能解決的。它們需要的是 Context Engineering——對上下文的工程化治理。
本文介紹一套在 OpenClaw 多 Agent 環境中運行三個多月、並在近一個多月集中升級整理出的上下文管理架構。我們稱之為"九層塔"。
從三層到九層：為什麼簡單記憶不夠#
最基礎的記憶架構分三層：
- Layer 0
：身份與規範（靜態，低頻修改） - Layer 1
：知識積累與檢索（持續增長） - Layer 2
：驅動行動（實時運轉）
三層架構能讓 Agent "記住東西"。但當你開始長期運行——跨天、跨周、多會話、多 Agent 協作——你會發現三層不夠：
- 記憶膨脹
：文件越來越多，bootstrap 注入被截斷 - 噪聲累積
：系統日誌、heartbeat、maintenance 消息混入記憶 - 召回失敗
：記了但找不到，或找到的不是最相關的 - 壓縮丟失
：長會話被 compaction 後，關鍵決策丟了 - 重複勞動
：同樣的任務做了十次，每次從零開始
九層塔就是為了解決這些問題而逐步演化出來的。
九層塔不是替代三層架構，而是在三層之上回答了"系統化治理"這個新問題。兩者讀起來可對比，但本文不依賴你讀過前文。
九層塔總覽#
L9 | 能力進化層⚠ 3 經驗 → 可複用技能 |
L8 | 自我迭代層⚠ 5🚨 2 錯誤 / 反饋 → 行為規則 |
L7 | 後台整理層⚠ 3🚨 1 短期上下文 → 長期記憶 |
L6 | 會話生存層⚠ 5🚨 2 Lossless Context Engine / compaction / flush |
L5 | 主動召回層⚠ 3🚨 1 消息前自動注入相關上下文 |
L4 | 語義檢索層⚠ 4🚨 1 embedding / search / fallback |
L3 | 文件記憶層⚠ 3 Markdown 長期事實 |
L2 | 規則治理層⚠ 3 行為邊界 / 工具協議 |
L1 | 身份注入層⚠ 3 身份 / 用戶 / persona |
⚠ 數字 為常見坑數 · 🚨 數字 為高嚴重度坑數
三組，每組三層：
- 基礎層（L1-L3）
：定義 Agent 是誰、該怎麼做、記住了什麼 - 運行時層（L4-L6）
：讓記憶在對話中真正發揮作用 - 進化層（L7-L9）
：讓系統隨時間變得更好
L1身份注入層：Agent 是誰#
解決的問題：Agent 需要一個穩定的身份錨點，否則在長對話或多 Agent 場景中會"人格漂移"。
OpenClaw 中的實現：
SOUL.md— 定義人格、語氣、行為邊界 IDENTITY.md— 基本信息：名字、角色、emoji USER.md— 用戶畫像：偏好、溝通風格、技術棧
關鍵設計：這些文件在每次 session 啓動時自動注入 context window，不依賴 Agent 主動讀取。
常見坑：
身份文件寫得太長，擠佔有效上下文空間 多 Agent 場景中，從 chat history 推斷身份而非從配置文件確認 persona 寫得太強，壓過任務目標
L2規則治理層：Agent 該怎麼行動#
解決的問題：Agent 需要明確的操作邊界——什麼能做、什麼不能做、怎麼做。
OpenClaw 中的實現：
AGENTS.md— 操作手冊：讀寫邊界、協作協議、安全規則 TOOLS.md— 工具使用規範：什麼場景用什麼工具 Bootstrap 配置 — 啓動時的行為指令
關鍵設計：規則分層——身份規則 > 安全規則 > 任務協議 > 工具偏好。優先級明確，衝突時高優先級覆蓋。
常見坑：
規則堆太多，Agent 遵循率下降 規則沒有分層，任務協議和人格描述混在一起 缺少"完成後必須彙報 / 落盤"的閉環要求
L3文件記憶層：長期事實載體#
解決的問題：Agent 需要一個持久化的、可人工修正的知識庫。
OpenClaw 中的實現：
memory/
shared/ ← 所有 Agent 可讀寫：項目、偏好、決策
daily/ ← 每日共享日誌
private/ ← 各 Agent 私有記憶
self-improving/ ← 行為改進記錄關鍵設計：
Markdown 格式：可讀、可 diff、可版本控制、可人工修正 shared / private 分區：多 Agent 協作時既共享又隔離 寫入規則明確：什麼信息寫哪裏，由 AGENTS.md 定義
常見坑：
MEMORY.md 變成垃圾桶，什麼都往裏塞，導致 bootstrap 截斷 shared 區被某個 Agent 意外覆蓋 短期日誌和長期事實混在一起，信噪比下降
L4語義檢索層：從記憶中找上下文#
解決的問題：記憶文件越來越多，不可能全部塞進 prompt。需要按需召回。
OpenClaw 中的實現：
向量索引（embedding）+ 混合搜索（BM25 + semantic） 多源檢索：memory 文件 + session transcript Fallback 機制：primary backend 超時時降級到 builtin index
關鍵設計：
不只是"向量相似度"，還有 temporal decay（時間衰減）和 MMR（多樣性） 索引定期更新（掃描 + embedding） 搜索結果有質量閾值，不是"找到就注入"
工程 Insight：
搜索 timeout 從 15s 提到 60s 只解決了配置層問題。真正的瓶頸在 query expansion + LLM rerank 路徑。搜索系統需要區分：索引是否更新、embedding 是否覆蓋、query path 是否穩定、ranking 是否符合預期。
常見坑：
只看"文件已索引"，忽略 embedding 覆蓋率 Fallback 靜默工作，掩蓋 primary backend 的性能問題 exact query 被日誌文件排在源文件前面（rerank 偏差） 檢索 CLI 的 stdout 不是乾淨 JSON——遇到 collection 不存在 / 參數異常時會先打印 Warning:或Usage:文本再給 JSON。下游 parser 必須容錯地跳過非 JSON 前綴，拋錯會讓多 collection 路徑整體退化到慢 fallbackper-agent 索引會累積大量 orphan 向量（content 已刪但 vector 留着），需要週期性 cleanup；orphan 佔比 > 50% 是 sqlite 體積膨脹的常見原因
L5主動召回層：消息前自動帶上下文#
解決的問題：用戶不應該每次都說"幫我查一下記憶"。系統應該自動判斷需要什麼上下文。
OpenClaw 中的實現：
Active Memory 插件：在用戶消息進入 Agent 前，自動搜索相關記憶 將召回結果壓縮為短摘要注入 prompt 結果標記為 untrusted context：明確告知 Agent 這部分內容來自自動召回而非用戶原話，可質疑、可忽略、可反向校驗，不作為權威事實直接採用
關鍵設計：
主動召回 ≠ 無腦注入。有質量閾值、空結果過濾、相關性判斷 注入內容明確標記來源，Agent 可以選擇忽略 對慢 query 可以選擇更輕的搜索模式
常見坑：
低質量摘要污染當前對話 Active memory 輸出被誤當作 trusted fact 召回 subagent timeout 太短，導致頻繁空結果 - 檢索後端單點失敗傳染整條召回鏈
：active memory 調底層多 collection 檢索時，任一子查詢拋錯會讓整條召回退化到 builtin slow path（>10s / 0 hits）。L4 parser 必須 fail-soft（warn + 返回空數組），主動召回層才能穩定
L6會話生存層：長會話不丟上下文#
L6 是九層塔最複雜、也最容易"安靜吃虧"的一層——本節多數 critical 標註集中在這裏，建議慢讀。
解決的問題：長對話會超過模型上下文窗口。只靠簡單截斷或一次性 compaction，會讓早期約定、任務狀態和關鍵決策從當前對話裏消失。
OpenClaw 中的實現：
Lossless Context Engine（lossless-claw）：作為 plugins.slots.contextEngine的運行時上下文引擎，實時攝入消息，並用 DAG / 摘要 / 分層壓縮來組裝下一輪模型上下文Session Memory hook：實時保存會話 transcript，保留可審計的原始時間線 Compaction Memory Flush：壓縮前自動將重要信息寫入 durable memory，作為最後一道持久化防線 Session transcript 被索引，可供 L4 語義檢索和後續 Dreaming 使用
關鍵設計：
L6 的中心不是單純 flush，而是"運行時上下文生存"：誰負責攝入、壓縮、組裝當前會話 檢索層回答"該找回什麼長期記憶"，context engine 回答"當前這條長會話怎樣繼續保持連貫"——兩者互補，不互相替代 memoryFlush / safeguard compaction 是 fallback safety rail，不是替代 context engine 的主機制 長任務應該外化 plan 到文件，而不是隻存在 context 裏 - 必須顯式綁定
plugins.slots.contextEngine：不綁不會報錯，只會悄悄退化到 legacy 截斷引擎（詳見 坑 #6） - 摘要 LLM 調用前必須 regex redact secrets
：否則 sk-XXX / token 會經 FTS + vector 持續放大注入（詳見 坑 #7） - 短源 (< 200 tokens) 跳過 summarizer
：避免"摘要 = timestamp + 原文"的反向膨脹（詳見 坑 #8）
工程 Insight：
compaction / heartbeat / system prompt 被寫入 transcript 後，可能被後台整理層（L7）錯誤晉升為長期記憶。會話生存層和後台整理層之間需要噪聲過濾機制。
Secrets 在 raw 消息裏容易識別（grep 一抓一個準），但 LLM 摘要把它換個上下文重新表述後，固定的 grep 規則就不一定 catch 得到了。在源頭 redact 比事後 audit 容易得多——這是 L6 必須正視的安全責任。
常見坑：
只依賴大窗口模型，不做顯式 context engine / 持久化治理 把 memoryFlush 當成主機制，而不是 fallback safety rail 長任務沒有外化 plan，壓縮後目標漂移 系統消息混入 transcript，污染下游
L7後台整理層：Dreaming 消化上下文#
解決的問題：短期記憶和 session transcript 會無限增長。需要定期整理、去重、提煉。
OpenClaw 中的實現：
Memory Core Dreaming：每日自動運行 Deep sleep：修復 recall store Light sleep：從 session corpus 中提煉候選記憶 REM：生成摘要和關聯 Post-sweep watchdog：檢查 Dreaming 產物、清理噪聲、統計健康指標
關鍵設計：
Dreaming 不是簡單的"把所有東西都記住"，而是有選擇地晉升 - Promotion threshold
：只有高價值內容才會從短期進入長期 噪聲清理是 Dreaming 的必要後置步驟 - L7 還要監控 L6 引擎本身
：context engine 是個安靜失敗的組件（不寫入即等於沉默）。L7 應當包含一個周度健康監控 cron，監控 lcm.db 增長、DAG leaf / condensed 比例、WAL 狀態。否則一次配置迴歸可能要 40 天才被發現
工程 Insight：
Dreaming 會把 heartbeat、maintenance、compaction 通知等系統噪聲納入候選。因此需要 post-sweep watchdog：每天 Dreaming 完成後自動清理噪聲、統計 promotion ratio、報告異常。典型數據：每天清理 200+ 行噪聲，promotion 率約 4-6%。
健康監控閾值要分級——🔴 才告警（ingest 沉默 / lcm 停擺 / WAL 損壞），🟡 只寫報告不打擾（DAG 淺 / WAL 滯後），🟢 靜默通過。否則告警疲勞會讓真問題被淹沒。
常見坑：
後台任務成功但報告投遞失敗，無人知道結果 噪聲進入 corpus 後被長期污染 Promotion threshold 太寬，低價值內容晉升
L8自我迭代層：從錯誤中改進行為#
解決的問題：Agent 會犯錯。同樣的錯誤不應該犯第二次。
OpenClaw 中的實現：
memory/self-improving/
hot/ ← 當前活躍的行為信號
corrections/ ← 被糾正的錯誤記錄
signals/ ← 觀察到的行為模式
shared-rules/ ← 晉升為穩定規則的條目關鍵設計：
錯誤記錄 → 信號積累 → 規則晉升：不是一次犯錯就改規則，而是重複出現才晉升 shared-rules 跨 Agent 共享：一個 Agent 的教訓，所有 Agent 受益 有 reviewer 和 threshold，防止規則膨脹 - agent identity 用唯一規範
：自我迭代目錄用 agent id（ agent-A/agent-B/ ...），不用 persona name（Persona-A/Persona-B這類用戶自定義顯示名）。所有跨進程協作（cron、patrol、promotion）用同一份 mapping - cron payload 用絕對路徑
：週期性自反思任務裏寫 memory/self-improving/X/hot.md這種相對路徑會被不同 cwd 解析到不同 workspace，造成同一 agent 的內容分裂到多處。統一用/root/.openclaw/workspace/memory/self-improving/<id>/...的絕對路徑 - patrol 用枚舉白名單
： KNOWN_AGENTS+KNOWN_FILES列表化，掃到不在白名單的就報警。這能在第 1 周內發現命名漂移、拼寫錯誤（如corrrections.md多打一個 r）、persona vs agent-id 大小寫分裂
常見坑：
把一次性偏好過早晉升為全局規則 沒有 deprecation 機制，過時規則永遠存在 目錄命名不一致，導致掃描漏項 persona name vs agent id 雙軌命名不統一，cron 跟 patrol 各走各的寫出多份目錄 cron payload 用相對路徑，cwd 一漂全軍覆沒
L9能力進化層：把經驗變成技能#
解決的問題：Agent 反覆做同樣的事情，每次從零開始。經驗應該固化為可複用能力。
OpenClaw 中的實現：
Skill Evolution：從歷史任務中 harvest → synthesize → review → promote 產出的 skill 存入 shared-skills 目錄，所有 Agent 可調用 定期審計：清理過窄、過時、重複的 skill
關鍵設計：
技能不是手動寫的，而是從實際任務中自動提煉 有 review 環節：不是所有 workflow 都值得變成 skill 技能有生命週期：創建 → 使用 → 驗證 → 可能 deprecate
常見坑：
技能過窄，只適用於特定場景 命名差，其他 Agent 找不到 私有上下文被錯誤抽象成 shared skill
九層之間的數據流#
點擊任一節點跳到對應章節 · 虛線表示跨輪閉環
這不是線性流程，而是一個閉環。每一層的輸出都是其他層的輸入。
搭建路徑建議#
不需要一次性搭建九層。建議分階段：
第一階段：基礎可用（L1-L3）
| 第二階段：檢索與召回（L4-L6）
| 第三階段：自動進化（L7-L9）
|
源碼層的小修整：把開源組件做成"工程資產"#
誠實地說，把九層塔落到生產時，光配置是不夠的。前文 L4（parser fail-soft）和 L6（摘要前 redact secrets / 短源跳過 LLM）提到的幾處問題，都需要在開源組件源碼上做小幅適配。
這一節不再重複"改什麼"，重點談"怎樣讓這種修改活下去"——臨時 hotfix 會隨着 npm 升級或上游 git pull 失效；只有做成可觀測、可重啓自愈的工程資產，才能真正成為架構的一部分。最佳實踐是：
// PATCH:<name> 註釋，apply 腳本據此判斷冪等 | |
ExecStartPre 自動跑 apply 腳本——上游覆蓋目標後下次重啓自動重打 | |
.patch | |
讓對開源組件的小修整可被持續維護，而不是"換台機器就丟"。
運維真心話：14 個最容易踩的坑#
九層塔架構清單容易看，但落地時會反覆踩一些坑。以下是從實際運行裏整理出的高頻陷阱，按層歸類：
篩選全部14L1–L31L44L52L64L72L82運維1🚨 高嚴重度2
| context engine slot 沒綁定 = 安靜失敗 | plugins.slots.contextEngine | ||
| LLM 摘要把 secrets 經 FTS 放大 | |||
ignoreSessionPatterns | |||
. 被默認忽略 | /etc/sudoers.d/X.tmpX 不帶後綴 |
沒有匹配的坑。換一個篩選條件試試。
其中 #6 和 #7 是這套架構最容易"安靜吃虧"的兩點：context engine 不綁 slot，整個 L6 等於沒裝；摘要器沒做 secrets redaction，secrets 會經 FTS 持續放大。這兩條強烈建議在搭建 L6 時就一次到位。
結語#
九層塔不是為了複雜而複雜——長期運行的 Agent 面臨的問題天然分佈在九個不同維度（身份 / 規則 / 記憶 / 檢索 / 召回 / 會話生存 / 整理 / 自我迭代 / 技能化），缺一層就會在某個時刻"漏出來"。
好的 Agent 不是"記得更多"，而是知道什麼該記、什麼時候召回、何時壓縮、如何清噪、怎樣從經驗中進化。
這就是 Context Engineering 的本質：不是管理上下文的大小，而是把上下文的整個生命週期做成 可觀測、可修復、可進化 的工程閉環。