OpenClaw Agent上下文压缩实战：摘要、检索与分层指令三大策略对比-平芜编程栈

1. 项目概述：当Agent遇上“肥胖”的上下文

最近在折腾一个基于OpenClaw框架的智能体项目，遇到了一个典型问题：随着对话轮次和工具调用链的增长，上下文就像吹气球一样膨胀起来。模型开始“健忘”，响应速度变慢，甚至偶尔会胡言乱语。这让我意识到，上下文管理不是个可有可无的“优化项”，而是决定Agent能否长期稳定运行的核心工程问题。于是，我决定停下来，专门花时间做一系列实验，系统地探索如何给OpenClaw的上下文“瘦身”。

OpenClaw是一个功能强大的AI智能体开发框架，它允许开发者构建能够理解复杂指令、调用工具、并维持长期记忆的智能应用。但它的强大也带来了挑战：为了做出准确的决策，Agent需要将历史对话、工具调用结果、系统指令等大量信息塞进每次请求的上下文窗口。这直接关系到两个核心指标：成本（更长的上下文意味着更高的API调用费用）和性能（过长的上下文会导致模型理解能力下降，响应延迟增加）。

这次实验的目标很明确，就是通过三种不同的技术路径，在不显著牺牲Agent智能水平的前提下，尽可能压缩上下文长度。我选择了三个方向进行切入：基于关键词的摘要提取、利用向量数据库的语义检索进行上下文筛选，以及探索Claude Code的“上下文分层”新特性。整个过程就像给一个塞满杂物的房间做断舍离，既要扔东西，又得保证最重要的物品触手可及。

2. 实验设计与核心思路拆解

2.1 问题定义与评估基准

在开始任何优化之前，必须明确我们要解决什么问题，以及如何衡量优化是否有效。盲目地压缩上下文可能会导致Agent失忆，做出前后矛盾的决策。

我定义的核心问题是：如何在不损害任务完成率和回答质量的前提下，减少每次调用大语言模型时所携带的上下文令牌数。为此，我设定了三个评估维度：

上下文长度压缩率：这是最直接的量化指标，即（原始上下文令牌数 - 压缩后上下文令牌数）/ 原始上下文令牌数。
任务完成率：设计一组标准的多轮对话任务（例如，查询天气、制定旅行计划、进行多步骤计算），观察压缩前后Agent能否同样准确地完成所有步骤。
回答质量一致性：通过人工评估或使用另一个LLM进行评判，对比压缩前后，Agent在复杂问题上的回答是否保持了相同的深度、准确性和连贯性。

我构建了一个简单的测试流水线：一个模拟用户与OpenClaw Agent进行多轮交互的脚本，它会自动记录每一轮请求的上下文内容、令牌数以及Agent的最终输出。这个基准测试将在三种压缩策略实施前后各运行一次，以获取对比数据。

2.2 三种压缩策略的技术选型

面对上下文膨胀，业界和社区有诸多思路。我选择了三种具有代表性且易于在OpenClaw框架内实现的方法进行实验。

策略一：基于规则与关键词的摘要提取这是最直观、计算成本最低的方法。其核心思想是：并非所有历史对话都同等重要。我们可以制定一些启发式规则，例如：

保留最近N轮对话的完整内容。
对于更早的对话，仅提取其中涉及的关键实体（如人名、地点、任务对象）、用户的核心意图以及关键的决策点，生成一段简短的摘要。
完全移除那些已被确认完成或无关紧要的中间步骤输出。

这种方法实现简单，速度快，但缺点也很明显：摘要的生成本身依赖另一套规则或一个较小的摘要模型，可能会丢失原文的细微差别和复杂逻辑。

策略二：基于向量数据库的语义检索这是一种更“智能”的动态压缩方法。其核心思想是：将历史上下文中的每一段话（可以是单轮对话，或一个工具调用结果）都编码成向量，存入向量数据库（如Chroma、Weaviate）。当需要构造新一轮请求的上下文时，我们不以时间为序，而是以相关性为序。

将当前用户的最新查询也编码成向量。
用这个查询向量去向量数据库中检索最相关的K条历史记录。
只将这K条最相关的记录放入本次请求的上下文窗口。

