我最近反复被同一种感觉卡住：AI 已经把问题分析到最后一步了，但真正落地时，我还是得自己去 SSH。
场景其实很普通。
本地仓库里，AI 已经把问题看得很清楚了。它知道哪里可能有 bug，知道接下来该查什么，甚至连命令都能直接给出来。可只要真正的程序不是跑在本地，而是跑在开发板、测试机、远程 Linux 主机或者 GPU 服务器上，整个流程就会突然掉回老时代。
我还是得自己切到 SSH，自己找那条会话，自己敲命令，自己盯输出，再把结果带回聊天窗口。
别扭的地方不在于“多敲了几条命令”，而在于上下文断了。本地对话已经推进到最后一步了，真正落地那一刻，却还是得我来做人肉中转。
项目主站：
https://zw-awa.github.io/ssh-session-mcp
远程开发真正难的，不是“发出一条命令”
如果只是把一条命令送到远端，其实从来都不缺办法。
真正麻烦的是，远端终端不是一个“发请求、等结果”的干净接口，它是一个一直在变化的现场。
它上一秒可能还在正常 shell 提示符，下一秒就可能停在密码输入、less、vim，或者某条还没跑完的长任务里。于是问题常常不是“命令对不对”，而是“命令被发到了哪里”。
这也是为什么很多看起来很顺的远程方案，一到真实环境就开始别扭。它们解决了“把命令送过去”这一步，却把最难处理的那部分状态，留给了用户自己兜底。
更现实的一点是，人并不会退出现场
我后来越来越不认同一种默认前提：只要 AI 足够能干，用户最好不要碰终端。
真实开发根本不是这样。
更常见的情况其实是：
- AI 先查一轮环境
- 我自己补一两条命令
- 再把控制权交回去
有时候是因为我更快，有时候是因为我更确定，有时候只是因为终端已经进入一个很怪的状态，我不想再让它盲打一条新输入。
所以我要的，从来都不是“让 AI 代替我拥有远端终端”，而是“让 AI 和我站在同一个现场里协作”。
我后来换了一个想法
我不再把 SSH 想成一个“命令执行通道”，而是把它想成“一条应该被共享的 PTY”。
ssh-session-mcp 就是顺着这个想法做出来的。
它保留一条真实的 SSH PTY 会话，然后让两边都围着这同一条会话工作：
- AI 通过 MCP tools 操作
- 人通过浏览器 viewer 观察和接管
这里最关键的点，不是“有两个入口”，而是“它们背后是同一条终端”。
只要这个前提成立，很多原本看起来零碎的能力就都会变得很自然。人和 AI 都可能输入，所以需要输入锁；终端状态不能乱碰，所以需要更谨慎的执行模式；命令有长有短，所以需要异步状态跟踪；共享终端不能变成黑盒，所以需要历史和诊断。
这些不是为了凑功能，而是这套模型推出来的结果。
它真正补上的，其实只有一层
我一直觉得，今天很多 AI 编码工具最大的短板不是“不够聪明”，而是它们在本地和远端之间，缺一层像样的运行时。
本地代码上下文，它们已经很强了。
可一到远端终端这边，很多时候还是靠人把分析结果搬过去，再把现场结果搬回来。
ssh-session-mcp 想补上的，就是中间这一层。
不是再做一个 SSH 客户端，不是再包一层命令执行接口，而是让远端终端不再是 AI 视野之外的手工地带。
我最希望成立的一条主链路其实很简单：
ssh-quick-connect -> ssh-run -> inspect -> ssh-command-status if async -> ssh-run
重点不在工具名，而在于这条链路终于能围绕同一条远端终端闭环。
一旦这一点成立，远程工作的手感会很不一样。以前很多时候，我明明已经和 AI 把问题分析到最后一步了，却还是要自己把最后一公里手动跑完。本地对话很现代，远端执行却还停留在传统时代。
而共享同一条终端之后，至少有一件事开始变得一致：分析、执行、观察、接管，不再散落在四五个彼此割裂的窗口和上下文里。
我为什么没有把它继续做大
我对这个项目最警惕的一件事，就是把它做成“大而全平台”。
因为一旦开始把板卡逻辑、ROS 流程、项目专有自动化、prompt 编排这些东西全塞进来，最后最先被稀释掉的，反而是最底层这条共享终端能力。
所以我宁可把边界收得很死。
这个项目主要关心的，就是 SSH 这一层运行时本身：会话怎么保留，人和 AI 怎么共享，谁什么时候该输入，长任务怎么继续跟踪，当前终端到底处在什么状态。
我希望它先把这一层做扎实，再去谈更上面的组合。
最后
我后来越来越确定，AI 进入远程开发现场，关键不是“它会不会再多生成一条 shell 命令”，而是它能不能和我共享同一条真实终端。
如果这件事做不到，很多远程协作都会停留在“AI 给建议，我去执行”的阶段。
如果这件事做到了，远端环境才算真的被接进来。
如果你也常在开发板、远程 Linux、服务器、测试机这些环境里切来切去，应该很容易理解这种割裂感。
如果这个方向对你有帮助，也欢迎帮项目点一个免费的 star。对这种还在持续打磨中的开源项目来说，star 至少能告诉我：这条路不是我一个人在意，也确实有人需要。
但如果你已经试过，或者你有非常具体的使用场景，我其实更希望你直接提 issue。对我来说，下面这些信息会比一句“不错”有用得多：
- 你在连什么环境
- 你希望 AI 和人怎么接管
- 你遇到的卡点发生在哪一段链路里
- 你觉得现在还缺哪种能力或保护
GitHub：
https://github.com/Zw-awa/ssh-session-mcp
Gitee：
https://gitee.com/Zw-awa/ssh-session-mcp
