作者在使用OpenClaw后，反思了其稳定性和工程化问题，强调了在AI应用中，架构设计和产品判断的重要性。暗示了AI是助手，但Owner仍然是人。
原文标题：我给 OpenClaw 杀了 47 次僵尸进程，终于想明白了一些事
原文作者：阿里云开发者
冷月清谈：
怜星夜思：
2、文章中提到了OpenClaw坚持本地主义，数据都在用户本地，这既是优势也是劣势。你认为在AI应用中，数据隐私和便捷性之间应该如何平衡？
3、文章提到了“RAG已死”的观点，并对比了grep检索和传统RAG的优劣。你认为在未来的AI应用中，哪种知识检索方式会更受欢迎，或者两者会长期共存？
原文内容
全文导读
-
吐槽了部署和二开OpenClaw踩过的坑
-
吐槽了钉钉通道集成的问题
-
探究了OpenClaw为啥火
-
对比了本地模式和云上沙箱
-
反思了Skill 与传统Agent 工程
-
反思了AI 交付产品的局限性
Gateway 挂了，整个世界都挂了
我必须承认，OpenClaw 用起来确实不顺手（PS：截止2月中下旬的版本来说）。
不是那种"学习曲线陡峭"的难用，而是那种"你以为它能跑起来，结果它动不动就挂"的难用。然后一整个春节假期就是，刚收完红包就去打开电脑重启一下，年夜饭开场去重启一下，小孩一睡着就马不停蹄的修连接器。
Gateway 是整个服务端运行时和唯一控制平面。你会发现：消息渠道的生命周期管理、Agent 事件分发、定时任务调度、插件加载、浏览器自动化、设备节点注册、会话和状态存储——全部都绑在这个长期运行的 WebSocket 进程上。更要命的是，OpenClaw 现在所有的进化路径和交互方式（从 IM 里下命令、用 mac 应用/CLI 配置、远程连节点、在线装插件和技能自更新）也都绕不过这条通道：一旦 Gateway 被插件拖挂、卡死或者崩溃，你的 AI 当场失控——远程消息进不来，指令发不出去，自救脚本也打不到进程里，只剩下走到那台机器前，亲手把 Gateway 从泥潭里挖出来这一条路。
在项目初期我还在折腾Channel的时候，遇到 Gateway 的问题几乎是每天两三次：旧进程没有正常退出，变成僵尸进程霸占端口，新进程启动不了，系统反复重启但始终恢复不了。有时候重启命令本身还会和后台遗留的进程打架，两边互相抢端口，谁也启动不成功。更离谱的是，偶尔连接会突然要求重新配对，之前建立的会话全部作废。
社区里甚至有人建议：装两个 OpenClaw 左右互搏，一个挂了让另一个修。当然这不是优雅的解决方案，而是向现实投降的黑色幽默。
图一：OpenClaw左右互搏的黑色幽默
钉钉通道集成？还是有原生和插件的区别对待。[截止春节的时候,最近钉钉插件已经完成重构] 对比 Telegram 这种完整实现 ChannelPlugin 接口、可以用 openclaw channels 命令统一管理的标准 Connector，钉钉这些本土化通道更像是"嫁接"上去的独立应用——核心的 gateway、status、pairing 适配器全部缺失，用的还是之前的clawdbot/plugin-sdk，CLI 配置、状态查看、健康探测这些基本能力统统没有。
另外更加麻烦的是图片消息处理：这块儿的图片识别实现并不完整，富文本消息只返回 [富文本消息] 占位符，独立图片只返回 [图片]，完全没有下载实际图片的逻辑。导致不得不重写消息解析、实现图片下载…我感觉把一个“集成”项目生生做成了“二开”。
图二：Telegram和DingTalk的通道架构区别
当然除了渠道集成的问题，大模型推理服务本身的稳定性也是个大麻烦。Glm-5 的推理引擎时不时 限流报错，基模对 Agent 调用格式的支持有时错乱导致下游解析失败，Qwen 3.5 偶尔图片识别任务死循环，同一个工具反复调用 20 多次停不下来……
用惯了被一堆工程师反复打磨过鲁棒性的成熟产品，再回来折腾这种"粗糙原始"的开源产品，很难不重新审视自己之前对 AI 编程的乐观判断。
30 万 Star 不光技术的胜利，更是叙事的胜利
刚看到 OpenClaw 宣传的时候，总觉得又是概念炒作——远程指挥、本地操作、Skill 无限进步，听着很美。但仔细一想，这些能力并不新鲜：远程执行任务，Claude Code 的 Cloud Bot 早就能做；写代码，Claude Code、Cursor、Qoder 哪个不行；操作浏览器，Playwright on CDP、Chrome 插件 relay 都是成熟方案；扩展能力，Skill/MCP/SubAgent 早就是 Agent 的事实标准。
但 OpenClaw 做了一件别人没做过的事：它第一次把"个人 AI 助理"这件事完整地具象化了。
以前大家对"AI 助理"的印象，基本就是一个躲在聊天窗口或 IDE 里的程序，能干的事儿由开发者预设好——ChatGPT 负责聊天、Claude Code/Cursor 写代码、Nanobanana 画图、Gemini Deep Research 做研究、Manus 处理云上办公，各管各的。
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的Github Star神话之路
你的数据在你手里，你的 bug 也在
OpenClaw 坚持本地主义：你的数据在你自己的机器上，AI Agent 直接操作你的系统。
这是最私密、最自由的方式。你可以审查每一行代码，确保它的行为符合预期。你不需要把 API 密钥上传到任何第三方云端。软件免费，只需支付 LLM 的 API 调用费用。
但这也是最不安全的方式。OpenClaw 能执行任意 Shell 命令、访问本地文件，恶意技能或提示注入攻击随时可能导致数据泄露甚至系统被控制。Cisco 扫描 ClawHub 发现 26% 的社区技能至少包含一个漏洞，Moltbook 事件更是暴露了 数万个 API 密钥——开源的自由和开源的风险，一直都是硬币的两面。
相反，Manus 走的是云端沙箱模式，靠的是用户和市场对这家公司的品牌信任。虽然迭代慢一点，但体验稳定、安全、多端一致。浏览器控制精准，视觉识别几乎没 bug。它未必“更强”，但明显“更成熟”。
|
|
OpenClaw |
Manus AI |
|
运行模式 |
开源、本地自托管 |
闭源 SaaS |
|
数据隐私 |
用户完全控制 |
数据托管在云端 |
|
成本 |
软件免费，仅付 API 费用 |
付费订阅 |
|
安全风险 |
有，需用户自担 |
由平台承担 |
|
用户体验 |
上手门槛高 |
开箱即用 |
|
功能扩展 |
本地电脑能力边界 |
厂商功能设计 |
这是两种截然不同的哲学。选 OpenClaw 为代表的开源本地派，你选的是自主权；选 Manus 为代表的云端沙箱派，你选的是省心。[当然你也可以选择商业化的本地产品，例如我司的“QoderWork”，虽然不开源但至少稳定很多。]
AI 应用的工程化已死？（当我开始用 grep 代替向量库）
OpenClaw 的另一个哲学是基于 Skill 的 AI Agent 开发模式。这个模式和传统工程很不一样：不再穷举、规定用户的操作路径，而是靠基础能力让 AI 自动组装。换来了机制的灵活性和插件扩展性，但也牺牲了效率和 Token。
比如说我最近用 OpenClaw 搭了一个轻量级的知识问答系统，用于学习辅助。场景很简单：把教材和题库放在本地，用户提问时实时检索相关内容，拼接到 prompt 里让模型回答。
按照传统思路，这事应该用 RAG——分块、建向量库、存数据库，工程量不小，还得配高内存机器。半年前大家还在讨论 RAG 不要自己建，技术细节大厂已经趟过了，直接用 RAG 服务即可。但这又和 OpenClaw 的本地主义背道而驰。
所以我没有这么做。效仿 ClaudeCode 等一众编程 Agent，直接用 pdfgrep 搜索 PDF 文件，找到相关段落后拼到上下文里，就跑起来了。
没有向量库，没有分片，没有数据库，甚至没有预处理步骤。
这看起来很"土"，但它像人找东西一样：翻文件、Ctrl+F、看上下文，不搞复杂索引。低成本、快速验证，全程让 OpenClaw+QoderCli 设计实现，几个小时就能搞一套落地能用的系统。（PS：时间主要浪费在连接器之类的地方了，本可以更快）
后来在 Hacker News 上看到一篇《RAG的墓志铭 The RAG Obituary》，讨论的是同一件事。
当然，每一个激进的观点都可能在博眼球。世界或许正在变革，但这终究是一个 trade-off，让我们多了一个选择：在不值得建向量库的场景里，用最朴素的方式解决问题。
我把两种方案放在一起对比，差异一目了然：
|
|
Agent grep 式检索 |
传统 RAG + 向量库 |
|
前置工程量 |
几乎为零，无需分片、建库、预处理 |
重，需要分块、Embedding、数据库部署 |
|
自建速度 |
几小时可用 |
数天到数周 |
|
Token 消耗 |
高，命中段落整段塞进 prompt |
低，只返回相关片段 |
|
检索精度 |
依赖关键词命中，模糊匹配弱 |
语义相似度匹配，召回率高 |
|
响应延迟 |
每次全文搜索，文件越大越慢 |
索引查询，毫秒级返回 |
|
维护成本 |
无额外依赖，文件更新即生效 |
需要维护向量库、重建索引 |
|
适用场景 |
小规模、低频率、高灵活性 |
大规模、高频率、结构化知识库 |
|
本地友好度 |
天然本地，零外部服务 |
通常依赖数据库服务或云端 RAG 平台 |
所以“RAG已死”只是一句夸张的墓志铭，现实是：工程化还在，只是被迫和 Agent 模式重新分工。
1337 个测试文件：AI 写得了代码，做不了产品
我们总说 AI 能让产品日抛、快速迭代。Claude Code 的创始人 Boris Cherny 甚至宣称："Claude Code 写了 100% 的新 Cowork，我们在一周半内就发布了。"听起来很美好，但现实呢？
一开始我也直觉认为：只要测试金字塔搭够高、覆盖率拉到漂亮，单人 + 纯 AI 做 TDD，就能把 OpenClaw 这种系统"守"住。
后来翻代码才意识到，TDD 能帮你守住"别一下子炸掉"的底线，但救不了产品的整体可用性。
OpenClaw 的测试体系不可谓不庞大：1,337 个测试文件，六个层次（Unit → Gateway Unit → Extension → E2E → Live → Docker E2E），覆盖率阈值 70%。但每一层的维护成本是指数级递增的——底层单元测试要精确控制时间、状态和环境隔离，稍有泄漏整个 test suite 就变成"本地绿、CI 偶尔红"的诡异状态；E2E 层要在同一进程里拉起完整的 Gateway，走通 WebSocket、Agent 调用、文件写入的完整闭环，哪些环节 mock、哪些走真实磁盘，全凭对系统拓扑的理解来取舍；再往上的 Live 测试要调用真实的 LLM API，贵、慢、不稳定，Docker E2E 更是要从零模拟用户的完整使用流程。
图四：OpenClaw的测试分层架构
这一整套体系，真正难的不是"写测试代码"，而是人要先决定在哪一层验证什么、牺牲什么，再让自动化去执行。 AI 可以帮你写断言，但很难自己发现跨文件的隐性耦合；可以帮你生成用例，但很难判断一个 E2E 场景该覆盖到哪里、在哪里止步。
即便有这么多测试，浏览器工具触发压缩死锁、SSE 流中断、/stop 指令被长队列淹没——这些问题依然频繁出现在OpenClaw的 Issue 里。另外Issue 清单里还有大量 [low] Test Bug Report，说明测试本身也在不断出错、不断维护。
TDD 最多把 OpenClaw 变成一个"没那么容易死"的工程，却没法自动把它变成一个"好用到每个人体验顺畅"的产品。 哪些地方该测、测到什么程度、哪些边界情况该通过产品设计去规避，这些判断仍然是人的工作。
860 个贡献者，但是架构师和产品经理依旧空缺
不是技术谁先进，而是背后有没有人扛架构决策、有没有人做产品取舍。
一个真正跑在企业里的产品，需要有人在写代码前就规划好并发控制、资源隔离这些"看不见的地基"，需要有人制定发布节奏和回滚规则，需要有人盯体验指标和工单——这些工作不在代码仓库里，却直接决定"这东西敢不敢让团队天天用"。
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，大规模高频率靠工程化。
沿着马斯克的说法，不是未来已来，而是未来来了一半。不用神话，不用焦虑，也不要抵抗 —— 赶紧上船一起划。
附录 & 参考链接：
-
The RAG Obituary: Killed by Agents, Buried by Context Windows：https://www.nicolasbustamante.com/p/the-rag-obituary-killed-by-agents
-
Manus决定出售前最后的访谈(Peak)：https://www.xiaoyuzhoufm.com/episode/695331cb2db086f897b50ea9