Computer-Use Agent实战：从截屏到点击的完整实现与避坑指南

1. 从“cua”这个标题说起：一个被低估的缩写背后藏着什么

第一次看到“cua”这个标题，我脑子里蹦出来的第一反应是——这大概率又是一个被缩写玩坏了的项目名。做技术的人都有这个毛病，喜欢把长名字砍成三四个字母，方便在命令行里敲、在聊天里传。但“cua”这个组合有点意思，它不像“api”“sdk”那样有明确的行业共识，也不像“cli”“gui”那样一眼能看出指向。它更像是一个内部代号，或者某个特定圈子里约定俗成的叫法。

我后来花了不少时间去琢磨这个标题可能指向什么。结合当下技术社区里高频出现的一些讨论方向，我倾向于认为“cua”最可能指向的是Computer-Use Agent，也就是“计算机使用代理”这一类技术。这个方向最近一年在自动化圈子里热度很高，核心思路是让一个智能体像人一样去操作电脑——看屏幕、点鼠标、敲键盘、切换窗口，完成那些没有开放接口、只能靠图形界面交互的任务。为什么这个方向会火？因为现实世界里大量的软件根本没有API，尤其是那些企业内部的老系统、桌面端的专业工具、还有一些只提供网页界面的服务平台。你想自动化它们，传统脚本要么做不到，要么维护成本高得离谱。而“让AI直接看屏幕操作”这个思路，恰好绕开了接口缺失这个死结。

当然，我也得承认，“cua”也可能指向别的东西。比如在某些语境下它可能是“Common User Access”的缩写，这是早期图形界面设计规范里的一套术语；也可能只是某个小项目的随机命名。但既然要写一篇有参考价值的博文，我选择沿着“Computer-Use Agent”这条线往下拆，因为这个方向目前确实有大量实操层面的问题值得聊，而且网上能搜到的系统性的、带踩坑经验的内容并不多。如果你正好在关注这个领域，或者手头有类似的需求，那接下来的内容应该能帮你省下不少试错的时间。

这篇文章适合谁看？如果你是做自动化测试的、搞RPA的、或者单纯对“让AI操作电脑”这件事好奇的开发者，那都能从中找到能直接抄作业的东西。我会从整体设计思路讲到具体实现细节，再到实际跑起来会遇到哪些坑，尽量把每个环节的“为什么”说清楚。毕竟这类项目最怕的就是照猫画虎，环境稍微一变就全盘崩溃，不理解背后的逻辑根本没法排查。

2. 整体设计思路拆解：为什么是“看屏幕操作”而不是“调接口”

2.1 核心矛盾：接口缺失与自动化需求的碰撞

做自动化的人迟早会撞上一堵墙：你想自动化的那个东西，它没有API。这不是技术倒退，而是现实世界的常态。一个跑了十年的内部审批系统，开发商早就联系不上了，你不可能让它开放接口；一个桌面端的图像处理软件，它的批处理功能只覆盖了百分之三十的操作，剩下的还得手动点；一个只提供网页界面的数据查询平台，它甚至没有导出按钮，你只能一页一页地看、一条一条地抄。这些场景下，传统自动化的三板斧——调接口、改数据库、写脚本模拟请求——全都使不上劲。

这时候“Computer-Use Agent”的思路就显出价值了。它的逻辑很朴素：既然人能看着屏幕操作，那让程序也这么做不就行了？具体来说，就是截取屏幕画面，用视觉模型理解当前界面上有什么元素、它们在哪、是什么状态，然后决定下一步该点哪里、输入什么内容，最后通过模拟鼠标键盘事件来执行。整个过程不依赖目标软件提供任何接口，只要它能显示在屏幕上、能接受鼠标键盘输入，理论上就能被自动化。

这个思路的优势很明显：通用性强。不管你是Windows上的老软件、macOS上的专业工具、还是浏览器里的网页应用，只要视觉模型能看懂，操作逻辑就是一致的。但劣势也同样明显：慢、脆、贵。截屏和推理都需要时间，界面稍微一变模型就可能懵，而且每次操作都要调用视觉模型，成本比调接口高出一个数量级。所以这类方案从来不是用来替代API自动化的，它是在API缺失时的最后手段，是“实在没办法了才用”的那一类工具。

2.2 方案选型：视觉模型、坐标映射与动作执行的三层架构

