OpenClaw 优化复盘：从能跑，到可控，到可沉淀

很多人折腾 OpenClaw，第一反应都是加功能、装技能、接更多 bot、接更多渠道。 但真跑一阵子就会发现，问题根本不在“功能够不够多”，而在另外几件更底层的事：

• 它到底稳不稳
• 多 agent 会不会串
• 经验能不能留住
• 这次调好的东西，下次会不会又重来一遍

我这段时间对 OpenClaw 的优化，基本也是沿着这个路径往前推的。 前半段解决“先跑起来别死”，中段解决“别越跑越乱”，后半段解决“好的结果能不能沉淀成默认能力”。

如果用一句话概括这轮优化，核心不是“做了多少自动化”，而是：

把 OpenClaw 从一个能用的工具，慢慢收成一个可运行、可隔离、可沉淀、可复用的系统。

---

一、第一阶段：先把运行层跑稳

最早一批优化，其实都不酷，甚至有点土。 它们不解决“上限”，只解决“别死”。

1. 托管浏览器设成默认 profile

浏览器这块最先做的，是把默认 profile 切到 openclaw。 这一步看着很小，实际上是在给后面的浏览器自动化打地基。

因为浏览器一旦混着用，很容易出现：

• 登录态乱串
• 环境不一致
• 一个任务用的是个人 Chrome，另一个任务用的是托管实例
• 最后你都不知道问题出在哪

所以这里先统一口径：浏览器归浏览器，个人环境归个人环境。

---

2. 把 CLI 的参数坑踩平

比如这个很典型：

openclaw browser --timeout 10000 status

这里 --timeout 得放在子命令前。 这种坑不大，但特别烦，因为它不是“不会”，而是“老忘”。 这类问题不解决，后面排障成本会被无限放大。

---

3. 遇到 gateway service not loaded，不重装，先修服务

这个点也很关键。

当时碰到：

• openclaw gateway restart
• 提示 Gateway service not loaded

第一反应很容易是“环境坏了”“要不要重装”。 但后来收敛出来的正确处理路径是：

openclaw gateway install
openclaw gateway start

这一步的价值，不是多高明，而是把“误判”改掉了。 很多时候系统没坏，只是服务没挂上。 先分清“服务没加载”和“系统坏了”，能少走很多弯路。

这阶段的本质不是增强，而是止损。 先把最底层运行面稳定住，别让整个系统动不动像死了一样。

---

二、第二阶段：从修命令，升级到修结构

如果说第一阶段是“救火”，那第二阶段开始，就已经不是修命令了，而是修架构。

最明显的标志，就是 agent / workspace 隔离。

1. 新增独立 agent：dailyWork

后面新增了 dailyWork 这种独立 agent，配了独立 bot、独立 workspace。 这一步其实很说明问题。

因为一开始很多人用 OpenClaw，都是默认一个 workspace 兜天下。 能跑的时候没感觉，东西一多就开始出问题：

• 记忆串了
• 技能串了
• 日常工作和实验流混在一起
• 配置、上下文、文件相互污染

所以后面的优化思路，已经不是“让命令更顺”，而是：

• 主 workspace 保持干净
• 日常流单独隔离
• 不同 bot 对应不同 agent
• 不同 agent 对应不同职责

2. 为什么隔离这么重要

OpenClaw 一旦开始多 bot、多频道、多任务，不做隔离，后面一定乱。 这不是使用习惯问题，是系统形态决定的。

单 agent 时代，很多脏活还能靠脑子顶住。 多 agent 之后，如果还想靠“我记得住”，基本就是等着翻车。

所以这阶段的优化，本质是在做一件事：

让不同工作流各回各位，别互相踩。

这一步做完，系统才开始真正具备“长期跑”的可能。

---

三、第三阶段：把记忆从聊天上下文，升级成文件系统 + 自动化

3 月 6 号这波，是一次真正的体系升级。 因为到这里，OpenClaw 已经不再只是“这次会话里聪明”，而开始往“长期有脑子”走。

1. 建立三层记忆结构

这里落地的是 L0 / L1 / L2 三层记忆：

• MEMORY.md：索引入口
• memory/core.md：核心规则
• memory/user-prefs.md：稳定偏好
• memory/agent-notes.md：经验和踩坑
• memory/YYYY-MM-DD.md：每日流水

这套结构的意义很直接： 把“记忆”从临时上下文，变成有层次的文件系统。

2. 接入 memU 自动化

光有文件还不够，后面又接了 memU 做自动提炼：

• daily 记录
• weekly 整理
• monthly 分析

这一步做完以后，系统开始具备几种很关键的能力：

• 可沉淀：不是聊完就没了
• 可复盘：知道以前怎么处理过
• 可迁移：换机器、换实例，记忆还在
• 可生长：不是一坨日志，而是逐步变成结构化经验

这一步其实是整个 OpenClaw 优化里最值钱的一步。 因为它让系统从“会话型助手”，慢慢长成“长期工作系统”。

---

四、这套优化背后的方法论，其实很朴素

如果把这一轮优化提炼成方法，不复杂，基本就 5 条。

