[Alan の手札] OpenClaw 成本与上下文优化方案(2026-03-26)

OpenClaw 成本与上下文优化方案-复盘（2026-03-26）

目标：基于当前 OpenClaw 实际配置，输出一份“先审计、后变更、可回滚”的优化方案，重点解决上下文膨胀、模型成本偏高、会话噪音累积与运行时数据卫生问题。
本文档当前为 方案版，不直接改配置；如确认执行，再按本文补丁逐项落地。

1. 执行摘要

当前系统已经做对了几件事：

已关闭 heartbeat
已开启 context pruning
已启用 compaction / memory flush
当前会话缓存命中率较高

但核心高成本问题仍然存在：

默认模型仍统一使用 openai-codex/gpt-5.4
main / code / writer 未做 agent 级模型分层
context pruning 仍偏保守
QMD session memory 仍可能把历史会话带回检索面
启动上下文文件存在重复职责
本地 logs / browser / session 数据堆积明显

结论

如果只做最小收益最大的动作，建议按以下顺序推进：

模型分层：给 main / code / writer / cron / 轻任务配置不同默认模型
上下文修剪增强：把 pruning 和 compaction 再收紧一档
QMD session recall 降噪：缩短 retention，必要时关闭 sessions recall
启动文件去重：收敛 SOUL / IDENTITY / TEAM / AGENTS / CONTEXT 的重复内容
运行时数据卫生：清理 logs / browser / 旧 sessions / 冗余备份

2. 当前观测（基于现场配置）

2.1 当前关键配置

默认模型：openai-codex/gpt-5.4
Agent 数量：3（main / code / writer）
heartbeat：全部关闭
contextPruning：已启用

mode: cache-ttl
ttl: 1h
keepLastAssistants: 6
softTrim.maxChars: 12000
hardClear.enabled: true

compaction.memoryFlush：已启用

softThresholdTokens: 90000
forceFlushTranscriptBytes: 2mb

QMD memory：已启用

includeDefaultMemory: true
sessions.enabled: true
retentionDays: 14

2.2 当前运行状态

新 direct 会话基线大约仍在 13k tokens
旧主会话可累积到 89k tokens
当前会话缓存命中已较高，但默认模型成本仍高

2.3 本地数据规模

~/.openclaw/logs：约 3.0G
~/.openclaw/browser：约 710M
~/.openclaw/agents：约 38M
session 文件数量：约 59
各 agent sessions：

main: ~15M
writer: ~8.2M
code: ~4.1M

2.4 结构层面的额外信号

工作区内存在大量其他工具/兼容层的 skills/ 镜像目录，例如：

