我受够了左手本地 AI、右手 SSH 终端的割裂感，于是做了个开源项目：ssh-session-mcp

Zwawa
0 阅读4分钟

我受够了左手本地 AI、右手 SSH 终端的割裂感，于是做了个开源项目：ssh-session-mcp

如果你最近也在用 Claude、Codex、Cursor 这类工具写代码，应该很容易遇到一种很别扭的状态：

本地项目里，AI 已经快成“副驾驶”了。

可一旦问题落到远程环境上，比如开发板、GPU 服务器、测试机、宿主机，你又会立刻退回到最原始的工作模式：

  1. 自己切 SSH
  2. 自己敲命令
  3. 自己看输出
  4. 再把结果转述给 AI

这种感觉特别像什么？

像你已经开上了带自动驾驶的车，但每到一个路口都得下车手动推过去。

我最近做的开源项目 ssh-session-mcp，就是想把这段断掉的路补上。

先说我最烦的几个瞬间

1. AI 已经定位到问题了，最后一步还得我“人工执行”

比如它已经判断：

  1. 服务没起来
  2. 需要重启
  3. 需要补看最近 200 行日志

但真正的：

systemctl restart xxx
journalctl -u xxx -n 200

还是得我切到另一个 SSH 窗口去敲。

这一步不仅费手，还费脑子，因为上下文已经断了。

2. 远端终端状态是黑盒

现在终端到底在：

  1. shell 提示符
  2. less
  3. 密码输入
  4. 编辑器
  5. 长任务运行中

很多 AI 工具其实并不清楚。

于是就会出现一种很蠢的情况：

你以为它在执行命令，实际上它是在往密码框里打字。

3. 人和 AI 容易抢终端

我自己很不喜欢“AI 独占终端，用户只能围观”的做法。

真实开发里，很多时候就是我先让 AI 跑一轮，再自己补一条命令，确认没问题后再交回去。

问题是如果没有明确的锁和状态提示，这个过程就会变成互相踩。

4. 多目标机器太容易串

板卡 A、板卡 B、测试机、容器宿主机、线上复现机。

如果没有清晰的设备 profile 和活动会话管理，命令发错机器这件事，迟早会发生。

Snipaste_2026-04-21_22-12-42.png

所以我做了什么

ssh-session-mcp 的核心思路其实很简单：

把 SSH 从“手工操作终端”升级成“AI 和开发者都能接入的共享运行时”。

它不是要替换 SSH，而是把 SSH 这段能力做成 MCP 友好的形态。

项目当前已经有这些能力：

  1. 共享 SSH PTY 用户和 AI 共用同一个终端，不是各开各的。

  2. 浏览器终端 用户可以直接看 AI 在远端做了什么，也可以自己随时接手输入。

  3. 输入锁 支持 common、user、claude/codex 模式，避免双方同时操作。

  4. 安全模式 默认 safe 模式拦危险命令、交互式程序和流式命令，必要时再切 full。

  5. 智能完成判定 ssh-run 结合 prompt、idle timeout、sentinel 判断命令是否结束，不是靠拍脑袋等超时。

  6. 异步长任务 长命令自动转异步，后面用 ssh-command-status 查。

  7. 行级历史和会话诊断 这样用户和 AI 都不会在一个完全黑盒的终端上瞎试。

  8. 多设备配置 可以用 ssh-session-mcp.config.json 管多台设备、多条连接。

Snipaste_2026-04-21_22-16-35.png

我最在意的一点：用户不能被排除在终端外

现在很多“AI 操作系统”式的产品思路都很激进，恨不得把用户变成审批器。

但我自己做项目时越来越确定一件事：

远程终端这件事，必须保留人工接管能力。

原因很现实：

  1. 真正危险的命令，人应该能拦
  2. 某些交互式操作，人必须能接
  3. 排障时，人要看见完整现场
  4. 有些时候就是自己敲一条更快

所以我做这个项目时，不是想让 AI 彻底替代终端，而是想让终端从“AI 盲区”变成“人机协作区”。

一个很典型的使用流

安装：

npm install -g ssh-session-mcp

启动：

npm run launch

AI 常见调用链路：

ssh-quick-connect -> ssh-run -> 读取输出 -> 决策 -> ssh-run

如果是长任务：

ssh-run({ command: "apt update" })
-> async commandId

ssh-command-status({ commandId: "..." })

如果用户想自己动手，直接在浏览器终端里敲，不需要把会话重建一遍。

这个项目适合谁

我觉得最适合三类人：

  1. 嵌入式和板卡开发者
  2. 经常在远程 Linux 环境里开发的人
  3. 已经在用 AI 写代码，但总觉得一到 SSH 场景就开始掉线的人

如果你日常开发几乎完全本地，那这个项目未必是刚需。

但如果你经常面对“本地 AI 很顺，远端调试很碎”的问题，它大概率能让工作流顺很多。

最后

这个项目已经开源，仓库在这里：

https://github.com/Zw-awa/ssh-session-mcp

我不打算把它吹成什么“下一代基础设施平台”，它现在更像一块正在认真打磨的底层拼图。

不过我确实觉得，这块拼图很值得补。

因为只要远程开发还是常态，AI 和 SSH 之间这段断层，迟早会有人要认真填上。

我先动手了。

avatar
文章
阅读
粉丝