2026年4月13日 · 阅读 —

一、OpenClaw 优化过程：你实际做了什么

Agent 与 Skills

结论先给：

这段时间你这边围绕 OpenClaw 优化，实际做了 3 条主线：

  1. 主 OpenClaw 运行面优化
    重点是浏览器默认配置、gateway 排障、agent/workspace 隔离、记忆体系落地。

  2. QMD / writer 这条内容生产链的部署与规则化
    重点是把 writer/qmd 跑成一个可持续迭代的“写作专用 agent”，不断把好用的输出规则反写进 skill。

  3. kill / 管控策略优化
    重点不是“动不动 kill 重跑”，而是先做可控、可纠偏、可回看，必要时再 kill。这个思路在 OpenCode / tmux / process 管理里都出现过。

下面我按「过程 → 方法 → 方案 → QMD → kill」给你收一版。

一、OpenClaw 优化过程：你实际做了什么

1）先处理运行层：把 OpenClaw 先跑稳

最早一批优化，核心是把“能不能稳定跑”先解决掉：

  • 把托管浏览器设成默认 profile：browser.defaultProfile = openclaw
  • 明确 openclaw browser --timeout 10000 status 这种参数位置坑
  • 遇到 gateway service not loaded 时，不是重装，而是：
    • openclaw gateway install
    • openclaw gateway start

这一步的本质不是功能增强，是止损：先把最底层运行面稳定住。
Source: memory/2026-03-05.md#L3

2）再做结构层：把 agent/workspace 隔离

你后面新增了 dailyWork 这种独立 agent，配独立 bot、独立 workspace。

这说明优化思路已经从“修命令”升级成“修架构”：

  • 主 workspace 保持干净
  • 日常工作流单独隔离
  • 避免记忆、配置、上下文互相污染

这是很关键的一步，因为 OpenClaw 一旦开始多 bot、多频道、多任务，不做隔离，后面一定乱。
Source: memory/2026-03-05.md#L17

3）再做长期能力：把记忆体系从“聊天上下文”升级成“文件 + 自动化”

3 月 6 号这波，是一次真正的体系升级：

  • 建立 L0/L1/L2 三层记忆
  • MEMORY.md 做索引入口
  • memory/core.md / user-prefs.md / agent-notes.md 分层
  • 接入 memU 自动化
  • weekly 流程升级到 memU 0.2.x

这一步的意义是：
OpenClaw 不再只是“会话中聪明”，而开始变成“长期可沉淀、可复盘、可迁移”的系统。
Source: memory/2026-03-06.md#L6

二、OpenClaw 优化办法：你这套方法论是什么

我给你提炼成 5 条。

方法 1：先保活，再增强

不是一上来搞 fancy 自动化，而是先解决：

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

这是典型工程打法：可运行 > 可扩展。
Source: memory/agent-notes.md#L3

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

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

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

这套方法很对，因为 AI 系统最怕“脑内约定”。
想长期稳定，就得落文件。

方法 3：复杂问题优先拆成“最小闭环”

你不止一次采用这个打法：

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

这说明你的优化不是“大改一通”，而是：

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

方法 4：把“好结果”反写进 skill

这其实是 QMD 那条线最重要的方法，也逐渐影响整个 OpenClaw 使用方式。

典型例子：

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

这意味着优化不只是“这次写好了”，而是：

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

方法 5：少 kill，多纠偏

在 OpenCode / tmux 那部分，你们其实已经形成了一个很明确的判断：

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

这条非常工程化。
因为 kill 虽然爽，但会丢上下文、丢中间产物、丢调查线索。
Source: ~/.openclaw/agents/writer/qmd/sessions/3bab6b26-a7f4-4c4d-aa87-5ff1218941ce.md

三、OpenClaw 优化方案：可以归纳成哪几个层次

我给你归纳成一个 4 层方案。

方案 A：运行面优化

目标：先稳

包括：

  • gateway install/start/restart 规范化
  • browser profile 默认化
  • 参数坑位收敛
  • 配对/绑定问题明确路径

适合解决“为什么这玩意儿有时像死了”的问题。

方案 B：结构面优化

目标：别串

包括：

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

适合解决“越用越乱”的问题。

方案 C：记忆面优化

目标：别忘、别漂

包括：

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

适合解决“同样的坑反复踩”的问题。

方案 D：交付面优化

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

包括：

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

适合解决“每次都重新教一次”的问题。

四、QMD 部署 / 配置过程：这条线是怎么跑起来的

你说的 “qmd 部署配置过程”，从现有记录看，核心不是单独一套“部署脚本文档”，而是 writer agent + qmd 会话目录 + skill 规则持续收敛 这条线。

目前能确认的落地形态：

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 的关键配置过程，其实是“规则进 skill”

这条线真正关键的不是 index.yml 本身，而是这些动作：

a. 只使用特定 skills 目录

当时明确收敛为只用：

  • [本机路径已隐藏]

然后还修正了 symlink，让技能都能从这个目录被发现。

b. /skills 行为固化

你要求：

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

这个规则被写进 SOUL.md。

c. 输出质量规则持续入 skill

典型包括：

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

这说明 QMD 的“配置过程”，本质上是：

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

4）QMD 这条线的优化成果

最后这条线形成了几个稳定能力：

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

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

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

五、kill：你这边实际形成的 kill 策略

你最后提到 “+ kill”，我理解你是想把这块也一起梳理。

1）OpenClaw / process 维度

最早明确的一条经验是：

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

这已经形成了标准后台任务管理方式。
Source: memory/archive/2026-02-14.md#L21

2）OpenCode / tmux 维度

后面又进了一层：

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

这个思路比“发现不对就重开”成熟很多。

3）kill 的正确定位

按你这套实践，kill 应该是三层策略里的第 3 层：

第 1 层：看日志

  • 到底卡哪
  • 是权限、认证、网络、UI、MCP、浏览器，还是任务本身

第 2 层：纠偏

  • 给补充指令
  • 切更小任务
  • 改 skill 规则
  • 改配置

第 3 层：kill

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

这个顺序是对的。

六、我帮你收成一句“总复盘”

如果把这段时间的 OpenClaw 优化浓缩成一句话，就是：

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

再翻成更工程的话：

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

七、给你一个可直接复用的整理版提纲

如果你要拿去写文档/文章/复盘，我建议直接用这个结构：

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

1. 为什么要优化

  • 配置散
  • 输出飘
  • 任务链长
  • 重复劳动多

2. 第一阶段：运行面优化

  • browser defaultProfile
  • gateway install/start
  • 参数坑排查
  • pairing/binding 规范

3. 第二阶段：结构面优化

  • dailyWork agent 隔离
  • workspace 分层
  • bot/channel 解耦

4. 第三阶段：记忆面优化

  • 文件三层记忆
  • memU 自动化
  • cron 固化 daily/weekly/monthly

5. 第四阶段：QMD / writer 生产线优化

  • writer/qmd 独立会话链
  • skills 目录收敛
  • /skills 菜单规则
  • skill 规则回写
  • 版本化交付

6. kill 策略

  • 先 log
  • 再 steer / send-keys
  • 最后 kill

7. 最终方案

  • 稳定运行
  • 可隔离
  • 可召回
  • 可复盘
  • 可复制

如果你要，我下一步可以直接帮你做两种成品之一：

  1. 整理成一篇完整文章版
  2. 整理成一份可执行的 md 文档版（更偏内部 SOP / 复盘文档）

你回我一句：
“出文章版” 或 “出SOP版”，我直接继续。

Continue reading

继续阅读