扔掉 Electron：一个人 + 一队 AI 代理，撸出双端原生 SSH 客户端 PixShell
摘要：2026 年了，为什么还有人用 Electron 写 SSH 客户端？PixShell 的作者给出了另一种答案：同一个 monorepo，macOS 端用 Swift + AppKit + SwiftTerm + SwiftNIO 手写 SFTP v3 协议，Windows 端用 C# WPF + WebView2 + SSH.NET，双端原生、零 Electron。功能上它几乎照着 FinalShell 抄了一遍作业（同屏目录同步、chmod、打包传输、一键迁移），又加上了 2026 年的新东西：MCP、Agent Bridge、AI 工具一键接管 SSH。更有意思的是——这个项目几乎是一个人带着几个 AI 编码代理写出来的。本文拆解它的功能定位、架构取舍、协议实现细节和那些藏在注释里的踩坑记录。 一个 SSH 客户端的"去 Electron 化"实验 打开 FinalShell、Termius、Tabby 的进程列表，你大概率会看到一堆 --type=renderer 的 Chromium 子进程。一个用来连服务器的工具，自己先吃掉 800MB 内存，这件事大家似乎已经习惯了。 PixShell（github.com/lyu0805/pixshell）的作者显然没习惯。这个项目的前身就是一个 Electron 应用——仓库里的蓝图文档还留着旧账：renderer 约 1.6 万行 + main 约 5700 行 JS。从 v0.1.1 开始，他做了一个相当激进的决定：推倒重来，双端全原生，同一个 monorepo 维护。 平台 UI 终端渲染 SSH/SFTP 栈 🍎 macOS Swift / AppKit SwiftTerm（原生渲染） SwiftNIO + 自研 SFTP v3 🪟 Windows C# / WPF WebView2 + xterm.js SSH.NET 注意这张表里最反直觉的一点：macOS 端没有用 xterm.js。Mac 的终端是 SwiftTerm 原生渲染的，只有 Windows 端因为 WPF 生态里没有像样的终端控件，才走了 WebView2 内嵌 xterm.js 这条路。作者在 README 里专门加了个警告框强调这件事——大概是被问烦了。 ...