当你发现 AI 助手开始”变笨”,问题可能不在模型,而在上下文。

上下文膨胀的代价

模型处理上下文时,注意力机制会对所有 token 做关联计算。注入越多无关信息:

– 注意力稀释 — 模型需要从大量文本中定位有用信息,无关内容越多,定位成本越高

– 指令遵循退化 — 特别是小模型(如 128K context 的模型),静态注入占比越大,遵循用户指令的能力越弱

– token 浪费 — 虽然缓存命中率高,但每次调用仍然计费

这恰好对应了 OpenClaw Issue #92451 报告的问题:v2026.6.x 新增了 20+ 个默认工具和系统指令,导致 instruction following 退化。

一、OpenClaw 会话的上下文结构

OpenClaw 的一次会话,上下文由六层构成:

层	模块	内容	加载时机
1	系统指令	角色定义、工具调用规范、安全策略、格式规则	初始注入
2	工具定义	30+ 工具的完整 JSON Schema 描述	初始注入
3	可用技能列表	53 个启用 skill 的名称、描述、路径	初始注入
4	Project Context	AGENTS.md / SOUL.md / USER.md / TOOLS.md / MEMORY.md / HEARTBEAT.md	初始注入
5	动态上下文	Inbound Context、Messaging 规范、Group Chat Context、Runtime 信息	初始注入
6	对话历史	用户消息 + AI 回复 + 工具调用结果	随对话增长

其中 1-5 属于初始注入,在每次新会话启动时一次性加载;6 是随对话推进逐渐增长的部分。

二、初始上下文注入构成

用 /status 查看初始注入的实测数据。优化前:

Context: 44k/1.0m (4.4%)   Cache: 98% hit

Tokens: 43k in / 37 out

44k tokens 的初始注入,各模块占比:

模块	估算大小	占比	用户可控?
系统指令	~5k	11%	否
工具定义	~10k	23%	否
技能列表	~3k	7%	否
Project Context 文件	~25k	57%	是
动态上下文 + 运行时	~1k	2%	否
合计初始注入	~44k	100%	—
对话历史 (首轮)	~6k	—	是

关键事实:

– 系统指令 + 工具定义 = 15k,占初始注入的 34%。这是 OpenClaw 框架自身的开销,用户无法优化。

– 技能列表 = 3k,占 7%。53 个启用 skill,每个描述约 60 tokens。OpenClaw 已正确过滤禁用 skill,但数量本身无法由用户缩减。

– Project Context = 25k,占 57%。这是用户唯一能直接优化的部分,也是最大的膨胀源。– “98% 缓存命中率”是假象。静态模板每次都相同,prompt cache 直接命中不代表对话历史被复用。

三、我们能优化什么,为什么只能优化这些

初始注入的六个模块中:

模块	能否优化	原因
系统指令	否	OpenClaw 框架内置,除非官方修改
工具定义	否	工具 schema 是运行时必需,不能删减
技能列表	部分	可以禁用不需要的 skill,但框架层面无法缩减描述长度
Project Context	是	用户完全控制文件内容
动态上下文	否	运行时自动生成
对话历史	是	但这是增量增长,不是初始注入

所以,唯一可优化的初始注入源就是 Project Context 文件 — 也就是 SOUL.md、USER.md、AGENTS.md、TOOLS.md、MEMORY.md 这些。优化前这 5 个文件合计约 25k tokens,占初始注入的 57%。

四、解决方案:冷热分层策略

核心思路:

每次会话都用到的 -> 留在 MD 文件中(热数据);偶尔才用到的 -> 迁移到 Obsidian 知识库,MD 中只留引用(冷数据);从来不用的 -> 直接删除。

第一刀:TOOLS.md 瘦身

TOOLS.md 是最大的膨胀源。原始版本约 15KB,包含大量场景化的代码示例:

# 原始内容(已删除)

– HZERO 低代码平台 React 表单填写完整代码(~1.5KB)

– SVG 中文字体规范完整教程(~0.8KB)

– PPTX 图标规则完整示例(~0.8KB)

– 模板占位内容 “What Goes Here / Examples”(~0.5KB)

问题在于:模型本身就知道这些知识。React 表单怎么填、SVG 字体怎么设、PPT 图标怎么做 — 不需要在 TOOLS.md 里写完整教程。只需要保留模型不知道的、犯过错的教训:

## HZERO 低代码平台操作经验

– iframe 嵌套:所有页面在 iframe 中,通过 iframe.contentDocument 访问

– React 表单:设置值后必须清除 _valueTracker 再触发事件

– 事件上下文:用 iframeWin.Event 而非外层 Event

从 15KB 降到 3.9KB,减少 74%。

第二刀:MEMORY.md 冷数据迁移

MEMORY.md 原始版本约 12KB,其中有些条目长期不被引用。通过 memory_search 搜索会话记录验证:

条目	近期被引用?	处理
HZERO 产品授权控制	0 次	迁移到 HZERO-wiki
信通院合作事项	0 次	迁移到 HZERO-wiki
GitHub Issue 操作偏好	1 次	保留
HZERO 飞码架构与定位	1 次	已是指针,保留

迁移后 MEMORY.md 从详细内容变为只留 wiki 路径引用:

## HZERO 产品授权控制

详细内容已入库 HZERO-wiki: `wiki/HZERO授权用户数控制逻辑.md`

第三刀:红线文件精简

SOUL.md、USER.md、AGENTS.md 定位为”仅人工维护”,AI 禁止自动修改。同时精简内容:

1. SOUL.md: 删除开头结尾的修辞性文字,只保留核心原则和边界(2.1KB -> 0.97KB)

2. AGENTS.md: 删除委派模板的详细格式说明,只保留必填项(2.4KB -> 1.7KB)

3. USER.md: 新增红线禁令表,禁止修改 (1KB,保持不变)

治理效果

指标	优化前	优化后
TOOLS.md	~15KB	~3.9KB
MEMORY.md	~12KB	~3KB
SOUL.md	2.1KB	0.97KB
AGENTS.md	2.4KB	1.7KB
USER.md	1KB	1KB
Project Context 合计	~25k tokens	~8k tokens
初始注入总计	~44k tokens	~27k tokens
红线文件	可被 AI 修改	仅人工维护
冷数据	无限膨胀	自动迁移到 wiki

审计机制:memory-lifecycle 技能

冷热分层不是一次性工作,需要持续维护。为此我们创建了 memory-lifecycle 技能,将审计流程标准化、自动化。

条目级审计元数据:

每个 MEMORY.md 和 TOOLS.md 的条目加上审计标记:

## HZERO 产品授权控制

**Created:** 2026-03-30 | **Audited:** 2026-06-13 | **Status:** cold

技能工作流:

扫描条目 -> 分类使用频率 -> 迁移冷数据 -> 更新元数据 -> 生成报告

具体步骤:

1. 扫描: 用 Python 脚本解析 MD 文件,提取所有 ## heading 条目及元数据

2. 分类: 对每个条目执行 memory_search(corpus=”sessions”),根据近 30 天命中次数判定: >=2 次 = hot(留在 MD);1 次 = warm(保留观察);0 次 = cold(迁移或删除)

3. 迁移: 冷数据写入 Obsidian 知识库(HZERO 相关 -> HZERO-wiki,其他 -> MY-wiki),MD 中替换为一行引用

4. 元数据: 更新 Audited 日期和 Status 状态

5. 报告: 输出审计报告到 .memory-audit/YYYY-MM-DD.md

触发方式:

场景	触发	说明
定时审计	cron 每两周执行	每月 1 号和 15 号
手动触发	用户说 “审计 MEMORY.md”	按需执行
写入前检查	新增条目前	确保有审计元数据

红线规则: 只审计 MEMORY.md 和 TOOLS.md,不触碰 SOUL.md / USER.md / AGENTS.md。

知识库分工:

知识库	用途	共享性
HZERO-wiki	HZERO PaaS 平台相关知识	可共享
MY-wiki	个人开发经验和通用知识	永不共享

冷数据迁移规则:HZERO 相关 -> HZERO-wiki,其他 -> MY-wiki。

五、与 Active-Memory 的关系

有人会问:OpenClaw 有 Active-Memory 功能,能动态召回相关记忆,还需要手动管理 MEMORY.md 吗?

答案是:两者解决不同层面的问题。

维度	Active-Memory	冷热审计
层面	检索层	管理层
作用	从记忆库中找到相关信息	决定什么信息留在记忆库中
类比	图书馆的检索系统	库存管理
局限	不能减少静态注入体积	不能帮你找到记忆

关键矛盾:

即使 Active-Memory 再强大,只要冷数据还在 MEMORY.md 里,就永远被注入到每次会话的上下文。Active-Memory 不能减少静态注入的体积。

类比:检索系统再强,如果书架上堆满没人看的旧书,也会挤掉新书的空间。冷热审计解决的是”书架上该放什么书”,Active-Memory 解决的是”怎么快速找到你要的那本”。

六、关键教训

1. 3%的初始上下文也不代表健康 — 上下文使用率低不代表注入内容都是有用的。

2. 模型知道的知识不需要写进 MD — TOOLS.md 应该只保留”模型不知道的规则”和”犯过错的教训”

3. 引用比全文更高效 — 冷数据迁移到 wiki,MD 中只留路径引用

4. 审计比一次性清理更重要 — 建立机制比手动执行更可持续

5. 红线文件应极度精简 — 每次新增内容前自问”这个真的每次都需要吗?”

6. 分清两层问题 — 用户层(MEMORY/TOOLS)自己能优化,系统层(默认工具/Skills 列表)只能反馈给开发团队

7. Active-Memory 不能替代冷热审计 — 检索层和管理层解决不同问题,缺一不可

本文基于 2026-06-13 的 OpenClaw 实践整理。相关 Issue: #92451(system prompt bloat)。