这种方法能确保上下文始终围绕当前最相关的话题，对于处理话题跳跃的对话非常有效。但其开销在于需要维护向量数据库，并且每次请求都需要进行编码和检索。

策略三：探索Claude Code的上下文分层指令这是一种利用模型自身能力的新思路。Anthropic在其Claude模型中引入了更强大的系统指令控制能力。我们可以尝试在系统指令中明确要求模型如何处理长上下文，例如：

“你拥有一个有限的短期记忆缓冲区。请主动识别对话中的核心事实、用户偏好和待办事项，并将其总结后存储在‘长期记忆’部分。在后续回答中，优先从‘长期记忆’中提取信息，而非逐字引用冗长的历史记录。”
或者，我们可以结构化上下文，将其分为“背景概要”、“近期关键事件”、“当前任务详情”等几个固定部分，强制模型以摘要化的方式更新这些部分。

这种方法将压缩的责任部分交给了模型本身，可能获得更好的语义保持度，但高度依赖于模型对复杂指令的遵循能力，且效果较难稳定控制。

3. 核心细节解析与实操要点

3.1 OpenClaw上下文结构剖析

要对症下药，必须先了解OpenClaw上下文的“解剖结构”。在一次典型的Agent请求中，上下文通常由以下几个部分组成，它们共同构成了一个庞大的提示词：

系统指令：定义了Agent的角色、能力、行为规范和核心目标。这部分通常较长且固定，是上下文的基础。
对话历史：用户与Agent之间一来一往的完整记录。这是上下文膨胀的主要来源，尤其是进行深入、多轮的任务协作时。
工具调用与结果：当Agent决定调用一个函数（如搜索网络、执行代码、查询数据库）时，工具的描述、调用参数以及执行结果都会被追加到上下文中。这些内容往往非常详细且结构化。
内部推理过程：一些高级的Agent框架（或通过提示词工程实现）会让模型输出“思考链”。这部分内容对于提升决策透明度至关重要，但也会显著增加令牌消耗。

在OpenClaw中，这些内容通常被组织成一个消息列表，每条消息都有其角色（如system,user,assistant,tool）。我们的压缩操作，本质上是在保持消息列表结构的前提下，对其中user,assistant,tool角色的消息内容进行精简、摘要或筛选。

注意：在操作中，务必保留system指令的完整性。对系统指令的修改会从根本上改变Agent的行为，这属于调优范畴，而非上下文压缩。

3.2 策略一实现：轻量级摘要生成器

我首先实现了一个基于规则和textrank算法的混合摘要器。为什么不直接用GPT来摘要？因为成本。我们的目标是降低开销，如果摘要过程本身又产生了高昂的API调用费，那就本末倒置了。

实现步骤：

对话分块与重要性标记：将历史对话按轮次分块。为每一块打上初步的重要性标签。例如，包含用户明确指令（如“请帮我订票”）或Agent关键结论（如“因此，我推荐方案A”）的块，标记为高优先级；而一些寒暄、确认性语句（如“好的”、“明白了”）则标记为低优先级。
关键实体提取：使用像spaCy或jieba（中文）这样的NLP库，从高优先级的对话块中提取命名实体（人物、组织、地点、时间、数字等）。这些实体是记忆的骨架，必须保留。
基于TextRank的摘要生成：对于标记为低优先级但又不能完全丢弃的对话块（可能包含一些背景信息），使用TextRank算法。该算法将文本视为一个词网络，通过投票机制找出最重要的句子。我们可以从中抽取1-2个核心句。
摘要组装：最后，将保留的完整高优先级对话块、提取的关键实体列表、以及生成的摘要句子，按照时间顺序组装成一段连贯但简短的文字，作为“压缩后的历史”。

实操心得与避坑指南：

阈值是关键：如何定义“高优先级”？我最初使用简单的关键词匹配，效果很差。后来改为基于句子嵌入的余弦相似度来判断：将当前用户查询的向量与历史每句话的向量比较，相似度超过某个阈值（如0.7）的句子所属的对话块，被视为高相关，予以保留或详细摘要。这个阈值需要根据你的任务域进行微调。
保持时间线：尽管压缩了，但组装时强烈建议保留大致的时间顺序。完全打乱顺序会让模型难以理解事件发展的因果关系。
测试，测试，再测试：一定要用你的真实业务对话流去测试这个摘要器。观察压缩后，Agent是否还记得早先约定的细节。我就在一个旅行规划Agent上栽过跟头，摘要器把用户“对花生过敏”这个关键信息当成了低优先级内容给压缩掉了，导致Agent推荐了含有花生的餐厅。