一个典型的Computer-Use Agent系统可以拆成三层。最上面是感知层，负责把屏幕上的像素变成结构化的信息。这里的选择很多，可以用纯视觉模型直接输出“屏幕描述+可操作元素列表”，也可以用OCR先提取文字再结合目标检测找按钮，还可以用无障碍树来辅助定位。纯视觉方案最通用，但精度和速度都受模型能力限制；混合方案精度更高，但实现复杂度也上去了。

中间是决策层，也就是“大脑”。它接收感知层传来的界面信息，结合任务目标，决定下一步动作。这里通常是一个大语言模型或者多模态模型在驱动，输入是“当前屏幕状态+历史操作+任务描述”，输出是“点击坐标(x,y)”或者“在某个输入框里键入某段文字”。决策层的难点在于长程规划——一个任务可能需要几十步操作，模型得记住之前做了什么、当前处于哪个阶段、下一步该往哪走。上下文窗口有限的情况下，怎么压缩历史信息、怎么维护任务状态，都是需要仔细设计的。

最下面是执行层，负责把决策层的指令变成真实的鼠标键盘事件。这层看起来简单，实际上坑很多。不同操作系统的输入事件模拟方式不一样，有些应用会检测输入来源、拒绝非物理设备的操作，还有些应用对点击的响应区域有特殊要求。执行层还需要处理时序问题——点击之后要等界面响应，输入文字之后要等输入框更新，这些等待时间设短了会出错，设长了效率又低。

三层之间的接口设计也很关键。感知层输出的坐标是屏幕绝对坐标还是相对于某个窗口的坐标？决策层输出的动作是原子操作（点击、输入、滚动）还是复合操作（“在搜索框输入关键词并回车”）？执行层执行完动作后怎么反馈结果给决策层？这些细节在项目初期就得想清楚，不然后面改起来牵一发动全身。

2.3 为什么不用传统的UI自动化框架

有人可能会问：Windows有UIAutomation，macOS有Accessibility API，Linux有AT-SPI，这些框架都能获取界面元素、模拟操作，为什么还要搞视觉方案？答案在于覆盖率和稳定性。这些无障碍接口确实好用，但前提是目标应用实现了它们。很多老软件、游戏、自绘界面的应用根本没有暴露无障碍信息，或者暴露的信息残缺不全。而且不同平台的无障碍接口差异很大，写一套跨平台的自动化代码要处理大量平台特定的逻辑。

视觉方案的好处是“所见即所得”。不管底层是什么技术实现的界面，只要它画在屏幕上，视觉模型就能看到。这省去了适配各种UI框架的麻烦，代价是精度和速度的下降。在实际项目中，我通常会采用混合策略：优先尝试无障碍接口，拿不到信息再回退到视觉方案。这样既能保证常见场景的效率，又能覆盖那些“硬骨头”。

3. 核心细节解析与实操要点：从截屏到点击的完整链路

3.1 屏幕捕获：频率、区域与压缩的权衡

截屏是整个链路的第一步，也是最容易被低估的一步。很多人觉得截屏就是调个系统API拿一张图，能有什么讲究？实际上截屏的频率、区域和压缩方式直接决定了整个系统的响应速度和资源占用。

先说频率。理想情况下，每次决策前截一张图就够了，但问题是决策本身需要时间——视觉模型推理可能要几百毫秒到几秒。如果在这段时间里界面发生了变化（比如加载动画结束了、弹窗出现了），那基于旧截图做出的决策就会出错。所以实际系统中通常需要持续截屏，维护一个“最新帧”的缓冲区，决策时取最近的一帧。截屏频率设多少合适？我的经验是10到15帧每秒足够，再高就是浪费CPU和内存，再低可能错过界面变化的瞬间。

区域选择也很重要。全屏截图的像素量很大，4K屏幕上一次截屏就是八百多万像素，传给视觉模型既慢又贵。实际使用中，我通常会根据任务类型限定截屏区域。比如操作浏览器时只截浏览器窗口，操作某个对话框时只截对话框区域。这样可以大幅减少数据量，同时避免界面其他部分的干扰。获取窗口位置可以用系统API，也可以让用户手动框选，后者更简单但不够灵活。

压缩方面，PNG是无损的但体积大，JPEG体积小但有压缩伪影可能影响模型识别。我的做法是先用PNG截取，然后在内存里转成JPEG（质量设85左右），这样兼顾了清晰度和传输效率。如果视觉模型支持直接输入图片字节流，就省去了存盘的步骤，速度更快。

