一、什么是上下文工程

很多人把“上下文”简单理解成提示词或 RAG。这个理解不算错，但不完整。

更准确地说，上下文工程是一套系统化的方法：持续构建、管理、筛选、注入任务相关信息，让大模型在有限预算里稳定输出。

可以抽象为：

Context = System Prompt + User Input + 历史对话 + 工具结果 + 检索内容 + 长期记忆

模型在当前轮次看到的所有信息，决定了它能否做出正确决策。

二、上下文工程要解决的三类问题

1) 减少幻觉与泛化回答

模型训练数据不是实时和专属的。要通过外部知识注入，把最新、准确、任务相关的信息喂给模型。

2) 应对上下文窗口限制

模型有固定 token 上限。任务越复杂，越容易超限。需要在预算内做选择、压缩、截断。

3) 提升信息可读性

输入若杂乱无序，模型难以理解。要把数据整理成结构化、可解释、可执行的格式。

三、上下文工程与提示词工程的关系

• 提示词工程：如何提问，如何写更好的指令模板
• 上下文工程：给模型什么背景信息，如何检索、筛选、注入

标准流程通常是：

1. 上下文工程先行：先把相关知识找全、筛干净
2. 提示词工程收尾：把“资料+问题”按模板组织后再发送

四、OpenClaw 的上下文工程分层

OpenClaw 采用流水线式设计，按职责可分为三层：

1) 资源管理层

负责管理上下文来源与冲突处理，包括：

• 用户配置
• 工作区文档（如 AGENTS.md、TOOLS.md）
• 对话历史
• 工具清单
• 长期记忆

2) 组装层

负责把信息按固定顺序和格式装配，并处理：

• 模型格式兼容
• 历史消息清洗
• token 预算内取舍

3) 保护层

负责稳定性与安全性：

• 上下文溢出检测
• 自动压缩触发
• 过载保护，避免会话崩溃

五、上下文引擎与核心构建流程

OpenClaw 定义了可插拔的上下文引擎接口，使默认实现可用、定制实现可扩展。

典型流程如下。

1) 系统提示词构建

系统提示词会定义 Agent 的身份、能力边界、可用工具和行为规则，核心包括：

• 身份声明（你是什么）
• 工具列表与调用风格
• 安全规则
• Skills 引导
• 记忆召回指令
• 工作区与运行时元数据

2) Bootstrap 文件加载

通过工作区文件注入项目级上下文，常见文件：

• AGENTS.md
• TOOLS.md
• MEMORY.md / memory.md
• SOUL.md
• IDENTITY.md
• USER.md
• HEARTBEAT.md
• BOOTSTRAP.md

并且支持：

• 单文件大小上限
• 总加载上限
• 会话键过滤
• full / lightweight / none 三种上下文模式

3) 会话历史清理

历史消息不能直接复用，需要清洗与修复：

• 删除无效工具调用
• 修复工具调用与结果配对
• 处理图像超限
• 修复跨会话标记与消息顺序
• 提供商特定兼容处理（如不同 API 的格式限制）

4) 最终组装与验证

组装后还要做预算与格式验证：

• 估算总 token
• 超限时触发压缩或截断
• 优先保留最近轮次
• 按目标提供商做 schema 和顺序校验

六、上下文窗口与预算策略

OpenClaw 的上下文窗口值按优先级确定：

1. 模型配置中的显式 contextWindow
2. 模型元数据
3. 默认值（200000）
4. 全局上限（agents.defaults.contextTokens）

保护阈值通常包括：

• 硬性最小值：低于阈值直接阻止运行
• 警告阈值：低于阈值记录告警但允许继续

这套机制用于避免误配置导致的 OOM 或频繁溢出。

七、OpenClaw 记忆系统的两层结构

记忆并不是“一股脑塞进上下文”，而是“持久化存储 + 按需检索”。

第一层：Markdown 记忆源

• MEMORY.md：长期记忆（约定、决策、持久事实）
• memory/YYYY-MM-DD.md：每日记忆（当天过程、临时讨论）

第二层：向量与关键词索引

系统会把记忆切块后构建索引，检索时采用混合检索：

• 向量检索：语义相关
• BM25 检索：关键词精确匹配

常见做法还包括：

• 向量/关键词加权融合
• 时间衰减（新信息权重更高）
• MMR 去重（避免返回重复片段）

记忆访问策略

• 主会话自动注入长期记忆（MEMORY.md）
• 每日记忆通过工具按需读取（如语义搜索 + 精确行读取）

目标是在不爆 token 的前提下，保留“长期一致性 + 近期相关性”。

八、工具与 Skills 的上下文注入策略

工具注入

工具来源可来自核心、插件、渠道，但不会全量注入。系统会按策略筛选：

• Profile（minimal/coding/messaging）
• Allow/Deny
• 沙箱限制
• 子 Agent 限制
• 群组策略

最终只把“当前可用且允许调用”的工具描述写入系统提示词。

Skills 注入

Skills 来自内置、用户、插件、项目等多源，按优先级合并去重。并在 token 不足时降级展示格式，确保在预算内保留最关键的 skill 信息。

九、上下文压缩机制

长期会话一定会触发压缩，典型触发方式：

1. API 返回上下文溢出（自动触发）
2. 上下文达到预算阈值（自动触发）
3. 用户手动触发（命令触发）

压缩策略分三级：

• 摘要压缩：保留关键任务、决策、标识符
• 截断压缩：直接丢弃更早历史，速度快
• 混合压缩：摘要与截断组合，平衡质量与性能

执行流程通常是：

1. 计算当前 token 使用量
2. 设定目标（例如压到预算的 80%）
3. 生成摘要并重构历史
4. 原子替换历史，避免写坏会话
5. 超时与异常保护，失败可回滚

十、可扩展架构：ContextEngine 接口

上下文引擎接口覆盖完整生命周期：

• bootstrap
• ingest / ingestBatch
• assemble
• compact
• afterTurn
• prepareSubagentSpawn / onSubagentEnded
• dispose

默认传统引擎保持向后兼容：多数方法透传或空实现，仅在压缩阶段委托到既有逻辑。这样可以让团队逐步替换成更智能的上下文引擎，而不必一次性重写系统。

十一、配置与调优建议

常用配置项：

• contextTokens：上下文 token 预算
• bootstrapMaxChars：单个 Bootstrap 文件字符上限
• bootstrapTotalMaxChars：Bootstrap 总字符上限
• compaction.mode：压缩模式（auto/manual/off）
• compaction.target：压缩目标（budget/threshold）

工程实践建议：

1. 持续监控 token 使用，减少溢出重试
2. 精简 Bootstrap 文件，删冗余、保关键约束
3. 复杂任务交给子 Agent，降低主会话压力
4. 按业务场景调压缩阈值，平衡连续性与性能

结语

OpenClaw 的核心价值不是“能聊天”，而是把上下文作为工程系统来治理：有预算、有策略、有保护、有扩展接口。

本质上，它在做一件事：用有限 token，把模型最该看到的信息稳定地组织出来，并在长周期运行中保持可控与可演进。