03：從陣亡循環到雲地協作 — 策略轉折

「最好的架構不是選擇 A 或 B，而是找到 A+B 的最佳組合。」

上一篇提到，我在 Synology DS920+ 上經歷了 9 次容器陣亡。

此時我面臨三個選擇：

1. 繼續硬剛：花更多時間解決 Docker 權限、瀏覽器沙盒、HTTPS 憑證
2. 直接放棄：買一台 Mac Mini M4，用官方推薦的方式跑
3. 換個思路：也許不需要「純本地」或「純雲端」，而是兩者都要

我選了第三條路。這個決定，後來成為整個系統架構的核心思想。

2/4 早晨：Zeabur 的曙光

在 GitHub 上翻 OpenClaw 的 Issues 時，我看到有人提到：

“Deployed on Zeabur in 5 minutes. Works perfectly.”

「5 分鐘？」

點開 Zeabur 的官網，發現它提供了 OpenClaw 的一鍵部署模板。不需要手動設定 Docker Compose、處理瀏覽器依賴、設定 HTTPS 憑證、Port Forwarding。只要 Fork 官方 Repo、點擊 Deploy to Zeabur、填入 Anthropic API Key、等 3 分鐘。

我試了。真的這麼簡單。

5 分鐘後：MeowClaw 誕生

部署完成，Zeabur 給了我一個網址：

https://meowclaw-xxxx.zeabur.app

打開，看到 OpenClaw 的 WebUI，狀態顯示：

✓ Gateway running
✓ Browser available
✓ Ready to pair

我在本機執行：

openclaw pairing approve web ABC-123

WebUI 立刻顯示：

✓ Connected
Agent: MeowClaw
Model: claude-3-5-sonnet

這就是我在 NAS 上奮鬥 27 小時想達成的狀態。而在 Zeabur 上，只花了 5 分鐘。

「那我的 NAS 白費了？」

看著成功運作的 MeowClaw，我心裡有點複雜。難道在 NAS 上陣亡 9 次的那 27 小時，全部白費了？

冷靜下來想想，其實不是。那 27 小時讓我理解了 OpenClaw 的底層運作原理——Docker entrypoint 的設定邏輯、權限問題的本質、瀏覽器沙盒的依賴需求、Gateway 的 pairing 機制。如果沒有這些踩坑經驗，我根本不知道 Zeabur 幫我解決了什麼問題。

更重要的是，這些知識讓我開始思考：Zeabur 很方便，但我真的要把所有運算都放在雲端嗎？

重新思考：為什麼要本地部署？

我最初選擇在 NAS 上部署 OpenClaw，是因為隱私、成本、控制權，以及本地檔案存取。這些理由在 Zeabur 成功部署後依然成立。

特別是本地檔案存取——NAS 上有多年的文件資料、專案程式碼、備份檔案、各種工作紀錄。如果 AI Agent 完全跑在雲端，它要怎麼讀取這些本地檔案？

策略轉折：雲地協作架構

此時我有了一個想法：為什麼一定要選「純本地」或「純雲端」？如果兩個都部署呢？

地端（NAS）的強項： - 本地檔案存取 - 隱私資料處理 - 深度分析任務 - 長時間運算

雲端（Zeabur）的強項： - 穩定的網路連線與 HTTPS 支援 - Webhook 接收（Telegram, Discord） - Web Search、API 呼叫 - 輕量級快速回應

兩者透過 API 或共享資料庫協作。這就是「雲地協作」架構的雛形。

命名：DarkMeow 與 MeowClaw

既然要部署兩個 Agent，就需要命名。MeowClaw 已經在 Zeabur 上跑起來了，NAS 上的新 Agent 需要一個名字。

我想到「Dark」這個字。不是因為邪惡，而是因為它在「暗處」運作（本地網路，不對外開放）、處理「黑箱」任務（深度分析、隱私資料）、跟 MeowClaw 的「Claw」對稱。另外，實際上轉頭看看那台 NAS——嗯，黑色的。

於是 DarkMeow 誕生了。

分工設計：各司其職

有了兩隻貓，就需要明確分工。

MeowClaw（Zeabur）負責： - Web Search（需要穩定外網） - 接收 Telegram/Discord Webhook - 呼叫外部 API（天氣、新聞、股票） - n8n 自動化整合 - 輕量級任務（快速回應）

DarkMeow（NAS）負責： - 讀取本地檔案 - 深度數據分析 - 長時間運算任務 - 隱私資料處理 - 備份與歸檔

核心原則：雲端強連接，地端強算力。

溝通方案：Git + Notion 混合架構

兩個 Agent 各自運作，但要協作就需要共享資訊。我考慮了三個方案：

1. Shared Database（PostgreSQL/MongoDB 當中間層）：需要處理 concurrency 和 locking
2. Message Queue（RabbitMQ/Redis）：需要額外部署一個服務，複雜度提升
3. Git + Notion 混合架構：即時層用 Notion（任務佇列、執行日誌）、持久層用 Git（人格檔案、技能版本控制）、本地層各自維護 MEMORY.md

我選了方案 3。不需要額外部署資料庫、Notion 有 API 兩邊都能存取、Git 提供版本控制避免資料丟失、各自維護 MEMORY.md 減少衝突。

Zeabur 的真實成本

雖然 Zeabur 部署很方便，但得算一下成本。

Zeabur Developer Plan $5/月，OpenClaw 因為要跑瀏覽器大概需要 512MB-1GB RAM，運算資源約 $3-5。總計每月 $8-10（後來實際上我把 VPS 開到了 $20/月）。

對比之下，Mac Mini M4 一次性 $599，NAS 電費約 $3/月（本來就在跑，邊際成本低）。結論是純雲端方案長期成本較高，混合架構初期投資高但長期划算。

不過 Zeabur 帶來的穩定性、HTTPS、自動擴展、免維護，這些都是值得付費的。更重要的是，這個架構讓我可以保留 NAS 的本地運算優勢，同時享受雲端的便利性。

這不是妥協，是最佳化。

2/4 傍晚：第一次協作測試

部署完成後，我做了一個簡單的測試——搜尋最新的 AI 新聞，並儲存到 NAS 的知識庫。

1. 我在 Telegram 傳訊息給 MeowClaw：「幫我搜尋最新的 OpenAI 新聞」
2. MeowClaw（Zeabur）執行 Web Search，取得結果
3. MeowClaw 將結果傳到 Notion Database
4. DarkMeow（NAS）定期檢查 Notion，發現新任務
5. DarkMeow 將新聞內容整理成 Markdown，存到本地 knowledge-base/
6. DarkMeow 更新 Notion 狀態：「已完成」

全程自動，無需人工介入。這就是雲地協作的第一次成功實踐。

教訓：架構思維勝過技術執行

這次從 NAS 到 Zeabur 的轉折，最大的收穫不是技術，而是思維方式的轉變。

技術思維是：「我要在 NAS 上跑 OpenClaw，所以要解決 Docker、權限、瀏覽器……」

架構思維是：「我要一個能用的 AI Agent，它需要哪些能力？這些能力最適合在哪裡執行？」

從「工具導向」到「需求導向」，從「單點解決」到「系統設計」。這個轉變，是 9 次陣亡後才領悟到的。

Build Log 系列 ← 上一篇：02：NAS 陣亡循環 → 下一篇：04：黑喵重建記