的难用。然后一整个春节假期就是，刚收完红包就去打开电脑重启一下，年夜饭开场去重启一下，小孩一睡着就马不停蹄的修连接器。

　　Gateway是整个服务端运行时和唯一控制平面。你会发现：消息渠道的生命周期管理、Agent事件分发、定时任务调度、插件加载、浏览器自动化、设备节点注册、会话和状态存储——全部都绑在这个长期运行的WebSocket进程上。更要命的是，OpenClaw现在所有的进化路径和交互方式（从IM里下命令、用mac应用/CLI配置、远程连节点、在线装插件和技能自更新）也都绕不过这条通道：一旦Gateway被插件拖挂、卡死或者崩溃，你的AI当场失控——远程消息进不来，指令发不出去，自救脚本也打不到进程里，只剩下走到那台机器前，亲手把Gateway从泥潭里挖出来这一条路。

　　在项目初期我还在折腾Channel的时候，遇到Gateway的问题几乎是每天两三次：旧进程没有正常退出，变成僵尸进程霸占端口，新进程启动不了，系统反复重启但始终恢复不了。有时候重启命令本身还会和后台遗留的进程打架，两边互相抢端口，谁也启动不成功。更离谱的是，偶尔连接会突然要求重新配对，之前建立的会话全部作废。

　　社区里甚至有人建议：装两个OpenClaw左右互搏，一个挂了让另一个修。当然这不是优雅的解决方案，而是向现实投降的黑色幽默。

　　钉钉通道集成？还是有原生和插件的区别对待。[截止春节的时候,最近钉钉插件已经完成重构]对比Telegram这种完整实现ChannelPlugin接口、可以用openclaw channels命令统一管理的标准Connector，钉钉这些本土化通道更像是嫁接上去的独立应用——核心的gateway、status、pairing适配器全部缺失，用的还是之前的clawdbot/plugin-sdk，CLI配置、状态查看、健康探测这些基本能力统统没有。

　　另外更加麻烦的是图片消息处理：这块儿的图片识别实现并不完整，富文本消息只返回[富文本消息]占位符，独立图片只返回[图片]，完全没有下载实际图片的逻辑。导致不得不重写消息解析、实现图片下载…我感觉把一个“集成”项目生生做成了“二开”。

　　当然除了渠道集成的问题，大模型推理服务本身的稳定性也是个大麻烦。Glm-5的推理引擎时不时 限流报错，基模对Agent调用格式的支持有时错乱导致下游解析失败，Qwen 3.5偶尔图片识别任务死循环，同一个工具反复调用20多次停不下来……

　　用惯了被一堆工程师反复打磨过鲁棒性的成熟产品，再回来折腾这种粗糙原始的开源产品，很难不重新审视自己之前对AI编程的乐观判断。

　　刚看到OpenClaw宣传的时候，总觉得又是概念炒作——远程指挥、本地操作、Skill无限进步，听着很美。但仔细一想，这些能力并不新鲜：远程执行任务，Claude Code的Cloud Bot早就能做；写代码，Claude Code、Cursor、Qoder哪个不行；操作浏览器，Playwright on CDP、Chrome插件relay都是成熟方案；扩展能力，Skill/MCP/SubAgent早就是Agent的事实标准。

　　但OpenClaw做了一件别人没做过的事：它第一次把个人AI助理这件事完整地具象化了。

　　OpenClaw把这些全融在一起了。它给人的感觉是：这玩意儿能动我整个电脑，不只是写代码，而是能完成我用电脑能完成的一切。最近猎豹CEO傅盛的龙虾三万养成日记很火，讲的也是同一个叙事——一个无限成长的万能个人助理。这种跨越数字与真实界限的执行能力，让人真切感受到了AI作为生产力工具的巨大潜力。

　　它甚至帮非技术人员克服了对IDE和命令行的恐惧。不需要打开VSCode，不需要敲git commit，在Telegram或钉钉里说一句话，AI就帮你干活了。这种无处不在的特性，极大降低了使用门槛。