---

方法一：先保活，再增强

不是一上来就搞 fancy 自动化，而是先看最底层几件事：

• gateway 能不能起来
• browser 能不能连上
• 参数有没有坑
• 绑定是不是对的

这是一种很工程的顺序：

可运行 > 可扩展

很多系统不是死在能力不足，而是死在底层不稳。

---

方法二：能文件化的，别只靠上下文

后面大量动作其实都在做同一件事：

• 规则写进 SOUL.md
• 偏好写进 USER.md
• 长期事实写进 MEMORY.md
• 每日流水写进 memory/YYYY-MM-DD.md
• skill 规则直接改 SKILL.md

这套打法对 AI 系统尤其重要。 因为 AI 最怕的不是“不会”，而是“你以为它记得”。

脑内约定永远不稳定。 想长期稳定，就得落文件。

---

方法三：复杂问题先拆成最小闭环

这个方法你这边其实反复在用。

比如：

• OpenClaw → OpenCode：先跑最小任务验证链路
• weekly-ai-news：先解决“不能只给链接”这个最小问题
• writer/qmd：先能稳定按 skill 出稿，再一点点补规则

这说明优化不是大改一通，而是：

先跑通 1 单，再把经验反写成规则。

这个顺序很稳，因为它避免了“还没跑通就先抽象”。

---

方法四：把满意结果反写进 skill

这是 QMD 那条线最重要的方法，也逐渐变成整个 OpenClaw 的通用套路。

典型例子有几个：

• /skills 菜单行为写进 SOUL.md
• weekly-ai-news 的输出结构写回 skill
• wx-article-rewrite-humanize_pro 的风格、版本规则、技术文章规则写回 skill

这个动作的价值在于，它不满足于“这次写好了”，而是继续往前做一步：

把一次满意交付，变成下次默认能力。

这才是真正的系统化。

---

方法五：少 kill，多纠偏

在 OpenCode / tmux 那部分，后面其实形成了很明确的判断：

• agent 跑偏时，优先 tmux send-keys 中途纠偏
• 不要第一反应 kill 重跑
• kill 是最后手段，不是默认手段

这条看起来只是操作习惯，实际上很关键。 因为 kill 虽然痛快，但代价也很真实：

• 丢上下文
• 丢中间产物
• 丢调查线索
• 丢掉“为什么会跑偏”的证据

所以成熟一点的做法，不是“出问题立刻重开”，而是：

1. 先看日志
2. 再纠偏
3. 最后再 kill

这个顺序，是对的。

---

五、把这些优化收成一套四层方案

如果从方案层面总结，这轮 OpenClaw 优化可以收成四层。

---

方案 A：运行面优化

目标只有一个：先稳

包括：

• gateway install / start / restart 规范化
• browser profile 默认化
• 参数坑位收敛
• pairing / binding 路径明确

这层解决的是：

为什么这玩意儿有时候像死了。

---

方案 B：结构面优化

目标是：别串

包括：

• 多 agent 分离
• 多 workspace 分离
• bot / channel / binding 独立
• 日常流与主控流解耦

这层解决的是：

为什么越用越乱。

---

方案 C：记忆面优化

目标是：别忘、别漂

包括：

• 文件三层记忆
• memU 自动提炼
• daily / weekly / monthly cron
• 重要规则不放脑子里

这层解决的是：

为什么同样的坑老是反复踩。

---

方案 D：交付面优化

目标是：一次经验，长期复用

包括：

• skill 驱动输出
• 文章 / 周报 / 翻译 / 改写规则回写 skill
• 版本号管理
• 技术文章模板化增强
• 表格、代码块、验证步骤标准化

这层解决的是：

为什么每次都像第一次。

---

六、QMD 这条线，真正优化的不是“装好了”，而是“跑成生产线了”

你提到的 QMD 部署 / 配置过程，如果从现有记录看，重点其实不在“部署脚本”本身，重点在这条线最后被跑成了一个写作生产系统。

1. QMD 目录已经成型

writer/qmd 这条链现在已经有很清晰的落地形态：

• ~/.openclaw/agents/writer/qmd/sessions/...
• ~/.openclaw/agents/writer/qmd/xdg-config/index.yml
• ~/.openclaw/agents/writer/qmd/xdg-cache/qmd/index.sqlite

这说明它不是随手试试，而是已经是：

• 有配置
• 有缓存
• 有会话存档
• 有可追溯历史

---

2. QMD 的真实定位：写作专用 agent

从会话记录看，这条链后面承担了不少事：

• 公众号技术文章
• OpenClaw / OpenCode / 浏览器 / 记忆系统整理文
• skill 规则持续改写
• 周报、翻译、改写、humanize

也就是说，QMD 最后不是“装了个写稿工具”，而是变成了：

内容生产 + 规则沉淀 + 版本迭代 的专用通道。

---

3. QMD 的关键配置过程，其实是规则收敛

QMD 真正值钱的，不是 index.yml 这类文件本身，而是后面持续发生的几个动作。

a）只使用固定的 skills 目录

后面明确收敛成只用：

[本机路径已隐藏]