3.3 策略二实现：集成向量数据库进行动态检索

第二种策略的实现更为工程化，需要引入外部组件。我选择了ChromaDB，因为它轻量且易于集成。

架构与流程：

初始化向量数据库：在Agent启动时，创建一个持久化的Chroma集合（Collection）。这个集合的“文档”就是历史上下文片段，“元数据”则包含该片段的角色、时间戳、关联的工具调用ID等信息。
对话片段向量化与存储：每一轮对话交互结束后（即收到Agent回复后），立即对本轮产生的所有新消息进行处理。将每条user,assistant,tool消息的内容，使用一个轻量级的句子嵌入模型（我选用all-MiniLM-L6-v2，它平衡了速度与质量）转换为向量，然后连同其元数据存入Chroma集合。
检索式上下文构建：当新的用户查询到来时：
- 首先，将当前用户查询也转换为向量。
- 然后，用这个查询向量去Chroma集合中检索相似度最高的K条历史记录（K值可根据当前上下文窗口剩余空间动态调整）。
- 接着，并非直接使用检索到的片段。为了提高连贯性，我会以这些检索到的片段为“锚点”，将它们各自所在的那一轮完整对话（包括锚点消息前后的相关消息）提取出来。这样可以避免出现孤立的、断章取义的句子。
- 最后，将这些完整的对话轮次，按照其原始时间顺序进行排序和组装，形成本次请求的上下文。

实操心得与避坑指南：

分块策略决定效果：直接将一整轮长达数十句的对话存为一个向量，检索精度会很差。我的经验是进行智能分块：以“说话人切换”或“主题明显转变”为界进行分块。一个简单的规则是：将连续的同一角色（如用户连续说了好几句话）的内容合并为一个块，或者将一个完整的“用户提问-助手回答-工具调用”循环作为一个块。
元数据是黄金：在存储时，务必丰富元数据。除了时间戳、角色，我还记录了session_id,turn_number,contains_decision（是否包含决策）,contains_fact（是否包含关键事实）等。在检索时，可以结合元数据进行过滤。例如，可以设置检索条件为“相似度 > 0.75 且 contains_fact == True”，这能优先召回包含硬性事实的片段，而不是那些闲聊。
注意“信息茧房”：纯粹的语义检索有一个潜在风险：如果用户一直围绕一个话题深入，检索到的永远都是最相关的那些历史，导致更早的、但可能很重要的背景信息（比如对话开始时设定的总体目标）被永远遗忘。为了解决这个问题，我引入了一个“强制记忆”机制：无论检索结果如何，总是将对话的前3轮和最近2轮完整地加入上下文。这保证了目标的连贯性和最新进展的完整性。

4. 实验过程与核心环节实现

4.1 实验环境搭建与测试流水线

工欲善其事，必先利其器。为了公平、可重复地对比三种策略，我搭建了一个标准化的测试环境。

技术栈：

核心框架：OpenClaw (最新稳定版)
大语言模型：Claude 3 Haiku (兼顾成本与能力，用于运行Agent)
向量数据库：ChromaDB (用于策略二)
嵌入模型：sentence-transformers/all-MiniLM-L6-v2(本地运行，用于策略二的向量化)
摘要模型/工具：textrank4zh(用于中文摘要，策略一) /spaCy(用于实体识别)
测试脚本：使用Pythonasyncio和pytest编写自动化交互与断言脚本。

测试流水线设计：我编写了一个AgentRunner类，它封装了原始的OpenClaw Agent调用逻辑。然后，我为其增加了三种“上下文处理器”装饰器，分别对应三种压缩策略。在测试时，同一个测试用例会使用不同的处理器各运行一次。

