2026年7月9日 周四晚上19:30,报名腾讯会议了解“如何构建自进化的动态知识库(Brain)”(限30人)
免费POC, 零成本试错
FDE知识库

FDE知识库

学习大模型的前沿技术与行业落地应用


收藏

我给 OpenClaw 杀了 47 次僵尸进程,终于想明白了一些事

发布日期:2026-03-18 08:45:58 浏览次数: 2709
作者:阿里云开发者

微信搜一搜,关注“阿里云开发者”

推荐语

OpenClaw开发者血泪史:47次僵尸进程大战后的工程反思,揭秘AI产品交付的暗坑。

核心内容:
1. OpenClaw架构致命伤:Gateway单点故障引发的连环崩溃
2. 钉钉通道集成困境:原生支持缺失导致的二次开发噩梦
3. AI工程化启示录:从Skill设计到云部署的局限性思考

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家

全文导读



  • 吐槽了部署和二开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,钉钉这些本土化通道更像是"嫁接"上去的独立应用——核心的 gatewaystatuspairing 适配器全部缺失,用的还是之前的clawdbot/plugin-sdkCLI 配置、状态查看、健康探测这些基本能力统统没有。



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





图二:TelegramDingTalk的通道架构区别

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



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



30 万 Star 不光技术的胜利,更是叙事的胜利


刚看到 OpenClaw 宣传的时候,总觉得又是概念炒作——远程指挥、本地操作、Skill 无限进步,听着很美。但仔细一想,这些能力并不新鲜:远程执行任务,Claude Code  Cloud Bot 早就能做;写代码,Claude CodeCursorQoder 哪个不行;操作浏览器,Playwright on CDPChrome 插件 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 万访客。是不是技术的奇点不好说,但一定是叙事的胜利。





图三:OpenClawGithub 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,走通 WebSocketAgent 调用、文件写入的完整闭环,哪些环节 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,大规模高频率靠工程化。



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


53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询

扫码登录
登录即表示您同意《53AI网站服务协议》
服务协议

欢迎您使用【53AI 官方网站】(以下简称“本网站”或“我们”)。本《会员服务协议》(以下简称“本协议”)是您(以下简称“会员”或“用户”)与【深圳市博思协创网络科技有限公司】之间关于注册、登录及使用本网站会员服务所订立的法律协议。

在您注册或登录前,请务必审慎阅读、充分理解各条款内容,特别是免除或限制责任的条款、知识产权条款、争议解决条款等。此类条款将以加粗形式提示您注意。 当您通过微信公众号授权、手机验证码验证或其他方式成功登录本网站时,即视为您已完全理解并同意接受本协议的全部内容。

一、 定义

本网站:指由【深圳市博思协创网络科技有限公司】运营的,域名为【53ai.com】的网站及相关移动端页面。

会员服务:指本网站向注册会员提供的知识库文章查阅、内容检索及其他相关增值服务。

知识库内容:指本网站发布的包括但不限于文字、图表、数据、研究报告、行业分析等数字化内容资源。

二、 账号注册与登录

登录方式:本网站支持以下登录方式,您可根据实际情况选择:

微信公众号授权登录:您同意将您的微信OpenID信息授权给本网站,用于创建或关联会员账号。

手机验证码登录:您需提供真实有效的手机号码,并通过短信验证码完成身份验证与登录/注册。

账号安全:您的账号仅限您本人使用,禁止赠与、借用、租用、转让或售卖。因您保管不善导致的账号被盗、密码泄露等损失,由您自行承担。

实名认证:根据相关法律法规要求,我们可能要求您在特定功能下完成实名认证。如您拒绝提供,可能无法使用部分或全部服务。

未成年人保护:若您未满18周岁,请在法定监护人的陪同下阅读本协议,并在征得监护人同意后使用本服务。

三、 服务内容与规范

知识库查阅权限:会员登录后,有权按照其会员等级对应的权限范围,在线浏览、检索本网站知识库中的相关文章及内容。

服务变更:我们有权根据业务发展需要,调整、变更或终止部分服务内容,并将以网站公告、公众号消息等方式提前通知。

禁止行为:您在使用服务时不得实施以下行为:

利用技术手段批量爬取、下载、转存知识库内容;

将知识库内容用于商业目的或未经授权地向第三方传播;

干扰本网站正常运行或侵犯其他用户合法权益;

发布违法违规信息或从事违反公序良俗的活动。

四、 知识产权声明

权利归属:本网站知识库中的排版设计、软件代码等内容的知识产权均归【公司全称】或原权利人所有,受《中华人民共和国著作权法》等法律保护。

有限许可:本网站授予会员一项非独占、不可转让、不可转授权的普通许可,仅限于个人学习、研究之目的在线查阅知识库内容。

侵权追责:未经书面许可,任何单位或个人不得以任何形式复制、转载、摘编、镜像、汇编或以其他方式使用上述内容。一经发现,我们保留追究其法律责任的权利。

五、 个人信息保护

我们重视对您个人信息的保护。关于我们如何收集、使用、存储和保护您的个人信息,请单独阅读 《隐私政策》。

您通过微信公众号授权或手机号验证所提供的信息,我们将严格按照《个人信息保护法》的规定处理,仅用于身份识别、服务提供及安全验证等必要用途。

您可以随时通过网站设置或联系客服行使查阅、更正、删除个人信息及撤回授权同意的权利。

六、 免责声明

内容准确性:知识库内容仅供参考,不构成专业建议。我们不对其完整性、准确性、时效性作任何明示或暗示的保证,您应自行判断并承担使用风险。

不可抗力:因自然灾害、政策法规变化、网络故障、第三方平台接口异常(如微信接口维护、运营商短信通道故障)等不可抗力导致的服务中断或延迟,我们不承担违约责任。

第三方链接:本网站可能包含指向第三方网站的链接,该等网站的内容和服务不受我们控制,请您自行甄别风险。

七、 违约责任

如您违反本协议约定,我们有权视情节采取警告、限制功能、暂停服务、注销账号等措施,并保留要求赔偿损失的权利。

如因您的违约行为导致我们遭受行政处罚、第三方索赔或商誉损失,您应承担全部赔偿责任(包括但不限于罚款、赔偿金、律师费、公证费等)。

八、 法律适用与争议解决

本协议的订立、执行和解释均适用中华人民共和国大陆地区法律。

因本协议产生的或与本协议有关的任何争议,双方应友好协商解决;协商不成的,任何一方均可向【公司所在地】有管辖权的人民法院提起诉讼。

九、 其他

本协议构成双方就本服务达成的完整协议,取代此前任何口头或书面约定。

本协议任一条款被认定为无效或不可执行的,不影响其他条款的效力。

我们对本协议享有最终解释权,并在法律允许的范围内保留随时修改的权利。修改后的协议一经公布即生效,继续使用服务即视为同意修订内容。


已查阅