最近 Wework 做了两次比较大的架构调整：

一是把桌面客户端从 Tauri 重写成 Electron；二是把原来的单体应用拆成一系列 DeepSeek Harness 插件，再重新组装起来。

先说 Tauri。

在 AI 时代，选择 Tauri 还是 Electron，开发难度其实已经没有过去那么大的差别了。两者的训练语料都足够丰富，大部分功能都能让 AI 帮你实现。

当初选择 Tauri，主要有两个原因：一是安装包体积小，方便分发；二是项目立项时只是想做一个 POC，没想到它后来真的能在日常开发中基本替代 Codex。因此，最初的技术决策多少有些随意。

Wework 做出来以后，实际体验比预期好很多。不敢说能 100% 平替 Codex，但至少能达到团队需求的 90%，同时还可以按照自己的想法不断增加功能，于是就一路迭代了下来。

但随着功能越来越复杂，Tauri 在 Wework 的具体场景下暴露出了两个问题。

第一个是“AI 浏览器”。

这个功能的核心，是让开发者修改前端代码时，可以直接在内置浏览器里预览和操作页面。Tauri 在 macOS 上依赖系统 WebView，一些页面会出现白屏、兼容性异常或难以解释的错误。为了让不同网站正常运行，我们不得不针对各种 case 不断打补丁，维护成本越来越高。

更麻烦的是性能分析，尤其是内存问题。

很多时候内存涨了还是跌了、为什么涨、涨在哪里，都很难形成可靠的证据链。即使通过 DevTools 录制性能日志，最后往往也只能得出“JavaScript 没有明显问题，但系统内存就是被占用了”这样的结论。一些卡顿同样难以稳定复现和定位。

从 Wework 做出来的这几个月里，我几乎一直在和这些性能问题斗智斗勇。

切换到 Electron 以后，我们甚至没有做多少针对性的性能优化，很多长期存在、难以解释的问题就自然消失了。它未必说明 Electron 在所有场景下都优于 Tauri，但至少对 Wework 这种高度依赖浏览器能力、调试工具和复杂页面集成的桌面应用来说，Electron 是更合适的选择。

第二个调整，是引入 DSH 框架。

最近 DSH 很火，但我觉得火的方向有一点奇怪。

“万物皆插件”本质上是一种面向开发者的技术实现方案，不应该直接等同于面向终端用户的产品形态。

先不讨论用户有没有能力定制插件，事实是，绝大多数终端用户根本没有这种意愿。他们真正想要的是开箱即用，再加上少量、可理解的配置，而不是先学习一套插件系统，再组装出一个自己能用的应用。

插件本质上还是一种与运行时绑定的开发协议。协议有机会形成长期生态，例如 TCP/IP 和 POSIX；但具体运行时的维护往往脆弱得多，能够长期稳定维护的大型运行时并不常见，操作系统可能算其中一种。

现在 DSH 插件社区的很多实践，正在把“AI 操作系统”的野心变成“桌面客户端 UI 换壳社区”。某种程度上，这也反映出了协议和运行时高度绑定后，社区很容易被具体实现牵着走。

因此，Wework 接入 DSH 的目标不是把面向用户的应用改造成一个“万物皆插件”这种听起来就很难用的东西，而是在保持开箱即用的前提下，提供边界清晰、能力受限的定制功能。

比如增加一个左侧菜单、扩展右侧边栏，或者添加一个自己专用的 Tab 页面。这些都属于可以开放的、受控的定制能力。

但在 Agent 运行能力上，我依然倾向于一个判断：未来真正知名、通用的 Agent，可能一只手就数得过来。与其让每个用户通过插件配置出一套自己的 Agent，不如把成熟通用 Agent 的工具和运行能力接进来。

目前 Wework 底层默认接入 Codex；打开实验特性后，也可以切换到 Claude Code、OpenCode 等其他 Agent。虽然底层已经具备“完全定制一个 Agent”的能力，但我认为，至少对于一款通用工具来说，这项能力现阶段的实际意义并不大。

这轮改造累计新增了十多万行代码，删除了七八万行，代码变更量接近二十万行。

从 8 月 24 日晚上做出决定，到新版本最终发布，大约只用了四天。整个过程基本就是我一个人，带着一群没日没夜疯狂工作的 AI 完成的。

放在几年前，“四天时间重写一个完整 IDE”听起来几乎是天方夜谭。

可能谁都没有想到，未来会来得这么汹涌。