OpenClaw 是第一个把「常驻 agent」做到大规模流行的项目。 我们拿它跑过一摊真实的服务器运维，然后在 2026-07-13 把那台机停了。 这一篇讲它是什么、以及停机那件事教了我们什么——停掉的东西也留在页面上，这是本站的规矩。
本文写什么它的形态与能力、我们的使用与停机、三条教训。 本文不写那台机的地址、跑的是什么业务、任何配置与时刻表。
| 形态 | 跑在你自己的机器上的个人 agent，不是云服务 |
| 入口 | 你已经在用的消息 App——WhatsApp、Telegram、Slack、Signal 等 |
| 能力 | shell 命令、浏览器自动化、邮件、日历、文件操作 |
| 自启 | 心跳调度器按设定间隔唤醒它，不需要你先说话 |
| 扩展 | 大量预置技能（AgentSkills） |
| 模型 | 模型无关：自带 key 接云端模型，或整个跑本地模型 |
关键设计有两条，它们后来被很多项目沿用： ① 入口放在消息 App 里（不用另开一个界面）； ② 心跳唤醒（它能在你没说话的时候干活）。
规模上它是个异数：GitHub 仓库 openclaw/openclaw，TypeScript，
386,998 星 / 81,287 fork（2026-08-21 经 API 核），2025-11-24 建仓——
不到十个月。
我们用它跑过一摊真实的服务器运维：不是 demo，是有真实后果、要长期维护的活。 它确实干成了——这一点没有保留。
然后：2026-07-10 把那摊活交给了另一套工具链；07-13 停机，知识库整个归档。
不是「不好用」。如果为了显得客观而编一个技术缺陷出来，那是撒谎。
真实理由很朴素：那台机的活被别处接走了，它就没有存在的理由了。 而一台没有活的常驻机器不是零成本——它还在花钱、还在等着被维护、 还在你的脑子里占一格「那台机怎么样了」。
本站的规矩是台账没记原因就写「没有记录原因」。这一条记了，所以照实写。
是「它在那儿」这件事本身占的注意力。 每一个常驻进程都在你脑子里开一个后台线程：它还活着吗、上次更新是什么时候、 那个报错要不要管。
这条成本不上账单，但它是真的。所以第 10 篇那三条判据 应该在搭之前过一遍，而不是搭完之后靠意志力维持。
停机那次我们把整个知识库完整归档了下来，当时只是出于谨慎。 后来证明这个动作是对的——不只是「万一要回头看」， 而是这些资产在下一个工具里还能直接用。
具体到 OpenClaw：它的后继者可以一条命令把 ~/.openclaw 整个端走，
人格、记忆、技能、设置全部继承。删掉的话，这条路就没了。
见第 14 篇。
搭之前就该问：哪天不要它了，怎么干净地拆？
如果答案是「不知道，反正它现在跑得挺好」，那这套东西迟早会变成你不敢碰、 也不敢关的存在。真正好拆的系统有三个特征：状态集中在少数几个目录里 · 不往系统各处塞东西 · 停掉之后别的东西不会跟着倒。
「不需要你先说话」是它最大的卖点，也是账单的来源。 每一次心跳都可能是一次完整的模型调用，而成本对轮数是超线性的。
上手第一天就该做的：把心跳间隔调到你真正需要的那个粒度， 并且知道去哪儿看用量。默认值是给演示用的，不是给长期跑用的。
能给你发消息的人，就能给它发消息。而它能跑 shell。
这两句话放在一起就是全部风险。所以这类 agent 的第一课永远是 先把「谁能跟它说话」锁死，再谈功能。 具体做法见第 15 篇——那一篇整篇都在讲这件事。
openclaw/openclaw，TypeScript，386,998 ★ / 81,287 fork，
建于 2025-11-24，2026-08-21 仍在推送。数字取自 GitHub API 当日核对。
GitHub 上的 license 字段显示为 Other（未标准化），协议以仓库内文件为准，本文不代为归类。