LCMLossless Context Management原理分析本文用于解释lossless-claw中 LCM 的核心原理以及它与 OpenClaw Context Engine、模型 Context Window、Compaction、Memory、Tools 和最终 LLM Request 之间的关系。重点回答几个容易混淆的问题LCM 到底解决什么问题128K / 1M Context Window是什么assemble()为什么每次会自动触发assemble()自己是否需要 LLMmessages[]到底是不是“完整上下文”摘要是谁生成的准确性怎么保证没有 LCM 时 OpenClaw 是否仍然会做 CompactionLCM 和 Memory 系统到底是什么关系1M Context 的模型还有没有必要使用 LCM1. LCM 是什么LCM 全称Lossless Context Managementlossless-claw是插件 / 项目名称而 LCM 是它实现的核心上下文管理机制。LCM 可以理解成一个面向长时间 Agent Conversation 的分层上下文管理系统。它主要解决一个非常现实的问题Conversation 可以不断增长 但 LLM 每一次推理能够读取的 Context Window 有上限例如模型 Context Window 128K tokens或者某些长上下文模型模型 Context Window 1M tokens但是一个持续几个月的 Conversation 完全可能累计500K 2M 10M 甚至更多 tokens因此不能简单地把整个 Conversation 每轮全部重新发送给模型。LCM 的基本解决思路是完整 Conversation History │ │ 持久化 ▼ ┌──────────────────────────┐ │ SQLite / Raw Messages │ │ Summary DAG │ └────────────┬─────────────┘ │ │ 每次模型调用前 ▼ assemble() │ ▼ 有限的 Working Context │ ▼ LLM因此LCM 并没有突破模型本身的 Context Window而是在有限 Context Window 上管理一个远大于模型窗口的长期 Conversation。2. Context Window 到底是什么假设某个模型写着Context Window 128K这里的128K指的通常是约 128,000 tokens而不是128 KB也不是128,000 个汉字Token 是模型内部处理文本的基本单位。2.1 Context Window 是模型限制吗是。Context Window 首先受到模型架构 / 模型服务的限制。例如Model A 128K Model B 200K Model C 1M但是实际可用 Context 往往还会同时受到模型上限 API / Provider 上限 OpenClaw Runtime 限制 输出 Token 预留 插件 / Context Engine 自己的 Budget影响。可以粗略理解为实际可用输入空间 模型最大 Context - System Prompt - Tool Schemas - Memory - Workspace / Skills - 输出空间 - 其他运行时开销3. 1M Context 是否代表每轮可以直接发送 1M Conversation理论上模型能够接受很大的输入不代表工程上应该每轮把窗口全部塞满。假设Model Context 1M实际一轮可能是System Prompt 30K Tools / Schemas 40K Memory 10K Workspace / Skills 20K Conversation Messages 500K Current Input 5K Output Headroom 100K -------------------------------- Total 705K所以1M 是整次 Model Request 的总上下文预算而不是 LCM 独享的 1M。即使模型支持 1M每轮都发送 900K 历史仍可能造成更高输入 Token 成本更长 Prefill 延迟更大的 KV Cache 压力更多无关信息干扰长上下文中的信息检索质量下降大量历史内容每轮重复发送因此长 Context Model 并不会让 LCM 失去价值。更合理的目标是Model Physical Window 1M 正常 Working Set 100K ~ 300K 确实需要时 500K ~ 800K 而不是每轮固定发送接近 1M4. OpenClaw 最终发送给 LLM 的东西是什么这是理解 LCM 最重要的一点之一。最终发送给 LLM 的完整 Context并不只是 LCM 的messages[]。可以粗略表示成Final LLM Context │ ├── System Prompt │ ├── OpenClaw 基础规则 │ ├── AGENTS / SOUL / USER │ ├── Workspace 信息 │ ├── Memory System Prompt │ └── Context Engine Addition │ ├── Tool Schemas │ ├── exec │ ├── read │ ├── memory_search │ ├── lcm_grep │ ├── lcm_expand │ └── ... │ └── messages[] ├── 历史 Summary ├── 最近 Raw User Message ├── 最近 Raw Assistant Message ├── Tool Call ├── Tool Result └── 当前 User Message因此messages[] ! Final LLM Context5.messages[]到底是什么最准确的说法是messages[]是当前这一轮Context Engine 决定让模型看到的Conversation Message Context。如果完整历史已经有2,000,000 tokensLCM 不会返回2,000,000 tokens而可能根据 Budget 生成messages[] ≈ 150K tokens其中可能包含[高层 Summary] [中层 Summary] [较新的 Summary] [最近 Raw User] [最近 Raw Assistant] [最近 Tool Result] [当前 User]因此可以理解成完整历史 ↓ LCM Context Representation ↓ messages[]所以messages[]是“当前 Conversation 的完整工作表示”但不是原始 Conversation 的完整逐字记录。6.messages[]也不等于“全部都是摘要”这是另一个很容易产生的误解。典型 LCM Context 更像messages[] │ ├── Summary ← 很久以前 ├── Summary ← 较早历史 ├── Summary │ ├── Raw User ← Fresh Tail ├── Raw Assistant ├── Raw Tool Call ├── Raw Tool Result ├── Raw User └── Current User也就是说messages[] 压缩历史 最近未压缩历史 当前消息因此更合适的名字是Assembled Conversation Context而不是简单的Compressed Messages7.assemble()是什么assemble从英文直译就是组装 装配在 LCM / Context Engine 中它干的正是这个事情根据当前 Conversation、Summary DAG、Fresh Tail、Token Budget 等信息组装这一轮应该交给模型的messages[]。它不是重新理解全部历史也不是每轮重新生成摘要更不是调用另一个 LLM 判断该放哪些消息正常情况下它更接近读取 DB 读取 Summary DAG 选择当前 Summary Frontier 选择 Fresh Tail Token Counting 预算判断 排序 裁剪 生成 messages[]8.assemble()为什么会每轮自动触发它不是 LCM 自己监听用户消息后主动调用。真正触发它的是OpenClaw Agent RuntimeContext Engine 是 OpenClaw 的一个生命周期组件。概念上可以理解成用户输入 ↓ OpenClaw Runtime ↓ 准备运行模型 ↓ onBeforeModelRun ↓ contextEngine.assemble() ↓ 获得 messages[] ↓ 构造 Final LLM Request ↓ 调用模型可以把它近似理解成一个程序 HookasyncfunctionbeforeModelRun(){constassembledawaitcontextEngine.assemble(...);returncallModel({systemPrompt,tools,messages:assembled.messages});}所以assemble()的“自动触发”本质是 OpenClaw Runtime 的程序生命周期事件。9.assemble()不一定只在一次用户消息中执行一次要特别注意User Turn ! Model Run一个 User Turn 可能触发多次 Model Run。例如User: 帮我检查项目为什么编译失败执行过程可能是User │ ▼ assemble #1 │ ▼ LLM #1 │ ▼ exec(...) │ ▼ Tool Result │ ▼ assemble #2 │ ▼ LLM #2 │ ▼ read(package.json) │ ▼ Tool Result │ ▼ assemble #3 │ ▼ LLM #3 │ ▼ Final Answer因此更准确地说assemble()是在每次 Model Run 前调用而不是简单地“每个用户消息调用一次”。10.assemble()自己需要 LLM 吗正常路径下不需要因为它并不负责“生成摘要”。它只是读取已经存在的 Context 数据并装配。例如当前 Budget 200K 已有 Summary Frontier 50K Fresh Tail 90K Current Turn 5K Total 145K那么145K 200Kassemble()可以直接return messages[]整个过程可以完全是确定性的程序逻辑。11. 那摘要是谁生成的摘要属于另一个阶段compact()也就是CompactionCompaction 的职责是将较老、较大的 Raw Conversation 内容压缩成更短的 Summary。概念链路Raw Messages │ ▼ compact() │ ▼ Summary LLM │ ▼ 生成 Summary │ ▼ 保存到 LCM DB / Summary DAG之后下一次assemble()只需要直接读取已经存在的 Summary。因此compact() 生产压缩数据 assemble() 消费压缩数据12. 为什么不让assemble()每轮都调用 LLM 重新摘要如果这样设计每轮 Model Run 前 完整历史 ↓ Summary LLM ↓ 新的 Summary ↓ Main LLM那么 Agent 每一次 Tool Call 后再次运行模型都可能先额外调用一次 Summary LLM。如果一个任务产生10 次 Model Run就可能变成10 次 Summary LLM 10 次 Main LLM这会导致非常明显的成本增加延迟增加摘要不断变化输出不稳定Context 管理成本本身超过 Agent 工作成本所以 LCM 将生成 Summary和使用 Summary分离。13. Compaction 什么时候发生基本思路是Context Pressure 上升 ↓ 达到阈值 ↓ 旧内容需要压缩 ↓ compact()例如模型允许的 Working Budget 假设是200K当前 Context 已经达到170K并且配置阈值是75%系统就可以开始认为需要准备 Compaction而不是非要等到199.9K才开始救火。14. Deferred Compaction 的意义现代 LCM 实现不会希望每次一达到阈值就阻塞当前用户请求。更合理的模式是发现 Context Pressure ↓ 记录 Compaction Debt ↓ 当前 Model Run 尽量继续 ↓ afterTurn / maintenance ↓ 执行 Compaction只有出现真正危险的情况当前组装出来的 Prompt 已经无法放进 Active Token Budget才可能在assemble()路径中同步做紧急压缩。因此可以把 Compaction 分成Proactive Compaction 提前维护 Emergency Compaction Prompt 已经超预算时救火15. 摘要是否一定准确不是。这是理解Lossless最关键的一点。Summary LLM 本身仍然是一个生成模型。例如原始内容Production Redis TTL 2700 Staging Redis TTL 3600摘要可能写成讨论并调整了 Redis TTL。这并没有错但丢掉了2700 3600 production staging甚至理论上摘要模型也可能发生事实错误。因此LCM 不能保证 Summary 本身 100% 无损或 100% 准确。16. 那为什么叫 Lossless因为它的“Lossless”主要不是指Summary 无损而是指Raw History 不丢失可以概括成Lossless Storage Lossy Representation也就是说底层保存 原始 User / Assistant / Tool Messages → 无损 当前模型看到 Summary → 有损压缩真正需要历史细节时可以重新回到 Raw History。17. Summary DAG 是什么普通摘要系统容易变成100 轮 ↓ Summary 1 Summary 1 新 100 轮 ↓ Summary 2 Summary 2 新 100 轮 ↓ Summary 3不断对“上一版摘要”再次摘要会产生累计信息损失。LCM 更倾向维护一个多层摘要结构S3 / \ S1 S2 / \ / \ S01 S02 S03 S04 / | \ / | \ Raw Raw Raw Raw Raw Raw也就是Raw Messages ↓ Leaf Summary ↓ Condensed Summary ↓ 更高层 Summary越久远的历史可以越来越抽象。但Raw Messages依然保存。18. LCM 的 Recall / Expand因为 Summary 可能省略细节所以 LCM 还需要提供Recall能力。例如模型当前看到Summary: 曾经讨论过 Redis TTL 调整。用户问Production 最后到底改成多少Summary 不足以回答。那么 Agent 可以进一步使用lcm_grep lcm_describe lcm_expand之类的机制去定位历史。执行逻辑可以理解成高层 Summary ↓ 发现缺少精确信息 ↓ 搜索相关 Summary / Message ↓ 向下 Expand ↓ 找到 Raw History ↓ 获取原始事实因此Summary 更像“历史索引 压缩表示”而 Raw Messages 才是底层事实源。19. LCM 可以类比成虚拟内存这是理解 LCM 很直观的方式。可以类比LLM Context Window RAMLCM SQLite / Raw History SSDSummary DAG 压缩缓存 / 索引Fresh Tail RAM 里的热数据lcm_expand Page-In于是所有历史 并不需要同时进入 RAM 只把当前 Working Set 加载进模型 Context所以 LCM 的本质不是让模型真的拥有无限 Context Window而是让有限 Context Window 可以操作近似无限增长的可寻址历史更准确的术语可以理解成Unbounded Addressable History Bounded Active Context20. LCM 的核心模块如果从工程角度总结可以归纳成20.1 Persist持久化原始 Conversation保存User MessagesAssistant MessagesTool CallsTool ResultsConversation 元信息20.2 Compact将旧 Raw History 压缩成 Summary通常可能调用Summary LLM20.3 Condense当 Summary 自身越来越多时Summary Summary Summary继续生成更高层 Summary。形成Summary DAG20.4 Assemble在每次 Model Run 前Summary Frontier Fresh Tail 当前消息 Token Budget生成messages[]20.5 Recall当当前 Summary 不足以回答问题时grep describe expand重新访问历史细节。20.6 Protect避免Conversation History Model Context Window导致模型请求失败。21. 没有 LCM 时 OpenClaw 会不会做摘要会。这是一个非常重要的区别。没有安装 LCM并不意味着OpenClaw 完全没有 CompactionOpenClaw 默认 Context Engine / Legacy Context 管理本身也需要解决Conversation 越来越长的问题。因此它也会进行某种Compaction Recent Messages 保留所以并不是没有 LCM 完全没有摘要而是没有 LCM → 使用 OpenClaw Legacy Context Engine 有 LCM → lossless-claw 接管 Context Engine Slot22. Legacy Context Engine 与 LCM 的区别可以简单理解成Legacy │ ├── Context 越长 ├── 自动 Compaction ├── 压缩旧内容 └── 保留近期消息而 LCM 更进一步LCM │ ├── Raw History 持久化 ├── Summary DAG ├── 多层压缩 ├── Token-aware Assemble ├── Fresh Tail ├── Deep Recall ├── Expand └── 长期 Conversation Virtualization因此 LCM 不是“增加一个摘要功能”而更接近替换 Conversation Context Management 的核心实现。23. LCM 与 Memory 有什么区别这是第二个非常容易混淆的问题。可以用一句话区分LCM “这个 Conversation 过去发生过什么”Memory “关于用户 / 项目有什么事实值得长期知道”24. LCM 更接近 Episodic Memory例如 Conversation 里曾经发生第 120 轮 我们决定将 Redis TTL 从 3600 改成 2700。 第 124 轮 因为 stale cache。 第 128 轮 staging 继续保持 3600。这些是Conversation History也就是“发生过什么”LCM 很适合管理。25. Memory 更接近 Semantic Memory例如用户默认使用 pnpm 用户主要维护 openclaw-extensions 生产数据库不能直接修改 用户倾向 TypeScript这些更像长期事实 长期偏好 稳定知识适合 Memory。Memory 并不关心这是第 120 轮说的 还是第 500 轮说的它更关心这是不是以后仍值得知道的事实26. LCM 与 Memory 如何配合可以画成LLM ▲ │ Final Context │ ┌────────────┼────────────┐ │ │ │ ▼ ▼ ▼ System Memory LCM Prompt Recall Assemble │ │ │ 身份/规则 长期事实 当前会话 工具说明 用户偏好 Summary 行为约束 项目知识 Fresh Tail两者最终竞争的是同一个有限 Context Window因此 Memory 不能无限注入LCM 也不能无限 assemble。27. Final LLM Request 的完整关系最准确的关系可以表示成完整 Conversation History │ ▼ LCM │ ▼ messages[] │ │ ├──────── System Prompt ├──────── Tool Schemas ├──────── Memory ├──────── Workspace / Skills │ ▼ Final Model Context │ ▼ LLM所以完整历史 ! messages[]messages[] ! Final Model Context而是完整历史 ↓ LCM ↓ messages[] messages[] 其他 Prompt Components ↓ Final Model Context28. 128K / 1M 和 LCM 的关系假设Model Context Window 128KConversation 已经800KLCM 可能800K History ↓ SQLite Summary DAG ↓ assemble 80K ↓ 加 System / Tools / Memory ↓ 控制在 128K 内如果换成1M Context ModelConversation 已经10MLCM 可能10M History ↓ LCM ↓ 300K / 500K / 700K Working Set ↓ Final Context 1M所以模型 Context 越大LCM 可以更少压缩 Fresh Tail 可以更大 历史信息保真度可以更高但并不会让 LCM 失去意义。29. 一次完整 Agent Turn 的执行链路可以把整个生命周期画成用户发送消息 │ ▼ OpenClaw Runtime │ ▼ Context Engine ingest │ ▼ LCM Persist │ ▼ SQLite / Conversation DB │ ▼ OpenClaw 准备 Model Run │ ▼ LCM assemble() │ ├── Summary DAG ├── Fresh Tail ├── Raw History ├── Current Turn └── Token Budget │ ▼ messages[] │ ▼ OpenClaw 添加 │ ├── System Prompt ├── Memory ├── Tools ├── Skills └── Runtime Metadata │ ▼ Final LLM Context │ ▼ Main LLM │ ├── 直接回答 │ └── Tool Call │ ▼ Tool Result │ ▼ 再次 assemble() │ ▼ Main LLM这也是为什么一次用户消息可能触发多次 assemble()30. Summary LLM、Main LLM、Expansion LLM 的区别LCM 周围可能出现多种模型调用。Main LLM负责真正回答用户Summary LLM负责Compaction例如20K Raw History ↓ Summary LLM ↓ 2K Summary它不是每轮都调用。Expansion / Recall Model某些实现还可能在深层历史检索时启动额外模型或子 Agent。例如高层 Summary ↓ 需要精确历史 ↓ Expansion ↓ 搜索更深层节点 ↓ Raw History因此assemble()本身不等于LLM Call31. 为什么 LCM 可以做到“Conversation 看起来无限长”因为用户体验看到的是我可以一直在一个 Conversation 中继续聊而模型实际上每轮只看到有限 Working Context所以所谓无限长 Conversation真正含义是Conversation Lifetime 可以非常长 但 Single Model Context 永远有限也就是无限历史 ≠ 无限 Prompt更准确的是长期历史近似无限增长 当前模型上下文保持有限32. LCM 的主要价值综合来看LCM 的主要价值可以归纳成32.1 防止 Context Overflow避免长 Conversation 最终超过模型限制。32.2 降低长期会话 Token 成本不必每轮重复发送全部原始历史。32.3 保持最近上下文的完整性通过 Fresh Tail 避免近期对话过早被摘要。32.4 让旧历史逐层抽象通过 Summary DAG 控制历史占用。32.5 保留原始历史即使 Summary 丢失细节Raw Message 仍存在。32.6 支持历史 Recall通过 Search / Expand 找回精确信息。32.7 支持长期 Agent Session让一个 Agent Conversation 能跨越非常长的时间周期。33. LCM 最核心的四个词如果只记住四个概念Persist ↓ Compact ↓ Assemble ↓ RecallPersist原始历史保存下来Compact旧内容由 Summary LLM 压缩Assemble每次 Model Run 前 从已有数据中组装 Working ContextRecallSummary 不够时 重新访问更深层历史 / Raw History34. 最终心智模型可以把整个系统理解成┌─────────────────────┐ │ Raw History │ │ │ │ User │ │ Assistant │ │ Tool Calls │ │ Tool Results │ └──────────┬──────────┘ │ ▼ Compact │ Summary LLM │ ▼ ┌─────────────────────┐ │ Summary DAG │ └──────────┬──────────┘ │ │ ┌──────────▼──────────┐ │ assemble │ │ │ │ Summary Frontier │ │ Fresh Tail │ │ Current Turn │ │ Token Budget │ └──────────┬──────────┘ │ ▼ messages[] │ ┌───────────────────────┼─────────────────────┐ │ │ │ ▼ ▼ ▼ System Prompt Memory Tools │ │ │ └───────────────────────┼─────────────────────┘ │ ▼ Final Model Context │ ▼ LLM │ 需要旧历史细节 │ ┌──────────┴──────────┐ │ │ No Yes │ │ ▼ ▼ Answer Grep / Expand │ ▼ Raw History35. 一句话总结 LCMLCM 不是让模型拥有无限 Context Window而是通过持久化原始历史、多层摘要、Token-aware Assembly 和按需 Recall让一个有限 Context Window 的模型可以长期操作远大于自身窗口的 Conversation History。36. 对openclaw-extensions集成的工程启示如果将lossless-claw合入自己的openclaw-extensions最值得关注的不是单纯插件有没有加载成功而是以下完整生命周期是否仍然正常ingest ↓ persist ↓ compact ↓ summary ↓ assemble ↓ final prompt ↓ main model ↓ recall / expand尤其建议重点验证1. Raw Messages 是否正常写入 2. Summary 是否正常生成 3. Summary DAG 是否正常维护 4. assemble 是否每次 Model Run 正常触发 5. Fresh Tail 是否保持原文 6. Token Budget 是否正确生效 7. Memory 是否仍然进入 Final Context 8. Tool Call / Tool Result 是否正确进入 Conversation 9. Context 超限时是否能安全 Compaction 10. Summary 丢失细节后是否能 Recall Raw History 11. Gateway 重启后 Conversation 是否仍可恢复 12. 切换 128K / 1M 模型时 Budget 是否能正确适配如果这些链路都正常才可以认为 LCM 不只是“插件加载成功”而是Context Engine 真正工作正常37. 最后再用三个等式避免混淆Conversation HistoryConversation History 从开始到现在发生过的全部原始消息它可以非常大。LCM messages[]LCM messages[] LCM 为当前 Model Run 组装出来的 Conversation Working Context它是有限的。Final LLM ContextFinal LLM Context System Prompt Tools Memory Workspace / Skills LCM messages[] 其他运行时内容它必须小于模型 Context Window。最终关系巨大 Conversation History ↓ LCM ↓ 有限 messages[] ↓ System Tools Memory Skills ↓ Final LLM Context ↓ 受 128K / 1M 等模型窗口限制 ↓ LLM这就是 LCM 在整个 OpenClaw Agent Runtime 中最核心的位置。