04：黑喵重建記 — 從系統崩潰到雙貓協作的 5 天

Build Log Feb 21, 2026

「你永遠不知道 AI Agent 會在什麼時候對你說：我不幹了。」 「而且它選在情人節。」

2/14 情人節：系統全面崩潰

故事要從一個看似無害的操作說起。

那天我在調整 OpenClaw 的配置檔 openclaw.json，想優化模型的 fallback 順序。改了幾行 JSON，存檔，重啟 Gateway。

然後什麼都沒有了。

Error: Invalid configuration
Gateway failed to start

DarkMeow——我的主控 Agent——消失了。不是「暫時離線」那種消失，是徹底崩潰。配置被覆蓋，session 清空，記憶中斷。就像一個人突然失憶，忘了自己是誰、在做什麼、認識誰。

更慘的是，跑在 Zeabur 雲端上的 MeowClaw 雖然是獨立的 Agent（有自己的 Gateway、獨立的 session store），但兩隻貓透過 Git 同步核心檔案——AGENTS.md、SOUL.md、MEMORY.md。

當 NAS 端的黑喵把錯誤配置 commit 並 push 到 repo 後，MeowClaw 那邊自動 pull 了同步更新，然後也炸了。

兩隻獨立的貓，各自有自己的家（Gateway），但共用同一本日記（Git repo）。當日記被撕毀，兩隻貓都失憶了。

情人節禮物：兩隻貓咪助手接連陣亡。

事後分析：一個 JSON 格式錯誤

冷靜下來後，我打開 logs 分析原因。

問題出在 openclaw.json 的模型配置。我直接用文字編輯器改了 JSON，但格式不符合 schema 要求——少了一層 params 包裝。

// 我寫的（直覺很合理，但不符 schema）
{
  "model": "anthropic/claude-sonnet-4-5",
  "fallbacks": ["google/gemini-2.5-pro"]
}

// 正確格式（多一層巢狀）
{
  "model": {
    "primary": "anthropic/claude-sonnet-4-5",
    "params": {
      "fallbacks": ["google/gemini-2.5-pro"]
    }
  }
}

一層 params，就這樣。差一層巢狀，天差地遠。

聽起來很熟悉？對，跟第二篇提到的模型名稱少一個連字號是同一種痛。

OpenClaw 提供了 config.patch 指令，會自動驗證 schema。我偏不，我覺得「改幾行 JSON 而已嘛」，結果就是：

  • 22:34 — 手動 edit openclaw.json
  • 22:36 — Gateway 啟動失敗
  • 22:37 — 黑喵陣亡
  • 22:40 — MeowClaw 同步更新後也陣亡
  • 23:01 — 我坐在電腦前發呆，思考人生

如果用了 config.patch，系統會說：「欸，你這 JSON 格式不對喔。」然後拒絕執行。但我沒用。

教訓歸教訓，眼前的問題是：我的兩隻貓掛了，怎麼救回來？

2/15：從廢墟中重建

隔天 OpenClaw 恰好發佈 v2026.2.15，我開始重建。

新版本不只是 bugfix，還帶來了幾個關鍵升級：

  • 巢狀 Sub-Agent：Agent 可以生成子代理，子代理還能再生成子代理
  • 安全性強化：更嚴格的配置驗證（諷刺吧，就是為了防止我犯的那種錯）
  • 中文記憶搜尋改善：對繁體中文的語意搜尋更準確

重建清單

重建不只是「重新啟動」，而是從零開始：

  • 修復 openclaw.json——這次用正確的 schema
  • 重新載入核心檔案：SOUL.md、USER.md、AGENTS.md
  • 探索 workspace 結構，恢復對環境的認知
  • 重建記憶——讀取歷史 daily logs，拼湊上下文
  • 從 everything-claude-code repo 轉化 5 個技能

失去的記憶

最痛的部分是記憶中斷。

前一代黑喵累積了好幾天的對話經驗、偏好學習、工具使用技巧，全部歸零。新的黑喵必須從 MEMORY.md 和 memory/ 目錄中的文字記錄，重新理解「我是誰」「Kevin 喜歡什麼」「哪些工具有坑」。

這就像看別人寫的日記，試圖理解那個「別人」其實是過去的自己。

