OpenClaw LCM深度解析：当Agent的”记忆”突破上下文窗口极限

在Hermes Agent凭借”自进化”登顶全球调用榜的同时，OpenClaw正在另一个维度上构建护城河——LCM（Lossless Context Management，无损上下文管理）。这是一个技术深度远超”聊天记忆”的架构创新：它不是简单地”记住对话”，而是构建了一个有向无环图（DAG）来表示Agent的完整认知历史。当其他Agent框架还在为”上下文窗口溢出”焦虑时，OpenClaw的LCM已经实现了”无限上下文”的技术突破。

一、问题：为什么Agent需要”无损”上下文管理

1.1 传统方案的困境

所有Agent框架都面临同一个核心问题：大模型的上下文窗口是有限的。

以Claude 3.5 Sonnet为例，其上下文窗口为200K Token。对于一个执行复杂任务的Agent来说，这个限制意味着：

场景A：Agent需要执行一个涉及100个步骤的任务，每个步骤平均产生2K Token的上下文（包含系统提示词、工具调用、返回结果、推理过程）。到第50步时，上下文窗口已经被占满——Agent”忘记”了第1-30步的细节。

场景B：Agent在执行任务时，用户提到了一个关键信息（如”我老婆的生日是3月15日”）。但在后续的对话中，这个信息被新的上下文”挤出”窗口，导致Agent在规划生日惊喜时完全忽略了这个关键约束。

场景C：Agent在一个长期运行的项目中积累了大量上下文（项目需求、会议纪要、代码决策）。当用户问”为什么当初选择PostgreSQL而不是MySQL”时，Agent无法回答——因为决策上下文早已不在窗口内。

1.2 传统解决方案的局限

现有Agent框架主要采用三种方案来处理上下文限制：

方案一：滑动窗口（Sliding Window）

• 实现方式：当上下文超过窗口限制时，删除最早的对话历史
• 问题：丢失了早期的重要信息，可能导致Agent”忘记”用户的初始目标

方案二：摘要压缩（Summarization）

• 实现方式：定期用LLM对历史对话进行摘要，用摘要替换原文
• 问题：摘要过程有损——关键细节可能在压缩中丢失；摘要质量依赖LLM能力

方案三：RAG检索（Retrieval-Augmented Generation）

• 实现方式：将历史对话存入向量数据库，需要时检索相关片段
• 问题：检索精度问题——可能漏检或误检；无法保留对话的时间顺序和因果关系

1.3 OpenClaw的洞察：上下文不只是”记忆”，而是”认知历史”

OpenClaw的LCM设计基于一个核心洞察：

Agent的上下文不是一堆”需要记住的信息”，而是一个”认知历史的图谱”

。

这个认知历史包含：

• 决策链
  
  ：Agent为什么做出某个决策？（包含当时的上下文、可选方案、权衡逻辑）
• 因果链
  
  ：当前状态是如何从前序操作演化而来的？
• 知识积累
  
  ：Agent从任务执行中学到了什么？（技能、偏好、约束）

传统方案的共同问题是：它们把上下文当作”数据”来处理，而不是”知识图谱”。

二、LCM的核心架构：Summary DAG

2.1 有向无环图（DAG）表示

LCM的核心是一个有向无环图（Directed Acyclic Graph），其中：

• 节点（Node）
  
  ：代表一个”摘要单元”，包含压缩后的上下文
• 边（Edge）
  
  ：代表”包含关系”，指向被摘要的子节点
• 根节点
  
  ：当前活跃的上下文（在窗口内的对话）
• 叶子节点
  
  ：原始的、未压缩的消息和工具调用

                    [当前活跃上下文]                           ↑                     [摘要节点 S3]                     /         \             [摘要节点 S1]  [摘要节点 S2]               /     \          |           [M1]    [M2-M5]   [M6-M10] 

2.2 摘要节点的结构

每个摘要节点包含：

json{"id": "sum_abc123","kind": "leaf | internal","depth": 2,"descendant_count": 5,"earliest_at": "2026-05-15T08:00:00Z","latest_at": "2026-05-15T09:30:00Z","content": "摘要内容...","token_count": 1500,"children": ["sum_def456", "sum_ghi789"]}

关键字段解读：

• kind
  
  ：leaf表示直接由原始消息摘要而来；internal表示由子摘要进一步摘要而成
• depth
  
  ：在DAG中的深度，深度越大表示压缩层级越高
• descendant_count
  
  ：包含的原始消息数量
• earliest_at / latest_at
  
  ：时间范围，用于时间检索

2.3 “无损”的含义

LCM的”无损”（Lossless）不是指”完全不丢失信息”，而是：

可以通过摘要节点还原出原始的、完整的上下文。

具体机制：

第一：每个摘要节点都保留了指向原始消息的”指针”（通过ID引用）。当Agent需要”回忆”某个细节时，LCM可以沿着DAG向下遍历，找到原始消息。

第二：摘要节点保留了”时间戳范围”，Agent可以基于时间维度检索上下文（如”上周三我们讨论了什么？”）。

第三：摘要内容采用”结构化存储”，而不是纯文本。这包括：

• 关键实体提取（人名、地名、时间、约束条件）
• 决策节点标注（Agent做出的关键决策及其理由）
• 工具调用记录（调用参数、返回结果、错误处理）

三、LCM的三大核心工具

OpenClaw为LCM提供了三个核心工具，供Agent在任务执行中使用：

3.1 lcm_grep：语义搜索

python# 搜索包含"PostgreSQL"的所有摘要result=lcm_grep(pattern="PostgreSQL",mode="full_text",# 或 "regex"scope="both",# "messages" | "summaries" | "both"limit=10)

