OpenClaw 解決了

• 功能：可插拔情境系統，適用於 OpenClaw 的 LCM — 討論區 #22251，@jalehman，2026年2月20日
• OpenClaw 2026.3.7 版本發行說明 — GitHub
• [Chrys Bader @chrysb](https 想像一下：你的 OpenClaw 代理程式已經為了一個研究專案運作了三個小時。它不斷地瀏覽、做筆記、交叉比對資料來源，逐步建構出某個複雜事物的輪廓。然後，它達到了上下文限制。

壓縮機制觸 它傳來的下一則訊息，讀起來就像剛失憶醒來一樣。它兩小時前找到的那個特定檔案路徑——不見了。你們共同決定要採取的作法——被濃縮成一句含糊不清的話。整串將你們引導至有用 這不是一個程式錯誤。這是刻意設計的——而且在 2026 年 3 月 8 日之前，這是任何代理程式唯一的選項。

OpenClaw 2026.3.7 改變了這一點。

---

脈絡壓縮的問題（跟你想的不一樣）

一般的說法是，壓縮是個記憶體管理問題。Token 的限制是有限的。當對話變得太長，就必須有所取捨。代理程式會總結最舊的部分，然後繼續。

這種說法讓它聽起來像 並非如此。原因如下。

當 OpenClaw 的預設壓縮程序觸發時，它會進行一次性摘要：最舊的訊息會被收攏成一個單一的摘要區塊，該區塊會被寫回對話紀錄中，而原始的 @jalehman——打造 lossless-claw 的開發者——在 討論 #22251 中精準地 最後那句話很重要。這並非 OpenClaw 特有的缺陷。ChatGPT 會這樣做。Claude 也會這樣做。每個代理人框架都會這樣做。整個領域一直以來都假設「有損壓縮」是唯一的選擇。

實際造成的影響相當重大：

對於在一小時內結束的單次對話來說，壓縮充其量只是個小麻煩。代理人會保留大部分重要的內容，你也能繼續下去。 對於長期運行的代理人而言——也就是那些人們實際部署來 24/7 全天候運行，用以處理橫跨數天或數週的專案，並在數十個任務中協調子代理人的代理人——「壓縮」便是一道 資深的 OpenClaw 使用者會發展出一些應變方法，這是有原因的：在關鍵時刻手動執行 /compact、調整 SOUL.md 的結構以強制關鍵事實能在壓縮後保留下來、將專案拆分成附有交接筆記的獨立 你在 Twitter 上會看到的標題是「lossless-claw — 一個賦予你 agent 完美記憶的 OpenClaw 外掛。」這句話是真的，但這並不是真正的新聞。

真正的新聞是，在 lossless-claw 得以存在之前，OpenClaw 核心必須發生的改變。 在 2026.3.7 版本之前，OpenClaw 的上下文管理是硬性編碼於核心之中。若不分支出整個程式碼庫，便無法將其替換、擴充或實驗替代方案。其壓縮邏輯——何時 @jalehman 提交的 PR — #22201 — 不僅僅是新增了 lossless-claw 的支援。它**將上下文管理抽離成一個可插 這在實務上的意義是：OpenClaw 現在為上下文管理定義了一個介面。任何實作該介面的外掛程式，都可以完全取代內建的引擎。預設行為維持不變——如果你什麼都沒設定，LegacyContextEngine 依然是備用 bootstrap(ctx): Promise // 初始化資料庫、索引 ingest(msg): Promise // 在每則訊息送達時將其封存 assemble(opts): Promise<AgentMessage[]> // 在每一輪建構模型脈絡 compact(ctx): Promise // 處理壓縮觸 prepareSubagentSpawn(): … // 將脈絡傳遞給衍生的子代理 onSubagentEnded(): … // 子代理完成後進行協調 }

這是一個完整的生命週期。每個涉及脈絡的時刻——擷取、組裝、壓縮、子代理交接——現在都是一個可供外掛程式攔截和取代的掛鉤。

若要使用替代的脈絡引擎，設定只需一行：

```json
{
  "plugins": {
    "slots": {
"contextEngine": "lossless-claw"
    }
  }
}

若未新增此行，則不會有任何改變，其行為與先前版本完全相同。此遷移路徑完全採選擇性加入。

---

lossless-claw 的運

lossless-claw 是這個介面的第一個實作。它基於由 Ehrlich 與 Blackman 所撰寫的 LCM (Lossless Context Management) 論文——這兩位研究人員後來也直接為此外掛背書。該論文的共同作者之一 @belisarius222 在 GitHub 的討論中寫道：

「Josh 對它做了非常多的改良，我認為它真的應該被稱為 LCM 2.0。」

其核心前提是將整個問題重新框架。 標準壓縮會等到溢出發生後才反應。等到它觸發時，你早已無法妥善保存上下文——你所做的，只是對數小時以來累積成堆的訊息進行緊急處理。其結果無可避免地會是有損的。 lossless-claw 不會等待。它在背景中持續且非同步地運作，在每次交流後、於任何溢位危機發生前，做出漸進式的摘要決策。它所建立的摘要並非平面文字。它們是圖形中的結構化 進入 lossless-claw 會話的每則訊息，都會立即持久化儲存到一個 SQLite 資料庫中。不是摘要——而是完整儲存。這是唯一的事實來源。它永遠不會被刪除。

隨著對話的增長，lossless-claw 會為 第二層摘要 (涵蓋多個第一層摘要) ↓ 第三層摘要 (捕捉主要專案階段)

摘要在樹狀結構中越往上層，就變得越抽象 — 靠近底層的摘要詳細且按時間順序，靠近頂層的則廣泛且具主題性。每個摘要都帶有元資料：其來源節點的 ID、時間戳記、深度、後代數量。

當需要為新一輪對話組裝上下文時，引擎的運作方式如下：

[受保護的新近結尾：最近 N 則原始訊息] + [摘要節點，從最舊到最新，填滿剩餘的 token 預算] + [代理程式透過 lcm_expand 明確請求的任何細節]

模型會看到完整的近期訊息，而較舊的資料則會以摘要
<parents>
    <summary_ref id="sum_def456" />
  </parents>
  <content>
    在此工作階段中，代理人研究了 API 等級的三種定價策略。
    結論是，基於 [原因]，以用量計價的方式更為可取。
    寫入的關鍵檔案：/workspace/pricing-analysis.md。
    已同意的下一步：與財務團隊的資料進行驗證。
  </content>
</summary>

代理人知道這是一份摘要。它知道其涵蓋的時間範圍、代表了多少則訊息，以及在需要時該去哪裡尋找更多資訊。

三個檢索工具

當光有摘要還不夠時——當代理程式需要確切的檔案路徑、決策的精確措辭、或特定研究會話的實際資料時——它有三個工具可以回溯歷史：

| 工具 | 功能說明 | lcm_expand 是關鍵所在。它並非將整個擴展內容載入主脈絡中——這會違背其初衷——而是使用一個子代理來讀取擴展後的內容，並僅回傳所要求的特定細節。如此 這就是 @jalehman 在他的提案中用書本比喻的意思：「這就像是能夠翻回書中的任何一頁。」 當你放下書本時，它並不會被銷毀。它就在書架上。你可以查閱任何內容。

---

「想像一下，再也不需要執行 /compact 或 /new 指令。……其結果令我感到無比驚艷：一場感覺上從未遺失任何資訊的對話（因為在某種程度上，它的確沒有），總是在 3 萬到 若要更量化地來看：社群開發者 [@chrysb] 在發布當天於 Twitter 上回報了早期的基準測試結果。他們使用 OOLONG 基準測試——一個專為評估長上下文保留能力與任務連續性而設計的測試套件——並以 Opus 4.6 作為兩者的模型：

系統	OOLONG 分數	備註
lossless-claw + OpenClaw	74.8	差距隨上下文長度增加而擴大
Claude Code (預設)	70.3	標準滑動視窗
OpenClaw 預設	~68 (估計值)	單次壓縮

這些是社群回報的數據，而非官方的基準測試，且 LCM 論文的共同作者 @belisarius222 指出，@jalehman 在原始論文實作之上做了一項具體改進：為摘要設定輸入長度上限。在原始的 LCM 中，摘要過長的內容本身就可能導致上下文溢出、產生不可預測的行為，並引入邊緣案例。這種設定上限的方法讓每個摘要步驟都變得可預測，這也使得系統在處理 lcm_expand 子代理程式的呼叫時更加可靠。

---

安裝與設定 lossless-claw

先決條件：OpenClaw 2026.3.7 或更新版本。「上下文引擎」外掛插槽在先前的版本中並不存在。

請注意： 2026.3.7 的初始版本有一個已知的 P1 註冊表錯誤（問題 #40096），此錯誤會 openclaw —version

應顯示：openclaw 2026.3.7 或更高版本 (包含登錄檔修復)

安裝外掛程式

openclaw plugins install lossless-claw

重新啟動閘道

openclaw restart contextEngine: “lossless-claw” } } }

### 誰應該啟用

lossless-claw 並非適用於所有 OpenClaw 設定的最佳選擇。它會增加額外負擔——包括儲存空間（隨著您的
- 您正在執行子代理系統，而脈絡交接至關重要
- 您曾因內容壓縮而遺失重要資訊，並被迫重新開始

**在以下情況，請繼續使用預設引擎：**
- 您主要使用 OpenClaw 執行可在一小時
lossless-claw 使用 LLM 來產生摘要。這會耗用 token。對大多數長時間運行的工作流程來說，避免重設 session 所省下的成本，遠大於生成摘要的額外開銷 —— 但若您在意成本，有個聰明的方式可以設定：

```json5
{
  agents: {
    defaults: {
      model: "anthropic/claude-opus-4-6",
    }
  },
  plugins: {
    slots: {
      contextEngine: "lossless-claw"
    }
  }
}

lossless-claw 的文件建議使用一個快速、便宜的模型來進行背景摘要工作——例如 anthropic/claude-haiku-4-5 或 MiniMax-M2.5-highspeed——同時保持您主要的推理模型不變。請查看 lossless-claw README 以找到確切的設定鍵，將摘要任務指向不同的模型。摘要任務相當單純，因此較小的模型便能妥善處理，且成本差異相當顯著。 @jalehman 的實作也旨在透過自適應的摘要節奏，將活躍情境維持在 3 萬至 10 萬詞元的範圍內 —— 如此一來，即使對話歷史無限增長，詞元用量也能保持可 在 3.7 版之前，每一項試圖改善 OpenClaw 情境管理的嘗試都遇到了同樣的瓶頸：它是寫死的。你可以編寫技能來嘗試從外部管理狀態。你可以調整你的 SOUL.md 結構以保存關鍵事實。你可以在關鍵時刻手動執行 /compact。但這些方法都無法觸及核心機制。

現在，這個介面已經開放了。

以下是社群中已經在討論的一些方向： 向量搜尋作為儲存後端。 SQLite 全文搜尋適用於關鍵字查詢。向量嵌入後端則可支援語意搜尋——即使沒有完全相同的詞彙，也能找到概念上相關的歷史內容。@belisarius222 最初的 Volt 實作就採用了這種方法。 **整合 RAG 的情境引擎。**一種情境引擎，它不僅利用對話歷史紀錄，還會取用外部知識庫——您的 Notion 工作區、您的程式碼庫、您的文件庫。這些資訊會根據當前任務的需求，在每一輪對話中動態 **Obsidian / Notion 作為記憶後端。**不再使用本機的 SQLite 資料庫，而是將所有內容持久化到一個結構化的外部工作空間，您可以在那裡自行瀏覽和編輯。您的代理人記憶便可在代理人外部進行審核與搜尋。

這些並非空想。它們是 lossless-claw 已實作介面的自然延伸。 從基礎架構的角度來看，這就是成熟平台演進的方式。OpenClaw 推出了瀏覽器自動化，接著開放瀏覽器工具的客製化功能。它推出了技能，接著建立了 ClawHub 來發布這些技能。它推出了脈絡管理，接著開放了脈絡引擎。這個模式始終如一：先把它建立起來，再讓它變得可擴充。 情境管理是代理人系統中最根本的一層。它決定了代理人知道什麼、如何進行跨時間推理，以及在長時間運行的任務中實際能完成什麼。將其開放並不是一個小功能。這是一個關於由誰來控制代理人記憶的架構性決策。

---

3.7 版還有哪些其他變更

lossless-claw 獲得了最多的關注，但 3.7 版本中還有另外兩個值得注意的功能： **Telegram 的依主題代理分派功能。**論壇群組現在可以將不同的主題分派給不同的代理。一個 Telegram 群組，多個專業代理——每個代理都以獨立的對話階段處理不同的主題討論串。數月以來，這一直是多代理團隊設定

總結

OpenClaw 從第一天起就有一個隱形的天花板：您的代理程式執行得越久，它遺忘的就越多。每個嚴肅的使用案例最終都會碰到它。幾個月來，社群一直透過 SOUL.md 技巧、手動 lossless-claw 是第一個解答 — 一個基於 DAG 的摘要系統，它會儲存所有內容、進行增量式摘要，並讓代理程式能夠依需求擷取確切的歷史細節。初期的社群基準測試數據顯示，在每個測試的上下文長度下，它的表現都優於 Claude Code 的預設引擎，且隨著對話變長，差距也越來越大。

如果您曾遇過代理程式忘記了它不該忘記的事情，那麼這個版本就是為您而生。

openclaw update

openclaw plugins install lossless-claw

這就是整個遷移過程。

---

*您的代理程式需要多久才會觸發壓縮？當壓縮發生時，您會損失什麼？請在留言區分享——我們正在追蹤不同工作流程類型如何經歷脈絡衰
*來源：[Martian-Engineering/lossless-claw](https://github.com/Martian-Engineering/lossless-claw) · [OpenClaw 討論區 #22251](https://github.com/openclaw/openclaw/discussions/22251) · [OpenClaw 2026.3.7 版本發行說明](https://github.com/openclaw/openclaw/releases/tag/v2026.3.7) · [Chrys Bader @chrysb](https://x.com/chrysb/status/2030526852146549140) · [LCM 論文，Ehrlich & Blackman](https://papers.voltropy.com/LCM)*