老王開門見山地問：“卸載過 OpenClaw 嗎？”

我和老王四目相對那一刻，我懂他想要的答案：“必須啊，老 6 了。”

像 QClaw、PicoClaw、ArkClaw、澳龍各種蝦的安裝部署，我都駕輕就熟。

當(dāng)然了，如果想省掉 299 的卸載費，我還可以一條龍服務(wù)到底，不在話下。

卸載命令我都能倒背如流。

但說真的，王哥，OpenClaw 的出現(xiàn)確實解放了我的生產(chǎn)力。

你別聽風(fēng)就是雨啊。工具本身沒有好壞，看的是應(yīng)用場景。

像我，現(xiàn)在審核 gitcode 賬號再也不用親自去找了，直接把昵稱丟到飛書，愛丟幾個丟幾個，我的龍蝦一號 PaiGit 員工很快就能幫我搞定。

“逗逗你的呀，別那么上頭。”老王摸了摸他的光頭，捋了捋他的胡子，“那我問你：卸載 OpenClaw 的完整流程是什么？別給我整一條命令就完事。”

content

01、卸載龍蝦的命令是什么？

“王哥，你這個問題問得好。很多人以為卸載就是跑一條 npm uninstall -g openclaw，錯。”

這樣卸載不干凈，殘留文件會藏在系統(tǒng)的各個角落，下次重裝的時候各種報錯——端口被占用、配置沖突、插件加載失敗，一堆莫名其妙的問題。

正確的卸載姿勢分三步。

第一步：停止 Gateway 服務(wù)

openclaw gateway stop

如果 Gateway 正在跑任務(wù)，強(qiáng)制停止可能會丟數(shù)據(jù)。建議先檢查狀態(tài)：

openclaw gateway status

確認(rèn)顯示 stopped 再繼續(xù)。

第二步：執(zhí)行官方卸載命令

openclaw uninstall

這個命令會彈出一個交互界面，讓你選擇要刪除哪些內(nèi)容。用空格鍵全選，然后回車確認(rèn)。它會幫你：

停止并卸載 Gateway 服務(wù)

刪除 ~/.openclaw/  狀態(tài)目錄

清理工作區(qū)配置

移除插件和緩存

第三步：移除全局 CLI 包

npm rm -g openclaw

如果你用的是 pnpm 或 bun，對應(yīng)換成：

pnpm rm -g openclaw
# 或
bun rm -g openclaw

遇到權(quán)限錯誤就加 sudo 。

老王點點頭：“那卸載后怎么驗證干凈？”

我說：“執(zhí)行以下命令，確認(rèn)沒有殘留：”

# 檢查全局包
npm list -g openclaw
# 檢查目錄
ls ~/.openclaw/
# 檢查端口占用
lsof -i:18789

全部返回空或“not found”，才算卸載干凈。

老王聽完點點頭：“行，卸載這塊確實熟。那我追問一下，~/.openclaw/ 目錄里都有什么？為什么刪這個目錄這么重要？”

02、龍蝦的核心目錄架構(gòu)了解嗎？

“王哥，你這是要考我架構(gòu)啊。”

~/.openclaw/  是 OpenClaw 的“神經(jīng)中樞”，里面存放著所有配置和狀態(tài)。

~/.openclaw/
├── openclaw.json        # 全局配置文件
├── gateway/             # Gateway 相關(guān)
│   ├── config.json      # Gateway 配置
│   ├── logs/            # 日志目錄
│   └── pid              # 進(jìn)程 ID 文件
├── plugins/             # 插件目錄
│   ├── @openclaw/       # 官方插件
│   └── @wecom/          # 第三方插件
├── workspaces/          # Agent 工作區(qū)
│   ├── default/         # 默認(rèn) Agent
│   └── paigit/          # 自定義 Agent
├── skills/              # 技能包
├── cache/               # 緩存目錄
└── .env                 # 環(huán)境變量

老王繼續(xù)追問：“這里面的每個目錄都有什么用？你挑重點講。”

openclaw.json：全局配置文件

這是 OpenClaw 的“大腦配置中心”。

