nexu：把 OpenClaw Agent 接進微信與飛書的桌面客戶端

nexu 要解決的是接入摩擦，不是模型能力

OpenClaw 本身是命令列工具，README 的比較表把它列為「CLI, requires technical skills」，模型要自備且手動配置，頻道整合也得自己動手。nexu 針對的正是這一段：把 Agent 接到 IM 的過程包成圖形介面，官方說法是「Scan, connect, and go」。

目標使用者寫得很明確：One Person Company 與小型團隊。README 的案例涵蓋跨境電商、內容創作者、獨立開發者、法律與財務顧問、在地零售、設計創意，共同點是一個人要同時扮演多個角色，且日常工作已經發生在微信或飛書裡。對這群人來說，真正的門檻不是模型選得好不好，而是「我不會寫設定檔」。

這裡有個容易混淆的地方：nexu 不提供模型，也不託管你的業務資料。它是一層客戶端，負責登入、頻道綁定與模型選擇。你付費的對象是模型供應商，不是 nexu。

本地優先的資料路徑與 BYOK 的兩條登入路線

README 反覆強調 local-first，並在比較表中用「we don't host your business data」對比那些資料繞經廠商伺服器的託管方案。桌面客戶端執行在你的機器上，訊息從 IM 進來、交給 Agent、再回到 IM，中間不經過 nexu 的伺服器。這是它與託管式 Feishu agent 堆疊最根本的差別，也是選擇它的主要理由。

模型接入分成兩條路。一條是 OAuth：README 點名 MiniMax、OpenAI Codex、GLM（Z.AI Coding Plan）支援一鍵授權，不必複製貼上 API Key。另一條是 BYOK，自己填 Key，而且可以完全不註冊帳號、不登入就使用客戶端。官方也提到可透過 nexu 帳號直接使用 Gemini 等模型，之後隨時切回自己的 Key。

授權模式是 MIT，README 的說法是「fork and audit」。對需要內部審查的團隊來說，這比閉源方案多了一個可驗證的選項，但同時也意味著沒有廠商 SLA 可以依靠。

從下載到掃碼：nexu 的啟動路徑

README 給出的路徑很短。先到 nexu.io 下載對應平台的安裝檔，官方列出的平台是 macOS（Apple Silicon）、macOS（Intel）與 Windows。安裝後雙擊啟動，README 強調不需要環境變數、不需要處理依賴。

接著是頻道綁定。微信這條路的說明是：需要 WeChat 8.0.7 OpenClaw plugin，在客戶端點擊連接，用手機微信掃碼，之後就能在微信裡和 Agent 對話。飛書、Slack、Discord 同樣是內建頻道，README 說「works out of the box」。飛書另外附帶完整的 Feishu Skills，OpenClaw Skills 也是原生內建。

模型這一步，選擇 OAuth 就一鍵授權，選擇 BYOK 就填入自己的 API Key。連上 IM 之後，Agent 處於 24/7 在線狀態，從手機就能繼續對話，不必額外安裝 App。

需要提醒的是，這份材料沒有提供任何 CLI 指令、設定檔路徑或設定鍵名稱。nexu 的設計就是把這些藏起來，所以本文也無法給出可貼上的設定範例。若你需要以程式化方式部署或納入 CI，這份 README 幫不上忙。

版本節奏透露的成熟度訊號

從 release 記錄看，v0.1.10 到 v0.1.12 分別落在 2026 年 4 月 2 日、4 月 8 日與 4 月 13 日，大約一到兩週一個版本，最後一次推送是 4 月 26 日。三個版本號都停在 0.1.x，代表 API 與行為都還在變動期。

這對評估有實際意義。桌面客戶端一旦承擔 Agent 的常駐執行，版本升級就可能影響你已經綁好的頻道與 Skills。README 沒有描述升級流程、資料遷移或回滾方式，也沒有說明設定是否向後相容。

我不會用版本號推論品質好壞，只把它當成一個事實：這是一個活躍但尚未進入 1.0 的專案。如果你的 Agent 只是個人助理，這個節奏可以接受；如果它掛著客戶自動回覆，升級前就該先確認變更內容。