class BaseContextProcessor: def process(self, full_context_messages: List[Dict]) -> List[Dict]: """接收完整历史消息，返回处理后的消息列表""" raise NotImplementedError class SummaryProcessor(BaseContextProcessor): # 实现策略一 pass class RetrievalProcessor(BaseContextProcessor): # 实现策略二，内部包含Chroma客户端 pass class ClaudeLayeredProcessor(BaseContextProcessor): # 实现策略三，主要通过修改系统指令实现 pass # 在AgentRunner中使用 runner = AgentRunner(model="claude-3-haiku-20240307") runner.context_processor = SummaryProcessor() # 可切换不同的处理器 response = runner.chat("用户查询")

测试用例是一组预先定义好的多轮对话场景，例如“从零开始规划一个三天的北京美食之旅”，其中包含信息收集（用户喜好）、工具调用（搜索景点、餐厅）、决策制定（安排日程）、修改调整等多个环节。

4.2 策略三的探索：与模型协作的上下文分层

策略三的实现更偏向于“提示词工程”。我没有在代码层面物理地删除或修改历史消息，而是设计了一套新的系统指令和消息格式，来“引导”模型以更节省空间的方式利用上下文。

核心指令设计：我在系统指令的开头增加了这样一段话：

“你是一个善于管理对话上下文的专家。为了确保我们高效、准确地协作，请遵循以下记忆管理协议：
核心记忆区：我会在每次对话中，以<CoreMemory>标签的形式，提供一份高度精简的对话核心摘要，包括：核心目标、已确认的关键事实、用户明确不变的偏好、以及当前的待办事项列表。这是你最需要关注的信息。
详细历史区：在<CoreMemory>之后，我会附上近期的详细对话历史以供参考。
你的责任：在每次回复结束时，请根据本轮交流，主动更新<CoreMemory>的内容。用最精炼的语言修改或增添内容，确保它始终反映最新、最核心的对话状态。如果本轮对话没有改变核心信息，则注明‘核心记忆未更新’。”

然后，在每次构造请求消息时，我不再发送全部原始历史。而是：

运行一个轻量级的算法（类似策略一的摘要器），生成当前的<CoreMemory>。
只附上最近3-5轮的完整对话作为“详细历史区”。
将<CoreMemory>放在消息列表的最前面（系统指令之后），确保模型优先看到。

这样，模型每次看到的“物理上下文”很短，但它通过维护和读取那个简短的<CoreMemory>，理论上可以保持对长期目标的追踪。

实现中的挑战：这个方法的成功完全依赖于模型是否严格遵循指令。在测试中，Claude 3 Haiku大约有70%的概率会很好地更新<CoreMemory>，但有时它会忽略，或者更新的格式不正确。这需要额外的后处理逻辑来解析模型的输出，提取出更新后的记忆部分，并在下一轮中提供。这引入了一定的复杂性和不确定性。

5. 实验结果分析与横向对比

经过对三个测试场景（旅行规划、技术问题排查、创意写作协作）各运行20轮对话的测试，我收集到了关键数据，并形成了以下对比分析。

5.1 量化指标对比

策略	平均上下文长度 (令牌数)	压缩率 (vs. 原始)	任务完成率	平均响应时间 (秒)	额外计算开销
原始 (无压缩)	12500	0%	100%	3.2	无
策略一：规则摘要	5800	53.6%	95%	2.8	低 (本地CPU处理)
策略二：向量检索	4500	64.0%	98%	3.5*	中 (向量编码与检索)
策略三：分层指令	3600	71.2%	85%	2.5	极低 (仅文本处理)

*策略二响应时间包含了向量编码和检索的时间（约0.3秒）。

数据分析：

压缩率：策略三（分层指令）在压缩率上表现最好，因为它物理上传递的信息最少。策略二（向量检索）次之，策略一（规则摘要）相对保守。
任务完成率：策略二表现最为稳健，几乎接近原始版本。因为它动态保留了最相关的信息，智能性最高。策略一由于依赖固定规则，在话题突然转换时可能误删关键信息，导致5%的失败率。策略三的完成率最低，只有85%，这是其最大短板，失败主要源于模型偶尔不遵守更新记忆的指令，导致后续对话失去关键前提。
响应时间与开销：策略一和三的响应时间优于原始版本，因为传递给模型的令牌数变少了。策略二因有额外的计算步骤，总耗时稍长。从资源开销看，策略二需要维护向量数据库，是唯一需要额外存储和计算资源的方案。