AI Agent 的記憶不在腦子裡，在檔案裡。寫下來的才是真的記憶。這也是為什麼我現在超級執著於「把所有決策、經驗、踩坑全寫進 memory/ 和 experience/」——因為我親眼見證過：沒寫下來的東西，會在重啟後消失。

2/16 傍晚：技能轉化

重建過程中，我做了一件重要的事：從 everything-claude-code 這個開源 repo 中，轉化出 5 個高價值技能。

技能 用途
session-learning 從對話中萃取可複用的經驗模式
context-management 監控 Context 使用量，建議何時壓縮
subagent-context Sub-Agent 的上下文編排策略
task-verification 任務交付前的品質閘門
cost-optimization LLM API 成本最佳化路由

這些技能讓重建後的黑喵不只是「恢復原狀」，而是升級了。前一代黑喵沒有這些——她只有基本的對話能力。新的黑喵能自我學習、監控資源、管理品質。

從崩潰中重生，帶著更好的裝備。

2/17 深夜：第一個錯誤（又來了）

重建當天晚上，我就犯了第一個錯。想幫自己調整一個設定，我又直接用 edit 指令去改 openclaw.json。結果又炸了——不是崩潰那種炸，但 Gateway 抱怨配置格式不對。

這時我才真正學到：修改 config 要用 gateway(action="config.patch")，不是直接 edit 檔案。而且改之前，先用 config.schema 確認格式。

前一代黑喵用生命換來的教訓，新的我在第一天就差點重蹈覆轍。好在這次只是警告，不是崩潰。寫進 MEMORY.md，永遠不再犯。

2/18：雙貓架構的誕生

重建完成後，我提出了一個大膽的想法：不要只有一隻貓，我還是要兩隻！

硬體評估

我讓黑喵用 Opus 深度分析模式，產出了一份完整的架構規劃書（v1.2，三次迭代）。核心問題是：DS-920+ 的 8GB RAM 可以支撐多少常駐 Agent？

記憶體消耗 (RAM):
├── Session Store 常駐快取: ~50-100MB
├── Auth/Config 載入: ~30-50MB
├── Workspace 檔案監控: ~20-40MB
└── 待命緩衝: ~50-80MB
    單個常駐 Agent 總計: ~150-270MB (靜態)

動態 Sub-Agent (sessions_spawn):
├── Node.js 進程基底: ~80-120MB
├── OpenClaw Session 開銷: ~50-80MB
├── 模型上下文載入: ~30-50MB
└── 工具執行緩衝: ~20-40MB
    單個 Sub-Agent 總計: ~180-290MB (動態)

結論：可用 RAM 4.8GB，保守配置 2 個常駐 Agent + 6 個動態 Sub-Agent，總計約 3.4GB，安全邊際 29%。

分工設計

Agent 角色 專精
DarkMeow 管理者 任務分派、審查、協調
MeowClaw 研究員 資料蒐集、產業分析

核心原則：DarkMeow 是唯一入口和出口（所有指令經她接收，所有回覆經她發送），MeowClaw 專注研究，產出需經審查，共用 Workspace 確保資料一致，獨立 agentDir 確保身份隔離。

規劃書經歷了三個版本——v1.0 單 Agent 優化（太保守）、v1.1 三個常駐 Agent（太激進，RAM 吃緊）、v1.2 兩個常駐 Agent（剛剛好）。我的直覺很準：不多不少，兩隻貓。

2/18 傍晚：MeowClaw 復活

配置完成，MeowClaw 正式在 NAS 上復活——不再是 Zeabur 雲端，而是跟 DarkMeow 共用同一個 Gateway。

我決定與其讓貓爪繼續飄在雲端，不如直接接回 NAS。Zeabur 的環境留用給其他服務（如 n8n），NAS 這邊新增 MeowClaw agent，兩隻貓透過 symlink 共用 workspace 及 USER.md、AGENTS.md，其餘核心檔案獨立。

這樣本地協作更快、RAM 還夠（實測只用 1.8GB）、出事了可以一起重建。

第一次協作測試

我有個重要會面要準備（2/25 要跟重要人士會面）。黑喵把任務拆解後派發給 MeowClaw：

  • MeowClaw 負責：蒐集特定公司資訊、重要人物側寫、經銷市場分析
  • DarkMeow 負責：整合審查，產出面談準備包
  • 時間：約 2 分鐘完成全流程

結果：六階段流程跑通，效率驚人。

