我把 Conch 上传到 GitCode:用 Rust + Flutter 做一个 AI 原生的 SSH/ADB 运维工作台

最近我把Conch同步到了 GitCode:项目地址: https://gitcode.com/Roufsi/conch如果只看名字,它像是又一个 SSH 客户端。但真正写完之后,我更愿意把它叫做一个AI 原生的运维工作台:底层用 Rust 写 SSH / SFTP / ADB / MCP 内核,上层同时提供命令行、桌面端和本地 MCP 服务。也就是说,它不是「GUI 写一套、CLI 写一套、AI 接口再写一套」,而是:同一个 r-shell-core ├── 给 r-shell CLI 用 ├── 给 Flutter 桌面端用 └── 给 MCP 服务器用,让 Cursor / Claude 这类 AI 助手借用 SSH 会话这篇文章就从 GitCode 上这个开源仓库出发,讲清楚 Conch 到底解决什么问题、仓库结构怎么拆、关键技术点在哪里,以及为什么它适合拿来学习 Rust 运维工具、Flutter 桌面应用和 MCP 集成。一、它想解决的不是「能 SSH」,而是运维工具太碎日常管理服务器时,最烦的往往不是 SSH 协议本身,而是操作链路太碎:查状态用ssh userhost cmd;传文件用scp或sftp;看监控要登录后敲top、df、free;管安卓设备又要切到adb shell、adb push、adb pull;想让 AI 帮忙查日志,又不敢把密码 / 私钥直接塞进模型上下文。Conch 的思路是把这些动作收敛到一个本地工作台里:场景Conch 的处理方式连接很多台服务器connections统一管理,本地保存连接信息一次性执行命令r-shell exec -c prod -- uptime交互式排障桌面端命令块终端 / CLIshell文件上传下载SFTP 双栏文件管理,也有 CLIupload/download实时看资源CPU / 内存 / 磁盘 / 网络监控面板AI 参与运维本地 MCP,AI 通过工具复用 SSH 常驻会话管安卓设备ADB 后端纳入同一套终端 / 文件 / 监控 UI这也是为什么我把它上传到 GitCode:它已经不只是一个命令行小工具,而是一个比较完整的跨平台开源项目样例。二、仓库结构:CLI、桌面端、MCP 共用一个 CoreGitCode 仓库里最关键的目录大致是这样:conch/ ├── core/ # r-shell-core:SSH / SFTP / ADB / 监控 / MCP / 存储 ├── cli/ # r-shell 命令行入口 ├── desktop/ # Flutter 桌面应用 flutter_rust_bridge ├── scripts/ # macOS / Windows 打包、内嵌 adb、版本脚本 ├── packaging/ # Windows NSIS 安装器等发布配置 └── docs/ # 架构、进度、ADB、MCP、GUI 等文档根目录是一个 Cargo workspace:[workspace] resolver 2 members [core, cli, desktop/rust]core才是单一事实来源。CLI 只是把参数解析完交给 core;Flutter 桌面端通过flutter_rust_bridge调 core;MCP 服务也在 core 里。这种结构的好处很明显:不会逻辑漂移:连接管理、凭据脱敏、主机密钥校验只写一份。测试更集中:Rust core 可以独立跑单测,不依赖 UI。新入口成本低:有了 core 后,CLI、GUI、MCP 只是不同外壳。适合长期维护:后续加 ADB、Windows 监控、命令块,都往 core 里扩展能力,上层复用。三、命令行入口:r-shell 是一个纯 Rust SSH 工作台Conch 里的 CLI 名叫r-shell。它用 Rust 写,SSH 栈选择纯 Rust 的russh/russh-sftp,不依赖 OpenSSL 或 libssh。常用命令包括:# 保存一个连接 r-shell connections add --name prod --host 203.0.113.10 --username deploy \ --auth publickey --key-path ~/.ssh/id_ed25519 # 列出连接 r-shell connections list # 执行远程命令 r-shell exec -c prod -- uptime # 打开交互式 shell r-shell shell -c prod # 上传 / 下载文件 r-shell upload -c prod ./app.tar.gz /tmp/app.tar.gz r-shell download -c prod /tmp/remote.log ./remote.log # 看系统快照 r-shell stats -c prod它和系统自带ssh/scp的区别,不是协议能力更神秘,而是把日常高频动作做成了统一子命令:连接信息管理 远程执行 SFTP 监控快照 MCP对运维和后端开发来说,这比每次手敲一大串ssh userip -p 2222更顺手,也更适合写进脚本。四、MCP:让 AI 借一条 SSH 常驻会话,而不是拿走你的钥匙Conch 里最有意思的部分是 MCP。传统让 AI 做运维,很容易变成两种危险姿势:把 SSH 密码、私钥路径、服务器地址直接塞进提示词;每执行一步都重新起一个ssh进程,慢,也很吵。Conch 反过来:连接和凭据由本地 Rust 内核持有,AI 只能通过 MCP 工具借用一条已经打开的会话。典型流程是:AI 调 ssh_session_open ↓ Conch 在本机建立 SSH 连接,返回 session_id ↓ AI 后续调 ssh_exec / ssh_read_file / ssh_write_file ↓ Conch 复用同一条 SSH session,不反复重连MCP 端点默认是:http://127.0.0.1:9123/mcp接入 Cursor 时配置类似:{ mcpServers: { conch: { url: http://127.0.0.1:9123/mcp } } }安全边界也做在 core 里:MCP 只绑定127.0.0.1;校验Host/Origin,防 DNS rebinding 和跨域访问;连接列表只返回has_password/has_private_key_path,不回吐密码和私钥;主机密钥按known_hosts做 TOFU 校验,变更即拒绝;workspace.json在 Unix 上按0600/0700收紧权限。我理解的关键原则是:连接归 Conch,凭据归本机,AI 只借会话。五、桌面端:Flutter 做界面,Rust 做内核Conch 桌面端用 Flutter 写 UI,通过flutter_rust_bridge调 Rust core。界面主要有几块:连接主页:按分组展示 SSH / ADB 连接卡片;命令块终端:类似 Warp 的块状命令输出,每条命令有自己的退出码、耗时和输出;文件管理:远程 / 本地双栏,支持上传、下载、重命名、删除、文本编辑;监控面板:CPU、内存、磁盘、网络实时刷新;MCP 面板:启动 / 停止本地 MCP 服务,查看工具目录;设置页:命令块字号、监控采样间隔、MCP 自启等。这里一个很重要的设计是:Flutter 只负责界面和交互,不重写 SSH / SFTP / ADB 逻辑。例如桌面端执行远程命令,最终仍会落到 Rust core:Flutter 输入命令 → flutter_rust_bridge → r-shell-core 的 NativeConnectionManager → SSH / ADB 后端 → 返回输出、退出码、cwd这对跨平台桌面应用很重要。UI 可以迭代得很快,但真正碰服务器、碰文件、碰凭据的部分留在 Rust 里,边界更清楚。六、ADB:把安卓设备也纳入同一套工作台后来 Conch 又加了 ADB 通道。原因很实际:很多时候我们不只管 Linux / Windows 服务器,也会管安卓设备。传统做法是另开终端敲:adb connect 192.168.0.101:5555 adb shell adb push local remote adb pull remote localConch 把 ADB 设备抽象成另一种连接协议:protocol SSH | ADB底层实现不是 trait object,而是一个后端枚举:enum Backend { Ssh(SshClient), Adb(AdbClient), }这样exec、PTY、文件、监控都能在一个NativeConnectionManager里统一分派。上层 UI 不需要到处判断「这是服务器还是安卓」,只要调用同一组能力。ADB 后端做的事情包括:adb shell cmd执行命令;adb shell -t -t打交互式终端;adb push/adb pull做文件传输;adb exec-out cat读文件;通过/proc和df采集安卓监控数据;首次连接支持配对码流程;连接后 best-effort 打开开发者相关设置。更关键的是交付问题:开发机上能找到adb,不代表用户电脑能找到。macOS 从 Finder 启动 App 时只有 launchd 的最小 PATH,不会读你的.zshrc;干净机更可能根本没装 Android SDK。所以 Conch 做了adb_bin定位器:CONCH_ADB / R_SHELL_ADB / ADB_PATH → 随应用内嵌的 adb → ANDROID_HOME / ANDROID_SDK_ROOT → PATH → 常见安装目录 → 回退裸名 adb打包时 macOS 把 universal adb 放进Conch.app/Contents/Resources/adb/,Windows 把adb.exe和AdbWinApi.dll/AdbWinUsbApi.dll放进发布目录。这样用户不用单独装 SDK,双击应用后 ADB 功能也能工作。七、命令块:让远程命令像聊天流一样可读传统终端适合交互程序,但很多日常运维只是连续跑命令:pwd ls -lah df -h systemctl status nginx如果所有输出混在一整屏滚动文本里,回头看很累。Conch 桌面端做了命令块终端:每条命令和输出独立成块,带退出码、耗时、当前目录。这里还有一个有意思的实现点:POSIX shell 和 Windows PowerShell 的包装不一样。POSIX 侧可以用类似哨兵的方式拿退出码和pwd:执行命令 → 末尾 printf 一个不可见分隔符 → 带回 exit code cwdWindows 侧默认是 PowerShell,不能吃 POSIX 语法,所以 core 里又实现了 PowerShell 版本包装,并在 bridge 层按连接缓存远端 shell 类型。第一次跑命令时探测,后续直接复用。结果就是:Linux / macOS 远端可以保持 cwd;Windows PowerShell 远端也可以保持 cwd;每个块都有真实退出码;stderr 会合并进块里展示;对不支持哨兵的环境优雅降级,至少输出能显示。这类细节很适合拿来学习「跨平台远程命令执行」。八、跨平台交付:功能写完不是结束,双击能用才算交付Conch 的另一个重点是零环境交付。Flutter Rust 桌面应用在开发机上跑通很容易,难的是打包给别人后还能双击即用:Windows 上 Flutter 引擎和 Rust MSVC 产物依赖 VC 运行时;macOS 往.app里塞文件后会破坏签名封印,需要重新签名;ADB 这类外部二进制不能赌 PATH;Rust 依赖的默认 features 可能在最终链接时拉进额外系统框架。Conch 的脚本里已经把这些做成发布流程:scripts/build_mac.sh → flutter build macos → 内嵌 adb → ad-hoc codesign --deep → otool -L 自检 → 产出 Conch-macos.zip scripts/build_win.ps1 → flutter build windows → 拷 VC 运行时七件套 → 内嵌 adb.exe AdbWin*.dll → NSIS 安装器 / 便携 zip这部分对做桌面端的人很有参考价值:真正决定用户能不能用的,往往不是 UI 写得多漂亮,而是你有没有把运行时、外部二进制、签名、依赖验证这些最后一公里做好。九、为什么这个项目适合放到 GitCode 上看我把它同步到 GitCode,一个原因是方便国内开发者直接访问和拉取;另一个原因是这个仓库比较适合作为完整开源项目样例。它不是只有一个孤立 demo,而是覆盖了很多真实工程问题:学习方向可以看的内容Rust CLIclap子命令、tokio 异步、russh SSH 编程SSH / SFTP主机密钥校验、PTY、文件传输、连接管理MCPStreamable HTTP、本地工具、常驻会话、安全来源校验Flutter 桌面桌面布局、命令块 UI、文件管理、监控图表Flutter 调 Rustflutter_rust_bridge、cargokit、异步接口ADB 工具配对、shell、push/pull、Android/proc监控跨平台发布macOS.app、Windows NSIS、VC 运行时、内嵌外部二进制GitCode 页面上也能看到最近的提交重点:例如feat(adb): bundle adb for zero-env delivery on macOS Windows,这类提交不是「加一个按钮」,而是把开发环境能跑的问题推进到干净机可交付。十、快速体验从 GitCode 拉源码:git clone https://gitcode.com/Roufsi/conch.git cd conch构建 CLI:cargo build --release --manifest-path cli/Cargo.toml ./cli/target/release/r-shell --help新增一个 SSH 连接:./cli/target/release/r-shell connections add \ --name prod \ --host 203.0.113.10 \ --username deploy \ --auth publickey \ --key-path ~/.ssh/id_ed25519执行命令:./cli/target/release/r-shell exec -c prod -- uptime启动 MCP:./cli/target/release/r-shell mcp # Conch MCP server listening on http://127.0.0.1:9123/mcp桌面端需要 Flutter 环境:cd desktop flutter pub get flutter run -d macos # macOS flutter run -d windows # Windows如果只是使用,建议直接下预编译包;如果是学习源码,可以从core/开始看,再看cli/和desktop/rust怎么复用它。十一、适合谁我觉得 Conch 适合几类人:运维 / DevOps:想统一管理 SSH 连接、命令执行、文件传输、监控;后端开发者:经常连测试机、发包、拉日志;AI 工具使用者:想让 Cursor / Claude 参与运维,但不想把服务器凭据交给模型;Flutter Rust 桌面开发者:想看一个真实的flutter_rust_bridge桌面项目;Rust 学习者:想看 russh、tokio、clap、MCP、跨平台打包如何落在一个项目里;安卓调试用户:希望把 ADB shell、文件、监控纳入同一个桌面工作台。如果你只想偶尔连一台服务器,系统自带ssh就够了。Conch 更适合「机器多、操作多、希望 GUI / CLI / AI 都能共用同一套连接能力」的场景。写在最后Conch 这个项目给我的最大体会是:一个运维工具真正难的地方,不是「能不能连上 SSH」,而是能不能把连接、凭据、命令、文件、监控、AI 调用和跨平台交付放在一个清晰边界里。Rust 负责把底层能力和安全边界收住,Flutter 负责把日常操作做得顺手,MCP 则让 AI 能在受控范围内参与运维。现在项目已经同步到 GitCode:https://gitcode.com/Roufsi/conch欢迎 star、clone、提 issue,也欢迎直接拿它当 Rust Flutter MCP 桌面工具的源码样例来读。免责声明:本项目仅供学习与合法运维使用。SSH、ADB、命令执行、文件读写都会对目标主机或设备产生实际影响。请只在你拥有合法授权的服务器和设备上使用,重要数据请提前备份。