突破 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 网络级别的物理切割。

架构设计

• Bridge Server (物理桌面端)：一个长期潜伏在 Session 3 的 Node 监听器。它不直接处理 SSH 流量，而是监听本地的一个 TCP 端口（如 8333）。当接收到连接时，动态 Spawn 拉起真正的 MCP 引擎，并将 stdin/stdout 重定向到该 TCP Socket。
• Bridge Client (SSH 接入端)：大模型通过 SSH 触发的不再是 MCP 主程序，而是一个极其干净的 TCP 透传脚本。它的唯一作用是连接本地的 8333 端口，并将数据原封不动地交还给 SSH 的 stdio。

由于 Client 没有任何多余的输出，TCP 又无损搬运了 Session 3 里的 MCP JSON-RPC 流，因此大模型客户端能稳定解析，且截图 API 也能顺利拿到前台真实的桌面画面。

核心部署代码

1. 部署 Bridge Server 并实现物理环境常驻

编写 mcp-bridge-server.js，部署在目标机的 D:\program\mcp-bridge\ 目录下：

const net = require('net');
const { spawn } = require('child_process');

const server = net.createServer((socket) => {
    // 有请求接入时，动态启动真实的 mcp server
    const child = spawn('cmd.exe', ['/c', 'npx', '-y', '@zavora-ai/computer-use-mcp'], { stdio: ['pipe', 'pipe', 'inherit'] });
    socket.pipe(child.stdin);
    child.stdout.pipe(socket);
    
    socket.on('error', () => child.kill());
    socket.on('close', () => child.kill());
    child.on('error', () => socket.destroy());
    child.on('exit', () => socket.destroy());
});
server.listen(8333, '127.0.0.1');

为了实现开机后自动在用户的物理桌面会话（Session 3）运行，向用户的启动目录注入 VBS 脚本：

$vbsPath = "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\StartMCPBridge.vbs"
$vbsContent = "Set WshShell = CreateObject(""WScript.Shell"")`r`nWshShell.Run ""node D:\program\mcp-bridge\mcp-bridge-server.js"", 0, False"
Set-Content -Path $vbsPath -Value $vbsContent -Encoding UTF8

2. 部署 Bridge Client (极简透传)

编写 mcp-bridge-client.js，同样放在该目录下：

const net = require('net');
const socket = new net.Socket();
socket.connect(8333, '127.0.0.1', () => {
    process.stdin.pipe(socket);
    socket.pipe(process.stdout);
});
socket.on('error', () => process.exit(1));
socket.on('close', () => process.exit(0));

3. 本地大模型客户端挂载 (以 Hermes/Claude 为例)

在大模型的配置文件中，直接让 SSH 运行 Client 脚本：

mcp_servers:
  windows-desktop:
    command: ssh
    args:
      - laptop-win  # 你的 SSH 别名
      - node
      - D:\program\mcp-bridge\mcp-bridge-client.js

扩展进阶：基于 UIA (UIAutomation) 的无视觉探针侦察

打通了无损的 TCP 桥接之后，不仅解决了“看”（截图）和“动”（物理键鼠）的问题，我们同时解锁了 Windows 最强大的超能力——底层无障碍树 (UIAutomation/AXTree) 深度透视。

在极其复杂的远端无人值守操作中，纯靠视觉坐标点击或者模拟快捷键（如盲按 Alt+Tab 或 Ctrl+C）容易陷入“焦点陷阱”（例如键盘焦点被后台聊天软件抢走，或者多设备的跨平台共享剪贴板将数据覆盖干扰）。

引入无障碍 API 作为侦察手段，是提升 RPA 鲁棒性的关键：

1. 精准定位真实焦点 (get_focused_element)：
   无需截图识别，直接调用底层探针接口，Windows 会立刻告诉你目前正在响应键盘的到底是个什么控件。
   实战案例：在 Chrome 中，焦点控件的 role 往往是 AXWebArea，而且它的 value 属性中直接包含了当前正在浏览的网页 URL！这意味着大模型完全不需要去模拟复制和读取剪贴板，一发接口调用就能拿到网址。

2. 跨遮挡窗口管理 (list_windows & activate_window)：
   直接读取系统运行的所有窗口句柄。如果目标程序被其他程序死死盖住，无需费劲找坐标点击，直接利用窗口 ID 强制置顶激活，然后再下发快捷键。

在自动化交互中，遵循 “先侦察（UIA / UI Tree），后动作（Mouse / Keyboard）” 的闭环，能极大提升基于 SSH 操控 GUI 的稳定性和容错率。

总结

通过这套轻量级的桥接方案，我们在 0 额外 GUI 占用的前提下，完美解决了困扰大量开发者的 Windows SSH 黑屏与协议污染难题。现在，你可以像控制本地 Mac 一样，直接用自然语言让大模型远程分析远端 Windows 的系统屏幕，甚至通过 MCP 灵活操控它的鼠标和键盘。