5.2 定性分析与人机交互体验

除了冷冰冰的数字，实际使用体验同样重要。

策略一（规则摘要）：体验中规中矩。在线性发展的对话中（如按步骤完成任务），它工作良好。但在用户突然回溯到很早之前的话题时（例如，“还记得我们一开始说的预算吗？”），Agent有较大概率无法给出准确回答，因为它依赖的摘要可能已经丢失了具体的数字细节。给人的感觉是Agent有点“粗心”。
策略二（向量检索）：体验最接近原始版本，甚至在某些方面更好。因为它能“想起”分散在对话各处的相关片段。例如，在旅行规划中，当用户后来问“我们昨天提到的那家素食餐厅怎么样？”时，即使“素食餐厅”是在很多轮之前偶然提及的，向量检索也能把它找回来。给人的感觉是Agent拥有“联想记忆”。
策略三（分层指令）：体验两极分化。当它正常工作时，对话非常流畅高效，Agent似乎能牢牢抓住重点。但当它“失灵”时，体验是灾难性的——Agent会完全忘记基本设定，需要用户不断重复。给人的感觉是与一个“有时靠谱有时失忆”的伙伴合作，可靠性存疑。

5.3 综合结论与选型建议

基于以上实验，我的结论是：没有一种策略是银弹，最佳选择取决于你的具体应用场景和优先级。

追求极致简单与低成本，且对话模式 predictable：选择策略一（规则摘要）。它实现简单，能有效对抗线性增长，适合任务导向型、步骤清晰的客服机器人或内部工作流助手。
追求最高智能性与可靠性，且资源允许：选择策略二（向量检索）。它是目前最健壮的方案，能有效处理话题跳跃和复杂查询，适合作为通用聊天助手、复杂问题分析工具或需要深度记忆的研究协作伙伴。
处于技术探索前沿，愿意为潜在收益承担风险：可以尝试策略三（分层指令），但绝不能单独使用。一个可行的方案是将其作为策略一或二的补充。例如，在用策略二检索出核心片段后，再用一个简短的、模型维护的<CoreMemory>来存储绝对核心的元信息（如最终目标），作为双重保险。

对我当前的项目而言，它是一个需要处理用户复杂、发散性需求的分析型Agent，因此我最终选择了**策略二（向量检索）**作为主力方案。同时，我借鉴了策略三的思想，在系统指令中加入了“请主动总结核心决策点”的引导，作为软性约束。这个组合方案在后续的实测中，在保持约60%压缩率的同时，任务完成率稳定在97%以上，达到了性能与成本的理想平衡。

6. 常见问题与排查技巧实录

在实际部署和优化上下文压缩策略时，我遇到了不少坑。这里记录下最典型的几个问题及其解决方法，希望能帮你绕开这些弯路。

6.1 向量检索效果不佳，召回不相关历史

问题现象：实现策略二后，发现有时候检索回来的历史片段与当前问题风马牛不相及，导致Agent的回答偏离主题。

排查与解决：

检查嵌入模型：首先确认使用的句子嵌入模型是否适合你的文本领域。all-MiniLM-L6-v2是通用模型，如果你的对话涉及大量专业术语（如医学、法律），使用在该领域微调过的嵌入模型（如BAAI/bge系列）效果会大幅提升。
优化分块大小：分块太大（如一整段长对话）会导致向量表征模糊，检索精度下降。分块太小（如单句）则会失去上下文，且增加检索开销。我的经验是，以“一个完整的语义单元”为块，例如一个问答对，或一个工具调用的描述+结果。通常令牌数在100-300之间比较合适。
尝试混合检索：纯语义检索（向量相似度）有时会漏掉关键词完全匹配但语义相似度不高的内容。可以结合稀疏检索（如BM25）。Chroma等数据库支持混合查询。你可以给向量相似度得分和BM25文本匹配得分赋予不同的权重，综合排序。这在查找具体名称、代号、编号时特别有效。
审视查询本身：用户的当前查询是否过于简短或模糊？例如，“那个怎么样？”这样的查询，向量表征的信息量极少。在这种情况下，可以尝试使用一个轻量级模型（如Haiku）将当前查询连同最近一两轮对话扩展成一个更完整的、信息丰富的查询语句，再用这个扩展后的语句去检索。

