日常查库、看服务器、传文件、拉日志，大概率是这么过来的：DBeaver 连 MySQL，终端开 SSH，再开一个 FileZilla 传包，偶尔还要用 RDP 连 Windows。几个工具来回切，连接信息散落在各个 App 里，排查一个问题要在三个窗口间复制粘贴输出。navop 想解决的就是这个场景——把真实连接、查询结果、命令输出放在同一个界面里，别让上下文断掉。
是什么 / 技术栈
navop 是一个原生桌面工作台，Rust + GPUI 构建，不依赖 WebView，GPU 加速渲染。当前是开源测试版，代码在 GitHub：https://github.com/feigeCode/navop。
功能面上覆盖数据库、SSH/SFTP、远程桌面、AI 协作和 Agent Hub，定位是"面向 AI 时代的开发/运维入口"。
功能拆解
数据库
支持 MySQL、PostgreSQL、SQLite、DuckDB、SQL Server、Oracle、ClickHouse，另外带独立的 Redis 工作台和 MongoDB Explorer。功能包括对象浏览、SQL 编辑、执行计划、导入导出、Schema/Data 比较和 ER 图。
覆盖面比大部分开源数据库客户端要广，特别是 DuckDB 和 ClickHouse 直接纳入支持列表，对偏 OLAP 场景的人很友好。
远程连接
SSH、终端分屏、广播输入、SFTP、远程文件编辑、端口转发、串口都有，RDP/VNC 属于扩展支持。
终端分屏和广播输入这两个功能，实际用起来适合批量操作：比如同时给多台机器发送同样的命令，或者分屏同时看应用日志和数据库执行状态。SFTP 可以直接在界面里拖文件，不用再单独开一个传输工具。
AI 相关
SQL 生成与解释、数据分析、终端助手、Agent Hub（项目文件树、Git 变更、终端串联），支持 MCP/CLI 接入外部 Agent。
对 AI 这块的判断：SQL 生成与解释这类功能实用性较强，日常写查询、分析线上问题时能省一些上下文切换成本。Agent Hub 的能力上限取决于外部 Agent 的接入质量，不建议期望它解决复杂运维问题。
部署与构建
GitHub Releases 提供 macOS / Linux / Windows 三平台包。Linux 有 .deb、.rpm、.AppImage 和压缩包；Windows 有便携版。
源码构建命令：
./script/bootstrap
cargo run -p main
一个已知的坑：Oracle 场景可能需要 Oracle Instant Client，或者换成纯 Go 驱动。没有装 Oracle 相关依赖的人，建议直接从 Release 拉包，别自己从源码编。
架构
前端是原生桌面界面（Rust + GPUI），后端是能力接入层：数据库驱动、SSH/SFTP、远程桌面、扩展市场、MCP/CLI Agent。
这种分层的好处是：UI 层和连接层解耦，以后加新的数据库类型或远程协议，不需要动界面层。不依赖 WebView 也意味着它在渲染大量输出数据时的性能会更稳，但实际感知多大，建议自己跑一次大数据量查询对比。
协议与合规
主代码是 Apache 2.0，但另有 Navop Supplementary License，对转售、竞争性产品、未经授权分发有限制。
如果只是团队内部使用，影响不大；但如果想基于它做二次集成、商用分发，需要先过一遍补充协议。建议不要只看 Apache 2.0 就认为完全自由，细节需要自行确认。
适合谁 / 不适合谁
适合试的：
- 本地多环境开发，日常在 MySQL、PostgreSQL、SQLite 之间切换
- 运维排查时要同时看库、连服务器、翻日志，窗口切换频繁
- 想减少工具数量，把 SSH/SFTP/查库收进一个原生桌面应用
不建议现在用的：
- 生产环境核心操作——这是刚推出的新项目，开源测试版不等于稳定商业版，建议先在测试环境跑一段
- 重度依赖 RDP/VNC 的日常运维，扩展支持毕竟不是主功能
- 团队已经有一套成熟的查库 + 远程工具链，迁移成本大于收益
提前看这些坑：
- Oracle 驱动依赖 Oracle Instant Client，折腾成本不低
- 补充协议有附加限制，商用前务必过一遍
- 新项目迭代快，版本兼容和接口变动需要自己跟进
总结
navop 的设计思路是"连接、输出、上下文都留在一个界面"，这个方向对开发者和运维都成立。目前功能覆盖广、原生性能好，但项目尚早，稳定性、生态成熟度、协议边界都要自己评估。适合有真实痛点的人拉下来试试，不适合拿来替换生产关键链路。