返回结果：

json{"matches": [    {"summary_id": "sum_abc123","snippet": "用户选择了PostgreSQL作为主数据库，理由是...","timestamp": "2026-05-10T14:30:00Z"    }  ]}

3.2 lcm_expand：展开摘要

当Agent需要深入了解某个摘要的细节时：

python# 展开摘要，获取原始上下文expanded=lcm_expand(summary_ids=["sum_abc123"],max_depth=3,token_cap=5000,include_messages=True)

返回一个包含完整上下文的文本块，Agent可以将其”加载”到当前的推理上下文中。

3.3 lcm_describe：查询摘要元数据

python# 获取摘要的详细信息info=lcm_describe(id="sum_abc123")

返回摘要的结构、token数量、时间范围、子节点列表等。

四、与竞品方案的对比

4.1 Hermes Agent的四层记忆体系

Hermes Agent的”四层记忆体系”是LCM的主要竞品：

LCM vs Hermes四层记忆：

4.2 AutoGPT的内存系统

AutoGPT使用”内存索引”（Memory Index）来存储和检索历史上下文：

• 存储：将每个重要的决策和结果存入向量数据库
• 检索：基于语义相似度检索相关记忆

LCM vs AutoGPT内存：

4.3 CrewAI的共享记忆

CrewAI在多Agent场景中使用”共享记忆”机制：

• 每个Agent有独立记忆
• 通过”记忆共享”协议交换信息

LCM的优势：LCM天然支持多Agent场景——每个Agent可以有自己的DAG，同时共享某些摘要节点。

五、实战：如何在OpenClaw中使用LCM

5.1 配置LCM

在OpenClaw的配置文件中启用LCM：

yaml# openclaw.yamllcm:enabled: truecompression_threshold: 0.7# 当上下文占窗口70%时触发压缩max_depth: 5# 最大压缩层级token_cap_per_summary: 2000# 每个摘要的最大token数storage:type: "sqlite"# 或 "postgres" / "mongodb"path: "./lcm.db"

5.2 在Skill中使用LCM

markdown# my-skill/SKILL.md## 使用LCM回忆用户偏好  当用户问"我之前说过什么"时：  1. 调用 `lcm_grep` 搜索相关上下文 2. 如果找到匹配的摘要，调用 `lcm_expand` 展开详情 3. 基于展开的内容回答用户  示例命令： 

lcm_grep –pattern=”用户偏好” –scope=summaries –limit=5 lcm_expand –summary-ids=sum_xxx –token-cap=3000

5.3 监控LCM状态

bash# 查看LCM的存储状态 openclawlcmstatus  # 输出示例 LCMStatus: Totalsummaries:127Totaltokensstored:45,000 Compressionratio:3.2x DAGdepth:4Storagesize:2.3MB 

六、LCM的技术挑战与未来方向

6.1 当前挑战

挑战一：摘要质量

• LCM依赖LLM生成摘要，摘要质量直接影响后续检索和展开的准确性
• 解决方案：采用多轮摘要校验机制，用第二个LLM验证摘要的完整性

挑战二：检索延迟

• 当DAG深度很大时，展开摘要可能需要多级查询，增加延迟
• 解决方案：引入”热点摘要缓存”，将高频访问的摘要预加载到内存

挑战三：存储膨胀

• 对于长期运行的Agent，LCM存储会持续增长
• 解决方案：引入”摘要过期”机制，自动清理过时的、不再被引用的摘要

6.2 未来方向

方向一：多模态LCM

• 当前LCM主要处理文本上下文
• 未来扩展到图像、音频、视频的多模态摘要和检索

方向二：跨Agent共享LCM

• 多个Agent可以共享同一个LCM实例
• 实现”团队记忆”——一个Agent学到的知识可以被其他Agent访问

方向三：LCM可视化

• 提供DAG可视化界面，用户可以直观浏览Agent的”认知历史”
• 支持手动编辑摘要、合并/拆分节点

七、给开发者的建议

7.1 何时使用LCM

适合LCM的场景：

• 长期运行的Agent（如个人助理、项目管理Agent）
• 需要频繁”回忆”历史的Agent（如客服Agent、研究Agent）
• 多步骤复杂任务的Agent（如代码重构Agent、数据分析Agent）

不适合LCM的场景：

• 一次性任务（如单次翻译、单次问答）
• 上下文窗口充足的场景（如简单的聊天机器人）

7.2 LCM最佳实践

实践一：设置合理的压缩阈值

• 过低（如0.5）：频繁压缩，增加延迟
• 过高（如0.9）：可能导致上下文溢出
• 推荐：0.65-0.75

实践二：为关键信息添加”锚点”

• 在用户提到重要约束时，手动创建一个”锚点摘要”
• 确保关键信息不会被后续压缩覆盖

实践三：定期清理过期摘要

• 对于不再活跃的Agent实例，定期清理其LCM存储
• 避免存储无限膨胀

结语

当Hermes Agent在”调用榜”上攻城略地时，OpenClaw的LCM代表的是另一条技术路线：不是让Agent”更快”，而是让Agent”更聪明”。

LCM的核心价值在于：它让Agent拥有了”长期记忆”的能力——不是简单的”记住对话”，而是构建了一个可以被查询、展开、追溯的认知图谱。

对于开发者来说，LCM是一个值得深入研究的技术模块。它不仅解决了上下文窗口的技术约束，更重要的是，它为Agent的”持续学习”和”知识积累”提供了基础设施。

当Agent的上下文不再是”有限的窗口”，而是”无限的历史”时，Agent的能力边界将被重新定义。

作者：NAS奇思妙想