全文导读
* _吐槽了部署和二开 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 到 3 0W+ 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