{
  "version": "2026.3.2",
"gateway": {
    "port": 18789,
    "auth": "token",
    "host": "0.0.0.0"
  },
"channels": {
    "feishu": {
      "appId": "cli_xxx",
      "appSecret": "xxx"
    },
    "wecom": {
      "botId": "xxx",
      "secret": "xxx"
    }
  },
"model": {
    "provider": "glm",
    "profile": "coding-plan",
    "defaultModel": "glm-5"
  },
"plugins": [
    "@openclaw/feishu-plugin",
    "@wecom/wecom-openclaw-plugin"
  ]
}

里面記錄了：

Gateway 配置：監(jiān)聽端口、認(rèn)證方式、綁定地址

IM 通道配置：飛書、企微等應(yīng)用的憑證

大模型配置：提供商、套餐、默認(rèn)模型

插件列表：已安裝的插件及其加載順序

王哥追問：“Gateway 配置里的 auth: "token" 是什么意思？Gateway 到底是干什么的？”

Gateway：消息路由中樞

“王哥，Gateway 是 OpenClaw 架構(gòu)里最關(guān)鍵的設(shè)計。”

很多人用 OpenClaw，只知道裝完跑 openclaw gateway start，但不知道 Gateway 到底在干啥。

簡單說，Gateway 是一個常駐后臺的消息路由服務(wù)。

它的職責(zé)有三層：

第一層：接收消息

你在飛書群里@機(jī)器人，飛書會把消息推送到 Gateway。Gateway 收到后，解析消息內(nèi)容，識別是哪個 Agent、哪個會話。

第二層：分發(fā)任務(wù)

Gateway 把消息路由給對應(yīng)的 Agent 處理。如果你配置了多個 Agent（比如一個負(fù)責(zé)代碼審核，一個負(fù)責(zé)會員審批），Gateway 會根據(jù)消息來源判斷該交給誰。

第三層：返回結(jié)果

Agent 處理完任務(wù)后，把結(jié)果交給 Gateway，Gateway 再通過 IM 通道發(fā)回飛書。

飛書消息 → Gateway → Agent → 大模型 → Agent → Gateway → 飛書回復(fù)

老王聽完眼睛一亮：“小伙子有水平啊。為什么要這樣分層？Gateway 和 Agent 為什么不耦合在一起？”

我說：“解耦。Gateway 負(fù)責(zé) IM 通信，Agent 負(fù)責(zé)任務(wù)執(zhí)行。這樣你可以一個 Gateway 掛多個 Agent，每個 Agent 用不同的模型、跑不同的任務(wù)，互不干擾。”

老王點點頭：“那如果 Gateway 掛了怎么辦？有沒有高可用方案？”

我說：“王哥，你這問題越來越深了。目前 OpenClaw 官方?jīng)]有提供高可用方案，Gateway 是單點的。如果要上生產(chǎn)，我的建議是：”

Gateway 集群部署，用負(fù)載均衡器分發(fā)請求

會話狀態(tài)下沉到 Redis，Gateway 無狀態(tài)

多實例之間用分布式鎖協(xié)調(diào)任務(wù)執(zhí)行

老王若有所思：“那插件呢？OpenClaw 的插件機(jī)制是怎么跑的？”

插件體系：微內(nèi)核架構(gòu)

我說：“OpenClaw 采用的是微內(nèi)核架構(gòu)。”

核心只提供最基礎(chǔ)的能力——消息收發(fā)、任務(wù)調(diào)度、工具調(diào)用。其他功能全部通過插件擴(kuò)展

飛書支持？插件。

企微支持？插件。

文檔處理？插件。

插件安裝在  ~/.openclaw/plugins/  目錄下，每個插件是一個獨立的 npm 包。

# 安裝飛書插件
openclaw plugins install @openclaw/feishu-plugin
# 安裝企微插件
openclaw plugins install @wecom/wecom-openclaw-plugin
# 查看已安裝插件
openclaw plugins list

老王追問：“插件加載的時機(jī)是什么？Gateway 啟動的時候？如果兩個插件對同一條消息都想處理，怎么解決沖突？”

