一、上下文引擎核心介绍
上下文引擎是 OpenClaw 负责拼装完整请求提示词的核心组件。用户每发送一条消息，引擎会自动整合系统人设、规则、技能、历史对话、长期记忆等内容，组合为模型可识别的完整 Prompt。
完整内容组装结构：
plaintext
┌─────────────────────────────┐
│ SOUL.md（智能体人设） │
│ IDENTITY.md（身份定义） │
│ USER.md（用户信息） │
│ AGENTS.md（执行规则） │
│ TOOLS.md（工具说明） │
│ 已安装全部 Skills 技能描述 │
│ MEMORY.md（长期记忆） │
│ ─────────────────────────────│
│ 对话历史（摘要 + 近期消息） │
│ ─────────────────────────────│
│ 用户最新消息 │
└─────────────────────────────┘
核心目标：在模型上下文窗口限制内，最大化保留有效信息，同时控制 Token 开销。
二、上下文窗口与 Token 预算分配
2.1 主流模型窗口上限参考
每个大模型都有固定上下文窗口，决定单次请求最多可承载的 Token 总量，中文大致字数对照如下：
表格
| 模型 | 上下文窗口 | 中文大致字数 |
|---|---|---|
| GPT-4o | 128K tokens | 约 6 万字 |
| Claude 3.5 Sonnet | 200K tokens | 约 10 万字 |
| DeepSeek V3 | 64K tokens | 约 3 万字 |
| Ollama 本地模型 | 4K ~ 32K tokens | 约 2 千～1.5 万字 |
引擎会根据当前使用模型的窗口大小，自动适配内容加载规则。当内容接近上限时，自动触发对话压缩。
2.2 Token 预算分配规则
引擎会按固定比例划分窗口空间，保证各类内容正常承载：
- 系统提示词（引导文件 + 所有技能）：20% ~ 30%
- 对话历史记录：50% ~ 60%
- 预留空间（新消息 + AI 回复）：15% ~ 20%
三、对话压缩（Compaction）机制详解
3.1 压缩工作原理
对话持续增多后，历史消息会不断占用 Token，逼近模型窗口上限。自动压缩会将早期多条原始对话合并为一段精简摘要，释放空间用于新对话。
流转示意：
plaintext
压缩前（Token 即将溢出）
[消息1][消息2]...[消息40][消息41]...[消息50][新消息]
压缩执行：提取早期对话 → 生成摘要 → 替换原始内容
压缩后（空间释放）
[1-40条对话摘要][消息41]...[消息50][新消息]
3.2 触发条件
默认规则：当对话历史 Token 占比达到窗口 70% 时，自动执行压缩，阈值可自定义修改。
3.3 完整配置项
编辑 ~/.openclaw/openclaw.json 配置压缩功能：
json
{
"compaction": {
"enabled": true,
"threshold": 0.7,
"model": "deepseek-chat"
}
}
表格
| 配置项 | 作用 | 默认值 |
|---|---|---|
enabled | 开关：是否开启自动压缩 | true |
threshold | 触发阈值（0~1，代表窗口占比） | 0.7 |
model | 生成摘要所使用的模型 | 同主对话模型 |
优化建议：优先使用低成本模型做摘要（DeepSeek、GPT-4o-mini），避免压缩环节额外增加开销。
3.4 压缩的优缺点与数据取舍
压缩属于有损优化，会精简细节内容：
✅ 保留内容：核心结论、关键决策、代码变更、重要指令
❌ 丢失内容：对话语气、中间试错过程、零散细节、临时数据
丢失细节解决方案
- 核心信息写入
MEMORY.md长期记忆，跨会话永久保留； - 固定规则、要求写入
AGENTS.md，每次会话都会加载； - 细节较多时手动新建会话（指令
/new），重置上下文。
四、消息队列三种工作模式
上下文引擎内置三类消息队列模式，控制消息的加载、执行、流转顺序，适配不同业务场景。
4.1 steer 引导模式
- 用途：在用户消息之前注入临时系统指令、约束规则
- 优先级：最高
- 典型场景：钩子前置指令、临时行为限制、即时权限管控
4.2 followup 跟进模式
- 用途：AI 完成当前回复后，自动执行后续任务
- 优先级：中等
- 典型场景：多步骤任务串联、工具调用后置处理、流程自动化
4.3 collect 收集模式
- 用途：短暂等待，收集多条消息后批量统一处理
- 优先级：最低
- 典型场景：用户连续刷屏、群组多人发言、批量指令处理
4.4 标准执行顺序
plaintext
1. steer 引导指令（最高优先级）
↓
2. 用户当前消息
↓
3. AI 生成回复
↓
4. followup 后置任务
↓
5. collect 批量消息（最低优先级）
五、Token 消耗拆解与优化方向
5.1 全链路 Token 占比
单次请求所有消耗来源及占比参考：
表格
| 消耗来源 | 占比 | 说明 |
|---|---|---|
| 系统提示词 | 20%~30% | SOUL/AGENTS/ 所有技能、工具定义 |
| 对话历史 | 40%~50% | 历史问答、压缩摘要 |
| 当前用户消息 | 5%~10% | 本次输入内容 |
| AI 回复内容 | 15%~25% | 模型输出文本 |
| 工具调用出入参 | 不固定 | 搜索、读文件、命令执行等大数据内容 |
5.2 技能带来的固定开销
单个技能描述常驻占用 24+ Token，属于永久固定开销：
- 安装 20 个技能：额外增加约 500 Token
- 安装越多，基础开销越大
优化操作：
bash
运行
# 查看已安装技能
clawhub list
# 卸载长期闲置技能
clawhub uninstall 技能名称
5.3 综合降本 & 控容建议
- 分层选模型：日常闲聊 / 摘要用低价模型，复杂推理用高阶模型；
- 主动新建会话：单一会话轮次过多时，执行
/new重置上下文； - 强制开启压缩：搭配低价模型生成摘要，兼顾空间与成本；
- 精简系统文件：缩短 SOUL.md、AGENTS.md 篇幅，剔除冗余内容；
- 本地部署兜底：隐私场景、高频使用场景切换 Ollama 本地模型，零 API 费用。
六、对话压缩 vs 长期记忆（MEMORY）
两者功能互补、定位完全不同，是上下文管理的两大核心能力。
表格
| 对比项 | 对话压缩 Compaction | 长期记忆 MEMORY.md |
|---|---|---|
| 作用范围 | 仅限当前会话 | 跨所有会话永久生效 |
| 触发方式 | 自动触发（Token 超限） | 智能体主动写入 / 手动编辑 |
| 存储位置 | 会话临时文件 | 独立 MEMORY.md 文件 |
| 信息形态 | 历史对话摘要 | 关键事实、用户偏好、重要规则 |
| 可恢复性 | 原始对话无法恢复 | 可随时查看、手动修改 |
信息分级存储最佳实践
按信息重要程度选择承载方式，形成完整分层体系：
- 临时对话细节：依靠会话 + 压缩，短期使用即可；
- 会话内关键内容：依赖自动压缩摘要保留；
- 用户偏好、重要决策：存入
MEMORY.md跨会话持久化； - 永久规则、人设、执行标准：写入
SOUL.md/AGENTS.md，全局生效。
优先级示意（重要程度由低到高）：
普通对话 → 压缩摘要 → MEMORY.md 长期记忆 → SOUL.md/AGENTS.md 永久规则
七、上下文状态调试命令
日常排查上下文溢出、记忆异常、压缩失效等问题，使用以下指令快速诊断：
bash
运行
# 查看当前会话 Token 总量、当日/月度用量
openclaw status
# 查看长期记忆加载状态、内容统计
openclaw memory status
也可直接在对话中交互查询：
plaintext
你当前加载了多少上下文内容？
八、总结
- 上下文引擎负责拼装全套提示词，是连接所有配置、对话、技能的中枢；
- 对话压缩自动解决窗口溢出问题，本质是用摘要换取空间，存在细节损耗；
- 三种消息队列模式可实现指令前置、任务后置、批量处理，适配复杂流程；
- 压缩负责会话内短期历史，Memory 负责跨会话长期信息，二者配合使用效果最佳；
- 合理调整压缩阈值、摘要模型、精简技能与配置，可同时优化上下文容量与 API 成本。