北京
作者 | Radek Sienkiewicz
譯者 | 平川
策劃 | Tina
“我是 OpenClaw 代碼庫的維護者，所以本文的深度超過大多數指南。”
每個 OpenClaw 用戶可能都會遇到同樣的難題。在最初的 20 分鐘內，這個代理（Agent）工作得很好，然后就開始偷偷地丟失指令，變得失控。
Summer Yue 是 Meta 超級智能實驗室的對齊總監，她告訴 OpenClaw 代理：“檢查這個收件箱，提供歸檔或刪除建議。在我發話之前不要做任何事。”在測試收件箱上，她的代理已經正常工作了幾個周。但當她將其指向她真正的收件箱時，數千條信息把上下文窗口填滿了。代理壓縮了它的歷史記錄，而那個“在我發話之前不要做任何事”的指令——Summer Yue 在聊天中給出，從未保存到文件中——從摘要中消失了。代理回到了自主模式，開始刪除電子郵件，并忽略了她的停止命令。
她說：“說實話，這是個新手錯誤。事實表明，研究對齊的人也不能免于對齊錯誤。”
事后，代理承認了錯誤并道歉。然后，它在自己的 MEMORY.md 中寫入了一條新規則：展示計劃，獲得明確的批準后再執行。不進行自主批量操作。代理完成了自我修復，只是為時已晚。
因為對話中給出的指令沒有在壓縮中保留下來，Meta 的對齊總監失去了對代理的控制。這樣的事也可能發生在你身上，除非你真的了解代理的記憶機制。
需要明確的是：壓縮是正常行為。真正的可靠性問題在于，如果工作流僅依賴于聊天過程中定義的規則，它能否在長時間會話中持續有效。提示并非強制執行機制。要實現真正的安全性，仍然需要權限控制和工具限制。
全面披露：我是 OpenClaw 代碼庫的維護者，所以本文的深度超過大多數指南。這里的一切都來自公共文檔、GitHub 問題和我自己 2 個多月來每天運行這個系統的經驗。
如果你只做三件事
在深入研究之前，只要在以下三個方面做些調整，你就能領先于 95% 的 OpenClaw 用戶。
將持久有效的規則放在文件中，而不是在聊天中提供。MEMORY.md 和 AGENTS.md 文件不受壓縮操作影響，但在對話中輸入的指令無法保證。
檢查記憶刷新是否啟用以及是否有足夠的緩沖區觸發。OpenClaw 有一個內置的安全網，用于在進行壓縮操作之前保存上下文，但大多數人從未檢查過它是否在運行或給它足夠的空間觸發。
強制檢索記憶。在 AGENTS.md 中添加一條規則：“在行動前搜索記憶”。沒有它，代理就會猜測而不是檢查它的記錄。
本文的剩余部分解釋了為什么這三個方面有效，以及以它們為基礎構建的整個系統。
心理模型
大多數人將“記憶”當成一個東西。但實際上，它是四個獨立的系統，這些系統有不同的失敗方式。知道哪一層出問題就已經完成了 90% 的修復工作。
記憶的四層結構
引導文件是你工作空間里的文件，包括：SOUL.md、AGENTS.md、USER.md、MEMORY.md、TOOLS.md。它們在會話開始時從磁盤加載。它們不受壓縮操作影響，因為它們是從磁盤重新加載的，而不是從對話歷史中。這是一個最持久的層。
會話記錄被保存為磁盤上的 JSONL 文件。當你繼續一個會話時，該記錄被重建為上下文。但是當上下文窗口填滿時，該記錄會被壓縮：一個簡潔的摘要取代了詳細的歷史。模型再也看不到原始消息了，盡管原始的記錄文件還在磁盤上。
LLM 上下文窗口是一個固定大小的容器，里面的一切都在爭奪空間。系統提示、工作空間文件、對話歷史、工具調用、工具結果，都在一個大小 200K 的令牌桶中。當它被填滿時，就會觸發壓縮操作。
檢索索引是一個可搜索的層——由向量和關鍵字組成——和你的記憶文件放在一起。代理可以使用 memory_search 查詢它，從過去的會話中找出相關的上下文。該功能僅在信息寫入文件后才有效。
三種失敗模式
當代理“忘記”某件事時，不外乎是發生了以下三件事之一。
失敗模式 A：“從未被存儲。”指令只存在于對話中，從未被寫入文件。當壓縮被觸發或開啟新會話時，它便消失了。這就是 Summer Yue 遭遇的情況。迄今為止，這是最常見的原因。
失敗模式 B：“壓縮操作改變了上下文內容。”長時間會話會觸發令牌限制。壓縮操作對舊消息進行了歸納處理。這種操作存在信息損耗，會丟失細節、一些微妙差別和特定的約束條件。代理現在根據歸納結果運行，而非你最初提供的指令。
失敗模式 C：“會話修剪了工具結果。”會話會修剪工具的輸出（文件讀取、瀏覽器返回的結果、API 響應）以優化緩存。代理“忘記”了工具之前返回的內容。這是臨時性的，磁盤上的記錄沒有變。但是模型無法看到工具先前響應這個請求的輸出。
快速診斷：
忘記了偏好設置？可能從未寫入 MEMORY.md 文件（失敗模式 A）
忘記了工具返回的內容？可能是修剪（失敗模式 C）
忘記了整個對話？壓縮或會話重置（失敗模式 B）
壓縮與修剪
大多數指南和大部分用戶都混淆了壓縮和修剪。它們是完全不同的系統。
壓縮將整個對話歷史總結為一段緊湊的摘要，改變了模型未來會看到的內容。該操作會在上下文窗口被填滿時觸發。它會影響一切，包括用戶消息、助手消息、工具調用。它是反應性的，當溢出即將發生時觸發，而不是提前。壓縮操作有損，是永久性的。
修剪僅在內存中修剪舊工具結果，僅針對單個請求，不會觸及磁盤上的會話歷史記錄。它只影響 toolResult 消息；用戶和助手消息不會被修改。它不會觸及工具結果中的圖像。修剪操作無損，是臨時性的。
修剪是朋友。它能減少膨脹，而且不會破壞對話上下文。壓縮是危險的，因為它會改變模型看到的內容。
修剪默認是“關閉”的，但更明智的默認設置是為所有 Anthropic 配置文件自動啟用 cache-ttl 模式。如果你使用的是 Claude，它可能已經打開了。你可以在配置中驗證并調整 TTL：
}證明你的代理看到了什么
在更改任何配置之前，在 OpenClaw 會話中運行 /context list。這是診斷為什么記憶“未能保持”的最快方法。
需要檢查的內容：
MEMORY.md 是否加載？如果顯示“缺失”或未列出，就表示該文件不在上下文中。
是否有什么東西被截斷？超過 2 萬個字符的文件會按文件截斷。所有引導文件的總字符數最多為 15 萬個字符。
注入的字符是否和原始字符一樣？如果不是，說明內容被截斷。
如果文件被截斷，則調整配置中的字符數限制。每個文件的字符數限制為 bootstrapMaxChars（默認 20000）。總字符數限制為 bootstrapTotalMaxChars（默認 150000）。這兩個參數是字符數量，而不是令牌數量——150000 個字符大約是 50K 令牌。
如果文件不在上下文中，對代理就沒有影響。在診斷其他任何問題之前，請務必先檢查 /context list。
壓縮實際做了什么
壓縮生命周期
如果你的上下文被消息和工具輸出填滿，接近設定的最大值，接下來會發生什么：
好路徑：維護壓縮。上下文接近限值，預壓縮記憶刷新首先啟動。在壓縮開始前，代理會自動將重要的上下文信息保存到磁盤。你看不到這個過程。然后，壓縮操作會總結以前的對話歷史。代理后續會使用這個摘要、用戶最近發送的消息以及磁盤上的內容。
壞路徑：溢出恢復。上下文變得太大，API 拒絕了請求。現在 OpenClaw 處于損害控制狀態。為了能繼續工作，它會一次性壓縮所有內容。不會刷新記憶，不會預先將重要內容保存到磁盤。上下文丟失最大化。
下面顯示的余量配置旨在使壓縮操作保持在好路徑上。
壓縮破壞了什么
以下內容會在壓縮操作中丟失：
嵌入在對話中的指令（頭號殺手）
在會話中給出的偏好、更正和決策
壓縮操作前共享的所有圖像（按設計，代理后續看不到它們）
工具結果和它們的上下文
原指令的一些細微之處和特異性（摘要存在信息損耗）
以下內容不會在壓縮操作中丟失：
所有工作區文件：SOUL.md、AGENTS.md、USER.md、MEMORY.md、TOOLS.md
每日記憶日志（通過搜索按需獲取，不重新注入）
代理在壓縮操作發生前寫入磁盤的任何內容
壓縮不會涉及你最近的消息，大約最后 20000 個 Token 會保持完整。即使在摘要中，文件路徑和 ID 也會被保留。
如果你的系統出現任何異常，請運行 openclaw --version 命令。2026 年 2 月下旬，我們修復了若干與壓縮操作相關的漏洞，請確保你使用的是 v2026.2.23 或更高版本。
關于 OpenClaw 的記憶，最重要的原則是：如果沒有寫入文件，就不存在。
三層防御
單靠任何一種機制都不夠，你需要三者協同運作。
第一層：壓縮前記憶刷新
這是你可以做出的最有用的配置更改。
OpenClaw 內置了壓縮前記憶刷新功能。在壓縮前，它會觸發一個靜默的“代理輪次”，提醒模型將任何重要的內容寫入磁盤。多數用戶并未意識到該機制的存在，也未驗證它是否已經啟用，且由于默認閾值的設置過嚴，許多時候意外禁用了該功能。
配置如下。不要憑記憶輸入，直接復制下面的代碼塊。重要的是要理解每個值的設置。
}reserveTokensFloor: 40000—— 這是預留空間。你希望為記憶刷新輪次和壓縮摘要保留足夠的空間，避免觸發溢出。刷新在上下文窗口減去預留底限減去軟閾值時觸發。當上下文最大值為 200K，在這個配置下，是在 200000-40000-4000=156000 個令牌時觸發。默認預留是 20K，這通常太少了。一個大型工具的輸出可能會跳過該閾值，使刷新沒有機會運行。在實踐中，40K 是一個起步值。如果你很少使用大型工具，則可以設置的低一些。如果你經常讀取大型文件或網頁快照，則務必要增加這個值。
memoryFlush.enabled: true—— 在最近的版本中應該是默認開啟了，但你還是應該檢查下你的配置。當上下文越過軟閾值時，OpenClaw 會插入一個靜默輪次，說“現在保存你的重要上下文”。代理會將其寫入記憶文件，然后繼續壓縮。用戶永遠不會看到這個輪次。NO_REPLY 令牌抑制了響應。
softThresholdTokens: 4000—— 距離預留底限多遠時觸發刷新。默認是 4000，在大多數情況下已經夠用。
自動刷新是一個安全網，而不是一種保證。代理可能無法保存所有重要的內容，令牌估計可能在一個大型輪次中跳過設置的閾值。這就是其他兩層存在的原因。
第二層：手動記憶管理
雖然有自動刷新機制，但經驗豐富的 OpenClaw 用戶會通過手動保存來補充這一機制。這是一個簡單的習慣，可以捕捉自動刷新遺漏的內容。
在切換任務之前，在給出復雜的新指令之前，或者當你剛剛做出重要決定時，告訴代理：
將此保存到 MEMORY.md或：
將今天的關鍵決定寫入記憶文件/compact 命令值得一學。大多數人認為壓縮是應該避免的事，但根據你的情況進行手動壓縮則不同。
以下是該命令的用法：
告訴代理將當前上下文保存到記憶文件。
發送 /compact 手動觸發壓縮。
然后給出新指令。
新指令會落在壓縮后的新上下文中，它們有最大的生命周期。當下一次壓縮來臨時，它們不會是第一個因為生成摘要而損失掉的內容。
你甚至可以告訴代理壓縮時的優先考慮事項：
/compact 關注決策與開放性問題這可以指示摘要生成器保留最相關的細節。
注意：如果等到“上下文溢出”，則可能會陷入 /compact 也失敗的境地。上下文太滿了，即使是壓縮請求也會溢出。那時，你唯一的選擇是 /new 或 CLI 恢復。不要等待，主動壓縮。
為什么既需要手動又需要自動？自動刷新是在達到令牌閾值時觸發。它是基于時間的，不是基于相關性。手動保存是基于相關性的：你知道什么時候發生了重要的事情。它們一起涵蓋了這兩種情況。
第三層：文件架構
這里是一切匯聚之地。
工作區分為兩類。
引導文件（SOUL.md, AGENTS.md, USER.md, IDENTITY.md, TOOLS.md, MEMORY.md, HEARTBEAT.md, BOOTSTRAP.md）在每個會話開始時加載到上下文中。壓縮對它們沒有影響，因為它們在每個輪次中都從磁盤重新加載。
記憶目錄包含每日日志（memory/YYYY-MM-DD.md）。這些文件并非是通過引導程序注入的。通常，記憶系統會自動讀取今日數據與昨日數據，其余數據均通過 memory_search/memory_get 按需調用。它們不計入引導程序截斷限制。
子代理會話僅注入 AGENTS.md 和 TOOLS.md，其他引導文件會被過濾掉。如果你創建子代理后發現它們未繼承你的個性或偏好設置，原因正在于此。
以下是各文件的作用：
SOUL.md—— 說明代理是誰（溝通語氣、個性、情感風格，道德界限以及代理與你的關系）。最重要的是要記住：SOUL.md 是身份，不是安全措施。LLM 可能會被社會工程學手段誘導泄露信息。要實現真正的安全防護，請在基礎設施層面采取控制措施：工具權限管理、工作區隔離、allowFrom 列表。
AGENTS.md—— 說明代理如何操作（工作流規則和決策框架、工具使用約定以及響應長度指南）。最有用的部分：不要做什么。當代理犯了你不希望重復的錯誤時，可以在這里添加規則。
如果你在團隊的 Discord 或 Slack 頻道中運行 OpenClaw，請將其添加到你的 AGENTS.md 中，否則代理會回復團隊發布的每個表情：
## 群聊規則 - 僅在以下情況下回應：直接被提及、直接被提問，或者你有真正有用的信息 - 不要回應：旁白對話、打趣、他人之間的后勤協調、問候、鏈接分享 - 如果有疑問 -> 僅回應：NO_REPLY - NO_REPLY必須是你的整個消息，沒有其他內容
USER.md—— 你是誰（你的項目、客戶、當前優先事項、溝通偏好、關鍵人物和關系、技術環境細節）。
MEMORY.md—— 在每次會話中都應保持不變的內容（你做出的決策及依據、代理學到的偏好、從過去錯誤中學到的規則）。保持簡短，不超過 100 行。這不是日記，而是速查表。
每日日志（memory/YYYY-MM-DD.md） —— 你每天工作的上下文（今天發生了什么、對話中做出的決策、活躍任務及其狀態）。預壓縮刷新輸出會自動寫到這里。
現在，使所有這些內容生效——記憶協議。將以下內容添加到你的 AGENTS.md 中：
## 記憶協議 - 在回答有關過去工作的問題之前：先搜索記憶 - 在開始任何新任務之前：檢查今天的記憶以獲取活躍上下文 - 當你學到重要的東西時：立即將其寫入相應的文件 - 當你糾正一個錯誤時：將更正作為規則添加到MEMORY.md - 當會話結束或上下文很大時：總結并寫入memory/YYYY-MM-DD.md
沒有這個規則，代理會根據上下文回答。有了它，代理會先查找信息。
記憶衛生。幾個月后，每日日志不斷累積，MEMORY.md 文件膨脹。務請謹記初始化截斷限制。處理方法如下：
每日：追加到每日日志，這是自動的。
每周：將每日日志中的持久規則和決策記錄到 MEMORY.md 文件中。你可以為此設置每周 cron 作業。
保持 MEMORY.md 簡短。任何不需要在每次會話中都出現的內容都可以放在每日日志中。代理需要時會通過搜索找到它。
你可能想要備份代理的記憶。在工作區目錄中運行 git init，設置通過每日 cron 或心跳自動提交。只是確保~/.openclaw/credentials/ 和 openclaw.json 不會進入存儲庫，其中包含認證令牌和 API 密鑰。
檢 索
如果代理無法在記憶文件中找到需要的信息，那么記憶文件就毫無用處。
兩個記憶訪問工具
OpenClaw 提供了兩個記憶訪問工具：
memory_search—— 在記憶文件中搜索，包括 MEMORY.md、每日日志、記憶目錄中的所有內容。默認情況下，它使用關鍵詞和基于語義的匹配，所以即使你寫的是“我們選擇了 29 美元的層級”，它也能找到“定價決策”。
memory_get—— 按文件和行范圍進行定向讀取。如果文件不存在，則優雅地返回空文本。當你確切地知道哪個文件包含什么信息時使用這個工具。
將這個檢索前置規則添加到你的 AGENTS.md 文件中：
## 檢索協議 在進行重要的工作之前： 1. memory_search項目/主題/用戶偏好 2. 如果需要，用memory_get獲取引用的文件塊 3. 然后繼續執行任務
沒有這個，代理會猜測。有了它，代理會先檢查它的記錄。
A 路徑：內置搜索
默認設置，最簡單，我們從這里開始。
內置系統自動索引 MEMORY.md 文件和記憶目錄中的所有內容。它監視文件更改并重建索引。不需要額外安裝。
}“混合搜索”意味著兩種匹配策略協同工作。關鍵詞搜索可以找到確切的詞：搜索“定價”，它會找到包含“定價”的文件。嵌入式搜索會將文本轉換為數字，捕捉句子的含義，而不僅僅是它們使用的詞，所以“定價決策”和“我們選擇了 29 美元的層級”在意義上是接近的。
A 路徑會在你的計算機上運行一個小型嵌入式模型，免費使用，除了首次下載外無需其他任何設置。該方案為你提供了基于關鍵詞和語義的混合搜索。對于大多數用戶來說，這已經足夠了。
A+ 路徑：extraPaths
在切換到其他后端之前，你需要知道的是，內置搜索支持索引工作區之外的其他 Markdown 文件。將 extraPaths 添加到你的配置中，并指向你的項目文件夾、記錄目錄等。同樣的混合搜索，無需額外安裝。
}當你需要搜索大型庫（數千個文件）、過去的會話記錄或多個獨立的集合時，可以升級到路徑 B。
B 路徑：QMD
QMD（查詢 Markdown 文檔）是一個實驗性的記憶后端，可以取代內置的索引器。當你需要搜索工作區之外的內容時，例如你的 Obsidian 庫、項目文檔、會議記錄、過去的會話記錄。
路徑 A 是代理檢查自己的日記。路徑 B 是代理搜索你所有的文件。免費使用，本地運行。
}在默認情況下，OpenClaw 的 memory_search 使用 QMD 的 BM25 關鍵詞模式。速度快，亞秒級響應，無需 ML 模型，沒有冷啟動風險。這里所做的讓步是：如果你將“API 定價決策”存儲為“我們選擇了 29 美元 / 月的層級”，它就找不到“API 定價決策”。如果你不希望那樣，就需要啟用語義搜索模式。該模式會加載 ML 模型，首次使用時需要的時間比較長。開始時使用關鍵詞模式，如果需要，再升級。
QMD 默認為 DM-only 范圍。如果你是在群組頻道中運行 OpenClaw，并且 memory_search 看上去被禁用了，請檢查是否需要更新你配置的 QMD 范圍。
QMD 返回相關的片段，而不是整個文件。代理不會為了找到一句話而將 50 頁的文檔全部加載到上下文中，這有助于避免觸發壓縮。
成本和緩存
你發送的每條消息都包含完整的系統提示和對話歷史。提示緩存意味著你為那些重復的 Token 支付的費用減少了大約 90%，但壓縮會使緩存失效。壓縮后的下一個請求需要支付全額費用以重新緩存所有內容。
每次不必要的壓縮都是一個可靠性問題和一個成本問題。
有兩件事會破壞緩存：
壓縮會重寫對話歷史，使一切失效。
每個回合都變化的易失性系統提示輸入會破壞緩存。
這也是為什么保持工作區文件穩定和 MEMORY.md 小巧而不是不斷重寫它的另一個原因。
在 cache-ttl 模式下進行會話修剪，可在強制執行壓縮前緩解工具臃腫。配置成本不高，卻能顯著提升緩存命中率。
故障排除
本節是常見問題及其解決方法。每個問題都包括一個你可以直接粘貼到 OpenClaw 會話中的提示。
“我的代理不記得我的偏好”
偏好是否寫入了 MEMORY.md 文件？如果它只存在于對話中，就不是持久的。運行 /context list 看看 MEMORY.md 是否真的加載了？它是否被截斷了？AGENTS.md 是否設置了記憶協議？在群組上下文中，MEMORY.md 按設計是不加載的，它只在主會話中加載。
運行 /context list 并檢查 MEMORY.md 是否已經加載。如果它缺失或被截斷，請告訴我。然后檢查我的 [偏好描述] 是否已經寫入 MEMORY.md 或任何記憶文件中。如果沒有，請現在將其添加到 MEMORY.md 中。
“memory_search 無返回或似乎被禁用”
運行 /context list 并檢查你的記憶文件實際是否存在。如果文件不存在，則意味著沒有東西可供搜索。如果文件存在，則問題通常出在嵌入式模型上——本地模型首次使用時需要下載。如果下載失敗，則搜索功能將無法正常工作。
運行 /context list 并告訴我：是否有任何記憶文件被加載？然后嘗試用 memory_search 搜索'test'并告訴我結果。如果搜索失敗，請檢查是否存在本地嵌入式模型，并報告任何錯誤。
“它不記得瀏覽器或工具說了什么”
那是會話修剪，不是壓縮。工具結果在緩存 TTL 后被清除。磁盤上的記錄沒問題；模型只是無法在當前請求中看到舊工具輸出。將重要的工具輸出寫入記憶文件，或重新運行工具。
本會話中早期的工具結果消失了。在重新運行任何東西之前，將重要工具輸出的摘要寫入今天的每日記憶日志，這樣我們就不會再次丟失它們。然后重新運行 [工具 / 命令] 獲取新的結果。
“壓縮發生得太晚，我收到了溢出錯誤”
不要等到溢出。在事情變得嚴重之前主動使用 /compact 進行壓縮。提高 reserveTokensFloor 以便更早地觸發壓縮。如果卡在溢出死鎖中，甚至無法運行 /compact，請使用 /new 重置，或通過 openclaw sessions CLI 恢復。
現在就將本會話的所有重要內容保存到今天的記憶日志中，包括決策、上下文、活動任務。然后我將運行 /compact 以清理空間。
“預壓縮記憶刷新沒有運行”
如果一個輪次導致 Token 數據大幅越過軟閾值，就會繞過刷新。檢查你的配置，看看該功能是否啟用。提高 reserveTokensFloor 的值，增加緩沖。請將其視為盡力而為的機制，并手動建立保存點作為備份。
在我們繼續之前，將本會話中所有重要的上下文保存到今天的記憶日志中：所做的決策、活動任務、上下文丟失時你需要恢復的任何內容。現在就做，作為手動保存點。
“我的代理在長時間會話后忘記了它的工具”
已知問題，尤其是長時間運行的 Discord 會話。壓縮操作生成的摘要可能會丟失工具上下文。修復方法：使用 /new 重置會話。如果有適當的記憶文件，代理就可以從中斷處繼續進行。模型選擇也很重要；更智能的模型能更好地處理壓縮摘要。
檢查你的記憶文件，看看我們正在做什么。在記憶文件中搜索 [主題 / 任務]。從對話中斷的地方繼續。
“我的代理一夜之間忘記了一切”
會話在每日重置時獲得新的會話 ID（默認為當地時間凌晨 4:00）。這本質上是一個新的會話。只有引導文件和可搜索的記憶會延續。這種行為符合預期，不是錯誤。這就是為什么寫入記憶文件很重要：每日重置由類似壓縮的事件來保證。
搜索你的記憶文件，了解昨天的活動。我們當時在處理什么？做出了哪些決策？哪些事項尚未解決？請進行總結然后繼續。
完整配置
兩個配置塊。請選擇你的路徑。
A 路徑：內置記憶搜索
無需額外安裝。壓縮配置的保留底限為 40000，啟用記憶刷新，使用 embeddinggemma 模型的本地混合搜索，以及 cache-ttl 修剪。復制并粘貼此內容。
}B 路徑：QMD 后端
相同的壓縮和修剪配置，但將內置搜索替換為 QMD。指向你的 Obsidian 庫，啟用會話索引，然后開始。
}從路徑 A 開始，當需要搜索 Obsidian 庫或過去的會話時，升級到路徑 B。
深度防御概述
斜杠命令參考
OpenClaw 記憶文檔 (https://docs.openclaw.ai/concepts/memory)
壓縮文檔 (https://docs.openclaw.ai/concepts/compaction)
會話修剪文檔 (https://docs.openclaw.ai/concepts/session-pruning)
提示緩存指南 (https://docs.openclaw.ai/reference/prompt-caching)
上下文文檔 (https://docs.openclaw.ai/concepts/context)
Tobi Lutke 的 QMD(https://github.com/tobi/qmd)
https://velvetshark.com/openclaw-memory-masterclass
聲明：本文最初發布于 VelvetShark，為 InfoQ 翻譯，未經許可禁止轉載。
會議推薦
OpenClaw 出圈，“養蝦”潮狂熱，開年 Agentic AI 這把火燒得不可謂不旺。在這一熱潮下，自托管 Agent 形態迅速普及：多入口對話、持久記憶、Skills 工具鏈帶來強大生產力。但這背后也暴露了工程化落地的真實難題——權限邊界與隔離運行、Skills 供應鏈安全、可觀測與可追溯、記憶分層與跨場景污染、以及如何把 Agent 納入團隊研發 / 運維流程并形成穩定收益。
針對這一系列挑戰，在 4 月 16-18 日即將舉辦的 QCon 北京站上，我們特別策劃了「OpenClaw 生態實踐」專題，將聚焦一線實踐與踩坑復盤，分享企業如何構建私有 Skills、制定安全護欄、搭建審計與回放機制、建立質量 / 效率指標體系，最終把自托管 Agent 從可用的 Demo 升級為可靠的生產系統。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
