引言 链接到标题

上一篇《OpenClaw 静态记忆文件的正确用法》 完成了身份层文件的精简，把 AGENTS.md、SOUL.md、IDENTITY.md 等从官方模板的 ~10KB 裁到 ~3.5KB。

但这只是第一步。优化后日志层的占比反而更突出了——详细日志占到了会话上下文的 59%。同时，MEMORY.md 里堆砌的操作流程，每次加载都在浪费 token。

本篇记录后续的两步优化：

  1. Memory 日志的摘要归档——把每日日志从全文加载改为摘要+存档
  2. Skill Workshop 把流程从记忆迁移到技能——让 Agent 自建 skill，按需加载

一、静态文件定制回顾 链接到标题

身份层文件的处理思路是：只放核心定义，删除模板中不适用段落。

文件 官方模板 定制后
AGENTS.md 7,874 字节 ~1,800 字节
其余身份文件 ~2,100 字节 ~1,700 字节
合计 ~10 KB ~3.5 KB
每次会话 token 节省 — ~1,625 tok

详细做法见上篇。本篇不再展开。

二、不自动加载，按需搜索 链接到标题

痛点 链接到标题

定制身份层后，日志占比凸显：

项目 Token 占比
定制身份层 ~875 41%
当天详细日志 ~750 35%
昨天详细日志 ~500 24%
合计 ~2,125 100%

日志占了近六成。每次会话都自动加载当天和昨天的完整日志，但大部分时候用不上。

分析：问题出在哪 链接到标题

最初的想法是"建一套摘要+归档机制"——白天写详细日志，晚上 cron 把原文存到子目录，原文件替换为摘要。

但仔细查看 OpenClaw 源码和文档后发现：

  • memory/ 下的所有文件都会被 memory_search 递归索引（唯一跳过的是 .openclaw-repair）
  • 如果存两份（摘要 + 归档），搜索会返回重复结果，短时召回也会混淆
  • 文档同时说：“These files are indexed for memory_search and memory_get, but they are not injected into the normal bootstrap prompt on every turn."——日志被索引但不注入到每次模型调用
  • 这意味着"自动加载"发生在会话启动（一次性的文件读取），但不会在每个轮次重复注入

问题不是加载行为本身，而是每次会话都加载全部内容，但大部分用不上。

修正方案 链接到标题

只做一件事：删掉 AGENTS.md 中的"读今天+昨天"指令。

Before:                      After:
AGENTS.md 写死"读今天+昨天"   → 不自动读，需要时 memory_search
session 自带 ~1,250 tok 日志  → 0 tok
自己维护摘要/归档机制          → 不用管

需要查历史时：

  • 直接 memory_search "关键词"，不用知道文件路径
  • 搜索自带时间衰减，旧内容自然排后面
  • 找到后 memory_get 读完整内容，用完即弃

效果对比 链接到标题

方案 每会话日志开销 维护成本 数据完整性
原做法 ~1,250 tok 无 完整
摘要+归档 ~150 tok cron + 存档目录 有重复风险
不加载，按需搜 ~0 tok 零 完整

不加载，按需搜——简单直接，文件不重复，逻辑不绕路。

三、Skill Workshop：从记忆到技能 链接到标题

问题：MEMORY.md 不该放流程 链接到标题

优化前，MEMORY.md 里放着大量操作流程——笔记归档步骤、健康记录规范、周目标管理规则……每次 DM 会话都加载，大部分时候用不上。这违反了静态记忆的核心原则：MEMORY.md 存持久事实，不存操作步骤。

这些流程应该做成 skill——用到时自动加载，不用时不占上下文。

OpenClaw 的 Skill Workshop 链接到标题

OpenClaw 内置了一套完整的 skill 创建机制，核心工具是 skill_workshop。工作流程：