　　当然，OpenClaw的成功不仅仅是叙事的功劳，它站在一整条已经被打磨过的技术链条之上：底层是Pi-Mono这类极简Agent运行时和Agent Loop的循环范式，上层复用了Skill/MCP工具标准、Playwright+CDP+Chrome扩展拼出的浏览器控制栈，再加上Telegram/WhatsApp/钉钉等成熟IM Bot SDK撑起的多渠道远程控制——这才让一个数周的项目，看上去像从一开始就很全面的系统。另外而在技术底座之外，Moltbook事件、Karpathy的「科幻起飞」推文、Musk的「奇点早期阶段」评论、Mac mini缺货、Lex Fridman播客采访、OpenAI的收购意向……一系列事件接连引爆，把这个故事推成了现象级话题。三个月，从0到30W+ GitHub Star，单周200万访客。是不是技术的奇点不好说，但一定是叙事的胜利。

　　OpenClaw坚持本地主义：你的数据在你自己的机器上，AI Agent 直接操作你的系统。

　　这是最私密、最自由的方式。你可以审查每一行代码，确保它的行为符合预期。你不需要把API密钥上传到任何第三方云端。软件免费，只需支付LLM的API调用费用。

　　但这也是最不安全的方式。OpenClaw能执行任意Shell命令、访问本地文件，恶意技能或提示注入攻击随时可能导致数据泄露甚至系统被控制。Cisco扫描ClawHub发现26%的社区技能至少包含一个漏洞，Moltbook事件更是暴露了数万个API密钥——开源的自由和开源的风险，一直都是硬币的两面。

　　相反，Manus走的是云端沙箱模式，靠的是用户和市场对这家公司的品牌信任。虽然迭代慢一点，但体验稳定、安全、多端一致。浏览器控制精准，视觉识别几乎没bug。它未必“更强”，但明显“更成熟”。

　　这是两种截然不同的哲学。选 OpenClaw 为代表的开源本地派，你选的是自主权；选 Manus 为代表的云端沙箱派，你选的是省心。[当然你也可以选择商业化的本地产品，例如我司的“QoderWork”，虽然不开源但至少稳定很多。]

　　OpenClaw的另一个哲学是基于Skill的AI Agent开发模式。这个模式和传统工程很不一样：不再穷举、规定用户的操作路径，而是靠基础能力让AI自动组装。换来了机制的灵活性和插件扩展性，但也牺牲了效率和Token。

　　比如说我最近用OpenClaw搭了一个轻量级的知识问答系统，用于学习辅助。场景很简单：把教材和题库放在本地，用户提问时实时检索相关内容，拼接到prompt里让模型回答。

　　按照传统思路，这事应该用RAG——分块、建向量库、存数据库，工程量不小，还得配高内存机器。半年前大家还在讨论RAG不要自己建，技术细节大厂已经趟过了，直接用RAG服务即可。但这又和OpenClaw的本地主义背道而驰。

　　所以我没有这么做。效仿ClaudeCode等一众编程Agent，直接用pdfgrep搜索PDF文件，找到相关段落后拼到上下文里，就跑起来了。

　　这看起来很土，但它像人找东西一样：翻文件、Ctrl+F、看上下文，不搞复杂索引。低成本、快速验证，全程让OpenClaw+QoderCli设计实现，几个小时就能搞一套落地能用的系统。（PS：时间主要浪费在连接器之类的地方了，本可以更快）

　　当然，每一个激进的观点都可能在博眼球。世界或许正在变革，但这终究是一个trade-off，让我们多了一个选择：在不值得建向量库的场景里，用最朴素的方式解决问题。

　　所以“RAG已死”只是一句夸张的墓志铭，现实是：工程化还在，只是被迫和Agent模式重新分工。

　　一开始我也直觉认为：只要测试金字塔搭够高、覆盖率拉到漂亮，单人+纯AI做TDD，就能把OpenClaw这种系统守住。

　　后来翻代码才意识到，TDD能帮你守住别一下子炸掉的底线，但救不了产品的整体可用性。

　　OpenClaw的测试体系不可谓不庞大：1,337个测试文件，六个层次（Unit→Gateway Unit→Extension→E2E→Live→Docker E2E），覆盖率阈值70%。但每一层的维护成本是指数级递增的——底层单元测试要精确控制时间、状态和环境隔离，稍有泄漏整个test suite就变成本地绿、CI偶尔红的诡异状态；E2E层要在同一进程里拉起完整的Gateway，走通WebSocket、Agent调用、文件写入的完整闭环，哪些环节mock、哪些走真实磁盘clash安卓配置文件下载，全凭对系统拓扑的理解来取舍；再往上的Live测试要调用真实的LLM API，贵、慢、不稳定，Docker E2E更是要从零模拟用户的完整使用流程。

