用 rdp-cli 为 Agent 接入远程桌面

AI Agent 能写代码、调 API，却未必能操作那些只有图形界面的软件。rdp-cli 给出了一条路径：通过命令行连接远程桌面，让 Agent 看截图、点击、输入，再用截图检查结果。

它的价值是把现有桌面应用接入 Agent 的工作流程，减少逐个开发 API 集成的需求。不过，原文展示的是操作教程，没有给出成功率或复杂任务的实测数据。对程序员而言，最值得借鉴的是执行与验证如何衔接。

Agent 操作桌面，关键是每一步都能回看

rdp-cli 支持控制 RDP 和 VNC 桌面，原文具体演示的是 Windows RDP 会话。视频编辑、检查表格、操作旧版 Windows 软件和 Android 手机被列为应用场景，但没有逐项展示完成过程。

它的基本循环是：

Connect → Screenshot → Act → Screenshot → Verify

这里的观察、行动、再观察（observe → act → observe），可以理解为：先确认界面在哪里，执行一次操作，再检查界面是否真的发生了预期变化。

命令执行结束，不等于界面任务已经完成。

例如，点击输入框后先截图确认焦点，再输入文字，最后检查结果。这样至少能避免 Agent 连续执行一串动作后，才发现第一步就点错了。

不过，截图只是提供证据。按钮有没有点对、文本有没有写进正确位置，仍然需要 Agent 判断，rdp-cli 不会替模型完成这些理解工作。

从连接到输入，命令里有哪些关键细节

原文提供 Linux x86_64 可执行文件，下载后运行 chmod u+x ./rdp-cli-linux-x86_64，再通过 ./rdp-cli-linux-x86_64 --help 查看帮助。作者称不需要额外运行时或管理员权限；Windows 和 macOS 的安装细节没有在正文展开。

连接前，需要在目标电脑启用 RDP。下面这段命令解决的是如何传入凭据，避免直接把密码写进命令参数：

IFS= read -r -s -p 'Password: ' rdp_password
printf '\n'
printf '%s' "$rdp_password" | \
  ./rdp-cli-linux-x86_64 connect \
  --host 192.0.2.20 \
  --user USER \
  --password-stdin

unset rdp_password

重点是 --password-stdin，它从标准输入接收密码；最后用 unset rdp_password 清理变量。连接命令返回会话标识，后续以 SESSION 代指。

行动前，先执行 ./rdp-cli-linux-x86_64 screenshot --session SESSION --out ./before.png。Agent 查看 before.png，定位输入框的坐标 X, Y，再进入下面的操作过程：

./rdp-cli-linux-x86_64 click \
  --session SESSION \
  --desktop \
  --x X \
  --y Y \
  --observation OBSERVATION

./rdp-cli-linux-x86_64 screenshot \
  --session SESSION \
  --out ./focused.png

./rdp-cli-linux-x86_64 type \
  --session SESSION \
  --text "Remote task completed." \
  --observation NEW_OBSERVATION

./rdp-cli-linux-x86_64 screenshot \
  --session SESSION \
  --out ./after.png

重点看两次 --observation：点击使用 OBSERVATION，输入使用 NEW_OBSERVATION。原文没有解释这些值怎样取得，也没有说明它们与截图之间的具体关联，因此这段示例还不足以直接拼出完整的 Agent 集成。

人工介入也有入口：运行 ./rdp-cli-linux-x86_64 watch --session SESSION --viewer window，可以打开同一会话。原文称也支持浏览器查看，查看器默认只读，并支持暂停 Agent 输入、人工接管和交还控制，但没有给出浏览器入口的具体命令。

我的判断

我认同它把截图检查放进操作循环的做法。对于缺少 API 的桌面软件，这种接入方式有实际价值，人也能在必要时接管。

但这是一份能力演示，还不是可靠性证明。作者没有提供真实任务耗时、失败率、连续操作成功率，也没有与人工操作或其他自动化方案做对照。不能据此判断它已经适合无人值守地处理复杂业务。

对前端和全栈开发者，选择工具仍要看操作对象。网页任务可以考虑基于 DOM 和元素定位的浏览器自动化；已有 API 的业务，可以直接调用接口。rdp-cli 更适合需要跨越远程桌面、旧软件和纯图形界面的场景。

坐标点击还依赖当前界面状态。窗口移动、布局变化后，之前的位置可能失效。这是该工作方式需要考虑的限制，原文没有展示相应的恢复策略。生产连接方面，作者也明确要求使用获授权的电脑和可信网络，并检查连接与证书设置，但没有展开配置细节。

能拿来做什么

• 给缺少 API 的远程桌面任务做小范围验证，先选「定位输入框、输入文本、检查结果」这样的短流程，确认观察与操作能衔接。
• 用 Node 编排命令时，把截图检查安排在每次关键操作之间，并先补齐 --observation 的生成和传递方式。
• 为需要人工复核的任务保留 watch 接管入口，先确认暂停、接管和交还控制的过程，再尝试更长的操作链。