我說：“對，Gateway 啟動時會掃描 plugins 目錄，按 openclaw.json 里的順序加載所有插件。每個插件會注冊自己的消息處理器和工具函數(shù)。”

“沖突解決靠優(yōu)先級機(jī)制——openclaw.json 里可以設(shè)置插件優(yōu)先級，優(yōu)先級高的先處理。另外每個插件有自己的命名空間，互不干擾。”

老王滿意地點點頭：“架構(gòu)這塊講清楚了。那我再問你——Gateway 的生命周期管理是怎樣的？啟動、停止、重啟流程是什么？中間有什么坑？”

Gateway 的生命周期管理

我說：“王哥，這個問題很實用，很多人踩過坑。”

啟動 Gateway

openclaw gateway start

啟動時會做幾件事：

1.加載 openclaw.json 配置

2.掃描并加載插件

3.初始化 IM 通道（連接飛書、企微等）

4.啟動 HTTP 服務(wù)監(jiān)聽端口

5.寫入 pid 文件

檢查 Gateway 狀態(tài)

openclaw gateway status

會顯示：

運行狀態(tài)（running / stopped）

進(jìn)程 ID

監(jiān)聽端口

已加載的插件數(shù)量

停止 Gateway

openclaw gateway stop

如果 Gateway 卡住，可以強(qiáng)制停止：

openclaw gateway stop --force

或者直接殺進(jìn)程：

kill $(cat ~/.openclaw/gateway/pid)

重啟 Gateway

修改配置后需要重啟：

openclaw gateway restart

老王追問：“啟動的時候常見的報錯有哪些？怎么排查？”

我說：“最常見的有三個問題。”

問題一：端口被占用

Error: Port 18789 is already in use

解決方法：

# 查看誰占用了端口
lsof -i:18789
# 殺掉占用進(jìn)程
kill -9 <PID>

問題二：插件加載失敗

Error: Failed to load plugin @openclaw/feishu-plugin

解決方法：

# 重新安裝插件
openclaw plugins uninstall @openclaw/feishu-plugin
openclaw plugins install @openclaw/feishu-plugin

問題三：配置文件損壞

Error: Invalid JSON in openclaw.json

解決方法：檢查 JSON 格式，或者直接刪掉重新配置。

老王點點頭：“那消息流轉(zhuǎn)呢？當(dāng)你在飛書群里@機(jī)器人時，消息是怎么流轉(zhuǎn)到 Agent 并返回結(jié)果的？整個鏈路涉及哪些組件？”

03、消息流轉(zhuǎn)的完整鏈路

我說：“王哥，是這樣的。”

第一步：事件訂閱

飛書把消息推給 Gateway。這需要在飛書開放平臺配置事件訂閱，開啟 im.message.receive_v1  事件。

第二步：消息解析

Gateway 收到消息后，解析消息內(nèi)容，識別來源（哪個群、哪個用戶）和意圖（要干什么）。

第三步：路由分發(fā)

根據(jù) bindings 配置，把消息發(fā)給對應(yīng)的 Agent。如果你配置了多個 Agent，Gateway 會根據(jù)消息來源判斷該交給誰。

第四步：執(zhí)行任務(wù)

Agent 調(diào)用大模型處理任務(wù)。如果是復(fù)雜任務(wù)，Agent 會拆解成多個步驟，一步步執(zhí)行。

第五步：結(jié)果返回

Gateway 把結(jié)果通過 IM 通道返回給飛書。

老王追問：“那狀態(tài)是怎么維護(hù)的？多輪對話的上下文存在哪里？”

我說：“會話上下文存在 

~/.openclaw/workspaces/<agent>/memory/

 目錄下。每次對話會序列化保存，Gateway 重啟后可以恢復(fù)。多輪對話用 session_id 標(biāo)識，防止串臺。”

老王接著問：“如果同時有 100 個用戶@機(jī)器人，Gateway 怎么處理并發(fā)？”

我說：“Gateway 用異步非阻塞 IO 處理請求。每個消息生成唯一 request_id，防止混淆。Agent 執(zhí)行隊列化，避免資源競爭。”

老王點點頭：“那 Agent 響應(yīng)很慢怎么辦？有沒有優(yōu)化方案？”