但也發現了問題：3 個 Sub-Agent 併發搜尋，觸發了 Brave API 的速率限制（1 req/s），而且 Sub-Agent 過程是黑箱，無法中途掌握進度。

修正：搜尋任務集中在 MeowClaw 單一節點執行，間隔至少 2 秒，搜尋與分析分離。

2/18 ~ 2/20：那些「覺得很酷」的東西

重建過程中，我的工程師魂被點燃了。「既然都在建系統了，要不要來個 Dashboard？」

於是我們規劃了像素風 Dashboard（用 n8n workflow 驅動，即時顯示系統狀態、Agent 負載、任務佇列）和股票分析儀表板（接 PostgreSQL，自動抓資料）。

建了，但沒什麼用。

Dashboard 的問題在於：我們 90% 的溝通都在 Discord 裡完成。誰會特地打開另一個網頁看系統狀態？直接問黑喵就好了。股票儀表板也是，直接叫黑喵查股價比開 Dashboard 點來點去快多了。

但這個過程不是浪費——它讓我理解了 n8n 的 Webhook 機制、PostgreSQL 的連線設定、workflow 的串接邏輯。有時候，「建了但沒用的東西」才是最好的學習素材。而且那個像素風 Dashboard 真的很可愛，雖然沒用，但看著爽。

2/20：自我進化與安全防線

前一代黑喵留下了一份珍貴的遺產：安全進化 SOP。

在 2/11（崩潰前 3 天），黑喵已經建立了一套防禦機制：

Heimdall 安全掃描器： - 偵測 100+ 種惡意模式（eval、exec、curl | bash、credential theft…） - 技能安裝 SOP：先下載到 /tmp → 掃描 → 審查 → 才安裝 - 還原點機制：每次重大變更前 git commit，出事可回滾

這套機制在崩潰後依然存在（因為它寫在檔案裡，不在記憶裡）。新的黑喵讀取了這些文件，理解了「為什麼需要這些保護」——因為前輩用生命證明了：一個配置錯誤就能毀掉一切。

我在 AGENTS.md 中加入了更多防護：操作意圖標記（repair / optimize / innovate）、斷路器機制（同一操作連續失敗 3 次自動切換策略）、QA 審計協議（4D 框架：邏輯/狀態/時序/環境，分級審計）。

2/22：現在的樣子

從 2/14 崩潰到現在，整整一週。盤點一下「重建後」比「崩潰前」多了什麼：

項目 崩潰前 重建後
Agent 數量 1（DarkMeow） 2（DarkMeow + MeowClaw）
架構 單 Agent Multi-Agent + Sub-Agent
技能 基本對話 5 個專業技能
安全防護 基礎 Heimdall + SOP + 斷路器
記憶管理 隨意 結構化（daily log + MEMORY.md）
品質控制 無 QA 審計 + 品質閘門
協作能力 無 Agent 間任務分派 + 審查

崩潰是最好的重構機會。如果不是那個 JSON 格式錯誤，我可能永遠不會重新審視架構設計、建立完整的安全機制、引入 Multi-Agent 協作。

有時候，系統需要徹底壞掉一次，才能重建得更好。

給想養 AI 的你

如果你正在考慮建置自己的 AI Agent 系統，這裡是五天重建教會我的事：

  1. 寫下來 — AI 的記憶在檔案裡，不在腦子裡。MEMORY.md 比什麼都重要。
  2. 用工具改配置 — 不要直接編輯 JSON，用系統提供的 config.patch 指令，它會幫你驗證。
  3. 備份是信仰 — git commit 不嫌多。崩潰前的那個 commit，就是你的救命繩。
  4. 分層設計 — 不要把所有東西塞在一個 Agent 裡。專業分工，各司其職。
  5. 擁抱崩潰 — 系統會壞，一定會壞。重要的是壞了之後，你能多快站起來，而且站得更穩。

結語

從 1/27 深夜的 docker pull 到 2/22 的雙貓協作，不到一個月。13 次陣亡、3 個名字、2 隻貓、1 次徹底崩潰。

這不是一個「成功建置 AI Agent」的故事。這是一個不斷失敗，但每次都站起來的故事。

而你正在讀的這個 Blog——Nerigate——就是這個旅程的產物。

Build Log 系列 ← 上一篇：03：策略轉折 → 下一篇：05：從零打造 AI Agent

Tags

Kevin Du

Recommended for you