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

很多人折腾 OpenClaw，第一反应都是加功能、装技能、接更多 bot、接更多渠道。刚上手的时候，这种冲动特别正常。谁都会先盯着“能不能干更多活”看，觉得功能越多，系统就越强。但真跑一阵子就会发现，问题根本不在“功能够不够多”，而在另外几件更底层的事：它到底稳不稳，多 agent 会不会串，经验能不能留住，这次调好的东西下次会不会又重来一遍。

这段时间对 OpenClaw 的优化，基本也是沿着这个路径一点点往前推的。前半段解决“先跑起来别死”，中段解决“别越跑越乱”，后半段解决“好的结果能不能沉淀成默认能力”。如果硬要用一句话概括这轮优化，核心不是做了多少自动化，而是把 OpenClaw 从一个能用的工具，慢慢收成一个可运行、可隔离、可沉淀、可复用的系统。

这种变化说起来不炸裂，甚至不够性感。因为它不太像“又接了一个大模型”或者“又打通了一个新渠道”那种看得见的进展，它更像在修地基：白天看不出多大变化，真到下雨的时候，才知道地基稳不稳。

---

第一阶段，先别谈上限，先把运行层救活

最早那批优化其实都不酷，甚至有点土。它们不解决“系统的上限”，只解决“别死”。但说实话，真正长期能用的系统，很多时候就是靠这种土办法活下来的。

浏览器这块最先动的，就是把托管浏览器设成默认 profile，统一切到 openclaw。这个动作看着不大，实际是在给后面的自动化打地基。因为浏览器一旦混着用，登录态会乱串，环境会不一致，一个任务跑的是个人 Chrome，另一个任务又跑的是托管实例，最后你连问题出在哪都说不清。于是这里先把口径统一：浏览器归浏览器，个人环境归个人环境。别混。混了就一定出脏活。

CLI 的参数坑也是那种不大但非常烦的问题。像 openclaw browser --timeout 10000 status 这种命令，--timeout 得放在子命令前。它不是“不会”，而是“老忘”。这类问题最恶心的地方在于，它会一点一点抬高排障成本。每次都不是大错，但每次都能让你多浪费十分钟。时间一长，人的耐心就被这种小坑啃掉了。

还有一个特别典型的误判，是看到 openclaw gateway restart 报 Gateway service not loaded，第一反应就是“环境是不是坏了，要不要重装”。后来才慢慢收敛出更对的处理路径：先 openclaw gateway install，再 openclaw gateway start。这一步的价值不在命令本身多高明，而在于它纠正了判断。很多时候系统没坏，只是服务没挂上。先分清“服务没加载”和“系统坏了”，能少走很多弯路。这一阶段的本质不是增强，而是止损。先把最底层运行面稳定住，别让整个系统动不动像死了一样。

如果把这一阶段再翻成更偏技术的手势，其实可以收成一套很朴素的排障顺序。先看服务状态，再看配置绑定，再看浏览器侧环境，最后才去怀疑安装本身。像 gateway 这条线，至少应该固定成这样一套检查动作：先跑 openclaw gateway status 看服务在不在，再根据结果决定是 openclaw gateway start 还是 openclaw gateway install；如果服务起来了但调用仍旧异常，再去看 account 绑定、bot token、以及当前会话是不是打到了对的 agent 上。浏览器这条线也一样，先确认默认 profile 是否已经切到托管实例，再确认登录态在哪个 profile 里，最后再看命令参数顺序是不是写对了。

这一阶段的操作拆解

步骤	目标	典型动作	产出/判断标准
1	确认 Gateway 是否存活	openclaw gateway status	能看到服务状态，不再盲猜
2	修复 service 未加载	openclaw gateway install / start	Gateway 进入可启动状态
3	收敛浏览器执行环境	统一默认 profile 到 openclaw	浏览器自动化不再混用个人环境
4	修 CLI 参数坑	固定参数顺序写法	同一命令不再反复踩坑

典型命令

openclaw gateway status
openclaw gateway install
openclaw gateway start
openclaw gateway restart

openclaw browser status
openclaw browser --timeout 10000 status

运行层最小验证

先执行 openclaw gateway status，确认服务已经 loaded 且 running；再执行一次最小命令，像 openclaw gateway restart 或浏览器 status，验证 CLI 到服务这一跳已经通；最后再用一个真实任务压一下浏览器链路，看登录态、默认 profile、timeout 参数是否真按预期工作。只有这三步都过了，才能说“运行面稳定”这件事成立。

---

第二阶段，问题已经不是命令了，而是结构

