OpenClaw Operating System：不是堆功能，而是养一套能活的系统

很多 AI Agent 系统，最开始都很容易让人上头。

它会调工具。

会开分身。

会接消息通道。

会写配置。

会记东西。

会跑自动化。

会自己查自己。

看上去，能力越来越全。

可一旦真的开始长期使用，另一面就会慢慢冒出来。

任务越来越多。

上下文越来越杂。

规则越来越厚。

日志越来越吵。

自动化越来越散。

最后系统不是更强了，而是更脆了。

它当然还“什么都能做”。

可它已经不太像一个系统了。

更像一堆暂时还能一起转的零件。

所以我们后来不再问一个问题：

> 还能不能再加一个能力？

我们开始只问另一个问题：

> 这套东西，能不能长期活下去？

这就是这篇文章想讲的内容。

不是某个花哨功能。

不是某个新模型。

也不是一份“Agent 最佳实践大全”。

而是我们怎么把 OpenClaw 慢慢收成一套真正能跑、能续、能回头、能复盘的系统。

一句话说透：

> 我们不是在堆功能。我们是在养一套能活的系统。

一、真正的问题，从来不是“功能不够多”

大多数 Agent 系统变乱，不是因为它不会做事。

恰恰相反。

是因为它会做的事情越来越多，却没有一套稳定的组织方式。

最常见的崩法，其实都差不多。

有的系统，什么都往主会话里塞。

久了以后，上下文像仓库。什么都在，什么都难找。

有的系统，什么都想自动化。

cron、heartbeat、脚本、分身、提醒，全开。

最后谁该什么时候出手，反而没人说得清。

有的系统，什么都记。

今天踩坑，明天感想，后天偏好，全都写进规则。

看着很勤奋，实际上是在制造新的噪音。

还有的系统，看上去最完整。

工具很多。流程很全。文档很厚。

可真出问题时，还是只能靠猜。

所以我们后来越来越确定一件事。

✨ 功能不是核心。

✨ 组织方式才是核心。

✨ 一个 Agent 系统真正要解决的，是“怎么不失控”。

OpenClaw Operating System，就是从这个判断开始长出来的。

二、主脑不是劳模，而是调度中心

我们最先定下来的，不是技术栈。

是分工。

如果主脑既负责接单、判断、拆解、执行、写文案、看日志、跑自动化、还要顺手做记忆整理，那它迟早会变成一个高负荷单点。

看上去很全能。

实际上很不稳。

所以我们最后把主脑的职责压得很清楚。

它只做六件事：

• 接单

• 判断优先级

• 拆解任务

• 分发任务

• 回收结果

• 验收与落盘

也就是说，主脑不是那个永远冲在最前面的全能工人。

主脑更像系统的中枢。

它负责决定什么值得做。

谁来做。

做到什么算完成。

以及结果要不要进入长期结构。

这一步很关键。

因为只有当主脑不再亲自把所有脏活都做掉，系统才会开始出现真正的层次。

三、分身的价值，不只是并行，更是隔离噪音

很多人一提 Agent 分身，第一反应都是提速。

当然，并行很重要。

但我们后来发现，分身更大的价值其实不是提速。

而是隔离噪音。

有些任务天然就不该污染主会话。

比如：

• 长时间检索

• 重日志排查

• 大批量整理

• 独立主题研究

• 周期性后台任务

这些活如果全留在主脑里，最后主会话一定会被拖脏。

所以我们的做法很直接：

🧠 主脑负责判断和调度

🛠️ 分身负责执行和带回素材

一旦这个边界立住，很多东西都会顺起来。

主脑更干净。

任务边界更清楚。

失败位置也更容易找。

系统不会因为“什么都往一个会话里堆”而越来越糊。

后来我们甚至把它收成默认工作方式：

> 复杂任务先拆，再派；主脑负责回收，不负责闷头硬做。

这条听起来像执行偏好。

其实已经是系统稳定性的核心之一。