6.2 摘要导致信息失真或关键细节丢失

问题现象：使用策略一时，Agent经常忘记早先对话中确定的数字、时间等具体约束条件。

排查与解决：

强化实体保护规则：在摘要生成流水线中，增加一个“实体保护”步骤。使用NER模型识别出所有的时间、日期、百分比、货币、数量、人名、地名等实体。在最终摘要中，强制保留这些实体及其直接关联的谓语。例如，“预算为5000元”被摘要时，“5000元”这个实体必须连带“预算”一起保留。
采用差分摘要：不要每次都从头摘要整个历史。维护一个“基础摘要”和“增量更新”。每次只摘要最新的几轮对话，然后将这个“增量摘要”与之前的“基础摘要”融合。融合时，对于冲突的信息（如预算从5000改成了6000），以最新的增量为准。这比每次都处理全部历史更不容易丢失最新变更。
引入重要性评分：不要只用规则判断重要性。可以训练一个简单的二分类模型（或使用零样本分类），来判断一段文本是否包含“承诺”、“决定”、“约束”、“偏好”等关键信息。在摘要时，对这些高重要性文本进行保留或最小化压缩。

6.3 模型不遵循分层记忆指令（策略三）

问题现象：在策略三中，模型经常忽略更新<CoreMemory>的指令，或者更新的格式乱七八糟，无法被后续解析。

排查与解决：

强化指令与格式化：在系统指令中，不仅告诉模型要做什么，还要给出极其清晰的例子。提供2-3个完整的、多轮的对话示例，在示例中明确展示<CoreMemory>的初始状态、如何根据对话更新、以及更新后的格式。让模型通过Few-shot Learning来学习。
后处理与兜底：不要完全相信模型会完美输出。在代码中，编写一个健壮的解析器来尝试从模型回复中提取<CoreMemory>更新部分。如果解析失败，则启动一个兜底策略：要么使用一个本地摘要算法（如策略一）自动生成更新，要么在下一轮对话中，以用户身份温和地提醒模型：“看起来上一轮的核心记忆更新失败了，当前核心记忆仍然是XXX，根据我们刚才的对话，是否需要更新为YYY？”。
考虑模型能力：Claude 3 Haiku是能力相对较弱的模型。对于遵循复杂指令的任务，升级到Sonnet甚至Opus模型可能会大幅提升稳定性。但这会直接增加成本，需要权衡。在我的实验中，切换到Claude 3.5 Sonnet后，指令遵循率提升到了90%以上。

6.4 压缩后Agent出现“幻觉”或前后矛盾

问题现象：无论采用哪种策略，压缩后的上下文有时会导致Agent“捏造”一些历史中不存在的信息，或对已有信息做出矛盾的解读。

排查与解决：

这是压缩的固有风险：首先要接受，任何有损压缩都可能丢失信息，从而给模型的“脑补”留下了空间。我们的目标是降低其概率。
保留“否决性信息”：在压缩时，要特别留意那些“否定句”、“排除项”和“选择结果”。例如，“我们不去故宫”、“在A和B中选择了A”。这些信息一旦丢失，模型就可能反向脑补。在规则摘要或检索时，给这类信息赋予更高的权重。
在上下文中加入元提示：在发送给模型的压缩后上下文开头，可以加一句醒目的提示：“以下是根据对话历史生成的精简摘要，可能包含归纳信息。请严格基于摘要内容进行回答，如果对某些细节不确定，请主动询问用户确认。”这能在一定程度上约束模型的幻想倾向。
实施一致性检查：对于关键决策点，可以让Agent在输出中，以结构化方式（如JSON）复述一遍它理解的核心参数（如时间、地点、预算）。这既能验证它的理解是否正确，也能为用户提供一个纠正的机会。

上下文瘦身是一个平衡的艺术，永远需要在成本、性能和可靠性之间做取舍。我的经验是，从简单的规则摘要开始，如果发现它开始“失忆”，就逐步引入更智能的向量检索组件。最重要的是，建立一套像本章节所述的监控和测试机制，持续观察压缩策略在你的特定场景下的表现，并准备好随时调整和优化。