　　这一整套体系，真正难的不是写测试代码，而是人要先决定在哪一层验证什么、牺牲什么，再让自动化去执行。AI可以帮你写断言，但很难自己发现跨文件的隐性耦合；可以帮你生成用例，但很难判断一个E2E场景该覆盖到哪里、在哪里止步。

　　即便有这么多测试，浏览器工具触发压缩死锁、SSE流中断、/stop指令被长队列淹没——这些问题依然频繁出现在OpenClaw的Issue里。另外Issue清单里还有大量[low] Test Bug Report，说明测试本身也在不断出错、不断维护。

　　TDD最多把OpenClaw变成一个没那么容易死的工程，却没法自动把它变成一个好用到每个人体验顺畅的产品。哪些地方该测、测到什么程度、哪些边界情况该通过产品设计去规避，这些判断仍然是人的工作。

　　一个真正跑在企业里的产品，需要有人在写代码前就规划好并发控制、资源隔离这些看不见的地基，需要有人制定发布节奏和回滚规则，需要有人盯体验指标和工单——这些工作不在代码仓库里，却直接决定这东西敢不敢让团队天天用。

　　Manus的浏览器操作能力，不是临时拼凑的，来自于它对于Monica的积累。之前我觉得AI时代来临后的追赶其实很快，但是这种长期细节积累的追赶其实也不是一蹴而就。在深度体验了Manus的浏览器操作之后（控制准确，识别稳定，边界处理到位），我感慨Manus的Peak在播客里面确实没有吹牛。

　　反观OpenClaw做同样的事？浏览器扩展经常连不上标签页，自动化流程中途莫名中断。不是它不想做好，而是还没走到那一步——缺的不是代码量，是对于异常和边界的持续收敛和打磨的过程。

　　OpenClaw应该是目前最活跃的开源项目了(860+贡献者，4.4K的PR)，但活跃度不等于成熟度，我猜不少这种零碎的问题，甚至还没来得及系统性地被摆上桌。（PS：社区活跃是真的太活跃了，我fork了工程，三天写了20个commit沾沾自喜，一看落后了主干1833个……）

　　AI能帮你写代码，但不能帮你做架构决策；能修bug，但不能预见长链路死锁场景；能跑测试，但不能告诉你哪些功能该砍掉。

　　翻一翻OpenClaw的活跃Issue就能看出来：并发控制缺失导致的浏览器工具死锁、Docker环境下Chromium进程不限内存直接拖垮主机、SSE流中断和15秒超时问题、核心模块单个文件50+个import导致的回归测试地狱……

　　这些不是写代码能解决的，而是需要在方案选型时就考虑好资源隔离、通信协议稳健性、模块解耦这些架构问题。AI会写lock/unlock，但它看不见跨组件的长链路陷阱；AI能快速实现功能，但它不会自发考虑多租户隔离、熔断机制这些防御性编程需求。

　　相比之下，Manus的方案虽然没有本地化的灵活，但是云端沙箱和浏览器控制，也让他从复杂度上少了一大部分。另外它海量迭代的A/B Test，对终端用户来说不稳定的能力极少暴露出来。

　　这个层面来说或许少即是多，也是开源自由和商业聚焦的根本差别。

　　1人+ AI的项目，规模稍大就会损失商业化级别的体验。AI能帮人快速写代码、跑测试，但架构设计、产品判断、边界取舍——这些决定能不能用的事，依然需要人来扛。测试再多，也只能守住别一下子炸掉的底线，守不住整体的可用性和体验。

　　AI助理的演进很快，但不是一蹴而就的。从聊天到写代码，从操作浏览器到整合多渠道，完整的个人助理正在一步步成型。趋势明确，但每一步能力的打磨都需要时间。今天的OpenClaw是未来的雏形，而不是未来本身。更何况，这种模式的安全问题也很难保障。

　　AI应用的工程化依然重要，不会被Skill模式取代。Skill模式用灵活性换扩展性，传统工程化用前置投入换稳定性。不是谁替代谁，是场景决定选择——小规模高灵活用Skill，大规模高频率靠工程化。

　　沿着马斯克的说法，不是未来已来，而是未来来了一半。不用神话，不用焦虑，也不要抵抗——赶紧上船一起划。