WhatsApp 是對話發生的地方。不是 Slack、不是 Discord、不是 Telegram——對世界上大多數人來說，WhatsApp 就是預設選項。每月 20 億活躍使用者，在歐洲、拉丁美洲、南亞和非洲佔主導地位。如果你想要一個真正融入日常生活的 AI 助理，它就必須在你日常對話已經發生的地方。
問題是 WhatsApp 沒有提供給個人的 bot API。WhatsApp Business API 存在，但它需要商業帳號、Meta 的審核，以及一個為客服設計的按訊息收費結構，不是為個人助理設計的。對於一個想在自己的 WhatsApp 中擁有個人 AI bot 的開發者來說——一個能在群組聊天中回應、記住上下文、在自己的硬體上運行的——官方途徑是死路一條。
NanoClaw 用 Baileys 解決了這個問題。Baileys 是一個開源的 WhatsApp Web 函式庫，它以與 WhatsApp Web 客戶端相同的方式連接到 WhatsApp 的伺服器。你掃描一個 QR code，連線就建立了，NanoClaw 就能以你的 WhatsApp 帳號收發訊息。不需要 Business API、不需要 Meta 審核、不需要按訊息付費。
架構：為什麼 WhatsApp 很特別
NanoClaw 的 WhatsApp 整合不只是一個訊息橋接——它是整個架構圍繞設計的主要頻道。雖然其他頻道（Telegram、Discord、Slack）是透過 Claude Code skill 添加的，WhatsApp 是內建在核心中的。這不是偏心；這反映了 WhatsApp 的群組模型如何自然地對應到 NanoClaw 的安全模型。
WhatsApp 群組就是隔離邊界。每個群組都有自己的容器、自己的 CLAUDE.md 記憶檔和自己的可寫工作區。當有人在家庭群組中發送訊息時，回應的 agent 只能存取該群組的歷史和記憶。它看不到你工作群組的訊息、無法存取你的私人聊天記錄，也讀不到屬於其他群組的檔案。隔離是由容器掛載強制執行的，而不是由應用程式邏輯。
這種按群組隔離正是讓 NanoClaw 在人們實際使用 WhatsApp 的方式下保持安全的關鍵。你的家庭群組討論私人事務。你的工作群組討論機密專案。你的朋友群組分享不會公開分享的東西。這些上下文中的每一個都需要是分開的，而 NanoClaw 確保它們是——不是透過可能有 bug 的存取控制清單，而是透過無法被應用層漏洞繞過的物理容器分離。
設定方式
設定過程大約十分鐘，大部分時間是在等 npm install。
複製程式碼庫並安裝依賴：
```bash git clone https://github.com/qwibitai/NanoClaw.git cd NanoClaw npm install ```
設定你的環境。最低限度的設定只需要一個 Anthropic API key：
```bash echo 'ANTHROPIC_API_KEY=sk-ant-your-key-here' > .env ``` 執行 WhatsApp 配對：
```bash npm run auth ```
這會在你的終端機中顯示一個 QR code。打開手機上的 WhatsApp，前往「已連結的裝置」，掃描 QR code。連線就建立了，NanoClaw 現在正在監聽訊息。
啟動 agent：
```bash npm start ```
就這樣。在任何你想讓 bot 活躍的 WhatsApp 群組中發送訊息，提及助理的名字（可透過 .env 中的 ASSISTANT_NAME 設定），它就會回應。第一次回應需要幾秒鐘，因為容器正在啟動；同一個 session 中的後續訊息會更快，因為容器保持在暖機狀態。
訊息如何流動
理解訊息流程有助於解釋為什麼 NanoClaw 在有容器開銷的情況下仍然感覺反應靈敏。當 WhatsApp 上收到一條訊息時，主機程序——NanoClaw 約 500 行的 TypeScript 核心——透過 Baileys 接收它。它檢查訊息是否是發給助理的（透過名字提及或私訊）。如果是，主機查詢該群組的容器狀態。
如果該群組已經有一個容器在運行（來自最近的對話），訊息就透過 IPC 路由到它。容器內的 agent 接收訊息、用 Claude Agent SDK 處理它，然後透過 IPC 把回應送回。主機把回應轉發到 WhatsApp。總共增加的延遲：IPC 幾毫秒，加上 Claude API 回應所需的時間。
如果沒有容器在運行，主機就啟動一個。在 macOS 上用 Apple Container 大約需要 200-400 毫秒。在 Linux 上用 Docker 需要 1-2 秒。容器接收群組的 CLAUDE.md 記憶檔、來自 SQLite 的對話歷史，以及透過 stdin 傳入的 API key。它處理訊息並回應。容器會保持存活一段可設定的逾時時間（預設：30 分鐘），以處理後續訊息而不需要啟動開銷。
結果是大多數訊息——那些在活躍對話中的——感覺是即時的。AI 回應時間主要取決於 Claude 的 API 延遲，而不是 NanoClaw 的基礎設施。只有長時間沉默後的第一條訊息才有容器啟動的開銷，而即使那樣也快到使用者很少注意到。
按群組記憶：讓它真正好用的功能
按群組的 CLAUDE.md 檔案是把一個無狀態的聊天機器人變成真正有用的助理的關鍵。每個群組的記憶檔隨著時間累積上下文——偏好、進行中的專案、反覆出現的話題、內部笑話。Agent 在每次對話回合開始時讀取這個檔案，這意味著它記得你上週告訴它的事，不需要你重複。
在家庭群組中，記憶可能記錄飲食偏好、學校行程和定期活動。在工作群組中，它可能追蹤專案截止日期、團隊偏好和技術決策。在朋友群組中，它可能記住旅行計畫、餐廳推薦和共同興趣。
記憶是可編輯的。你可以要求 agent 記住特定的事（「記住媽媽對貝類過敏」）或忘記某些事（「忘掉我說的關於驚喜派對的事」）。你也可以直接編輯 CLAUDE.md 檔案——它是你檔案系統上的純文字檔，不是鎖在資料庫裡的。 ## 隱私的現實面
運行 WhatsApp AI bot 會引發合理的隱私問題，值得直說。NanoClaw 處理的訊息會被送到 Anthropic 的 API 讓 Claude 生成回應。這意味著你的 WhatsApp 訊息——至少是那些發給助理的——會離開你的裝置並由 Anthropic 的伺服器處理。
NanoClaw 透過幾種方式來緩解這個問題。只有明確發給助理的訊息才會被送到 API——bot 不會處理或儲存不是針對它的訊息。儲存在 SQLite 中的對話歷史留在你的機器上。CLAUDE.md 記憶檔留在你的機器上。而如果你設定 NanoClaw 使用 Ollama 而不是 Anthropic，AI 處理也在本地進行——什麼都不會離開你的網路。
對大多數使用者來說，實際的隱私狀態是：你的 WhatsApp 訊息留在你的裝置上，除非你明確向 AI 助理提問，此時那條特定訊息會被送到 Anthropic（或用 Ollama 在本地處理）。這比那些處理和儲存你輸入的所有內容的雲端 AI 服務，在隱私方面好得多。
WhatsApp 是你生活發生的地方。NanoClaw 把一個 AI 助理放在那裡——帶著隔離、記憶和隱私模型，讓它在你討論真正重要事情的群組中也能安全使用。