而且还修了 symlink，保证技能都能从这个目录被发现。 这个动作很关键，因为它解决的是“写作环境到底以谁为准”。

b）把 /skills 交互固化

你后来明确要求：

• 发 /skills
• 返回“技能菜单（只用 workspace-writer/skills）”

这类行为最后被写进 SOUL.md。

这一步很重要，因为它把“使用习惯”升级成了“系统行为”。

c）把输出质量规则持续写进 skill

这部分其实是整个 writer 线最强的地方。

典型规则包括：

• weekly-ai-news：不能只给链接，必须有描述、表格、四条线拆解
• wx-article-rewrite-humanize_pro：去 AI 味、三国风、朋友圈底层价值观、少总结少清单
• 技术文章：必须有表格、代码块、安装步骤、验证步骤
• 同一篇文章多次修改：不能覆盖，必须 -v2/-v3

所以 QMD 的配置过程，本质上不是“填了哪些参数”，而是：

目录收敛 → 菜单规则 → skill 规则 → 输出标准化

这条线一旦形成，后面就是持续复利。

---

4. QMD 最终跑出来的成果

到最后，这条线形成了几个很稳定的能力：

• 有专门的 writer agent
• 有固定的 skills 工作目录
• 有 /skills 交互习惯
• 有会话留痕
• 有技能级规则沉淀
• 有版本化交付规范

换句话说，QMD 不是“装好了”，而是已经进入：

可持续维护的写作生产线状态。

---

七、kill：不是禁用，而是降级成最后手段

最后你提到的 kill，这块也值得单独收一收。

1. OpenClaw / process 维度

早期比较明确的一条经验是：

• 用 exec background:true
• 再通过 process log / poll / submit / kill 管理 session

这意味着后台任务管理开始有了标准手势。 不是随便开，随便等，随便重来。

---

2. OpenCode / tmux 维度

后面又进一步收敛成：

• 尽量不要直接 kill
• 先 tmux send-keys 纠偏
• 只有任务彻底跑歪、挂死、上下文不可救时再 kill

这套思路明显成熟得多。 因为它把 kill 从“默认操作”，降级成了“兜底动作”。

---

3. kill 的正确定位

按这套实践，kill 应该排在三层策略里的第 3 层。

第 1 层：看日志

先确认到底卡在哪：

• 权限
• 认证
• 网络
• UI
• MCP
• 浏览器
• 还是任务本身

第 2 层：纠偏

如果还救得回来，就先救：

• 给补充指令
• 切更小任务
• 改 skill 规则
• 改配置
• 中途 steer / send-keys

第 3 层：kill

只有这些情况才值得 kill：

• 进程死锁
• 状态脏了
• session 不可恢复
• 必须清场重来

这个顺序很重要。 因为越是复杂系统，越不能把“重启一切”当成本能。

---

八、这轮 OpenClaw 优化，最后到底优化出了什么

如果把这段时间的 OpenClaw 优化压成一句总复盘，我会这么说：

前半段在修“能不能跑”，中段在修“会不会乱”，后半段在修“好结果能不能沉淀成默认能力”。

再翻成更工程一点的话，就是五个词：

• 运行稳
• 结构清
• 记忆长
• 交付可复用
• kill 最后再用

这五件事，单拆开看都不惊艳。 但真正有价值的地方，在于它们连起来之后，OpenClaw 不再只是一个“能聊天、能跑工具、能接渠道”的 AI 系统，而是开始有一点像真正的工作系统了。

它知道怎么运行。 知道怎么隔离。 知道怎么留痕。 知道怎么复用。 也知道什么时候该忍住别乱 kill。

这才是这轮优化最值得留的东西。

---

九、如果接下来还要继续优化，下一步该盯什么

如果沿着现在这条路继续往下走，我会优先盯这几件事：

1. 把运行面排障再模板化

把 gateway / browser / telegram / pairing / binding 的排障路径进一步固化成 SOP。

2. 把 agent 隔离策略做成默认约定

新 agent 不要再“先混着用再拆”，而是从一开始就独立 workspace、独立 bot、独立职责。

3. 把记忆自动化和人工记忆边界再划清

什么该进 memory/*.md，什么只做 memU 内部结构化库，什么必须保留人工真相源，继续收紧。

4. 把 QMD / writer 生产线继续产品化

重点不是“多写几篇”，而是继续把好结果回写进 skill，让生产线自己越来越稳。

5. 把 kill 前的“纠偏动作”再标准化

什么时候先 steer，什么时候先 send-keys，什么时候直接 kill，最好再沉淀成一套统一手册。

---

结尾

很多系统一开始都挺聪明。 但真正难的，从来不是“会不会”，而是：

• 能不能稳定跑
• 能不能长期用
• 能不能在人不盯着的时候别乱
• 能不能把一次次修出来的经验留下来

OpenClaw 这轮优化，真正做成的，不是某个单点功能，而是把这些底层问题逐步收住了。

从能跑，到可控，到可沉淀。 这条路不花哨，但值钱。 因为系统一旦走到这一步，后面每一次新增能力，才开始有复利。