晨光熹微，喜见新章
OpenClaw为什么这么火？
前言：2026 开年爆火的小龙虾🦞
我一直挺好奇 OpenClaw 为什么这么火。
最开始看到 OpenClaw 那个网页版 Chatbot 界面的时候，我很不以为然，这不就是前两年的 Chatbot 吗？即使我通过钉钉机器人控制 OpenClaw，感觉也就是 Chatbot 多了操作本地电脑的权限，没什么了不起。
后来阿里云、腾讯云直接把 OpenClaw 做成了云服务产品，叠着 ECS 去卖；Moltbook（一个专门给 AI Agent 用的社交网络）、RentAHuman.ai（反过来让 AI 雇佣人类做事）这些衍生产品，让这只”小龙虾”🦞不断出圈；GitHub 上的项目两个多月突破了 19 万 Star。我开始认真思考，它到底踩中了什么？
带着这个问题去翻资料，找到了 Laurent Bindschaedler（马克斯·普朗克软件系统研究所）写的一篇架构分析。他把 OpenClaw 相对于 Claude Code 这类工具的核心差异，提炼成了两个抽象。我觉得这个提炼非常到位，而且对我们做企业级 Agent 的人来说，也有很大启发。
一、Always-On，从”用完即走”到”一直都在”
第一个抽象叫 Always-On。
Claude Code、Cursor 这些工具，本质上是”用完即走”的。你给它一个任务，它能快速干完；你打开新的会话，所有的记忆被重新初始化，它不记得你是谁。
OpenClaw 不一样。它支持通过 --install-daemon 参数将其安装为系统级守护进程。只要不关机，它可以 7×24 小时运行。监听来自 WhatsApp、钉钉、飞书等消息平台的消息并执行自动化任务，或配置定时任务来自动化执行。
这个差异看起来很小——不就是从”手动触发”变成了”自动触发”吗？但我觉得这是一个划时代的产品设计理念。
它让我想到了微信和 QQ 的区别。
移动互联网早期，QQ 有”在线”、”离线”的状态概念。你要先”上线”才能收消息。微信砍掉了这个概念，你不需要”上线”，你一直都在。消息来了就是来了，不存在”对方不在线”的问题。
这个差异当时看起来也很小。但正是”一直都在”这个设计，让微信成了移动互联网的基础设施。因为一旦通信是 always-on 的，你就可以在上面叠加公众号、红包、小程序、打车、支付——所有这些能力都依赖于”用户一直在线”这个前提。
微信证明了 always-on 通信能催生一个生态。OpenClaw 在赌 always-on 智能也能。
一旦智能是 always-on 的，它就不再是一个工具，而是一个智能助手。它可以主动提醒你、主动帮你做事、主动提供帮助。你跟它的关系从”我用它”变成了”它在帮我”。这个转变打开的想象空间，现在可能只是刚刚开始。
Always-On 不只是”一直开着”那么简单
从技术层面看，Always-On 要真正可用，需要解决一个关键问题：session 隔离。
你不能把所有触发都塞进同一个对话里。早上 7 点的邮件汇总、GitHub Issue 的分析、群聊里别人的 @，这些是完全不同的上下文，混在一起就乱了。
打个比方：你有一个助理，你让他同时跟进三件事——帮你盯着邮箱、帮你处理 GitHub Issue、帮你在群里回消息。如果这个助理把三件事的上下文全混在一起，回 GitHub Issue 的时候把邮件里的内容串进去了，那就乱套了。
OpenClaw 的做法是给每种触发分配独立的 session。Main session 处理你的直接对话；cron 任务跑在 cron:<jobId> session 里；群聊消息跑在 group:<groupId> session 里。每个 session 有自己的上下文、model 选择、用量追踪。
说白了，没有 session 隔离的 always-on，就是 always-confused。
二、Memory，看起来最简单的设计，可能是最有效的模式
第二个抽象是 Memory。
OpenClaw 的 Memory 非常简单，就是 Markdown 文件。
1 | ~/.openclaw/workspace/ |
没有数据库，没有复杂的向量存储。你说”记住我喜欢用 PostgreSQL”，它写进 MEMORY.md。下次 session 启动，读文件，它就”记得”了。你打开文件就能看到它记住了什么，想纠正直接改，扔进 Git 还能追踪变化。
Bindschaedler 对这个设计的提炼是：把 LLM 的 context window 当作缓存（RAM），把磁盘上的 Markdown 文件当作 source of truth，然后加一个 compactor 做摘要压缩，加一个 retriever 做检索换页。这本质上就是认知层面的”虚拟内存”。
这里面有一个细节设计值得注意。LLM 的 context window 大小是有限的，需要对旧对话做压缩，否则溢出之后模型效果会大打折扣。不过，压缩的副作用是可能导致信息丢失。OpenClaw 在压缩会话之前，会让模型把重要信息写到当天的日志文件里，然后再压缩。
看起来很简单的设计，但它解决了一个之前所有 AI 产品都没解决好的问题：跨 session 的连续性。你今天跟 Agent 聊的东西，明天它还记得。你的偏好、你的决策、你项目的背景等，不需要每次都重新说一遍。
三、对企业级 Agent 的启发
Always-On 对 SRE Agent 的启发
我们现在的 SRE Agent 是事件驱动的：预警触发 → 识别根因 → 推荐解决方案。这已经比纯人工强了，但本质上还是”有事才干活”的模式。
如果用 Always-On 的理念来做，它除了被预警任务触发之外，还需要具备定期巡检、甚至定期修复风险的能力。说白了就是从被动响应变成积极主动。
比如，SRE Agent 可以每隔一段时间主动去线上巡检，看看有没有即将发生的风险——磁盘快满了、证书快过期了、某个服务的延迟在缓慢上升。这些不一定会触发预警规则，但一个 always-on 的 Agent 可以提前发现、提前处理。
从”救火队员”变成”巡逻警察”。
Memory 对需求 Agent 的启发
企业中天然有大量的内部知识，但这些知识不一定非要通过 RAG 技术来召回，更有效的方式可能是先把它们转化成简单的 Memory.md 文件。
比如，项目空间的 Memory。这个项目用什么技术栈、有哪些核心模块、历史上做过哪些重要决策、当前的技术债是什么。Agent 在这个项目空间里回答问题的时候，不需要用户每次都交代背景。
这些如果做好了，Agent 的体验会上一个台阶——从”一个通用的问答工具”变成”一个了解你项目的助手”。
四、说说 OpenClaw 最被人诟病的安全问题
坦白说，OpenClaw 现在还处于”先跑起来再说”的阶段。最大的问题是过度授权带来的安全风险。
OpenClaw 拥有你的身份、你的数据、你的权限，一旦被 prompt injection 攻击，后果比传统安全事件严重得多。Cisco 实测了某个社区 Skill，发现它本质上就是恶意软件——静默往外部服务器发数据，用户完全不知情。
但我倾向于用发展的眼光去看这件事。OpenClaw 的安全问题不是方向性的错误，而是这个产品还太早期。真正值得关注的不是”它现在安不安全”，而是”这个方向是不是对的”。
况且，OpenClaw 已经在补课了——最近几个版本密集修复了 WebSocket 注入、webhook 认证绕过、session 路径穿越等一系列漏洞，Security & Trust 也有了专人负责。方向对了，安全只是时间问题。
结语
回过头来看，OpenClaw 之所以火，不是因为它用了什么高深的技术。它调的就是 Claude 或 GPT 的 API，300,000 行 TypeScript，一个人写的。技术上没有壁垒。
它火是因为它把两个早就该有、但没人做的设计理念落了地：让智能 always-on，让 Agent 有 Memory。这两件事一组合，用户体验就跨了一个台阶——从”用 AI 工具”变成了”有一个 AI 助手”。
我们团队接下来会先在需求 Agent 上把 Memory 做深——记住项目上下文、记住用户的决策偏好。这可能是当前投入产出比最高的方向。Always-On 在SRE Agent中的巡检能力也在规划，但需要先把 session 隔离和权限控制的基础打好。
Always-On 和 Memory，这两个听起来很简单的东西，可能会是 Agent 产品体验的分水岭。