什麼情況下 nexu 是錯的工具

第一個限制來自平台。官方只列出 macOS 與 Windows，Linux 不在支援清單內。開發環境或伺服器跑 Linux 的團隊，這條路直接堵住。

第二個限制是微信這條路的依賴。README 明確要求 WeChat 8.0.7 OpenClaw plugin。這意味著微信端的可用性不完全由 nexu 決定，而是綁在一個特定版本的插件上。插件更新、微信端政策變動，都可能讓這條鏈路失效，而 nexu 這邊能做的有限。

第三個限制是抽象化的代價。nexu 把設定收進 GUI，換來的是可程式化程度的下降。README 的比較表自己承認 OpenClaw 官方版本的好處是「Free, but self-deploy required」，也就是完全可控。如果你的需求是自訂頻道、串接內部系統、或在多台機器上複製同一套配置，直接使用 OpenClaw CLI 會比透過 nexu 更直接。nexu 的價值在於你不想做這些事。

第四，資料留在本機是優點也是責任。沒有廠商幫你備份、幫你做合規稽核，這些都回到你自己身上。

與託管式 Feishu agent 堆疊的取捨

最直接的替代方案是 README 比較表中的「Typical hosted Feishu + agent stacks」。這類方案把模型、頻道與執行環境一起打包，通常按月或按席位收費，好處是開箱即用、有人維運，代價是模型被平台鎖定、無法切換，且訊息會經過廠商伺服器。

兩者的差異不在功能清單，而在責任歸屬。託管方案把維運與合規外包出去，你換到的是可預測性；nexu 把這些留給你，你換到的是控制權與模型自由。nexu 的費用結構也對應這個取向：客戶端免費，你直接用自己的 API Key 付錢給模型供應商。

另一個替代方案是直接使用 OpenClaw 官方 CLI。它免費、開源、完全可配置，但需要自己處理環境與頻道整合。nexu 本質上是這條路的圖形化封裝，適合不想碰終端機的人，不適合需要腳本化的人。

選擇的判斷點很簡單：你更怕資料離開本機，還是更怕自己維護？前者選 nexu 或 OpenClaw CLI，後者選託管方案。

授權、維護成本與採用判斷

授權是 MIT，可以自由 fork 與審計，README 也把這一點當成賣點。要注意的是，MIT 涵蓋的是 nexu 這個客戶端本身，不包括你使用的模型供應商服務條款，也不包括微信、飛書、Slack、Discord 各自的平台政策。你的 Agent 一旦在這些平台上自動回覆，責任落在你的帳號上。本文不構成法律意見，涉及客戶資料的場景請自行確認合規要求。

維護成本主要來自兩處。一是版本升級：0.1.x 階段變動頻繁，README 未說明遷移方式，升級前建議先看 release notes。二是外部依賴：微信端綁定 WeChat 8.0.7 OpenClaw plugin，這個版本關係到整條鏈路能否運作。

採用前值得親自驗證的是：你的 OpenClaw Agent 能否在 nexu 內正常載入 Skills、你要用的模型是否支援 OAuth 或需要自備 Key、以及 IM 端的訊息延遲與斷線重連行為。這三項在 README 裡都沒有具體數字，只能自己實測。

編輯結論

nexu 適合不想碰命令列、只想把既有 OpenClaw Agent 接到微信或飛書的個人與小團隊，尤其是願意自備 API Key、在意資料留在本機的人。若你需要自訂頻道、自行編排多步驟流程，或必須在 Linux 上跑，nexu 目前不是合適的選擇，官方列出的平台只有 macOS（Apple Silicon 與 Intel）與 Windows。動手前先確認三件事：你的 OpenClaw Agent 版本與微信 8.0.7 OpenClaw plugin 是否相容、你要用的模型供應商是否落在 OAuth 名單（README 點名 MiniMax、OpenAI Codex、GLM／Z.AI Coding Plan）或改走 API Key、以及團隊是否接受把 Agent 的常駐執行交給一個版本還在 0.1.x 的客戶端。

官方來源

1. License: MIT
2. nexu-io/nexu on GitHub
3. Project website
4. README
5. Releases