OpenClaw因记忆不可靠无真正用途，仅每日新闻摘要可行。多数宣传夸大，安全风险高，当前版本不值得投入时间。
### 我们本以为OpenClaw是个酷炫演示，结果跑偏了
NonBioS团队制作了一段YouTube视频。视频里，NonBioS在全新的Linux虚拟机上自动部署OpenClaw。整个过程零人工干预，从开始到结束大约七分钟。我们原本只想展示NonBioS处理任何开源软件的能力。视频发布后，事情的发展远超我们的预期。大量观众看到了这个自动化过程，产生了浓厚兴趣。他们不再只是观看，而是直接动手尝试。
从那时起，通过我们的基础设施，OpenClaw的部署数量已经接近一千次。人们涌入我们的平台，启动一个虚拟机，跑起OpenClaw，把它连接到WhatsApp或Discord。他们开始用这个被黄仁勋称为“个人AI操作系统”的东西做实验。每个人都带着兴奋和好奇，觉得自己找到了一个强大的自动化助手。但真实情况呢？很快，问题就开始浮现。
我和自己圈子里的许多人聊过，包括工程师、创业公司创始人、技术运维人员。这些人独立部署了OpenClaw，并花了大量时间试图让它变得有用。不是仅仅一个周末的随便玩玩，而是好几个星期。有些人真心想让它发挥作用，费了很大劲去配置环境、调试连接、编写指令。他们投入了真实的精力，期待得到真实的回报。然而，我们最终发现了一个令人沮丧的事实。
经过对所有可用信息的梳理——我们的一千次部署数据、与用户的对话、网上的各种帖子——我得出了一个明确的结论：OpenClaw没有任何一个真正站得住脚的合法用途。这个结论听起来很极端，但它是基于大量真实使用场景的分析得出的。我想对OpenClaw公平一些，它不是一个假软件。它是一个真实存在的程序。它可以安装，可以运行，可以连接到你的消息应用，可以和Claude以及GPT对话，可以执行Shell命令。技术本身是存在的。
但是，当我仔细观察人们实际在用OpenClaw做什么的时候，我找不到任何一个经得起推敲的用例。这包括我们的一千次部署，包括与我圈内朋友的交流，也包括领英和推特上铺天盖地的帖子。所有人都在说OpenClaw多么神奇，但只要你追问细节，故事就变了。你会发现那些所谓的“自动化整个工作流”其实漏洞百出。真正稳定运行、不出错、能放心交办任务的场景，一个都没有。
记忆不可靠，一切都白搭
OpenClaw的核心问题是记忆，其他所有问题都从记忆问题衍生出来。OpenClaw作为一个持续运行的代理程序，它本该是你永远在线的助手。你可以随时向它交办任务，它应该记住对话的来龙去脉，记住你的偏好，记住任务的状态。但现实是，OpenClaw的记忆非常不可靠。最糟糕的地方在于，你完全不知道它什么时候会出问题。它可能正常运行一整天，然后在最关键的时刻突然忘记关键信息。
想象一下这个场景在实际使用中意味着什么。你让OpenClaw替你发送一封邮件。之前你们一直在讨论一个你正在计划的生日派对。有三个人确认参加，一个人拒绝了。OpenClaw需要发送一封更新邮件，告诉所有人最新情况。但在生成邮件时，它丢失了关于谁拒绝参加的重要上下文。结果，它给列表里的每个人都发送了包含错误信息的邮件。你没能及时发现错误，因为使用自主代理的全部意义就在于你不需要检查每一个输出。
一个你每次使用后都必须人工验证的自主代理，本质上只是一个多了几个步骤的聊天机器人。你原本希望节省时间，结果却要花更多时间去做验证工作。你原本希望减少错误，结果却因为代理的错误而引入了更多错误。这就好比你雇了一个助手，每次他做完事你都要从头检查一遍。那你为什么不自己直接做呢？OpenClaw的这种情况不是下一个版本就能修复的小Bug。这是OpenClaw管理上下文方式的一个根本性限制。
代理持续运行，上下文窗口被填满，信息开始被遗忘。有时被遗忘的是重要信息，有时是不重要的。你永远不会知道哪些信息会被丢掉，直到问题已经发生并造成了实际损害。你可能会在客户面前出丑，可能会发错文件，可能会执行错误的命令。因为你无法预测代理什么时候会“失忆”，所以你也无法建立任何有效的容错机制。这种不确定性，让OpenClaw无法承担任何严肃的工作。
大脑不是文件索引，战略遗忘才是关键
我在NonBioS花了整整一年时间研究这个问题。我们把方法称为“战略遗忘”。根据我的深度实践经验，我可以明确告诉你：让一个AI代理在长任务周期内保持连贯性，是整个AI领域最难解决的工程问题。这不只是增加上下文窗口大小就能解决的。也不是简单地采用“先总结再丢弃”的策略就能搞定的。OpenClaw的开发者们显然也意识到了记忆问题，但他们采用的方法是把每一天、每一月、每一年的记忆映射到单独的文件里。
这种做法看起来很规整，好像把信息分门别类存放就不会丢了。但人类的大脑根本不是这样工作的。大脑不是一个你可以建立索引的文件列表。你不会用“上个月”这样的高维度标签来回忆所有事情。你也不会在需要某一天的具体细节时，再去“拉取”那个文件。大脑的工作方式是：所有重要的事情同时被记住，所有不重要的细节被遗忘，除非那些细节本身也很重要。这就是“战略遗忘”的核心原理。
我们的大脑会实时评估信息的价值，决定哪些值得保留，哪些可以安全丢弃。这个评估过程是持续的、动态的、基于上下文的。OpenClaw没有这种能力。它的“记忆”只是机械地保存对话历史，当历史太长时，就简单地截断或丢弃最早的部分。这种方式完全无法区分“生日派对中谁拒绝了邀请”和“你们讨论生日派对时提到的天气”哪个更重要。对于大脑来说，前者重要，后者不重要。对于OpenClaw来说，两者同等重要或同等不重要。
所以，OpenClaw会犯两类错误。第一类错误是保留了太多无用信息，导致上下文窗口被垃圾信息填满，真正重要的信息反而被挤出。第二类错误是过早丢弃了重要信息，导致后续任务失败。更糟糕的是，你无法预知它会犯哪类错误。你今天让它帮你处理邮件，它表现完美。明天让它做同样的事情，它可能就搞砸了。这种不可预测性，让OpenClaw在真实生产环境中完全没有立足之地。
唯一真正好用的功能，早就有无数替代品
在翻遍了所有我能找到的资料之后——包括我们的部署数据、用户对话记录、网上的帖子——我发现唯一真正能稳定运行的用例是每日新闻摘要。OpenClaw会搜索网络上你关心的话题，汇总成摘要，每天早上通过WhatsApp发送给你。这个功能确实能用，而且很少出错。因为任务简单，不需要长期记忆，每次执行都是独立的。OpenClaw只需抓取信息，总结，发送。没有状态需要维护，没有上下文可能丢失。
就这样。这就是所谓的“杀手级应用”。一个个性化的每日简报确实不错，但问题是，你早就可以用其他更简单、更可靠的工具实现同样的功能。比如，你可以用Zapier的工作流加上任意一个大语言模型的API。或者用ChatGPT自带的定时任务功能。或者用其他几十个已经存在了好几年的工具。这些工具不需要你维护一个专用的服务器，不需要你给代理root权限，不需要你担心记忆崩溃。
你完全不需要一个拥有25万GitHub星标的项目，跑在一台专用服务器上，拥有你环境的根访问权限，就为了每天早上收到一份新闻摘要。这就像用火箭筒去打一只苍蝇。OpenClaw的复杂性和它所提供的价值完全不成比例。为了运行OpenClaw，你需要配置虚拟机、安装依赖、设置环境变量、连接消息应用、调试各种权限问题。而最后你得到的，只是一个用Zapier十分钟就能搭好的新闻机器人。
更讽刺的是，那些声称用OpenClaw实现了复杂自动化的人，其实都在回避它的记忆问题。他们设计的任务要么是无状态的（如新闻摘要），要么短到不会触发记忆丢失（如发送一条消息）。一旦任务需要跨越几个小时或涉及多轮交互，OpenClaw就开始出错。没有人愿意承认这一点，因为承认就意味着他们投入的数十个小时变得毫无意义。但事实就是事实：OpenClaw的唯一稳定功能，根本不值得它所带来的麻烦。
社交媒体上的OpenClaw神话，全是营销套路
关于整个OpenClaw事件，有一件事需要说得明明白白。你在社交媒体上看到的大部分关于OpenClaw的帖子，内容大概是这样的：“我用OpenClaw自动化了我的整个团队”，“OpenClaw替代了我的三个员工”，“我的OpenClaw代理在我睡觉时帮我运营整个公司”。这些帖子几乎都是冲着营销热度去的。人们知道，现在发OpenClaw相关的内容能获得大量互动，所以他们拼命生产OpenClaw内容。驱动他们的动力是吸引观众，而不是陈述事实。
我和这些帖子背后的一些人聊过。在每一个案例中，只要你深入追问，故事就会变成以下两种情况之一。第一种情况是，他们搭建的东西用标准的AI工具早就能实现了。比如ChatGPT、Claude，或者任何一个带有简单集成功能的大语言模型。他们只是把OpenClaw作为一个前端或调度器，真正的智能工作还是由其他模型完成的。第二种情况是，这些故事完全是“理想化”的——一个周末做出来的原型，在演示环境下勉强能跑通，但没有人敢用它来处理真实任务。
我不是说这些人在撒谎。我相信他们中的大多数人是真心相信自己正在构建的东西。但是，“我让OpenClaw成功做了一件酷事”和“我每天都依赖OpenClaw做重要工作”之间存在着巨大的鸿沟。前者只需要一次成功的演示，后者需要数周无故障的运行。前者可以忽略所有的边缘情况，后者必须处理每一个异常。在我和所有这些人的交流中，我没有找到任何一个属于第二类的人。没有一个人能说：“是的，我已经连续一个月让OpenClaw替我处理我的日历和邮件，没有出过一次错。”
这种营销炒作造成了非常坏的影响。它让新用户产生了不切实际的期望，以为OpenClaw是一个成熟的生产力工具。他们投入时间学习、配置、部署，然后发现现实完全不是那么回事。他们遇到记忆丢失、上下文错误、任务失败，然后开始怀疑是自己配置错了。他们会花更多时间去调试、去搜索文档、去论坛提问。最后，他们要么放弃，要么勉强接受OpenClaw只是一个昂贵的新闻摘要工具。这个循环每天在大量新用户身上重复。
安全风险被严重低估，隔离环境是底线
OpenClaw的安全问题已经被广泛报道过，我就不再赘述了。但有一点必须强调：这就是人们把OpenClaw连接到自己的邮箱、日历和消息应用时所处的环境。他们给一个记忆不可靠的代理授予了大量权限。这个代理运行在他们的个人电脑上，可以访问他们的文件系统、执行Shell命令、读取他们的邮件、代发消息。OpenClaw的任何一次记忆错误，都可能导致灾难性的后果。
想象一下，OpenClaw错误地认为某封邮件是垃圾邮件并帮你删除了它，而那封邮件恰好是你的工作合同。或者，它错误地记得你的老板要求你把所有文件移动到某个目录，然后执行了移动命令，结果你丢失了所有文件索引。或者，它错误地理解了你的指令，向整个公司群发了一条你本来只想发给一个人的消息。这些不是假设，而是真实可能发生的场景。因为OpenClaw的记忆不可靠，你无法预测它什么时候会做出错误的理解。
我们制作NonBioS部署视频，正是因为看到了这个问题。我们的最低要求是：如果你非要用OpenClaw做实验，至少把它放在一个隔离的虚拟机里。这样，即使OpenClaw被攻破或出错，也不会接触到你的个人数据。这是最基本的底线，但大多数人连这个都没做。他们直接在主力电脑上运行OpenClaw，授予各种权限，然后祈祷不要出事。这种行为就像在装满汽油的车库里玩打火机，短时间可能没事，但只要出一次事就是灾难。
我不是在危言耸听。已经有多个安全研究员报告了OpenClaw的潜在漏洞。因为它可以执行Shell命令，所以任何提示注入攻击都可能让攻击者在你的电脑上执行任意代码。而OpenClaw的记忆问题会让这种攻击更难被发现，因为代理自己可能都记不住之前执行了什么命令。你甚至无法通过查看日志来追溯攻击，因为日志也可能因为记忆问题而不完整。安全不是一个可以事后补救的问题，它是一个必须从一开始就设计好的特性。OpenClaw显然没有做到这一点。
诚实评价：周末玩玩可以，认真投入就算了
我的诚实评价是这样的。如果你有一个周末的空闲时间，并且你喜欢捣鼓新技术，那么OpenClaw是一个有趣的实验。你会学到很多关于AI代理如何工作的知识，了解演示环境和生产环境之间的差距，理解为什么上下文管理如此重要。这是一个很好的学习体验。你可以亲手搭建一个AI代理，看到它连接消息应用、执行命令、和LLM对话。你会遇到各种问题，然后解决问题，这个过程本身就有教育意义。
但是，如果你在评估是否要把真实的时间投入到OpenClaw这个当前版本上，那么你可以直接跳过它，完全不用觉得错过了什么。你没有错过一场生产力革命。你错过的只是一个每天早上给你发新闻摘要的工具，以及大量用来配置YAML文件的时间。这些YAML文件用于定义OpenClaw的行为、工作流、提示词，调试它们会耗费你无数个夜晚和周末。而最后，你得到的只是一个可靠性堪忧的玩具。
OpenClaw背后的理念是正确的。AI代理在真实电脑上执行真实任务的时代已经到来。我深信这一点，因为这也是NonBioS每天都在构建的东西。我们相信，未来的计算范式将是以AI代理为中心，而不是以应用程序为中心。你不需要学习如何使用不同的软件来完成不同的任务，你只需要告诉你的代理你想完成什么，它会自动调用合适的工具。这个愿景是激动人心的，也是我们努力的方向。
但是，OpenClaw的执行还没有达到那个水平。在记忆问题被解决之前——在你能够真正信任一个自主代理，让它持续数小时甚至数天记住什么重要、什么不重要之前——其他的所有东西都只是表演。你可以有漂亮的界面、流畅的演示、激动人心的宣传，但如果代理记不住它应该记住的事情，那么这一切都没有实际价值。OpenClaw是一个先驱，它让我们看到了可能性，也让我们看到了问题。但它不是一个可以交付给普通用户的可靠产品。
我的建议是：保持关注，但不要现在投入。
等记忆问题有了真正的解决方案，等OpenClaw或者类似的项目能够证明它们可以稳定运行数周不出错，那时候再考虑使用。现在，如果你真的需要自动化某些任务，用那些已经成熟、可靠、不需要你每天祈祷的工具。用Zapier，用Make，用传统的脚本语言。它们虽然不够“AI”，但至少不会在你最需要它们的时候突然失忆。而OpenClaw，就让它继续作为实验室里的一个有趣实验吧。