openclaw.json 优化实战：从 132KB 到 40KB 的配置审计全过程

224 个 Agent 缩减到 25 个，contextPruning 从关闭到自动，踩坑与决策全记录

2026-08-18 约 2882 字预计阅读 6 分钟

/images/Code-Art-Studio-images/openclaw-config-optimization-audit/openclaw-config-optimization-audit.webp

2026-05-10 晚，我对自己维护的 OpenClaw 实例做了一次彻底的配置审计。対象是 /home/administrator/.openclaw/openclaw.json——一个 132KB、4101 行的 JSON 文件。

做这次审计，是因为前一周刚清理过一次配置，可文件体积很快又涨了。我想知道：到底什么东西在悄悄膨胀？哪些配置其实从未被使用？有没有一眼看不出来的隐患？

最终结果是：清理出 5 项变更、4 项确认不变，配置文件体积和解析效率都得到明显改善。

一、审计概览

在开始之前，先明确审计范围：

文件大小：132KB / 4101 行
JSON 格式：有效（没有语法错误）
lastTouchedVersion：2026.5.7
分析时间：2026-05-10 22:54 ~ 23:34（约 40 分钟）

二、P0 问题

Agent 数量严重膨胀

症状：打开 agents.list，映入眼帘的是 224 个 agent。但日常实际在用的只有约 25 个。

根因：安装 agency-orchestrator 后，系统自动注册了 180+ 个模板 agent，涵盖 marketing-、engineering-、design-、academic-、game-、unity-、roblox-* 等系列。这些模板从未被调用，却一直占据配置文件。

影响：

配置文件解析时间增加
维护复杂度提高
每次 openclaw doctor / openclaw config validate 都要遍历全部 224 个条目

决策：✅ 立即清理。将 agents.list 从 224 个缩减到约 25 个实际使用的 agent。

清理后的实际在用 agent 包括：main、chief-yuntian、scout-yuntianhuo、writer-yuntianfeng、editor-yuntianyue、oc-engineer、oc-inspector、agent-ops、factory-architect、skill-factory、kb-writer、debt-rebirth-oklife、pub-yuntianxing、design-yuntianguang、audio-yuntianlai、marketing-content-creator、testing-evidence-collector、testing-tool-evaluator、agents-orchestrator、engineering-wechat-mini-program-developer、prompt-engineer。

经验：agency-agents 模板会大幅膨胀配置文件。安装 agency-orchestrator 后，配置体积从 ~40KB 膨胀到 132KB，应定期清理。

open_id 拼写疑云

症状：在 channels.feishu.accounts.oc-engineer.allowFrom[3] 中发现一个 open_id：

ou_bb7511e25xxxd752

而顶层和其他 account 中的值是：

ou_bb7514e25xxxd752

第 3 位和第 4 位数字不同：7511 vs 7514。

排查过程：飞书 open_id 是 38 位字符串，肉眼很难分辨中间几位差异。我逐字符比对后发现，确实只有两位不同。

决策：✅ 不是错误，保持不变。ou_bb7511... 是正确的 open_id，与顶层值不同是正常的多账号场景。

教训：飞书 open_id 需要逐字符比对。这种两位差异的字符串，肉眼检查几乎不可能发现，必须用工具或代码比对。

三、P1 问题：配置细节优化

3.1 plugins.allow 白名单

现状：白名单 49 个，实际启用 46 个。

未启用的 3 个（有意禁用）：

google（搜索）
lmstudio（本地推理）
openclaw-qqbot（与 feishu 冲突）

分析：46 个已启用插件中，约 20+ 个与当前核心业务无关（语音类 8 个、图像/视频生成 3 个、搜索/嵌入 2 个、本地推理 4 个等）。

决策：后续根据实际需要慢慢禁用，暂不处理。原则：不主动禁用任何已启用插件。

3.2 session.maxDiskBytes 偏小

原始配置：

"session": {
    "maintenance": {
        "mode": "warn",
        "pruneAfter": "7d",
        "maxEntries": 50,
        "maxDiskBytes": "200mb",
        "resetArchiveRetention": "30d"
    }
}

问题：5 月 8 日分析显示 main agent 单个 session 就占了 281MB（超预算 34%）。

决策：✅ 修改为 "1gb"。

修改后配置：

"session": {
    "maintenance": {
        "mode": "warn",
        "pruneAfter": "7d",
        "maxEntries": 50,
        "maxDiskBytes": "1gb",
        "resetArchiveRetention": "30d"
    }
}

3.3 compaction 配置：reserveTokens 可能过高

现状：reserveTokens(24000) + keepRecentTokens(48000) = 72K 保留。

分析：对 LongCat-2.0-Preview（1M 上下文）不是问题，但对 fallback 模型（如 qwen2.5-7b，81920 上下文）可能触发过早 compaction。

决策：暂不调整。当前主路模型 1M 上下文足够大。

3.4 contextPruning 处于关闭状态

