OpenClaw CN IM Docker 鏡像：預載飛書釘釘企微的 AI 機器人網關

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

在 Docker Hub 上累積超過 22 萬次 pulls 的 justlikemaki/openclaw-docker-cn-im，把 OpenClaw 這套 AI 助理框架與飛書、釘釘、企業微信、QQ 機器人的介接預先打包進同一個容器，主打一行 docker compose up -d 就能把對接中國大陸主流 IM 的 AI 機器人網關架起來。它的價值與限制都來自同一件事：這是一個由第三方個人開發者維護、針對中國大陸市場所做的整合鏡像，不是 OpenClaw 官方出品，也不是為台灣本地 IM 使用習慣設計。這篇會把 docker-compose.yml 與 .env.example 翻開來看，順著部署流程拆解它的設計選擇與預設值暗礁。

如果你是「要對接中國大陸業務、團隊內部同時用飛書釘釘企微」的開發者，這個鏡像確實能省下大量配介面卡（adapter）的力氣。如果你只是想在台灣內部用 LINE 或 Slack 接 AI 機器人，它不會比 OpenClaw 官方搭配的第三方一鍵安裝腳本更適合，因為你會拖一整包根本用不到的 IM 介面卡進容器。

Pin

從 docker pull 到 docker compose up，部署流程拆解

這個鏡像的部署流程在 README 寫得相當簡短，照官方文件走是四個指令：下載 docker-compose.yml 與 .env.example、把範本複製成 .env、填入 LLM 的 MODEL_ID、BASE_URL、API_KEY，然後 docker compose up -d。容器跑起來後，閘道（Gateway）會在 18789 埠、Bridge 在 18790 埠，預設監聽 0.0.0.0 全部網卡。IM 介接的憑證可以晚點再補，先把 AI 服務跑起來、確認會回應，再去飛書開放平台或釘釘開發者後台申請機器人。

實際下載 docker-compose.yml 與 .env.example 來看，會發現 README 的「四個指令」遮掉了很多設計細節。docker-compose.yml 的 x-openclaw-common-env anchor 一次展開了大約兩百個環境變數鍵，覆蓋六個 LLM provider 槽位（MODEL_ID 到 MODEL6_MAX_TOKENS，可以同時接多家 API）、四個 IM 平台（飛書、釘釘、QQ Bot、企業微信）個別的單帳號與多帳號 JSON 構型、以及通用訊息策略（DM_POLICY、GROUP_POLICY、ALLOW_FROM）。時區被釘在 TZ: Asia/Shanghai，容器內的工作目錄是 /home/node，這兩個值都在 anchor 裡寫死，要改得動 compose 檔案。

真正影響行為的是 .env.example 裡的預設值。DOCKER_BIND=0.0.0.0 代表閘道一啟動就暴露在所有網路介面，若 VPS 沒有防火牆，等於直接把 AI 機器人控制端開放給整個網際網路；DM_POLICY=open、GROUP_POLICY=open、ALLOW_FROM=* 三個一組，意思是「任何私訊、任何群組、任何來源都接受訊息」，預設全開放，這在企業內部測試方便，但對外公開就是反垃圾訊息紅線。AGENT_REACH_USE_CN_MIRROR=true 預設啟用中國大陸的 GitHub proxy 與 pip 鏡像，這對身在大陸防火牆內的部署者友善，但對台灣或海外使用者來說等於把相依套件下載路徑繞進第三方鏡像源，是個供應鏈信任的抉擇。

鏡像到底預載了什麼：從 docker-compose 看設計選擇

Pin

翻 .env.example 與 Docker Hub 的 README，這個鏡像實際預載的東西可以分三層來看。最底層是 OpenClaw core 本身，也就是 openclaw/openclaw 這個上游框架（截至 2026-07 已累積 38 萬 stars，但授權是 NOASSERTION，並不是一般認知的那種「完整開源」）；鏡像會把 core 版本釘到目前最新的 2026.5.19（見 issue #211），上游一升級，作者就會跟著發新鏡像。

