跳到主要内容

OpenClaw：上下文与记忆管理策略

目录​

这一篇解决什么问题​

个人助手最常见的失败不是「模型不够聪明」，而是：上下文管理失控——对话越长越贵、越慢、越容易跑题；工作区里堆满临时口令；技能文件复制三份互相冲突；多入口共用同一记忆导致隐私串味。

本篇把 OpenClaw 相关的「上下文与记忆」拆成可执行策略：哪些内容属于会话内短期上下文，哪些属于工作区长期提示与技能沉淀，以及何时使用压缩、重置与会话工具。
权威概念请以 Session model、Agent 为准；工具与技能机制见 Tools、Skills。

先对齐概念：上下文、会话与「记忆」​

在工程语境里建议严格区分这三者，否则团队对话会永远吵不到同一个点：

  1. 上下文（Context）：模型在单次或连续多轮里能「看见」的 token 范围，包括系统提示、历史消息、工具输出等。它受模型窗口限制，是昂贵且易污染的资源。
  2. 会话（Session）：Gateway 侧对一次连续交互的会话状态管理；与「聊天窗口」相关但不等价。官方文档见 Session model。
  3. 记忆（Memory）：在 OpenClaw 路线里，往往由「工作区文件 + Skills + 会话历史」共同实现；它不是自动「越用越懂」的黑盒，而是你设计出来的沉淀策略。

一句话：上下文是燃料，会话是管道，记忆是仓库布局。燃料会耗尽，管道会串，仓库乱了就全乱。

工作区提示文件：AGENTS、SOUL、TOOLS 的分工​

官方 README 提到工作区默认在 ~/.openclaw/workspace，并会注入 AGENTS.md、SOUL.md、TOOLS.md 等提示文件（路径与可配置项见 README 与 Configuration）。建议你用下面分工来维护，避免所有东西都写进一个文件：

文件建议承载的内容不建议承载的内容
SOUL.md稳定人设、价值观边界、语气具体项目需求、临时任务清单
AGENTS.md角色职责、任务类型、协作边界大量重复 SOP（应技能化）
TOOLS.md工具启用策略、默认拒绝项、审批规则API 密钥与明文密码（应走密钥管理）

为什么要拆分：人设（SOUL）变化频率低；工具策略（TOOLS）变化频率高；把它们混写会导致每次调工具策略都意外改变人设表现。

Skills：把流程从对话里抽出来​

Skills 的路径在 README 中描述为 ~/.openclaw/workspace/skills/<skill>/SKILL.md（详见 Skills）。它的价值在于：把「重复出现的工作流」从对话上下文里搬走，让模型在需要时引用明确步骤，而不是依赖几十轮之前的口头约定。

落地建议：

  • 技能粒度：一个技能解决一类事（例如「周报生成」「发布检查」），不要把整个公司制度写进一个技能。
  • 版本与变更：技能变更要有记录；否则你会遇到「模型以为流程 A，用户记得流程 B」。
  • 与上下文的关系：技能被引用时会占用上下文；不要为了「全面」把技能写成超长文档。

会话模型：短期上下文如何被消费​

当你讨论「助手为什么忘了刚才那句话」时，通常要先区分：

  • 是 会话状态没延续（会话切换/重置/路由到了不同 Agent）？
  • 还是 模型窗口装不下（需要压缩或摘要）？
  • 还是 工具输出没被写回（工具失败/权限拒绝）？

官方 Operator quick refs 提到 /compact 等与会话状态相关的命令（以你版本 help 为准）。工程上要把这些命令纳入「运维手册」，让使用者知道：压缩不是免费魔法，它可能丢掉细节，需要配合工作区里的长期约束来兜底。

长对话与压缩：官方命令背后的工程含义​

README Operator quick refs 列出 /compact、/usage 等命令方向。你可以把它们理解成三类动作：

  1. 观测：/usage 类命令帮助你看清 token 压力与成本来源，决定是换模型、减工具输出、还是改交互习惯。
  2. 压缩：/compact 类命令用摘要换空间；适合长对话但会带来信息损失，关键约束应放在工作区而不是指望摘要永远正确。
  3. 重置：/new / /reset 用于「会话叙事断档」时的硬切换；适合任务切换，但不适合作为「逃避安全策略」的手段。

分层策略：什么放工作区、什么放技能、什么不放​

内容类型放哪里原因
稳定人设与安全边界SOUL.md / AGENTS.md低频变更、强约束
可重复流程Skills可被引用、减少上下文浪费
当天临时任务会话里短期保留避免污染长期文件
密钥与证书密钥管理/环境变量不应进入 markdown 与工作区 Git

绝对不要把「上下文管理」当成「把所有东西写进提示文件」。提示文件越大，越容易让模型抓错重点；正确做法是分层 + 技能化 + 在会话里用短消息确认关键约束。

隐私、合规与最小披露​

个人助手最容易忽略的是：工作区与技能文件往往包含最敏感的组织信息。建议固定以下规则：

  • 最小披露：只在 TOOLS.md 写明「允许访问哪些目录/哪些 API」，不要写「整个家目录都可读」这种泛化描述。
  • 脱敏：客户名、身份证号、密钥片段不应进入会被同步到多端的工作区；如必须存在，应加密与访问控制（这已超出 OpenClaw 默认能力，需要你自己补齐）。
  • 审计：定期抽查工作区与技能目录是否出现不该出现的内容。

与多 Agent 协同时的记忆边界​

一旦你使用多 Agent 路由（见本站 多 Agent 方案），「记忆」必须先回答：哪些东西是全局共享、哪些是 Agent 私有。推荐默认偏保守：

  • 默认不共享客户对话原文 across agents，除非你有明确的跨会话协作需求与审批。
  • 共享技能要小心：技能若包含路径与账号信息，会变成隐式共享敏感信息。

可操作的日常运维节奏​

  • 每周：看一次 /usage 或日志里的 token/成本异常；检查是否有人把临时任务写进了长期文件。
  • 每月：整理 Skills：合并重复、删除过期流程、补齐失败案例。
  • 每次升级 OpenClaw：阅读 Updating，运行 openclaw doctor，验证压缩/会话命令是否变化。

把“周维护”拆成可执行清单（建议）​

每周 15 分钟（个人）/ 每周 30 分钟（团队）：

  1. 运行 openclaw doctor，确认 DM 策略与配置风险项无新增。
  2. 抽查 1～2 个 Skills：是否仍与当前流程一致；是否出现互相冲突的指令。
  3. 若使用多渠道：检查最近是否出现「串台」用户反馈；若有，优先查路由与会话归属。

每月一次（更深入）：

  1. 对工作区文件做“分层瘦身”：把临时说明迁出 AGENTS.md，把流程迁到 Skills。
  2. 回顾工具调用：是否有工具长期不用却仍开启（扩大攻击面）。
  3. 备份：配置与工作区（密钥单独管理）。

Token 与成本意识（为什么也属于“记忆管理”）​

上下文管理直接与成本相关：工具输出越长、历史越多，越容易触发压缩与更高模型费用。建议你在团队内约定：

  • 工具输出默认裁剪：只保留结论字段与必要证据（片段/链接），避免整页 HTML/JSON 进入对话。
  • 固定“任务完成定义”：避免无限轮次修补；该重置就重置，该写技能就写技能。

与多 Agent 的交叉引用（避免重复造轮子）​

当你启用多 Agent 路由时，“记忆与上下文”要先分清楚 哪些记忆是全局、哪些是 Agent 私有。更系统的隔离与路由策略见本站 多 Agent 方案。

原文与延伸阅读​