我說：“有幾種優(yōu)化思路：”

換更快的模型（比如 GPT-5.4）

簡化 BOOT.md 里的指令

用流式輸出，邊生成邊返回

復(fù)雜任務(wù)后臺異步執(zhí)行，先返回 ACK

老王聽完感慨：“你這理解得夠深的。那我再問你一個實際應(yīng)用的問題，你用 OpenClaw 干過什么真實的業(yè)務(wù)場景？別給我整那些 demo。”

04、真實業(yè)務(wù)場景：gitcode 賬號批量審核

我說：“王哥，這個問題問到我心坎里了。”

講一個真實的場景——技術(shù)派（paicoding.com）的 gitcode 賬號審核。

技術(shù)派加入的會員需要開通 gitcode 代碼倉庫的訪問權(quán)限。以前這個流程是這樣的：

1.會員申請加入

2.我收到通知

3.手動打開 gitcode 后臺

4.搜索用戶昵稱

5.添加到對應(yīng)的項目組

6.發(fā)消息通知會員審核通過

一個賬號還好，如果一次來 20 個呢？光這個流程就要折騰半小時。

現(xiàn)在呢？我把這個任務(wù)交給了 OpenClaw。

第一步：創(chuàng)建一個專屬 Agent

openclaw agents add PaiGit --workspace ~/openclaw-workspaces/paigit

第二步：配置 BOOT.md 告訴 Agent 它的職責(zé)

# PaiGit 職責(zé)
你是技術(shù)派的 gitcode 賬號審核助手。
當(dāng)收到飛書消息包含用戶昵稱時：
1. 登錄 gitcode 后臺
2. 搜索用戶
3. 添加到技術(shù)派-會員組
4. 回復(fù)審核結(jié)果

第三步：綁定飛書通道

在飛書群里，我直接發(fā)消息：

幫我審核以下用戶：張三、李四、王五

OpenClaw 收到消息后，自動執(zhí)行整個審核流程。20 個賬號，1 分鐘搞定。

老王聽完眼睛都直了：“這效率提升有點狠啊。”

我說：“還不止。我還給它設(shè)了定時任務(wù)，每天早上 9 點自動檢查有沒有新的待審核申請，有的話直接處理，處理完推送到飛書群。”

老王來了興趣：“還有沒有別的場景？”

05、場景二：飛書群消息同步

我又給他講了一個——飛書群消息同步。

技術(shù)派有好幾個飛書群：開發(fā)群、運營群、會員群。有時候一個群里發(fā)的消息需要同步到其他群，比如新功能上線通知。

以前的做法是：手動復(fù)制粘貼，或者用飛書的轉(zhuǎn)發(fā)功能。但轉(zhuǎn)發(fā)格式不好看，而且容易漏。

現(xiàn)在我用 OpenClaw 搞定了這個流程。

配置 Webhook

每個飛書群都有一個 Webhook 地址，可以在群設(shè)置里找到。

把這些 Webhook 地址告訴 OpenClaw：

記住以下群的 Webhook 地址：

開發(fā)群：https://open.feishu.cn/open-apis/bot/v2/hook/xxx

運營群：https://open.feishu.cn/open-apis/bot/v2/hook/yyy

會員群：https://open.feishu.cn/open-apis/bot/v2/hook/zzz

發(fā)送同步指令

在開發(fā)群、運營群、會員群同時發(fā)送：派聰明 v2.0 今天上線了，新增了 AI 面試助手功能，大家快去體驗！

OpenClaw 會自動調(diào)用 Webhook，把消息發(fā)到三個群。

老王點點頭：“這個場景實用，省得一個個群轉(zhuǎn)發(fā)。”

06、場景三：定時任務(wù)推送

“定時任務(wù)呢？你剛才說的每天早上 9 點給你推送最新的 hacknews 消息，是怎么實現(xiàn)的？”

OpenClaw 支持用自然語言創(chuàng)建定時任務(wù)。

直接告訴它：

每天早上 9 點，檢查有 hacknews 有沒有好玩的AI訊息，整理一下發(fā)送給我。

