夜雨聆风
我开发了 OpenClaw 桌面版，也反复被问到一个问题。
已经有 OpenClaw 了，为什么还要做一个桌面版？
如果只看表面，这个问题很容易被理解成在 OpenClaw 外面包了一层壳。可我真正想做的事情，要比多一个桌面界面严肃得多。
OpenClaw 很强，它有模型、有智能体、有渠道、有 Skill、有 Gateway，也有很大的扩展空间。
但也存在真实的问题。
对于绝大部分用户来说，首先面对的是一串要先解决的门槛。Node.js 怎么装，CLI 怎么跑，端口怎么看，日志去哪找，配置文件怎么改，出问题以后从哪开始排查。
对极客与 OpenClaw 玩家来说，这些是常规动作。对更多普通用户和团队用户来说，这些已经足够劝退。
所以我做 OpenClaw 桌面版，想解决的是交付问题。
PART 01｜开发桌面版的原因
我越来越清楚地意识到，很多产品真正难的地方，并不在能力有没有，而在于用户能不能顺利用起来，并长期用下去。
直接安装 OpenClaw，用户往往还要自己处理几件并不轻松的事情。
安装运行环境与依赖
理解 Gateway、配置、端口、日志、会话这些概念
在 CLI、配置文件、浏览器页面之间来回切换
出故障时自己定位路径、版本兼容与恢复办法
团队分发时尽量保证每台机器环境一致
这些任务很繁琐，也不能产生价值。
我想做的，就是把这部分复杂度尽量收回到产品内部。用户安装完成后，拿到的应该是一套可以工作的本地 AI 工作台，而不是一堆还差几步才能跑起来的零散组件。
OpenClaw 提供的是强大的 AI 能力底座。OpenClaw 桌面版负责把这套能力稳定交付到个人用户、专业用户和团队的日常工作流里。
PART 02｜我给产品定了条原则
我从一开始就不想把 OpenClaw 桌面版，做成一个定制（魔改）的 OpenClaw，类似有些大厂的做法。
这条原则很重要。
因此，桌面端应该封装上游，尽量不改动上游。
这意味着几件事。
第一，核心能力仍然来自 OpenClaw 本身。模型、智能体、路由、渠道、Skill、Gateway 协议，这些底层能力体系，我不想在桌面版里再造一遍。
第二，桌面版负责的是产品化交付层。它要把安装、桌面 UI、进程管理、配置入口、诊断入口、升级路径、团队分发这些事情做好。
第三，桌面版应保留原版能力的入口。原版的控制台界面（Control UI）不能消失，CLI 也不能消失。高级用户需要它们，因为真正做调试、核查、排障时，这些原生入口依然很重要。
所以你会看到，OpenClaw 桌面版一方面内置完整、最新版的 OpenClaw，另一方面又保留原版 Control UI，并通过配置文件与 Gateway API 和上游保持一致。
这是产品长期可维护的前提。
PART 03｜产品的 7 条设计规则
开始做桌面版以后，我给立了几条硬性规则。后面每做一个功能，我都会拿它们来对照一遍，这件事到底该不该做。
1）完整交付
用户真正需要的不是一个能打开的窗口，而是一套可以工作的环境。
所以桌面版交付的不只是聊天页。它要把 OpenClaw Gateway、OpenClaw CLI、原版 Control UI，以及聊天、配置、技能、日志、终端、会话、智能体管理这些能力一起组织好，再补上自动更新、托盘、恢复等桌面能力。
2）尊重上游
桌面版的价值不在于和上游比谁功能更多。真正有价值的地方，是尽量复用已有能力，尽量沿用已有配置和概念，让高级用户仍然能直接接触原版入口，把精力更多放在可视化、引导、兼容和易用性上。
3）把桌面版做成工作台
桌面版不是另一个控制台。
控制台解决的是能不能管。工作台解决的是能不能长期好用。这两者差别很大。
工作台意味着什么？
意味着聊天、配置、运维、日志、技能安装、会话切换，不该分散在多个入口里。
它们应该在一个统一导航和一组结构化页面里形成真实工作流。Dashboard、Chat、AgentHub、Session Manager、Skills、Terminal、Logs、Settings，这些模块存在的意义也在这里。
4）把复杂留给产品，把简单留给用户
优秀的桌面产品，不靠让用户理解更多内部机制来证明专业。
它应该反过来做事。
能用安装包解决的，就别让用户搭环境。
能用 Provider 选择器解决的，就别让用户手写配置。
能用图形化渠道表单解决的，就别让用户直接改 JSON。
能用错误页、日志入口和恢复路径说清楚的，就别让用户在报错里靠猜。
5）对国内用户友好是关键
这件事我看得很重。
所谓对国内用户友好，远远不只是界面翻译成中文。
更关键的是模型是否更容易配置，国内常见的模型提供方是否更容易发现，飞书这类渠道是否有明确入口，技能生态是否在国内网络环境里更容易获取，更新、下载、诊断这些路径是否更顺畅。
所以桌面版在模型提供方（Provider）展示上，按推荐、国内、国际、Coding和本地/定制等方式组织，在渠道上补充飞书等入口，在技能中心同时支持 SkillHub 和 ClawHub，也会在下载和分发链路上显式考虑国内网络现实。
6）同时服务新手和高手
我不希望它只为一种用户设计。
新手用户需要图形界面、模板、解释和尽量低的门槛。
高级用户需要 Control UI、CLI、日志、配置细节和更底层的控制能力。
一个成熟的桌面产品，应该同时容纳这两种入口，而不是强迫所有人都走同一条路。
7）可分发、可维护、可升级
一款软件能不能走进团队，最后拼的往往不是页面漂不漂亮，而是它能不能稳定打包，能不能统一分发，版本能不能讲清楚，升级风险能不能控制，出问题时能不能快速恢复。
桌面版的版本策略、自动更新、安装包分发、日志与恢复路径，本质上都在回答这些问题。
PART 04｜定了规则，如何落地
如果只讲理念，文章很容易写得很空。更重要的是，这些原则今天已经对应到一些具体能力上。
先说最核心的一点。
OpenClaw 桌面版内置完整、最新版的 OpenClaw，同时保留原版 Control UI。这保证了它既有开箱即用的交付能力，也没有牺牲专业用户对原生入口的需求。
其次，Provider 配置体验明显更适合国内用户。它不再把所有提供方平铺成一长串，而是按推荐、国内、国际、Coding和本地/定制等方式组织。很多容易出错的 Key、Base URL、协议差异、模型适配问题，也会尽量在界面层提前讲清楚。
第三，渠道接入开始从“读文档 + 改 JSON”变成产品化入口。飞书等国内渠道已经进入桌面配置路径，后面也会继续按跟进上游成熟实现，再补齐桌面易用性的思路推进。
第四，Skills 的获取方式也在变。桌面版不只是展示本地安装了哪些 Skill，它把浏览、查看详情、一键安装、本地导入这些动作组织成一条更自然的路径，并同时支持 SkillHub 与 ClawHub。
第五，多智能体、多会话终于不只是底层概念了。会话 Tab、智能体选择、Session Manager、AgentHub、运行中 sub-agent 可视化，这些界面对象的价值，在于把原来偏底层的能力变得可看见、可切换、可管理。
第六，桌面版正在形成一个更完整的工作台。除了聊天，它还要覆盖 Dashboard、Terminal、Logs、Settings 等模块，让用户不仅能调用 AI，也能长期管理和维护自己的 AI 环境。
PART 05｜这份设计哲学，也在约束产品路线图
路线图对我来说，首先是一套取舍规则。页面多少、清单多长，都不是最重要的衡量标准。
后面每做一个版本，我都会先看几件事。
第一，它有没有显著降低第一次安装、第一次配置、第一次扩展 Skill、第一次遇错恢复的门槛。很多看起来不耀眼的功能，其实对完成率影响最大。
第二，它有没有强化工作台属性。聊天、配置、会话、技能、终端、日志、状态之间如果不能形成联动，那就只是孤立页面的堆积。
第三，它有没有继续保持和 OpenClaw 上游的兼容。能复用的地方尽量复用，Desktop 多做交付层、可视化层、操作层的增强。
第四，它有没有继续照顾国内用户的真实使用环境。Provider、渠道、下载、技能、诊断这些链路，要整体更可达。
第五，它有没有同时保留简单入口和专业入口。图形化、模板化、可解释的路径要继续做，Control UI、CLI、日志与底层状态这些入口也不能被牺牲。
按这个思路看，后面的版本目标就很清楚了。
刚刚发布的 OpenClaw 桌面版 v0.3.0，已经开始更像一个每天会打开的工作台，把多智能体、多会话、Skills、Terminal、快捷操作和国内体验完整提供。
未来，我希望它更深地融入日常工作环境，比如多窗口、托盘、通知、快捷入口、文件与系统级操作的顺滑整合。
更长远一点看，我希望它从个人工作台继续走向团队级交付，但前提始终不变。它仍然应该尊重 OpenClaw 的能力边界，保持与上游协同，而不是脱离生态自己长成另一个系统。
PART 06｜我对桌面版产品的展望
短期看，我希望桌面版，可以让更多人能更顺畅地装上 OpenClaw、配好 OpenClaw、真正开始使用 OpenClaw。
中期看，我希望它成为用户日常工作里的统一 AI 工作台。打开一个应用，就能聊天、配置、查看状态、安装技能、切换会话、排查问题。
长期看，我希望它能把 OpenClaw 从高手工具继续往前推一步，推成个人用户愿意长期使用、团队愿意统一分发、组织愿意持续维护的软件。
这也是我理解的产品化。
它要做的是把能力组织得更好，把复杂度接过去，把门槛降下来，把维护路径铺平。原版入口还在，底层能力也还在，只是交付方式变了。
我觉得可以这样总结。
直接安装 OpenClaw，你得到的是能力。
安装 OpenClaw 桌面版，你得到的是能力、体验、交付和工作流。