如果说第一阶段是在救火，那第二阶段开始，事情就已经不是修命令了，而是在修架构。最明显的标志，就是 agent / workspace 隔离开始变成主问题，而不是附属优化。

后面新增了像 dailyWork 这种独立 agent，配了独立 bot、独立 workspace。这个动作特别能说明问题。因为一开始很多人用 OpenClaw，默认都是一个 workspace 兜天下。刚开始当然没感觉，毕竟东西少，脑子还能记住。但只要任务一多，记忆会开始串，技能会开始串，日常工作和实验流会混在一起，配置、上下文、文件互相污染。系统不是一下子炸掉，而是慢慢脏掉。最难受的恰恰就是这种慢慢脏。

所以后面的优化思路已经变了。不是让命令更顺，而是让不同工作流各回各位。主 workspace 保持干净，日常流单独隔离，不同 bot 对应不同 agent，不同 agent 对应不同职责。这种分层听上去像“麻烦”，但它其实是在给长期运行买保险。

OpenClaw 一旦开始多 bot、多频道、多任务，不做隔离，后面一定乱。这不是习惯问题，是系统形态决定的。单 agent 时代，很多脏活还能靠脑子顶住。多 agent 之后，如果还想靠“我记得住”，基本就是等着翻车。第二阶段真正做的事，其实就一句：让不同工作流别互相踩。

这一步做完之后，系统才第一次看起来像是能长期跑，而不是只能偶尔跑通。

如果把这阶段补成技术操作，最关键的是把“隔离”从概念变成默认配置。一个可执行的做法，是每新建一个 agent，就同时落实四件事：独立 workspace、独立 bot、独立 binding、独立职责边界。不要再“先混着用，乱了再拆”，而是从第一天就把目录、通道和记忆分开。这样做的好处，不只是减少串味，更是把排障半径缩小。一个 agent 出事，不至于把整个系统一起拖下去。

更偏工程的验证方式也应该跟上。第一步，检查 openclaw.json 里 agent list、bindings、telegram accounts 是否一一对应；第二步，分别在两个 bot 上发最小请求，看回复是否稳定落到各自 workspace；第三步，在一个 agent 里写入明显的偏好或记忆锚点，再去另一个 agent 验证它不应该看到这些东西。只有这种“故意制造污染，再确认没串过去”的验证做过，隔离才算真的成立。

这一阶段的操作拆解

步骤	目标	典型动作	产出/判断标准
1	新建独立 agent	配置 id + workspace	agent 不再和主空间混用
2	绑定独立 bot/channel	单独配置 account/binding	消息流与职责边界清晰
3	隔离技能与记忆	不同 workspace 独立维护	不同流不再互相污染
4	做交叉污染验证	刻意写入锚点再交叉测试	确认“不串”不是错觉

配置示意

{
  "id": "dailyWork",
  "workspace": "[本机路径已隐藏]
}

结构层验证动作

先检查 agent list、bindings、telegram accounts 是否一一对应，再在两个 bot 上分别发最小请求，看回复是否稳定落到各自 workspace；最后在一个 agent 里写入一条明显偏好或临时记忆，再去另一个 agent 里验证看不到它。只有这种“故意压污染”的测试过了，隔离才算成立。

---

第三阶段，真正值钱的是把“记忆”从会话里搬出来

到三月初这波，OpenClaw 的优化已经不再只是“这次会话里聪明一点”，而是在往“长期有脑子”走。这里最关键的一步，是把记忆从聊天上下文，升级成文件系统加自动化。

落地方式其实很朴素，就是把记忆拆出层级。MEMORY.md 做索引入口，memory/core.md 放核心规则，memory/user-prefs.md 放稳定偏好，memory/agent-notes.md 放经验和踩坑，memory/YYYY-MM-DD.md 记每日流水。看起来像整理文档，实际上是在做一件特别重要的事：把“记忆”从临时上下文，变成有层次的文件系统。

这一步一做，系统就开始变味了。它不再只是“这轮对话里像懂你”，而是变成“即使会话断了，很多关键东西也还在”。后面再接上 memU 做自动提炼，daily 记录、weekly 整理、monthly 分析这些能力一补上，整个系统的长期性才算真正长出来。

这波升级最值钱的地方，在于它不是多了一坨日志，而是让系统开始具备几种很关键的能力：可沉淀，可复盘，可迁移，可生长。聊完就没了的东西，开始能留住；以前同一个坑会反复踩，现在至少知道上次怎么踩的。说白了，这一步让 OpenClaw 从“会话型助手”，慢慢长成了“长期工作系统”。

