让 AI Agent 操控没有 API 的老旧桌面应用：AWS WorkSpaces 新玩法

2026-05-13 25 预计阅读时间：1 分钟
来源：infoq.com AI 摘要 原文链接

免责声明：本文为 AI 摘要整理，建议结合原文阅读。摘要可能省略上下文、版本差异或边界条件，不作为官方说明。

预计阅读时间：11 分钟

大量企业核心系统还跑在那些没有 REST API、没有 SDK、甚至连命令行接口都欠奉的桌面应用上。自动化这些系统，过去只能靠 RPA 工具硬点鼠标——脆弱、难维护、一改界面就崩。AWS 刚进入公开预览的一项能力，换了个思路：让 AI Agent 以 IAM 身份登录 Amazon WorkSpaces 虚拟桌面，用计算机视觉"看"屏幕、用输入模拟"操作"界面，绕开 API 缺失的死胡同。

从 RPA 到 Vision Agent：为什么换路

传统 RPA 的本质是坐标录制+像素匹配。窗口位置偏了几个像素、按钮文字改了一个词，流程就断。维护成本随业务变化线性增长，最终很多 RPA 项目不是被技术淘汰，而是被运维拖垮。

AWS 这次的方案把"看懂屏幕"这件事交给多模态大模型：Agent 不再死记硬背像素坐标，而是像人一样理解界面语义——识别出"这是登录按钮""那个是错误提示框"，再决定下一步操作。这意味着界面小幅调整不再必然导致流程失败，容错空间大了不少。

但代价也很直白：看屏幕比调 API 贵得多。Reflex 基准测试给出一个硬数字——Vision Agent 消耗的 token 数量是 API Agent 的 45 倍。每一步操作都要先把屏幕截图喂给模型做视觉理解，再生成操作指令，双倍推理开销叠加，成本曲线陡峭。

IAM 认证 + WorkSpaces：Agent 的身份怎么管

Agent 登录 WorkSpaces 不是靠共享密码，而是走 AWS IAM 体系：

  • IAM Role 绑定到 Agent 运行环境（比如 Lambda、ECS Task），Agent 拿到临时凭证。
  • WorkSpaces 访问策略 控制该 Role 可以连接哪些桌面池、在什么时间窗口内操作。
  • Session 级隔离：每个 Agent 实例获得独立的桌面会话，不会和人类用户抢屏幕。

这比 RPA 常见的"共享一台机器、共用一个 Windows 贚号"安全得多。审计层面，IAM 的每次 AssumeRole 和 WorkSpaces 的每次连接都有 CloudTrail 记录，可追溯。

下面是一个最小化的 IAM 策略，允许 Agent Role 连接指定 WorkSpaces 目录下的桌面：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AgentWorkSpacesAccess",
      "Effect": "Allow",
      "Action": [
        "workspaces:StartWorkspaces",
        "workspaces:StopWorkspaces",
        "workspaces:DescribeWorkspaces",
        "workspaces:DescribeConnectionStatus"
      ],
      "Resource": [
        "arn:aws:workspaces:us-east-1:123456789012:directory/d-1234567890"
      ]
    },
    {
      "Sid": "AgentStreamingAccess",
      "Effect": "Allow",
      "Action": [
        "workspaces:StreamWorkspaces"
      ],
      "Resource": [
        "arn:aws:workspaces:us-east-1:123456789012:workspace/w-abcdef1234"
      ]
    }
  ]
}

部署前把 directory/d-1234567890 和 workspace/w-abcdef1234 替换为你环境中的实际 ARN。StreamWorkspaces 是 Agent 获取桌面视频流的关键权限，目前公开预览中可能需要额外开通白名单。

视觉闭环：Agent 怎么"看"和"动"

整个操作循环可以拆成四步：

  1. 截屏采集——从 WorkSpaces 流中抓取当前桌面帧。
  2. 视觉理解——将截图发送给多模态模型（如 GPT-4o、Claude 3.5 Sonnet），模型返回对界面元素的语义描述和操作建议。
  3. 输入模拟——根据模型输出，在虚拟桌面上模拟键盘输入、鼠标点击、滚动等操作。
  4. 结果验证——再次截屏，确认操作是否生效；如果出现异常弹窗或错误提示，进入异常处理分支。

用一个简化 Python 片段展示这个循环的核心逻辑（假设你已有 WorkSpaces 流接入和截图能力）：

import boto3
import base64
from openai import OpenAI

client = OpenAI()
workspaces = boto3.client("workspaces", region_name="us-east-1")

WS_ID = "w-abcdef1234"