中間層是 IM 平台介面卡，覆蓋飛書（Feishu / Lark）、釘釘（DingTalk）、QQ 機器人、企業微信（WeCom）四個中國大陸主流通道，加上獨立環境變數區塊的 Telegram（這個反而是國際通用的）。飛書支援多帳號 JSON 構型（FEISHU_ACCOUNTS_JSON）、群組規則 JSON（FEISHU_GROUPS_JSON），可以用一個容器同時掛好幾個機器人；釘釘用 Stream 模式、不需要公網回呼 IP；QQ Bot 與企業微信各自有獨立的 env 區塊。FEISHU_OFFICIAL_PLUGIN_ENABLED=false 這個預設值值得記一下：它用的是非官方整合路徑，與飛書開放平台建議的官方事件訂閱方式不完全一致，好處是不用走嚴格的回呼 IP 白名單，代價是平台政策改變時可能跟不上。

最上層是工具鏈：內建 OpenCode AI（AI 程式碼助手）、Playwright（瀏覽器自動化，可以讓機器人操作網頁與截圖）、中文 TTS（語音合成）。這三個附加工具讓 AI 機器人不只是問答，還能夠「幫你看網頁、產生語音訊息」，但也把容器的體積與攻擊面推大不少。配備 Playwright 的容器跑起來，資源佔用比單純的 Node.js 服務高一截，這在規劃 VPS 規格時要先算進去。

第三方而非官方：justlikemaki 是誰

這個鏡像的維護者是 Docker Hub 上的 justlikemaki，對應 GitHub 帳號是 justlovemaki（兩個帳號名只差一個字母，同時出現在 README 連結裡，是這類個人專案常見的命名不一致）。GitHub 上的 justlikemaki/openclaw-china-docker（前身為 justlovemaki/OpenClaw-Docker-CN-IM）累積 3,756 stars / 454 forks / 12 個 open issues，採用 GPL-3.0 授權，這是這個鏡像 repo 本身的授權，與上游 OpenClaw core 的 NOASSERTION 是兩回事，商用整合時需要分開看 copyleft 義務。

把它放回 OpenClaw 生態地圖：官方的 openclaw/openclaw 是 core，第三方周邊還有 miaoxworld 的 Shell 一鍵安裝腳本、ClawX 桌面 GUI、MimiClaw 的 ESP32 硬體版本，以及本篇這個 justlikemaki 的中國 IM 整合 Docker 鏡像。每個都是不同的部署切入點，互相沒有從屬關係，更不是官方認證；選哪一個，取決於你的部署環境與目標 IM。

社群活躍度方面，這個鏡像確實還活著。從 issue 軌跡看，2026-04 到 2026-05 之間作者連續發布了 #209（同步 openclaw 2026.4.9 → 2026.5.5）與 #211（同步至 2026.5.19）多次更新，社群也有人催更（#208「老闆 還更新嗎 等好久了」）。但第三方個人專案的維護承諾永遠是「作者意願制」，他停更那一天，鏡像就停在那一刻的 core 版本，不會有人接手繼續同步上游安全修補。對長期生產環境來說，這是必須寫進採購評估的風險。

飛書釘釘企微的台灣現實：跨境團隊才用得上

這個鏡像最該被誠實說明的限制是：它預載的四個 IM 介面卡，沒有一個是台灣本地主流選擇。飛書在台灣只有「跟中國大陸客戶往來的業務團隊」或「總部在中國大陸的跨國分公司」會用；釘釘與企業微信更是中國大陸內部企業管理工具，台灣本地公司多半用 LINE、Slack、Discord、Teams；QQ 已經是相對小眾的消費級聊天軟體。換句話說，這個鏡像的目標讀者非常明確：「你的服務要賣給、或服務給中國大陸的使用者，而且那邊的客戶不用 Telegram 或 Slack」。