flowchart LR A["Agent 起草 skill
proposeCreateSkill"] --> B["提案写入
skill-workshop/proposals/"] B --> C["主人审查提案
inspectSkillProposal"] C --> D["修改提案
reviseSkillProposal"] D --> E["主人确认
applySkillProposal"] E --> F["skill 编译到
workspace/skills/"] F --> G["下次会话
自动按需加载"]

关键区别：

传统做法（opencode） Skill Workshop
创建方式 手动编辑文件 Agent 自动起草
审查机制 无 提案 → 审查 → 应用
迭代流程 直接改 revise → inspect → apply
按需加载 需手动配置 自动按需

Agent 自己就能根据需求起草 skill，你只需审查确认。这远比手动编辑静态文件高效。

实际案例：Obsidian 技能集 链接到标题

我在 jax 节点上把原本存在 MEMORY.md 和 memory/*.md 里的操作流程，迁移到了独立 skill 中：

Skill 功能 来源
obsidian-archive 归档 Inbox 已标 archived: true 的笔记 原流程在 memory/obsidian-rules.md
obsidian-health 记体重、血压到 Obsidian，标准化 frontmatter 原流程在 MEMORY.md
obsidian-daily-summary 汇当天会话到总结笔记写入 Inbox 新技能，按需生成
obsidian-weekly-goals 管理本周目标，检查完成情况 原流程在 MEMORY.md
obsidian-pocket-money 记录孩子零花钱，Base 视图自动汇总 新技能
task-list 汇总各层级目标中未完成任务 原跨文件逻辑

以 obsidian-archive 为例，它的 skill.md 定义了精确的规则：

## Inbox 存档管理

### 规则
- 只处理 frontmatter 中已标 `archived: true` 的笔记
- 标 `archived: false` 或没有 archived 字段跳过
- 不要请示，直接归档

### 步骤
1. 扫描所有 Inbox 文件，用 obsidian CLI property:read 检查 archived
2. 按文件名前缀 yyyy-mm- 提取归档目录
3. 用 obsidian CLI move 移到 Archive/2026/04
4. 输出报告

这些规则过去在 MEMORY.md 里每次加载，现在只有调用该 skill 时才注入，上下文零开销。

效果 链接到标题

项目 原做法 现做法
存放位置 MEMORY.md / memory/*.md workspace/skills/
加载时机 每次 DM 会话 skill 触发时
上下文开销 ~2-3 KB 持续占用 ~0 KB（不用不加载）

每释放一个流程到 skill，会话基线就减少几百 token。所有技能加起来，相当于把 MEMORY.md 的上下文占用降低了 80% 以上。

额外的收获：迭代质量 链接到标题

Skill Workshop 的提案机制带来的副产品——审查闭环。

Agent 创建的 skill 不是一步到位的。实际迭代中发生了这样的过程：

  1. Agent 起草 obsidian-archive skill
  2. 审查发现它用了 grep + mv 操作 vault，会被 iCloud 文件锁卡住
  3. 修改提案：改用 obsidian CLI move
  4. 再次审查：确认命令路径写死，使用环境变量 OBSIDIAN_VAULT
  5. 应用生效

这个过程在普通文件编辑中很容易遗漏。Skill Workshop 的 inspectSkillProposal 让你能清晰看到改动差异，reviseSkillProposal 支持反复修改，直到满意。

总结 链接到标题

两次优化方向一致：文件只放核心，内容按需加载。

优化 手法 节省 tok/次
① 身份层精简 定制 SOUL/AGENTS/USER 等 ~1,625
② 去自动加载 日志不注入会话，按需搜索 ~1,250
③ 流程→Skill 操作步骤从 MEMORY 迁到 skill ~500+
合计 ~3,375+

关键工具是 OpenClaw 的 Skill Workshop。它让 Agent 能自我管理记忆——日志按需搜索、流程提炼为 skill、迭代优化，形成一个持续减负的闭环。

最终，AGENTS.md 变成一份薄薄的目录，MEMORY.md 只存真正持久的事实，具体流程交给 skill。Agent 更轻、响应更快、token 花在刀刃上。