OpenClaw优化指南：路由+记忆+编排替代全量上下文注入
OpenClaw 文章封面图
## OpenClaw 默认配置到底慢在哪里
这份仓库在 README 开头就点得很直接：默认 OpenClaw 的主要问题，不是“不会回答”，而是回答前要先消化太多无效上下文。
OpenClaw 每次回复前，都会把工作区里的核心文件注入到提示里。通常就是这些：
* `SOUL.md`
* `AGENTS.md`
* `MEMORY.md`
* `TOOLS.md`
如果这些文件越写越臃肿，结果就是：
* 每条消息要多读 15KB 到 20KB 的上下文
* 复杂任务更容易顶到上下文上限
* 长会话越跑越脏，模型越来越难抓住重点
* 明明是一个执行任务，主模型却一直在做“复读机”
按 README 的自述，这套优化后的对比大致如下：
* 每条消息上下文从 `15-20KB` 压到 `4-5KB`
* 响应时间从 `4-8 秒` 降到 `1-2 秒`
* 单次消息 token 成本从约 `5000` 降到约 `1500`
* 长会话不再明显劣化，并且能并行处理多个任务
这些数字不应该被当作你环境里的固定 benchmark，但它们很清楚地说明了一件事：
**OpenClaw 的瓶颈首先是架构瓶颈，其次才是模型瓶颈。**
OpenClaw 优化前后对比图
## 这份仓库到底改了 OpenClaw 的什么
看完后，觉得最值得抄的不是结论，而是它动刀的位置非常准。基本就三刀。
### 第一刀：把根目录文件从“知识仓库”改成“路由文件”
这份指南最核心的思路是：根目录文件必须变瘦，而且只保留稳定规则。
README 里给了很清楚的目标尺寸：
* `SOUL.md` 控制在 `1KB` 以内
* `AGENTS.md` 控制在 `2KB` 以内
* `MEMORY.md` 控制在 `3KB` 以内
* `TOOLS.md` 控制在 `1KB` 以内
* 总注入上下文尽量压在 `8KB` 以内
这不是洁癖，而是因为这些文件会被频繁注入，每多一行，OpenClaw 每轮都要重新读一遍。
仓库给出的模板非常“OpenClaw 风格”：
* `SOUL.md` 只保留人格、记忆规则和安全边界
* `AGENTS.md` 只保留决策树、何时拉起子袋、何时并行
* `MEMORY.md` 不再放长文，只放指向 `vault/` 的索引
* `TOOLS.md` 只写工具名和一句话用途
比如它在 `SOUL.md` 里强调的一条规则就非常关键：
* 涉及过去的项目、人物、决策时，先跑 `memory_search`
它在 `AGENTS.md` 里强调的另一条也很关键：
* 代码任务一旦超过几个文件或几十行，就不要让主模型自己硬写，直接拉子袋
这就意味着，OpenClaw 的根目录文件从“资料堆放区”变成了“决策路由层”。
OpenClaw 根目录文件瘦身图
### 第二刀：把 `MEMORY.md` 从百科全书改成目录
默认思路里，很多人喜欢把各种背景、项目历史、偏好、日志都堆进 `MEMORY.md`，觉得“让模型一直看着它，记得更牢”。
这份仓库反过来做：
* `MEMORY.md` 只做目录
* `memory/` 放更容易被命中的结构化摘要
* `vault/` 放完整项目文档、研究记录、人物档案、决策沉淀
README 里给出的三层结构非常清楚：
```
MEMORY.md
memory/
projects.md
people.md
decisions.md
vault/
projects/
people/
decisions/
lessons/
reference/
research/
```
真正有价值的点在于，它不是只讲“分层存储”，而是把 OpenClaw 的本地记忆链路也补上了：
* 用本地 Ollama 提供 embedding
* 拉取 `nomic-embed-text`
* 让 OpenClaw 直接在 `localhost:11434` 上使用它
* 通过 `memory_search()` 把最相关的片段取回来
按照 README 的写法，这一步甚至不需要你做复杂配置，OpenClaw 会直接探测本地 Ollama。作者给出的描述是，`memory_search()` 的代价只有几十毫秒级，远低于把整份长文反复塞进上下文的成本。这个差异一旦放到长会话里，收益会非常明显。
更重要的是，这让 OpenClaw 的记忆方式从：
* “把所有东西永远带在身上”
变成了：
* “我知道东西在哪里，需要时再拿”
这才是适合长期运行 Agent 的记忆方式。
OpenClaw 三层记忆架构图
### 第三刀：让主模型做编排，不做重活
仓库第三个非常贴 OpenClaw 的点，是它没有把“主模型更强”误解成“主模型应该做一切”。
README 里给出的角色分工很直接：
* 你是给方向的人
* OpenClaw 主模型是协调者
* 子袋是执行者
也就是说，主模型负责：
* 理解目标
* 判断优先级
* 规划步骤
* 汇总结果
而不是亲自去做所有这些事情：
* 扫描大量文件
* 写大段代码
* 跑信息搜集
* 处理多个独立任务
模板里的 `AGENTS.md` 甚至把决策树写得很直白：
* 过去项目、人、决策相关问题，先 `memory_search`
* 代码任务超过阈值，拉 coding 子袋
* 研究任务，拉 research 子袋
* 两个以上彼此独立的任务，默认并行
它给的 OpenClaw 写法也很具体，就是用 `sessions_spawn(...)` 来做子袋拉起。
这一步为什么重要？因为 OpenClaw 一旦把“判断”与“执行”拆开，你就不再需要让最贵的模型去做所有琐事。README 里提到的一个收益是：
* 代码执行任务可以交给更便宜、更快的模型，节省可达数倍
这也是为什么这份仓库一直在强调：优化的是工作流，而不只是模型本身。
OpenClaw 编排与子袋协作图
## 这份指南里最值得照抄的 OpenClaw 细节
如果你真的准备照着改 OpenClaw，下面这些细节比“讲道理”更有用。
### 给 OpenClaw 加一个 fallback model
README 建议的方式很朴素，但非常实用：
```
"fallbackModels": ["your-provider/faster-cheaper-model"]
```
意思很简单：主模型继续负责最重要的判断，但限流、简单任务或者执行型任务，可以让更快更便宜的模型接手。
### 用 `/status` 盯住 reasoning mode
仓库专门提醒了这一点：
* `Off` 最快
* `Low` 是折中
* `High` 质量最好，但会增加额外思考时间
作者自己的偏好是长期开 `High`，因为在复杂调试、架构判断、多步规划里质量提升明显；而上下文瘦身带来的加速，能抵消一部分高推理模式的额外开销。
### 不用的插件要关掉
README 里点名了几个常见插件：
* `memory-lancedb`
* `memory-core`
如果你当前根本没在用，直接关掉，别让它们白白增加系统开销。
### Ollama 只保留真正需要常驻的模型
仓库建议你定期做两件事：
```
ollama ps
ollama stop modelname
```
它的判断很明确：如果只是为了本地向量检索，你真正需要常驻的就只是 `nomic-embed-text`。别让一个大模型长期躺在内存里白占资源。
### 善用仓库自带的模板和 one-shot prompt
这份项目不只是提原则，它还给了可直接抄的模板：
* `SOUL.md`
* `AGENTS.md`
* `MEMORY.md`
* `TOOLS.md`
* 示例 `vault/` 结构
而且 README 底部还给了一段 one-shot prompt，目标就是一次性让 OpenClaw 帮你把这些优化动作跑完。对第一次改工作区的人来说，这一点很实用。
## 如果你今天就要改 OpenClaw，最短路径是什么
如果按这份仓库的思路自己上手，会按下面这个顺序做，不拐弯。
1. 先备份当前 OpenClaw 工作区配置。
2. 把 `SOUL.md`、`AGENTS.md`、`MEMORY.md`、`TOOLS.md` 全部瘦身到目标范围。
3. 创建 `memory/` 和 `vault/` 的目录结构，把长文和历史资料迁过去。
4. 安装 Ollama，并拉取 `nomic-embed-text`。
5. 在 `SOUL.md` 里明确写上：涉及过去项目和决策，先 `memory_search`。
6. 在 `AGENTS.md` 里明确写上：复杂代码、研究、并行任务都走子袋。
7. 给 OpenClaw 增加 fallback model，关掉不用的插件。
8. 用几类真实任务回归测试：过去项目问答、长会话、多任务并行、复杂代码变更。
这份仓库还给了一张 30 分钟清单，核心就是让你确认下面这些都已落地：
* 总上下文在 `8KB` 内
* `MEMORY.md` 是目录，不是文档仓库
* `memory_search()` 已经成为默认习惯
* `vault/` 目录已经承担长期知识
* 主模型开始真正做 orchestration
OpenClaw 30 分钟落地清单
## 这份指南最适合什么样的 OpenClaw 用户
总的来说，这份仓库对三类人最有价值：
* 你用 OpenClaw 处理的是长任务，而不是一句话问答
* 你希望它记住项目、人和历史决策，而不是每次重开就失忆
* 你已经在做多步工具调用、多袋协作，成本和延迟开始变得明显
如果你只是拿 OpenClaw 做轻量聊天，这套改造的收益不会这么夸张。但只要你已经进入“项目型使用”阶段，这份指南的价值就很高。因为它指出的不是某个提示词技巧，而是一个对 OpenClaw 很关键的设计原则：
**工作区文件应该是轻量路由，不应该是长期存储。**
这句话，基本可以当成这份仓库的中心思想。
## 写在最后
很多人会把 OpenClaw 变慢，归因到模型不够强、上下文不够长、机器不够快。但 `openclaw-optimization-guide` 给出的答案更像是工程视角：
* 先把常驻上下文变小
* 再把长期知识移出工作区主提示
* 最后让主模型回到“判断和编排”的位置
你会发现，OpenClaw 的体感提升，往往先来自这些结构调整，而不是先来自换一个更大的模型。
需要说明的是，文中提到的数字和收益来自该仓库 README 的作者自述，更适合作为优化方向，而不是硬性 benchmark。不同模型、不同插件组合、不同 OpenClaw 工作区规模，最终表现都会有差异。
### 仓库信息
* GitHub 仓库名：OnlyTerp/openclaw-optimization-guide
* 搜索关键词：OnlyTerp OpenClaw optimization guide
* 使用前建议先通读 README，再对照 `templates/` 目录落地