微信龍蝦只活2天：一次更新干崩全生態(tài)，OpenClaw 撞上 Vibe Coding 天花板

整理 | 褚杏娟

3 月 22 日，微信官宣推出 ClawBot 插件，支持接入 OpenClaw，用戶掃碼或復制命令即可將其接入微信。兩天后，OpenClaw 的一次更新就“殺掉”了這只微信龍蝦。

OpenClaw 官方更新到了 v2026.3.22，新版 OpenClaw 被重新定位為跨平臺個人 AI 助手，強制將其插件生態(tài)系統(tǒng)從公共 npm 倉庫遷移到官方 ClawHub 市場，而不再像過去那樣依賴開發(fā)者熟悉的 Node.js 標準包管理平臺 npm。同時，舊版插件系統(tǒng)也被移除，改用新的軟件開發(fā)工具包。

新的公開插件 SDK 接口已調整為openclaw/plugin-sdk/*；原來的 openclaw/extension-api 已被移除，且不提供兼容層。

這說明這不是“來不及做兼容”，而是團隊主動選擇了切斷舊接口，強迫生態(tài)遷移。

npm 長期以來一直是全球 JavaScript 開發(fā)者的通用基礎設施，開發(fā)者可以自由發(fā)布和分發(fā)代碼模塊。但由于其開放性，歷史上也長期存在惡意軟件傳播、依賴投毒等問題。這次，官方?jīng)]有直接說“放棄 npm”，但它已經(jīng)用產品設計把答案寫出來了：npm 還能用，但不再是 OpenClaw 想重點押注的插件生態(tài)中心。

原生命令安裝插件時，對看起來像 npm 包名的插件，會先去 ClawHub 找，再回退到 npm。

在 OpenClaw 的更新說明里，還有一個很值得注意的安全動作：官方禁用了某些“隱式 workspace plugin 自動加載”的行為，避免用戶 clone 一個倉庫后，插件代碼在沒有明確“信任決定”的情況下自動執(zhí)行。結合 OpenClaw 生態(tài)近期暴露出的惡意 skills、供應鏈投毒和分發(fā)安全問題，這次重構把插件體系從開放式分發(fā)轉向官方可控的 registry、統(tǒng)一 SDK 和更強的執(zhí)行邊界。

錯誤不斷，微信龍蝦只活了兩天

更新后，不少開發(fā)者遇到了問題，包括缺失 “dist/control-ui” 目錄、系統(tǒng)崩潰。有用戶表示，自己的 WhatsApp 插件在更新后直接失效，不得不回滾到舊版本，才能維持服務。

OpenClaw 創(chuàng)始人 Peter Steinberger 隨后回應稱，這次問題的一個直接原因，是發(fā)布流程中漏掉了與 web control UI 資源相關的步驟，導致當前版本無法正確加載對應內容。他建議用戶先升級到已經(jīng)修復的 beta 版，或者等待后續(xù)修復后的正式版本。

但問題顯然不止這一處。國內模型如 MiniMax 配置失效、Windows 沙箱環(huán)境中權限報錯，而使用了官方插件的微信、飛書、企業(yè)微信等也遇到了“更新即崩”的問題。

對此，微信員工 @客村小蔣回應，“openclaw 的這次升級，似乎也影響了一堆國內外的 IM 消息渠道，一個新產品的迭代里有點小問題，可以理解”。根據(jù)騰訊騰訊公關總監(jiān)張軍的說法，目前微信 Clawbot 插件已完成更新并修復相關問題。

可以看出，這不是一個 bug 引發(fā)的單點失效，而是一次重構后，插件加載、消息通道、模型配置、沙箱權限、分發(fā)訪問同時出問題，說明它暴露的是系統(tǒng)級脆弱性，而不是單個模塊缺陷。

這次故障的核心在于，所有插件現(xiàn)在都必須上傳到 ClawHub 才能運行，但大量舊插件并未完成遷移。與此同時，版本升級帶來的訪問洪峰又壓垮了 ClawHub 本身，觸發(fā)了嚴格的限流機制，導致用戶既無法訪問舊插件，也無法順利下載新插件。Peter 也承認，平臺限流規(guī)則設得過嚴，后續(xù)會放寬限制，以恢復正常訪問。

于是，這次升級很快被部分用戶評價為“一次糟糕的更新”。

OpenClaw 不能隨便爆改了

在故障發(fā)生后，一些開發(fā)者開啟“自救”。

“它把那個和 memory-lancedb 都搞砸了，但我卸載了 LDB 內存插件，進入 TUI，重新安裝了它，然后輸入了網(wǎng)關啟動時的錯誤信息，嘗試了兩次之后，我又恢復正常了！比一般的調試過程簡單多了。”

某種意義上，這場事故甚至演變成了一場由 AI 幫助修 AI 的現(xiàn)場排障。有用戶用 Claude、Cursor 來救場。

這次事故可能也暴露出，OpenClaw 已經(jīng)不再是一個可以隨意爆改的實驗項目，而是要開始像基礎設施那樣被要求。

有用戶在升級到 beta 版后留言稱，他們現(xiàn)在有 8 個 agent 通過 OpenClaw 全天候 24/7 運行，因此系統(tǒng)穩(wěn)定性對他們而言極其重要。他們感謝官方這次在問題說明上的透明度，也認為自動化端到端測試流水線，在如今這種采用規(guī)模下會帶來實質性的幫助。

如果當時有更完整的自動化端到端測試，這次很多故障大概率能在正式發(fā)布前就暴露出來。區(qū)別于針對單個函數(shù)或組件的單元測試，端到端測試用于測試從開始到結束的流程，模擬真實用戶場景，確保系統(tǒng)的所有組件作為一個整體正確地運行。Peter 透露，他正在推動整個發(fā)布流程自動化，并為 web 端補充端到端測試。

整體看，這次 OpenClaw 雖然優(yōu)先考慮了開發(fā)者體驗和系統(tǒng)安全，然而沒有做好可用性和用戶體驗之間的平衡，缺乏充分的兼容性規(guī)劃、流量壓力測試以及流暢的用戶過渡方案，使得一次“升級”演變成了一場重大故障。

當 Vibe Coding 進入大規(guī)模生產環(huán)境

OpenClaw 本身就是 Vibe Coding 浪潮的產物。Peter 的開發(fā)方式很典型：他摒棄了傳統(tǒng)逐行編碼方式，而是組織一個由 AI 組成的開發(fā)團隊：用 Claude Code 入門，用 Codex 作為主力，讓多個 agent 同時跑起來，通過不斷生成、驗證、修正，快速把產品做出來。他自己專注系統(tǒng)架構與方向把控，agent 負責代碼生成、測試、調試等機械工作。

“我真的很在意整體結構。但我沒有把每一行代碼都讀一遍，因為很多代碼說白了就是枯燥的‘管道工程’。”他說道。

此前就有開發(fā)者吐槽：“OpenClaw 的多線程和定時器一定寫的一坨屎。”他評價道，當下 AI Coding 的能力，如果沒有精細化的人為干預，是做不好的，預計還要迭代很久，AI 的屎山也是屎山。

OpenClaw 早期的全量版本通常包含龐大的生態(tài)插件和架構，部分分析指出其總代碼量（包含依賴與插件庫）可能達到 40 萬行級別。而目前，OpenClaw 的 PR 數(shù)量正以一種離譜到不可能的速度增長。“我昨天干了一整天，提交了大約 600 次代碼。之前是 2700，現(xiàn)在已經(jīng)超過 3100 了。”

他表示，自己需要一個 AI，能掃描每一個 PR 和 Issue，并去重，它還應該能根據(jù)各種信號判斷，哪個 PR 才是“最靠譜的那個版本”。他打算先在 OpenClaw 的基礎上自己做一個，而 token 消耗已經(jīng)不在他考慮范圍里了。

大量 AI 代碼此前就導致 OpenClaw 經(jīng)常出現(xiàn)故障，目前 OpenClaw 依然頻繁出現(xiàn)各種問題。

而這次更新事故也恰好為 Vibe Coding 未來發(fā)展敲響了警鐘。就像由高校研究者和行業(yè)實踐團隊共同發(fā)布的論文《Vibe Coding in Practice: Flow, Technical Debt, and Guidelines for Sustainable Use》中提出的：Vibe Coding 在前期探索階段的確很好用，但很多團隊會不知不覺地把“適合快速試錯”誤認為“適合一路推進到生產環(huán)境”，而這往往正是技術債失控的起點。

需求看起來更完整了，其實也可能更模糊了

Vibe Coding 往往從自然語言提示開始，但自然語言最大的問題，就是天然不夠精確。

論文指出，很多團隊的起點往往是類似“幫我做一個支持用戶注冊、后臺管理和數(shù)據(jù)統(tǒng)計的系統(tǒng)”這樣的高層描述，這樣的提示足以讓 AI 快速開工，卻未必足以讓它做對。模型可能“自作聰明”地補上你沒有要求的功能，也可能忽略那些你沒明確寫出、卻決定系統(tǒng)能否真正上線的關鍵要求。

最容易被遺漏的，恰恰是那些非功能需求：安全、性能、可靠性、可維護性、可擴展性。這些內容不會像“做一個登錄頁”那樣直接寫進 prompt，但卻決定了系統(tǒng)最后能不能投入真實使用。論文特別提到，很多本應成為設計前提的架構關鍵需求，在 Vibe Coding 過程中會被悄悄省略。結果就是，功能看起來越來越齊全，底層質量屬性卻從一開始就沒有被認真考慮。

你以為在搭系統(tǒng)，實際上可能只是在“拼布”

架構不一致，是 Vibe Coding 的另一筆隱形債。

很多項目直接從 prompt 跳到代碼，中間缺少系統(tǒng)性的架構設計：一個頁面是這么生成的，另一個模塊是后來補的，第三個服務又是在下一輪生成時順手改出來的。短期看，功能似乎不斷增加；但時間一長，整個系統(tǒng)就容易變成一塊拼布。

論文舉了一個很典型的例子：某個基于微服務的系統(tǒng)，在一次重生成之后，把原本基于 JWT 的認證方式改成了 session cookie。表面看只是局部調整，但結果卻是其他依賴它的服務全部開始報 401。類似的情況還包括 API 字段名悄悄變化，導致前端集成測試瞬間全面失效。

這類問題最麻煩的地方在于，它們不是某一行代碼寫錯了，而是系統(tǒng)邊界在多輪生成中被慢慢侵蝕了。因此，那些看起來很“傳統(tǒng)”的工程方法，在 Vibe Coding 時代反而變得更重要：職責分層、架構文檔、領域建模、邊界約束，都沒有過時。AI 越強，系統(tǒng)越需要明確邊界。

安全問題不是“以后再修”，而是一開始就在長

論文作者團隊還用 agent 式安全掃描器檢查了 7 個早期 vibe-coded MVP，共發(fā)現(xiàn) 970 個安全問題，其中 801 個是高危問題。這個數(shù)字本身已經(jīng)足夠說明問題。

這些漏洞并不冷門，恰恰是開發(fā)里最常見也最危險的那些：路徑遍歷、不安全存儲、硬編碼密鑰、命令注入、XSS、不安全反序列化、缺失認證檢查。更關鍵的是，很多問題不是單個文件的孤立錯誤，而是在系統(tǒng)快速拼接的過程中自然長出來的。

這意味著，如果團隊把 Vibe Coding 僅僅理解成“先做出來，安全以后再補”，那么從第一版開始，風險就已經(jīng)在不斷累積。

代碼越長，你反而越不理解它

AI 生成代碼的另一個陷阱在于：它看起來很完整，卻未必真正可維護。

論文中提到，在多輪生成之后，某個系統(tǒng)后端甚至出現(xiàn)了兩份database.py，函數(shù)名略有差異，兩份文件都能運行、看起來都沒問題，但真正被調用的其實只有一份。之后 AI 在下一輪修改時又調錯了模塊，最終引發(fā)靜默錯誤，只能靠人工逐個文件排查根因。

這說明，AI 確實能讓代碼飛快增長，但它不會自動幫你維持結構秩序。如果團隊沒有文檔、沒有依賴關系追蹤、沒有代碼清理機制，系統(tǒng)最后就很容易變成“能跑，但沒人敢動”。

測試看起來有了，不等于系統(tǒng)真的被驗證了

Vibe Coding 確實很容易生成測試，但這些測試往往只覆蓋最理想的 happy path。邊界條件、錯誤處理、異常狀態(tài)、非功能需求很容易被忽略。有些測試甚至只是模型自己生成的一套 mock，運行當然能通過，卻并沒有真正驗證系統(tǒng)。

例如某個原型系統(tǒng)的認證流程測試一直是綠的，但真實登錄流程其實早就壞了。原因不是邏輯沒測，而是測試根本沒真正走到真實 session 邏輯里，只是在調用模型生成的偽造響應。于是測試通過了，系統(tǒng)卻根本沒被驗證。

本地能跑，不代表可以上線

Vibe Coding 還有一個非常現(xiàn)實的問題：代碼生成速度，已經(jīng)快過了部署護欄建設速度。

很多項目在本地環(huán)境中每個模塊都能跑起來，但一旦進入 CI/CD、集成環(huán)境或生產部署階段，問題就會集中爆發(fā)：依賴不一致、環(huán)境變量錯配、端口沖突、構建失敗、回滾困難。論文因此強調，AI 生成代碼最多只能算“第一稿”。真正要進生產環(huán)境，仍然必須經(jīng)過 lint、類型檢查、回歸測試、可觀測性、自動回滾等完整工程流程。否則，本地 demo 再漂亮，也扛不住真實業(yè)務壓力。

結束語

OpenClaw 這次出問題，表面上看是一次插件系統(tǒng)重構引發(fā)的大面積兼容性事故，但也可能是一個典型的 AI 原生產品，從“快速生長”走向“規(guī)模化生產”時，撞上的第一堵墻。

一個靠 AI 和開源社區(qū)高速生長出來的產品，生態(tài)可以迅速做大，但平臺治理、發(fā)布流程、安全邊界和兼容性體系，卻往往來不及同步成熟。這也是日后留給 OpenClaw 們的一道課題。

https://github.com/openclaw/openclaw/releases/tag/v2026.3.22

https://finance.biggo.com/news/PNZOHp0BNZYCTTDv8JbI?utm_source=chatgpt.com

https://arxiv.org/pdf/2512.11922

聲明：本文為 InfoQ 整理，不代表平臺觀點，未經(jīng)許可禁止轉載。

會議推薦

OpenClaw 出圈，“養(yǎng)蝦”潮狂熱，開年 Agentic AI 這把火燒得不可謂不旺。在這一熱潮下，自托管 Agent 形態(tài)迅速普及：多入口對話、持久記憶、Skills 工具鏈帶來強大生產力。但這背后也暴露了工程化落地的真實難題——權限邊界與隔離運行、Skills 供應鏈安全、可觀測與可追溯、記憶分層與跨場景污染、以及如何把 Agent 納入團隊研發(fā) / 運維流程并形成穩(wěn)定收益。

針對這一系列挑戰(zhàn)，在 4 月 16-18 日即將舉辦的 QCon 北京站上，我們特別策劃了「OpenClaw 生態(tài)實踐」專題，將聚焦一線實踐與踩坑復盤，分享企業(yè)如何構建私有 Skills、制定安全護欄、搭建審計與回放機制、建立質量 / 效率指標體系，最終把自托管 Agent 從可用的 Demo 升級為可靠的生產系統(tǒng)。