如果你是在台灣本地的 SaaS 團隊，想把 AI 助理接進內部溝通，這個鏡像不會比通用方案更划算。它假設的情境是「員工天天用飛書釘釘企微」，這個假設在台灣不成立。把這個鏡像拉回台灣內部用，你等於拖著四個用不到的 IM 介面卡與一整套中國大陸鏡像源設定，反向增加維運負擔。除非你公司就是台商、跨境電商、或服務中國大陸客戶的代營運團隊，這個鏡像的價值才會兌現。

另一個附帶但重要的觀察：AGENT_REACH_TWITTER_COOKIES、AGENT_REACH_XHS_COOKIES（小紅書）、AGENT_REACH_GROQ_KEY 這幾個 env 鍵的存在，說明這個鏡像預設的使用情境是「給要爬取與監控中國大陸社交平台」的 AI 工作流。這類 cookie 抓取功能在台灣法規下，不僅涉及對方平台服務條款，也可能踩到個資法與《刑法》妨害秘密罪的紅線。不是不能用，而是「能不能用」需要你自己查清楚適用情境，鏡像本身不會幫你判斷。

預設值裡的資安暗礁

把 .env.example 預設值攤開來看，這個鏡像在「方便部署」與「安全預設」之間明顯偏向前者，這對生產環境是必須調整的。最關鍵的幾個：

• DOCKER_BIND=0.0.0.0：閘道暴露到所有網路介面。如果你的 VPS 沒有防火牆或安全群組，AI 機器人控制端等於直接掛在公網。實務上應該改成 127.0.0.1（只本機存取）或搭配 Nginx 反向代理與鑑權。
• DM_POLICY=open / GROUP_POLICY=open / ALLOW_FROM=*：訊息策略預設全開放，任何來源都可以呼叫機器人。正式環境一定要把 ALLOW_FROM 收斂到具體 user id 清單，或把 DM_POLICY 設成 closed / friend-only。
• OPENCLAW_GATEWAY_TOKEN=123456：預設閘道 token 是範例值 123456，這個值出現在 README 與 env 範本，等於半公開。不改就是讓任何人都能用這個 token 呼叫閘道。
• AGENT_REACH_USE_CN_MIRROR=true：預設啟用中國大陸鏡像源，把 GitHub 與 pip 下載路徑繞進第三方鏡像。台灣或海外部署應該關掉，直接走官方源。
• API Key 集中 .env：六個 LLM provider 的 key 都集中在同一個檔案，洩漏一次就全曝光。README 自己也提醒「千萬別把 .env 提交到公開 GitHub 倉庫」，這條要照辦。

另外有一個 Docker 部署常見、但這個鏡像特別容易踩到的權限摩擦：容器以 node 使用者（UID 1000）執行，但宿主機的 ~/.openclaw 掛載目錄預設可能是 root 或當前登入使用者所有，啟動時會出現 Permission denied。issue #204 與 README 的「常見問題」都討論過，正解是 sudo chown -R 1000:1000 ~/.openclaw 或在 compose 指定 OPENCLAW_RUN_USER。會遇到這個問題的機率很高，建議第一次啟動前就先把目錄所有權調好，別等到容器反覆崩潰才排查。

還有一個新手不容易注意到的設定覆蓋陷阱：openclaw.json 設定檔只在「首次啟動且檔案不存在」時從 env 生成，之後改 .env 不會自動同步到 JSON，這在 README 寫得很小聲，但實務上你一定會踩到。要套用新設定，要嘛刪掉 openclaw.json 讓它重新生成，要嘛設 SYNC_OPENCLAW_CONFIG=true 與 SYNC_MODEL_CONFIG=true 讓它每次啟動都覆寫。

AIClient-2-API「無限 Token」是怎麼回事

