夜雨聆风从“上门安装 OpenClaw”到集体销声匿迹，只用了半年。
2026 年初，如果你混 AI 圈，一定见过这种场面：朋友圈里一夜之间冒出无数“电子牧民”，开始养 Claw。有人晒自己的 OpenClaw 学会了订机票，有人晒它自动整理了一整周的邮件，还有人直接挂出服务——“上门安装 OpenClaw，一次 500，包教会”。那时没人觉得奇怪。一个能自己用电脑、自己上网、自己写代码、甚至能记住你喜好的“数字管家”，听起来确实是下一个时代的入口。而“安装 OpenClaw”能成为一种职业，听着荒谬，但真有人靠它赚到了钱。
然后呢？不到半年，集体安静了。身边几乎没人再提“养虾”这回事。当初那句“我就每天发几个指令，不用干活，它都给我干了”的口号，也再没人重复。
我们也跟风安装过 OpenClaw。当时也是借鉴了其他人的经验，为了避免每个人电脑上都装一个、管理混乱，不如单独弄一台服务器，部署一个服务端，然后和钉钉打通。我们在钉钉后台创建机器人，按业务组织配置不同群组，每个群里加一个机器人。需求大致是这样：
按事业部划分，每个部门要有独立的工作空间——也就是创建单独的智能体，所有上下文记录彼此隔离。
把智能体映射到每个钉钉群。有个特别坑的地方：群号居然得从后台日志里捞，翻遍钉钉界面也找不到哪里能直接看。
群与群之间上下文隔离，同一群里不同用户的上下文也彼此隔离。最大上下文设成 30 轮对话，后面为了调性能，这几个参数反复改，改到想吐。
还需要一个共享文件目录，因为涉及文件交互——上传、生成、下载。但在对话框里传文件，是传到钉钉服务器，智能体根本读不到；生成的文件也没法直接下载。这块体验极其恶心。
实际使用方式很简单：在群里 @ 助手，它就能干活。
第一个星期，大家是兴奋的。“帮我查一下目录下有哪些文件”“整理一下上周的会议纪要”，群里消息不断。
第二个星期，兴奋开始打折。因为每次提问都要等——等一分钟、两分钟、三分钟，偶尔直接报错。第三个星期，群里安静了不少，只剩零星几句：“这个文件到底存哪了？”“结果呢？”更让人崩溃的是，任务跑完了，它只回一句“已完成”，但文件你翻遍所有地方都找不到。问它，它说“文件已保存到 /xxx/xxx/xxx”——实际上不一定靠谱，也有可能是记忆错乱，虽然设置了隔离，有时候也会放错地方。第四周，已经有人忍不住直接开喷：“你们这个机器人到底行不行？”
我们后来甚至有了心理阴影。每次在群里看到机器人的回复图标不停转圈，心里就慌得一比。中间还组织过两次培训，实操环节基本全程掉链子。折腾了两个月，大家彻底不想搞了。后来，我们索性自己去搭智能体平台。
为什么没能用起来？
一、慢，慢到让人失去耐心举个真实场景。钉钉群里有人问：“帮我查一下上个月立项的那个 XX 项目文件，总结一下关键信息。”就这一句话，OpenClaw 内部发生了什么：
加载系统提示词——每新开一轮对话，框架会把
AGENTS.md、SOUL.md、IDENTITY.md、USER.md、TOOLS.md全部拼接起来塞给大模型。如果这些 md 写得很长，用户还没提问，几千甚至上万 Token 就已经被吃掉了。
加载全局记忆——它会读取此前积累的所有长期记忆，包括你和它聊过的所有事、公司所有项目的历史摘要。用得越久，这部分越膨胀，几千到上万 Token 是常事。
加载技能清单——几十个内置技能的名称和描述全部塞进上下文，让模型“知道自己会什么”，又是几千 Token。
模型开始思考——先规划：找文件该用哪个工具？先检索还是先浏览目录？思考两三轮，每一轮都是全量上下文重算。
调用“检索文件”工具，返回一串结果。
读取文件——如果那是一份几万 Token 的文档，它会整个吞进上下文，只为最后总结出三句话。
终于，输出答案。
你算算这笔账：一个“查文件 + 总结”的小任务，峰值上下文轻轻松松到 5–10 万 Token，算上多轮推理的实际消耗，总量是它的两三倍——15 万到 30 万Token，耗时几分钟。而同事用 Ctrl+F 自己找，30 秒；直接问 DeepSeek，5 秒。这就是最根本的矛盾：OpenClaw 每一步都“想得很周全”，但周全的代价是——它处理一句话，比人类处理十句话还慢、还贵。新鲜感撑不过第三周，就是因为这个。
二、技能很多，但“知道有”和“用得上”是两回事
OpenClaw 自带一长串能力清单：文件检索、日程管理、浏览器自动化、代码执行、图像处理，看上去无所不能。
它的加载逻辑是：技能完整说明不会一次性加载，但所有技能的名字 + 简介，会全部塞进每一轮的系统提示词；只有模型选定某个技能之后，才会读取完整的技能文档。
看似省资源，实际坑点不少。原生自带几十个技能，如果再导入自定义扩展，技能总数很容易冲到上百个。哪怕只是名称和简短描述，累积就是几千 Token，每一次对话刚性扣费，业务还没开始，上下文已经被占掉一大块。
更大的麻烦是决策噪音。模型每次要在上百个技能里挑选工具，很容易纠结、选错、反复试错。你以为它在思考业务，其实它在一大堆技能列表里徘徊迷路。
实际跑业务会发现，真正高频能用的也就五六个。其余几十项能力从头到尾没被调用过一次，却始终常驻提示词，持续消耗 Token。现在像 WorkBuddy，包括我们自己在开发时，肯定不会再这么干了。
三、上下文爆炸，然后是“失忆”与死循环
这是所有长任务智能体绕不开的坎，OpenClaw 也不例外。
它的应对机制是压缩：上下文快满时，把前面的历史总结成一份摘要，扔掉细节，继续干活。思路没错，但现实很骨感：
压缩是有损的。丢掉的往往不是废话，而是“当时觉得不重要、后来发现是关键”的细节——比如某个文件的路径、某次修改的中间状态。
压缩之后，模型面对摘要重新推理，经常得出和压缩前不一样的结论。更糟的是，如果压缩恰好发生在任务执行到一半，模型会失忆——忘了自己进行到哪一步，于是开始重复调用同一个工具、反复读同一个文件、一遍遍问自己“我到底在干嘛”。
我们在钉钉群里见过最魔幻的一幕：机器人为了总结一份文档，把同一个文件连续读了四遍，前后花了二十分钟，最后输出了一句话，还是错的。
这就是“上下文爆炸 → 死循环”的标准剧本。任务执行越久，上下文越臃肿，压缩越频繁，死循环概率越高。而你只能干瞪眼，因为它看起来“一直在忙”。调上下文的参数真的恶心到爆炸，至今我们也没搞明白它到底是怎么压缩的。
四、Web 界面很简陋，内置工具是“尝鲜级”
OpenClaw 的 Web 界面功能极度单薄，核心就只剩一个对话窗口。
没有可视化文件管理，没有模型参数配置面板，任务进度也看不到，大量配置都要直接修改本地文件。页面上满眼都是开发者日志，业务人员根本看不懂。别人问任务有没有完成，只能靠翻日志猜结果。
内置的各类工具都是零散单点能力，可以独立跑通，却无法串联起完整业务链路。它能搞定一些碎片化小操作，但企业真正需要的端到端工作流程，很难落地。热度一过，Demo 里的“强大”就很难复现在真实场景中。
五、看不懂的 TS 源码，挡住了绝大多数人
因为上面出了那么多问题，我们也想过能不能改改源码——比如上下文到底怎么压缩的、系统提示词能不能精简一些。代码是能跑起来，但真想动它，能力实在达不到。
包很大，全栈 TypeScript，依赖一大堆。想改点东西？得先搞懂 agent 主循环、技能注册机制、MCP 协议、记忆管理模块……每一条都是硬骨头。
国内技术栈主流是 Java、Go、Python，TS 的 AI Agent 工程化人才本来就少。更要命的是，中文深度教程几乎没有。于是，就这么放弃了。
一点冷思考
OpenClaw 不是一个失败的产品，它压根就没把自己当成一个“产品”来做——它是一个开源项目，是一套关于“如何让大模型拥有手脚”的参考答案。
它真正留给行业的，不是可用的软件，而是可借鉴的思想：Agent 主循环怎么跑、工具怎么注册、记忆怎么管理、上下文怎么组织……这些骨架，后来被 WorkBuddy、通义们默默吸收、消化、重构成了各自的产品。几乎今天你能看到的每一个智能体产品，骨子里都流着 OpenClaw 的血。
它不是被淘汰了，而是被“消化”了。开源项目最好的归宿，从来不是自己活得久，而是它的思想活在了别人的产品里。
至于它本身体验粗糙、落地困难，那不是它的错——它本来就是个“思想原型”，不是“交付物”。真正把它变成可用产品的，是后来那些踩着它肩膀往前走的人。
OpenClaw 教会了我们怎么做，而后来的人教会了它怎么用。这条路，才刚刚开始。
作为一个开发人员来说，个人的能力远达不到这样的高度，也不应该去评头论足。只是个人的一点感想进行分享。
