Lossless-Claw 背景与目标

问题陈述：LLM 上下文窗口的瓶颈

上下文窗口的限制现状

大型语言模型 (LLM) 的上下文窗口虽然在不断扩展，但仍然存在硬性限制。截至 2026 年，主流模型的上下文窗口配置如下：

关键数据点：

• 在一次典型的 2 小时编程会话中，代码审查对话可轻松超过 50K tokens
• 技术咨询场景下，多轮问答累计 token 数平均增长率为 15-20% / 轮
• 当上下文达到窗口上限的 80% 时，模型开始出现”注意力稀释”现象

传统方案的缺陷：滑动窗口压缩

当前绝大多数 AI Agent 框架（包括 OpenClaw 默认配置）采用滑动窗口压缩策略：

flowchart TD
    A[对话开始] --> B[消息累积]
    B --> C{超出窗口?}
    C -->|否| D[继续对话]
    C -->|是| E[截断旧消息]
    E --> F[保留最近 N 条]
    F --> G[上下文丢失]
    D --> B
    G --> H[对话质量下降]

滑动窗口的核心问题：

1. 信息丢失不可逆：被截断的消息无法恢复，导致上下文断裂
2. 关键信息被误删：简单按时间截断可能删除包含关键决策、需求变更的消息
3. 长周期任务失败：超过 20 轮的复杂任务（如代码重构、项目规划）容易丢失早期约束条件
4. 用户体验割裂：用户感知到 Agent”忘记”了之前的讨论内容

实际案例：

• 在一次代码审查会话中，开发者在第 15 轮提出了关键的安全约束，但在第 45 轮时被滑动窗口截断，导致后续生成的代码违反了该约束
• 根据 Martian Engineering 的内部测试，滑动窗口方案在长对话（>30 轮）中的信息丢失率高达 40-60%

约束条件与成功指标

技术约束

LCM 方案设计时必须满足的约束条件：

成功指标定义

LCM 方案的验收标准：

功能性指标：

• ✅ 所有原始消息必须持久化到 SQLite
• ✅ 活跃上下文必须控制在配置阈值内（默认 75%）
• ✅ 提供工具支持从摘要回溯原始消息
• ✅ 支持全文检索（FTS5）快速定位历史信息

性能指标：

• ✅ 上下文组装延迟 < 500ms（P95）
• ✅ 摘要生成 token 开销 < 原始消息的 20%
• ✅ 数据库存储增长 < 原始对话的 150%

质量指标：

• ✅ 信息可检索率 > 95%（通过 lcm_grep 测试）
• ✅ 摘要准确性 > 90%（人工评估）
• ✅ 长对话（>50 轮）的任务完成率 > 85%

LCM 的解决思路

核心设计理念

LCM (Lossless Context Management) 基于以下关键洞察：

1. 分层抽象：对话历史可以分层组织，高层摘要 + 近期原始消息 = 完整上下文
2. DAG 结构：摘要节点形成有向无环图，支持从任意节点回溯到源消息
3. 按需展开：只在需要时展开摘要，避免一次性加载全部历史
4. 工具增强：提供专门工具（lcm_grep/describe/expand）让 Agent 主动检索历史

与传统方案的本质区别

flowchart LR
    subgraph 滑动窗口方案
        A1[消息1] --> A2[消息2] --> A3[消息3]
        A4[消息4] --> A5[消息5]
        A3 -.->|截断| X1[丢失]
    end
    
    subgraph LCM DAG方案
        B1[消息1] --> B2[消息2] --> B3[消息3]
        B1 & B2 --> S1[摘要A]
        S1 --> B4[摘要节点]
        B3 & B4 --> S2[摘要B]
        S2 -.->|可回溯| B1
    end

关键差异：

参考资料

1. LCM: Lossless Context Management for Large Language Models - Voltropy 研究团队，2025
2. The Context Window Problem in LLMs - 上下文窗口限制研究综述
3. OpenClaw Context Engine Specification - 插件架构规范
4. Sliding Window vs Hierarchical Compression - Martian Engineering 技术博客