README 最上方的推薦欄位寫著「推薦搭配 AIClient-2-API 專案使用，將各大 AI 客戶端轉換為標準 API 介面，實現無限 Token 呼叫」。這個推薦配置是同一個作者 justlikemaki / justlovemaki 的另一個專案，從字面描述看，它做的事情本質上是「把用戶端（如 ChatGPT、Claude 官方網頁）的會話轉成 OpenAI / Claude 相容的 API 端點」。

這條路徑在技術圈是常見的灰色地帶：LLM 供應商（OpenAI、Anthropic、Google）的服務條款幾乎都明文禁止「把網頁版會話包裝成 API 對外提供」，因為這等於繞過他們的 API 計費機制，把網頁版的「不限量訂閱」當 API 用。從供應商角度，這是 ToS 違規；從使用者角度，這是「我訂閱了，怎麼用是我的事」的認知落差。本篇不會背書也不會鼓勵這條路徑，只如實說明它的本質與風險。若你的服務要長期營運、要對客戶負合約責任，把整個 AI 後端押在一個會被供應商隨時封鎖的灰區機制上，是風險不對等的賭注。穩當的做法是直接用 OpenAI、Anthropic、Google 的官方 API（或代理如 OpenRouter）作為 BASE_URL。

鏡像本身是中立的：你填哪個 BASE_URL，它就呼叫哪個 API。把 BASE_URL 指向 AIClient-2-API 或指向 OpenAI 官方 API，部署流程完全一樣，差別在你承擔的合規風險。

多 LLM provider 的配置也值得展開看。docker-compose 的 anchor 一次保留六個 provider 槽位（MODEL_ID 到 MODEL6_MAX_TOKENS），每個槽位都有獨立的 BASE_URL、API_KEY、API_PROTOCOL、CONTEXT_WINDOW、MAX_TOKENS 五個欄位。這個設計讓你可以在同一個容器內同時掛 OpenAI、Anthropic、Google、阿里通義、字節豆包等六家模型，再透過 PRIMARY_MODEL 指定預設、IMAGE_MODEL_ID 指定圖片模型，把不同的 AI 任務路由到最適合的供應商。這個 multi-provider 切換是 OpenClaw core 本身就提供的功能，本鏡像只是把環境變數攤出來方便填。實際路由邏輯、failover、計費追蹤都還是 core 在做。

另一個值得點出的設計是工作空間持久化。容器把 /home/node/.openclaw/workspace 目錄掛到宿主機，機器人的長期記憶、對話歷史、技能設定都存在這裡，容器重啟不會遺失。但 openclaw.json 主設定檔與 workspace 是分開的：主設定只在首次生成時寫入，這也是前面提到的「改 .env 不生效」陷阱的根源：workspace 是持久的、設定檔也是持久的，但兩者的同步邏輯不對稱。實務上要嘛把 SYNC_OPENCLAW_CONFIG=true 打開（每次啟動都把 env 同步到 JSON），要嘛手動維護 JSON 不依賴 env，兩者只能擇一，否則一定會踩到「我明明改了 env 怎麼沒生效」的困惑。

與其他 OpenClaw 部署路徑的差異

TechMoon 先前已經介紹過幾種不同的 OpenClaw 部署或使用切入點，本篇這個鏡像與它們的關係需要釐清，免得讀者混淆：

關鍵差異化在於「IM 介接預載」這一件事：其他四個方案（安裝腳本、教學站、桌面 GUI、硬體）都不幫你接好飛書釘釘企微，你拿到的是 OpenClaw core 本身，IM 介接要自己照官方文件（如 openclaw.ai/docs/channels 的說明）逐個平台申請、配置、寫介面卡。本篇這個鏡像把這段工作做完了。代價是它預設的中國大陸視角（CN 鏡像源、Shanghai 時區、XHS 小紅書 cookie 抓取）你必須能接受或自行關閉。

誰適合用，誰該繞路

綜合以上，這個鏡像適合的讀者輪廓相當具體：