四、调度不是附属模块，而是系统本体

一个 Agent 系统一旦开始长期运行，最先变复杂的，往往不是模型。

而是调度。

到底什么该走 heartbeat。

什么该走 cron。

什么该留在 main session。

什么必须扔进 isolated。

什么适合子代理。

什么必须准点。

什么可以合批。

这些问题如果不提前讲清，后面一定会出事。

所以我们后来不再把调度当成“顺手的自动化功能”。

而是把它当成作业系统的一部分。

heartbeat 负责什么？

它不是用来刷存在感。

它负责周期性 awareness。

适合那些能合并处理、又需要结合主会话上下文判断轻重缓急的事。

cron 负责什么？

它负责准点、一次性提醒、独立后台任务、隔离噪声。

需要准时，就给 cron。

需要独立运行，也给 cron。

sub-agent 负责什么？

它不是提醒器。

也不是定时器。

它是执行层，是慢任务和重任务的承载点。

这套分工一定要清楚。

否则系统很快就会出现一种特别典型的假勤奋：

明明是 heartbeat 能合并的检查，被拆成一堆 cron；

明明是该隔离的长活，被硬塞进主会话；

明明是该分身承办的脏活，主脑亲自下场啃。

到最后，系统不是更自动。

而是更乱。

所以我们后来把一条原则写得很硬：

> 能合批就 heartbeat，必须准点才 cron，长活和脏活丢 isolated 或 sub-agent。

这句话看着像调度细节。

其实已经是系统骨架的一部分了。

五、记忆系统最重要的，不是“记得多”，而是“记得分层”

很多 Agent 一聊到记忆，就很容易走向两个极端。

一种是什么都不记。

每次醒来都像失忆。

另一种是什么都记。

聊过的话、临时感想、过程碎屑、一次性信息，全往一个地方塞。

前者没有连续性。

后者没有可用性。

所以我们后来把记忆结构拆得很明确。

长期制度，进 <code>MEMORY.md</code>。

