OpenClaw，或是大家常暱稱的「龍蝦」，絕對是這幾個月AI 領域最火紅的題材沒有之一。有人說它是未來 Agentic AI 的雛形，也有人已經用它打造出能多個自動運行的 AI Agent，開始包辦日常營運的微型公司。面對這麼神奇的東西，我當然也想親自參一腳。
因此，我花了大約一天的時間架設並成功讓它運作。但沒想到，接下來的一個禮拜，我幾乎陷入無止盡的修修補補。我每天都在重複同樣的「debug 地獄循環」：早上醒來發現整個系統崩潰，花了好幾個小時除錯，直到睡前好不容易修好，讓它正常運行了一兩個小時。本以為可以安心去睡覺，隔天早上打開手機，卻發現它又掛了。
一個多禮拜後我才驚覺，我花在修理它的時間，早就遠大於能好好享受它帶來產能的時間。再加上我認為不斷修復這些特定軟體的系統崩潰，對我長遠學習 AI 領域知識的邊際效應實在太低。在權衡利弊後，我認知到自己目前的技術能力與系統理解深度，或許還不足以長時間穩定維護這隻龍蝦，於是決定先將它卸載，等未來這個專案更加成熟後再來挑戰。
這篇文章主要想跟大家分享我這一個禮拜的完整心路歷程，包含我的初始硬體設定、中間經歷了哪些優化與無情崩潰，以及最後我如何權衡利弊並思考自身真實需求後，決定徹底退出龍蝦的坑。
OpenClaw 龍蝦簡介
在這邊先對不熟悉龍蝦的朋友簡單介紹一下什麼是 OpenClaw。這是 2025 年底由 Peter Steinberger 發佈的一個 Github 開源專案，它的核心功能是讓你能透過一般的通訊軟體（例如 Telegram），遙控一個有機會完全免費、24 小時在線、且能完全掌控你電腦最高權限的專屬 AI 助理。不僅如此，這個 AI 還具備主動執行與長期記憶能力，能夠自己查資料、寫程式與執行各種複雜任務。
我的初始架構與部署方式
由於我一開始就主打「希望能免費或者先使用現有的訂閱方案」，因此在環境隔離方面，我在我的 M4 Mac Studio 裡面架設了 UTM 虛擬機，把龍蝦安裝在裡面，並且直接無腦開滿所有的系統權限。
至於模型（大腦）方面，因為我本來就有訂閱 ChatGPT，因此我最初使用 OpenAI ChatGPT OAuth (GPT-5.4) 作為我的主力，這也是目前大廠中 OAuth 相對比較安全的選項。但是，由於我本身也在使用 Codex 進行其他專案開發，因此我的每週使用額度很快就被耗盡。
為了省錢，我只好另謀出路，決定先從本地開源模型下手。反正我想說讓它跑得慢一點也沒關係，只要最終能完成任務就好。因為我本機的 RAM 只有 36GB，且我想要具備多模態的模型，所以我直接用 Ollama 裝了 Qwen3.5 35B，並且開放 Gateway 監控我的 UTM 來處理 OpenClaw 的請求。這個做法基本上直接榨乾了我所有的記憶體，硬碟也經常被迫當作虛擬記憶體來用 (Swap)，但我也認為參數量更低的模型難以完整理解指令並穩定完成任務，所以這就成了我最初的架構。不過在我安裝好之後，有個新的開源專案 omlx 就紅起來了，或許之後可以嘗試用它來部署本地模型，與 Mac 的適配度更好。
中間遭遇的大坑以及解決方式
因為我的美好想像是希望「人在外面也可以透過手機遙控 OpenClaw 隨時進行開發」，所以我非常看重我用的通訊軟體（目前是 Telegram）與 OpenClaw 之間的連線品質。但事與願違，系統基本上每天都在斷線，而且時好時壞，我經常找不到原因在哪。甚至我是到決定刪掉它的最後一天才恍然大悟：原來是我家裡的 Wi-Fi 會嚴重掉封包，只要換成手機熱點網路就稍微正常了。
當然，這只是冰山一角。這段期間我還踩了無數個技術深坑，以下整理出幾個最折磨人的狀況與我事後回想的對策：
| 遇到的狀況 | 發生的原因 | 修復與優化對策 or 未來優化方向 |
|---|---|---|
| Telegram 409 衝突 | 多個背景進程同時競爭同一個 Bot Token，導致 AI 出現「人格分裂」，互相搶佔網路頻寬造成當機。 | 必須手動執行深度清空，利用終端機指令 pkill -9 -f openclaw 徹底清除卡住的殭屍程式，並檢查 PM2 狀態後再重啟服務。 |
| Groq API http 413/429 錯誤 | 中後期我發現 Groq 有免費的 API Key 可用，於是改以 Llama3-70B 優先排程。但在對話沒多久後，Context Window 就超過了單次請求的硬性上限。 | 當記憶快滿時，系統預設是交給正在用的模型進行壓縮，這導致了死胡同。我試著呼叫其他模型來壓縮、拔除一些工具，最後甚至要把 workspace/ 裡面的各種 .md (如 MEMORY.md, AGENTS.md, SOUL.md 等) 直接全量壓縮，還是瘋狂報錯。這條路最後我只能放棄，之後會再研究其他人的使用方法。 |
| 長時間的任務會需要手動一直喚醒 AI 讓他繼續進行 | 有些長時任務執行到一半 AI 就會停止回覆，因為 LLM 推理是有長度與時間限制的，一旦超過 token 上限或推理時間限制，整個生成過程就會被中斷。 | 參考李宏毅老師的做法將 Cron job 的概念寫入 Memory.md 中，當 Agent 遇到需要背景執行的任務，請他自行建立定時任務，待時間到後由 Cron 自動喚醒並發送推播回報。 |
| Telegram 回覆嚴重延遲 | 經 ping 測試發現，我的主機雖然使用其他的網路功能都完全正常，但是連接到 Telegram API 的掉包率高達 95% | 雖然切成手機熱點可以暫時性的解決問題，但是由於手機不會一直放在家，所以我先試著用 Surfshark VPN 把虛擬機的網路直接掛到荷蘭阿姆斯特丹 (Telegram 總部所在地)，瞬間迎刃而解。 |
| 龍蝦把自己的大腦改壞，且 Antigravity 越改越壞 | 龍蝦在自己修改程式碼時，常會不小心把對外的 Gateway 關掉，或是把自己的設定檔 openclaw.json 改壞。為此，我用 SSH 連進主機請 Antigravity 幫忙修。 | 適逢 Google 大砍 AI Pro 的額度，我只剩下比較一般的 Gemini 3 Flash 可以用。也許是我的指令下得不夠好，它很常把情況越弄越糟，這幾乎無解。我覺得之後直接在虛擬機裡裝 Antigravity 或改用 Claude Code 比較有解，另外一定要設定 Cron job 定期備份設定檔。 |
| Google API 超級燒錢 | 我曾經試著綁定 Gemini 2.5 Flash 一陣子，但發現它常要跟我來回對話很久才能完成任務。衝動之下，我把模型升級成了 Gemini 3 Flash。 | 換了大腦後，效果跟反應速度確實大幅提升，但也極度燒錢。我大概只傳了 10 個訊息就燒了快 100 塊台幣，嚇得我馬上把它關掉。 |
除此之外，還有一點很重要的是：沒事千萬不要亂更新 OpenClaw 的版本，每次安裝新版後常常會有莫名其妙的 Bug 出現。
三個決定卸載的根本原因
老實說，我覺得只要肯花一點錢使用好一點的模型，以及在虛擬機裡面掛個 Claude Code，然後把龍蝦裝個類似 openclaw-min-bundle 這種 Skill，整個環境就可以穩定非常多。而 Telegram 掉封包的問題我真的是到最後才發現，如果早點發現或許可以免去很多挫折。但綜合以下種種原因，促成了我在多方評估後，決定還是暫時卸載龍蝦：
1. 穩定度落差：維護時間大於使用時間
自從安裝以後，我幾乎每天都需要花費數小時進行痛苦維修。作為一個提高生產力的工具，如果「修復工具的時間」大於「它幫我省下的產出時間」，便完全失去了追求自動化的高效初衷。
2. 對「全權限 AI」意義的重新反思
一開始架設這隻龍蝦 (OpenClaw)，核心訴求無非是：想要一隻 24 小時隨時在線、具備電腦最高執行權限、且能隨時用手機 Telegram 溝通並執行排程的助理。然而在一步步深思後，我發現我其實多數的需求只是「希望它能進行多個複雜的自動化任務（包含涉及多個應用程式與瀏覽器操作，且中間需要有 LLM 的涉入）」。要隨時隨地與它聊天或進行開發的需求反而沒有那麼多，保留龍蝦似乎只是一種「隨時有個 AI 盡在掌握」的滿足感跟安心感而已。
而針對這樣單純的自動化需求，現在只要善用 Claude Code 推出的 Remote Control 或是 Claude cowork dispatch 模組搭配它的 Scheduler，或是直接使用 Codex CLI 設定排程任務，就足以完美解決多數困擾，真的不需要為了用龍蝦而用龍蝦。
3. 學習效益的邊際遞減
不可否認，在與 OpenClaw 搏鬥的過程中，我被迫學到了許多關於 VM 虛擬機網路橋接、系統守護進程 (Daemon)、以及 LLM context compaction 的底層知識。但走到某個節點後，繼續深挖這類特定框架的除錯工作，對於我想專注於「學習更多現代 AI 理論與核心知識」以及練習利用 AI 進行開發的長期目標來說，邊際效應實在太低了。及時停損，把時間投資在更高價值的事物上，才是明智之舉。
結語
我認為 OpenClaw 真的是非常有潛力的一項產品。即便在它現在還那麼不成熟的情況下，世界上依然有非常多神人能將其發揮得淋漓盡致。然而對我這種沒有深厚技術背景、也沒有多餘荷包可以使用昂貴好模型的玩家來說，我認為可以試著體驗看看，但絕對不要一開始就奢求它能輕易做到網路上那些神人展示的魔法。
這個禮拜的歷程也讓我看到了許多後續未來可以努力精進的方向。希望在不久的將來，等我準備好後，我就會再度踏入龍蝦的世界！如果有任何內容有誤需要改正，或是想要與我分享您的龍蝦使用心得或技巧都歡迎留言或是聯繫我！
常見問答 (Q&A)
Q1: 在 36GB 記憶體的電腦上硬跑 35B 的大模型，對系統有什麼影響？
因為模型參數量太大，記憶體會瞬間被吃滿全空，導致電腦頻繁調用硬碟空間當作擴充區域。這不僅會讓 AI 的反應速度慢到無法忍受，也極度損耗硬體效能。因此，不建議硬體有限但想要多模態能力的玩家硬跑本地模型。
Q2: 如果不需要 24 小時待命的本地 AI，有什麼更穩定的排程自動化方案？
可以利用 Claude Code 內建的 Remote Control 與 Claude cowork dispatch 功能，再搭配原生的 Scheduler 來建立常規自動化；或是直接學習使用 Codex CLI 也可以達成。這些工具不需要你除錯不穩定的區域網路，也不用擔心 Telegram 掉封包的問題。
Q3: 如果 AI 在自主寫程式時改壞自己的設定檔，最好的防護網是什麼？
我認為定期備份應該可以解決的大部分的問題，例如可以寫一個輕量腳本或設定系統排程器 (Cron job)，要求系統定期保存重要的 openclaw.json。這樣即使其他 AI 在嘗試修補時把系統越修越壞，依然可以輕鬆抓取備份檔，一鍵還原回正常的狀態。