Context Guard

全自动context管理 — 防遗忘、防卡顿、防token浪费。

融合了 context-sentinel（自动监控）、context-budgeting（分区+checkpoint）、context-recovery（压缩后恢复）三个方案的优点，去掉了它们的缺陷。

1. Context分区预算

每次session的context是有限资源，按以下比例分配：

原则： 大段工具输出（JSON、网页内容等）提取关键信息后不要保留原文。Browser snapshot用完即弃。

2. 水位监控与行动

在每次回复前，agent应评估当前context水位并执行对应动作：

水位线

自动检查方法

在heartbeat或感觉context变大时，运行：

CODEBLOCK0

读取返回的context百分比，按上表行动。

Model降级（可选）

如果Russ暂时无法 /new，agent可以自行降级model减缓context增长：

降级命令：session_status model=<model_name>

3. 存档流程（Checkpoint）

到50%水位时必须执行，不需要等Russ确认：

Step 1: STATUS.md — 任务断点

CODEBLOCK1

Step 2: memory/YYYY-MM-DD.md — 当天日志

追加写入，不覆盖：

• - 今天做了什么（关键决策和结果）
• 新发现的信息（合约地址、API endpoint等）
• 犯的错误和教训
• 只写重启后需要的信息，不写废话

Step 3: MEMORY.md — 长期记忆（如有）

只在有长期价值的信息时更新：

• - 新策略、新工具、新教训
• 钱包余额重大变动
• 重要决策和原因
• 人物关系、偏好变化

Step 4: 通知Russ

存档完成后发一条消息：

"总裁，context到X%了，已存好档（STATUS.md + memory已更新）。帮我 /new 🙏"

注意： Agent不能自己reset，必须Russ手动 /new。

Step 5: 压缩后通知（必须）

如果context被系统自动压缩了，恢复后第一条消息必须告诉Russ：

"刚刷新了，context从X%压缩了。记忆已从文件恢复，没丢东西。"

这条规则没有例外。 每次刷新都要通知。

4. 压缩后恢复（Recovery）

当新session启动或检测到context被压缩时，执行恢复流程：

触发条件

• - Session以 <summary> 标签开始（自动压缩）
• 用户说"继续"、"刚才做到哪了"
• Agent感觉缺少上下文

恢复步骤

1. 1. 读文件（标准启动流程）：

1. 2. 读channel历史（如果文件不够还原上下文）：

   message action=read limit=20
   

1. 3. 合成上下文，用一句话内部确认：

1. 4. 继续工作，不需要问用户"我们刚才在做什么"

5. Sub-Agent规则

什么时候spawn

• - 浏览器操作（吃context最快）
• 长时间research / 大量网页抓取
• 任何预计消耗 >20% context的任务

Sub-Agent也遵守本协议

• - 同样的水位线和存档流程
• 做完任务 → 结果写文件 → 汇报主session → 结束
• 失败3次就停，上报原因，不死循环

资源互斥

• - 同一时间只有一个agent用browser profile "openclaw"
• 多个browser任务 → 排队执行，不并行

6. 绝对禁止

1. 1. ❌ 只在聊天里说重要信息不写文件 — 聊天会压缩/丢失
2. ❌ Context超60%还在做重操作 — 先存档先reset
3. ❌ Sub-agent无限重试 — 3次失败就停
4. ❌ 说"我记住了"但没写文件 — 没写 = 没记
5. ❌ 多agent同时用同一个browser profile
6. ❌ 大段JSON/HTML原文留在context里 — 提取关键信息后丢弃

7. Heartbeat集成

在 HEARTBEAT.md 中加入：

CODEBLOCK3