如果把这一段也翻成技术动作，它其实是一套“记忆落盘策略”。什么进 MEMORY.md，什么进 memory/YYYY-MM-DD.md，什么留给 memU 的日/周/月提炼，都得有边界。最稳的做法不是全都记，而是分层记：稳定规则进长期文件，短期流水进日期文件，自动摘要只做提炼不做真相源。这样你既能保留原始证据链，也能让系统逐渐长出结构化经验。

验证这套记忆系统是否真的生效，也应该有个最小闭环。比如当天写进 memory/YYYY-MM-DD.md 一条明确的踩坑记录，隔天再让系统通过 MEMORY 索引或 memU 提炼结果回忆它；或者换一个新会话，验证是否还能从文件层拿回之前的规则和偏好。如果只有“文件写上了”，却没有“下次能用出来”，那还不算记忆系统，只算文档堆积。

记忆结构示意

MEMORY.md
memory/core.md
memory/user-prefs.md
memory/agent-notes.md
memory/2026-03-12.md

这一阶段的操作拆解

步骤	目标	典型动作	产出/判断标准
1	分层落盘	长期规则 / 短期流水分开写	记忆结构清晰
2	接自动提炼	daily / weekly / monthly	记忆开始可复盘
3	保留真相源	原始文件不被摘要覆盖	证据链仍在
4	做读取验证	新会话再取回旧信息	证明“记住了”

---

回头看，这套优化背后的方法其实不复杂

如果把这一轮优化提炼成方法论，说穿了并不玄。第一条很土，但特别重要：先保活，再增强。不是一上来就搞 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 出稿，再一点点补规则。这说明优化不是大改一通，而是先跑通一单，再把经验反写成规则。这个顺序很稳，因为它避免了“还没跑通就先抽象”。

第四条，是把满意结果反写进 skill。/skills 菜单行为写进 SOUL.md，weekly-ai-news 的输出结构写回 skill，wx-article-rewrite-humanize-pro 的风格、版本规则、技术文章规则也写回 skill。这个动作的价值不在“这次写好了”，而在于再往前多走一步，把一次满意交付，变成下次默认能力。这才是真正的系统化。

第五条，是少 kill，多纠偏。在 OpenCode / tmux 那部分，后面慢慢形成了很明确的判断：agent 跑偏时，优先 tmux send-keys 中途纠偏，不要第一反应 kill 重跑。kill 是最后手段，不是默认手段。因为 kill 虽然痛快，代价也很真实：丢上下文，丢中间产物，丢调查线索，丢掉“为什么会跑偏”的证据。成熟一点的做法，不是“出问题立刻重开”，而是先看日志，再纠偏，最后再 kill。这个顺序，是对的。

如果要把这套方法做成更技术化的团队规则，它其实可以落成一个很简单的执行模板：每次新增能力，先补运行验证；每次新增 agent，先补隔离验证；每次新增记忆策略，先补读取验证；每次新增输出规范，先把规则写回 skill；每次要 kill 之前，先保留日志和中间产物。这样方法论就不再只是“感悟”，而会变成工程操作。

---

再往上收一层，这轮优化其实可以看成四层方案

如果从方案层面看，这轮 OpenClaw 优化大概可以收成四层。第一层是运行面优化，目标只有一个：先稳。gateway install / start / restart 规范化，browser profile 默认化，参数坑位收敛，pairing / binding 路径明确，这一层解决的是“为什么这玩意有时候像死了”。

第二层是结构面优化，目标是：别串。多 agent 分离，多 workspace 分离，bot / channel / binding 独立，日常流与主控流解耦，这一层解决的是“为什么越用越乱”。

第三层是记忆面优化，目标是：别忘、别漂。文件三层记忆，memU 自动提炼，daily / weekly / monthly cron，重要规则不放脑子里，这一层解决的是“为什么同样的坑老是反复踩”。

第四层是交付面优化，目标是：一次经验，长期复用。skill 驱动输出，文章 / 周报 / 翻译 / 改写规则回写 skill，版本号管理，技术文章模板化增强，表格、代码块、验证步骤标准化，这一层解决的是“为什么每次都像第一次”。

这四层一旦立住，OpenClaw 才不再只是“一个能干活的 AI 工具”，而开始像一套真正在运行的系统。

如果更偏技术一点去落方案，这四层其实都能配一段标准动作。运行面有 service / browser / binding 的启动与验证手册，结构面有新 agent 的创建模板和隔离检查表，记忆面有文件分层与自动提炼边界，交付面有 skill 回写、版本命名、验证步骤模板。真正长期跑得稳的系统，最后都不是靠一个聪明人顶着，而是靠这类标准动作不断重复。

四层方案对照表