def capture_screen():
    """从 WorkSpaces 流中截取当前桌面帧——实际实现依赖流协议 SDK"""
    # 公开预览中 AWS 尚未发布官方流截屏 SDK，
    # 此处假设你通过 NICE DCV 或第三方桥接拿到 PNG bytes
    with open("current_frame.png", "rb") as f:
        return base64.b64encode(f.read()).decode()

def ask_vision_model(image_b64, task_prompt):
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {
                "role": "user",
                "content": [
                    {"type": "text", "text": task_prompt},
                    {"type": "image_url",
                     "image_url": {"url": f"data:image/png;base64,{image_b64}"}},
                ],
            }
        ],
        max_tokens=512,
    )
    return response.choices[0].message.content

def execute_action(action_desc):
    """将模型输出的操作描述转为桌面输入事件"""
    # 实际实现需要接入 WorkSpaces 输入模拟接口
    # 示例：action_desc = "点击坐标(320, 410)的'提交'按钮"
    print(f"[ACTION] {action_desc}")
    # ... 模拟点击/键盘输入 ...

def run_agent_loop(task: str, max_steps: int = 10):
    for step in range(max_steps):
        img = capture_screen()
        prompt = (
            f"你正在操作一个 Windows 桌面应用。当前任务：{task}\n"
            f"这是当前屏幕截图。请描述你看到的界面，"
            f"并给出下一步操作（点击坐标、输入文字等）。\n"
            f"如果任务已完成，回复 DONE。"
        )
        result = ask_vision_model(img, prompt)
        if "DONE" in result:
            print(f"任务完成，共 {step + 1} 步")
            break
        execute_action(result)

# 示例：让 Agent 在老旧 ERP 里录入一笔订单
run_agent_loop("在 SAP GUI 中创建一笔采购订单，供应商编号 V-10024，金额 5800")

注意：截屏和输入模拟两步目前依赖你自己的桥接实现，AWS 尚未在公开预览中发布完整的 Agent 流 SDK。上面的代码展示的是逻辑骨架，不是可直接运行的成品。实际部署时，NICE DCV 的 SDK 或开源的桌面桥接工具（如 PyAutoGUI 远程模式）可以作为过渡方案。

45 倍 Token 消耗：什么时候值得

45 倍不是一个小数字。拆开看原因：

  • 每一步都要两张图：操作前一张（理解现状）、操作后一张（验证结果），每张图经过视觉编码后占用数千 token。
  • 冗余语义：API 调用 POST /orders {vendor: "V-10024", amount: 5800} 只需几十 token；而视觉 Agent 要先"读"整个屏幕、定位输入框、逐字段填写，每一步的推理链路都更长。
  • 重试成本：界面响应慢或弹窗遮挡时，Agent 需要额外截屏判断，token 消耗进一步膨胀。

所以这个方案不是"API 的替代品"，而是API 不存在时的最后手段。决策框架可以简化为：

场景 推荐路径
目标系统有稳定 API 直接 API Agent，成本最低
有 API 但覆盖不全 API 为主，Vision 补缺口
完全没有 API，界面稳定 RPA 或 Vision Agent，按维护成本选
没有 API，界面经常变 Vision Agent 优先，语义理解比坐标录制更抗变化
没有 API，操作频率极高 先算 token 成本，可能比雇人更贵

一个粗略估算：如果单次任务需要 10 步操作，每步 2 次截屏，每次截屏约 1,500 token（图像编码）+ 500 token（文本推理），单次任务约 40,000 token。按 GPT-4o 当前定价，一次任务约 $0.12——看起来不多，但日跑 1,000 次就是 $120/天，月成本近 $3,600。同等逻辑的 API Agent 可能只要 $80/月。

上手清单

如果你决定在公开预览中试一把，建议按这个顺序推进：

  1. 选一个低频、高痛点的老旧应用作为首个试点——操作次数少，token 成本可控，但人工操作确实烦人。
  2. 创建专用 WorkSpaces 目录，和人类用户的生产桌面隔离，避免 Agent 操作误伤真实数据。
  3. 配置 IAM Role 和策略，最小权限原则，只开放目标 WorkSpaces 的流和操作权限。
  4. 搭建截屏-推理-执行循环，先用开源桥接（DCV SDK / PyAutoGUI）跑通端到端流程，再逐步替换为 AWS 官方 SDK。
  5. 计量 token 消耗，每步记录截屏 token 和推理 token，跑 100 次任务后算真实成本，再决定是否扩大范围。
  6. 设置异常兜底——Agent 连续 3 步未通过验证时，暂停任务并通知人类介入，避免无限重试烧 token。

这项能力解决的是一个真实痛点：大量遗留系统短期内不会获得 API，但业务又需要自动化。Vision Agent 不是最优解，却是当前唯一能语义级操控无 API 桌面应用的路径。关键在于——只在 API 确实不存在的地方用它，并且始终盯着 token 账单。

相关推荐