突破 Windows OpenSSH Session 0 隔离：大模型 MCP 视觉接管的 TCP Bridge 桥接方案

在当前 AI 桌面自动化（Computer Use / RPA）以及大模型 MCP（Model Context Protocol）生态中，许多开发者尝试通过 OpenSSH 连接远端 Windows 物理机来实现原生的 GUI 控制。然而，这条技术路线往往会撞上微软底层的两座大山。

痛点分析：为什么 Windows SSH 跑不通 GUI 控制？

当大模型试图通过 OpenSSH（基于 stdio 通信）连接远端 Windows 执行视觉自动化时，会遇到两个难以逾越的系统级障碍：

1. 黑屏屏障 (Session 0 隔离)

Windows 的 OpenSSH Server 默认以系统服务的形式运行在 Session 0。Session 0 没有任何物理显示输出，是一个隔离的后台环境。
在这个环境里直接调用任何屏幕捕获 API（如截图工具），返回的永远是一张纯黑的图像。同时，程序也无法对当前用户互动的物理桌面（如 Session 3）进行鼠标点击。

2. stdio 协议污染 (JSON-RPC 崩溃)

传统的破局思路是利用 Sysinternals 的 PsExec -i 3 将进程强行穿透、注入到物理桌面会话。
但在 MCP 时代，这个方法失效了。因为 MCP 协议依赖极其纯净的 stdio JSON-RPC 数据流。而 PsExec 每次执行，都会强制在标准流（stdout）中打印一行横幅版权信息（如 PsExec v2.43 - Execute processes remotely...）。
这些多余的字符混入数据流，会直接导致远端的大模型客户端（如 Claude Desktop、Hermes）JSON 解析崩溃，连接中断。

优雅破局：TCP Bridge 解耦架构

既要穿透到 Session 3，又要保持 SSH stdio 数据流的一尘不染，最完美的方案是将“服务端”与“标准流交互端”进行 TCP 网络级别的物理切割。