层级	目标	解决的问题	典型动作
运行面	先稳	为什么它像死了	gateway/browser/binding 排障
结构面	别串	为什么越用越乱	多 agent / 多 workspace 隔离
记忆面	别忘	为什么同坑反复踩	文件分层 + 自动提炼
交付面	可复用	为什么每次像第一次	skill 回写 + 版本规范

---

QMD 这条线最值钱的，不是装好了，而是跑成生产线了

QMD 这条线如果顺着现有记录去看，真正值钱的不是“部署脚本有没有跑通”，而是它最后已经被收成了一个写作专用 agent。它承担的不只是写稿，而是公众号技术文章、OpenClaw / OpenCode / 浏览器 / 记忆系统整理文、skill 规则持续改写、周报、翻译、改写、humanize 这些一整条内容生产链。也就是说，QMD 最后不是“装了个写稿工具”，而是变成了内容生产、规则沉淀、版本迭代的专用通道。

QMD 的关键配置过程，本质上也不是“填了哪些参数”，而是规则收敛。后面已经明确只使用固定的 skills 目录 [本机路径已隐藏]，还专门修了 symlink，保证技能都能从这个目录被发现。这个动作解决的不是路径问题，而是“写作环境到底以谁为准”。

紧接着，/skills 交互也被固化了。后来明确要求，发 /skills 就返回“技能菜单（只用 workspace-writer/skills）”。这类行为最终写进了 SOUL.md。它很重要，因为它把“使用习惯”升级成了“系统行为”。

再往后，真正拉开差距的是输出质量规则持续写回 skill。weekly-ai-news 不能只给链接，必须有描述、表格、四条线拆解；wx-article-rewrite-humanize-pro 要求去 AI 味、三国风、朋友圈底层价值观、少总结少清单；技术文章必须有表格、代码块、安装步骤、验证步骤；同一篇文章多次修改不能覆盖，必须 -v2/-v3。这条线一旦形成，QMD 的价值就不再是“会写”，而是“写出来的东西越来越像一条稳定生产线”。

所以 QMD 最终跑出来的成果，不只是有专门的 writer agent，有固定的 skills 工作目录，有 /skills 交互习惯，有会话留痕，有技能级规则沉淀，有版本化交付规范，而是它已经进入了一种可持续维护的写作生产线状态。真正优化的不是“装好了”，而是“跑成生产线了”。

如果把 QMD 这条线补成技术操作，它也完全可以写成一个标准落地过程。先收敛 skills 目录，再修 symlink，保证发现路径唯一；然后把 /skills 菜单行为固化到 SOUL.md，让交互方式不再漂；接着持续把满意的输出规则写回对应 skill，把“这次写得不错”变成“下次默认这样写”；最后通过 -v2/-v3 这种版本号规范，把同一篇文章的迭代历史留住。路径、菜单、规则、版本，这四件事一连起来，写作系统就不再是“人盯着 AI 写”，而是开始像可维护的软件模块。

对这条线的验证也不难。第一步，看 /skills 是否稳定只返回 workspace-writer/skills；第二步，拿一篇文章连续改两次，确认会生成 -v2/-v3 而不是覆盖；第三步，改一条 skill 规则，再用下一篇稿子验证输出是否真的跟着变。这三步只要能稳定通过，QMD 基本就已经不是“装好的工具”，而是“跑起来的生产线”。

QMD 最小 SOP

阶段	标准操作	验证点
目录收敛	只保留 workspace-writer/skills 为有效目录	技能发现路径唯一
菜单固化	/skills 固定返回 workspace 私有菜单	不再混入别的目录技能
规则回写	满意输出反写 skill / SOUL / USER / MEMORY	下次输出风格自动继承
版本交付	同文多次修改走 -v2/-v3	不覆盖旧稿，可追溯

---

kill 没被禁用，只是终于被降级成最后手段

kill 这条线也特别值得单独收一下。因为成熟系统和半成熟系统的区别，很多时候就体现在“遇到问题第一反应是重启，还是先理解”。

在 OpenClaw / process 这一侧，早期已经形成了一套比较明确的后台任务管理手势：先用 exec background:true 跑，再通过 process log / poll / submit / kill 去管理 session。这意味着后台任务开始有标准动作，不再是随便开、随便等、随便重来。

到了 OpenCode / tmux 这一侧，思路又往前收了一层：尽量不要直接 kill，先用 tmux send-keys 中途纠偏。只有任务彻底跑歪、挂死、上下文不可救的时候，才再 kill。这套思路明显成熟得多，因为它把 kill 从“默认操作”降级成了“兜底动作”。