OpenClaw 會創(chuàng)建一個定時任務(wù)，到點自動執(zhí)行。

定時任務(wù)的底層實現(xiàn)是 cron。OpenClaw 會把自然語言轉(zhuǎn)成 cron 表達(dá)式，然后在后臺調(diào)度執(zhí)行。

老王追問：“定時任務(wù)如果執(zhí)行失敗了怎么辦？有沒有重試機(jī)制？”

我說：“目前 OpenClaw 沒有內(nèi)置重試機(jī)制，但可以通過 BOOT.md 里加錯誤處理邏輯來實現(xiàn)。比如告訴 Agent：'如果任務(wù)執(zhí)行失敗，等待 5 分鐘后重試，最多重試 3 次'。”

“另外，定時任務(wù)執(zhí)行結(jié)果會記錄到日志里，可以在 

~/.openclaw/gateway/logs/

 目錄下查看。”

老王聽完感慨：“這三個場景都挺實用的，不是那種為了用工具而用工具。”

07、大模型集成的工程化問題

老王話鋒一轉(zhuǎn)：“那我再問你一個方向——OpenClaw 需要調(diào)用大模型 API，在實際使用中，你遇到過哪些問題？比如 token 限制、響應(yīng)延遲、費用控制。你是怎么解決的？”

我說：“王哥，這個問題太實際了，我踩過不少坑。”

token 優(yōu)化

OpenClaw 燒 token 是真的快。一個稍微復(fù)雜的任務(wù)，Agent 在后臺可能調(diào)用十幾輪甚至幾十輪大模型。

我的優(yōu)化方法：

prompt 壓縮：去除冗余信息，只傳必要上下文

上下文裁剪：只保留最近 N 輪對話

結(jié)果緩存：相同問題直接返回緩存結(jié)果

響應(yīng)加速

大模型響應(yīng)慢是通病。我的方案：

流式輸出：邊生成邊返回，減少用戶等待

異步處理：復(fù)雜任務(wù)后臺執(zhí)行，先返回 ACK

模型選擇：簡單任務(wù)用 Lite 模型，復(fù)雜任務(wù)用 Pro 模型

費用控制

這個最頭疼。我的做法：

配額管理：每天/每月設(shè)置 token 上限

成本追蹤：記錄每個任務(wù)的 token 消耗

自動降級：額度用完時切換到便宜模型

老王追問：“如果大模型 API 掛了怎么辦？有沒有降級方案？”

我說：“有。大模型掛了，切換到本地模型（比如 Qwen）。網(wǎng)絡(luò)不通，用緩存兜底。超時處理，返回友好提示而非報錯。”

08、生產(chǎn)環(huán)境部署的考量

老王最后問了一個很實際的問題：“如果讓你把 OpenClaw 部署到生產(chǎn)環(huán)境，你會考慮哪些問題？”

我說：“王哥，這個問題我能講半小時。我挑重點說。”

高可用

Gateway 集群部署，用負(fù)載均衡器分發(fā)請求

會話狀態(tài)下沉到 Redis，Gateway 無狀態(tài)

多實例之間用分布式鎖協(xié)調(diào)任務(wù)執(zhí)行

監(jiān)控

Gateway 層：監(jiān)聽端口、連接數(shù)、QPS

Agent 層：任務(wù)執(zhí)行成功率、平均響應(yīng)時間

模型層：token 消耗、費用統(tǒng)計、模型調(diào)用成功率

日志

按模塊分割日志（gateway.log、agent.log、plugin.log）

關(guān)鍵操作記錄審計日志

日志輪轉(zhuǎn)和歸檔（保留 30 天）

安全

API Key 加密存儲，支持動態(tài)輪換

插件白名單機(jī)制，只允許官方插件

網(wǎng)絡(luò)隔離，Gateway 只對外暴露必要端口

老王點點頭：“最后一個問題——你在用 OpenClaw 的過程中踩過什么坑？怎么排查的？”

09、常見問題排查實戰(zhàn)

我說：“我挑幾個最典型的說。”

問題一：Gateway 啟動后收不到消息

老王問：“這個怎么排查？”