注意：有些系统在截屏时会触发安全机制，比如某些视频播放器或金融类应用会检测截屏行为并黑屏处理。遇到这种情况，视觉方案基本无解，只能考虑其他途径。

3.2 界面理解：视觉模型选型与提示词设计

界面理解是决定整个系统上限的环节。模型选得好不好、提示词写得对不对，直接影响到能不能准确找到按钮、能不能理解界面状态。

模型选型上，目前可用的方案大致分两类：通用多模态大模型和专门针对GUI场景微调的模型。通用模型的好处是泛化能力强，没见过界面也能大致理解；缺点是精度不够，经常把坐标定位偏几十个像素，或者把相似的元素搞混。专门微调的模型在常见界面元素上精度更高，但遇到没见过的界面类型就容易抓瞎。我的建议是：如果任务涉及的界面类型比较固定，优先考虑微调模型；如果界面变化多端，通用模型更稳妥。实际项目中也可以两者结合，通用模型做粗定位，微调模型做精定位。

提示词设计是另一个关键点。很多人直接把截图丢给模型说“帮我点登录按钮”，然后抱怨模型找不到。问题出在提示词太模糊。好的提示词应该包含几个要素：当前任务目标、界面元素的描述规范、输出格式要求。比如可以这样写：“你是一个界面操作助手。当前任务是登录系统。请分析截图，找到用户名输入框、密码输入框和登录按钮，输出它们的中心坐标，格式为JSON：{‘username’: [x,y], ‘password’: [x,y], ‘login’: [x,y]}。如果某个元素不存在，对应值设为null。”这样模型输出的结果就是结构化的、可直接使用的坐标，省去了后处理解析的麻烦。

还有一个技巧是让模型输出“思考过程”。比如要求它先描述看到了什么，再判断每个元素的位置，最后给出坐标。这样虽然会增加输出长度和推理时间，但准确率通常能提升不少。因为模型在描述的过程中相当于做了一次自我校验，不容易出现“一眼看过去就瞎猜坐标”的情况。

3.3 动作执行：坐标映射、输入模拟与等待策略

拿到坐标之后，下一步就是把它变成真实的鼠标点击。这里第一个坑是坐标映射。视觉模型输出的坐标通常是相对于它收到的图片的，而图片可能是缩放过的、裁剪过的。你需要把这些坐标还原到屏幕的绝对坐标系。如果截屏时做了区域裁剪，还要加上裁剪区域的偏移量。如果图片被缩放了，要乘以缩放比例。这些计算不难，但很容易漏掉某一步导致点击位置偏移。

输入模拟方面，不同平台有不同的API。Windows上可以用SendInput，macOS上可以用CGEvent，Linux上可以用XTest或者uinput。这些API的细节差异很大，比如SendInput需要构造INPUT结构体数组，CGEvent需要创建事件源和事件对象。如果项目需要跨平台，建议用现成的库来封装，比如PyAutoGUI或者pynput，它们屏蔽了平台差异，虽然性能略低但开发效率高很多。

等待策略是另一个容易被忽视的点。点击之后不能立刻进行下一次截屏和决策，因为界面可能需要时间响应。等太久效率低，等太短又可能截到中间状态。我的做法是采用“条件等待+超时”的策略：点击后循环截屏，直到检测到预期的界面变化（比如某个元素消失了、某个新元素出现了），或者超过最大等待时间（比如5秒）就放弃。检测界面变化可以用简单的图像差分，也可以用视觉模型判断，前者快但容易误判，后者准但慢。实际使用中我通常先用图像差分做快速判断，不确定的时候再调模型确认。

实操心得：在输入文字之前，一定要先点击输入框确保焦点正确。我遇到过好几次因为焦点没切过去，文字直接输到了上一个窗口里，排查了半天才发现问题。

4. 实操过程与核心环节实现：搭一个能跑的最小系统

4.1 环境准备与依赖安装

在开始写代码之前，先把环境搭好。我假设你用的是Python，因为生态最全、上手最快。核心依赖包括：截屏库（mss或者Pillow的ImageGrab）、输入模拟库（pynput或者PyAutoGUI）、图像处理库（OpenCV或者Pillow）、以及调用视觉模型的SDK（根据你选的模型服务来定）。

pip install mss pillow pynput opencv-python numpy

如果要用无障碍接口做辅助定位，Windows上可以装pywinauto，macOS上可以用pyobjc调用Accessibility API。这些是可选的，先不装也不影响最小系统跑起来。