contextPruning 模式演进图：off → auto → cache-ttl 三阶段时间线，标注每个阶段的问题和触发原因

原始配置：

"contextPruning": {
    "mode": "off",
    "ttl": "1h",
    "keepLastAssistants": 3
}

问题：关闭状态导致长会话 token 消耗持续增长，历史上下文不会被自动裁剪。

决策演进：

风哥先修改为 mode: "auto"
后又手动改为 mode: "cache-ttl"（最终值）

最终配置：

"contextPruning": {
    "mode": "cache-ttl",
    "ttl": "1h",
    "keepLastAssistants": 3
}

教训：contextPruning 的 mode 经历了 off → auto → cache-ttl 的演进，说明配置模式需要根据实际运行效果逐步调优，不能一蹴而就。

四、P2 问题：配置细节微调

4.1 plugins.bundledDiscovery 仍为 compat 模式

原始配置："bundledDiscovery": "compat"

问题：compat 模式下 bundled provider 用 legacy 模式发现，可能与 allowlist 冲突。

决策：✅ 修改为 "allowlist"。

4.2 proxy 配置存在但禁用

现状："enabled": false，配置保留无害。

决策：✅ 保留不动。知道怎么用，需要时再启用。

4.3 QQ Bot default account 缺少 enabled 字段

现状：default account 没有 enabled 字段，而 chief-yuntian 和 oc-engineer 都有。

决策：✅ 禁止修改。这是踩坑修复后的正确状态，任何情况下不要动。

⚠️ 重要：这是踩坑修复后的状态，不是遗漏。如果看到某个配置“看起来少了字段”，先确认是不是修复后的状态，再决定要不要补。

4.4 narrative-designer 的 id 和 name 相同

原始配置："name": "narrative-designer"（与 id 相同）

决策：✅ 修改为 "name": "叙事设计师"。name 应该对人类友好，而不是重复 id。

五、模型配置分析

5.1 Providers（8 个）

Provider	状态	模型数	说明
longcat	✅	4	主力 provider
llama8081	✅	4	本地 Qwen 系列
bailian	✅	3	deepseek-v3.2, MiniMax-M2.5, glm-5.1
zai	✅	2	glm-5.1, glm-4.7-flash
nvidia-glm5	✅	1	glm5
nvidia-kimi2-5	✅	1	kimi-k2.5
nvidia	✅	1	minimax-m2.5
lmstudio	❌ disabled	2	本地推理，有意禁用

5.2 Fallback 链（12 个）

当前 fallback 链共有 12 个模型，按优先级排列如下：

LongCat-2.0-Preview
LongCat-Flash-Thinking-2601
LongCat-Flash-Chat
LongCat-Flash-Lite
nvidia-glm5
zai/glm-4.7-flash
nvidia-minimax
nvidia-kimi2.5
openrouter/free
llama8081/qwen2.5-7b
bailian/MiniMax
bailian/glm-5.1
bailian/qwen3-235b
lmstudio/qwen3.5-35b

建议（未执行）：精简到 5-6 个，移除不稳定的 openrouter/free 和已 disabled 的 lmstudio。

六、验证结果

风哥手动修改后执行 openclaw config validate：

无错误 ✅
2 个已知 warning（确认可忽略）：
1. plugins.load.paths 中存在指向 OpenClaw bundled plugin 目录的冗余路径
2. openclaw-qqbot 插件 manifest 缺少 channelConfigs 元数据

七、执行总结

7.1 已完成的 5 项变更

#	变更项	原始值	修改后
1	agents.list 清理	224 个	~25 个
2	session.maxDiskBytes	200mb	1gb
3	contextPruning.mode	off	cache-ttl
4	bundledDiscovery	compat	allowlist
5	narrative-designer.name	narrative-designer	叙事设计师

7.2 确认不变的 4 项

ou_bb7511xxxd752 — 正确的 open_id，非拼写错误
插件白名单 49 个 — 后续慢慢精简
proxy 配置 — 保留不动
QQ Bot default account — 禁止修改（踩坑修复后的状态）

八、经验教训

agency-agents 模板会大幅膨胀配置文件：安装 agency-orchestrator 后自动注册的 180+ 个模板 agent 会显著增加配置体积（从 ~40KB → 132KB），应定期清理。
飞书 open_id 需要逐字符比对：ou_bb7514... vs ou_bb7511... 仅两位差异，肉眼难辨。
contextPruning 模式演进：off → auto → cache-ttl，配置模式需要根据实际运行效果逐步调优。
踩坑修复的配置不要动：QQ Bot default account 缺少 enabled 字段是踩坑后的修复状态，不是遗漏。
插件白名单策略：不主动禁用已启用插件，由风哥根据实际需要逐步精简。

关联阅读

[[openclaw.json备份]]
[[OpenClaw配置]]
[[plugins设置]]
[[上下文配置优化操作手册]]

参考来源

（本文基于实际配置审计记录整理，无外部引用 URL）

目录