我說：“分三步走。”

第一步：檢查日志

cat ~/.openclaw/gateway/logs/error.log

看有沒有報錯信息。常見錯誤有：飛書 App ID 填錯、權(quán)限沒開通、事件訂閱沒配置。

第二步：檢查通道狀態(tài)

openclaw channels status

看飛書/企微通道是不是正常連接。

第三步：檢查飛書配置

去飛書開放平臺，確認(rèn)：

事件訂閱已開啟

im.message.receive_v1 事件已添加

長鏈接模式已啟用

問題二：模型調(diào)用失敗

老王問：“這個呢？”

我說：“模型調(diào)用失敗一般是三個原因：”

原因一：API Key 無效或過期

去大模型平臺檢查 API Key 狀態(tài)，必要時重新生成。

原因二：額度用盡

如果是 Coding Plan 套餐，檢查本月額度是否用完。用完了要么等下個月，要么升級套餐。

原因三：網(wǎng)絡(luò)問題

# 測試網(wǎng)絡(luò)連通性
curl -I https://open.bigmodel.cn

如果連不上，檢查代理配置或防火墻設(shè)置。

問題三：Agent 響應(yīng)很慢

老王問：“響應(yīng)慢怎么優(yōu)化？”

我說：“分情況處理。”

如果是模型推理慢

換更快的模型（Doubao-Seed-2.0-Lite 比 Pro 快 30%）

簡化 prompt，減少 token 數(shù)量

開啟流式輸出，邊生成邊返回

如果是任務(wù)執(zhí)行慢

拆分大任務(wù)，分批執(zhí)行

用緩存減少重復(fù)計算

后臺異步執(zhí)行，先返回 ACK

如果是網(wǎng)絡(luò)延遲

用離你最近的模型服務(wù)節(jié)點

檢查網(wǎng)絡(luò)鏈路，優(yōu)化代理配置

問題四：多 Agent 消息串臺

老王問：“這個我遇到過，怎么解決？”

我說：“多 Agent 串臺是因為 bindings 配置不清晰。”

在 openclaw.json 里用 bindings 字段明確指定每個 Agent 對應(yīng)的通道：

{
  "bindings": [
    {
      "agentId": "PaiGit",
      "match": {
        "channel": "feishu",
        "appId": "cli_xxx"
      }
    },
    {
      "agentId": "PaiReview",
      "match": {
        "channel": "feishu",
        "appId": "cli_yyy"
      }
    }
  ]
}

這樣 Gateway 收到消息時，會根據(jù) App ID 精準(zhǔn)路由到對應(yīng) Agent，不會串臺。

老王聽完感慨：“你這排查思路挺清晰的，不是那種遇到問題就懵的人。”

我說：“王哥，這都是踩坑踩出來的經(jīng)驗。OpenClaw 文檔雖然全，但很多問題得自己摸索。”

老王沉默了兩秒，然后說：“你什么時候能來上班？”

ending

不瞞大家說，有小伙伴最近去面試，的確有遇到面試官問 OpenClaw 的，可惜他之前沒有準(zhǔn)備，后悔不已。

這波浪就在眼前。

你沖，它在眼前。你不沖，它仍在眼前。

重要的是應(yīng)用場景，為你所用。

假如你沒有應(yīng)用場景，也沒必要硬湊。沒有龍蝦的日子，也許會更幸福一點。

反正我爸每天就是打打牌，曬曬太陽，我就很羨慕他。

當(dāng)然了，有龍蝦的日子，我也過得很幸福。因為它確實有幫助到我——一個簡單的 gitcode 賬號審核，就幫了我大忙。

到此這篇關(guān)于卸載OpenClaw命令是什么?OpenClaw卸載的完整流程的文章就介紹到這了,更多相關(guān)卸載OpenClaw方法內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持腳本之家！

推薦閱讀：

OpenClaw/Clawdbot必裝10大Skills指南：從部署到技能精通

零基礎(chǔ)入門OpenClaw 完整安裝配置實戰(zhàn)指南(完全流程)

OpenClaw配置部署完整實戰(zhàn)指南(附踩坑記錄)

最新評論