.claude/skills/*
.cursor/skills/*
.roo/skills/*
.continue/skills/*
.qwen/skills/*
.windsurf/skills/*
等

这些不一定直接进入 OpenClaw 主上下文，但会增加工作区复杂度、扫描负担和后续维护噪音。

3. 问题分解与根因

3.1 默认模型未分层

根因

当前所有 agent 默认共用 openai-codex/gpt-5.4。

影响

简单问答也使用高价模型
cron / 检查 / 轻分析没有降级通道
“角色拆分”已做，但“成本拆分”未做

现象

即使已经有较好的缓存命中，单次请求的成本上限仍高。

3.2 上下文修剪有，但力度还不够

根因

当前 pruning / compaction 已启用，但阈值偏保守：

keepLastAssistants 偏多
softTrim 仍保留较多字符
compaction 启动较晚

影响

新会话基线仍偏高
老会话仍容易累计到较大上下文
缓存虽然有帮助，但上下文体积本身仍偏大

3.3 QMD session memory 可能引入历史噪音

根因

memory.qmd.sessions.enabled = true 且保留 14 天。

影响

历史会话中的工具输出、失败记录、重复讨论可能进入检索候选
recall 面变宽，质量不一定更高
容易把“短期会话痕迹”误当成“长期有价值记忆”

3.4 启动注入文件有重复职责

当前文件角色存在重叠

SOUL.md 与 IDENTITY.md：人格/身份信息重叠
AGENTS.md 与 TEAM.md：团队分工/调度规则重叠
MEMORY.md 与 CONTEXT.md：启动入口与热记忆职责重叠

影响

启动 prompt 存在重复信息
指令层冗余增加
维护成本高，未来更容易出现冲突

3.5 运行时数据卫生不足

根因

logs / browser / sessions / 旧备份持续累积。

影响

本地磁盘占用高
排障噪音大
归档与备份成本增加
会话/检索治理更难做精细化

4. 优化目标

本次优化目标拆成四类：

4.1 成本目标

让简单任务不再默认走顶配模型
让轻任务、定时任务、后台检查优先走小模型

4.2 上下文目标

降低新会话基线 token
降低老会话累积速度
避免 session recall 把短期垃圾带回 prompt

4.3 可靠性目标

保留重要 persona / 规则 / 记忆能力
避免为了省钱把关键行为搞坏

4.4 运维目标

让工作区结构更清晰
降低 logs / browser / sessions 的维护成本

5. 方案设计：A / B / C 三档

方案 A：最小改动版（推荐先做）

目标

只做最高 ROI、风险最低的调整。

包含项

给 agent 做默认模型分层
收紧 context pruning 一档
缩短 QMD sessions retention
清理运行时大文件（logs / browser / 旧 session）

预期收益

成本下降明显
行为风险较低
不需要大规模改工作区结构

风险

个别轻任务如果路由到过小模型，回答质量可能下降
pruning 更 aggressive 后，超长对话回溯能力会下降一些

方案 B：平衡优化版（推荐作为主方案）

目标

在方案 A 基础上，把启动文件和记忆结构一起收敛。

包含项

方案 A 全部内容
精简 IDENTITY.md
将 CONTEXT.md 缩成跳转说明，弱化其启动地位
合并 TEAM.md 与 AGENTS.md 的重复规则段
复查 workspace 中镜像 skills 目录是否需要迁移归档

预期收益

成本与上下文双下降
规则层更干净
后续维护明显更轻松

风险

改动面比方案 A 略大
如果收敛文档不谨慎，可能影响既有工作流

方案 C：激进省钱版

目标

把“省钱”放第一优先级。

包含项

方案 B 全部内容
关闭 QMD sessions recall
进一步降低 compaction / pruning 阈值
将更多任务默认降到小模型
更积极清理旧 sessions / browser 数据

预期收益

成本下降最大
上下文明显更轻

风险

记忆召回能力可能明显下降
某些复杂任务需要更频繁手动切回大模型

6. 推荐方案

7. 具体改动提案（不直接执行）

7.1 提案一：模型分层

建议目标

按“任务性质 + agent 角色”双维度做分层。

建议原则

main：默认中档；复杂分析再升级
code：默认中高档；重构/复杂调试再升级
writer：默认中档；成稿润色/高要求表达再升级
cron / 检查 / 心跳 / 简单通知：默认小模型

7.2 提案二：收紧 context pruning

当前

ttl: 1h
keepLastAssistants: 6
softTrim.maxChars: 12000
softThresholdTokens: 90000

建议方向

建议值（平衡版）

keepLastAssistants: 6 -> 4
softTrim.maxChars: 12000 -> 8000~10000
softThresholdTokens: 90000 -> 60000~70000
ttl: 视会话体验，评估是否从 1h 收到 30m~45m

预期收益

降低上下文累积速度
降低老会话在 70k~100k token 区间长期停留的概率

风险

超长对话中，早期细节更容易被裁掉

回滚

恢复原阈值即可

7.3 提案三：QMD session recall 降噪

当前

sessions.enabled: true
retentionDays: 14

建议分两步

第一步（推荐）

保留 sessions.enabled: true
将 retentionDays: 14 -> 5~7

第二步（可选）

如果发现 recall 噪音仍高：

关闭 sessions.enabled
只保留 memory 文件体系的长期记忆

预期收益

降低历史会话干扰
提高 recall 质量稳定性
降低检索噪音

风险

某些“前几天聊过但没写 memory 文件”的内容更难召回

回滚

把 retention 恢复到 14 天，或重新启用 sessions recall

7.4 提案四：启动文件去重收敛

当前重复点

SOUL.md vs IDENTITY.md
AGENTS.md vs TEAM.md
MEMORY.md vs CONTEXT.md

建议收敛方式

处理建议

IDENTITY.md：缩成最小身份标签，或并入 SOUL.md
CONTEXT.md：保留为兼容文件，但正文改成“去 MEMORY.md / memory/core.md”，不再承载太多活跃状态
TEAM.md：只保留团队协作总览；具体调度规则归 AGENTS.md

预期收益

减少重复注入
降低规则冲突概率
后续维护简单很多

风险

如果删得过快，某些旧工作流可能临时不适配

回滚

所有文件先备份再改；必要时恢复原版

7.5 提案五：运行时数据卫生

当前重点对象

~/.openclaw/logs ≈ 3.0G
~/.openclaw/browser ≈ 710M
agent sessions 若干
大量历史备份文件

建议动作

建议清理优先级

清理过旧 logs
评估 browser profile 是否可瘦身/重建
清理久未使用的 session 文件
归档或删除冗余 openclaw.json.bak*

预期收益

磁盘占用下降
维护负担减轻
运行环境更干净

风险

删除 logs 后，旧问题排障证据会减少
重建 browser profile 可能会丢失一些登录状态

回滚

删除前先打包归档到压缩包或 quarantine 目录

7.6 提案六：工作区镜像 skills 目录归档

当前情况

workspace 里有大量非 OpenClaw 主技能目录的镜像 skills 目录。

建议

建立一个明确的归档区，如 workspace/_archives/tool-skill-mirrors/
将不参与主系统运行的外部兼容层技能迁入归档
保持 workspace/skills/ 只放真正要给 OpenClaw 用的技能

预期收益

降低目录噪音
降低后续排查时的误判成本
结构更清晰

风险

某些外部工具若依赖这些目录，迁移后需要同步调整它们自己的配置

回滚

原路径恢复即可

8. 推荐实施顺序

第一阶段：只做高 ROI、低风险

agent 模型分层
pruning / compaction 收紧一档
QMD sessions retention 从 14 天降到 7 天

第二阶段：做结构收敛

精简 IDENTITY.md
缩减 CONTEXT.md
合并 TEAM.md / AGENTS.md 重复内容

第三阶段：做运行时清理

清理 logs
清理旧 sessions
评估 browser profile 瘦身
归档镜像 skills 目录

9. 验证方案

每完成一阶段，都建议用 新会话 验证，而不是在旧会话里凭感觉判断。

核心验证指标

新会话基线 token 是否下降
简单问题是否仍能稳定回答
复杂问题是否仍能维持质量
记忆召回是否出现明显退化
是否出现规则丢失/人格异常/调度异常

建议观察项

prompt tokens
cached tokens / cache hit
响应速度
recall 质量
main / code / writer 各 agent 体验差异

10. 回滚原则

所有优化按以下原则执行：

一次只改一类配置
每次变更前先备份
每次变更后用新 session 验证
任意异常，先回滚再分析

最小回滚单元

模型分层：可逐 agent 回滚
pruning：可逐参数回滚
memory recall：可逐项恢复 retention / sessions.enabled
文件收敛：可直接恢复旧版 md 文件
数据清理：先归档、后删除

11. 最终建议

如果只给一句执行建议：

先做“模型分层 + pruning 收紧 + QMD session recall 降噪”，再做“启动文件去重”，最后做“logs/browser/session 清理”。

这是当前这套 OpenClaw 配置下，收益最大、风险可控、回滚也最简单的路线。

12. 已执行变更：模型分层（2026-03-25）

已按当前决策完成第一轮模型分层落地。

已应用的 agent 分层

main → openai/gpt-5-mini
code → openai-codex/gpt-5.4
writer → openai/gpt-5.4-mini

已加入 allowlist / models 的模型

openai/gpt-5-mini
openai-codex/gpt-5.4
openai/gpt-5.4-mini
openai/gpt-4o-mini

当前全局默认

agents.defaults.model.primary 已改为 openai/gpt-5-mini

说明

本轮已经把三类主 agent 的默认模型拆开。

其中：

main 的默认模型已经降到日常档
code 继续保留工程稳定档
writer 使用较轻但质量仍较高的写作档

“轻任务 / 后台 → openai/gpt-4o-mini” 目前已加入可用模型池，但还没有单独做自动路由规则。也就是说：

现在它已经可以作为后续轻任务路由目标使用
但是否自动用于 cron / 后台 / heartbeat，仍需下一轮再补具体路由策略

备份与校验

备份文件：~/.openclaw/openclaw.json.bak-model-layering-20260325-1129
配置校验：已通过 openclaw config validate

已执行变更：pruning 收紧 + QMD session recall 降噪

已完成一轮最小可回滚的上下文治理 patch：

context pruning

ttl: 1h -> 45m
keepLastAssistants: 6 -> 4
softTrim.maxChars: 12000 -> 9000

compaction / memory flush

softThresholdTokens: 90000 -> 65000

QMD sessions recall

retentionDays: 14 -> 7

本轮意图

让旧上下文更早进入修剪窗口
降低长会话继续膨胀的速度
收窄 QMD sessions recall 的时间面，减少历史噪音带回 prompt 的概率

本轮备份

~/.openclaw/openclaw.json.bak-pruning-qmd-tune-20260325-1423

后续建议

下一步建议继续做两件事：

为轻任务 / 后台任务补单独路由策略，使 openai/gpt-4o-mini 真正自动吃到轻任务
观察一到两个新 session，确认：

main 是否已稳定走 gpt-5-mini
writer 是否已稳定走 gpt-5.4-mini
code 是否仍保持预期质量

轻任务路由结论（当前版本）

本轮检查后，**未发现一个明确、稳定、官方推荐的“全局轻任务模型开关”**可直接把后台/轻任务统一切到某个模型。

因此更稳的落地方式是：

方案 1：保守版

保持当前 main / code / writer 三 agent 分层不变
轻任务由 main 继续承接
在未来的 cron / 自动化任务定义中，显式指定轻任务走单独 agent 或单独模型

方案 2：推荐版

新增一个专门处理轻任务/后台任务的 agent，例如：

light → openai/gpt-4o-mini

由它承接：

cron
后台检查
简短通知
简单总结
低风险自动化动作

这样做的好处：

路由清晰
成本边界清晰
不会污染 main 的默认模型策略
后续如果要把 cron、watch、heartbeat、后台 worker 切过去，也更容易

当前建议：如果要真正把 openai/gpt-4o-mini 用起来，最稳方案是新增一个 light agent，而不是硬找一个不存在的“轻任务全局路由键”。

已执行变更：新增 `light` agent

已完成以下落地：

新增 agent：light
模型：openai/gpt-4o-mini
workspace：/Users/xulanzhong/.openclaw/workspace-light

当前四类 agent 分层

main → openai/gpt-5-mini
code → openai-codex/gpt-5.4
writer → openai/gpt-5.4-mini
light → openai/gpt-4o-mini

本次新增的备份

~/.openclaw/openclaw.json.bak-add-light-agent-20260325-1139

下一步

后续要想让这次分层真正完整生效，需要把以下任务逐步路由到 light：

cron
后台检查
简短通知
短摘要
低风险自动化任务

当前这一步已经把基础结构搭好，但“具体哪些任务交给 light”还需要在后续 cron / 自动化定义里继续接入。

已执行变更：cron 重构

已将原先单条、偏重、易超时的 daily-memory-hygiene 重构为两条：

1) 每日轻检查

名称：daily-memory-check
agent：light
模型：openai/gpt-4o-mini
时间：每天 04:00
特征：

只读 MEMORY.md、memory/topics/cron-jobs.md、最近 1 天 daily memory
只做增量检查
不做大规模合并
不改 OpenClaw / QMD 配置
输出控制为极简摘要

2) 每周深整理

名称：weekly-memory-hygiene
agent：code
模型：openai-codex/gpt-5.4
时间：每周日 04:30
特征：

读取最近 7 天 daily memory + topics
承担长期信息合并、去重、专题沉淀
保留原来的深整理职责，但降低执行频率

这样拆分后的收益

每日任务更轻，显著降低超时风险
light agent 真正开始承接轻任务
深整理仍保留在 code，避免能力不足带来记忆误治理
后台任务分层开始真正落地，而不只是停留在 agent 配置层

13. 收官验收

本节记录本轮“成本 + 上下文 + 后台治理”优化的最终落地状态与可验证指标。

13.1 模型分层（Codex OAuth 口径）

由于当前鉴权方式为 OpenAI Codex OAuth，生产可用模型以 openai-codex/* 为准。

全局默认（agents.defaults.model.primary）：openai-codex/gpt-5.2
main：openai-codex/gpt-5.2
code：openai-codex/gpt-5.4
writer：openai-codex/gpt-5.4-mini
light：openai-codex/gpt-5.4-mini

13.2 上下文修剪（pruning/compaction）

contextPruning.ttl：45m
contextPruning.keepLastAssistants：4
contextPruning.softTrim.maxChars：9000
compaction.memoryFlush.softThresholdTokens：65000

13.3 QMD session recall 降噪

memory.qmd.sessions.enabled：true
memory.qmd.sessions.retentionDays：7

13.4 cron 重构（轻/重拆分）

当前 cron 共 2 条：

daily-memory-check

agent：light
model：openai-codex/gpt-5.4-mini
timeoutSeconds：480
最近一次手动验证：成功（约 33 秒）

weekly-memory-hygiene

agent：code
model：openai-codex/gpt-5.4
timeoutSeconds：1200
已收敛为“每周增量整理版”（最近 3 天真正 daily + topics）

13.5 启动文件去重（最小改动版）

已精简：

IDENTITY.md
CONTEXT.md（降级为兼容占位，指向分层记忆入口）
TEAM.md（精简为结构 + 最小调度规则）并已生成对应 .bak-dedupe-* 备份。

13.6 运行时数据清理（保守版）

logs：~/.openclaw/logs 约 3.0G → 263M（归档压缩 + 截断）
browser：~/.openclaw/browser/openclaw/user-data 约 710M → 152M（清缓存）
sessions：清理 >14 天旧文件，session 文件数 59 → 35
配置备份：归档到 ~/.openclaw/config-archive/

14. 下一步建议（可选）

14.1 新会话验收

建议新开一个 session，观察：

基线 token 是否下降
pruning 是否更早触发
recall 是否更干净（尤其是 sessions retention 缩短后的效果）

14.2 可选修复：tools.profile allowlist 警告

网关日志提示 tools.profile (coding) allowlist contains unknown entries (...)。这不影响当前优化主线，但可以作为后续一次性清理项（对齐工具配置）。

附：本次方案聚焦的优化点清单

[x] 默认模型未分层
[x] agent 级模型未拆分
[x] pruning 收紧
[x] QMD session recall 降噪
[x] cron 轻/重拆分并落地到 light
[x] 启动文件去重
[x] logs/browser/sessions 清理

OpenClaw 成本与上下文优化方案-复盘（2026-03-26）

1. 执行摘要

结论

2. 当前观测（基于现场配置）

2.1 当前关键配置

2.2 当前运行状态

2.3 本地数据规模

2.4 结构层面的额外信号

3. 问题分解与根因

3.1 默认模型未分层

根因

影响

现象

3.2 上下文修剪有，但力度还不够

根因

影响

3.3 QMD session memory 可能引入历史噪音

根因

影响

3.4 启动注入文件有重复职责

当前文件角色存在重叠

影响

3.5 运行时数据卫生不足

根因

影响

4. 优化目标

4.1 成本目标

4.2 上下文目标

4.3 可靠性目标

4.4 运维目标

5. 方案设计：A / B / C 三档

方案 A：最小改动版（推荐先做）

目标

包含项

预期收益

风险

方案 B：平衡优化版（推荐作为主方案）

目标

包含项

预期收益

风险

方案 C：激进省钱版

目标

包含项

预期收益

风险

6. 推荐方案

推荐：先执行 方案 B（平衡优化版）

7. 具体改动提案（不直接执行）

7.1 提案一：模型分层

建议目标

建议原则

推荐落地方式

最小版

预期收益

回滚

7.2 提案二：收紧 context pruning

当前

建议方向

建议值（平衡版）

预期收益

风险

回滚

7.3 提案三：QMD session recall 降噪

当前

建议分两步

第一步（推荐）

第二步（可选）

预期收益

风险

回滚

7.4 提案四：启动文件去重收敛

当前重复点

建议收敛方式

处理建议

预期收益

风险

回滚

7.5 提案五：运行时数据卫生

当前重点对象

推荐：先执行方案 B（平衡优化版）

已执行变更：新增 `light` agent