nexu 评测：把 OpenClaw 桌面客户端接到微信、飞书，本地优先但配置门槛仍在
The simplest desktop client for OpenClaw 🦞 — bridge your Agent to WeChat, Feishu, Slack & Discord in one click. Works with Claude Code, Codex & any LLM. BYOK, Oauth, local-first, chat from your phone 24/7.
秒懂
- 它是什么？
- nexu 是一个 MIT 许可的桌面客户端，目标是用图形界面把 OpenClaw 智能体接到微信、飞书、Slack 和 Discord。它强调本地优先和自带 API Key，但需要先理解 OpenClaw 的生态和微信插件的限制。
- 适合谁用？
- 适合已经使用 OpenClaw、熟悉其插件机制，并且希望把智能体搬到手机聊天窗口里的个人开发者或小团队。不适合完全没有命令行经验、指望开箱即用的人，因为微信通道依赖 OpenClaw 的插件版本，飞书技能也需要自己维护。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 142 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是哪个具体问题
OpenClaw 本身是一个命令行工具，智能体跑在终端里，普通用户没法在手机上随时对话。nexu 把自己定位成 OpenClaw 的桌面客户端，把智能体接到微信、飞书、Slack 和 Discord 这些聊天软件里。目标用户是单人公司和三五人小团队，尤其是跨境电商、内容创作者、独立开发者这类角色。它不提供模型，模型靠你自己的 API Key 或者 OAuth 登录。客户端的价值在于省掉手动配置环境变量和依赖的步骤，双击安装，图形界面里点几下就能连上聊天通道。
本地优先的数据路径与远程可达的矛盾
README 反复强调 local-first，数据留在本机，不经过 nexu 的服务器。但聊天通道本身需要把消息转发到 IM 平台，比如微信的消息要经过微信服务器。所谓本地优先，指的是你的业务数据、对话记录和 API Key 不存到 nexu 的后端，而不是说消息不经过第三方。这个区分很重要。对隐私敏感的用户，需要清楚哪些数据留在本机，哪些数据必然经过 IM 平台。nexu 的定位是客户端，不是网关，所以它无法避免聊天平台对消息的接触。
安装与首次运行：图形界面掩盖了什么
官方提供 macOS Apple Silicon、macOS Intel 和 Windows 的下载包，宣称双击安装、无需环境变量。首次运行有图形化设置，内置飞书技能，支持 Gemini 等模型。但要注意，微信通道依赖 WeChat 8.0.7 的 OpenClaw 插件，这意味着你本机必须已经装好对应版本的微信，并且插件要能正常工作。nexu 只是客户端，它不包含 OpenClaw 本体。若你从未装过 OpenClaw，双击 nexu 后大概率会引导你去装依赖，而不是真正的零配置。
模型接入方式：BYOK 与 OAuth 并存
nexu 支持两种模型接入路径。一是自带 API Key，不登录账号也能用，这适合已有 OpenAI、Anthropic 或 Google 账号的用户。二是 OAuth 登录，目前支持 MiniMax、OpenAI Codex 和 GLM 的 Z.AI Coding Plan，授权后无需复制粘贴 Key。这种设计降低了使用门槛，尤其对 Codex 用户友好。但注意，README 没有列出所有支持的模型提供商，只说 Gemini 和更多。实际可用模型列表需要查看文档或应用内选项，不能假设任意 LLM 都能直接填入。
技能与工作流：飞书技能是亮点还是负担
nexu 内置 OpenClaw Skills 和完整的飞书技能。这意味着智能体不只是聊天，还能执行具体的业务动作，比如查库存、生成文案、处理退货。飞书技能对国内团队尤其有用，因为飞书本身是办公协作平台，技能可以直接对接审批、文档、消息卡片。但技能是需要维护的。OpenClaw 的技能生态在变化，飞书 API 也可能更新，nexu 是否跟随上游同步是个问题。从仓库活跃度看，最近一次提交是 2026 年 4 月，v0.1.12 在 4 月 13 日发布，说明项目还在迭代，但版本号仍是 0.1.x，意味着 API 和功能可能不稳定。
与官方方案和托管平台的差异
README 用表格对比了三种路径。官方 OpenClaw 需要手动配置模型，nexu 提供图形化切换。托管平台把数据路由到厂商服务器，nexu 保持本地。官方方案是 CLI，nexu 是纯 GUI。这个对比基本成立，但漏了一个关键点：官方 OpenClaw 是开源的，你可以完全控制部署方式，而 nexu 作为客户端，依赖桌面操作系统和微信插件，反而增加了环境耦合。对需要远程访问的用户，托管平台自带公网入口，nexu 需要你自己处理内网穿透或公网可达性，否则手机上的微信无法连回你家里的电脑。README 没有提及这一点，但这是任何本地运行智能体的实际障碍。
维护成本与许可证
项目以 MIT 许可证发布，你可以自由 fork 和审计代码，README 也鼓励这么做。这意味着如果你不信任二进制安装包，可以自己从源码构建。但 MIT 许可证不附带任何担保，也不提供免费支持。版本 0.1.x 阶段，API 可能变化，升级客户端可能需要重新配置通道。微信插件的兼容性尤其脆弱，微信更新可能导致插件失效。维护成本取决于你对 OpenClaw 的熟悉程度。若你只是用现成功能，升级客户端即可。若你依赖自定义技能，需要跟踪 nexu 和 OpenClaw 两边的变更。
谁适合用，谁应该避开
适合已经跑通 OpenClaw、有 API Key、想从命令行升级到手机聊天界面的用户。不适合期待完全零配置、没有 OpenClaw 基础、或者业务数据必须完全不出本机的人。后者应该考虑自建网关，比如用官方 CLI 配合反向代理，虽然配置更复杂，但数据路径完全由你控制。nexu 的价值在于把 OpenClaw 的接入成本压缩到一个桌面应用里，代价是你接受了它对通道和模型的选择。在采用前，先确认你的微信版本、OpenClaw 插件版本，以及你需要的模型是否在支持列表里。
编辑结论
适合已经使用 OpenClaw、熟悉其插件机制，并且希望把智能体搬到手机聊天窗口里的个人开发者或小团队。不适合完全没有命令行经验、指望开箱即用的人，因为微信通道依赖 OpenClaw 的插件版本，飞书技能也需要自己维护。建议先确认你的 OpenClaw 版本与微信 8.0.7 插件兼容，再下载对应平台的安装包。若你只想要一个不依赖桌面客户端的聊天机器人，官方 CLI 或自建网关可能更直接。
社区笔记