视觉模型方面，你需要一个能接受图片输入、输出文本的模型服务。可以是本地的开源模型，也可以是云端的API。本地模型的好处是数据不出境、没有调用费用，缺点是硬件要求高、推理速度慢。云端API的好处是开箱即用、速度快，缺点是要花钱、有网络延迟。我的建议是先用云端API把流程跑通，确认方案可行之后再考虑迁移到本地模型。

4.2 截屏与坐标转换的代码实现

先写截屏模块。用mss库可以高效地截取指定区域的屏幕：

import mss import numpy as np from PIL import Image class ScreenCapture: def __init__(self, region=None): self.sct = mss.mss() self.region = region # (left, top, width, height) 或 None 表示全屏 def capture(self): if self.region: monitor = { "left": self.region[0], "top": self.region[1], "width": self.region[2], "height": self.region[3] } else: monitor = self.sct.monitors[1] # 主显示器 img = np.array(self.sct.grab(monitor)) return Image.fromarray(img[:, :, :3]) # 去掉alpha通道 def to_screen_coords(self, local_x, local_y, img_width, img_height): """把图片上的坐标转成屏幕绝对坐标""" if self.region: left, top, width, height = self.region else: mon = self.sct.monitors[1] left, top, width, height = mon["left"], mon["top"], mon["width"], mon["height"] scale_x = width / img_width scale_y = height / img_height screen_x = left + int(local_x * scale_x) screen_y = top + int(local_y * scale_y) return screen_x, screen_y

这段代码的关键在to_screen_coords方法。视觉模型返回的坐标是基于它收到的图片的，如果图片被缩放过了（很多模型会把输入图片统一缩放到某个尺寸），就需要按比例还原。如果截屏时只截了屏幕的一部分，还要加上偏移量。这两个转换漏掉任何一个，点击都会偏。

4.3 调用视觉模型解析界面

接下来是调用视觉模型。这里以通用的多模态API为例，展示怎么把截图和提示词一起发过去，拿到结构化的坐标输出：

import base64 import json from io import BytesIO def analyze_screen(image, task_description, model_client): # 把图片转成base64 buffered = BytesIO() image.save(buffered, format="JPEG", quality=85) img_base64 = base64.b64encode(buffered.getvalue()).decode() prompt = f"""你是一个界面操作助手。当前任务：{task_description} 请分析截图，找到完成任务所需的下一个操作元素。 输出JSON格式：{{"element": "元素描述", "action": "click/type/scroll", "coords": [x, y], "text": "如需输入的文字"}} 如果找不到目标元素，输出 {{"error": "原因"}}""" response = model_client.chat( messages=[{ "role": "user", "content": [ {"type": "text", "text": prompt}, {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{img_base64}"}} ] }] ) # 解析模型返回的JSON try: result = json.loads(response.content) except json.JSONDecodeError: # 模型可能返回了带markdown代码块的JSON，做个清洗 content = response.content.strip() if content.startswith("```"): content = content.split("\n", 1)[1].rsplit("```", 1)[0] result = json.loads(content) return result

这里有个细节值得展开：模型返回的JSON经常被包裹在markdown代码块里，直接json.loads会报错。所以需要先做一层清洗，把json和去掉。这个坑我踩过好几次，后来干脆写了个通用的清洗函数，所有模型输出都先过一遍。

4.4 执行动作与循环控制

拿到坐标和动作类型之后，就可以执行了。用pynput来模拟鼠标键盘：

from pynput.mouse import Controller as MouseController, Button from pynput.keyboard import Controller as KeyboardController import time mouse = MouseController() keyboard = KeyboardController() def execute_action(action, screen_x, screen_y, text=None): if action == "click": mouse.position = (screen_x, screen_y) time.sleep(0.1) # 给鼠标移动一点时间 mouse.click(Button.left) elif action == "type": mouse.position = (screen_x, screen_y) time.sleep(0.1) mouse.click(Button.left) # 先点击确保焦点 time.sleep(0.2) keyboard.type(text) elif action == "scroll": mouse.position = (screen_x, screen_y) mouse.scroll(0, -3) # 向下滚动 time.sleep(0.5) # 等待界面响应

主循环的逻辑就是：截屏→分析→执行→再截屏，直到任务完成或达到最大步数。判断任务完成可以用视觉模型来做，让它输出一个done标志；也可以用规则判断，比如检测到某个特定界面出现就认为完成了。

