1. 长任务Agent开发的上下文困境
作为一名长期从事Agent开发的工程师,我深刻理解处理长任务时的痛点。当Agent执行代码调试、文档解析这类需要多轮交互的任务时,最让人头疼的就是上下文窗口溢出问题。模型突然报错"上下文过长",或者更糟的是Agent开始"失忆"——重复读取已经处理过的文件,再次踩进之前已经解决的坑,甚至忘记了工作区的基本规则。
这种问题在传统聊天场景中并不突出,因为普通对话的上下文相对简单。但在Agent开发中,上下文不仅包含对话历史,还包括:
- 工具调用结果(如文件内容、命令输出)
- 失败日志和调试信息
- 工作区配置文件(如AGENTS.md)
- 必须保持的操作上下文状态
我曾尝试过简单的摘要方案来解决窗口溢出问题,结果发现关键信息丢失得更快。模型生成的摘要往往会过滤掉那些看似不重要但实际上决定任务走向的细节。这正是OpenClaw社区近期讨论的核心议题——上下文成本直接决定了Agent能否完成长任务。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. OpenClaw的上下文治理框架
2.1 核心概念解析
在深入OpenClaw的解决方案前,我们需要明确几个关键概念,这些定义来自官方文档,是理解后续设计的基础:
-
上下文(Context)
- 模型单次调用可见的全部内容
- 包括:系统提示词、对话历史、工具调用及结果、附件、压缩产物
- 可通过
/context list查看具体构成 - 注意:不同于"记忆",上下文是窗口内的临时内容
-
压缩(Compaction)
- 将较早历史总结后写回会话
- 持久化到session的JSONL记录
- 后续请求看到的是"摘要+最近几轮原始消息"
-
会话修剪(Session Pruning)
- 仅在内存中临时修剪旧的tool result
- 不修改磁盘上的JSONL历史
- 仅影响工具结果消息,用户和助手消息保持不变
-
对话记录清理(Transcript Hygiene)
- 按模型提供商规则做内存修正
- 包括:工具调用ID清理、配对修复、轮次排序
- 满足接口格式要求,不重写磁盘记录
-
固定执行链路
- 窗口预检→历史卫生→配对修复→压缩重试→超时快照→溢出恢复
- 将上下文治理设计为可恢复的状态机
2.2 三类膨胀源分析
OpenClaw将Agent上下文问题归类为三种膨胀源,这比普通聊天产品的问题更复杂:
-
旧轮次堆积
- 用户与Agent的对话轮次持续增加
- 早期消息占用窗口空间
- 示例:调试会话可能持续数十轮
-
旧工具结果膨胀
- read_file、bash、browser等工具返回的大段内容
- 是占空间的主要来源
- 示例:读取一个500行的配置文件
-
单条超大输出
- 一次命令打印数万字符
- 读取超长文件
- 单次调用就可能刺穿窗口
- 示例:执行
ls -R列出整个目录树
2.3 信息保真等级
OpenClaw根据信息的重要性将其分为三个保真等级,并匹配不同的治理策略:
| 保真等级 | 内容类型 | 处理策略 |
|---|---|---|
| 高 | 最近短期记忆、工具调用配对 | 绝对保留 |
| 中 | 文件读写历史、工具失败记录 | 结构化摘要 |
| 低 | 旧轮次对话、已完成任务的细节 | 可完全删除 |
3. 三层渐进式治理架构
OpenClaw的核心创新在于其三层渐进式治理架构,从预防到恢复,层层兜底。
3.1 第一层:预防性裁剪
这一层的目标是在调用LLM前做轻量处理,避免进入昂贵的摘要流程。
3.1.1 历史轮次限制
- 从消息尾部保留最近N轮用户消息及后续链路
- 关键点:截断必须落在完整的user turn边界
- 避免拆分
user->assistant->tool_result的完整链路
3.1.2 工具结果修剪
- 渐进式处理旧tool result
- 两档处理:软裁剪和硬清理
- 三个保护规则:
- 第一条用户消息前的工具结果不修剪
- 最近3条assistant关联的tool result不动
- 图片类结果不修剪
- 支持工具黑白名单
- 修剪带5分钟TTL,与Anthropic的prompt cache周期对齐
3.1.3 单条tool result截断
- 硬边界设置:
- 单条结果最多占窗口30%
- 绝对上限400,000字符
- 超过后截断并提示模型"可按offset/limit继续读取"
3.2 第二层:精细化压缩
当预防性裁剪不足时,启动这个包含8个步骤的压缩流水线。
3.2.1 压缩流程详解
-
压缩前记忆刷新
- 静默执行Memory Flush
- 将关键状态写入磁盘(如memory/YYYY-MM-DD.md)
-
收集关键事实
- 整理必需信息:读/改过的文件、工具失败记录、工作区规则
-
历史预裁剪
- 对超大内容做chunk拆分
- 丢掉最老块并单独摘要
-
配对修复
- 修复tool_use/tool_result的配对关系
- 按提供商规则处理
-
分段摘要合并
- 将消息按token拆分为多个chunk
- 逐段摘要后再做"摘要的摘要"
-
自适应chunk大小
- 根据平均消息体积动态调整chunk比例(40%→15%)
- 加1.2倍安全系数
-
三级降级兜底
- 全量摘要失败→剔除超大消息再摘要→返回兜底说明
-
结构化补丁+安全隔离
- 补加Tool Failures等结构化内容
- 避开toolResult.details等不可信字段
3.2.2 记忆系统设计
OpenClaw的记忆系统采用三层架构:
- 上下文:短期工作记忆
- 磁盘:
- 每日日志(memory/YYYY-MM-DD.md)
- 可选长期记忆(MEMORY.md)
- 向量索引:BM25 + 向量的混合搜索
3.3 第三层:溢出恢复
成熟的系统需要假设前两层可能失败,因此设计了专门的恢复链路。
3.3.1 恢复流程
-
双端溢出检测
- 提交阶段被provider拒绝(请求前)
- 生成过程中返回过长错误(请求中)
-
有序兜底流程
- SDK自动压缩重试(最多3次)
- 持久级tool result截断
- 提示用户/reset或切换大窗口模型
-
超时快照回滚
- 压缩超时回到压缩前的干净快照
- 避免半压缩的"脏状态"暴露
-
Branching重写
- 持久级截断不原地修改历史
- 从父节点拉新分支追加内容
- 保留session的append-only语义
4. 工程设计的四个关键判断
OpenClaw的成功不仅在于技术细节,更在于其符合大模型Agent工程化的核心判断。
4.1 渐进式降级优于一次性摘要
- 轻量操作优先(限制轮次、修剪)
- 重操作后置(压缩、截断)
- 避免过早将原始信息变成不可逆的二手信息
4.2 保护不变量而非逐字保留
- 守住五个核心不变量:
- 最近短期记忆
- 工具调用配对
- 文件读写历史
- 工具失败记录
- 工作区规则
- 优先保证运行正确性,而非阅读流畅度
4.3 与Provider Cache协同设计
- 修剪TTL与Anthropic的cacheRetention对齐
- Heartbeat保温机制保持缓存"温热"
- 避免频繁改写历史打碎cacheRead前缀
4.4 摘要失败宁可不做
- API报错、流程异常时直接cancel压缩
- 保留原始历史
- 坏摘要比没摘要更危险
5. 实战技巧与核心参数
5.1 六个可直接复用的技巧
-
拆分上下文问题
- 明确区分三类膨胀源
- 针对性治理
-
工具结果渐进式修剪
- 分软裁剪、硬清理两档
- 保留关键部分
-
设短期记忆保护区
- 保护最近几轮对话和工具结果
- 不盲目为省token删除决策依据
-
压缩输出加结构化补丁
- 补回失败记录、文件读写痕迹、工作区规则
-
设计溢出恢复链路
- 重试→压缩→截断→提示重置的顺序兜底
-
历史修改版本化
- 持久化修改用branch思路
- 不原地覆盖,保留可审计性
5.2 八个核心配置参数
| 参数 | 说明 | 建议值 |
|---|---|---|
| max_user_turns | 保留的用户轮次 | 10-20 |
| tool_result_ttl | 工具结果保留时间 | 300s |
| max_single_result | 单条结果最大长度 | 400,000 |
| compaction_threshold | 触发压缩的阈值 | 0.8 * window_size |
| min_chunk_size | 最小摘要chunk大小 | 500 tokens |
| max_compaction_retries | 最大压缩重试次数 | 3 |
| protected_tool_classes | 受保护的工具类型 | ["file_reader"] |
| heartbeat_interval | 缓存保温心跳间隔 | 60s |
可通过/status查看上下文使用情况,/usage tokens追踪消耗。
6. 与Dakou方案的对比
近期Dakou提出的七大策略与OpenClaw在"上下文管理是系统工程"上达成共识,但设计侧重点不同:
| 维度 | OpenClaw | Dakou |
|---|---|---|
| 设计目标 | 单Agent长任务稳定性 | 多Agent协作灵活性 |
| 核心优势 | 工程稳定性、Provider生态协同 | 可视化锚定、工具动态扩展 |
| 适用场景 | 需要长时间稳定运行的Agent | 需要快速组装的临时Agent群 |
| 学习曲线 | 较高,需要理解完整治理链路 | 较低,模块化设计 |
选择建议:
- 需要运行数小时以上的复杂任务 → OpenClaw
- 快速构建临时性多Agent协作 → Dakou
7. 上下文治理的核心原则
基于OpenClaw的设计经验,我总结出三个适用于所有大模型Agent的核心原则:
-
分层治理,渐进兜底
- 从轻量到重度设计多级处理
- 每一步都有备选方案
- 避免单点失效导致系统崩溃
-
保真优先,结构为王
- 识别并保护关键不变量
- 会话结构完整性比压缩率更重要
- 避免Agent因信息丢失而失控
-
工程化设计,兼顾生态
- 匹配模型接口规则
- 考虑Provider缓存计费机制
- 设计完善的监控和恢复能力
在实际开发中,与其追求完美的摘要prompt,不如先实现这套"渐进式降级+结构化保真+失败可恢复"的工程方案。毕竟,能稳定完成长任务的Agent,才是真正有价值的Agent。
