常驻原生、按需 WebView：agent 桌面应用的 GUI 公式

一个后端背景的独立开发者，把自己的 agent 桌面应用从 Wails 迁到了 MyGo 原生 GUI，把全程踩坑发在 V2EX 上。这篇帖子的价值不在结论，在于它是「agent 桌面应用的 GUI 选型」这个新问题下少见的实名实操记录：连两个分支都留着做对照（Ally agent 的 main 分支是 Wails 版，mygo 分支是 MyGo 版，仓库 github.com/Bronya0/ally-agent）。

一、为什么迁

作者用 Wails 用了很多年，V3 刚等来正式版，「等了四年」。看到有人推荐 MyGo（egoist 出品，VuePress 等知名开源项目的作者），自己对内存和性能有追求，就拿自己的项目当试验田，结论是「结果意外的不错」。迁移动机里 Wails 的痛点有三条：跨平台界面细节不一致（Windows 的 WebView2 和 macOS 的 WKWebView 是两个引擎，字体、行高、滚动条偶发差异，macOS 上表格线条发虚）；构建链长（前端依赖、绑定生成、Vite 构建、再编译 Go 四段）；前端内存问题难排查（Go 堆、JS 堆、DOM、渲染进程几块内存混在一起，「分析起来没有 Go 那么顺手」）。

二、MyGo 是什么

egoist 的 Go 桌面应用框架：纯 Go、无 CGO，要求 Go 1.27 以上。最关键的设计是每个窗口二选一：系统 WebView 或 GPU 自绘的 Native UI（Metal、Direct3D 11、OpenGL），同一个应用里可以混用。官方口径：单二进制约 7MB，native UI 内存约 44MB，webview 约 62MB，空闲 CPU 为零，当前 v0.7.0。作者的迁移范围也遵循务实原则：聊天、设置这些常用页面用 Native UI，插件页面和部分预览（HTML、Mermaid）仍按需走 WebView。

三、五条踩坑干货

一，自绘统一了渲染引擎，但不等于像素完全一致：文字排版仍走各平台的文字系统，字体回退、DPI、输入法要分别检查。二，内存排查回到舒适区：全部在 Go 进程里，pprof 顺手，作者还加了设置页「导出内存诊断」入口。三，最硬核的一条：MyGo 界面更新会重建控件树，渲染函数里不能做重活。作者的命令执行卡片折叠时先拆分整段输出再取末尾几行，改成从尾部向前扫描加缓存后，2 万行输出的单次分配从 1.9MB 降到 1.9KB，耗时从 0.72ms 降到 0.02ms。核心经验是分清「每次请求执行一次」还是「每帧执行一次」。四，构建链变短：纯 Go 无 CGO 交叉编译，一个脚本产出 Win、mac、Linux 乘 x64、ARM64 六个目标。五，插件化是 Go 的硬伤：标准库 plugin 不支持 Windows、加载后不能卸载，跨三平台热插拔插件市场不现实，「可插拔页面」更接近天花板。

四、冷水与判断

四条质疑：作者自己承认「内存占用和响应明显改善」是体感，没有完整对照数据；单一样本；MyGo 很新（v0.7.0），Lindy 效应未知；Wails 3.1 也加入了无 CGO 构建，差距可能收窄；自绘有隐性成本，无障碍、输入法、复杂文本排版这些 WebView 本来免费提供的能力，自绘路线要自己补。

判断落在选型公式上：「常驻原生、按需 WebView」是 agent 桌面应用目前最务实的 GUI 组合：主界面要常驻和低内存，就用原生自绘；复杂内容渲染按需回 WebView。还有一层更值得记的：作者明说「现在有 AI 帮忙，这件事容易太多了」，原生 UI 的成本方程被 agent 改写之后，后端背景的独立开发者成了最大受益者。至于迁移的收益有多少属于 MyGo、有多少属于「重写一遍本身」的清理效应，帖子里分不出来，读者引用那些数字时要带上这个折扣。

来源：V2EX 原帖 v2ex.com/t/1253950（第一手，2026-11-02）；github.com/Bronya0/ally-agent；mygo.egoist.dev。