def run_task(task_description, max_steps=30): capture = ScreenCapture() for step in range(max_steps): image = capture.capture() result = analyze_screen(image, task_description, model_client) if "error" in result: print(f"第{step}步出错：{result['error']}") break if result.get("done"): print("任务完成") break coords = result.get("coords") if coords: screen_x, screen_y = capture.to_screen_coords( coords[0], coords[1], image.width, image.height ) execute_action(result["action"], screen_x, screen_y, result.get("text")) else: print(f"第{step}步没有拿到坐标，跳过")

这个最小系统跑起来之后，你就可以用它来完成一些简单的任务了，比如“打开浏览器搜索某个关键词”“在某个网页上填写表单”“点击某个按钮直到出现特定文字”。当然，实际任务会比这复杂得多，需要处理弹窗、验证码、加载等待等各种情况，但核心链路就是这些。

5. 常见问题与排查技巧实录

5.1 点击位置偏移：坐标转换的连环坑

点击偏移是这类项目最高频的问题，没有之一。表现是模型说“点击登录按钮”，结果鼠标点到了按钮旁边几像素的地方，有时候能触发有时候不能。排查这个问题要按链路一步步查。

先确认模型输出的坐标是不是基于你发给它的图片。如果你发的是缩放后的图片，模型输出的坐标就是缩放后的坐标系。然后检查你的坐标转换函数：有没有乘缩放比例？有没有加裁剪偏移？这两个都对了，再看屏幕的缩放设置。Windows和macOS都支持显示缩放（比如150%），系统API拿到的屏幕尺寸可能是逻辑尺寸而不是物理像素尺寸，而截屏库拿到的可能是物理像素。这两者不一致的话，坐标转换就会出错。解决办法是统一用物理像素，或者在转换时把缩放因子考虑进去。

还有一个隐蔽的坑：多显示器。如果你有多个显示器，主显示器的坐标原点可能不是(0,0)，截屏区域和屏幕坐标的对应关系会更复杂。建议在开发阶段先用单显示器，跑通之后再处理多显示器的情况。

5.2 模型识别不准：提示词与图片质量的双重优化

模型找不到元素或者找错元素，原因通常有两个：提示词不够明确，或者图片质量不够好。

提示词方面，我总结了一个模板，实测下来准确率比随意写的提示词高不少：

你是一个精确的界面分析助手。请仔细查看截图，完成以下任务：

1. 描述当前界面的整体布局和主要区域
2. 找到与任务相关的元素，描述它们的外观和位置
3. 输出最合适的下一个操作元素的中心坐标 任务：{task_description} 输出格式：{{“reasoning”: “你的分析过程”, “element”: “元素描述”, “coords”: [x, y], “action”: “click/type”}}

让模型先描述再输出坐标，相当于强制它做一次视觉校验，比直接要坐标准确得多。

图片质量方面，如果截图分辨率太低，小按钮和文字会糊成一团，模型自然认不出来。建议截屏时不要缩放，保持原始分辨率。如果图片太大导致模型处理慢，可以只截取相关区域而不是缩小整张图。另外JPEG压缩质量不要设太低，85以上比较稳妥，再低就会出现明显的块状伪影，影响文字识别。

5.3 操作无响应：焦点、权限与时序问题

有时候坐标明明点对了，但界面就是没反应。这种情况通常是三个原因之一：焦点不对、权限不够、或者时序不对。

焦点问题在输入文字时特别常见。你以为点击了输入框，但实际上焦点还在上一个窗口。解决办法是在输入之前先做一次显式点击，并且点击后稍微等一下再输入。如果还是不行，可以尝试用键盘的Tab键来切换焦点，有时候比鼠标点击更可靠。

权限问题在macOS上尤其突出。macOS对输入模拟有严格的权限控制，你的程序需要在“辅助功能”里被授权才能模拟鼠标键盘事件。如果没有授权，所有操作都会被静默忽略，不报错但也不生效。Windows上一般没有这个问题，但如果目标程序以管理员权限运行，而你的自动化程序是普通权限，也会出现操作无效的情况。

时序问题就是等待时间不够。界面响应需要时间，点击之后立刻截屏可能截到的是旧画面。我的经验是点击后至少等300毫秒再截屏，如果目标界面有加载动画，还要等动画结束。可以用轮询的方式：每隔100毫秒截一次屏，直到检测到预期变化或者超时。

5.4 常见问题速查表