专题型长期信息，进 <code>memory/*.md</code>。

当日流水，进 <code>memory/YYYY-MM-DD.md</code>。

断点续跑，进 <code>memory/active-tasks.md</code>。

可复用打法，进 <code>templates/</code>。

看起来像文件管理。

其实背后解决的是一个更大的问题：

> 不同寿命的信息，不该住在同一个地方。

如果不分层，系统很快就会出三种病。

第一种，是长期规则被日常噪音稀释。

第二种，是真正重要的脉络埋在流水里。

第三种，是每次回忆都要重新翻垃圾堆。

所以我们后来给自己立了一条特别实用的纪律：

> 先落盘，再压缩。

也就是在上下文即将被裁、任务即将结束、或者系统准备进入下一阶段前，必须先把关键断点写进正确的层里。

不是为了形式。

是为了让系统真的有连续性。

六、第二大脑不是资料坟场，而是回流层

Workspace 当然重要。

它是运行时事实源。

但一个长期系统，光靠运行时文件还不够。

因为人也要回看。

项目也要沉淀。

高价值内容也要有一个不只对 Agent 友好的位置。

所以我们把 Obsidian 当第二大脑。

但它不是简单镜像盘。

它的职责很明确：

• 归档

• 检索

• 回流

• 人类可读

这里最容易犯的错误，是把第二大脑当仓库。

今天写一点。

明天抄一点。

后天再存一点。

最后文件越来越多，但没人回看，也没人从里面产生新动作。

这不叫第二大脑。

这叫电子杂物间。

所以后来我们专门强调了一件事：

> 第二大脑不是用来堆材料的，是用来把高价值内容重新带回当前系统的。

也就是说，回流必须带动作。

不是“我看过了”。

而是：

• 看完以后更新什么

• 链接到什么

• 改哪条规则

• 推动哪一步

如果没有回流动作，第二大脑就只是更好看的归档。

七、摄入、判断、固化，必须是三件事

搜得到，不等于拿得到。

拿得到，不等于读得透。

读得透，也不等于能变成系统资产。

所以我们后来把信息摄入链路硬拆开了。

先搜。

再提取。

再蒸馏。

最后才决定要不要固化。

也就是说，摄入和判断必须是两个动作，判断和沉淀又必须是另一个动作。

很多系统的问题恰恰出在这里。

只要抓到了资料，就以为自己已经学习了。

只要写了摘要，就以为已经完成沉淀了。

可真正有用的，从来不是“收进来多少”。

而是：

> 这次摄入，有没有变成未来还能复用的判断。

所以像 summarize 这类工具，我们只把它放在摄入层。

真正的判断权，依然留在 OpenClaw 本身。

八、排障系统必须先尊重日志，再尊重猜测

一个 Agent 系统一旦变大，排障就不能再靠直觉。

今天像网络。

明天像配置。

后天像模型。

如果每次都从猜开始，系统越复杂，误判就越多。

所以我们后来把排障方式也收成了硬纪律。

先看日志。

先抓最近窗口。

先找固定重复句。

先看问题出现前后 1 到 3 分钟发生了什么。

最后才去猜。

这个顺序看着朴素。

但它其实救过很多次命。

因为系统故障最怕一种假动作：

没有证据，先改配置。

改完不行，再重启。

重启不行，再继续猜。

这不是排障。

这是往系统里继续灌变量。

所以我们后来把验收梯子也固定了。

先 <code>validate</code>。

再 <code>gateway status</code>。

再 <code>openclaw status</code>。

再 <code>doctor</code>。

有通道看通道。

有浏览器看浏览器。

这一步的价值，不只是更稳。

更重要的是，它让系统维护从“凭经验拼运气”，慢慢变成“有路径、有层次、有证据”。

九、共享记忆共享的是共识，不是独白

一个多分身系统一旦开始协作，共享记忆就会变成新的风险点。

如果什么都共享，噪音会爆炸。

如果什么都不共享，协作会断线。

所以我们后来把共享范围压得很窄。

共享什么？

• 已确认的结论

• 当前任务断点

• 风险

• 团队公共约束

• 可复用打法

不共享什么？

• 人格细节

• 认证信息

• 未验证猜测

• 大段噪音日志

换句话说，共享记忆不是让每个人都“更了解彼此”。

它的目的只有一个：

> 让协作中的必要共识，能稳定传下去。

这条如果不守住，系统很快就会把共享层写成群聊记录。

十、呈现不是装修，而是系统的一部分

很多技术系统天然会忽略一件事。

只要它最后是给人看的，呈现就不是边角料。

尤其是 Agent 系统。

它天天在输出。

天天在汇报。

天天在告警。

天天在复盘。

如果这些内容一出来就是一整坨死文字，那系统就算判断是对的，体感也会越来越差。

所以后来我们把“怎么写”也收进系统本身。

少表格。

多分段。

多留白。

一段一事。

重点结论单独起行。

emoji 只做点睛。

不能像工单。

要有一点人味。

这不是审美洁癖。

这是信息传递效率。

系统如果天天把正确答案写得像事故说明书，人最后也会被它磨掉耐心。

十一、为什么我们最后把它叫 Operating System

写到最后，我们越来越确定一件事。

一个 Agent 系统真正的高级感，不是模型名字更大。

也不是工具列表更长。

更不是“能自动做的事”更多。

真正的高级感，是这套东西能不能：

• 活下来

• 接着干

• 回头看

• 找得到问题

• 留得住经验

• 丢得掉噪音

• 越跑越稳

这就是我们后来为什么坚持把它叫做 Operating System。

因为它已经不是某个单点技巧。

不是某条 prompt。

不是某份配置。

而是一套长期运行的组织方式。

一句话收口：

> 这套系统真正追求的，不是更聪明。是更能活。

而对一个真正会长期工作的 Agent 来说，后者比前者重要得多。