如果把 kill 的正确定位说得更清楚一点，它应该排在三层策略里的第三层。第一层是看日志，先确认到底卡在哪：权限、认证、网络、UI、MCP、浏览器，还是任务本身。第二层是纠偏，如果还救得回来，就先救：补充指令、切更小任务、改 skill 规则、改配置、中途 steer 或 send-keys。第三层才是 kill，只有进程死锁、状态脏了、session 不可恢复、必须清场重来的时候才值得动手。

这个顺序特别重要。因为系统越复杂，就越不能把“重启一切”当成本能。重启当然痛快，但它往往也顺手抹掉了最值钱的东西——错误现场和演化线索。

这条线如果写成更技术的操作手册，大概就是这样：先用 process log 和 process poll 看任务是不是还在推进；如果只是卡住或跑偏，优先发补充指令、缩小任务、或者在 tmux 里 send-keys 纠偏；只有确认进程僵死、状态已经脏掉、继续救反而会扩大污染时，才 process kill。kill 的意义不是快，而是明确承认“这个现场已经不可救，应该保留证据后重开”。

# 后台启动
openclaw exec --background "<command>"

# 观察
openclaw process log <sessionId>
openclaw process poll <sessionId>

# 必要时再结束
openclaw process kill <sessionId>

这组动作本身不复杂，难的是忍住不要一遇到异常就直接跳到最后一步。

---

最小 SOP：把这轮优化收成标准动作

如果把整轮优化压成一个最小 SOP，它其实可以长成下面这样。重点不是“背下来”，而是以后每次加能力、接新链路、上新 agent，都按这个顺序来。

场景	最小 SOP	通过标准
Gateway 异常	status → install/start → restart → 再查 binding	服务稳定可用
浏览器异常	查默认 profile → 查登录态 → 查参数顺序	浏览器链路可重复执行
新 agent 接入	建 workspace → 建 bot → 建 binding → 做交叉污染验证	不串味
记忆升级	分层落盘 → 接自动提炼 → 新会话回读验证	真能记住
写作生产线	固定 skills 目录 → 固化 /skills → 回写规则 → 版本交付	输出稳定复利
跑偏任务	先日志 → 再纠偏 → 最后 kill	不中断证据链

---

验证清单：怎么确认这条链已经稳定了

部署完成后，最怕的不是“今天能跑”，而是“明天还一样能跑”。所以这轮优化如果要验收，至少应该过下面这套检查。它不复杂，但每一条都很实。

验证项	检查方式	通过标准
Gateway 存活	openclaw gateway status	服务 loaded + running
浏览器隔离	跑一次 status + 真实登录任务	不混用个人环境
Agent 隔离	双 bot 分别发最小请求 + 污染测试	互不串味
记忆生效	写入 daily 记录后新会话回读	能取回旧规则/旧记录
Skill 生效	改一条 skill 规则再出一篇稿	输出跟着变
版本交付	同文连续修改两次	生成 -v2/-v3，不覆盖
kill 策略	故意制造一个卡住任务	能先日志/纠偏，再决定是否终止

如果这几条能稳定通过，那你优化出来的就不是“这几天看起来挺顺”，而是一条真正开始具备长期运行条件的系统。

---

最后回头看，这轮优化到底优化出了什么

如果把这段时间的 OpenClaw 优化压成一句总复盘，大概可以这么说：前半段在修“能不能跑”，中段在修“会不会乱”，后半段在修“好结果能不能沉淀成默认能力”。再翻成更工程一点的话，就是五个词：运行稳，结构清，记忆长，交付可复用，kill 最后再用。

这五件事拆开看都不惊艳，没有哪一条像“全新革命”，但真正有价值的地方就在于它们是连着的。连起来之后，OpenClaw 不再只是一个“能聊天、能跑工具、能接渠道”的 AI 系统，而是开始有一点像真正的工作系统了。它知道怎么运行，知道怎么隔离，知道怎么留痕，知道怎么复用，也知道什么时候该忍住别乱 kill。

这才是这轮优化最值得留下来的东西。因为很多系统一开始都挺聪明，但真正难的从来不是“会不会”，而是能不能稳定跑，能不能长期用，能不能在人不盯着的时候别乱，能不能把一次次修出来的经验留下来。OpenClaw 这轮优化，真正做成的，不是某个单点功能，而是把这些底层问题逐步收住了。从能跑，到可控，到可沉淀。这条路不花哨，但值钱。因为系统一旦走到这一步，后面每一次新增能力，才开始有复利。

---

#OpenClaw #Agent #工程化 #复盘 #工作流 #记忆系统 #Skills #QMD #隔离 #可控