避坑技巧：在开发阶段，把每一步的截图、模型输出、执行动作都记录到日志里。出问题的时候回看日志，比现场调试效率高得多。我习惯用带时间戳的文件夹存每一步的截图，排查的时候一目了然。

6. 性能优化与扩展思路：让系统跑得更快更稳

6.1 缓存与复用：减少重复的模型调用

视觉模型的调用是整个链路里最慢也最贵的一环。一个任务跑下来可能要调用几十次模型，每次几百毫秒到几秒，累积起来就很可观了。优化的思路是尽量减少不必要的调用。

一个简单的做法是缓存界面状态。如果连续两帧截图几乎一样（可以用图像差分判断），说明界面没有变化，那就不需要重新调用模型分析，直接复用上一次的分析结果。这在等待加载的场景下特别有用——界面没变的时候模型调用完全是浪费。

另一个做法是分层决策。不是每一步都需要视觉模型参与。比如“点击坐标(x,y)”这个动作，如果坐标已经确定了，执行本身不需要模型。可以把任务拆成“规划阶段”和“执行阶段”，规划阶段用模型确定步骤序列，执行阶段只做坐标定位和动作执行。坐标定位可以用更轻量的方法，比如模板匹配或者OCR，只有匹配失败的时候才回退到视觉模型。

6.2 并行化：截屏、推理与执行的流水线

当前的设计是串行的：截屏→推理→执行→截屏→……每一步都要等上一步完成。但实际上有些步骤可以并行。比如截屏可以在推理的同时进行，维护一个最新帧缓冲区；执行动作的时候可以同时准备下一次截屏。这样能把整体延迟降低百分之二三十。

更激进的方案是用两个线程：一个专门负责截屏和界面变化检测，另一个负责模型推理和决策。截屏线程持续运行，把最新帧放到共享缓冲区；决策线程从缓冲区取帧，调用模型，执行动作。两者通过队列通信，避免锁竞争。这个架构实现起来复杂一些，但对长任务来说效率提升明显。

6.3 扩展方向：从单步操作到复杂任务编排

最小系统只能做单步操作，但实际任务往往是多步的、有条件的。比如“登录后进入设置页面，找到通知选项，关闭所有通知”，这需要系统能记住当前处于哪个阶段、根据界面状态决定下一步做什么。

扩展的方向有几个。一是引入任务状态机，把复杂任务拆成多个阶段，每个阶段有明确的进入条件和退出条件。二是增加错误恢复机制，当某一步失败时能回退到上一个稳定状态重新尝试。三是支持条件分支，比如“如果出现弹窗就点确定，否则继续”。这些逻辑用代码写会比较繁琐，但可以用规则引擎或者简单的DSL来描述，让任务定义和代码实现分离。

还有一个值得关注的方向是和传统自动化工具结合。比如在浏览器里可以用Playwright直接操作DOM，比视觉方案快得多也稳得多；只有在遇到没有DOM接口的场景时才回退到视觉方案。这种混合架构能兼顾效率和覆盖率，是目前比较务实的做法。

7. 一些个人体会与后续可以尝试的方向

这个方向我断断续续跟了大半年，最大的感受是：视觉方案的上限取决于模型能力，但下限取决于工程细节。模型选得好不好决定了系统能不能理解复杂界面，但坐标转换、等待策略、异常处理这些工程细节决定了系统能不能稳定跑起来。我见过太多demo很惊艳但实际用起来到处是坑的项目，问题基本都出在工程细节上。

另一个体会是，不要试图用视觉方案解决所有问题。它适合的场景是“没有其他办法”的情况，但凡目标系统有API、有DOM、有无障碍接口，都应该优先用那些方案。视觉方案应该是工具箱里的最后一件工具，而不是第一件。把视觉方案和传统方案结合起来，在合适的场景用合适的技术，才是务实的做法。

后续如果继续深入，我会想尝试几个方向。一是把操作历史压缩成更紧凑的表示，减少上下文长度，让长任务不容易丢失状态。二是引入更细粒度的界面理解，不只是找元素坐标，还能理解元素之间的关系和界面的语义结构。三是探索多模态模型的微调，用自己积累的操作数据训练一个更懂特定软件界面的小模型，在精度和速度上都比通用模型更有优势。

这些方向目前都还在早期，网上能参考的成熟方案不多，但正因为如此才有折腾的空间。如果你也在做类似的事情，欢迎交流踩坑经验，这个领域目前最缺的就是真实的、带细节的实践记录。