• 台商、跨境電商、代營運團隊：你的客戶或合作方在中國大陸，內部溝通與客服都走飛書釘釘企微，需要把 AI 助理快速接入這幾個 IM。這是這個鏡像的甜蜜點。
• 中國大陸中小企業內部 IT：公司用的就是這幾個 IM，需要一個不用養 DevOps 團隊就能架起來的 AI 機器人網關。
• 開發者評估 IM 整合可行性：想快速做 POC 驗證「飛書 + AI 回應 + 釘釘通知」這類多平台工作流，這個鏡像可以省下至少一週的介面卡配置時間。

相對地，以下幾種情境建議直接繞路：

• 純台灣內部用 LINE、Slack、Discord：這個鏡像幫不上忙，請走 官方 core + 自己寫 LINE/Slack 介面卡，或直接找專為這些 IM 設計的整合方案。
• 需要正式環境的合規與長期維護承諾：第三方個人專案的維護是「作者意願制」，且 GPL-3.0 的 copyleft 對商業產品嵌入有義務，正式產品建議直接用上游 OpenClaw core 自架。
• 不熟悉 Docker 與 Linux 權限模型：UID/GID 摩擦、設定覆蓋陷阱、0.0.0.0 綁定這些都是 Docker 部署的基本題，但對新手會卡很久。沒意願啃 docker-compose 與 .env 配置的話，這個鏡像不是好起點。
• 要把 AI 後端押在「無限 Token」灰區：作者推薦的 AIClient-2-API 路徑踩 LLM 供應商 ToS，長期營運的服務別押在這上頭。

常見問題

這個鏡像是 OpenClaw 官方出品嗎？

不是。鏡像維護者是個人開發者 justlikemaki（GitHub 帳號 justlovemaki），採 GPL-3.0 授權，與上游 openclaw/openclaw（NOASSERTION 授權）沒有從屬關係，只是把上游 core 打包進容器並預載中國大陸 IM 介面卡。官方 OpenClaw 不對這個第三方鏡像背書。

什麼情境會想用這個鏡像？

主要場景是「業務或服務對象在中國大陸」，例如台商、跨境電商、代營運團隊、或總部在中國大陸的跨國分公司。如果你的客戶天天用飛書、釘釘、企業微信跟你溝通，把 AI 助理接進這幾個 IM 對你的工作效率有實質幫助。本地內部用 LINE、Slack 的團隊，這個鏡像的預載內容不會用上。

可以商用嗎？

鏡像本身的 GPL-3.0 允許商用，但任何「散布」衍生作品的義務會觸發：你把它包進自家 SaaS 對外提供，需要揭露你的修改並保留 GPL-3.0 授權條款。上游 OpenClaw core 的 NOASSERTION 是另一層，要單獨看它的 LICENSE 條款。此外，飛書、釘釘、企業微信各自的開發者服務條款也對「機器人自動發訊」有反垃圾訊息規範，商用前一定要逐個平台讀完條款。

為什麼我啟動後機器人能發訊息但收不到訊息？

最常見原因是飛書開放平台後台沒有正確配置事件訂閱。需要在「事件與回呼」頁面選擇「使用長連接接收事件」，並勾選 im.message.receive_v1（接收訊息）這個事件，這是 README 與飛書開放平台文件都會提醒、但首次部署最容易漏掉的設定。釘釘、企業微信也有各自的回呼或長連接設定，症狀相同時先檢查事件訂閱方向。

鏡像會持續更新嗎？

截至 2026-07，作者還在持續同步 OpenClaw core 至 2026.5.19（見 issue #211），但第三方個人專案的維護承諾沒有合約保障。長期生產環境建議把 core 版本釘死、定期手動跟進升級，不要無腦用 :latest 標籤。

想看作者後續更新軌跡或社群反饋，可以追 GitHub issue 列表；想了解 OpenClaw 整體生態、其他部署方式，可以回頭看我們先前整理的 OpenClaw 101 第三方教學聚合站介紹。